[Soot-list] Soot options in soot-infoflow

Cheng Zhang cheng.zhang.stap at gmail.com
Wed Jul 23 21:01:57 EDT 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20140723/5de18c14/attachment.html 


More information about the Soot-list mailing list