AndroidProjectCreator – The ‘how’ and ‘why’

Preferably, when reversing malware, one only has to open the APK with the preferred tool in order to see the decompiled code. After that, it is up to the analyst to digest the inner workings of the malicious sample. This is possible with proprietary tooling that costs quite some money.

During my job as an Android malware analyst, I had tooling which was able to simply open the APK and allowed me to refactor names, add comments and execute scripts. This resulted in an efficient analysis of the malicious sample. Since I quit my job and moved on to graduate, I do not have access to these tools anymore. As such, I was on the lookout to find something similar which was within my budget. Alas, my search yielded no results.

Although JAD-X has the option to export the content of an APK as an Android Studio project, it does not always succeed in decompiling all classes. The other tools that I tested, which were JD-CMD (part of JD-GUI ) and Fernflower , did not manage to correctly decompile all code either. These tools generally failed on different classes, resulting in the possibility to use multiple decompilers to obtain the correct decompilation for every class in the APK. Besides convenience, this was the reason for me to include multiple decompilers in this project.

For those wondering, I am leaving the names of these programs out of this article on purpose, as I do not want to imply any wrongdoing of these companies. My sole purpose with AndroidProjectCreator is to create a tool which provides an alternative for those who analyse APKs in their spare time or for school assignments. Obviously, companies are free to use it as well. For all users, the usage should be allowed according to the terms that are provided in the GNU GPL v3 license.

A proof-of-concept

Before creating the AndroidProjectCreator, I was unable to efficiently analyse Android malware due to limitations by the programs I used. On Windows, I used Notepad++ to Search in files for the name of something I wanted to replace. The problem with this, is the fact that within packages there are duplicate names of classes, methods and fields. By using the Search in files functionality, I had to manually select all the entries which I wanted to refactor. This resulted in a slow analysis with a lot of mistakes. Additionally, there was no undo functionality since multiple files were altered at once. A mistake was therefore permanent, so manually creating back-ups of the folder(s) I was working in, was required.

As an example, the code below has multiple methods and fields that have the same name. Using a single search and replace, would replace too much methods with the desired name. Essentially, this would make the code even more unreadable than the minified and/or obfuscated code already is after decompilation.

public class A {
 
    public int a;
    public int b;
 
    public int a() {
        return b;
    }
 
    public int b() {
        return a;
    }
}
 
public class B {
 
    public int a;
    public int b;
 
    public int a() {
        return b;
    }
 
    public int b() {
        return a;
    }
}

A tool which is often used to decompile Android applications, is JAD-X. The GUI version provides an overview of the application and shows the decompiled Java code. It does not allow the user to refactor, add comments or execute scripts. One can (using the CLI or the GUI) export the decompiled Java code. This code can then be used by another tool. JD-CMD (which is used in JD-GUI) and Fernflower can also do this, when they are used in combination with APKTool and Dex2Jar. First, the APK is decoded using APKTool, after which the classes.dex file is converted into a Java Archive (JAR). This JAR is then decompiled to Java code.

The goal

My search for a free (and preferably open-source) tool which would allow me to refactor code, add comments and execute scripts at my command seemed like a hard one at first. If one were to leave out the fact that this is decompiled code, the simplest solution would be to pick an IDE and use that. So I went with that option, since most IDEs allow refactoring of code, the addition of comments and the execution of scripts. All in all, IDEs are advanced programs which make the life of a programmer easier. Even though reverse engineering is a different form of programming, it still is applicable.

Since this is code for an Android application, it is logical to use Android Studio. Using the decompiled code, I created an Android Studio project. Alas, this gave me a handful of errors. Firstly, the manifest could not be found. Secondly, the resources could not be found. Both errors resulted early in the Gradle build, which limited the functionality of the IDE in such a way, that refactoring code became disabled.

Fixing the errors

To fix these errors, I used APKTool’s decoded AndroidManifest and the decoded resources. By placing those two in the correct place within the Android Studio project, the Gradle build partially succeeded. A complete successful build is nearly always impossible, since the decompiled code contains elements that are not accepted by the compiler. An example of this would be the jumps and labels that are used, which are not reckognised by the compiler, thus resulting in an error. The build only needs to succeed to the point where the IDE can refactor code and execute scripts. The partially succeeding Gradle build tasks did allow refactoring code. Adding comments was possible all along and scripts can be executed. The proof-of-concept was successfully completed!

AndroidProjectCreator

The proof-of-concept paved the way for an automated version. Within the automated version, multiple different tools could be included. In the coming release, the aforementioned tools (JD-CMD, JD-GUI, JAD-X, Fernflower, APKTool and Dex2Jar) are included. An empty Android Studio project is also included as a template. In the future, more tools will be included.

The installation

The installation feature requires no user interference, as long as the correct prerequisites have been installed: Java 8 JRE, JDK and Maven. Do not forget to set the JAVA_HOME environment variable! The additional programs are stored in a single folder with a sub folder for each program. The folder named Library is used to store the programs in and resides in the same directory as the AndroidProjectCreator JAR.

In the background, the Git repositories of all tools are cloned in a sub directory of the Library , named repos . The building process of each tool is started as a separate process on the machine. The output of these processes is shown to the user in the command line interface. After all tools have been built, the compiled versions of the tools are copied to the correct subfolder within the Library folder. The repositories are then deleted. From that step onwards, AndroidProjectCreator can be used without an internet connection. The reason to clone the Git repositories is to ensure the latest stable version of each tool is used. The branch that is used is selected on this.

The application flow

Upon providing the correct parameters, the decompilation and assembly of the Android Studio project is started. The APK is first decoded using APKTool. This provides three objects that are used in later steps. Firstly, the manifest file, which is used in the template project. Secondly, the resources folder, which is also used in the template project. Lastly, the classes.dex file is given. The classes.dex file is then converted to a JAR using Dex2Jar. The Java code that is derived from the JAR using a decompiler is also used in the template project. Note that for none of the tools, parameters have to be provided as these are all stored within the AndroidProjectCreator.

After all the tools have finished, the template project is extracted and filled with the required data in a temporary directory named temp within the Library folder. The Android Studio project is then copied to the provided output directory, as specified by the user. At last, the temporary folder temp is deleted.

Android Studio

Using Android Studio, one can receive multiple errors or warnings, which should all be solvable using the help of the IDE. One that is commonly encountered is a mismatch of the build-tools . This can be solved by simply allowing Android Studio to download the correct toolset.

Conclusion

To conclude, AndroidProjectCreator provides a simple and free way to get started with the analysis of an APK. Using any of the given decompilers, a user can easily see which of the tools provide the output that is required. A combination of the output of these different decompilers can also be used since the variable names are derived from the SMALI code (intermediate language). This means that a class that was decompiled using decompiler A can be used in a project which was decompiled using decompiler B, since the variable names are the same. This is only true for projects which have not yet been refactored at all.

All in all, AndroidProjectCreator provides an enhanced and automated experience of multiple tools in a single bundle. Using the command line interface, it can be further automated in other projects or it can be set as an environment variable on the system, which would allow the user to call the AndroidProjectCreator JAR from anywhere on the system.

To contact me, you can e-mail me at [info][at][maxkersten][dot][nl], send me a PM on Reddit or DM me on Twitter @LibraAnalysis .