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

Darius d.sas at campus.unimib.it
Tue Nov 21 11:16:16 EST 2017


Hi Steven,

I have attached the stack trace of the execution while using soot.jimple.toolkits.ide.icfg.JimpleBasedInterproceduralCFG.

Thank you for the additional info!!

Best Regards,
Darius

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

Hi Darius,

Please send me the stack trace so that I can have a look. Maybe it is a bug, let’s see.

If you are interested in a data flow analysis, FlowDroid (which is essentially soot-infoflow plus some additions that you don’t necessarily need if you are dealing with pure Java) is a good starting point. Over time, FlowDroid´has evolved from a pure data flow solver that looks for privacy violations into a framework for conducting all sorts of data flow analyses. It offers a lot of interfaces that you can use to plug in your own semantics or change the pre-defined logic.

By the way: In FlowDroid, we don’t use Heros anymore, we have our own specialized IFDS solver, which is a lot faster and requires a lot less memory. On the other hand, this customized solver is geared towards the FlowDroid model of flow functions being the main consumer of data flow abstractions, i.e., with the custom solver, you can’t enumerate all abstractions and query them in the end. Instead, the flow functions directly check for the properties of interest (such as sinks being reached) while the data flow analysis is still running.

Best regards,
  Steven 

Von: Darius [mailto:d.sas at campus.unimib.it] 
Gesendet: Dienstag, 21. November 2017 11:41
An: Arzt, Steven <steven.arzt at sit.fraunhofer.de>; soot-list at CS.McGill.CA
Betreff: R: [Soot-list] Inter-procedural info-flow analysis for Javalibraries

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/6a5d2bff/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stacktrace.txt
URL: <https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20171121/6a5d2bff/attachment-0001.txt>


More information about the Soot-list mailing list