Android Mobile Root Detection – Snake Oil or Silver Bullet?

research vulnerability

Android is one of the most widely used mobile operating systems in the world. However, with its widespread use, it is also susceptible to security threats.

Root Detection

One of the most significant threats are root exploits that can compromise the security of an Android device. In a research project, SEC Consult wanted to find out, if current root detection libraries, used by applications dealing with highly sensitive information like banking applications, would detect if a device is compromised during runtime by a malicious application using a root exploit. The aim is to question the usefulness of root detection in general and discuss the different implementation possibilities.

In order to better understand this topic, our mobile security experts Hussam Cheaib and Fabian Densborn, will start by describing what rooting actually is, what different types of root exist and how or whether root detection actually works.

What is Rooting?

Rooting is the process of gaining administrative privileges or "root access" on an Android device. By default, Android devices are set up with restricted user accounts that have limited permissions. These restrictions prevent users from accessing certain system files and settings, which can help improve the security and stability of the device. Once a device has been rooted, the user has full control over the device, including the ability to install custom software, modify system settings, and access system files that were previously restricted. While rooting can provide users with greater control over their device, it can also come with risks. Rooting can potentially make the device more vulnerable to security threats, such as malware and other malicious software. There exist two different types of rooting that have to be distinguished:

User Root - Users rooting their own devices

For users who want more control over their device, rooting can provide a way to bypass these restrictions and gain full control over the operating system. Rooting essentially involves modifying the device's firmware or software in order to allow privileged access to the system files and settings. Rooting can be done through various methods, such as using a rooting tool or flashing a custom ROM (modified version of the Android operating system). Most of the time a gatekeeper application like Magisk will be installed to supervise access to those elevated privileges. In this scenario, users are aware of the rooted device because they have taken steps such as flashing the device themselves. They want to take advantage of the flexibility they get from rooting their own device. There exist a lot of artifacts on the device that can be used to detect that such a device is rooted, but as this root is intentional, most of the custom ROMs do not even try to hide such artifacts.

Malicious Root – An attacker compromising a victim’s device

Malicious root is often used by malware to get elevated root privileges without modifying the system in a way that it is easy to detect. Most of the times a kernel exploit is abused to escalate the privileges and the malware executes its malicious actions. Only a few artifacts, which could indicate the compromise of the system, are placed on the device as the malware tries to hide its malicious intention. This makes it almost impossible to detect malicious root, as with its high privileges, the malware can hide all of its tracks. Most malicious root exploits are temporary, i.e., they last only until the next reboot (but smartphones are not frequently rebooted anyways). However, there are also malicious root exploits that are able to reach persistence, some of them even surviving a factory reset of the smartphone.

Root exploits are essentially vulnerabilities that allow attackers to obtain root privileges on a device. Once attackers have gained root access, they can do anything on the device, including modifying system files, stealing data, and installing malware.

Most of the root exploits abuse a kernel vulnerability to get elevated privileges on the device. But for a successful exploitation many security features like SECCOMP or SELinux have to be circumvented first. Additionally, most of the root exploits need to be tailored to a specific device in order to work.

Root Detection

What is Root Detection?

Root detection is a technique used by some Android apps to determine if a device has been rooted. When an app is installed, it checks for signs of rooting, such as the presence of specific files or folders created during the process. If rooting is detected, the app may disable certain features that could be exploited by an attacker with root access or refuse to run entirely. The purpose of this process is to ensure the app runs on a device that hasn't been compromised, maintaining the default security measures of the operating system, such as keeping the private directory of an application only accessible to the app itself and preventing other apps from accessing its sensitive data.

How does Root Detection Work?

Root detection can work in a variety of ways, depending on the app and the specific techniques used. Some apps may simply check for the existence of certain files or folders that are created when a device is rooted. Others may use more advanced techniques, such as checking the device's kernel for modifications or analyzing the device's file system for signs of tampering. Some apps may also use a combination of different techniques to improve the accuracy of their root detection.

