As digital information becomes more valuable, companies are spending a lot of money to secure their data.
Protecting mobile applications becomes even more crucial since apps have been created to do almost every thing, from booking a cab to buying a house.
The goal of this article is to walk you through the very first step in the process of hacking a mobile application, understanding the internal structure of a mobile app by reverse engineering its
Android application package
Before we can jump into reversing an
apk, we should understand how an Android app is built and the anatomy of an Android app.
The process of generating an
apk is pretty much straight forward, it can be sum up nicely in the following diagram:
Result of the above process is a zip file with
When you unzip it, you can find the following files and directories:
|Directory||Content & Description|
||a binary file describing the name, version, access rights, referenced libraries… it can be converted into readable plaintext XML with tools such as AXMLPrinter2, apktool, or androguard|
||contains the manifest file
||contains applications assets, which can be retrieved by AssetManager|
||compiled classes in the dex file format understandable by the
||contains compiled native shared library for different CPU architecture:
||contains resources not compiled into
||contains precompiled resources, such as binary XML for layouts, styles…|
Obtaining the target
There are a few ways to obtain the target application
- Using Android Debug Bridge (a.k.a
- Back up
apkto MicroSD card using one of the following applications:
- Downloading from Google Play using a third party service:
Application general information
We can easily obtain general information after having the APK by using a tool called
aapt which is bundled inside Android SDK
Output will contain some helpful information like package name, version name, version code…
Reversing the target
Configuration & resource files
First, we will use apktool to de-obfuscate the
apk to obtain readable
AndroidManifest.xml, assets and resource XML files.
It will also produce a list of machine readble
smali files, together with original application certificate and resources hash (kept in
If the target application makes use of shared native libraries, there will be a folder called
lib containing all
*.so artifacts for different CPU architecture.
From here, we can pretty much know about the application layout structure, configuration for receivers as well as content provider if there is any.
Java source codes
To learn more about the application logic, we need to know the Java part of it. Hence, we use
dex2jar to convert the previous obtained
classes.dex file, which is in
Dalvik bytecode format, to
Java bytecode format.
If the application is a multidex application, we need to put together all
classes.dex files for the decompiler in order to parse properly.
jd-gui or any Java decompiler tools, you then can view the readable Java source files.