[Soot-list] Converting reflection code to static code

Eric Bodden eric.bodden at ec-spride.de
Fri Feb 8 02:03:11 EST 2013


There is also the new "wjpp" pack, which runs before "cg". That might
be another option. I twas actually included for transformations such
as the one you are describing.

Of course it becomes interesting in case you already require some kind
of call graph to do your string analysis. In that case, things would
get complicated.

Eric

On 8 February 2013 02:25, Marc-Andre Laverdiere-Papineau
<marc-andre.laverdiere-papineau at polymtl.ca> wrote:
> Hello,
>
> Looks like you are right! I mixed jb with cg - my bad.
>
> You can try using PackManager.v().getPack("cg").insertAfter and
> insertBefore. This option gives you a small risk of breakage if things
> get modified in that pack, but that shouldn't happen too often ;)
>
> Marc-André Laverdière-Papineau
> Doctorant - PhD Candidate
>
> On 13-02-07 06:48 PM, ASHISH MISHRA wrote:
>> Thanks Marc-Andre,
>>
>> The packs and phases tutorial on Erics home page says-
>> http://www.bodden.de/2008/11/26/soot-packs/
>>
>> All cg, wjtp, wjop and wjap can be changed by adding a Scene transform.
>> So if I am not wrong, cg is modifiable.
>>
>> transforming wjtp to get whole program data flow analysis like String
>> and Points to information looks good.
>>
>> Ashish
>>
>>
>> On Fri, Feb 8, 2013 at 2:52 AM, Marc-Andre Laverdiere-Papineau
>> <marc-andre.laverdiere-papineau at polymtl.ca
>> <mailto:marc-andre.laverdiere-papineau at polymtl.ca>> wrote:
>>
>>     Namaste Ashish,
>>
>>
>>     Since I am not fully understanding your question, my answer could be
>>     missing the mark. Don't hesitate to ask point out if that is the case.
>>
>>     1) The phase
>>     You 'cannot' modify the phase cg, so that one is out question. Of
>>     course, you can always do what you want with the source code, but lets
>>     just say it is not really recommended ;)
>>
>>     By default wjop is disabled, so that's not the best option.
>>
>>     So if you want to do something before the call graph is constructed, go
>>     for wjpp, otherwise use wjtp.
>>
>>     2)
>>     The most tempting answer for me is to tell you to do two runs of soot.
>>     You can output the results of the first analysis in Jimple format, so
>>     the next run would be faster.
>>
>>     On the first run, you would take the spark output in wjtp and do your
>>     analysis and store results on the disk. (If you have any run-time
>>     information you want to put in, you could do that there, or in wjpp).
>>
>>     On the second run, you would do the transformations in wjpp and let
>>     Spark take it from there.
>>
>>     If the results are good, then a closer integration in soot (like in the
>>     cg phase) would make sense :)
>>
>>     3) Precise interprocedural analysis without CG
>>     Well, yes and no. You can determine call targets locally, but your
>>     precision may not be super good. Java programs love to pass objects all
>>     over the place, so the type can be hard to guess intraprocedurally. You
>>     can try, and fall back on CHA if you don't have local information.
>>
>>     Tripp et al. published a paper on their Andromeda system that does away
>>     with a global call graph construction - it could be interesting for you.
>>
>>     I hope it helps.
>>
>>     Regards,
>>
>>     Marc-André Laverdière-Papineau
>>     Doctorant - PhD Candidate
>>
>>     On 13-02-07 03:47 PM, ASHISH MISHRA wrote:
>>      > Hi all,
>>      >
>>      > I understand how to use tamiflex to handle reflection using soot.
>>     i wish
>>      > to solve the problem(To some extent , since, exact solution could
>>     not be
>>      > computed.) using String analysis, pointer analysis and some other
>>     static
>>      > ways. My main concerns is -
>>      >
>>      > Suppose I have  a code fragment say its original Program P
>>      >
>>      > //
>>      > 4String str= "someclassname"
>>      > 5Class clazz = Class.forNmae(str);
>>      >
>>      >   6Method mt=clazz.getMethod("execute", null);
>>      > 7 mt.invoke(o , null);
>>      >
>>      > //some other code.
>>      >
>>      > I can analyze the argument passed to the dynamic class loading at
>>     line 5
>>      > using the String analysis and if its is a Constant string or it
>>     can be
>>      > tracked via some other means I can enrich this program P to some
>>     thing like
>>      >
>>      > 4String str= "someclassname"
>>      > 5Class clazz = Class.forNmae(str);
>>      >
>>      >   6Method mt=clazz.getMethod("execute", null);
>>      > 7 mt.invoke(o , null);
>>      >
>>      > someclass sc = new someclass();
>>      > sc.execute();
>>      >
>>      > //some other code. say p'
>>      >
>>      > And finally run Call Graph construction algorithm on P'
>>      >
>>      > My first question is -
>>      >
>>      > I am confused about where to add my transformation-
>>      > 1)wjop - looks most promising ,as I am optimizing the source
>>      > 2)cg
>>      > 3wjtp
>>      >
>>      > Secondly
>>      >
>>      > Do I need to add  two different transformations ,
>>      > one to generate an On the fly Call graph with pointer analysis and
>>      > String analysis
>>      > and then apply the transformation from P to P' and then again
>>     generate a
>>      > Call graph again. i need a precise Call graph of whole
>>     application with
>>      > reflection information added by a side analysis like String , pointer
>>      > and other static analysis.
>>      >
>>      > Is its possible to get a precise inter procedural dataflow analysis
>>      > independent of Call graph construction. I feel its not possible
>>     as they
>>      > both are interlinked.
>>      >
>>      > Please help me on this.
>>      >
>>      > --
>>      > Regards,
>>      > Ashish Mishra
>>      > Graduate Student,
>>      > Computer Science and Automation Department,IISc
>>      > Cell : +91-9611194714
>>      > Mailto : ashishmishra at csa.iisc.ernet.in
>>     <mailto:ashishmishra at csa.iisc.ernet.in>
>>      > <mailto:ashishmishra at csa.iisc.ernet.in
>>     <mailto:ashishmishra at csa.iisc.ernet.in>>
>>      >
>>      >
>>      >
>>      > _______________________________________________
>>      > Soot-list mailing list
>>      > Soot-list at sable.mcgill.ca <mailto: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 <mailto:Soot-list at sable.mcgill.ca>
>>     http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>>
>>
>>
>> --
>> Regards,
>> Ashish Mishra
>> Graduate Student,
>> Computer Science and Automation Department,IISc
>> Cell : +91-9611194714
>> Mailto : ashishmishra at csa.iisc.ernet.in
>> <mailto:ashishmishra at csa.iisc.ernet.in>
>>
> _______________________________________________
> 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


More information about the Soot-list mailing list