Most of the root detection libraries check the following things:

  • Are root management apps (e.g. like Magisk) installed on the device?
  • Are other potentially malicious applications installed?
  • Does the build tag contain test keys?
  • Has the device set dangerous device properties?
  • Is the busybox binary installed on the device?
  • Is the su binary installed on the device?
  • Is the system partition mounted as read write and not read-only?

Some applications even try to get the current SELinux mode the device is running in, but without special permissions, which are only accessible to system applications, this is not possible in modern Android versions.

How applications deal with Root Detection?

When an app detects that the device it is running on is compromised, there are different ways apps respond:

  1. Warning the User: Some apps may simply warn the user that they are operating on a rooted device, informing them about the potential risks.
  2. Restrict Functionality: Some apps may choose to restrict certain features if they detect that the device is rooted. For instance, a banking app may disallow transactions on a rooted device.
  3. Deny Access: In more extreme cases, an app may refuse to run altogether on a rooted device. This is common for applications that deal with highly sensitive data or transactions, such as banking or financial apps, certain games to prevent cheating, or streaming services to prevent piracy.

Proof of Concept: Do Root Detection Libraries detect Malicious Root?

To check whether applications that implement root detection mechanisms also detect malicious root exploits at runtime, we first had to identify possible exploit candidates for which a public Proof-of-Concept (PoC) exists.

During the research, the vulnerabilities with identifiers CVE-2019-2215 and CVE-2020-0847 turned out to be the most documented ones. For both vulnerabilities a PoC already exists, which allows us to exploit the kernel vulnerability and create a shell with root privileges at runtime.

Screenshot showing a successful root exploit that is not detected by the RootBeer Sample app.
Figure 1: Screenshot showing a successful root exploit that is not detected by the RootBeer Sample app.
Screenshot showing a successful root exploit that is not detected by the SuChecker app.
Figure 2: Screenshot showing a successful root exploit that is not detected by the SuChecker app.

Bad Binder Exploit - CVE-2019-2215

This vulnerability has been well documented by security researcher Maddy Stone

It allows a malicious installed application to gain root privileges on an Android device by exploiting a flaw in the Binder driver.

In order to exploit this vulnerability and check whether root detection libraries would detect this malicious root access, we first had to set up a device with a vulnerable kernel version. For that, we compiled our own kernel for Android 10 and reintroduced the vulnerability by undoing the commit that patched the vulnerability. Once we had reintroduced the vulnerability, we created an Android Virtual Device (AVD) and started it with our newly compiled kernel. We then used the available PoC root exploit to spawn a root shell from the Android Debugging Bridge (ADB). In this scenario we used ADB instead of a malicious application to trigger the exploit, as the ADB process is not secured with SECCOMP, which would be another hurdle to circumvent in order to successfully exploit the target device. Nevertheless, this does not impact the result of root detection libraries in any way. After getting root access to the device, we tried to access the private directory of installed applications. As expected, it was possible to read all privately stored files of the applications, including the shared preferences.

Next, we installed a number of applications that implement root detection mechanisms to see if they could detect the presence of the root exploit. Among others, we tested the following applications from which we know that they implement some form of root detection mechanisms:

  • Barclays Privatkunden
  • Snapchat
  • Instagram
  • RootBeer Sample APK
  • SuChecker

We found that none of the tested applications was able to detect the compromise of the device. The following screenshots show the RootBeer Sample app and the SuChecker app, which perform many root checks but fail to detect the rooted system, while the command line shows a successful root exploit with SELinux set to permissive.

RootBeer does not detect busybox binary on non-default locations.
Figure 3: RootBeer does not detect busybox binary on non-default locations.

However, to be on the safe side and verify our assumption, we also tested a second root exploit on a physical Android device.

Dirty Pipe Exploit - CVE-2020-0847

