[Soot-list] Soot options in soot-infoflow

Thu Jul 24 09:58:47 EDT 2014

Hi Cheng, hi Marc-André,

FlowDroid relies on -no-bodies-for-excluded quite heavily to reduce analysis time. For larger applications, loading all bodies of all JDK classes referenced from the target application would induce a very heavy memory and performance overhead. The story goes on when constructing callgraphs: You usually neither want nor need all the JDK in there as this would again cost you a lot of time and memory. I would thus not remove this option.

Concerning your other question: FlowDroid can run on any input files on which Soot can run, so class or JAR files is all you need. There is no requirement to have source files.

Concerning the main problem: When the resolver finally gets the job to bring Logger$1 to BODIES, it should automatically also bring it to all earlier levels. It’s not possible to jump levels anyway, so the resolver should (if it’s not buggy) be totally fine with getting a class for level x and doing all levels < x on its own automatically.

Best regards,

  Steven 

Von: soot-list-bounces at CS.McGill.CA [mailto:soot-list-bounces at CS.McGill.CA] Im Auftrag von Cheng Zhang
Gesendet: Donnerstag, 24. Juli 2014 15:47
An: Marc-André Laverdière
Cc: soot-list at CS.McGill.CA
Betreff: Re: [Soot-list] Soot options in soot-infoflow

Hi Marc-André,

Thanks for sharing your insights.

I did not know that src-prec is a precedence setting.

As for the -no-bodies-for-excluded option, I believe that Eric introduced it mainly to reduce Soot's analysis time. 

Perhaps we need to be careful when specifying the lists of -include and -exclude, because some included classes

may reference excluded classes which may reference other included classes. As you suggested, it may be safer

to try -include-all or disable -no-bodies-for-excluded in the first attempt. 

Best,

Cheng

On Thu, Jul 24, 2014 at 8:59 AM, Marc-André Laverdière <marc-andre.laverdiere-papineau at polymtl.ca> wrote:

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
>
_______________________________________________
Soot-list mailing list
Soot-list at CS.McGill.CA
https://mailman.CS.McGill.CA/mailman/listinfo/soot-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20140724/e498da5e/attachment-0001.html 