Introduction to Linux Kernel Modules on Android

Linux Kernel Modules (LKMs) offer a powerful mechanism to extend the functionality of the Linux kernel without requiring a full kernel recompile. On Android devices, LKMs are particularly potent, providing unparalleled access and control over the operating system’s core. This deep dive will explore advanced LKM techniques, specifically focusing on intercepting and modifying system calls, a fundamental operation for tasks ranging from security monitoring to injecting custom behaviors into the Android system.

Understanding system call interception is crucial for anyone looking to perform expert-level OS customizations or develop advanced security tools. It involves diverting the flow of execution from a standard system call to a custom handler, allowing us to inspect, modify, or even deny operations before the kernel processes them.

Why Intercept System Calls?

The ability to intercept system calls opens up a myriad of possibilities for advanced Android control:

• Security Monitoring: Monitor file access, network connections, process creation, and other sensitive operations in real-time. This can be used to detect malware or unauthorized activities.
• Policy Enforcement: Implement custom security policies, such as restricting specific applications from accessing certain files or network resources.
• Debugging and Analysis: Gain insights into how applications interact with the kernel, invaluable for reverse engineering or performance analysis.
• Feature Injection: Add new capabilities or modify existing ones without altering the application binaries or the core kernel image.
• Rootkit Development: While often associated with malicious intent, the same techniques are fundamental for understanding and defending against sophisticated rootkits.

Prerequisites for LKM Development on Android

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

1. Rooted Android Device: Essential for loading custom kernel modules.
2. Kernel Source Code: Obtain the exact kernel source code matching your device’s kernel version. This is critical for successful compilation and symbol resolution.
3. Android NDK & Cross-Compilation Toolchain: Required to compile your LKM for the device’s specific architecture (e.g., ARM64).
4. Basic Linux Kernel Programming Knowledge: Familiarity with C programming and kernel module basics is assumed.

To verify your kernel version, use uname -a on your Android device:

adb shell uname -a

Locating the System Call Table

The Linux kernel’s system call table (sys_call_table) is an array of function pointers, where each index corresponds to a specific system call number. To intercept a system call, we need to find the address of this table in kernel memory.

Method 1: Using /proc/kallsyms

On many systems, the /proc/kallsyms file exposes the addresses of all exported kernel symbols. We can parse this file to find the sys_call_table address:

adb shell cat /proc/kallsyms | grep sys_call_table

The output will typically look like this:

ffffffff81000000 T sys_call_table

The hexadecimal value is the address. Note that on some hardened Android kernels, /proc/kallsyms might be restricted or obfuscated.

Method 2: Scanning Kernel Memory (Advanced)

If /proc/kallsyms is unavailable, you might need to scan kernel memory for a specific byte pattern that identifies the sys_call_table. This is highly architecture-dependent and complex, often involving searching for known sequences of system call addresses (e.g., `sys_read`, `sys_write`, `sys_open`). This approach is beyond the scope of this tutorial but is a viable alternative for highly protected systems.

Disabling Write Protection (CR0 Register)

The sys_call_table resides in a read-only section of kernel memory. To modify it, we must temporarily disable the CPU’s write protection. This is typically achieved by clearing the Write Protect (WP) bit in the CR0 control register. This operation is privileged and can only be performed in kernel mode.

Kernel-level CR0 Manipulation

In your LKM, you can define functions to clear and set the WP bit:

#include <linux/module.h> #include <linux/kernel.h> #include <linux/kallsyms.h> #include <asm/uaccess.h> #include <asm/current.h> #include <linux/syscalls.h> // For ARM64, CR0 is not directly exposed to modify WP bit this way. // Instead, we directly modify the memory permissions using set_memory_rw/set_memory_ro // or rely on architectural-specific methods if directly manipulating page tables. // For x86/x64, it would look like this: // static void disable_write_protection(void) { //   unsigned long cr0; //   asm volatile("mov %%cr0, %0" : "=r"(cr0)); //   cr0 &= ~0x00010000; // Clear the WP bit //   asm volatile("mov %0, %%cr0" : : "r"(cr0)); // } // static void enable_write_protection(void) { //   unsigned long cr0; //   asm volatile("mov %%cr0, %0" : "=r"(cr0)); //   cr0 |= 0x00010000; // Set the WP bit //   asm volatile("mov %0, %%cr0" : : "r"(cr0)); // } // For ARM64, we typically use functions like set_memory_rw/set_memory_ro // from the kernel, if they are exported or accessible. If not, // direct page table manipulation is required, which is significantly more complex // and highly architecture/kernel-version dependent. // For simplicity in this general tutorial, we'll assume a method exists, // or that the kernel has an exported set_memory_rw/ro function. // In a real ARM64 scenario, you'd likely use kallsyms to find set_memory_rw. // A simpler approach for *some* ARM64 kernels is to directly invalidate // the TLB after modifying the table entry, trusting the kernel's // initial page table setup might allow a temporary write. // This tutorial will proceed with a conceptual `disable_memory_protection` // and `enable_memory_protection` functions. // In practice for ARM64, you'd often target the specific page containing // the sys_call_table and modify its permissions.

