Introduction to ROP Chains and ASLR Bypass on Android ARM64

Modern operating systems, including Android, implement robust security measures to prevent arbitrary code execution. Two cornerstone defenses are Data Execution Prevention (DEP) or Non-Executable (NX) bits, which prevent code execution from data segments, and Address Space Layout Randomization (ASLR), which randomizes the memory locations of key program components. These defenses make traditional stack-based shellcode injection largely ineffective. To circumvent NX, attackers resort to Return-Oriented Programming (ROP), a technique that chains together small code snippets (gadgets) already present in the executable memory of the target process.

However, ROP chains rely on knowing the exact memory addresses of these gadgets. This is where ASLR presents a significant challenge. By randomizing memory layouts, ASLR makes it impossible to hardcode gadget addresses, thus breaking ROP chains. This tutorial will delve into the intricacies of ASLR on Android ARM64 and demonstrate a common bypass technique: information leakage, followed by the construction of a ROP chain to achieve command execution.

Understanding ASLR on Android ARM64

The Purpose of ASLR

ASLR is a computer security technique involved in preventing an entire class of memory corruption vulnerabilities. It randomly arranges the address space positions of key data regions, including the base of the executable and position of libraries, heap, and stack. This randomization makes it difficult for an attacker to predict target addresses, such as the location of specific functions or ROP gadgets, making exploits more complex and less reliable.

Android’s ASLR Implementation

Android utilizes a strong ASLR implementation, especially on 64-bit ARM architectures (ARM64). The vast 64-bit address space (2^64 possible addresses) provides a massive entropy pool, making brute-forcing memory addresses practically impossible within reasonable timeframes. System libraries (like libc.so, libandroid.so) and application binaries are loaded at different, randomized base addresses with each process execution. For a ROP chain to succeed, an attacker must first defeat ASLR to determine these randomized base addresses at runtime.

Information Leakage: The Key to ASLR Bypass

The most common and effective method to bypass ASLR is through an information leakage vulnerability. Such a vulnerability allows an attacker to read out sensitive memory contents, including pointers or addresses of loaded modules. Once an address from a randomized module (e.g., a function pointer from libc.so) is leaked, the attacker can subtract the known offset of that function within the module to calculate the module’s base address. From there, all other functions and data segments within that module become addressable.

Common Leakage Vectors

• Format String Vulnerabilities: Incorrect use of format strings (e.g., printf with user-controlled input) can leak stack contents or arbitrary memory.
• Uninitialized Memory Disclosures: Returning uninitialized stack or heap memory can reveal pointers or sensitive data from previous operations.
• Out-of-Bounds Reads: Errors in array indexing or buffer handling can allow reading beyond intended memory boundaries, potentially disclosing pointers.
• Partial Pointer Overwrites: In some cases, only a portion of an address might be randomized. Overwriting a non-randomized part can lead to a leak or controlled write.

Simulating an Address Leak

For this hands-on tutorial, we’ll assume we’ve identified an information leakage vulnerability in an ARM64 Android native application that allows us to retrieve an address within libc.so. For example, a vulnerable C++ program might accidentally print a pointer from its internal workings. You can inspect memory maps of a running process using adb:

adb shell cat /proc/<pid>/maps

This command shows the memory layout for a given process ID. You’d typically see entries like:

724a800000-724aa46000 r-xp 00000000 103:02 5462 /apex/com.android.runtime/lib64/bionic/libc.so

If we leak, say, the address of the puts function, we can then determine the base address of libc.so. First, we find the offset of puts within a local copy of libc.so (extracted from a matching Android device/emulator image):

readelf -s /path/to/android/libc.so | grep puts

This might yield an output like: 88: 0000000000072d70 96 FUNC GLOBAL DEFAULT 14 puts indicating an offset of 0x72d70. If the leaked runtime address of puts was 0x724a872d70, then libc_base = 0x724a872d70 - 0x72d70 = 0x724a800000. Now we have the base address, and all other functions within libc.so (like system) can be accurately located.

Return-Oriented Programming (ROP) Fundamentals on ARM64

The Concept of Gadgets

ROP bypasses NX by executing existing instruction sequences, called