Introduction: The Unseen World of Android Kernel Modules

Android devices, at their core, run a Linux kernel heavily customized for mobile hardware and use cases. Beneath the surface of apps and user interfaces, a complex interplay of kernel modules governs everything from hardware interaction to security features. Reverse engineering these kernel modules can be critical for security research, performance optimization, and understanding proprietary functionalities. While static analysis tools provide a foundational view, dynamic analysis offers insights into real-time execution flows. This article delves into leveraging Ftrace, the Linux kernel’s powerful tracing utility, to dynamically analyze Android kernel modules and uncover their hidden operations.

Ftrace provides a detailed look into what the kernel is doing, offering mechanisms to trace function calls, events, and even set up custom probes. When applied to kernel modules, it becomes an indispensable tool for understanding their runtime behavior, identifying performance bottlenecks, and scrutinizing security-sensitive operations without needing to modify and recompile the kernel.

Prerequisites for Dynamic Kernel Module Analysis

Before diving into Ftrace, ensure you have the following setup:

• Rooted Android Device: Full root access is essential to interact with debugfs, where Ftrace controls reside.
• ADB Access: Android Debug Bridge (adb) is required to shell into the device and execute commands.
• Kernel Debugging Symbols (Optional but Recommended): If you have access to the Android device’s kernel image with debugging symbols (e.g., vmlinux), tools like objdump or readelf can help identify function names and offsets within specific modules, significantly aiding targeted tracing.
• Basic Linux Command-line Proficiency: Familiarity with commands like cat, echo, ls, and shell scripting.

Setting Up Ftrace for Kernel Module Tracing

Ftrace operates primarily through the debugfs virtual filesystem, typically mounted at /sys/kernel/debug/tracing. All Ftrace controls and trace outputs are accessible within this directory.

1. Accessing the Tracing Interface

First, connect to your Android device via ADB and navigate to the tracing directory:

adb shellsucd /sys/kernel/debug/tracing

2. Identifying Target Kernel Modules

Before tracing, you need to know which modules are loaded and their exact names. Use lsmod or inspect /proc/modules:

cat /proc/modules

This will list all currently loaded kernel modules. For example, you might see entries like wlan 123456 0 - Live 0x00000000. Note the module name (e.g., wlan).

3. Enabling a Tracer and Filtering by Module

For broad function-level tracing, the function or function_graph tracers are most useful. function_graph provides a call graph visualization, which is excellent for understanding execution flow.

echo 0 > tracing_on # Disable tracing to configureecho function_graph > current_tracer # Set the tracerecho 1 > options/func_stack_trace # Capture stack traces for more context

Now, to focus on a specific module, use set_ftrace_filter. This is crucial for reducing noise and focusing on relevant activity.

echo my_custom_module > set_ftrace_filter # Replace 'my_custom_module' with your target module name

If you need to trace specific functions within that module, and you know their names (e.g., from static analysis or symbols), you can list them:

echo my_custom_module_function_A > set_ftrace_filterecho my_custom_module_function_B >> set_ftrace_filter # Use >> to append

Alternatively, to filter out functions *not* belonging to your module, you can use set_ftrace_notrace if you have a very specific set of functions to exclude, but set_ftrace_filter is usually more direct for module-specific tracing.

Advanced Ftrace Event Filtering with Kprobes

While function tracing is powerful, sometimes you need to trace specific events, register changes, or argument values at arbitrary points in a function, not just its entry/exit. This is where kprobe (kernel probe) events shine.

1. Understanding Kprobes

Kprobes allow you to dynamically insert breakpoints into almost any kernel function and define custom trace events. You can capture function arguments, return values, and even register states. The syntax for defining kprobe events is:

p:<event_name> <function_name>[:<offset>] <field>=<expression>

For instance, to trace the entry of a function my_module_init within my_custom_module and capture its first argument (assuming it’s a pointer to an integer):

echo 'p:my_mod/init_entry my_module_init arg1=%di' > /sys/kernel/debug/tracing/kprobe_events

