[Soot-list] Creating n-custom entry point call graphs

[Cheng Zhang]

Hi Jason,

Did the "-f J" option resolve your previous problem (i.e., the
ClassCastException)?

As for you follow-up question, I have no specific ideas, as there can be
many causes. For example, the second entry method actually calls only eight
methods. You may find useful hints by searching for discussions about
incomplete call graphs in this mailing list.

-- Cheng

On Tue, Apr 28, 2015 at 1:29 PM, Jason Ott <jott002 at ucr.edu> wrote:

> Force it to Jimple, great idea.
>
> The next problem I have is that subsequent callgraphs are super small
> (size of 8)  and the first one has a size of (14,000+).  Any ideas why that
> is the case?
>
> On Tue, Apr 28, 2015 at 1:26 PM, Cheng Zhang <cheng.zhang.stap at gmail.com>
> wrote:
>
>> Hi Jason,
>>
>> Can you try to add "-f J" to your Soot arguments?
>> Sorry that I do not know exactly how it may be related to the problem,
>> but it might be a workaround.
>>
>> -- Cheng
>>
>> On Tue, Apr 28, 2015 at 1:06 PM, Jason Ott <jott002 at ucr.edu> wrote:
>>
>>> I have 1,000+ methods that will be used as custom entry points to
>>> generate a call graph.  They have different classes and what not.  I've
>>> tried a few different things which I will list below, after I discuss my
>>> general approach and shed some more light on exactly what I'm trying to do.
>>>
>>> As I said I have N-number of methods that I want to generate a call
>>> graph for.  They are in the following format:
>>>
>>>
>>> android.accessibilityservice.IAccessibilityServiceClient$Stub$Proxy.onAccessibilityEvent,
>>> android.accounts.IAccountAuthenticator$Stub.confirmCredentials,
>>> android.app.admin.IDevicePolicyManager$Stub.setMaximumFailedPasswordsForWipe,
>>> etc.
>>>
>>> The class is actually an interface that contains a static inner class
>>> (`$Stub`) that contains an inner class (`$Proxy`, which implements said
>>> interface).  So `android.accessibilityservice.IAccessibilityServiceClient`
>>> is an interface, `$Stub` is a static inner class to
>>> `android.accessibilityservice.IAccessibilityServiceClient` and `$Proxy` is
>>> an inner class to `$Stub`.
>>>
>>> My logic for solving this is as follows:
>>> // get records from disk...
>>> while(records.hasNextRecord()) {
>>>
>>> // get records from disk
>>> while(records.hasNextRecord()) {
>>> if(!setArgs) {
>>>     Options.v().parse(args);
>>>     setArgs = true;
>>> }
>>>
>>> SootClass sootClass = Scene.v().forceResolve(record.getClassName(), SootClass.BODIES);
>>> sootClass.setApplicationClass();
>>> Scene.v().loadNecessaryClasses();
>>> SootMethod sootMethod = sootClass.getMethodByName(record.getMethodName());
>>> List<SootMethod> entryPoints = new ArrayList<SootMethod>();
>>> entryPoints.add(sootMethod);
>>> Scene.v().setEntryPoints(entryPoints);
>>> PackManager.v().runPacks();
>>>
>>> soot.jimple.toolkits.callgraph.CallGraph callgraph = Scene.v().getCallGraph();
>>> System.out.println("[TestSpark] Call graph size " + callgraph.size());
>>>
>>> System.out.println(String.format("It took: %d seconds to generate a callgraph for: %s",
>>>         TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis() - start),
>>>         record.getClassName() + "." + record.getMethodName()));
>>>
>>> System.out.println("=====================================");}
>>>
>>> This allows me to generate the callgraph from the custom entry point.
>>> After the second iteration I get the following exception:
>>>
>>> Exception in thread "main" java.lang.ClassCastException:
>>> soot.baf.internal.BIdentityInst cannot be cast to soot.jimple.Stmt
>>> at
>>> soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.getImplicitTargets(OnFlyCallGraphBuilder.java:604)
>>> at
>>> soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processNewMethod(OnFlyCallGraphBuilder.java:530)
>>> at
>>> soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processReachables(OnFlyCallGraphBuilder.java:420)
>>> at soot.jimple.spark.solver.OnFlyCallGraph.build(OnFlyCallGraph.java:55)
>>> at
>>> soot.jimple.spark.builder.ContextInsensitiveBuilder.build(ContextInsensitiveBuilder.java:76)
>>> at
>>> soot.jimple.spark.SparkTransformer.internalTransform(SparkTransformer.java:84)
>>> at soot.SceneTransformer.transform(SceneTransformer.java:39)
>>> at soot.Transform.apply(Transform.java:90)
>>> at soot.RadioScenePack.internalApply(RadioScenePack.java:57)
>>> at
>>> soot.jimple.toolkits.callgraph.CallGraphPack.internalApply(CallGraphPack.java:49)
>>> at soot.Pack.apply(Pack.java:116)
>>> at soot.PackManager.runWholeProgramPacks(PackManager.java:563)
>>> at soot.PackManager.runPacksNormally(PackManager.java:456)
>>> at soot.PackManager.runPacks(PackManager.java:391)
>>> at Main.main(Main.java:39)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:483)
>>> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
>>>
>>> I've tried adding all the methods per class to a the entry points and
>>> run the callgraph when the class changes, obviously the above method,
>>> one-by-one resolution, etc.  But the exception continues to persist.
>>>
>>> Any ideas on how to build a callgraph for >50 different classes that
>>> contain n-number of custom entry points that don't produce the exception
>>> would be very helpful.  Thanks.
>>>
>>> _______________________________________________
>>> 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: https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20150428/a554ffff/attachment.html