We are very happy to announce a new tool in our toolchain: CodeInspect – A Jimple-based Reverse-Engineering framework for Android and Java applications.

Developing an Android application in an IDE is very convenient since features like code completion, “Open Declaration“, renaming variables, searching files etc. help the developer a lot. Especially code-debugging is a very important feature in IDEs. Usually, all those features are available for the source code and not for the bytecode, since they support the developer not a reverse-engineer. Well, but all those features would be be also very helpful for reverse-engineering Android or Java applications. This is the reason why we came up with a new reverse-engineering framework that works on the intermediate representation Jimple and supports all the features above and a lot more. In the following we give a detailed description about CodeInspect and its features.

CodeInspect supports as input format a complete Android Application Package (apk), just the Android bytecode (dex-file) or a jar-file. In the following we will describe the different features based on a malicious Android apk.

 

Framework Overview

The figure above is a screenshot of CodeInspect. As one can see, CodeInspect is based on the Eclipse RCP framework. One can define a workspace with different projects (apks). Furthermore, CodeInspect contains different perspectives, different views and a new editor for the intermediate representation. The main perspectives are the “CodeInspect” perspective as shown in the screenshot and the “Debug” perspective which is known from the general Eclipse IDE including views for “Expressions”, “Breakpoints” and “Variables”. Other basic views in the CodeInspect perspective are:

• Project Explorer: It shows all the important files in a readable format of an apk
• Outline: Shows all the fields and methods of a specific class. By clicking on an item, one directly jumps to the corresponding line in code.
• Console: Shows the console output.
• Problems: Shows all the warning and errors (e.g., compilation errors) that occur in the project.

 

Importing the Bytecode

Importing a complete apk is done with a few clicks. One just has to provide the path to the Android-SDK and the Android bytecode is converted into the human readable intermediate representation – Jimple (more information in the next section). All other files, stored in the apk, will be extracted. The following video shows the complete import process:

 

 

Bytecode-Intermediate-Represenation

Reading the bytecode of an application is most of the time not convenient for a reverse-engineer. Reading the source code is much more convenient. Unfortunately, decompiling the bytecode into source code is most of the time NOT 100% possible. Therefore, we use an intermediate representation called Jimple (“Java but simple”), which comes together with the static analysis framework Soot. The framework and the intermediate representation have existed for over 10 years now and Soot has an active community. The Jimple intermediate representation is, as the acronym hints, a “java-based” representation of the bytecode that is very easy to read. For further information on Jimple or Soot, we refer the reader to the following sources:

• https://github.com/Sable/soot
• https://github.com/Sable/soot/wiki
• http://sable.github.io/soot/
• Instrumenting Android and Java Applications as Easy as abc

 

General IDE Support

Features like code refactoring (e.g., renaming variables or methods), jumping to the declaration of a variable with a single click or debugging the application is useful during the development process. But on the other side, those features are also very useful for manual reverse-engineering the bytecode, which is most of the time very time consuming. There is always a trade-off between time and money one wants to invest when reverse-engineering applications. The following video shows an excerpt of the general IDE features of CodeInspect:

 

Debugging

One of our main features in CodeInspect is the debug functionality. With the help of CodeInspect, one is able to debug the intermediate representation (Jimple) of the applications. Just imagine debugging the source code of an Android application in Eclipse, where in our case you are able to directly debug the bytecode which is represented in a human readable intermediate represenation!

CodeInspect supports all Android versions, including Android versions compiled to ART. Furthermore, debugging works as you would expect it from debugging the source code:

• set some breakpoints
• choose any Android device you want (NO emulator modification necessary!)
• click on “debug”

and the compiled Application gets debugged. In the following we show a video where CodeInspect uses its debugging feature:

 

 

Code Modification

During reverse engineering applications, it is always very convenient to modify the original (potentially malicious/obfuscated) code. In the following we describe standard Jimple code-modifications, advanced Java-based modifications and Manifest-modifications.

Standard Jimple-Modification

We regard to a standard Jimple-modification in cases where the Jimple code gets modified either by removing Jimple statements, modifying them, or by adding new Jimple statements. This can be useful for removing emulator checks in the code or “simulating” server responses by changing a

String a = InputStream.readLine();

to

String a = “#m1234:My Text”;  

Adding new statements will be supported by a code-completion feature.

Advanced Java-Based Modification

There are cases where a simple Jimple modification is not sufficient enough or takes too long. Therefore, we added a feature where one can add Java source-code or even Java projects to the original compiled apk. This means one can enhance the bytecode by adding Java source code which gets then compiled into the original apk.

Manifest Modifications

Especially advanced modification could result in a modification of the Android manifest, e.g. by adding new code that requires a new permission. Well, but also simpler modifications such as changing the “exported“-flag from false to true is very important for a further component-fuzzing for instance.

 

How and when can I use it?

CodeInspect is currently in an alpha-testing-phase and we will provide more information on our blog as soon as possible.

Involved in this project are…

Marc Miltenberger, Steven Arzt, Stephan Huber, Siegfried Rasthofer and Eric Bodden

More information…

If you find this project interesting and want more concrete information, just contact me.