s1l3ntk1ll3r (Sukrit Dua)

Android Hacking- Part 2

Build Process, Compilation, APK Structure, Components, Signing and more.

Sukrit Dua's photo
Sukrit Dua
·

5 min read

Android Hacking- Part 2

Table of contents

Understanding how Android Applications are compiled and structured will help us understand the process better.

Compiling Applications

Android App building = Compilation + Packaging + Signing.

Here are the compilation steps and diagram showing the process:

  • (Android Asset Packaging Tool) aapt -> R.java + .java + .aidl + app source code

  • Java Compiler -> .class

  • dex -> classes.dex files

  • apkbuilder -> .apk

  • Jarsigner -> signed .apk

  • zipalign -> signed and aligned .apk

Android App compilation process

Compilation process | Source: MASPT Caendra

APK (Android Package) Structure

An 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:

  • AndroidManifest.xml

  • classes.dex

  • resources.arsc

  • /assets

  • /lib

  • /META-INF

  • /res

  • 3rd party libraries, etc.

AndroidManifest.xml

Viewing this as an unzipped file, it looks garbled but has plenty of strings that are visible. We can recreate the file with the apktool, jadx-guiand more.

This file contains the package name,

  • mindSdkVersion which tells us the oldest version of Android this app can run on.

  • targetSdkVersion is the OS version the app was designed for.

💡
All manufacturers and/or developers wants to support as many devices as they can but they need to strike a balance between supporting old devices aka inheriting the vulnerabilities that come with and putting data at risk.

Classes.dex

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 shows that we can never assume anything when it comes to Application Security. The client app code is not secret and when dealing with client-server communications we can never be sure if the client hasn't been modified or impersonated.

Assets folder

This holds everything from HTML, fonts, text files, images and more.

Lib folder

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.

META-INF folder

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

Res folder

All resources that are not compiled into the resources.arsc file. These files are not very important when thinking from a pentesting perspective.

Other files

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

Tools: jadx-gui or Apktool

Compilation Process

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.

Application Signing

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.

  • jarsigner tool 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

  • Tools : keytool, jarsigner, zipalign

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).

🔺
If an app dev loses the private key, there is no way for them to recover this and continue to have their app users receive updates. If a key is compromised, an organization will have to sign the app with a new key which will show up as a new app on Play store because that is how it identifies the organization who signs the app. If an attacker gets the private key, they can sign and publish malicious apps to the Play store as the organization.

Signing Modes

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.

Validation Process

APK validation process |Source: source.android.com

Alignment

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.

Androidapp developmentbuildpenetration testinghackingcompilationapk