Rooting and jailbreaking frameworks are constantly evolving, often maintained by independent developers without formal security oversight. As a result, they frequently introduce unpredictable risks that pose a serious and ongoing threat to enterprise security by enabling malware infections, app compromise, and even full system takeovers.
At Zimperium’s zLabs, tracking these tools is a key part of our threat analysis workflow. This continuous monitoring helps us stay ahead of emerging vulnerabilities and maintain real-time awareness of the evolving mobile threat landscape, as cybercriminals move to a mobile-first attack strategy.
Our findings consistently demonstrate that these frameworks present real, exploitable risks in the wild. In this blog post, we will present a technical analysis of a vulnerability we originally discovered in mid-2023, illustrating how attackers could leverage it to completely compromise a rooted Android device.
In this post, we’ll cover:
- How modern rooting frameworks like KernelSU, APatch and SKRoot gain root access and escalate privileges.
- How an attacker could exploit one such vulnerability to gain full control using an internally developed proof-of-concept.
The Rise of Kernel Patching: How Modern Rooting Tools Hook Deep into Android
Over time, numerous techniques have been used to gain root access on Android devices. However, most recent frameworks have converged on a common strategy: Android kernel patching, as seen in tools like KernelSU, APatch and SKRoot.
This approach involves hooking into key kernel functions—either by hot-patching a pre-compiled kernel or directly modifying the source code. This allows these frameworks to intercept execution and run arbitrary code within the kernel. To bridge the gap between kernel space and user space, they typically hook specific system calls, creating covert communication channels to a manager app running with normal user privileges. This app acts as the interface for managing permissions and controlling access, including its own, despite not having elevated rights itself.
While most modern rooting tools follow similar patterns in kernel integration, they differ significantly in how they handle authentication.
The Hidden Weak Spot: Manager Authentication
Because system calls can be triggered by any app on the device, strong authentication and access controls are essential. Unfortunately, this layer is often poorly implemented—or entirely neglected—which opens the door to serious security risks. Improper authentication can allow malicious apps to gain root access and fully compromise the device.
Password-Based Authentication (A Common but Fragile Approach)
Some tools, such as APatch and SKRoot, protect kernel interfaces using a password—either auto-generated or user-defined during installation. However, if the password is weak or the validation mechanism is flawed (e.g., vulnerable to side-channel attacks), attackers may be able to bypass authentication, access the root interface, and escalate their privileges.
Package-Based Authentication (Verifying the Caller’s Identity)
Another approach, used by tools like KernelSU, relies on package-based authentication. In this model, the kernel verifies that it’s communicating with the legitimate manager app by checking package names, UIDs, or digital signatures. This method avoids relying on user-generated secrets and instead enforces trust based on the app’s identity on the system.
While package-based authentication can be more robust than password-based methods, it still demands careful implementation. Without proper signature checks or if combined with permissive policies, it too can be vulnerable to spoofing or privilege misuse.
In the next section, we’ll explore how such spoofing attacks can allow a malicious app to impersonate the manager and gain unauthorized root access.
The Vulnerability
The first vulnerability we’ll discuss was present in KernelSU version 0.5.7 (Git tag v0.5.7) and allowed an attacker to authenticate as the KernelSU manager.
KernelSU Manager Interface
To provide an interface between the manager app and the kernel, KernelSU hooks into the prctl system call—a syscall typically used to get or set various attributes of the calling process.
The standard function signature of prctl is:
int prctl(int op, ...);
Under normal usage, the option parameter specifies the operation to be performed, and depending on that operation, the function may take additional arguments.
For KernelSU, hooking into prctl offers a flexible and convenient mechanism. It allows the manager application to pass arbitrary arguments to the kernel, enabling various actions to be triggered based on the input. To route execution into its own internal handler, KernelSU uses a predefined magic value—0xDEADBEEF—as the first argument. This value signals that the call should be interpreted by the KernelSU handler rather than the default prctl logic. It's followed by a specific command code and optional parameters.
For example, to retrieve the current KernelSU version, the manager app could invoke the following C code:
prctl(0xDEADBEEF, CMD_GET_VERSION, &version_buffer);
Note: These commands are only accepted when issued by an authenticated manager application. To gain access to the privileged interface, the app must first successfully invoke CMD_BECOME_MANAGER. Without this initial step, all other commands will be ignored or denied by the kernel.
In addition to CMD_GET_VERSION, KernelSU supports a variety of other command options, including:
- CMD_ALLOW_SU – Manages an allowlist of app package names permitted to execute as root.
- CMD_SET_SEPOLICY – Allows modification of SELinux policies.
- CMD_GRANT_ROOT – Grants root privileges to the calling process.
- CMD_BECOME_MANAGER – Promotes the calling app to act as the root manager.
- ...and many more.
These commands, routed through the prctl hook, give the manager app powerful control over the rooted environment—making secure authentication and validation absolutely critical.
KernelSU manager authentication (v0.5.7)
The following code snippet, adapted from the original KernelSU manager application, demonstrates how the system call is prepared to request manager privileges. As discussed in the previous section, KernelSU leverages the prctl syscall and a specific command (CMD_BECOME_MANAGER) that allows an application to declare itself as the manager. In addition to the command, a third argument must be passed to the kernel containing the path to the calling app’s data directory:
As shown above, the data directory path is built based on the application’s user ID. For applications running under the primary user (UID < 100000), the expected prefix is /data/data/.
Kernel-Side Verification Process
Upon receiving this request, KernelSU performs a series of checks to validate the authenticity of the caller:
- Parse and Validate the Provided Path
The kernel copies the third argument and verifies that it starts with the expected prefix (/data/data or /data/user/<id>), based on the calling app’s UID:
- Verify Ownership of the Target Path
Next, the kernel confirms that the folder specified in the path is indeed owned by the calling app:
Because the application inherently owns this folder, the caller can easily pass this check.
3. Verify the APK’s SignatureFinally, KernelSU attempts to verify the identity of the manager by examining the signing certificate of the calling process's APK:
- It iterates over the process’s open file descriptors (fd table).
- It searches for the first file that matches /data/app/*/base.apk, assumed to be the main APK.
- It checks the APK's v2 signature to confirm it matches the official KernelSU manager.
This reliance on the first base.apk found in the fd table introduces a significant weakness, which will be the focus of the attack described in the next section.
The Exploit
In the following scenario, we assume an attacker-controlled application with the package name com.attacker.manager. The goal is to bypass KernelSU's authentication checks and impersonate the legitimate manager application in order to gain root access.
Passing the first two checks is straightforward, as shown in the example below:
// Request to become the manager by mimicking expected input
const char* data_path = "/data/data/com.attacker.manager";
int32_t result = -1;
prctl(KERNEL_SU_OPTION, CMD_BECOME_MANAGER, data_path, nullptr, &result);
However, the final check—verifying the signing certificate—is considerably more challenging and requires a creative workaround.
As previously described, KernelSU performs signature verification by scanning the current process’s file descriptor (fd) table and inspecting the first file that matches the pattern /data/app/*/base.apk. If this file does not contain the expected signature, the authentication process is immediately aborted.
This becomes a problem for an attacker: The first matching base.apk entry will typically point to the attacker’s own APK, which of course does not match the signature of the official manager. To bypass this, the attacker needs to trick the kernel into reading the legitimate manager’s APK instead.
This can be achieved by manipulating file descriptor ordering, ensuring the manager’s base.apk appears earlier in the fd table than the attacker’s own APK.
Steps to Perform the Attack
- Identify the fd of the attacker's own base.apk.
- Locate a free file descriptor with a lower value than the one found in step 1.
- If no free fd is available, close stdin (fd 0) and reuse it.
- Open the official KernelSU manager's base.apk.
To facilitate step 4, the attacker must bundle the official KSU manager APK with their own application. One practical location is the app’s lib directory, which typically resolves to a path like:
/data/app/<hash>/<hash>.com.attacker.manager/lib/<arch>/base.apk
This path satisfies KernelSU’s filtering criteria (i.e., it starts with /data/app), making it a viable target for signature spoofing during the authentication process.
A PoC with the full attack is shown in the video below:
Limitations
It's important to note that this attack is only effective if the attacker’s application is executed before the legitimate KernelSU manager application. Once the official manager authenticates, its UID is temporarily cached by the kernel, and any subsequent requests from other apps—including malicious ones—will be denied.
That said, the attack remains practical under realistic conditions. For instance, if the device reboots and the attacker’s app starts before the legitimate manager, it can successfully authenticate and gain root access—achieving its objective before any safeguards are in place. This can be achieved by ensuring that the attacker’s application declares the RECEIVE_BOOT_COMPLETED permission in its manifest.
Wider Implications: Common Vulnerabilities Across Rooting Tools
Our analysis of KernelSU is just one example among many. Over the years, zLabs has examined a wide range of rooting frameworks—both well-known and obscure—and we've consistently identified severe flaws in their design and implementation. These vulnerabilities often arise from rushed development, lack of formal security reviews, and the inherent complexity of modifying privileged kernel behavior from user space.
In our experience, nearly every rooting framework contains at least one critical vulnerability at some point in its lifecycle. These issues typically stem from:
- Improper or missing authentication mechanisms between user apps and the kernel interface (e.g., weak passwords, hardcoded secrets, or lack of signature checks).
- Excessive trust in user-space input, without rigorous validation or sanitization.
- Insecure communication channels between manager apps and their associated kernel modules.
- Poor isolation and privilege boundaries, allowing unprivileged apps to invoke root-level actions via misconfigured hooks or exposed interfaces.
Examples from Other Tools
- APatch: Earlier versions of APatch used a weaker password authentication mechanism that, if abused, could lead any app to invoke privileged operations without user consent. The APatch developers strengthened it over time to make it secure.
- Magisk: A recent Magisk vulnerability (CVE-2024-48336) allowed local apps to impersonate Google Mobile Services and execute arbitrary code within the Magisk app, silently gaining root access without user interaction.
How Can Zimperium Help?
Rooting tools like KernelSU, APatch, SKRoot and Magisk offer powerful capabilities, but they also introduce serious security risks that are often underestimated or completely overlooked by users. These tools hook deep into the Android kernel, bypass standard security controls, and expose privileged interfaces to applications running in user space. While many of them implement some form of authentication, our research shows that these mechanisms are often fragile or flawed–especially during early stages of development–leaving an opening for attackers to escalate privileges and fully compromise the device. To evade detection by security-sensitive apps (e.g. banks), users often switch to newer or less-detectable rooting tools, unknowingly exposing themselves to real-world attacks. A single successful compromise is often enough for attackers to exfiltrate sensitive data or take control of the device.
Critically, users often trust these tools without realizing the long-term implications, including data leaks, unauthorized access, or remote exploitation. In fact, nearly every rooting solution we’ve analyzed has had at least one critical vulnerability in its lifecycle—some of which could be exploited silently, without any user interaction.
That’s why continuous analysis of these frameworks is a core part of our work at Zimperium’s zLabs. We actively monitor and reverse-engineer updates to stay ahead of new threats, uncover hidden attack paths, and help protect users—whether or not they’re aware of the risks they’ve accepted. Detecting and mitigating the presence of such tools in enterprise environments is not just recommended—it’s essential.
Zimperium’s Mobile Threat Defense (MTD) and Mobile Runtime Protection (zDefend) SDK provide on-device, real-time detection and response to threats introduced by rooting tools. Our solutions can identify and act on:
- Device rooted – Detects when the device has been rooted, even if the rooting method attempts to hide or obfuscate its presence.
- Hacking tool present – Flags known and unknown rooting utilities, reverse engineering tools and rooting managers.
- System tampering – Identifies unauthorized modifications to the OS, kernel, or security settings, including changes made to hide compromise.
- Malware detection – Uses on-device machine learning to detect both known and zero-day malware, including malicious APKs bundled with or delivered through rooting toolkits.
By combining these detection capabilities with automated policy enforcement—such as blocking access to sensitive apps or requiring step-up authentication—Zimperium enables organizations to mitigate the risks of rooting tools before they lead to device compromise or data loss.