Introduction: The Challenge of Control-Flow Integrity on Android

Control-Flow Integrity (CFI) is a critical security mechanism designed to prevent attackers from hijacking program execution flow. On Android, CFI is extensively used, primarily implemented via LLVM’s compiler-based CFI, which instruments indirect function calls, virtual calls, and returns to ensure they target only valid, pre-determined locations. This makes traditional arbitrary code execution via memory corruption vulnerabilities significantly harder. However, for skilled adversaries or researchers, bypassing CFI remains a key objective, often paving the way for full compromise. This article delves into the practical aspects of achieving a Control-Flow Integrity bypass on Android using a Return-Oriented Programming (ROP) chain, focusing on common architectural pitfalls and exploitation techniques.

Understanding CFI in the Android Context

Android’s CFI is typically enabled at compile-time by LLVM and operates by verifying the target of indirect branches. For instance, when a function pointer is called, CFI ensures that the target address corresponds to a valid function signature known at compile time. If an attacker corrupts a function pointer to point to arbitrary shellcode, CFI will detect the invalid target and terminate the process. This protection extends to virtual calls and, in some implementations, to return instructions.

Specifically, Android’s LLVM CFI implementation adds checks:

• Indirect calls: Ensures the target address is a valid function with a compatible type.
• Virtual calls: Similar to indirect calls, checks the vtable pointer and method index.
• Backward-edge CFI (BTI/PAC on ARMv8.5+): Newer ARM architectures introduce Branch Target Identification (BTI) and Pointer Authentication Codes (PAC). BTI ensures branches only land on valid target instructions (BTI instruction), while PAC cryptographically signs pointers (including return addresses) to prevent tampering. For this guide, we’ll primarily consider environments without PAC/BTI or scenarios where PAC/BTI can be circumvented, focusing on the core ROP concept against LLVM CFI.

The Foundation: Information Leaks and Memory Corruption

Before crafting a ROP chain, two fundamental conditions are almost always required:

1. Memory Corruption Vulnerability: An exploitable bug such as a buffer overflow, use-after-free, or integer overflow that allows an attacker to corrupt memory, particularly stack data or heap metadata. This is the primitive used to redirect control flow.
2. Information Leak: Due to Address Space Layout Randomization (ASLR), memory addresses are randomized at each program execution. An attacker needs an information leak (e.g., through a format string vulnerability or a UAF primitive that leaks heap pointers) to discover the base addresses of loaded libraries (like libc.so) and the stack. Without knowing these addresses, a ROP chain cannot reliably target gadgets.

For illustrative purposes, let’s assume we have an arbitrary write primitive and an information leak that provides us with the base address of libc.so.

Example: Leaking libc Base Address

While not an exploit primitive itself, reading /proc/self/maps illustrates what an info leak provides:

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

Output might look like:

72a00000-72c1e000 r-xp 00000000 103:07 1019  /apex/com.android.runtime/lib64/bionic/libc.so

Here, 0x72a00000 would be the base address of libc.so for that particular process execution.

Crafting the ROP Chain: Bypassing CFI with Returns

The core idea behind ROP is to chain together small sequences of legitimate, existing instructions (called