Ftrace for Android Security Research: Monitoring Kernel Exploits with Advanced Event Filters

The Android operating system, at its core, relies on the Linux kernel. Kernel vulnerabilities are among the most severe, often leading to full system compromise or privilege escalation. When analyzing or developing kernel exploits, or even simply hardening a system, understanding kernel execution flow at a granular level is paramount. This is where Ftrace, the Linux kernel’s internal tracing utility, becomes an indispensable tool for security researchers.

Ftrace provides a powerful, low-overhead mechanism to observe kernel functions, events, and their interactions in real-time. While its basic usage for performance profiling is well-documented, its advanced capabilities—particularly sophisticated event filtering—offer an unparalleled view into the kernel’s state, making it ideal for monitoring suspicious activities that might indicate an ongoing exploit.

Prerequisites for Ftrace on Android

To effectively utilize Ftrace for Android kernel security research, you’ll need the following:

• Rooted Android Device: Full root access is required to access and modify Ftrace configuration files within the /sys/kernel/debug/tracing directory.
• ADB (Android Debug Bridge): For connecting to the device and executing shell commands.
• Basic Linux Kernel Knowledge: Familiarity with kernel concepts, system calls, and function names will be highly beneficial.

First, establish an ADB shell connection to your device:

adb shell

Next, mount the debugfs filesystem, which exposes the Ftrace interface:

su
mount -t debugfs none /sys/kernel/debug

Navigate to the Ftrace control directory:

cd /sys/kernel/debug/tracing

Understanding Basic Ftrace Operations

Before diving into advanced filtering, let’s briefly review the fundamental Ftrace controls:

Enabling and Disabling Tracing

To clear any previous trace data and disable tracing:

echo 0 > tracing_on
echo > trace

To enable tracing:

echo 1 > tracing_on

Selecting a Tracer

The current_tracer file determines the tracing mode. For security research, function and event are most useful, though nop (no operation) is used for configuration without active tracing.

echo function > current_tracer # Traces kernel function calls
echo nop > current_tracer    # Resets tracer (good practice before configuring)

You can list available tracers using cat available_tracers.

Viewing Available Events

Kernel events are categorized. You can list all available events or specific categories:

ls events/
ls events/syscalls/
cat events/kmem/enable # Check if kmem events are enabled

Advanced Event Filtering for Kernel Exploit Monitoring

This is where Ftrace truly shines for security researchers. Instead of logging every single kernel event (which would be overwhelming), advanced filters allow you to pinpoint activities relevant to exploit analysis.

Tracing Specific Kernel Functions

To monitor a particular kernel function, such as commit_creds (often targeted in privilege escalation exploits) or prepare_kernel_cred, you can use set_ftrace_filter.

echo nop > current_tracer
echo 0 > tracing_on
echo > trace

echo commit_creds > set_ftrace_filter
echo prepare_kernel_cred >> set_ftrace_filter # Add another function
echo function > current_tracer
echo 1 > tracing_on

# Perform an action that might trigger these functions (e.g., run an exploit)

echo 0 > tracing_on
cat trace # View the collected trace data

To clear the function filter:

echo > set_ftrace_filter

Monitoring System Calls with Event Filters

System calls are crucial attack surfaces. Ftrace allows you to enable specific syscall events and then apply filters based on their arguments.

echo nop > current_tracer
echo 0 > tracing_on
echo > trace

# Enable all syscalls (can be noisy, filter below)
echo 1 > events/syscalls/enable

# Example: Monitor mmap calls with PROT_EXEC (0x4) or PROT_WRITE (0x2)
# The 'prot' argument for sys_mmap is typically the 4th argument.
# Ftrace event fields can be found in /sys/kernel/debug/tracing/events/syscalls/sys_mmap/format
# Let's assume 'prot' is a field name for illustration.
echo 'prot & 0x4 || prot & 0x2' > events/syscalls/sys_mmap/filter

# You could also filter for openat calls trying to access sensitive files
echo 'filename ~ "*shadow*" || filename ~ "*passwd*"' > events/syscalls/sys_openat/filter

echo 1 > tracing_on
# Run suspicious activity
echo 0 > tracing_on
cat trace

Clear event filters by echoing an empty string to them:

echo > events/syscalls/sys_mmap/filter
echo 0 > events/syscalls/sys_mmap/enable

Tracking Kernel Memory Allocations (Kmem Events)

Heap exploits often involve specific patterns of kernel memory allocation and deallocation. Ftrace’s kmem events are invaluable here.

