Introduction to Live Kernel Patching on Android

The Android operating system, at its core, runs on a Linux kernel. This foundational layer dictates everything from process scheduling to hardware interaction. For developers, security researchers, and enthusiasts pushing the boundaries of system customization, the ability to inspect and dynamically modify kernel behavior at runtime is an invaluable, albeit advanced, technique. Live kernel patching, using tools like Kprobes and Ftrace, provides a powerful mechanism to achieve this without requiring a full system reboot or recompilation of the kernel image.

This article delves into the intricacies of Kprobes and Ftrace, demonstrating how they can be leveraged on Android devices to perform dynamic analysis, trace function calls, and even lay the groundwork for runtime behavioral modifications. We’ll explore the underlying principles, setup a practical environment, and walk through real-world examples.

Prerequisites and Environment Setup

Before embarking on live kernel patching, ensure you have the following:

• Rooted Android Device or Emulator: Access to the root shell is mandatory to interact with kernel debugging interfaces.
• ADB (Android Debug Bridge): Essential for connecting to your device and executing commands.
• Kernel Source Code: While not strictly necessary for simple Ftrace/Kprobe events, having access to your device’s exact kernel source code (or a similar version) is crucial for understanding function signatures and offsets for more complex probing.
• `CONFIG_KPROBES` and `CONFIG_FTRACE`: Verify that your kernel is compiled with these configurations enabled. You can check this via grep -i KPROBES /proc/config.gz and grep -i FTRACE /proc/config.gz after decompressing.
• Basic Linux Kernel Knowledge: Familiarity with kernel modules, system calls, and the Linux directory structure (`/sys/kernel/debug`) is beneficial.

Verifying Kprobes and Ftrace Availability

On your rooted Android device, you can quickly check if the necessary kernel features are enabled:

adb shellsu -cd /sys/kernel/debugls tracing# You should see directories like 'events', 'kprobe_events', 'trace_pipe'ls kprobes_events # This file should exist to register kprobes

If `tracing` or `kprobe_events` are missing, your kernel may not have these features enabled, and you might need to compile a custom kernel.

Understanding Kprobes: Runtime Probing

Kprobes (Kernel Probes) provide a mechanism to dynamically insert breakpoints into any instruction address in the Linux kernel. When the probed instruction is hit, Kprobes can execute a user-defined handler function before (pre-handler), after (post-handler), or instead of (fault handler) the original instruction. This allows for non-intrusive monitoring and, critically, the ability to alter control flow or data if designed carefully within a kernel module.

There are three types of Kprobes:

1. Kprobe: The most common type. It registers a breakpoint at a specified address. When hit, it executes a pre-handler, the original instruction, and then a post-handler.
2. Jprobe: Designed for probing function entry points. It allows direct access to the probed function’s arguments. The jprobe handler replaces the original function until it explicitly calls jprobe_return().
3. Kretprobe: Probes function return points. It executes a handler when the probed function returns.

For dynamic modification via `kprobe_events` and Ftrace, we primarily interact with `kprobe_events`, which simplifies Kprobe registration without writing a kernel module.

Understanding Ftrace: The Linux Kernel Tracer

Ftrace is an internal Linux kernel tracing utility designed to help developers and system administrators understand what the kernel is doing. It can trace function calls, schedule events, system calls, and much more. Ftrace exposes its interface primarily through the `debugfs` filesystem, typically mounted at `/sys/kernel/debug/tracing`.

Key Ftrace components relevant to Kprobes:

• `current_tracer`: Specifies the active tracer (e.g., `function`, `nop`).
• `trace_pipe`: A real-time stream of trace events.
• `events/`: A directory containing various event types (system calls, scheduling, custom events). Crucially, this is where `kprobe_events` integrate.
• `kprobe_events`: This special file allows you to register Kprobes dynamically from user space, without recompiling or loading kernel modules. Ftrace then routes the probe hits into its tracing infrastructure.

Practical Example: Tracing a Kernel Function Call

Let’s trace the `sys_openat` system call, which is frequently used by Android applications to open files. We’ll use `kprobe_events` to set up probes and Ftrace to capture the output.

Step 1: Identify the Target Function and Arguments

For `sys_openat`, the signature typically looks like `long sys_openat(int dfd, const char __user *filename, int flags, umode_t mode)`. We want to capture `filename` and `flags`.

Step 2: Register Kprobe Events

We’ll register two probes: one at the entry of `sys_openat` and one at its return. This requires knowing the function name and argument offsets (or relying on Ftrace’s symbol lookup for common functions).

adb shellsu -echo 'p:myprobe_openat_entry sys_openat dfd=%ax filename=%si flags=%dx' > /sys/kernel/debug/tracing/kprobe_eventsecho 'r:myprobe_openat_ret sys_openat retvalue=%ax' >> /sys/kernel/debug/tracing/kprobe_events

Explanation:

• `p:` Prefix for a Kprobe at function entry.
• `r:` Prefix for a Kretprobe at function return.
• `myprobe_openat_entry`, `myprobe_openat_ret`: Custom event names.
• `sys_openat`: The target function.
• `dfd=%ax`, `filename=%si`, `flags=%dx`: Capture arguments using register conventions (may vary by architecture; for ARM/ARM64, arguments are typically passed in `x0-x7` or `r0-r3`). Note: For ARM64, `%ax` is `x0`, `%si` is `x1`, `%dx` is `x2`, etc. You might need to adjust based on your specific architecture. Assuming a 64-bit Android system for common registers.
• `retvalue=%ax`: Capture the return value (often in `x0`).

Step 3: Enable Kprobe Event Tracing

Once registered, these probes appear as events under `/sys/kernel/debug/tracing/events/kprobes/`.

adb shellsu -echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe_openat_entry/enableecho 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe_openat_ret/enableecho 1 > /sys/kernel/debug/tracing/tracing_on

Step 4: Generate Activity and Observe Output

Now, perform some file-related activity on your Android device (e.g., open an app, browse files). Then, read the trace output:

adb shellsu -cat /sys/kernel/debug/tracing/trace_pipe

You will see output similar to this (simplified):

<...> adbd-1234  [002] ...1 12345.67890: myprobe_openat_entry: sys_openat+0x0/0x180 dfd=0xffffff9c filename="/data/data/com.example.app/files/test.txt" flags=0x80000<...> adbd-1234  [002] ...1 12345.67900: myprobe_openat_ret: sys_openat+0x0/0x180 retvalue=0x3

Step 5: Clean Up

Disable tracing and unregister probes:

adb shellsu -echo 0 > /sys/kernel/debug/tracing/tracing_onecho 0 > /sys/kernel/debug/tracing/events/kprobes/myprobe_openat_entry/enableecho 0 > /sys/kernel/debug/tracing/events/kprobes/myprobe_openat_ret/enableecho > /sys/kernel/debug/tracing/kprobe_events

The last command clears all registered Kprobes.

Advanced: Simulating Dynamic Modifications

While `kprobe_events` with Ftrace excels at observation, true