Listen to this Post
Introduction:
Runtime Application Self-Protection (RASP) solutions on Android monitor application behavior to detect and block malicious activities, but they operate at the userspace or framework level—leaving the kernel untrusted. By modifying the Android kernel and leveraging dynamic tracing tools like ftrace, kprobes, and uprobes, security researchers can observe and manipulate application execution from a privileged perspective, effectively bypassing RASP controls.
Learning Objectives:
- Understand how kernel-level instrumentation bypasses userspace RASP protections
- Learn to compile a custom Android kernel with ftrace, kprobes, and uprobes enabled
- Apply dynamic tracing techniques to intercept syscalls, kernel functions, and userspace routines of a target Android app
You Should Know:
1. Understanding RASP and Why Kernel Attacks Work
RASP integrates into an app’s runtime environment (e.g., through Dex bytecode instrumentation or native hooks) to detect reverse engineering, debugging, or tampering. However, RASP cannot see below the kernel boundary. By operating at the kernel layer, you can observe every system call, file access, memory allocation, and process event without triggering userspace hooks.
Key concept: The kernel is the ultimate authority. If you control the kernel (via a modified boot image on a rooted device), you can trace, log, and modify app behavior invisibly.
Prerequisites:
- Rooted Android device or emulator with unlockable bootloader
- Android AOSP source or kernel source matching your device
- Linux build environment (Ubuntu 20.04/22.04 recommended)
Step‑by‑step guide to verify kernel tracing support:
On your Android device (rooted), check if ftrace is available:
adb shell su mount -t debugfs none /sys/kernel/debug ls /sys/kernel/debug/tracing
If the `tracing` directory exists, ftrace is enabled. For kprobes:
cat /sys/kernel/debug/kprobes/list
Linux commands to build a custom kernel with tracing:
Clone kernel source (example for Pixel 3) git clone https://android.googlesource.com/kernel/msm.git -b android-msm-crosshatch-4.9-android12 cd msm Enable tracing in defconfig make ARCH=arm64 cross_compile=aarch64-linux-android- defconfig echo "CONFIG_FTRACE=y" >> .config echo "CONFIG_KPROBES=y" >> .config echo "CONFIG_UPROBES=y" >> .config echo "CONFIG_DEBUG_FS=y" >> .config make ARCH=arm64 CROSS_COMPILE=aarch64-linux-android- -j$(nproc)
- Dynamic Tracing with Ftrace for Real-Time Syscall Monitoring
Ftrace captures kernel function entries and exits with minimal overhead. When an Android app makes a system call (e.g., open, read, write, ioctl), ftrace can record the call stack and arguments, revealing how the app interacts with the OS—bypassing any RASP hooks on libc or linker.
Step‑by‑step guide to trace all `open` syscalls by a specific app:
First, find the PID of the target app:
adb shell ps -A | grep com.example.targetapp
Then on the device (root shell):
cd /sys/kernel/debug/tracing echo 1 > tracing_on echo function_graph > current_tracer echo do_sys_open > set_graph_function echo $$ > set_ftrace_pid replace $$ with the PID cat trace_pipe > /data/local/tmp/trace.log & Run the app, then stop: echo 0 > tracing_on
Windows alternative (using ADB over USB):
adb shell "su -c 'echo 1 > /sys/kernel/debug/tracing/tracing_on'" adb shell "su -c 'echo do_sys_open > /sys/kernel/debug/tracing/set_graph_function'" adb shell "su -c 'cat /sys/kernel/debug/tracing/trace_pipe'" > trace.log
Pro tip: Use `trace-cmd` for a more user-friendly interface:
On device trace-cmd record -p function_graph -l do_sys_open -P <PID> -o /sdcard/trace.dat Pull and view on Linux adb pull /sdcard/trace.dat trace-cmd report trace.dat
3. Implementing Kprobes for Kernel Function Hooking
Kprobes allows you to insert breakpoints into any kernel function and execute custom handler code. This is more flexible than ftrace—you can modify return values or even block syscalls. For RASP bypass, you can hook functions like `__arm64_sys_ptrace` (to hide debugger detection) or `security_file_permission` (to bypass file integrity checks).
Step‑by‑step guide to install a kprobe module:
Create a C file `kprobe_hide_ptrace.c`:
include <linux/kernel.h>
include <linux/module.h>
include <linux/kprobes.h>
static int handler_pre(struct kprobe p, struct pt_regs regs) {
// Return -EPERM to make ptrace think it failed
regs->regs[bash] = -EPERM;
return 1; // Skip original function
}
static struct kprobe kp = {
.symbol_name = "__arm64_sys_ptrace",
.pre_handler = handler_pre,
};
int init_module(void) {
return register_kprobe(&kp);
}
void cleanup_module(void) {
unregister_kprobe(&kp);
}
MODULE_LICENSE("GPL");
Compile for Android kernel and insert:
On build host (using kernel Makefile) make -C /path/to/kernel M=$PWD modules adb push kprobe_hide_ptrace.ko /data/local/tmp adb shell insmod /data/local/tmp/kprobe_hide_ptrace.ko
Verification: Run a ptrace-based anti-debug check in the target app—it will fail silently, bypassing RASP detection.
4. Using Uprobes for User-Space Application Monitoring
Uprobes instruments userspace functions (e.g., Java_com_example_antitamper_check) without modifying the binary. Unlike RASP’s own hooks, uprobes operate from the kernel and are invisible to the app. This allows you to log or skip anti-tampering functions.
Step‑by‑step guide to hook a native function in a running app:
- Find the function’s offset in the app’s `.so` library using `nm` or
objdump:adb pull /data/app/com.example.targetapp/lib/arm64/libtarget.so aarch64-linux-android-objdump -T libtarget.so | grep anti_debug Assume offset 0x12345
2. On device, attach uprobe:
cd /sys/kernel/debug/tracing echo 'p:anti_debug_hook /data/app/com.example.targetapp/lib/arm64/libtarget.so:0x12345' > uprobe_events echo 1 > events/uprobes/anti_debug_hook/enable cat trace_pipe
To skip the function entirely (return immediately):
You would need a kernel module that modifies registers via uprobe handler. Simpler: use uprobe to log and then patch the binary in memory—but that’s another article.
- Bypassing RASP Integrity Checks by Hiding Kernel Modifications
Many RASP solutions check for kernel tampering (e.g., ro.secure=1, verifiedbootstate). With kernel control, you can spoof these values. Hook `proc_dostring` or `sysfs_read` to return fake boot states.
Step‑by‑step guide to spoof verified boot state using kprobe:
Target function: `show_verifiedbootstate` in drivers/of/sysfs.c. Hook it to always return “green”:
static int spoof_vboot(struct kprobe p, struct pt_regs regs) {
char buf = (char )regs->regs[bash];
sprintf(buf, "green\n");
regs->regs[bash] = strlen("green\n");
return 1; // skip original
}
After inserting the module, any read of `/sys/devices/system/arm/secure_boot` returns “green” regardless of actual state.
Windows-side automation: Use `adb` script to push, load, and verify:
adb push spoof_vboot.ko /data/local/tmp adb shell "su -c 'insmod /data/local/tmp/spoof_vboot.ko'" adb shell "su -c 'cat /sys/devices/system/arm/secure_boot'"
6. Mitigation Strategies for Defenders
While kernel attacks are powerful, defenders can raise the bar:
– Implement kernel-level integrity monitoring (e.g., Linux Kernel Module Signing, Verified Boot with custom keys)
– Use hardware-backed attestation (Android Keystore, TrustZone) to detect kernel modifications remotely
– Deploy eBPF-based monitoring on the kernel to detect rogue kprobes/uprobes (e.g., using `bpftool` to list probes)
– Periodically check `/sys/kernel/debug/tracing` for unexpected events or enabled tracers
– Recompile kernel without CONFIG_KPROBES/CONFIG_UPROBES in production devices—but this breaks legitimate debugging
Command to list all active kprobes on a compromised device (for incident response):
cat /sys/kernel/debug/kprobes/list cat /sys/kernel/debug/tracing/uprobe_events
What Undercode Say:
- Kernel is the new app layer. As RASP and userspace anti-tampering mature, attackers move deeper into the kernel. Ftrace, kprobes, and uprobes provide a stealthy, powerful toolkit for bypassing almost any userspace protection.
- Defense must shift left and down. Mobile security strategies must include kernel hardening, runtime kernel integrity checks, and hardware-backed attestation. RASP alone is insufficient against a motivated adversary with root access and kernel modification skills.
- Knowledge asymmetry. Most mobile app developers and even many security engineers are unfamiliar with kernel tracing techniques. This gap creates a dangerous blind spot. Red teams should adopt these methods; blue teams should monitor for their artifacts.
Prediction:
Within 18–24 months, we will see commercial Android RASP products integrating kernel-level anomaly detection (via eBPF) to counter these exact bypass techniques. Simultaneously, advanced malware will begin shipping with custom kernel modules to disable RASP and hide persistence. The arms race will move from userspace hooking to kernel rootkit detection, pushing mobile security closer to traditional endpoint detection and response (EDR) paradigms. Expect Google to introduce stricter kernel runtime restrictions in Android 16+, possibly deprecating debugfs on production builds—but determined attackers will simply reflash custom kernels. The ultimate solution lies in hardware-enforced security (TrustZone, hypervisor), not software kernel hardening.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
