Understanding ASLR on Android ARM64

Address Space Layout Randomization (ASLR) is a fundamental security mechanism designed to prevent memory corruption exploits, such as buffer overflows, from reliably executing shellcode. By randomizing the base addresses of key memory regions—like the stack, heap, and shared libraries—ASLR makes it incredibly difficult for an attacker to predict the location of essential functions or ROP (Return-Oriented Programming) gadgets. On Android, especially on ARM64 architectures, ASLR is robustly implemented, presenting significant challenges for exploit developers. This article will demystify ASLR and walk through a conceptual framework for bypassing it on Android ARM64.

The Challenge of ASLR on ARM64

ARM64 architecture, coupled with modern Android kernels, utilizes 64-bit pointers and typically offers a high degree of entropy for ASLR. This means that base addresses are randomized across a vast address space, making brute-forcing memory locations impractical. A successful ASLR bypass almost always relies on an information leak vulnerability. This leak allows an attacker to discover the randomized base address of a critical module (like libc.so) or a stack/heap address, effectively nullifying the protection ASLR provides for that specific memory region.

The Cornerstone: Information Leakage

An information leak is the lynchpin of almost all ASLR bypasses. It’s a vulnerability that allows an attacker to read arbitrary memory contents or specific sensitive data that reveals memory addresses. Common sources of information leaks include:

• Out-of-bounds reads: Reading beyond the allocated buffer, potentially disclosing stack or heap pointers.
• Uninitialized memory disclosure: Applications failing to zero-initialize buffers before sending them to an attacker.
• Format string vulnerabilities: Using functions like printf with attacker-controlled input, leading to memory disclosure.
• Heap metadata leaks: Specific heap management vulnerabilities exposing heap chunk pointers.

For our demonstration, let’s assume we’ve identified an out-of-bounds read vulnerability in a native Android application’s service running as a privileged user. This vulnerability, when triggered, allows us to read a few bytes past an intended buffer. Crucially, due to stack layout, one of these leaked values happens to be a return address pointing directly into libc.so.

Identifying the Leak and Target Process

First, we need to locate our vulnerable application’s process ID (PID) and inspect its memory map. We’ll use adb shell to interact with the Android device.

adb shell ps -ef | grep com.example.vulnerableapp

Let’s say the PID is 1234. Now, we examine its memory map to understand the ASLR randomization:

adb shell cat /proc/1234/maps | grep libc

A typical output might look like this (addresses will be randomized on each run):

72e0000000-72e01a9000 r-xp 00000000 103:07 1673   /apex/com.android.runtime/lib64/bionic/libc.so

Note the base address: 0x72e0000000. This address changes with every process restart due to ASLR. Our goal is to dynamically discover this address.

Building the Bypass: Step-by-Step

Step 1: Triggering the Information Leak

Assuming we have a crafted input (e.g., a specially formatted string, a network packet) that triggers the out-of-bounds read, we’ll execute it. The vulnerable application, upon processing this input, will leak a part of memory containing a libc address back to us (e.g., through a debug log, a network response, or an error message). Let’s say the leaked address is 0x72e00123456. This is an address *within* libc.so, not its base.

Step 2: Calculating the libc Base Address

To determine the base address of libc.so from the leaked internal address, we need to know the offset of the leaked address within a *non-randomized* libc.so. We can obtain this offset by analyzing the libc.so binary from the Android device using tools like readelf or a disassembler (e.g., IDA Pro, Ghidra).

First, pull the libc.so from the device:

adb pull /apex/com.android.runtime/lib64/bionic/libc.so .

Now, inspect the binary. Let’s assume the leaked address 0x72e00123456 corresponds to a known function or a specific instruction within libc.so that is at a fixed offset (e.g., 0x123456) from its base in the non-ASLR’d binary. This offset can be found using `objdump` or `readelf` on the pulled `libc.so` binary.

readelf -s libc.so | grep SomeKnownFunction

If SomeKnownFunction is located at offset 0x123456, then the libc base address can be calculated:

leaked_address = 0x72e00123456 (from the exploit output)offset_in_libc = 0x123456 (from static analysis of libc.so)libc_base_address = leaked_address - offset_in_libc= 0x72e00123456 - 0x123456= 0x72e0000000

Voila! We have successfully derived the runtime base address of libc.so, effectively bypassing ASLR for this critical library.

Step 3: Crafting the Exploit Payload (ROP Chain)

With the libc base address known, all functions within libc become deterministic. This means we can now reliably locate functions like system() or execve() and string literals like "/system/bin/sh" (if present) or provide them via a writable memory region.

We can use tools like ROPgadget or build our ROP chain manually to find suitable gadgets (small instruction sequences ending in a return instruction) within libc.so. The general idea for an ARM64 ROP chain to execute a shell might involve:

• Popping arguments into registers (e.g., x0 for the command string, x1 for args, x2 for envp).
• Branching to the `system()` function (located at libc_base + system_offset).

For example, if `system` is at offset `0x45678` and the string `”/system/bin/sh”` is at `libc_base + 0xABCDE`, our ROP chain would roughly look like this:

# Placeholder for ROP chain (conceptual)payload = b''# 1. Pop address of "/system/bin/sh" into x0 (argument for system)payload += p64(libc_base_address + pop_x0_gadget_offset)payload += p64(libc_base_address + shell_string_offset)# 2. Call system()payload += p64(libc_base_address + system_function_offset)

This crafted ROP chain would then be delivered through another memory corruption vulnerability (e.g., a buffer overflow on the stack or heap) that allows overwriting the return address or a function pointer with our chain.

Conclusion

Bypassing ASLR on Android ARM64 is a complex but achievable task, almost invariably relying on an initial information leak. By leveraging a vulnerability to disclose a memory address within a randomized library like libc.so, an attacker can calculate the library’s base address. Once the base is known, the full power of memory corruption exploits, such as ROP, can be unleashed to achieve arbitrary code execution. This process highlights the critical importance of mitigating information leakage vulnerabilities and implementing robust exploit mitigations beyond just ASLR to protect modern systems.