AI
How RASP Monitors Mobile Apps
RASP integrates directly into an app at development or deployment time. At runtime, it monitors behavior, inspects inputs and system instructions, and can kill the app or throw an error when it detects a threat. Common checks include root detection, emulator detection, and hooking detection. Modern RASP solutions add memory integrity checks that compare ELF headers and checksums across the file system and memory. If the app binary has been tampered with, the check fires. These checks run continuously, not once.
Why the Kernel Defeats Every RASP Check
Every RASP check eventually bottoms out as a syscall. Root detection uses faccessat to test if suspicious files exist. Frida detection opens /proc/tasks and scans port 27042 via connect and bind. Memory integrity checks read /proc/PID/maps to compare loaded library checksums. Since all of these go through the kernel, modifying how the kernel handles those syscalls breaks every check at once. No Frida hooks are needed. The kernel sits above any userspace protection.
Five Syscalls, One Driver
The driver (named “ohyas”) targets five syscalls: connect, bind, read, faccessat, and openat. These cover all four RASP detection categories. Intercepting connect and bind hides the Frida port from port scans. Intercepting faccessat and openat hides root artifacts and Frida gadget files. Each interceptor checks the calling process ID, then inspects the path or address against a list of known security-tool signatures. If it matches, the driver returns minus one. Otherwise it calls the original syscall and passes through the result.
Compiling the Driver Into the OnePlus 6 Kernel
The OnePlus 6 kernel is open source, downloaded from GitHub, and built with Clang. The driver source lives in the kernel’s drivers/ohyas/ folder. Halder’s team compiled it directly into the kernel image rather than as a loadable module, because the OnePlus 6 kernel rejected out-of-tree modules. After editing the Makefile and Kconfig to include the driver, the build produces a boot.img flashed to the device via fastboot. Process IDs are hardcoded at compile time because the kernel lacks libc for dynamic string parsing.
Evasion Results and the Limits of RASP
With the driver running, the modified kernel logs every file path a target app tries to open and blocks any that match Frida gadget signatures, returning minus one instead of the real result. Halder tested this against several RASP-protected Android apps and confirmed universal bypass. Performance overhead is negligible: each interceptor does a string comparison and calls the original syscall. The team’s parallel project, NOX Frida Patcher, achieves similar results without kernel modification by patching the Frida gadget binary directly.
Notable Quotes
a frozen kernel is a major problem so Subho Halder · ▶ Watch (14:12)
that this bypasses work universally Subho Halder · ▶ Watch (29:22)
kind of impossible for your rasp vendor Subho Halder · ▶ Watch (30:11)
Key Takeaways
- RASP protections all rely on syscalls, making kernel-level interception a universal bypass.
- Five syscalls (connect, bind, read, faccessat, openat) cover root, Frida, port-scan, and integrity checks.
- Custom kernel drivers compiled into the boot image evade detection with negligible performance overhead.
- RASP is a useful control layer, but apps should not depend on it as the sole defense.
About the Speaker(s)
Subho Halder is Co-Founder and CTO at Appknox, a mobile application security platform for automated assessment. A security technologist and product developer, his expertise stems from deep research into mobile platforms. He has earned accolades in Hall of Fame programs and has spoken at Black Hat, DEF CON, RSA, AppSec, and other major security conferences.