Introduction to Control-Flow Integrity (CFI) in Android

Control-Flow Integrity (CFI) is a crucial security mechanism designed to prevent common exploit techniques, such as return-oriented programming (ROP) and call-oriented programming (COP), by ensuring that the execution flow of a program adheres to a predetermined valid path. In the context of Android native binaries, CFI plays a vital role in hardening the operating system’s core components and third-party applications against various memory corruption vulnerabilities. This lab will guide you through the process of reverse engineering Android native binaries to uncover and understand how CFI is enforced, laying the groundwork for identifying potential bypasses.

The fundamental principle behind CFI is simple: restrict indirect branches (like indirect calls, jumps, and returns) to only land at valid, type-compatible target locations. While seemingly straightforward, implementing robust CFI without significant performance overhead or false positives is a complex challenge, especially in a diverse ecosystem like Android, which leverages LLVM’s compiler infrastructure.

Android’s CFI Landscape and LLVM Integration

Android heavily relies on LLVM’s compiler infrastructure, which provides robust support for various sanitizers, including CFI. Specifically, Android’s build system often employs LLVM’s fine-grained CFI. This implementation typically involves two primary categories of checks:

• Virtual Function Call Checks: Ensuring that virtual method calls dispatch to an object’s legitimate virtual table entry for its declared type.
• Indirect Function Call Checks: Verifying that calls through function pointers target functions with compatible signatures.

These checks are injected by the compiler during compilation (e.g., using flags like -fsanitize=cfi) and manifest as additional code sequences within the compiled binary. Understanding these code patterns is key to identifying CFI enforcement.

Setting Up Your Reverse Engineering Lab

To embark on this reverse engineering journey, you’ll need a set of essential tools:

• IDA Pro or Ghidra: Powerful disassemblers/decompilers for static analysis.
• ADB (Android Debug Bridge): For interacting with Android devices or emulators.
• Android NDK: Useful for compiling simple native binaries with CFI enabled for experimentation.
• Rooted Android Device or Emulator: To pull system binaries or test your own compiled code.

Obtaining a Target Binary

For our lab, we’ll aim for a native library (.so file) that is likely compiled with CFI. A good starting point could be a system library from a recent Android version. For instance, you can pull a library like /system/lib64/libbinder.so or a component from an AOSP build if you have access.

adb shell adb pull /system/lib64/libbinder.so .

Alternatively, you can compile a simple C++ program with virtual functions using the Android NDK, explicitly enabling CFI:

// cfidemo.cpp #include <iostream> class Base { public: virtual void foo() { std::cout << "Base::foo" << std::endl; } }; class Derived : public Base { public: void foo() override { std::cout << "Derived::foo" << std::endl; } }; int main() { Base* b = new Derived(); b->foo(); return 0; }

# Compile for ARM64 with CFI enabled $NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android29-clang++ cfidemo.cpp -o cfidemo -fsanitize=cfi -fno-omit-frame-pointer -O1 -Wall

This will produce a binary (cfidemo) that you can analyze.

Deconstructing a CFI-Enabled Binary

Identifying CFI Compiler Flags

While you can’t always directly determine compiler flags from a stripped binary, the presence of specific symbols or code patterns is a strong indicator. Using readelf or objdump can sometimes reveal sections related to sanitizers, though explicit CFI symbols might be stripped.

# Look for sections or symbols related to sanitizers readelf -S cfidemo | grep sanitize objdump -T cfidemo | grep __cfi

Analyzing VTable-Based CFI

When a C++ program uses virtual functions, the compiler generates a virtual table (vtable) for each class containing pointers to its virtual functions. CFI for virtual calls typically involves checking that the vtable pointer (VPTR) belongs to a valid type for the call site. In disassembly, this often translates to runtime type checks before an indirect call through the vtable.

Let’s consider a simplified conceptual ARM64 disassembly snippet that illustrates a CFI check before a virtual function call:

; Assume X0 holds 'this' pointer ; Assume X8 holds the vtable pointer for 'this' (loaded from [X0]) ; Assume X9 is the expected type descriptor for the call MOV X1, #0            ; Reserved for CFI checks BL __cfi_check_vptr_vcall ; Call CFI helper function LDR X10, [X8, #0x18]    ; Load actual virtual function address from vtable BLR X10               ; Branch to the virtual function

In IDA Pro or Ghidra, search for cross-references to functions like __cfi_check_vptr, __cfi_check_vcall, or similar mangled names containing __sanitizer_cfi. You’ll often find these checks preceding indirect branches where virtual methods are invoked. The CFI helper function (e.g., __cfi_check_vptr_vcall) would internally compare the type information derived from the object’s vtable against the expected type for that call site, aborting if there’s a mismatch.

Indirect Call CFI

CFI also extends to indirect calls made through function pointers. Here, the challenge is to ensure that the target address of an indirect call corresponds to a legitimate function with a compatible signature. The compiler injects checks that verify the target’s type or entry point against a pre-computed set of valid targets.

A conceptual ARM64 example for an indirect call CFI check:

; Assume X0 holds the function pointer BL __cfi_check_vptr_icall_jump_impl_fast_indirect_call_amd64 ; Call CFI helper function for indirect calls BLR X0                ; Branch to the indirect call target

Again, searching for symbols like __cfi_check_icall or similar in your disassembler will lead you to these enforcement points. The CFI runtime maintains metadata about valid function targets, and this helper function performs a lookup to ensure the supplied function pointer is indeed one of those valid targets for the specific call site’s type signature.

Conceptualizing CFI Bypasses

While this lab focuses on understanding CFI enforcement, it’s worth briefly conceptualizing how a bypass might occur. CFI aims to ensure type compatibility. Therefore, bypasses often involve:

• Type Confusion: Manipulating an object’s type such that CFI believes it’s calling a method of one type, but the underlying memory layout causes it to execute code intended for a different, attacker-controlled type.
• Information Leaks: Prior knowledge of CFI’s internal data structures (e.g., shadow tables, type IDs) could be leveraged. If an attacker can leak the valid type ID for a specific call site, they might be able to forge a valid target.
• Partial Overwrites: If only a part of a pointer or vtable entry can be overwritten, it might be possible to direct control flow to a CFI check that is itself flawed or can be bypassed with the remaining legitimate parts.
• CFI-Uninstrumented Code: Some older or specific parts of a codebase might not be compiled with CFI. An attacker could try to pivot control flow to these uninstrumented sections.

The complexity of CFI bypasses often stems from the need to not only control the target address but also to satisfy the type-compatibility checks imposed by CFI. This typically requires more sophisticated primitives than simple arbitrary write vulnerabilities.

Conclusion

Reverse engineering CFI enforcement mechanisms in Android native binaries is a deep dive into compiler-level security. By identifying and understanding the injected CFI checks for virtual and indirect calls, security researchers gain invaluable insight into how modern exploit mitigations function. This knowledge is not only crucial for hardening systems but also for developing advanced exploitation techniques that navigate or bypass these sophisticated defenses. As CFI implementations continue to evolve, particularly with hardware-assisted features like ARM Memory Tagging Extension (MTE), the reverse engineer’s role in dissecting these protections becomes ever more critical.