Rooting and jailbreaking frameworks are continually evolving, usually maintained by unbiased builders with out formal safety oversight. In consequence, they incessantly introduce unpredictable dangers that pose a severe and ongoing menace to enterprise safety by enabling malware infections, app compromise, and even full system takeovers.
At Zimperium’s zLabs, monitoring these instruments is a key a part of our menace evaluation workflow. This steady monitoring helps us keep forward of rising vulnerabilities and keep real-time consciousness of the evolving cell menace panorama, as cybercriminals transfer to a mobile-first assault technique.
Our findings constantly show that these frameworks current actual, exploitable dangers within the wild. On this weblog put up, we are going to current a technical evaluation of a vulnerability we initially found in mid-2023, illustrating how attackers might leverage it to fully compromise a rooted Android machine.
On this put up, we’ll cowl:
- How trendy rooting frameworks like KernelSU, APatch and SKRoot achieve root entry and escalate privileges.
- How an attacker might exploit one such vulnerability to achieve full management utilizing an internally developed proof-of-concept.
The Rise of Kernel Patching: How Fashionable Rooting Instruments Hook Deep into Android
Over time, quite a few strategies have been used to achieve root entry on Android units. Nevertheless, most up-to-date frameworks have converged on a standard technique: Android kernel patching, as seen in instruments like KernelSU, APatch and SKRoot.
This method entails hooking into key kernel features—both by hot-patching a pre-compiled kernel or instantly modifying the supply code. This permits these frameworks to intercept execution and run arbitrary code throughout the kernel. To bridge the hole between kernel house and person house, they sometimes hook particular system calls, creating covert communication channels to a supervisor app operating with regular person privileges. This app acts because the interface for managing permissions and controlling entry, together with its personal, regardless of not having elevated rights itself.
Whereas most trendy rooting instruments comply with comparable patterns in kernel integration, they differ considerably in how they deal with authentication.
The Hidden Weak Spot: Supervisor Authentication
As a result of system calls will be triggered by any app on the machine, sturdy authentication and entry controls are important. Sadly, this layer is usually poorly carried out—or fully uncared for—which opens the door to severe safety dangers. Improper authentication can enable malicious apps to achieve root entry and totally compromise the machine.
Password-Primarily based Authentication (A Frequent however Fragile Strategy)
Some instruments, similar to APatch and SKRoot, defend kernel interfaces utilizing a password—both auto-generated or user-defined throughout set up. Nevertheless, if the password is weak or the validation mechanism is flawed (e.g., susceptible to side-channel assaults), attackers could possibly bypass authentication, entry the basis interface, and escalate their privileges.
Bundle-Primarily based Authentication (Verifying the Caller’s Identification)
One other method, utilized by instruments like KernelSU, depends on package-based authentication. On this mannequin, the kernel verifies that it’s speaking with the legit supervisor app by checking package deal names, UIDs, or digital signatures. This methodology avoids counting on user-generated secrets and techniques and as an alternative enforces belief based mostly on the app’s id on the system.
Whereas package-based authentication will be extra sturdy than password-based strategies, it nonetheless calls for cautious implementation. With out correct signature checks or if mixed with permissive insurance policies, it too will be susceptible to spoofing or privilege misuse.
Within the subsequent part, we’ll discover how such spoofing assaults can enable a malicious app to impersonate the supervisor and achieve unauthorized root entry.
The Vulnerability
The primary vulnerability we’ll focus on was current in KernelSU model 0.5.7 (Git tag v0.5.7) and allowed an attacker to authenticate because the KernelSU supervisor.
KernelSU Supervisor Interface
To offer an interface between the supervisor app and the kernel, KernelSU hooks into the prctl system name—a syscall sometimes used to get or set varied attributes of the calling course of.
The usual perform signature of prctl is:
int prctl(int op, …);
Below regular utilization, the choice parameter specifies the operation to be carried out, and relying on that operation, the perform might take extra arguments.
For KernelSU, hooking into prctl presents a versatile and handy mechanism. It permits the supervisor software to cross arbitrary arguments to the kernel, enabling varied actions to be triggered based mostly on the enter. To route execution into its personal inner handler, KernelSU makes use of a predefined magic worth—0xDEADBEEF—as the primary argument. This worth alerts that the decision ought to be interpreted by the KernelSU handler moderately than the default prctl logic. It is adopted by a selected command code and non-obligatory parameters.
For instance, to retrieve the present KernelSU model, the supervisor app might invoke the next C code:
prctl(0xDEADBEEF, CMD_GET_VERSION, &version_buffer);
Be aware: These instructions are solely accepted when issued by an authenticated supervisor software. To achieve entry to the privileged interface, the app should first efficiently invoke CMD_BECOME_MANAGER. With out this preliminary step, all different instructions will likely be ignored or denied by the kernel.
Along with CMD_GET_VERSION, KernelSU helps quite a lot of different command choices, together with:
- CMD_ALLOW_SU – Manages an allowlist of app package deal names permitted to execute as root.
- CMD_SET_SEPOLICY – Permits modification of SELinux insurance policies.
- CMD_GRANT_ROOT – Grants root privileges to the calling course of.
- CMD_BECOME_MANAGER – Promotes the calling app to behave as the basis supervisor.
- …and lots of extra.
These instructions, routed via the prctl hook, give the supervisor app highly effective management over the rooted atmosphere—making safe authentication and validation completely crucial.
KernelSU supervisor authentication (v0.5.7)
The next code snippet, tailored from the unique KernelSU supervisor software, demonstrates how the system name is ready to request supervisor privileges. As mentioned within the earlier part, KernelSU leverages the prctl syscall and a selected command (CMD_BECOME_MANAGER) that permits an software to declare itself because the supervisor. Along with the command, a 3rd argument have to be handed to the kernel containing the trail to the calling app’s knowledge listing:
As proven above, the info listing path is constructed based mostly on the applying’s person ID. For purposes operating below the first person (UID < 100000), the anticipated prefix is /knowledge/knowledge/.
Kernel-Facet Verification Course of
Upon receiving this request, KernelSU performs a collection of checks to validate the authenticity of the caller:
- Parse and Validate the Supplied Path
The kernel copies the third argument and verifies that it begins with the anticipated prefix (/knowledge/knowledge or /knowledge/person/), based mostly on the calling app’s UID:
- Confirm Possession of the Goal Path
Subsequent, the kernel confirms that the folder specified within the path is certainly owned by the calling app:
As a result of the applying inherently owns this folder, the caller can simply cross this test.
3. Confirm the APK’s Signature
Lastly, KernelSU makes an attempt to confirm the id of the supervisor by analyzing the signing certificates of the calling course of’s APK:
This reliance on the primary base.apk discovered within the fd desk introduces a major weak spot, which would be the focus of the assault described within the subsequent part.
The Exploit
Within the following state of affairs, we assume an attacker-controlled software with the package deal identify com.attacker.supervisor. The purpose is to bypass KernelSU’s authentication checks and impersonate the legit supervisor software as a way to achieve root entry.
Passing the primary two checks is easy, as proven within the instance under:
// Request to turn out to be the supervisor by mimicking anticipated enter
const char* data_path = “/knowledge/knowledge/com.attacker.supervisor”;
int32_t end result = -1;
prctl(KERNEL_SU_OPTION, CMD_BECOME_MANAGER, data_path, nullptr, &end result);
Nevertheless, the ultimate test—verifying the signing certificates—is significantly more difficult and requires a inventive workaround.
As beforehand described, KernelSU performs signature verification by scanning the present course of’s file descriptor (fd) desk and inspecting the first file that matches the sample /knowledge/app/*/base.apk. If this file doesn’t comprise the anticipated signature, the authentication course of is instantly aborted.
This turns into an issue for an attacker: The primary matching base.apk entry will sometimes level to the attacker’s personal APK, which in fact doesn’t match the signature of the official supervisor. To bypass this, the attacker must trick the kernel into studying the legit supervisor’s APK as an alternative.
This may be achieved by manipulating file descriptor ordering, making certain the supervisor’s base.apk seems earlier within the fd desk than the attacker’s personal APK.
Steps to Carry out the Assault
- Determine the fd of the attacker’s personal base.apk.
- Find a free file descriptor with a decrease worth than the one present in step 1.
- If no free fd is accessible, shut stdin (fd 0) and reuse it.
- Open the official KernelSU supervisor’s base.apk.
To facilitate step 4, the attacker should bundle the official KSU supervisor APK with their very own software. One sensible location is the app’s lib listing, which usually resolves to a path like:
/knowledge/app/
This path satisfies KernelSU’s filtering standards (i.e., it begins with /knowledge/app), making it a viable goal for signature spoofing through the authentication course of.
A PoC with the total assault is proven within the video under:
Limitations
It is necessary to notice that this assault is barely efficient if the attacker’s software is executed earlier than the legit KernelSU supervisor software. As soon as the official supervisor authenticates, its UID is briefly cached by the kernel, and any subsequent requests from different apps—together with malicious ones—will likely be denied.
That stated, the assault stays sensible below sensible circumstances. As an illustration, if the machine reboots and the attacker’s app begins earlier than the legit supervisor, it could actually efficiently authenticate and achieve root entry—attaining its goal earlier than any safeguards are in place. This may be achieved by making certain that the attacker’s software declares the RECEIVE_BOOT_COMPLETED permission in its manifest.
Wider Implications: Frequent Vulnerabilities Throughout Rooting Instruments
Our evaluation of KernelSU is only one instance amongst many. Through the years, zLabs has examined a variety of rooting frameworks—each well-known and obscure—and we have constantly recognized extreme flaws of their design and implementation. These vulnerabilities usually come up from rushed improvement, lack of formal safety evaluations, and the inherent complexity of modifying privileged kernel conduct from person house.
In our expertise, practically each rooting framework accommodates not less than one crucial vulnerability sooner or later in its lifecycle. These points sometimes stem from:
- Improper or lacking authentication mechanisms between person apps and the kernel interface (e.g., weak passwords, hardcoded secrets and techniques, or lack of signature checks).
- Extreme belief in user-space enter, with out rigorous validation or sanitization.
- Insecure communication channels between supervisor apps and their related kernel modules.
- Poor isolation and privilege boundaries, permitting unprivileged apps to invoke root-level actions through misconfigured hooks or uncovered interfaces.
Examples from Different Instruments
- APatch: Earlier variations of APatch used a weaker password authentication mechanism that, if abused, could lead on any app to invoke privileged operations with out person consent. The APatch builders strengthened it over time to make it safe.
- Magisk: A latest Magisk vulnerability (CVE-2024-48336) allowed native apps to impersonate Google Cellular Providers and execute arbitrary code throughout the Magisk app, silently gaining root entry with out person interplay.
How Can Zimperium Assist?
Rooting instruments like KernelSU, APatch, SKRoot and Magisk provide highly effective capabilities, however additionally they introduce severe safety dangers which are usually underestimated or fully missed by customers. These instruments hook deep into the Android kernel, bypass customary safety controls, and expose privileged interfaces to purposes operating in person house. Whereas a lot of them implement some type of authentication, our analysis exhibits that these mechanisms are sometimes fragile or flawed–particularly throughout early levels of improvement–leaving a gap for attackers to escalate privileges and totally compromise the machine. To evade detection by security-sensitive apps (e.g. banks), customers usually change to newer or less-detectable rooting instruments, unknowingly exposing themselves to real-world assaults. A single profitable compromise is usually sufficient for attackers to exfiltrate delicate knowledge or take management of the machine.
Critically, customers usually belief these instruments with out realizing the long-term implications, together with knowledge leaks, unauthorized entry, or distant exploitation. The truth is, practically each rooting resolution we’ve analyzed has had not less than one crucial vulnerability in its lifecycle—a few of which may very well be exploited silently, with none person interplay.
That’s why steady evaluation of those frameworks is a core a part of our work at Zimperium’s zLabs. We actively monitor and reverse-engineer updates to remain forward of latest threats, uncover hidden assault paths, and assist defend customers—whether or not or not they’re conscious of the dangers they’ve accepted. Detecting and mitigating the presence of such instruments in enterprise environments is not only beneficial—it’s important.
Zimperium’s Cellular Risk Protection (MTD) and Cellular Runtime Safety (zDefend) SDK present on-device, real-time detection and response to threats launched by rooting instruments. Our options can determine and act on:
- Gadget rooted – Detects when the machine has been rooted, even when the rooting methodology makes an attempt to cover or obfuscate its presence.
- Hacking software current – Flags identified and unknown rooting utilities, reverse engineering instruments and rooting managers.
- System tampering – Identifies unauthorized modifications to the OS, kernel, or safety settings, together with modifications made to cover compromise.
- Malware detection – Makes use of on-device machine studying to detect each identified and zero-day malware, together with malicious APKs bundled with or delivered via rooting toolkits.
By combining these detection capabilities with automated coverage enforcement—similar to blocking entry to delicate apps or requiring step-up authentication—Zimperium allows organizations to mitigate the dangers of rooting instruments earlier than they result in machine compromise or knowledge loss.