[TUTORIAL] Reversing Android Apps

After looking at the post of our Admin, about the Android, i thought of publishing this one...! This topic was shared in DEFCON conference which was held in Chennai on 11th Sep 2011...!

So, Lets dig up some important points here again...


Android puts the user in control of everything. The Android Security model is based on the fact that each application is to be run within its own DVM, which acts as a sandbox between two applications. So that, even if one of the application crashes, it won't affect the other application or the phone. This makes sure that the two applications are independent of each other; also the data of one application cannot be accessed by another application without sufficient permissions.
Dalvik Virtual Machine was created by Dan Borstein, specifically for the android platform, so that applications could run smoothly under low power processors with graphics and hardware acceleration suitable for the mobile device.

The DVM is register based instead of the standard Stack Based JVM (Java Virtual Machine). Due to this, java files of the android applications, are compiled to a Dalvik byte codes or dex (Dalvik Executables) before being packaged into the apk.

Also, if there are more than one java files, all are compiled into a single dex file to save space and memory.
When installed, each application is assigned a unique UID and GID, just like what is there in the Linux file system. Each app's UID has to be different from another application. Also, applications from a single developer could share the same UID, so that it is easy to push updates for the application, without having the user to uninstall the old version and install the new one.

REVERSE ENGINEERING

Reverse Engineering is a process in which we decompile an application to understand its working and functionality better, by analyzing the codes and debugging it.
The reverse engineer of an Android Application, is not much different from the reverse engineering of computer software.
Before reversing, let’s understand, how an APK is made


Now, in real world scenario, we have the apk file in our phone. So, first of all we would be depackaging it, using any standard, unzip file, such as Winrar or 7-zip.

If we're on Linux, a standard command “unzip app2test.apk” would be uncompressing the apk to get the following files and folders.

Quote :

1. Meta-Inf
2. Res
3. classes.dex
4. AndroidManifest.xml
5. Resources.arsc

At this point of time, our main point of concern would be the classes.dex file, which is the compiled java classes and contains all the codes of the things to be performed by the application.

So, our main aim would be to somehow decompile the classes.dex file into human readable codes.
There are two ways we can proceed now. The first one being, converting the classes.dex into smali format, which is similar to java file format and the other method, is to decompile it to JAR file and then opening it using a jar decompiler such as JD-GUI.



Smali is a file format having a structure similar to Jasmine.

We can convert classes.dex to smali formats using a tool name as Baksmali.

Or we can use another tool name as APKTool made by __ which is an overall tool, which could be used to both decompile and compile an android application.

Lets in our case, use APKTool, as it contains the feature of converting the classes.dex file to Smali format codes, along with some other nice features.

According to Brut.all, the creator of APKTool, it is a tool to reengineer closed binary android apps. It also makes us easier to analyse/debug the smali codes step by step and read the AndroidManifest.xml file.

apktool d Settings.apk

Here the d stands for decoding in debug mode.

r00t@hax0r:~$ apktool d Malware.apk

I: Baksmaling...

I: Loading resource table...

I: Loaded.

I: Loading resource table from file: /home/r00t/apktool/framework/1.apk

I: Loaded.

I: Decoding file-resources...

I: Decoding values*/* XMLs...

I: Done.

I: Copying assets and libs...


We just decompiled an APK into readable smali format for debugging
The debugged files and folders would be saved to a folder named as the name of the apk, in this case, in a folder named “Malware”
If you wish to save it in a desired folder, use

r00t@hax0r:~$ apktool d Malware.apk Outputfolder/

The decompiled smali files would be saved to a folder named as “Smali” .

The whole list of commands can be brought up by apktool. After we've made necessary modifications with the apk, If we have to recompile the apk, we would be using the build functionality of apktool

r00t@hax0r:~$ sudo apktool b Malware/

The newly generated apk would be located in a folder named as “build”.



Apart from converting to smali format and analysing the codes, we could also convert the classes.dex file to the original java classes. However the point to note here is that, by converting to java classes, we would be having a little bit modified code and in some cases, we may even not be getting some of the parts of the codes.

The first step in converting the file to java format is to first convert it to JAR file. To do this, we have a wonderful free utility named as Dex2Jar.

First of all, we need to have the classes.dex file of the apk. To get it, just extract the apk.

r00t@hax0r:~$ unzip malware.apk

The extracted files would be having our required classes.dex file.

Also, in some of the cases, the AndroidManifest.xml file upon extracting won't be readable. In that case, you could use the aapt tool present in the Android SDK.

r00t@hax0r:~$ aapt xmltree d AndroidManifest.xml malware.apk

To convert to Java, first we have to convert it to JAR format using Dex2jar.

From the JAR file, we could get the original java files using a tool named as JD-GUI.

r00t@hax0r:~/dex2jar$ ./dex2jar.sh

Before using the above command, you've to set the class path if you're using Linux.

If you're on windows, you can use the command directly. Like,

dex2jar.bat classes.dex

[You must be registered and logged in to see this image.]

After conversion, you'll be having a jar file named as classes_dex2jar.jar

Now, the final step is to convert the jar file to readable java file format.

To do this, you can use a Java decompiler such as JD-GUI.

Just opening the jar file in the JD-GUI, we would be having the java readable code with us.

[You must be registered and logged in to see this image.]

We would be having a screen like the above with the java codes. Using JD-GUI, we could also save all the files and modify it later, and then recompile it to make a modified application. This is how most of the mobile malwares for this platform are made, by inserting the malicious codes into the legitimate app and then repackaging it to make a new APK looking exactly similar to the original one.

Analysing the java/smali files could also be useful from a penetration testing point of view. However mobile application penetration testing consists of lot more things than just analysing the codes. One also needs to capture the network data, and then see if, any information is being sent by an application to a remote server of the attacker. Also, one need to trace the system calls and the changes made to the Dalvik Virtual Machine, after installing the application on it.
Just opening the jar file in the JD-GUI, we would be having the java readable code with us.


CREDITS:
Aditya Gupta is a Cyber Security Consultant and Ethical Hacker. He loves researching on Web Application Security and Android Malwares. He also gives workshops and talks on Cyber and Mobile Security.

I think this was helpful...!