[Soot-list] Identify virtual-call targets and library callee

[Haipeng Cai]

Hi Marc-Andre,

I can see that your work-around is a viable solution, I would like to try
that later.
Thank you a lot!

Regards,
-Haipeng Cai



On Tue, Jul 29, 2014 at 9:25 AM, Marc-André Laverdière <
marc-andre.laverdiere-papineau at polymtl.ca> wrote:

> Hi Haipeng,
>
> When you say application vs library, are you referring to
> SootClass.isApplicationClass and SootClass.isLibraryClass?
>
> The Soot class loader has this annoying 'feature' that any class that is
> referenced from the application becomes also an application class.
>
> The work-around I am using right now to classify them properly is to
> extract the information in the jars in the library scope. and then sort
> them out accordingly.
>
> Marc-André Laverdière-Papineau
> Doctorant - PhD Candidate
>
> On 07/26/2014 05:52 PM, Haipeng Cai wrote:
> > Hi all,
> >
> > To follow up my previous questions, now I can see that getting all
> > possible virtual call targets could be done by a CHA if not using
> > CallGraph builder with conservative cg and spark options. However,
> > Distinguishing application callees from library callees with static
> > analysis seem to be harder than listing all possible targets, based on
> > my experience with the following example case:
> >
> > _$i6 = interfaceinvoke r10.<org.w3c.dom.NodeList: int getLength()>(); //
> > in XML-security  _
> >
> > For this call site, CHA gives an application method
> > _org.apache.xml.security.utils.HelperNodeList: int getLength();_
> > as the only possible target by searching 'subtypes' from class
> > 'org.w3c.dom.NodeList'. Indeed, this is the only one in the application
> > code.
> >
> > However, for a particular execution, r10 points to an object not of the
> > above application class , and the real callee is actually the
> > 'getLength' method implemented in the root class 'org.w3c.dom.NodeList',
> > which is in a library (xalan.jar) that I put on the Soot Classpath.
> > Therefore, CHA got a bad case telling mistakenly a library callee as an
> > application callee.
> >
> > I am wondering how to precisely identify application callee versus
> > library calee in static analysis. Does even the most precise static p2
> > analysis solve this problem?
> >
> > Thanks for your inputs in advance.
> >
> >
> >
> >
> > On Thu, Jul 24, 2014 at 8:14 PM, Haipeng Cai <hcai at nd.edu
> > <mailto:hcai at nd.edu>> wrote:
> >
> >     Hi All,
> >
> >     I am doing a static interprocedural dependence analysis with Soot
> >     for Java programs and having two difficulties:
> >
> >     1. How do I safely identify all possible callees at a call site,
> >     especially virtual call site?
> >
> >     2. How should I discern, among all the callees identified above,
> >     library callees from application callees?
> >
> >     I have tried the CallGraph class, which seems to be quite
> >     incomplete; I also noticed that there is a method "IsJDKLibraryCall"
> >     in SootMethod class, which only tells JDK library calls from others,
> >     though.
> >
> >     Any thoughts and advises are appreciated.
> >     Thanks,
> >
> >     _______________________________________________
> >     Soot-list mailing list
> >     Soot-list at CS.McGill.CA <mailto:Soot-list at CS.McGill.CA>
> >     https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
> >     <https://mailman.cs.mcgill.ca/mailman/listinfo/soot-list>
> >
> >
> >
> >
> > _______________________________________________
> > Soot-list mailing list
> > Soot-list at CS.McGill.CA
> > https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
> >
> _______________________________________________
> Soot-list mailing list
> Soot-list at CS.McGill.CA
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20140729/d3ad2fa7/attachment.html