Prof. Dr. Eric Bodden

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 »

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.