I’d like to preface this by saying this post is a mile wide and an inch deep when it comes to reverse engineering on the Android platform. However, for those who are new to mobile and looking to get a quick test environment set up, this post is for you. We’ll assume you have a rough idea of what an APK file is and at least a superficial understanding of Android itself.
In order to get started, we’re going to need two things: a virtual instance of 32 bit CentOS and the Android emulator. In addition to these two things, your mobile lab should include tools for static and dynamic analysis such as Burp Suite (free edition works fine), smali, JD-GUI, and dex2jar, but we’ll only touch on those things briefly for the time being. Once you have your CentOS base install done, go ahead and grab the Android SDK (which includes the emulator) from Google’s official site. After you’ve downloaded the zip file, no installation is required; simply unzip and change into the SDK directory to get started.*
*When you launch the emulator for the first time, you may receive an error about libgl.so.1. To fix this, as root, simply run “yum -y install mesa-libGL-devel” and restart the emulator.
Now that you have the SDK installed, the next thing to do is create a virtual disk used by the emulator. To do this, navigate to ../adt-bundle-linux-x86-20130522/sdk/tools and run the below command:
[root@localhost tools]# ./android create avd -n <imageName> -t 1 Auto-selecting single ABI armeabi-v7a Android 4.2.2 is a basic Android platform. Do you wish to create a custom hardware profile [no] Created AVD 'asdasd' based on Android 4.2.2, ARM (armeabi-v7a) processor, with the following hardware config: hw.lcd.density=240 vm.heapSize=48 hw.ramSize=512
You can use the android command to customize options such as the amount of RAM you give to the virtual device, but for the sake of getting things up and running, the default value of 512M should be just fine.
The next step is to boot our virtual disk and sideload an app which we will do with the below commands:
To boot the device, cd to ../adt-bundle-linux-x86-20130522/sdk/tools and simply run ./emulator <imageName> where <imageName> is the name of the virtual disk we created before. After a minute or two, the device should boot and you should be looking at something like the below.
If you see a lock screen when it boots, it behaves the exact same way the Android lock screen does on a physical device. Simply click the lock and drag away to unlock.
Now that we have the device up and running, we can sideload an app to do some dynamic analysis. If you’re not familiar with the term “sideload” and you don’t have the strength to click the Wikipedia link, it basically means we’re going to install it but not do so through the Android store. To sideload an app for your emulated device, use the adb command which can be found in /adt-bundle-linux-x86-20130522/sdk/platform-tools. With your device running, run “adb install filename.apk” to install the application as seen below.
[root@localhost platform-tools]# ./adb install testfile.apk * daemon not running. starting it now on port 5037 * * daemon started successfully * 1167 KB/s (59290 bytes in 0.049s) pkg: /data/local/tmp/testfile.apk Success [root@localhost platform-tools]#
One thing to note when installing APK files is the file names themselves. If the APK you downloaded or are going to install contains special characters such as forward/backslashes or spaces, rename it prior to installation as this can cause issues with the installation process.
Lastly, now that we have our app installed, virtual disk created, and everything is up and running, restart the virtual disk using the -http-proxy command. Start up Burp Suite and make sure that you have a local listener on 127.0.0.1. Once Burp is up and running, start the emulator with:
[root@localhost platform-tools]# ./emulator @fooblah -http-proxy 127.0.0.1:8080
After booting, launch your app and with any luck, Burp will be able to successfully intercept and modify HTTP requests for your application (assuming of course it’s using vanilla HTTP with no certificate pinning and other fancy tricks).
It’s far from a complete overview of reverse engineering mobile applications, but with any luck, and the tools mentioned at the start of the post, you’ll have the info you need to get started on more serious tasks.