Note on ARM64: Directly manipulating CR0 (or its ARM equivalent) to disable write protection on an arbitrary memory region is significantly more complex and often involves direct manipulation of page tables rather than a simple register bit flip. Modern kernels employ stricter memory protection. For practical purposes, you might need to use exported functions like set_memory_rw() and set_memory_ro() if available via kallsyms, or resort to highly architecture-specific page table modifications.

For the remainder of this tutorial, we will conceptually use disable_memory_protection() and enable_memory_protection(), implying whatever mechanism is appropriate for the target architecture and kernel version.

Hooking a System Call: Example with sys_write

Let’s demonstrate by hooking the sys_write system call. Our hooked function will simply log a message before calling the original sys_write.

1. Define the Original System Call Pointer

// Define the type for the original sys_write function pointer typedef asmlinkage long (*orig_write_t)(int fd, const char __user *buf, size_t count); orig_write_t original_sys_write; // Pointer to the original sys_call_table

2. Implement Your Hook Function

// Our custom sys_write hook function asmlinkage long hooked_sys_write(int fd, const char __user *buf, size_t count) {   char kbuf[256];   if (fd == 1 || fd == 2) { // stdout or stderr     if (copy_from_user(kbuf, buf, min((size_t)255, count))) {       // Handle error, e.g., printk(KERN_ERR "Failed to copy_from_user");     } else {       kbuf[min((size_t)255, count)] = '';       printk(KERN_INFO "LKM Hook: Process %d wrote to FD %d: %sn", current->pid, fd, kbuf);     }   }   return original_sys_write(fd, buf, count); // Call the original sys_write }

3. Module Initialization (init_module)

In your module’s initialization function, you’ll locate the sys_call_table, store the original sys_write address, disable write protection, and replace the entry with your hook.

// Assume this function exists for disabling protection static void disable_memory_protection(void); // Assume this function exists for enabling protection static void enable_memory_protection(void); // Placeholder for sys_call_table (must be found dynamically) unsigned long *sys_call_table; static int __init syscall_hook_init(void) {   // Find sys_call_table address (example for ARM64, can vary)   sys_call_table = (unsigned long *)kallsyms_lookup_name("sys_call_table");   if (!sys_call_table) {     printk(KERN_ERR "LKM Hook: Could not find sys_call_table!n");     return -ENOENT;   }   printk(KERN_INFO "LKM Hook: sys_call_table found at 0x%lxn", (unsigned long)sys_call_table);   // Store original sys_write   original_sys_write = (orig_write_t)sys_call_table[__NR_write];   // Disable write protection for sys_call_table page   disable_memory_protection();   // Replace sys_write with our hook   sys_call_table[__NR_write] = (unsigned long)hooked_sys_write;   // Re-enable write protection   enable_memory_protection();   printk(KERN_INFO "LKM Hook: sys_write hooked successfully.n");   return 0; }

4. Module Cleanup (cleanup_module)

Upon module unload, it’s crucial to restore the original sys_write pointer to prevent system instability.

static void __exit syscall_hook_exit(void) {   if (sys_call_table) {     // Disable write protection for sys_call_table page     disable_memory_protection();     // Restore original sys_write     sys_call_table[__NR_write] = (unsigned long)original_sys_write;     // Re-enable write protection     enable_memory_protection();     printk(KERN_INFO "LKM Hook: sys_write unhooked successfully.n");   } } module_init(syscall_hook_init); module_exit(syscall_hook_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Your Name"); MODULE_DESCRIPTION("Android System Call Interceptor");

Compiling and Deploying the LKM

1. Create a Makefile

You’ll need a Makefile for cross-compilation. Adjust `ARCH` and `CROSS_COMPILE` based on your device’s architecture and toolchain path.

# Makefile KDIR := /path/to/your/android/kernel/source/tree ARCH := arm64 # or arm CROSS_COMPILE := /path/to/your/android/ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android- obj-m := syscall_hook.o all:   $(MAKE) -C $(KDIR) M=$(PWD) modules clean:   $(MAKE) -C $(KDIR) M=$(PWD) clean

2. Compile Your Module

make

This will generate syscall_hook.ko.

3. Deploy and Load on Android Device

adb push syscall_hook.ko /data/local/tmp/ adb shell su -c "insmod /data/local/tmp/syscall_hook.ko"

After loading, any process writing to stdout/stderr should trigger your printk messages, which you can view with adb logcat -k or dmesg.

4. Unload the Module

adb shell su -c "rmmod syscall_hook"

Important Considerations and Best Practices

• Kernel Version Compatibility: System call table offsets, internal kernel functions, and memory protection mechanisms can vary significantly between kernel versions. Always compile against the exact kernel source for your target.
• Race Conditions: Modifying critical kernel structures like the sys_call_table can introduce race conditions if not handled carefully.
• System Stability: Incorrectly hooked or buggy functions can lead to kernel panics (KPs) or system instability. Test thoroughly in a controlled environment.
• Detection: Sophisticated security systems can detect system call hooks. Techniques to avoid detection (e.g., direct page table manipulation, trampoline functions) add significant complexity.
• Error Handling: Robust LKMs include comprehensive error checking, especially when dealing with user-space memory (e.g., copy_from_user).

System call interception is a powerful tool in the arsenal of advanced Android customization. While it provides immense control, it also demands a deep understanding of kernel internals and careful implementation to ensure stability and security. Use these techniques responsibly and ethically.