[Soot-list] Soot options in soot-infoflow

[Cheng Zhang]

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/dfcd71e3/attachment.html