Android Hacking- Part 2
Build Process, Compilation, APK Structure, Components, Signing and more.
Understanding how Android Applications are compiled and structured will help us understand the process better.
Android App building = Compilation + Packaging + Signing.
Here are the compilation steps and diagram showing the process:
(Android Asset Packaging Tool) aapt ->
.aidl+ app source code
Java Compiler ->
Jarsigner -> signed
zipalign -> signed and aligned
Compilation process | Source: MASPT Caendra
APK (Android Package) Structure
apk file can be renamed with a
zip extension to decompress and look at its contents. Once decompressed the following files and directories are visible typically:
3rd party libraries, etc.
Viewing this as an unzipped file, it looks garbled but has plenty of strings that are visible. We can recreate the file with the
This file contains the package name,
mindSdkVersionwhich tells us the oldest version of Android this app can run on.
targetSdkVersionis the OS version the app was designed for.
This is where majority of the compiled application bytecode lives.
$ file classes.dex
classes.dex: Dalvik dex file version 035
Java code written in, say, Android Studio is compiled into a "dex" file. It's name comes from Dalvik Executable (which we saw in the last post) but it is universal to both Dalvik VMs and Android Runtime environments.
Limits : There is a limit of 65535 methods that can be stored in a single dex file. Most programs have a single dex file because the Dalvik VM supported one per APK. However, you can configure multiple dex files (multidexing) if needed.
Tools to view :
dexdump to disassemble code sections into smali.
This holds everything from HTML, fonts, text files, images and more.
This is used for storing libraries and precompiled code. Going through this directory we can find directories which represent different combinations of CPU types and instruction sets known as Application Binary Interfaces or ABIs. Inside these subdirectories (like x86, etc.) we can filed Linux Shared Object files (.so).
The .so files are libraries either created by the app developer or third parties. If an attacker can modify and replace these files this could be a straightshot way to RCE. However, there are safeguards in place to deter attackers from the same.
Files related to the integrity and authenticity of the application live here.
MANIFEST.MF - A listing of all the resource files and their SHA1
CERT.RSA - Developers signing certificate
CERT.SF - List of resources and hashes
All resources that are not compiled into the
resources.arsc file. These files are not very important when thinking from a pentesting perspective.
There are plenty of other files that we might see like 3rd party libraries, app specific directories, etc. When auditing the source code we should investigate those as well.
Application Security & Signing Process
Every Android Application can be reverse engineered, rebuilt, re-signed and re-run
This means an attacker can modify application functionality
Java program vs Android Program
Android apps are written in Java, compiled into DEX (Dalvik Executable) bytecode. The Android VM (ART) runs the DEX bytecode directly compiled from the JAVA. ART has more optimizations features than the Dalvik VM.
Source: TCM Academy
Anyone can modify an application and publish it to the Play Store how do we ensure it's integrity? Public Key Cryptography!
The public key is often included in a type of digital file known as a x.509 certificate. This is used to verify the identity of an entity.
There are 3 methods of verifying signatures
APK signature scheme v1-3
Google implemented Google Play signing which adds unique signatures to the apps
The application signing process is built into Android Studio.
jarsignertool can be used to sign or verify a signature and is the same tool used for a Java JAR file.
jarsigner -sigalg SHA1withRSA -digestalg SHA1 -keystore whatever.keystore myapp.apk ksalias
We can use openssl to validate the hash in the MANIFEST.MF file matches the original file to validate.
Similar process can be followed for the CERT.SF file as well to validate the apk file.
MANIFEST.MF the hashes are of the files whereas in CERT.SF the hashes are of the lines of the MANIFEST.MF
Android requires all APK entries and the APK to be signed by the same certificate. This is done to enable OTA updates (the way they are distributed and validated).
Android Studio has two signing modes: Debug and Release
Debug is for testing purposes to run apps on emulators or connected devices
Release mode is for publishing apps on Play store or pushing to consumers.
APK validation process |Source: source.android.com
Finally, an APK is aligned after it is signed which is done with the
zipalign tool like so.
zipalign -v 4 project_unaligned.apk project.apk
Alignment is done to optimize the structure for efficient installation on Android devices and improved performance.