[Soot-list] Call Graph with non-static entry points?

[Eric Bodden]

Hi all.

We observed the same problem when analyzing Android apps because also
there some objects like the main Activity objects just "appear from
nowhere". We solved this by adding an entry-point generator that
automatically generates stub methods which we then use as entry
points. Back then I discussed this with Ondrej and he told me this
would be the easiest way to go about this (the alternative being to
modify Spark). I think I now agree with Ondrej. It was actually
relatively easy and another advantage is that if you generate such
"fake main methods" automatically then you can generate them in such a
way that they simulate the correct lifecycle of the component you are
analyzing, e.g., call lifecycle methods such as "start" and "stop" in
the right order. Flow-sensitive analysis components such as Heros can
take advantage of that.

Eric

On 11 January 2013 08:36, Bernhard Berger <berber at tzi.de> wrote:
> Hi,
>
> the problem I observed had to do with calls to methods of the same instance. e.g.:
>
> void entryPoint(Param entryParameter) {
>   this.foo();
> }
>
> The call to foo was missing in the resulting call graph. It would be very logical to say that spark has got now information about this and therefore fails to resolve the call. That was the conclusions I made and solved my problem by generating a "correct" main method that generates an instance and respects the lifecycle of the managed object.
>
> Bernhard
>
> Am 11.01.2013 um 04:45 schrieb Laurie Hendren <hendren at cs.mcgill.ca>:
>
>> Hi Marc-Andre,
>>
>> I would have to look to see why that would be a problem,  but it may
>> have to do with needing a concrete object for the receiver.     In fact,
>> if your entry points are not static, doesn't some method need to create
>> an object on which it calls your entry point ..
>>
>> If so, then wouldn't you just have to create a dummy static method that
>> creates an object and makes the call,  and then start the call graph
>> algorithm at the dummy static method?
>>
>> Or ... am I misunderstanding your question?
>>
>> Laurie
>>
>>
>>
>> +--------------------------------------------------------------
>> | Laurie Hendren --- http://www.sable.mcgill.ca/~hendren
>> | Associate Dean (Academic), Faculty of Science
>> | Professor, School of Computer Science, McGill University
>> | New McLAB project:  http://www.sable.mcgill.ca/mclab/
>> | Also: www.sable.mcgill.ca/soot  www.sable.mcgill.ca/abc
>> +--------------------------------------------------------------
>>
>> On 10/01/2013 10:30 PM, Marc-Andre Laverdiere-Papineau wrote:
>>> Hello,
>>>
>>> Chatting with Bernhard yesterday, he was telling me that there are
>>> problems with Spark when the entry points are not static.
>>>
>>> Since my entry point detection framework is very good at detecting
>>> non-static things, I am wondering if that is making the framework moot.
>>>
>>> Can anyone confirm whether Spark, or call graph constructions algorithms
>>> in general, have an assumption concerning the type of entry points it is
>>> dealing with? Or should that be considered as a bug that we'll fix along
>>> the way?
>>>
>>> Regards,
>>>
>>
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list



-- 
Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt