Instrumenting Android Apps with Soot

Eric | January 8, 2013

I am excited to let you know that we have recently committed to the development Branch of Soot support for reading and writing Dalvik bytecode with Soot. (This code will also be contained in Soot’s upcoming release.) This supports consists of two major modules. One is called Dexpler, mainly developed by a group around Alexandre Bartel, and with some enhancements by Ben Bellamy and myself as well as Frank Hartmann and Michael Markert, two students of mine. Dexpler converts Dalvik bytecode into Jimple’s three-address code. This may sound simple – after all Dalvik code is register based and Jimple uses local variables which are quite similar to logical registers. However, things get tricky with respect to typing. Jimple is typed; every local variable is of some declared type. In Dalvik, registers are untyped, and during the execution of a method the same register can hold values of quite different types. Constants in Dalvik are also untyped: when loading a double or a long into a register, Dalvik just loads an eight-byte bit-pattern into the register without telling you whether it’s a long or double. But in Jimple we need this information. Thus getting the typing of Jimple locals right is quite tricky and took us a while. On the other hand, typed locals are great, as they allow for a simpler and more precise pointer analysis, among other things. Read the rest of this entry »

Comments
Comments Off on Instrumenting Android Apps with Soot
Categories
Research
Tags
Soot Tutorial

Using Soot with custom entry points

Eric | July 26, 2012

When doing whole-program analysis with Soot, you will need to tell Soot what the entry points to your program are. Soot has always supported an option of custom entry points, which comes in handy when analyzing libraries, applets or apps that do not have a “main method”. However, as it turns out there was quite some confusion as to how to use the “custom entry points” feature. Admitted, it is more tricky than it maybe should be. This blog post is meant to clarify some of those issues. The following code shows you how to set a method MyEntryPoint.myMethod as entry point.

Options.v().parse(args);
SootClass c = Scene.v().forceResolve("MyEntryPoint", SootClass.BODIES);
c.setApplicationClass();
Scene.v().loadNecessaryClasses();
SootMethod method = c.getMethodByName("myMethod");
List entryPoints = new ArrayList();
entryPoints.add(method);
Scene.v().setEntryPoints(entryPoints);
PackManager.v().runPacks();

Usually we recommend users to just call Soot’s very own main method after setting up the initial configuration. Note that in this particular case this is not recommended. The problem is that the above code is loading classes, which conflicts with the standard class-loading process that Soot’s main method implements. Instead above we call runPacks which will run all of Soot’s packs in the usual order. At the beginning of the above code, we call parse to parse the command-line arguments given to your driver class, forwarding those to Soot (as usual).

Thanks to Yi Lin, Marc-André Laverdière-Papineau, Phil Pratt-Szeliga and for helping me figure out how to get this work best.

Comments
Comments Off on Using Soot with custom entry points
Categories
Research
Tags
Soot Tutorial

Whole-program analysis, but without the JDK (using Soot)

Eric | June 4, 2010

In the past many people have asked how they can configure Soot so that it would analyze a given set of classes, but without analyzing all the internals of the JDK. Of course, such an analysis is generally unsound, but often people don’t really care – they just want to have fast results. I have often found myself in the same situation when testing whole-program analyses that I wrote myself. Every analysis run would normally take minutes to run, which can cause your day to pass by quickly when you are debugging a complicated analysis.

Today I added a new option to Soot: -no-bodies-for-excluded. This option causes Soot to not load any method bodies of classes from the “exclude” packages (see –exclude option), even in whole-program mode, unless the class is explicitly as a “basic class”. -no-bodies-for-excluded implies -allow-phantom-refs, as it uses the phantom-refs mechanism to model classes that are not loaded.

All changes have been committed to SVN. This feature is still experimental, but it appears to work for me – I am now able to run all of Clara‘s tests in seconds each instead of minutes each, just because they now ignore JDK classes.

Comments
Comments Off on Whole-program analysis, but without the JDK (using Soot)
Categories
Research
Tags
Java, Soot, Soot Tutorial

Using Soot and TamiFlex to analyze DaCapo

Eric | March 29, 2010

In this tutorial, I describe how to use TamiFlex to facilitate the static analysis of the DaCapo benchmarks with Soot. You can also find this tutorial on the TamiFlex website.

Also feel free to use our scripts for this purpose. You can also find many details in our Technical Report.

Step 0: Downloading the necessary components

To analyze DaCapo benchmarks with Soot, first download the following:

Read the rest of this entry »

Comments
Comments Off on Using Soot and TamiFlex to analyze DaCapo
Categories
Research
Tags
Soot, Soot Tutorial, TamiFlex

Packs and phases in Soot

Eric | November 26, 2008

This the fourth post in a series of blog posts about frequently asked questions with using Soot. Today’s topic will be on packs and phases in Soot.

One frequent question that comes up on the Soot mailing list is when to run a particular analysis in Soot. Soot’s execution is divided in a set of different packs and each pack contains different phases. Therefore the question could be rephrased as “In which pack do I have to run my analysis or transformation?”. This tutorial tries to help you answer this question.

Read the rest of this entry »

Comments
Comments Off on Packs and phases in Soot
Categories
Research
Tags
LinkedIn, Soot, Soot Tutorial

Implementing an intra-procedural data-flow analysis in Soot

Eric | September 22, 2008

After my last tutorials on using Soot on the command line, and using the Soot Eclipse plugin, this is the third of a series of blog posts about frequently asked questions with using Soot. Today’s topic will be on extending Soot with your own intra-procedural data-flow analysis.

Read the rest of this entry »

Comments
Comments Off on Implementing an intra-procedural data-flow analysis in Soot
Categories
Research
Tags
Data-flow analysis, Eclipse, LinkedIn, Soot, Soot Tutorial

Using the Soot Eclipse plugin

Eric | August 30, 2008

After my last tutorial on using Soot on the command line, this is the second of a series of blog posts about frequently asked questions with using Soot. Today’s topic will be on Soot’s eclipse plugin.

Read the rest of this entry »

Comments
Comments Off on Using the Soot Eclipse plugin
Categories
Research
Tags
Eclipse, Plugin, Soot, Soot Tutorial

First steps using Soot 2.3.0 as a command-line tool

Eric | August 21, 2008

This is the first of what will be a series of blog posts about frequently asked questions with using Soot. I will try to cover different topics like using Soot from the command line, as a framework and in form of its Eclipse plug-in. This is basically a user-friendly digested version of all the fabulous Soot tutorials that we have online already. Today’s topic will be on Soot’s command line and phase options.

Read the rest of this entry »

Comments
Comments Off on First steps using Soot 2.3.0 as a command-line tool
Categories
Research
Tags
Soot, Soot Tutorial