Here, %di is a register (x86_64, first argument) that would hold the first argument. For ARM64, arguments are typically in x0 to x7 registers. You’ll need to consult ARM64 calling conventions for the correct register usage.

2. Enabling and Disabling Kprobe Events

Once defined, enable the kprobe event:

echo 1 > events/my_mod/init_entry/enable

To disable:

echo 0 > events/my_mod/init_entry/enable

To remove a kprobe definition:

echo '-:my_mod/init_entry' > /sys/kernel/debug/tracing/kprobe_events

Capturing and Analyzing Trace Data

With Ftrace configured, you can now capture activity.

1. Starting and Stopping Tracing

echo 1 > tracing_on # Start tracing

Perform the operations on your Android device that you want to trace (e.g., load the module, interact with the feature it controls).

echo 0 > tracing_on # Stop tracing

2. Viewing the Trace Output

The captured trace data is stored in the trace file:

cat trace > /sdcard/my_module_trace.txt # Save to a file for later analysis

Example `function_graph` output for a hypothetical `my_module`:

# tracer: function_graph#-# span:    0ms; Time:     0.000 ms#CPU  DURATION                  FUNCTION CALLS|+ 0)               | my_module_init() {|+ 0)   0.345us   |  some_helper_function();|+ 0)   1.234us   |  another_module_func();|+ 0)               |  sub_init() {|+ 0)   0.123us   |   sub_sub_func();|+ 0)   2.567us   |  }|+ 0)   4.890us   | }

For kprobe events, the output will include the captured fields:

# tracer: nop#...cpu     0:        123456.789: my_mod_init_entry: (my_module_init+0x0/0x100) arg1=0xbeefdead

3. Cleaning Up

After analysis, it’s good practice to reset Ftrace:

echo > trace # Clear the trace bufferecho nop > current_tracer # Reset to no tracer (or function to remove filters)echo > set_ftrace_filter # Clear all filters

Real-world Example: Tracing a Hypothetical Custom Device Driver

Imagine an Android device has a custom kernel module, my_device_driver.ko, that interfaces with a unique sensor. We suspect performance issues or want to understand its initialization sequence and data handling. Let’s trace its key functions.

Scenario: Analyze my_device_driver initialization and read operations.

1. Identify the module:adb shellsucat /proc/modules | grep my_device_driver
2. Set up Ftrace for my_device_driver functions:cd /sys/kernel/debug/tracingecho 0 > tracing_onecho function_graph > current_tracerecho my_device_driver_init > set_ftrace_filterecho my_device_driver_read >> set_ftrace_filterecho my_device_driver_probe >> set_ftrace_filter
3. Enable a kprobe for specific read arguments: Assuming my_device_driver_read has a signature like ssize_t my_device_driver_read(struct file *file, char __user *buf, size_t count, loff_t *pos), and we want to capture count (often in x2 or r2 for ARM64/ARM).echo 'p:my_driver/read_args my_device_driver_read count=%x2' > kprobe_eventsecho 1 > events/my_driver/read_args/enable
4. Start tracing and trigger events:echo 1 > tracing_on

   Now, perform an action that would load the driver or trigger a read operation (e.g., open a specific app, interact with the sensor).

   echo 0 > tracing_on

5. Analyze the trace:cat trace

   Look for the my_device_driver_init and my_device_driver_probe call graphs to understand the initialization flow and any functions they call. Observe the my_driver_read_args events to see the count value passed during read operations, indicating data request sizes.

Conclusion: The Power of Dynamic Kernel Module Analysis

Ftrace provides unparalleled visibility into the runtime behavior of Android kernel modules. By combining function tracing, function graph analysis, and powerful kprobe events, reverse engineers and security researchers can dynamically dissect complex module operations, identify hidden functionalities, analyze performance characteristics, and uncover potential vulnerabilities. This dynamic approach complements static analysis, offering a holistic understanding of how these critical low-level components operate within the Android ecosystem. Mastering Ftrace is a crucial step for anyone involved in advanced Android system analysis and security research.