Introduction to Android Memory Corruption Mitigations

The Android operating system, underpinning billions of devices, continuously evolves its security posture to combat sophisticated exploitation techniques. Memory corruption vulnerabilities, such as buffer overflows and use-after-free, remain a primary target for attackers. To counter these, Android leverages advanced hardware and software mitigations designed to disrupt common exploit primitives like arbitrary code execution and control flow hijacking.

The Landscape of Android Security

Modern Android versions incorporate a multi-layered security model. At its core, the Linux kernel, coupled with SELinux, provides fundamental process isolation and access control. However, deeper within the system, compiler-based and hardware-assisted mitigations specifically target the runtime behavior of applications and the kernel itself, making memory corruption exploits significantly harder to achieve. Understanding and, more importantly, being able to bypass or disable these mitigations is crucial for security researchers to assess their effectiveness, identify potential weaknesses, and develop advanced exploit techniques for responsible disclosure.

Understanding CFI, PAC, and BTI

This guide focuses on three prominent memory corruption mitigations: Control Flow Integrity (CFI), Pointer Authentication Codes (PAC), and Branch Target Identification (BTI).

• Control Flow Integrity (CFI): A compiler-based mitigation that ensures program execution follows a predetermined control flow graph, preventing arbitrary jumps or calls to unintended code locations.
• Pointer Authentication Codes (PAC): An ARMv8.3-A hardware feature that cryptographically signs pointers, making it harder to forge or corrupt them without detection.
• Branch Target Identification (BTI): An ARMv8.5-A hardware feature that restricts indirect branches to specific ‘landing pad’ instructions, preventing attackers from jumping to arbitrary locations within executable memory.

Control Flow Integrity (CFI) in Android

How CFI Works

CFI operates by instrumenting the compiled code to verify that every indirect call, jump, or return instruction targets a valid, type-compatible destination. If a target address doesn’t match the expected type or isn’t a valid entry point, the program terminates. This is implemented using compiler flags like -fsanitize=cfi, which injects runtime checks at various points in the control flow graph.

Observing CFI in Action

When CFI detects an integrity violation, it typically results in a crash with specific log messages. You can often see these messages in logcat or dmesg. For example:

AndroidRuntime: FATAL EXCEPTION: main
Process: com.example.vulnerableapp, PID: 12345
java.lang.Error: org.chromium.build.generated_build_config.BuildConfig
    at android.os.AsyncTask.execute(AsyncTask.java:650)
    at com.example.vulnerableapp.MainActivity.onCreate(MainActivity.java:30)
    ...
Caused by: java.lang.Error: Sanitizer: CFI: call to virtual function with wrong type
    at <unknown module> (<unknown file>:0)

The key indicator here is