[Soot-list] Incomplete Call Graph for Web Application

Marc-Andre Laverdiere-Papineau marc-andre.laverdiere-papineau at polymtl.ca
Thu Dec 13 05:46:52 EST 2012


Hello,

Thanks for sharing. Since my PhD research is all about analyzing JEE 
webapps, I take a lot of interest when people tell me what challenges 
they are facing. And what solutions they found.

I found the same lot of challenges when I was preparing my to-do list. 
My thinking is along the same lines as yours, actually.

So you are using program transformations to convert the program to a 
saner form. I started coding that and I'm barely scratching the surface. 
Its a couple months of work just to get started... so that brings me to 
the logical question:

Have you released that code yet?  :D


Marc-André Laverdière-Papineau
Doctorant - PhD Candidate

On 12-12-13 04:09 PM, Bernhard Berger wrote:
> Hi,
>
> I've analyzed JEE applications (Java 5 and Java 1.4) and some Android applications -which have similar problems- in the past and currently writing down the results to publish them. For enterprise systems there are different hurdles to take. If you have a Web-Frontend you have to deal with Java Servlets and their special life cycle. There you have to take JSP into account, too (some sort of precompiling is necessary since they may contain normal Java code). In the next step you have to connect the front end with the business logic (aka session beans), having their own life cycles. Depending on the JEE version this is quite challenging (for older versions there is no dependency between the implementation and the interface). Furthermore, you have to look for the additional container magic, such as dependency injection, pooling, security mechanisms, interceptors and so forth.
> During my recent work I created some kind of app-specific container abstraction to allow soot (and other frameworks) to analyze the code and to measure the effects to the call graph and analyses results. In contrast to Marc-Andrés suggestion it is done in a preprocessing step, containing different static analysis to extract all necessary facts, to generate a modified version of the app containing the container model.
>
> Regards,
>
> Bernhard
>
>
> Am 13.12.2012 um 11:09 schrieb Marc-Andre Laverdiere-Papineau <marc-andre.laverdiere-papineau at polymtl.ca>:
>
>> Hi,
>>
>> I read that paper and I'm glad that work is ongoing. A JEE server like
>> glassfish has nearly 100mb of jars, so that's no fun for a static analyzer.
>>
>> The thing that wouldn't help us is that its a priori algorithm, from
>> what I recall. Spark's needs to be able to run on the fly with no a
>> priori knowledge of the program or its libs.
>>
>> So porting this to soot is not going to be trivial. And that's why its
>> going to be even more awesome when we get it!
>>
>> In the meantime, I can envision some post-processing of the call graph
>> to add some edges as needed. That is _not_ a perfect solution, but I
>> think I can prototype something fast that may help us all until the
>> Waterloo call-graph-fu comes with the perfect solution :D
>>
>> Regards,
>>
>>
>> Marc-André Laverdière-Papineau
>> Doctorant - PhD Candidate
>>
>> On 12-12-13 02:05 PM, Eric Bodden wrote:
>>> Hello.
>>>
>>>> In other words, we'd need a call graph algorithm that can point to an
>>>> interface and leave it at that if need be. I don't recall a Spark option
>>>> to enable that. Any pointers to make it happen?
>>>
>>> I think many people are aware of this problem, and the problem is
>>> quite pressing, but not much research has been done in this area. The
>>> question is what can be done automatically if you really can assume
>>> nothing about the library except for it's API.
>>>
>>> Karim Ali and Ondrej Lhotak had a paper in that direction but it still
>>> extracts some knowledge about the API's implementation as far as I can
>>> recall:
>>> http://plg.uwaterloo.ca/~olhotak/pubs/ecoop12.pdf
>>>
>>> Ondrej, by the way, are you still planning on integrating this into Soot?
>>>
>>> Cheers,
>>> Eric
>>>
>> _______________________________________________
>> 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
>


More information about the Soot-list mailing list