Also known as "Dirty Pipe", this vulnerability was discovered by Max Kellerman and allows all readable files on the system to be overwritten. This can be abused to overwrite system libraries and get code execution as root. There are further steps required to bypass SELinux restrictions, however, these are beyond the scope of this blog post.

This time we used a physical Google Pixel 6 device running Android 12 with security patch level from February 2020. Again, we used the existing PoC exploit to get a root shell on the device. To verify that we indeed got root permissions, we tried to read files from the private app directory as a quick sanity check. Afterwards we installed the applications we wanted to test on the device to check if they detect the compromised operating system.

Even on the physical device with a different exploit, the applications did not detect the compromised system. Although the exploit copies the "busybox" binary to the device it will not be detected by the root detection libraries because the binary is placed in a non-default location where installed applications don't have access to.

The following image shows that the root detection library RootBeer searches for the binary but was not able to find it:

What does that mean?

We analyzed the root detection mechanisms implemented by these applications to determine why they were not effective in detecting the root exploit. We found that most of these mechanisms were looking for root artifacts in certain locations that are only present in "user root" settings. Malicious exploits try to hide their tracks and as they have complete access to the device, they can just hide/change every property the root detection library is looking for. Once a malicious application has gained root access, it can do anything on the device.

That means, root detection mechanisms most of the times only detect "compromised" devices, where the users are aware of the fact that their devices are rooted and probably know about the security consequences. However, the real threat comes from malicious root access obtained by abusing known or unknown vulnerabilities. In such cases, the user is generally unaware of the fact that the device is compromised, and therefore oblivious to the consequences of using applications with sensitive data on that device.

Conclusion – Snake Oil or Silver Bullet?

Root detection can be a helpful measure to ensure that users of enterprise applications cannot bypass security measures of the app and that confidential data cannot be accessed by rogue apps. However it fails to detect a malicious compromise of the device. Overall, root detection should not be seen as a silver bullet. Here's why:

False Sense of Security: It's important not to be lulled into a false sense of security by simply implementing root detection. An organization or user may mistakenly believe they're protected from malicious threats, which is not always the case. Moreover, protective measures such as Data Loss Prevention (DLP) that prevents actions such as copying and pasting or taking screenshots can be better enforced through a centralized Mobile Device Management (MDM) system and well-defined policies. An MDM can continuously monitor the integrity of the operating system, whereas an application can only check the integrity while executing. If root detection is only embedded within individual applications, while the application may refuse to run on a rooted device, it doesn't inherently prevent a root user or attacker from accessing the stored data.

Efficacy and Use Cases: Users who root their devices are often seeking full control. Given their elevated privileges, a determined user can typically bypass most app root detection mechanisms. Therefore, for non-enterprise applications, a better approach may be to warn users of the potential security risks of using the application on a rooted device. This helps them make informed decisions. In enterprise environments, where device and data control is crucial, root detection can be beneficial in certain use cases, but for most use cases, greater security could be achieved through security features such as hardware-backed encryption, such as the Android Keystore, and step up authentication, such as biometrics.

Cost & Resource Allocation: Implementing root detection isn't free; it demands time, money, and technical resources for both development and rigorous testing. For consumer-facing apps, it may be more beneficial to channel these resources into a robust security architecture and regular penetration testing ("pentests"). Mobile security pentesting evaluates the security of an application and provides the necessary guidance to make the application as secure as possible, even in a potential compromise.

In a nut shell:

  • For end user applications we do not advise to implement root detection, but to focus on other security mechanisms and regular security assessments.
  • For enterprise applications, root detection should not be the main security mechanism, but can be a reasonable additional security measure. However, it would be more effective to implement this through a Mobile Device Management (MDM) solution.
  • In any case, it would be more advisable to enhance the security architecture of the application in such a way, that the data can be protected even if used on a compromised device.


This blog post has been written by Fabian Densborn and Hussam Cheaib and published on behalf of the SEC Consult Vulnerability Lab.

Are you interested in working at SEC Consult?

SEC Consult is always searching for talented security professionals to work in our team.