[Soot-list] Call Graph Generation Performance
Simone Aonzo
simone.aonzo at gmail.com
Thu Apr 7 11:50:42 EDT 2016
Hi Steven,
thanks for the suggestion about the the Exceptions.
I launch the vm with the parameter:
-Xmx 8192m -Xms4096m
but despite other optimization options the search for the callback
needed too much time for my purposes. So I wrote this method:
protected void internalTransform(String phaseName,
@SuppressWarnings("rawtypes") Map options) {
System.out.println("--Callback analysis starts--");
Iterator<SootClass> classes =
Scene.v().getClasses().iterator();
while (classes.hasNext()) {
SootClass sootClass = classes.next();
if (startWithApi(sootClass.toString())) {
continue; // this class belong to api
}
Set<SootClass> allIfaces =
collectAllInterfaces(sootClass);
for (SootClass iface : allIfaces) {
if
(androidCallbackClasses.contains(iface.toString())) {
List<SootClass> superclasses =
getAllSuperclasses(sootClass);
classesWithCallbacks.add(new
ClassWithCallback<>(sootClass, iface));
}
}
}
System.out.println("--Callback analysis ends--");
}
because I don't need to add the callbacks to the dummy method.
On 07/04/2016 14:40, Steven Arzt wrote:
>
> Hi all,
>
> The access path length does not influence the callgraph. It is only
> important for the data flow tracker. Inside the callgraph, there are
> no access paths. The same holds for enabling or disabling static field
> tracking, or flow-sensitivity in alias tracking. Exceptions do matter,
> because when you disable exceptions, the callgraph does not need to
> consider control flows via uncaught exceptions.
>
> @Simone: How much Java heap space did you allocate? Note that you need
> to explicitly increase the heap using the –Xmx JVM parameter, e.g.,
> -Xmx4g for 4 GB.
>
> Yes, it is indeed the size and complexity of the classes.dex file that
> matters. The remainder of the APK file has no influence on callgraph
> construction time.
>
> Enabling or disabling callback handling makes a great difference.
> FlowDroid performs iterative callback analysis. It first takes all
> entry points that are visible from the manifest file. It then scans
> for registrations of new callbacks such as button click handlers. If
> one is found, this callback gets added to the dummy main method and
> the process is restarted. We need to start over, because we need a new
> interim callgraph from which we can then again scan for new
> registrations. In the future, we will have to see whether and how we
> can avoid the recomputation of all the interim callgraphs, but that’s
> future work. If you are interested, you might want to look into how we
> can dynamically extend the interim callgraphs.
>
> Best regards,
>
> Steven
>
> *Von:*soot-list-bounces at CS.McGill.CA
> [mailto:soot-list-bounces at CS.McGill.CA] *Im Auftrag von *Enzo Lucky
> *Gesendet:* Donnerstag, 7. April 2016 12:17
> *An:* Simone Aonzo; soot-list at CS.McGill.CA
> *Betreff:* Re: [Soot-list] Call Graph Generation Performance
>
> Hi Simone,
>
> I am aware of the options (e.g. the access path length) you use, my
> understanding is using these options will make Soot generate a
> non-precise call graph. I wanted to know if there are other options to
> improve performance that wouldn't require sacrificing the precision of
> the call graph.
>
> Thanks,
>
> Enzo
>
> On Thursday, April 7, 2016 8:48 AM, Simone Aonzo
> <simone.aonzo at gmail.com <mailto:simone.aonzo at gmail.com>> wrote:
>
>
> Yes, I use FlowDroid.
> The size of the apk is irrilevant, what matters is the size of the
> classes.dex
>
> With my configuration running on an Intel(R) Core(TM) i7-4810MQ CPU @
> 2.80GHz:
> small, 2,3MB, 30 sec
> medium, 6,8MB, 1 minute
> big, 11MB (whatsapp), 3 minutes
>
> With the default configuration I've never seen it halting [but I can't
> say that it never halts, dear Turing :)] with the medium and the big
> dex, also after 7 hours.
>
> Keep in touch!
> Simone
>
> On 06/04/2016 19:11, Denis Bogdanas wrote:
>
> Interesting,
>
> I'm assuming you use FlowDroid. I'm also looking into good options
> for performance.
>
> What size is the apk and how much faster are these settings
> compared to defaults?
>
> thanks,
>
> Denis
>
> On 6 April 2016 at 06:05, Simone Aonzo <simone.aonzo at gmail.com
> <mailto:simone.aonzo at gmail.com>> wrote:
>
> This is the way I get a call graph in a reasonable time... if someone
> has better ideas: share!
>
> soot.G.reset();
> SetupApplication setupApplication = new
> SetupApplication(androidJar.toString(), apk.toString());
> setupApplication.getConfig().setFlowSensitiveAliasing(false);
> // --aliasflowins
> setupApplication.getConfig().setAccessPathLength(1); // --aplength n
> setupApplication.getConfig().setEnableStaticFieldTracking(false);
> // --nostatic
> setupApplication.getConfig().setEnableCallbacks(false);//
> --nocallbacks
> setupApplication.getConfig().setPathBuilder(DefaultPathBuilderFactory.PathBuilder.ContextSensitive);//
> --pathalgo
> setupApplication.getConfig().setComputeResultPaths(false); //
> --nopaths
> setupApplication.getConfig().setEnableExceptionTracking(false);
> // --noexceptions
> setupApplication.calculateSourcesSinksEntrypoints(sourcesAndSinks.toString());
>
> Options.v().set_src_prec(Options.src_prec_apk);
> Options.v().set_soot_classpath("/usr/lib/jvm/java-8-oracle/jre/lib/rt.jar:/usr/lib/jvm/java-8-oracle/jre/lib/jce.jar:.");
> Options.v().set_process_dir(Collections.singletonList(apk.toString()));
> Options.v().set_android_jars(androidJar.toString());
>
> List<String> excludeList = new LinkedList<String>();
> excludeList.add("java.");
> excludeList.add("sun.misc.");
> excludeList.add("android.");
> excludeList.add("org.apache.");
> excludeList.add("soot.");
> excludeList.add("javax.servlet.");
>
> Options.v().set_exclude(excludeList);
> Options.v().set_no_bodies_for_excluded(true);
> Options.v().set_output_format(Options.output_format_none);
> Options.v().set_allow_phantom_refs(true);
> Options.v().set_whole_program(true);
> Options.v().setPhaseOption("cg.spark", "on");
> Options.v().setPhaseOption("cg", "trim-clinit:false");
> SootMethod dummyMain =
> setupApplication.getEntryPointCreator().createDummyMain();
> Options.v().set_main_class(dummyMain.getSignature());
> Scene.v().setEntryPoints(Collections.singletonList(dummyMain));
> PackManager.v().runPacks();
> CallGraph callGraph = Scene.v().getCallGraph();
>
> 2016-04-04 12:37 GMT+02:00 Enzo Lucky <luckenzo24 at yahoo.com
> <mailto:luckenzo24 at yahoo.com>>:
> > Hi,
> >
> > I am using Soot to generate call graph of some Android apps, and
> I find Soot
> > take more than a day to generate the call graph for some apps.
> Can I do
> > anything other than the suggestions in the FlowDroid homepage
> >
> (https://github.com/secure-software-engineering/soot-infoflow-android/wiki#improving-performance)?
> > I want a precise call graph and hence, I didn't use any of the
> options.
> > Also, is the time normal or am I doing something wrong? Please
> find attached
> > my dummy main class.
> >
> > Thanks,
> > Enzo
> >
> > _______________________________________________
> > Soot-list mailing list
> > Soot-list at CS.McGill.CA <mailto:Soot-list at CS.McGill.CA>
> > https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
> <https://mailman.cs.mcgill.ca/mailman/listinfo/soot-list>
> >
> _______________________________________________
> Soot-list mailing list
> Soot-list at CS.McGill.CA <mailto:Soot-list at CS.McGill.CA>
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
> <https://mailman.cs.mcgill.ca/mailman/listinfo/soot-list>
>
>
>
>
> --
>
> Denis
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at CS.McGill.CA <mailto:Soot-list at CS.McGill.CA>
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
> <https://mailman.cs.mcgill.ca/mailman/listinfo/soot-list>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20160407/5da28da2/attachment-0001.html
More information about the Soot-list
mailing list