Android applications are bundled and distributed as apk(s), aka Android application package.To make an APK file, a program for Android is first compiled, and then all of its parts are packaged into one file. An APK file contains all of that program’s code (such as .dex files), resources, assets, certificates, and manifest file. As is the case with many file formats, APK files can have any name needed, provided that the file name ends in “.apk”.
An APK file is an archive that usually contains the following files and directories:
Signature-Version: 1.0 Created-By: 1.0 (Android) SHA1-Digest-Manifest: wxqnEAI0UA5nO5QJ8CGMwjkGGWE= ... Name: res/layout/exchange_component_back_bottom.xml SHA1-Digest: eACjMjESj7Zkf0cBFTZ0nqWrt7w= ... Name: res/drawable-hdpi/icon.png SHA1-Digest: DGEqylP8W0n0iV/ZzBx3MW0WGCA=
lib: the directory containing the compiled code that is specific to a software layer of a processor, the directory is split into more directories within it:
armeabi: compiled code for all ARM based processors only
armeabi-v7a: compiled code for all ARMv7 and above based processors only
arm64-v8a: compiled code for all ARMv8 arm64 and above based processors only
x86: compiled code for x86 processors only
x86_64: compiled code for x86 64 processors only
mips: compiled code for MIPS processors only
res: the directory containing resources not compiled into resources.arsc (see below).
assets: a directory containing applications assets, which can be retrieved by
AndroidManifest.xml: An additional Android manifest file, describing the name, version, access rights, referenced library files for the application. This file may be in Android binary XML that can be converted into human-readable plaintext XML with tools such as AXMLPrinter2, android-apktool, or Androguard.
classes.dex: The classes compiled in the dex file format understandable by the Dalvik virtual machine
resources.arsc: a file containing precompiled resources, such as binary XML for example.
Our prerequisite would be these 3 tools:
dex2jar: Used to convert the apk to jar file. Can be downloaded from here.
JD-GUI: Used to view the contents/source from the jar file decompiled in previous step. Details are here.
apktool: For reverse engineering the apk to extract files and folders. This can be used to extract the manifest individually and then reading from it. It is available here for download.
dex2jar and JD-GUI are used together. dex2jar converts apk to jar file and JD-GUI provides the editor to browse that jar file. To use dex2jar:
- Download dex2jar from here and extract it to a separate folder.
- Execute the following command to decompile an apk:
sh d2j-dex2jar.sh testapp.apk
- It might happen that terminal might show you a permissions error related to d2j_invoke.sh while executing step 2, if that happens then provide d2j_invoke.sh with appropriate permissions by executing:
sudo chmod +x d2j_invoke.sh
- Post above steps, testapp.jar should be generated which can be opened and browsed via JD-GUI. This file contains all the decompiled code(.class files)
We are already able to browse the source code using dex2jar and JD-GUI, however, another important tool in the arsenal is apktool, which is a tool for reverse engineering 3rd party, closed, binary Android apps. It can decode resources to nearly original form and rebuild them after making some modifications. It also makes working with an app easier because of the project like file structure and automation of some repetitive tasks like building apk, etc. Apps/Apks. Decoding of an apk via apktool can be done by using following command:
apktool d test.apk
Repackaging as an apk can be done by:
apktool b test
JD-GUI, d2j and apktool is the essential tooling required to get an effective and deep insight into 3rd party apps which often exist as black boxes. As shown above, the usage is simple and pretty straight forward. I would request you to share your inputs and experiences in comments with these tools or any others that you might have explored for decoding Android or any other platform apps.