[Soot-list] spark points to analysis

salim bansal salim.bansal at gmail.com
Tue Feb 26 15:32:32 EST 2013


Sure, for unreachable code you will never get any edges. So do you
mean that the code, during execution time, is not actually
unreachable? In that case you are probably having an incomplete main
method.

Yes the code is reachable at execution time though main method doesn't cover
it due to asynchronous execution of callback/listeners. e.g.
android.view.View has a method setOnCilckListener(listenerObject) and when
a click
event is generated the android framework code would call onClick() on the
listenerObject.
But as I am only processing the app code and not the Android source code,
the onClick()
method of the listenerObject would be unreachable from the main method,
though it becomes
reachable when the click event happens as android framework code takes care
of it.



On Tue, Feb 26, 2013 at 2:03 AM, Eric Bodden <eric.bodden at ec-spride.de>wrote:

> Hi Salim.
>
> > Thanks a lot for the reply Eric.
> > I am trying to build call graph for android apps.
> > For that I have created a class with main method that calls relevant
> methods
> > like
> > onCreate, onStart()... of the launcher activity class of the app. And
> this
> > main method is entry point for soot.
>
> Ah, a well known problem :-)
>
> > Then I run spark points-to analysis. When it is finished I go through all
> > the methods of the app looking for statements
> > like a.method1() and add an edge from this statement to method1() of all
> the
> > possible type that can be pointed to by 'a'.
>
> I don't quite understand. Would Spark not be adding those edges
> automatically?
>
> > But as there are lots of callbacks involved a lot of code is unreachable
> > from the custom entry point(the main class). So I think when I execute
> >
> > Scene.v().getPointsToAnalysis().reachingObjects(<local pointing to
> > a>).possibleTypes()
> >
> > on a code that was unreachable from the main method I get an empty set.
> Is
> > it correct?
>
> Sure, for unreachable code you will never get any edges. So do you
> mean that the code, during execution time, is not actually
> unreachable? In that case you are probably having an incomplete main
> method.
>
> > Also when I encounter a callback registration site like
> > src.register(listener) I add edges to call graph from this statement to
> all
> > the methods in 'listener' class. But this happens after spark is run and
> now
> > though the call graph  covers the call back code but the points-to set is
> > still empty for the code that was unreachable from the main method,
> before
> > spark was run.
> > Is my understanding correct? Is there a better/correct way to built the
> > complete call graph considering all the callbacks present in android
> apps?
>
> My advice would be to not patch the call graph afterwards but to
> instead model your main method completely and correctly. That's what
> we are doing for Android and it seems to be working fine.
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20130226/7de81b18/attachment.html 


More information about the Soot-list mailing list