echo nop > current_tracer
echo 0 > tracing_on
echo > trace

# Enable kmalloc and kfree events
echo 1 > events/kmem/kmalloc/enable
echo 1 > events/kmem/kfree/enable
echo 1 > events/kmem/kmem_cache_alloc/enable

# Filter kmalloc events for suspicious allocation sizes (e.g., very large, or specific chunk sizes for heap spraying)
# Assuming 'bytes_req' is the field for requested size (check format file)
echo 'bytes_req > 1048576 || bytes_req == 4096' > events/kmem/kmalloc/filter

# Filter kfree events potentially freeing critical structures (can be harder without context)
# Example: monitor kfree of certain addresses (requires prior knowledge)
# echo 'ptr == 0xdeadbeef' > events/kmem/kfree/filter # Hypothetical

echo 1 > tracing_on
# Trigger memory-intensive or exploit-related actions
echo 0 > tracing_on
cat trace

Remember to check the format file for each event (e.g., events/kmem/kmalloc/format) to understand the available fields for filtering.

PID-Specific Tracing

If you suspect a particular process, you can narrow down tracing to only include events from that PID:

echo <PID> > set_ftrace_pid

To clear:

echo > set_ftrace_pid

Capturing Stack Traces

For deeper analysis of *how* a specific function or event was reached, enabling stack tracing is crucial. This can be combined with function or event filtering.

echo stacktrace > current_tracer # Not always ideal with function tracer
echo 1 > options/stacktrace # Enable stacktrace for selected events/functions

# After tracing, the stacktrace will appear in the trace output.

Analyzing Trace Data

The trace file contains the collected data. The format is typically:
<task-name>-<pid> [CPU#] | tracer_name: function_name (parent_function) | timestamp: function_entry
For events, it includes event-specific fields.
Manually parsing large trace files can be tedious. Tools like ftrace_analyzer.py (part of the Linux kernel source’s tools/tracing directory) or custom scripts using grep, awk, and Python can help. For Android, you might need to pull the trace file to your host machine:

adb pull /sys/kernel/debug/tracing/trace ./trace.log

Practical Scenario: Detecting a Kernel Heap Corruption Attempt

Imagine an exploit attempts to corrupt a kernel object by manipulating heap allocations. We want to detect unusual kmalloc sizes followed by calls to a sensitive function like vmap_area_alloc (often involved in allocating executable memory).

# 1. Reset Ftrace
echo nop > current_tracer
echo 0 > tracing_on
echo > trace
echo > set_ftrace_filter
echo > set_ftrace_pid
for i in $(ls events/*/); do echo 0 > events/$i/enable; for j in $(ls events/$i/); do echo > events/$i/$j/filter; done; done

# 2. Set function filter for suspicious functions
echo vmap_area_alloc > set_ftrace_filter
echo alloc_pages_vma >> set_ftrace_filter # Another related function
echo __kmalloc >> set_ftrace_filter # Catch the underlying kmalloc

# 3. Enable kmem events and filter for specific sizes
echo 1 > events/kmem/kmalloc/enable
echo 1 > events/kmem/kfree/enable
# Assume an exploit uses a specific chunk size, e.g., 256 bytes, or a very large size for a specific object
echo 'bytes_req == 256 || bytes_req > 524288' > events/kmem/kmalloc/filter

# 4. Enable stack tracing for better context
echo 1 > options/stacktrace

# 5. Start tracing
echo function > current_tracer # Or set to nop and only rely on events
echo 1 > tracing_on

# 6. Run the exploit or application that might trigger it
# Example: adb shell /data/local/tmp/exploit_binary

# 7. Stop tracing and retrieve data
echo 0 > tracing_on
adb pull /sys/kernel/debug/tracing/trace trace_exploit.log

# 8. Analyze trace_exploit.log for suspicious sequences:
#    - Large or specific kmallocs
#    - Subsequent calls to vmap_area_alloc or other sensitive functions
#    - The call stack leading to these events

Conclusion

Ftrace is an extraordinarily powerful and flexible tool for anyone engaged in Android kernel security research. By mastering its advanced event filtering capabilities, researchers can move beyond broad observation to precisely target and monitor specific kernel activities. This granular control is vital for identifying the footprints of kernel exploits, understanding their mechanics, and ultimately developing more robust defenses against them. Integrating Ftrace into your kernel debugging and exploit analysis workflow will undoubtedly enhance your ability to uncover hidden vulnerabilities and validate security patches.