[Soot-list] Incomplete Call Graph for Web Application

[Bernhard Berger]

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