First blog post in a long time, so I figured I should start back off with something I’ve been getting a lot of questions about lately, which is how to get started with learning more about Android application security.
I think the absolute best way to understand what’s going on is to start looking at real world applications. This tutorial will show you how to download an Android application and convert it back into a format that we prefer, which is its original Java code. Hopefully this will be the first tutorial of many, so be sure to check back from time to time.
I hope this post can be of use to developers as well, in order to better understand that the code they allow to be distributed on mobile devices can easily be decompiled. If you are storing hardcoded credentials or reference other things you don’t want the user (or bad guys) to know about, you should re-evaluate that design choice.
My disclaimer is that this should not be used for malicious purposes, etc etc and all of the other stuff no one will likely listen to.
To get started, you will need these applications on your box:
The first step is to download the Android SDK (Software Development Kit). You will rely on this heavily when testing applications and interacting with Android devices. There are many useful utilities bundled with it including Android Debug Bridge (ADB) and the emulator.
The next step is to download an interesting application to rip open. Most of us are Twitter fans, so why don’t we take a look at the Twitter application for Android?
At this point, you have 2 choices:
-Download it to your physical Android device
-Download it to a virtual device running in the Android emulator
By default, the virtual devices available using the emulator that comes with the Android SDK do not have the Google Market application installed. You can either 1) spend time finding ways around this or 2) install an image that has the software pre-loaded. Here is an excellent tutorial on how to go that route, although you may want to use a more up to date image than the ones referenced. They use older versions of Android.
Assuming you have either plugged your phone in or started an Android virtual machine, in the tools folder of the Android SDK folder, you’ll find several utilities incuding ADB. I recommend familiarizing yourself with it, as you will use it almost constantly if you are working with the Android platform.
ADB allows us to do many things including connect to the device and have shell access. We first need to figure out where the application we downloaded is stored. Under the /data/app/ directory, we will find all of the APK files for applications we’ve downloaded. Under /system/app is all of the applications included with your Android distribution. For this tutorial, we are concerned with /data/app as this is where our Twitter application will be located.
Now that we know what we want to download, we need to transfer the file to our local system for further analysis. This can be achieved also by using ADB.
We will not be using the shell this time, but rather the “pull” command which allows us to select and retrieve files from the Android device. The general format for this command is: adb pull apk_file destination_directory
Now that we have the APK file, we’ll need to unzip it. The APK is simply in standard ZIP format, so any of your existing ZIP compatible utilities will work.
After unzipping the APK file, there are two things you should be primarily concerned with at this point: looking at the manifest file, and getting the .DEX file into a more desirable format to work with. The manifest contains juicy information like permissions, intent filters, and lots more. If you aren’t familiar with the manifest file and how its used with Android applications, I highly recommend reading the documentation on the Android development site:
If you try to open the AndroidManifest.xml file that was just unzipped, you’ll find that it isn’t in plain text. We’ll use apktool at this point to convert it into a format we are comfortable with. We’ll use apktool to decode the entire APK, and then the manifest file should be much easier on the eyes:
After running apktool, this is what the AndroidManifest.xml file should look like when viewed in a text editor or Eclipse:
The classes.dex file in the originally unzipped APK file is the crown jewel here. It contains all of the application’s code, but in the Dalvik Executable format.
There are tools such as dedexer and apktool that will convert .DEX into smali assembly format, but again we are concerned with looking at the Java code. We can use dex2jar to achieve this:
Once we’ve run dex2jar, there will be a classes.dex.dex2jar.jar file in the folder where the original .DEX file was located. Simply unzip this JAR file. Upon unzipping it, we see a bunch of .class files.
Nothing to worry about, this is familiar territory at this point. Simply use your favorite Java decompiler to convert from bytecode to easily readable code.
We now have complete access to the entire client application. In the tutorials to come, I’ll show you some things you should be paying close attention to when reviewing or designing an Android application.