[Soot-list] Soot options in soot-infoflow

[Marc-André Laverdière]

Hello,

By default, Soot excludes things in the com.sun.*, java.*, javax.* and
com.apple.* packages. The option -include-all disables that.

Flowdroid is extensible and you can provide your own IInfoflowConfig to
change the Soot parameters if you need.

As for the resolution level, I was under the impression that it was
monotonic, except when someone uses Scene.forceResolve, which can
transform a phantom class (resolving level BODIES) to something lower if
desired. That's really a hack, because phantom classes is a late
addition to Soot.

Regarding src-prec, it is a precedence setting, not a 'disable
everything else' setting. By default, Soot prefers bytecode first. This
is useful in case that the same class definition is provided in
different forms for any reason.

Marc-André Laverdière-Papineau
Doctorant - PhD Candidate

On 07/23/2014 09:01 PM, Cheng Zhang wrote:
> Hi,
> 
> I am using soot-infoflow described in the paper [1] on SecuriBench Micro
> as well as other programs.
> I hit the RuntimeException as below:
> 
>     java.lang.RuntimeException: This operation requires resolving level
> SIGNATURES but java.util.logging.Logger$1 is at resolving level DANGLING
>     If you are extending Soot, try to add the following call before
> calling soot.Main.main(..):
>     Scene.v().addBasicClass(java.util.logging.Logger$1,SIGNATURES);
>     Otherwise, try whole-program mode (-w).
> 
> Later I found that this exception can be avoided, if the
> "-no-bodies-for-excluded" option is turned off in method
> initializeSoot() of class soot.jimple.infoflow.Infoflow. 
> Also, using "-no-bodies-for-excluded" as the keyword, I could find a
> thread in this mailing list:
> 
>   https://mailman.cs.mcgill.ca/pipermail/soot-list/2013-March/005551.html
> 
> 
> But during the process of diagnosing this exception, I found some
> relevant details of "-no-bodies-for-excluded".
> The most relevant code is in method processResolveWorklist() of class
> soot.SootResolver. 
> In my case, I have three classes, namely
> com.sun.jmx.remote.util.ClassLogger, java.util.logging.Logger,
> java.util.logging.Logger$1, in which ClassLogger references Logger and
> Logger references Logger$1.
>   - When the -no-bodies-for-excluded is off, all these classes will
> brought to BODIES level, which is fine. 
>   - When the -no-bodies-for-excluded is on, ClassLogger, which is
> excluded, will brought to SIGNATURE level. And Logger is inserted into
> the "SIGNATURE" LinkedList in the worklist.
>     Then, when Logger is retrieved from the worklist to resolve, the
> index i is 1 (i.e., SIGNATURE). 
>     But because Logger is included, it is brought to BODIES and Logger$1
> is inserted into the "BODIES" LinkedList in the worklist.
>     Since the index i can never go back to 2 (i.e., BODIES) within the
> current while loop, the class Logger$1 is not resolved and its level
> remains at DANGLING.
>     This eventually causes the RuntimeException.
> 
> My observation here is that the resolution level can go up and down,
> when a class is excluded and some referenced classes are included.
> While the index i always decreases, some classes (at higher level) may
> not be resolved in the end.
> 
> Is it a known design of -no-bodies-for-excluded? 
> Or am I actually looking at some out-dated code of Soot...? (I cloned
> the code from GitHub quite recently.)
> 
> In method initializeSoot() of class soot.jimple.infoflow.Infoflow, I
> found that the -src-prec option is set to src_prec_java (for non-android
> case).
> But it seems that soot-infoflow can still run on .class and .jar files,
> without using .java files. Am I missing anything related to this option?
> 
> 
> [1] FlowDroid: Precise Context, Flow, Field, Object-sensitive and
> Lifecycle-aware Taint Analysis for Android Apps, PLDI '14
> 
> Thanks,
> Cheng
> 
> 
> _______________________________________________
> Soot-list mailing list
> Soot-list at CS.McGill.CA
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>