[Soot-list] R: Inter-procedural info-flow analysis for Javalibraries

[Darius]

Hi Steven,

Thank you for your reply.
I followed your guidelines and tried different approaches. So far the best one seems to be to create a dummy main, using SequantialEntryPointCreator class from soot-infoflow repository.
Though some issues arise and I think some may interest you:
- Using the soot.jimple.toolkits.ide.icfg.JimpleBasedInterproceduralCFG class to generate the ICFG a NullPointerException is raised, while everything works using soot.jimple.toolkits.ide.icfg.OnTheFlyJimpleBasedICFG. I don’t know if it is my fault, but I thought it may intereset you in case it is a bug (I can send you the stack trace if you want)
- While executing the Heros solver a RuntimeException arises saying there is no body present for a native method (ie. <java.lang.System: void arraycopy(java.lang.Object,int,java.lang.Object,int,int)>). I can’t get around this issue and have no idea why I get it (heros should ignore native methods, right?)

For my analysis I’ll try to use soot-infoflow, it seems there are a lot of useful methods already implemented (thanks!).

Thank you very much for your answer again.

Best Regards,
Darius

Da: Arzt, Steven
Inviato: lunedì 20 novembre 2017 12:04
A: Darius; soot-list at CS.McGill.CA
Oggetto: AW: [Soot-list] Inter-procedural info-flow analysis for Javalibraries

Hi Darius,

For performing anm IFDS analysis, you need a callgraph. Traditionally, callgraphs are built iteratively from a set of entry points. Since you did not specify any entry points, there is nowhere to start for SPARK, Soot’s callgraph generator, and consequently, you do not have a callgraph. Without one, there is no interprocedural control flow graph (ICFG). IFDS, however, propagates data flow abstractions over an ICFG. To cut a long story short, you need to get a callgraph.

You have several options how to proceed here. One is to over-approximate the callgraph by treating all public methods as entry points for a CHA callgraph. That is the easiest option, but as imprecise as it can be. If you nevertheless want to go down that (dark) road, look up Soot’s “all-reachables” CG option. A better alternative is to create a dummy main method as an entry point that calls the various library method in an order that makes sense for your library. With that concept, you can model API restrictions such as “foo() is always called before bar()”. Look at FlowDroid’s various entry point creators such as the SequentialEntryPointCreator class for that option. The third option is to use SPARK’s library mode, which has a quite particular semantics. Have a look at “Library mode” in the Soot command-line documentation [1].

Best regards,
  Steven

[1] https://soot-build.cs.uni-paderborn.de/public/origin/develop/soot/soot-develop/options/soot_options.htm

Von: Soot-list [mailto:soot-list-bounces at cs.mcgill.ca] Im Auftrag von Darius
Gesendet: Montag, 20. November 2017 11:03
An: soot-list at CS.McGill.CA
Betreff: [Soot-list] Inter-procedural info-flow analysis for Java libraries


Hello,

My name is Darius and I’m currently working on my M.Sc. thesis.
I need to perform inter-procedural info-flow analysis for a given Java library and I hope you can help me getting on the right track.
For my analysis I need to compute inter-procedural info-flow analysis for a given method of the given library, to see how the data from the method’s parameters flows in the library. Specifically I need to see which sensible sinks it reaches.

So far I’ve tried using HEROS in combination with Soot, specifically using the following code:
               SootMethod sm = [the starting point of my analysis]
IFDSTabulationProblem<Unit, ?, SootMethod, InterproceduralCFG<Unit,SootMethod>> lif = lif = new IFDSLocalInfoFlow(new OnTheFlyJimpleBasedICFG(sm));
JimpleIFDSSolver<?, InterproceduralCFG<Unit, SootMethod>> solver = new JimpleIFDSSolver(lif);
                solver.solve();

But it throws this exception:
    Exception in thread "main" java.lang.RuntimeException: There is no main class set!
from the IFDSLocalInfoFlow.initialSeeds() methods.
Even if I overload the initialSeeds() method to return the initial seeds I want it gives me the same Exception (no main class set).

So my questions are:
- Since I want to analyze libraries, is there a way to avoid Soot asking for main class/method?
- Is my approach the correct approach?
- Is there a better way to do this?

Thank you for your time.
Best Regards,
Darius




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20171121/6f3e8319/attachment.html>