[Soot-list] Questions about soot spark

[GRACE GU]

To whom it may concern,

Hello, I am new to soot and currently I am trying to use spark to construct call graph. I have 4 questions and look forward to some replies. Thanks in advance.

1. 

I did a tiny test, if I set cg.spark on with default options (i.e. on-fly-cg:true,rta:false,vta:false,etc...), I got a call graph size with size of 18. (I used "-p cg.spark enabled")

Then If I set cg.spark to on-fly-cg:false,rta:true, the call graph suddenly exploded to size of 193543. How could this happen? I was wondering whether setting rta:true would implicitly change some other settings, which caused this explode problem? (I used "-p cg.spark enabled,on-fly-cg:false,rta:true")

2.

I got an exception if I tried to set_no_bodies_for_excluded to true. Error message is:

Warning: java.dyn.InvokeDynamic is a phantom class!

[Call Graph] For information on where the call graph may be incomplete, use the verbose option to the cg phase.

[Spark] Pointer Assignment Graph in 0.1 seconds.

Exception in thread "main" java.lang.RuntimeException: This operation requires resolving level HIERARCHY but sun.misc.ClassFileTransformer is at resolving level DANGLING

If you are extending Soot, try to add the following call before calling soot.Main.main(..):

Scene.v().addBasicClass(sun.misc.ClassFileTransformer,HIERARCHY);

Otherwise, try whole-program mode (-w).

at soot.SootClass.checkLevel(SootClass.java:125)

at soot.FastHierarchy.canStoreClass(FastHierarchy.java:280)

at soot.FastHierarchy.canStoreType(FastHierarchy.java:215)

at soot.FastHierarchy.canStoreType(FastHierarchy.java:261)

at soot.jimple.spark.internal.TypeManager.castNeverFails(TypeManager.java:113)

at soot.jimple.spark.internal.TypeManager.makeTypeMask(TypeManager.java:92)

at soot.jimple.spark.SparkTransformer.internalTransform(SparkTransformer.java:91)

at soot.SceneTransformer.transform(SceneTransformer.java:39)

......

Here is part of my settings, I have already set to whole program mode. 

Options.v().set_whole_program(true);

Options.v().set_allow_phantom_refs(true);

Options.v().set_no_bodies_for_excluded(true);

Scene.v().loadNecessaryClasses();

3.

And another question to be clear, as I observed, the library classes are excluded from transformation by default, right? It seems that I don't need to set_exclude for library classes. 

4.

Last question, as I referred to the API from https://ssebuild.cased.de/nightly/soot/javadoc/, it seems that sometimes methods described in this javadoc don't exist?

Same situation for the soot command line options document from https://ssebuild.cased.de/nightly/soot/doc/soot_options.htm, sometimes, although very rare, options could be invalid? (eg. on-the-fly?)

I am wondering where could I search for up-to-date documents?

Thank you for your patience. I am looking forward to your reply. 

Best regards,

Grace

[Steven Arzt]

Hi Grace,

 

1.       In general, RTA is less precise than SPARK’s default allocation site propagation. How large the effect is depends on the concrete program you are analyzing. Without access to your target program, it’s hard to say what happens there.

 

2.       Please provide the full command-line with which you started Soot. If you use Soot in a program of your own, create a minimal working example.

 

3.       Library classes are not transformed by default, but bodies of methods inside library classes get loaded if required for callgraph construction. If you exclude the methods, this will not change anything as they are already library classes. However, if you use the –no-bodies-for-excluded option, you explicitly ban Soot from loading the method bodies even if required for callgraph construction which can lead to an incomplete callgraph.

 

4.       The Javadoc available on the ssebuild machine are generated from source code by an automated script that runs every night. This document is always up-to-date. I would be very surprised to see Javadoc for non-existing methods in there. Do you have a concrete example?

 

Best regards,

  Steven

 

 

M.Sc. M.Sc. Steven Arzt

Secure Software Engineering Group (SSE)

European Center for Security and Privacy by Design (EC SPRIDE)

Rheinstraße 75

D-64293 Darmstadt

Phone: +49 61 51 869-336

Fax: +49 61 51 16-72118

eMail: steve...@ec-spride.de

Web: http://sse.ec-spride.de