Introduction to ASLR and Information Leaks

Address Space Layout Randomization (ASLR) is a fundamental security feature designed to prevent memory corruption exploits, such as buffer overflows, by randomizing the base addresses of key data areas, including the executable, libraries, stack, and heap. On Android ARM64, ASLR is robust, making direct exploitation significantly harder. However, ASLR is not an impenetrable shield; it merely raises the bar for attackers. The first, and often most critical, step to bypassing ASLR is to find an “information leak.”

An information leak reveals the real memory address of a module, function, or piece of data that ASLR was intended to randomize. Once an attacker knows the actual location of even one critical memory region, they can often deduce the locations of others, effectively nullifying the protection ASLR provides. This article will delve into practical techniques for identifying such leaks on Android ARM64, setting the stage for more advanced exploit development.

Understanding ASLR on Android ARM64

Android, leveraging the Linux kernel, implements ASLR for all processes. Specifically, Position Independent Executables (PIE) are mandatory for all applications targeting API level 16 (Android 4.1) and higher. PIE binaries and shared libraries are loaded at random base addresses in memory each time the process starts, preventing attackers from relying on static memory layouts.

You can observe the memory layout of any running process on an Android device using the /proc filesystem. The /proc/<pid>/maps file provides a detailed map of all memory regions allocated to a process, including their permissions and the files they map to. Examining this file after each application launch would show different base addresses for the main executable and its loaded shared libraries if ASLR is effective.

adb shell
PID=$(pidof com.example.vulnerableapp)
cat /proc/$PID/maps | grep .so

This command would display lines similar to:

72e0000000-72e01a0000 r-xp 00000000 103:07 10178 /apex/com.android.runtime/lib64/bionic/libc.so
72e01a0000-72e01ba000 r--p 001a0000 103:07 10178 /apex/com.android.runtime/lib64/bionic/libc.so
72e01ba000-72e01bd000 rw-p 001ba000 103:07 10178 /apex/com.android.runtime/lib64/bionic/libc.so
72e01bd000-72e01be000 rw-p 00000000 00:00 0 
72e01c0000-72e0225000 r-xp 00000000 103:07 10206 /data/app/~~...==/com.example.vulnerableapp-==/lib/arm64/libnative.so
72e0225000-72e022b000 r--p 00065000 103:07 10206 /data/app/~~...==/com.example.vulnerableapp-==/lib/arm64/libnative.so
72e022b000-72e022c000 rw-p 0006b000 103:07 10206 /data/app/~~...==/com.example.vulnerableapp-==/lib/arm64/libnative.so

The crucial observation is that the starting addresses (e.g., 72e0000000 for libc.so and 72e01c0000 for libnative.so) will differ across restarts.

Common Types of Information Leaks

Stack Leaks

Stack leaks occur when uninitialized stack memory is disclosed, often through a vulnerability. If a sensitive pointer (e.g., a return address, a frame pointer, or an address of a global variable) resides on the stack and an application subsequently reads and prints an uninitialized buffer that overlaps with that pointer, its value can be leaked. This type of leak provides insight into the stack layout and potentially the base address of the main executable or loaded libraries.

Heap Leaks

Heap leaks can arise from similar issues on the heap, such as disclosing uninitialized heap memory. Heap metadata, like pointers to other heap chunks or `tcache` structures, can also be leaked if not properly sanitized or if a use-after-free vulnerability allows reading freed chunks. Such leaks are invaluable for heap spraying attacks or understanding heap layout for subsequent heap-based exploits.

Library Base Address Leaks (.text, .data)

Perhaps the most sought-after leaks are those that reveal the base address of a loaded shared library (like libc.so or a custom native library). A pointer to any function or global variable within a library’s .text or .data section, when leaked, can be used to calculate the library’s base address. Since all offsets within a PIE library are fixed relative to its base, knowing one address allows calculating all others.

Relocation Table Leaks (GOT/PLT)

The Global Offset Table (GOT) and Procedure Linkage Table (PLT) are essential for position-independent code to call external functions. The GOT, in particular, contains entries that are dynamically resolved to the actual addresses of functions in shared libraries. Leaking an address from the GOT directly reveals the real address of an external function, which in turn can lead to the base address of the corresponding library.

Practical Techniques for Leak Hunting

Memory Inspection via /proc Filesystem

While /proc/<pid>/maps shows address ranges, /proc/<pid>/mem allows direct memory reading. This requires root privileges or specific SELinux policies, but it’s a powerful way to search for known values (e.g., specific gadget sequences) or pointers. If you suspect a specific memory region contains a pointer you’re interested in, you can dump it and analyze it offline.

adb shell su -c

        
        
        

            

                
            
            

                
Android Mobile Specs & Compare Directory
                
Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!
                Compare Devices Specs →