Android Rooting: Methods, Detection, and Evasion

∗
San-Tsai Sun Andrea Cuadros Konstantin Beznosov
University of British Columbia Universitat PolitÃĺcnica de University of British Columbia
Vancouver, Canada Catalunya Vancouver, Canada
santsais@[Link] Barcelona, Spain beznosov@[Link]
andreac@[Link]

ABSTRACT 2014 [25]. Android security controls restrict users and appli-
Android rooting enables device owners to freely customize cations (a.k.a. “apps”) from obtaining root privileges (i.e.,
their own devices and run useful apps that require root privi- full device administrative access), which could be abused or
leges. While useful, rooting weakens the security of Android misused to compromise the security of the entire system. In
devices and opens the door for malware to obtain privileged order to freely explore or customize full system functionali-
access easily. Thus, several rooting prevention mechanisms ties, many Android device owners voluntarily perform root-
have been introduced by vendors, and sensitive or high-value ing to remove root access constraints placed by stock An-
mobile apps perform rooting detection to mitigate potential droid devices [27, 20]. Rooting is a process of allowing device
security exposures on rooted devices. However, there is a users to attain a persistent privileged control (i.e., “root” ac-
lack of understanding whether existing rooting prevention cess) to the device. The de-facto way to achieve this persis-
and detection methods are effective. To fill this knowledge tent root access is by installing a custom su binary (known as
gap, we studied existing Android rooting methods and per- “switch user”, “super user”, or “substitute user”) that allows
formed manual and dynamic analysis on 182 selected apps, any app on the device to perform privileged operations as
in order to identify current rooting detection methods and root (details in Section 3). Once the device has been rooted
evaluate their effectiveness. Our results suggest that these (i.e., custom su installed), the device user can remove re-
methods are ineffective. We conclude that reliable meth- strictions placed by carriers and hardware manufacturers,
ods for detecting rooting must come from integrity-protected alter or remove system applications, run paid apps for free,
kernels or trusted execution environments, which are diffi- or enjoy useful root apps (i.e., apps that requires root privi-
cult to bypass. leges), such as backup and restore, firewall, tethering, or full
anti-malware functionality.
In this paper, by “rooting a device” we refer to the in-
Categories and Subject Descriptors stallation of a modified su binary on a device. This work
D.4.6 [Security and Protection]: Access controls, Inva- focuses on the study of those apps that detect widely de-
sive software ployed su distributions installed voluntarily by the device
owners. The detection and prevention of the malware that
exploits system vulnerabilities, in order to obtain and persist
General Terms root access, are out of this paper’s scope.
Security Although useful to device owners, rooting weakens the se-
curity of Android devices. Without rooting, malware must
Keywords exploit a system or kernel vulnerability present in the system
in order to gain root access, which could be technically chal-
Android Rooting; Privileged Malware lenging. However, on a rooted device, any app could simply
ask the user for root access with one-line of code (e.g., Run-
1. INTRODUCTION [Link](“su”)). The security of a rooted device relies solely
on the device user regulating root access properly. Yet, the
Android is the most popular mobile operating system, ac-
research shows that many users ignore security warnings due
counting for about 80% of global mobile devices market in
to habituation or lack of contextual information [23, 35].
∗The author was visiting the University of British Columbia A usability study of Android permissions also showed that
when this work was conducted. most participants were not able to properly understand and
grant Android permissions [24]. Once root access is inad-
Permission to make digital or hard copies of all or part of this work for personal or
vertently granted, malware could gain unauthorized access
classroom use is granted without fee provided that copies are not made or distributed to any sensitive data stored on the device, intercept user
for profit or commercial advantage and that copies bear this notice and the full cita- inputs, tamper with runtime code (e.g., circumvent security
tion on the first page. Copyrights for components of this work owned by others than controls, intercept file IO and network communication), and
ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- manipulate inter-app communications.
publish, to post on servers or to redistribute to lists, requires prior specific permission Rooted devices are prevalent. According to a recent An-
and/or a fee. Request permissions from Permissions@[Link].
SPSM’15, October 12, 2015, Denver, Colorado, USA.
droid security report [27], Google Verify Apps detected root-
c 2015 ACM. ISBN 978-1-4503-3819-6/15/10 ...$15.00. ing apps (i.e., apps that root the devices via privilege-
DOI: [Link]

3
escalation vulnerabilities) installed on approximately 2.5M We tested RDAnalyzer against apps examined in the ex-
devices, and particularly about 3-4% of Chinese devices have ploratory study, and revised it whenever a new rooting de-
a rooting application installed. Note that the number does tection method was uncovered. After this formative study,
not include other rooting methods (e.g., unlockable boot- we conducted a confirmatory study by analyzing 152 apps
loader, bootable SD card, OEM flash utilities). In addi- downloaded from Google Play.
tion, Verify Apps found that there are numerous applica- Our investigation of Android rooting methods found that
tions from major Chinese corporations that include rooting existing mechanisms for preventing rooting can be circum-
exploits to provide functionality that is unavailable through vented by an advanced su daemon started at boot time.
the official Android API. Moreover, in China, 80% of cheap The su daemon could be installed through pre-boot rooting
Android phones are shipped with customized system images methods (e.g., unlockable bootloader, bootable SD card),
that allow root access by default [20]. Furthermore, popu- and those rooting options would most likely remain avail-
lar community-built system images (e.g., CyanogenMod [2]) able for device users, so long as “freedom of customization”
and root apps (i.e., apps that require root access such as is embraced by device vendors. In addition, we found that
Titanium Backup [15], Root Explorer [12]) each has over 10 due to the confinement of privileged system daemons by SE-
million downloads. Android, vendor-specific kernels and device drivers would
Several rooting prevention mechanisms (e.g., mount sys- be the next main targets of those rooting apps that rely on
tem partition with nosuid option [28], drop setuid call capa- privilege-escalation vulnerabilities for rooting.
bility [28], SEAndrod [34]) have been introduced by Google For rooting detection, we found a wide variety of tech-
in Android versions 4.3 and later. Yet, as we show in this pa- niques used by the studied apps. Besides obvious rooting
per, some rooting techniques bypass these countermeasures. traits (e.g., su binary, SuperSU app), various Java/C APIs
To reduce the risks of potential security exposures on and shell commands are leveraged by apps to find a wide
rooted devices, mobile apps with sensitive or high-value func- range of rooting traits exhibited in different parts of the
tions therefore perform rooting detection and disable their system. These rooting traits range from files and packages
functions, if the device appears to be rooted. Unfortunately, installed during and after rooting, to directory permissions,
it is still common for the developers of root cloakers (i.e., suspicious processes, background tasks, system properties,
apps that evade rooting detection) to engage into arms race and even to the logo of a target app or over-the-air (OTA)
with the rooting detection methods [22]. update certificates.
This raises an immediate concern regarding the effective- Unfortunately, current methods for detecting rooting are
ness of rooting prevention and detection methods employed. not effective; they can be evaded, as we demonstrate with
Clearly, reliable rooting detection is desirable. There is, our RDAnalyzer. As such, existing root cloakers could be
however, a lack of understanding of how various rooting easily improved to evade all current rooting detection meth-
methods work and what rooting detection methods could ods. Our study also suggests that the “arms race” between
be difficult to evade. Our work aims to answer the following the developers of rooting detectors and cloakers is heavily
research questions to bridge this knowledge gap: asymmetric—the detectors are sandboxed while the cloak-
ers are armed with root privileges. Ultimately, mobile apps
• RQ1: What methods are currently available for de- need a reliable rooting detection method provided by the
vice users to perform Android rooting, and how do mobile OS. Based on the results of our investigation, we call
those rooting methods circumvent the rooting preven- for a reliable rooting detection API provided by Android
tion mechanisms employed? OS.
• RQ2 What are traits exhibited on a rooted Android
To summarize, this work makes the following contributions:
device?
• RQ3: What methods are used by existing mobile apps • We studied Android rooting methods and developed
to detect rooting traits? their taxonomy that systemizes scattered knowledge
about them. We also investigated how existing rooting
• RQ4: How effective existing rooting detection methods
prevention controls are circumvented.
are?
• We conducted a first empirical study to understand
To answer these research questions, we first studied and existing rooting detection techniques on Android.
tested existing Android rooting methods to understand how • We evaluated the effectiveness of the existing rooting
they work and what traits distinguish a rooted device. Next, detection techniques with a dynamic analysis tool that
we conducted an exploratory study by reverse-engineering 30 we built. Our results suggest that all rooting detection
apps that contain rooting detection logic, to gain an overall methods we found can be evaded.
understanding of existing root detection techniques. Manual
code inspection, however, is pronged to human errors and The rest of the paper is organized as follows: We provide
hard to scale, because detection logic could be obfuscated background and describe related work in Section 2. Section 3
or written in native code (C/C++). In addition, it would presents the methodology and results of our investigation of
not allow us to evaluate the effectiveness of the detection rooting methods, and Section 4 discusses existing detection
techniques. methods and evasion techniques. The implications of our
Informed by the insights obtained from the exploratory findings and limitations are discussed in Section 5. We con-
study, we developed a tool for dynamic analysis of rooting clude in Section 6.
detection methods. Named RDAnalyzer, it hooks a set of
APIs, both in Java and native code. For each hooked API, 2. BACKGROUND AND RELATED WORK
our analyzer logs the input parameters, and manipulates Root access restrictions. Android security prevents
the output of the API attempting to evade the detection. users and apps from obtaining root privileges [36]. First,

4
Android Open Source Project (AOSP) releases and stock Verified Boot [29] establishes a chain of trust from the
Android devices allow only a small subset of core system ser- bootloader to the system image, and thus it is able to prevent
vices to run with root privileges. Second, each app installed unauthorized alterations to boot and system partitions (e.g.,
on an Android device is constrained by Android’s security rooting). However, Verified Boot has not been deployed by
sandbox. Upon installation, each app is assigned a unique most Android devices, as it requires changes to the OTA
Linux-level user id (uid), and its privileges are restricted update mechanism (e.g., switching from file-level to block-
within the uid-based process boundary through Linux’s Dis- level updates).
cretionary Access Control (DAC). Thus, an app can only RootGuard [33] is an enhanced root-management system
access resources within its own sandbox (i.e., app local stor- that provides fine-grain control (rather than “all” or “noth-
age) and cannot interact with other apps by default. To ing”) for users to grant the requested permissions to an app.
gain system resources access (e.g., GPS, network, contacts), The permission policy is based on system calls and parame-
apps must declare their required permissions which need to ters invoked by an app. Similarly to SE Android, RootGuard
be granted by users during installation.1 Note that the de- monitors system calls made by root apps to detect and pre-
fault su binary shipped with Android Engineer (eng) build vent abnormal behavior of apps (i.e., malware) with root
allows only root and shell users to invoke it. privileges. Nevertheless, as acknowledged by the authors,
Persistent rooting mechanism. The de-facto mecha- attackers might employ kernel rootkits or exploit kernel or
nism for device users to obtain a persistent root access is device driver vulnerabilities to circumvent RootGuard.
by installing a custom su binary [19, 30, 32] that can be Usability of root management. Current root-
executed by all apps and commands on the device. When management model relies on users to grant root access to
the custom su is invoked, it checks whether the calling app apps, but it’s well known among usable security researchers
has been granted root access by the user via a root privilege that average users are either uncapable or unmotivated to
management app [19, 30, 32] (denoted as “SuperSU” in this consider carefully and make informed decisions about grant-
paper). If the access has been granted, su calls setuid(0) ing root privileges to an app. Many users ignore security
system call to switch the current process user to root and warnings due to habituation or lack of contextual informa-
then executes the input command under root privileges. We tion [23, 35]. Felt et al. [24] show that only 3% of Internet
found that, for Android versions 4.3 and later, due to the savvy and 24% of laboratory study participants are able to
rooting prevention mechanisms introduced by Google, su successfully understand and grant permissions, while 42%
does not call setuid system API anymore. Instead, su for- of participants are unaware of permissions at all. Kelley
wards the received command to an su daemon for execution et al. [31] performed twenty semi-structured interviews to
(see Section 3.3.2 for more details). explore Android users’ feelings about and understanding of
Risks of rooting. Vidas et al. [36] survey privileged permissions, and their findings are aligned with the results
access attacks in the early Android platform (2011), includ- of Felt et al. [24].
ing rooting. Our work presents the current state of rooting
methods and analyzes how su has been advanced to circum- 3. INVESTIGATING ROOTING METHODS
vent current rooting prevention mechanisms.
We started with a qualitative investigation of the methods
Vulnerabilities in the su binary and SuperSU app could
employed for rooting Android devices and getting around
be exploited by malware to gain root access as well. Several
various countermeasures that are supposed to make rooting
implementation bugs in su were uncovered (CVE-2013-6774,
difficult, if not impossible. We systemized our understand-
CVE-2013-6775, CVE-2013-6770), which allow any app ex-
ing in a form of a taxonomy of those methods.
ecute commands as root without a user permission [18]. In
addition, Shao et al. [33] demonstrate that SuperSU’s policy 3.1 Methodology
database and the local socket file could be attacked by mal-
To understand what methods are available for device users
ware to obtain root privileges. Moreover, Zhang et al. [38]
to root their Android devices (RQ1) and what traits are
show that privileged malware can retain its escalated per-
exhibited on a rooted device (RQ2), we studied and tested
missions even after the user unroots the device. Further-
existing Android rooting methods from various sources. In
more, Zhou et al. [39] show that 37% of malware leverage
particular, we used XDA Developers website [37], a popular
root-level exploits to fully compromise Android.
source for rooting related-information. We studied forums
Rooting Prevention and Protection. SEAndroid pro-
dedicated to particular models of Android devices, to un-
vides mandatory access control (MAC) to enforce sandbox-
derstand various rooting-related topics, e.g., rooting tools,
ing on Android system [34] and middleware [17] levels. Smal-
instructions, trouble-shooting, custom ROMs, drivers. We
ley et al. [34] demonstrate that SEAndroid is able to stop
found that the information in those forums rich but not
critical steps of a privilege-escalation exploit and prevent
comprehensible, and sometimes, confusing. Further inves-
abusing root privileges even if system daemons are compro-
tigation revealed that there are typically multiple ways to
mised. However, SEAndroid could be circumvented through
obtain temporary root access for a given device, and there
pre-boot rooting methods or kernel vulnerabilities (e.g., fu-
might be dependencies among those temporary root access
tex by TowelRoot). According to 2014 Android security re-
mechanisms. In addition, for a given temporary root access
port [27], about 0.6% of devices had SELinux fully disabled
mechanism, there are multiple rooting packages available in
and 0.3% of devices had SELinux configured in permissive
different forms. To build a complete view, we analyzed each
mode. Our investigation uncovers how SEAndroid is cir-
rooting method found, and developed a taxonomy to clar-
cumvented (details in Section 3.3.2).
ify the relationships between various rooting-related compo-
nents.
1 We also studied su source code and its over-the-air (OTA)
Please note that Android platform has been expanded in
version Android M to include runtime permissions. update packages from three primary su distributions [19, 30,

5
Figure 1: Taxonomy of Android Rooting Methods: The relationships between boot sequence, temporary root
access mechanisms and su installation packages.

32]. This allowed us to understand how su works and how “pre-boot” group, require making the device’s bootloader to
it overcomes the security protection mechanisms placed by boot into (1) a special bootloader mode or (2) a custom re-
Google. We found that only Chainfire’s su distribution [30] covery OS, or (3) boot from an external bootable SD card.
works on devices with SEAndroid [34] in enforcing mode, Alternatively, “post-boot” rooting methods are employed af-
but the distribution is closed source. ter the device has been fully booted, and all of them require
first to obtain a root shell. They do so through either (4)
3.2 Taxonomy of Android Rooting Methods an exploitation of privilege-escalation vulnerabilities, or (5)
The de-facto way for device users to attain a persistent root a privileged Android Debug Bridge (ADB).
access is by installing a custom su binary that allows any Depending on which temporary root access mechanism is
app on the device to perform privileged operations as root. used, there are different types of su packages available for
However, users cannot simply download or copy su over on device users to facilitate the process of installing and con-
to their devices. First, the system partition needs to be figuring su (e.g., OTA update package, custom system or
remounted as read-writable in order to install the su bi- boot images, bundled with the rooting apps). The main al-
nary and its related files on to system folders (e.g., /sys- teration targets of rooting methods are the boot partition
tem/xbin/). Second, any program that calls the setuid (e.g., alter configurations in the RAM disk) and the sys-
system call is required to have its SUID bit set (e.g., via tem partition (i.e., install su). We describe existing rooting
chmod u+s command), which indicates to the operating sys- methods in the rest of this section.
tem that the program is allowed to escalate its runtime priv-
ileges to root. Furthermore, for Android versions 4.3 and 1. Fastboot/Download mode: An unlockable bootloader
later, several system files need to be altered in order for the typically supports a special mode (e.g., fastboot [5] or down-
su daemon to be launched at boot time (further discussed in load [10] mode) that allows users to unlock the bootloader
Section 3.3.2). All these operations require temporary root and flash custom images using tools such as fastboot [5] or
access. The ways of obtaining such access can be divided ODIN [10]/heimdall [6] (for Samsung devices), through a
into two groups, depending on whether the access is gained USB connection from a host machine. For security reasons,
during or after the boot process. “unlocking” a bootloader will typically trigger device fac-
When an Android device is powered on and starts to boot, tory reset (i.e., reformat the userdata and cache partitions)
a low level, hardware specific program called “bootloader” to ensure that a malicious OS image cannot get access to the
is executed. The main purpose of a bootloader is to find existing user data. Once the bootloader has been unlocked,
and start the Android OS, or alternatively, the recovery OS. there are several ways to install su:
Many Android devices (e.g., Nexus, HTC, Motorola XOOM,
Android One, Samsung) are shipped with an “unlockable” Replace system partition: One easy way to enable per-
bootloader, which allows device users to flash (i.e., write sistent root access is to flash a custom system image
raw partition image to the device’s persistent storage) cus- that has su already installed on it (e.g., Cyanogen-
tom system, recovery or boot images, or boot from transient Mod [2]). Alternatively, if the user wants to use the
boot or recovery images, without flashing them to the device. existing system image on the device, he/she could sim-
On the other hand, some Android devices do not have an ply pull the stock system image from the device (e.g.,
unlockable bootloader. Only those boot and recovery im- using dd command) onto a host machine, install and
ages signed by the manufacturer can be loaded by locked configure su, repackage it, and then flash the new sys-
bootloaders. tem image back to the device.
As illustrated in Figure 1, we have identified five tem-
porary root access mechanisms that device users could use Alter boot partition to enable root shell: The user id
to install a custom su binary on their devices. Based on under which an ADB shell runs on the device depends
whether the bootloader is unlockable or not, they are cate- on the value of system property [Link]. If [Link]
gorized into “pre-boot” or “post-boot” groups. Methods in equals 0, an ADB shell will run as root; otherwise,

6
 the shell will run as a non-privileged user (e.g., shell ). files to their intended locations in the file system via the
The value of this property is set at boot time, based cp_perm helper function. Function cp_perm is a shell func-
on the [Link] file located in the boot parti- tion that copies (cp) a source file to a target destination,
tion. By unpacking and repacking a boot image with and then (1) changes the owner (chown) to root, (2) sets
[Link]=0, one can make the ADB daemon run as permissions (chmod), including SUID bit of su, and (3) con-
root and enable root access via a root shell. figures SELinux security label of the target file (labeled as
system_file). Note that in addition to su and SuperSU
Boot from a transient boot image: An Android boot im- app, a script called by init to install OTA updates (i.e.,
age consists of a Linux kernel and a RAM disk. The [Link]) is overwritten by the update script,
RAM disk is a small partition image that contains a which allows daemonsu to be invoked by init at boot time.
root filesystem (i.e., rootfs) mounted as read-only by Furthermore, the tool (supolicy) used by daemonsu to patch
the kernel at boot time. Once the rootfs is mounted, SELinuc policy at boot time is copied as well (details are in
the first Linux process init will be started to mount Section 3.3.2).
the rest of file systems from the devices, and then per-
form initialization procedures based on the configura-
tion files (e.g., [Link]). By creating a boot image 3. Bootable SD Card: Bootloaders of some devices (e.g.,
that contains customized commands and scripts, one Nook Color, WonderMedia tablets) support booting from an
can therefore install su into the system partition, or external bootable SD card. By creating a bootable SD card
even flash custom system images, by booting the de- that contains a customized RAM disk (e.g., accompanied
vice from a custom boot image. with the su binary and an update script similar to the one
shown above), one could install su into the system partition
Flash a custom recovery OS: Recovery OS is a minimal by booting the device from the SD card.
Linux OS that consists of a Linux kernel, a RAM disk
with various low-level executables and configuration
4. Rooting apps or tools. For devices that do not have
files, and a recovery program. A stock recovery OS
an unlockable bootloader, root access can be obtained by
is used to apply post-ship system updates delivered in
exploiting a system or kernel vulnerability. A privilege es-
a form of over-the-air (OTA) update packages. OTA
calation exploit, typically packaged into “one-click” rooting
packages include updated system files and a script that
apps or scripts, allows an app or script to start a root shell
applies the updates. Stock recovery OS typically only
to install su or modify system configurations. Many popu-
allows applying OTA update packages signed by the
lar one-click rooting tools exploit one or more vulnerabilities
device manufacturer. Nevertheless, since the recovery
found in the kernel (e.g., futex by TowelRoot, mem wrtite
OS is stored in a partition similar to system and data
by Mempodroid), device drivers (e.g., PowerVR SGX driver
partitions, device users can replace it with a custom
by levitator, Qualcomm diagnostic driver by diagroot), or
recovery OS, once a temporary root access has been
system daemons (e.g., adbd by RAtC and bin4ry, zygote by
obtained. All existing su distributions provide instal-
Zimperlich, init by psneuter and KINTO, vold by Zergrush
lation packages in a form of OTA update packages.
and GingerBreak) to install su for a persistent root access.

2. Custom recovery. A popular and flexible way to in- 5. Privileged ADB. The [Link] system property con-
stall su is via an OTA update package applied by a cus- figured in [Link] determines the process uid under
tom recovery OS (e.g., ClockworkMod Recovery [1], Team which an ADB shell is running. When the value is set to
Win Recovery Project [14]). An OTA update package can 1 (i.e., secure mode), the adbd daemon process, which ini-
add or alter system files without replacing the entire sys- tially runs as root, drops all capabilities from its capabil-
tem image, and thus the installed su can coexist with the ity bounding set, except CAP SETUID and CAP SETGID,
stock OS on the device. Note that the updater script for the and then changes its UID to AID SHELL (UID=2000) be-
OTA update is usually written in a special edify script lan- fore spawning an ADB shell. Certain manufacturers, and
guage [26]. However, we found that all su OTA packages use Android engineering (eng) builds, do not set [Link] to
traditional UNIX shell, so that the same installation script secure mode, which allows users to have a shell that can ex-
can be reused by other rooting methods (e.g., bootable SD ecute any program as root. With a root shell from ADB,
card, privileged ADB, one-click rooting apps). A snippet one can upload su and its installation script to a temporary
of su installation script from Chainfire’s distribution [30] is folder on the device, and then execute the script from that
shown below. folder to persist su.

mount -o rw,remount /system /* remount system as writable */

---snip--- /* place files and set permissions*/
3.3 Privileged Operations via su
cp_perm 0 0 06755 <src>/su /system/xbin/su Once su and SuperSU app have been properly installed,
cp_perm 0 0 0755 <src>/su /system/xbin/daemonsu any app on the device can invoke su to run arbitrary com-
cp_perm 0 0 0644 <src>/[Link] /system/app/[Link]
cp_perm 0 0 0755 <src>/supolicy /system/xbin/supolicy mand with root privileges. In this section, we discuss how
cp_perm 0 0 0755 <src>/[Link] su is used by apps to perform privileged operations. This
/system/etc/[Link] knowledge allows us to analyze rooting detection methods
/* content of [Link] */
#!/system/bin/sh
currently employed by various apps. It could also shed light
/system/xbin/daemonsu --auto-daemon & on future rooting detection and prevention techniques.
The update script first mounts the system and data par-
titions in read-write mode, and then copies the included 3.3.1 Android OS v4.2 and Earlier

7
 Figure 2: The sequence of invoking su by an app
to perform privileged operations on Android ver-
sions 4.2 and earlier. Dashed boxes denote process
boundaries.
Figure 3: The sequence of invoking su by an app to
perform privileged operations on Android versions
Figure 2 illustrates the data flow when su is invoked by an 4.3 and later. Dashed boxes denote process bound-
app in Android versions 4.2 and earlier: aries, and underlined labels denote security context
(domain).
1. An app invokes su binary through a shell. The input
command can be provided to su in the command line
directly (e.g., su -c cmd), or through standard input
piped from the calling app. Note that the app process to call setuid API [28], (2) dropping all capabilities, includ-
is always running under a unique uid assigned during ing call_setuid, from the capability bounding set for all
installation of the app. Android apps forked by the zygote process [28], and (3) con-
2. su performs a permission check by sending an autho- fining privileged processes with SEAndroid [34] mandatory
rization request. It starts with creating a local socket access control (MAC) policy.
under the SuperSU’s local folder, and sets the permis- Under SEAndroid (Android port of SELinux), each pro-
sions on the socket so that only SuperSU is allowed cess in the system is labeled with a security context (called
to access it. Then, su sends an intent message to Su- domain). When a process tries to perform an action on a
perSU, containing the path to this socket. Once Su- resource (called object in SEAndroid terminology), an ob-
perSU connects to this socket, su uses it to send an ject manager in kernel intercepts the requested action, and
authorization request that contains the package name checks the request against a centrally managed MAC policy,
and UID of the requesting app. in order to determine whether the request should be allowed
or not. Thus, on Android versions with SELinux in enforcing
3. SuperSU checks its policy database to determine whether mode, executing a process with root UID does not change
or not the requesting app has been granted root ac- its security context, and such a process is still constrained
cess by the user. If the root permission has not been by the SEAndroid MAC policy.
granted, SuperSU prompts the user for granting root Due to these new security constraints, persisting root ac-
permission to the app. cess is not as simple as copying an SUID binary to the de-
4. SuperSU returns to su the authorization decision, ei- vice. Although replacing the boot or system partitions al-
ther granting or denying the request. lows these security controls to be disabled and any security
5. If the root permission is granted, su calls setuid(0) mitigation to be reverted, such a radical approach is not de-
and setgid(0) to switch the uid of the current process sirable by the su developers. Thus, su has been re-designed
from the requesting app’s uid to root. to coexist with the new stock Android systems.
As illustrated in Figure 3, the original su has been sep-
6. su forks a new shell to execute the input command arated into an su and a su daemon (denoted as dae-
under root uid. monsu). The su binary does not call setuid API any
7 & 8. The output of the executed command is returned back more. Instead, it forwards all the requests received from
to the app through a standard output. apps to daemonsu, which runs as a daemon process with
root uid and init security context. To enable daemonsu
3.3.2 Android OS v4.3 and Later running under init domain, the su installation script mod-
For Android versions 4.3 and later, several security enhance- ifies the system in such a way that the daemonsu is in-
ments have been introduced to disallow apps from execut- voked by init so that it can inherit the domain of init (e.g.,
ing, or installing, the su binary. The security enhance- modify /system/etc/[Link], symlink /sys-
ments include (1) mounting system partition with nosuid tem/bin/app_process to /system/xbin/daemonsu, add an
option, which disables programs located on that partition init script to /system/etc/init.d/). In addition, daemonsu

8
patches the MAC policy during boot time to unconfine the the app’s package (APK), converted the APK into JAR us-
init domain and to allow su to connect to the local socket ing dex2jar [4], and then decompiled the JAR using both
created by the daemonsu. Note that the new su architecture JAD [8] and JD-GUI [9]. We manually analyzed the source
is backward compatible, and thus existing root apps can code to identify the root detection methods employed by
work with both versions of su without any modifications. these apps.
The data flow of an app performing privileged operations We observed that rooting detection functions are com-
via su in v4.3 and later is similar to the flow of v.4.2 and monly called from the launch activity of the app. For each
earlier (see Figure 2). The main difference is in how the rooting detection method identified, the API used by the app
domains of related processes are labeled. At boot time, the and its input parameters were documented. We found four
first process, init, sets its own domain as “init”. When init apps that perform rooting detection in native code, instead
launches zygote process, zygote’s security context is labeled of Java, and three other apps had their code obfuscated. We
automatically, according to the automatic domain transi- kept these apps for dynamic analysis in the formative study,
tion rule defined in the policy (e.g., type_transition init but did not attempt to reverse-engineer them any further,
zygote_exec:process zygote), and the type of zygote ex- as no new rooting detection methods were found after first
ecutable labeled during the system build process (e.g., la- 20 apps.
beled as zygote_exec). All Android apps are forked by zy- Manual analysis of the source code was valuable, allowing
gote process, and when an app is launched, zygote assigns us to understand what APIs and parameters are used by
the app to untrusted app domain, based on the app’s UID apps to detect rooting traits. Manual analysis, however, is
assigned during installation and a system configuration file neither effective nor scalable due to the following constraints:
(i.e., seapp_contexts). Note that when su is invoked by an
app, su inherits the domain of the app (i.e., untrusted app). • Manual source code inspection is a time-consuming
su then connects to a local socket of daemonsu. Upon re- and error-prone process (e.g., miss or mis-identifies a
ceiving the request, daemonsu forks a new process and then rooting detection method).
executes the input commands under root uid and init secu-
• Java code can be obfuscated before distribution, mak-
rity context.
ing it difficult to analyze.
In this section, we presented our findings on various root-
ing methods available for users, and how apps perform priv- • Native code (C/C++) used for rooting detection is
ileged operation through su. These technical details are es- compiled into machine code when the app is distributed.
sential for apps to detect whether a device has been rooted. • The effectiveness of the identified rooting method could
In the following section, we discuss what methods are used not be evaluated.
by current apps to perform rooting detection, and how those
detection techniques can be evaded. 4.1.2 Formative Study
To overcome the constraints of manual analysis, we devel-
4. DETECTION AND EVASION oped a tool, named “RDAnalyzer”, for semi-automatic dy-
Rooting traits are unique properties exhibited on a rooted namic analysis of rooting detection methods employed by
Android device. Depending on the rooting method employed apps. RDAnalyzer consists of two parts. The first part pro-
for rooting (e.g., OTA update packages, rooting apps), and vides user interface for configuration settings, such as the
what root apps or tools have been installed after rooting, list of targeted apps (specified in package name) and the
different traits will be exhibited. Thus, some rooting traits blacklisted rooting traits (e.g., file paths, package names,
are present on all rooted devices (e.g., su binary, SuperSU commands, keywords). The second part is an API hooking
app), while others only on some. In addition, rooting traits module that intercepts a set of API calls, both in Java and
could be present in different parts of the system (e.g., file native code. The list of hooked APIs and input parame-
system, process, package manager), and could be detected ters were initially gathered from the exploratory study and
via different API calls and commands. Rooting detection were revised throughout the confirmatory study (described
on Android devices is achieved today by examining different in the next section). The hooking module was implemented
parts of the system and checking whether one (or more) of as an extension of Cydia Substrate [3], a popular userland
these rooting traits can be found. When one of these rooting API hooking framework for both Android and iOS. Sub-
traits is detected, it is an indication that the device has been strate injects our hooking module into each app when the
rooted. app process is forked by the zygote process.
We first deployed RDAnalyzer to dynamically analyze apps
4.1 Methodology that were examined in the exploratory study. For each API
To evaluate the effectiveness of existing rooting detection hooked at runtime, RDAnalyzer logs the input parameters
methods, we conducted three empirical studies. Specifically, and manipulates the output of the API to evade detection.
these studies helped us to understand what detection meth- For instance, RDAnalyzer returns false when the app checks
ods used by existing mobile apps (RQ3), and whether and the existence of a file (e.g., /system/xbin/su), removes root-
how those detection methods can be evaded (RQ4). ing traits from the output of an API call, or throws an ex-
ception when a targeted shell command (e.g., “which su”)
4.1.1 Exploratory Study is executed. Whenever RDAnalyzer failed to evade a detec-
As a starting point, we conducted an exploratory study tion method, we reverse-engineered the corresponding app
by reverse-engineering 30 apps that contain rooting detec- to understand which APIs and input parameters should be
tion logic. The list of apps was obtained from a popular considered, and then revised RDAnalyzer to evade the newly
root cloaker website [22], which claims that those apps had discovered detection technique(s). To confirm whether RD-
been “successfully tested”. For each app, we downloaded Analyzer has successfully evaded an app’s root detection, we

9
inspect that app manually (e.g., message shows that “the de- positive (i.e., the app reports rooting even when the
vice is not rooted”, functions prohibited to run on a rooted device is not rooted). In the case it is not a false posi-
device is enabled when RDAnalyzer is activated). tive (which was the case for all the examined apps), we
reverse-engineered the app to find new detection meth-
4.1.3 Confirmatory Study ods. We then revised RDAnalyzer and tested the app
By applying RDAnalyzer to a sample of apps, we collected again, until all rooting detection methods employed by
data on the use of various detection techniques in the wild. the app were evaded successfully.
During this study, whenever we uncovered previously un-
known detection techniques, we revised RDAnalyzer accord- 4.2 Results: Detection Methods
ingly, and re-analyzed previously analyzed apps from the The results of the uncovered rooting detection methods are
sample. For each app, we recorded the detection techniques presented in this section. Using RDAnalyzer, all of the root-
it employed. The primary objective of this study was to ob- ing detection methods we discovered can be evaded. Figure 4
tain descriptive statistics about the use of rooting detection illustrates the distribution of detection methods used by the
techniques in the wild. apps in the confirmatory study, ordered by download popu-
To facilitate the collection of the sample apps in sys- larity from most (left) to least (right). Note that D4 (Check
tematic and reproducible way, we developed a tool, named System Properties) was identified in the exploratory study,
“APK downloader”, that automatically downloads apps from but none of apps in the confirmatory study used this detec-
Google Play based on query keywords. We selected apps tion method.
that (a) most likely have rooting detection logic in place, In the rest of this section, we discuss each of the seven
such as those that can be found on Google Play by search- detection techniques and the ways we were able to evade
ing for the query strings on free apps “root check” and “root them.
verify” with APK Downloader and (b) popular apps that
require the device to be rooted (e.g., backup, file manager) 4.2.1 D1: Check Installed Packages
that could be found in Google Play and third party app Certain apps packages are commonly installed during or af-
stores. ter rooting, for instance:
Overall, we selected 242 apps, out of which, we excluded
apps (1) whose description mentioned specifically that no 1. SuperSU app: An app that installed along with the su
root is required, (2) with UI in a language other than En- binary for users to regulate root access [19, 30, 32].
glish or Spanish, (3) that did not work properly (e.g., the app 2. Rooting apps: Apps that exploit privilege-escalation
could not be opened due to an error), (4) in which “root”, vulnerabilities to root the device (e.g., One Click Root,
“check” or “verify” in the description has a different meaning iRoot, Root Genius).
than Android rooting (e.g., “math square root”), (5) that are
designed for specific device models (e.g., Samsung Galaxy 3. Root apps: Apps that require root privileges for their
only), (6) with low popularity (i.e., less than 1,000 down- functions, such as BusyBox, SetCPU, Titanium Backup,
loads), and (7) that we considered not to be valid for analy- Wireless Tether, Adfree, ShootMe.
sis as we used them for rooting purposes (e.g., Busybox and 4. Root cloakers: Apps that hide the fact the device has
SuperSU ). Overall, we excluded 45 apps. At the end, 152 been rooted (e.g., Root Cloaker [22], Root Cloaker
apps were selected for analysis in the confirmatory study. Plus [21]).
We first downloaded all the apps’ apk and meta data (e.g.,
5. API hooking frameworks: Libraries that provide API
app description, popularity in number of downloads, cate-
hooking functions (e.g., Cydia Substrate [3], Xopsed
gory) for a certain query using APK Downloader. We then
Framework [16]).
proceeded to install all the apps on a rooted Nexus 7 de-
vice with Android version 4.2.1. We employed the following PackageManager is an Android Java class for retrieving
procedure for the analysis of each app: various kinds of information related to installed applica-
tion packages. This class is commonly used by the stud-
• Without activating RDAnalyzer, we launched one-by-
ied apps to check whether a specific app package that re-
one all the installed apps from the tablet. For each
quires root privileges is installed on the device. For instance,
app we inspected whether it detects that the device
getInstalledPackages or getInstalledApplications re-
has been rooted. We did this by (1) looking for visual
turn a list of all packages/applications that are installed on
indications that could appear on the screen (e.g., su
the device. The detecting app then iterates through the re-
permission prompt, message shows that “the device is
sults to see whether a specific package is presented. Other
rooted” or “the app is prohibited to run on a rooted
common used APIs are getPackageInfo and getApplica-
device”), and (2) testing app features that need root
tionInfo which retrieves overall information about an in-
and verifying if they work or not.
stall package/application.
• We then activated RDAnalyzer. We again launched We found that some PackageManager’s methods do not di-
one-by-one all the apps and looked for the indications rectly return an application/package information, but they
mentioned previously to confirm whether they detect are leveraged by apps to infer whether a given package is in-
that the device has been rooted. We also obtained the stalled or not. For example, getApplicationLogo retrieves
log generated by RDAnalyzer to classify the rooting the logo icon associated with an application, getLaunch-
detection techniques each app used. IntentForPackage returns an intent to launch a front-door
• If the analyzed app surpassed RDAnalyzer, we first in- activity in a package, and getPackageGids returns an array
stalled the app in an unrooted Nexus S with Android of all of the secondary group-ids that have been assigned to
version 4.1.2 to check whether the detection was a false a package.

10
 Evasion: For APIs that return a list of packages or ap- 4.2.5 D5: Check Directory Permissions
plications, RDAnalyzer calls the hooked function and then Some rooting tools make certain root folders readable (e.g.,
removes the target package names from the result before re- /data) or writable (e.g., /etc, /system/xbin, /system, /proc,
turning them to the app. For APIs that retrieve specific /vendor/bin) to any process on the device. The [Link]
information for an given package, RDAnalyzer returns null and canWrite Java APIs, or access C API can be used to
directly to falsely indicate to the app that the package does check whether such condition exists.
not exist. Evasion: If the target path is presented in the input pa-
rameter, RDAnalyzer simply returns false (e.g., not readable
4.2.2 D2: Check Installed Files or not writable) to the app.
The [Link] Java method, or access, open C APIs can
be used to check the existence of a file in the file system. 4.2.6 D6: Check Processes/Services/Tasks
Commonly checked files include the follows:
The [Link] method
• /system/xbin/su, system/bin/su. We found that some returns a list of currently running application processes.
apps manipulate the path attempting to confuse eva- This API is used by studied apps to check whether a spe-
sion (e.g., /system/xbin/../xbin/su). cific app that requires root privileges is running on the de-
• /system/xbin/busybox and all symbolic links of com- vice. Similarly, getRunningServices or getRecentTasks
mands created by busybox. APIs are also used by apps to retrieve a list of current run-
ning services or tasks respectively to check whether SuperSU
• /data/app/<APK name> or /system/app/<APK name>
and popular apps for rooted devices are running on the de-
of popular apps packages that are installed during or
vice.
after rooting.
Evasion: RDAnalyzer calls the hooked function and then
We found that some apps check APK files under /data/data/ removes the target names from the result before returning
directory, however, access to this directory are restricted by them to the app.
default for user installed apps.
Evasion: When the target file path is detected in the in- 4.2.7 D7: Check Rooting Traits Using Shell Com-
put parameter, RDAnalyzer calls the original hooked func- mands
tion with a fake file path that certainly does not exist (e.g., Shell commands are commonly used by studied apps to de-
/system/xbin/doesnotexist) as the input parameter. While tect aforementioned rooting traits. Apps can use [Link]
openat() and other related functions can be used to remove Java API, ProcessBuilder Java class, or execve C API to
full path names from the executable and refer to the file by execute a specified command in a separate process, and then
a file handle, RDAnalyzer or root cloakers could find the full examine the output of the shell command to detect rooting
path of the file, given the file handle. traits. Commonly employed shell commands are as follows:
4.2.3 D3: Check the BUILD tag
• su: If the su binary exists, this shell command will
By default, stock Android images from Google are built with exit without error; otherwise, an IOException will be
“release-keys” tag. If “test-keys” are presented, this can thrown to the calling app.
mean that the Android image on the device is either a de-
veloper build or an unofficial build. The follow code is used • which su: The which command outputs the full path
by apps to test whether the Android image on the device is of a specified command; in this case, the su command
an official build or not. (e.g., /system/xbin/su).
if () {//rooted} • ps | grep <target>: The ps command outputs a list
of the current running processes. The output of ps
Evasion: We examined the source code of [Link] can be piped through a grep command to search spe-
and found that this build tags information is a class-level cific app processes that requires root access (e.g., dae-
static final string retried from “[Link]” system monsu, SuperSu).
property through [Link] method. To mask
this value, RDAnalyzer uses Java reflection APIs to change • ls - <target>: ls command can be used to check the
it to “release-keys”. existence of a file in the file system.
Class _class = [Link]("[Link]"); • pm list packages: List all installed packages using
Field field= _class.getDeclaredField("TAGS"); the pm command to search for specific targets.
[Link](null, "release-keys");
• pm path <package>: Output the full path of the tar-
4.2.4 D4: Check System Properties geted package.
If the value of system property [Link] equals “0”, the
adb shell will be running as root instead of shell user. Sys- • cat /system/[Link] | grep [Link]: Check
[Link] Java API can be used by apps to examine whether [Link]=release-keys
this property value. We found that some apps also check if
“[Link]=1” and “[Link]=1”. Examining Evasion: RDAnalyzer (1) throws an IO exception if the
ADB source code reveals that the adbd daemon will be also input command involves su, or (2) removes target names
running as root user if both properties are set to one. from the command output by piping the input command
Evasion: RDAnalyzer hooks [Link] and through an invert-match grep command (e.g., | grep -v
returns “‘1” for [Link] property, and “0” for [Link] "su"), so that only non-matching lines are returned to the
and [Link] properties. calling app.

11
Figure 4: The distribution of rooting detection methods used by apps in the confirmatory study, ordered by
download popularity from most (left) to least.

4.3 Results: Detection Apps

In this section, we report on the results of our confirmatory
study. They are summarized in Figures 4 and 5. Our anal-
ysis of rooting detection apps revealed several interesting
aspects.
First of all, while we identified D4 in our exploratory
study, none of the apps we analyzed in the confirmatory
study employed this detection method. The popularity of
root detection apps did not correlate with the number of
the detection techniques they used, as can be seen from Fig-
ure 4. Almost 2/3 of the analyzed apps employed only 2-3
detection methods. Figure 6 illustrates the popularity of the
detection methods.

Figure 6: The popularity of detection methods. Y-

axes is the percentage of the analyzed apps, which
employed the method in question.

nate efforts to provide a unified way for mobile apps to query

the security state of a bootloader. In addition, records of
modifications made to the boot and system partitions should
be provided as well. It could be an interesting subject of
future research to investigate whether and how remote at-
testation with a strong hardware root of trust and other
techniques could be employed for supporting detection of
unlocked bootloader or even rooted device.
Impacts of SEAndroid on the targets of rooting
apps. Rooting apps need to exploit privilege-escalation
Figure 5: The employment of detection methods by vulnerabilities found in system daemons, kernel, or device
apps. It shows how many methods the analyzed drivers in order to persist root access. While SEAndroid
apps employed. could be circumvented by pre-boot methods, it can make
rooting apps difficult to exploit privilege-escalation vulnera-
bilities found in system daemons. In addition, Linux kernel
is compact and gradually stablized, and hence discovering
5. DISCUSSION new kernel vulnerabilities would be a challenging task, if
Pre-boot rooting v.s. freedom of customization. De- not impossible. Therefore, vendor-specific kernels and de-
spite the effort of security enhancements for preventing root- vice drivers would become the main targets of rooting apps
ing, pre-boot rooting methods (unlockable bootloaders in in the future, as they are implemented by a single party
particular) would probably remain available for device users and mostly closed source, without undergoing rigid security
to customize their devices. This is because one of Android’s review.
biggest selling points has always been its “freedom of cus- Asymmetric arms-race for rooting detectors. Our
tomization”, and installing a third-party Android build or study shows that the arms race between rooting detectors
useful root apps are attractive options for user. Besides cus- and evaders is an asymmetric competition that favors evaders.
tomizing the system, an unlockable bootloader may even be While detectors are sandboxed by Android security model,
the only way to run an updated version of Android on de- evaders are armed with root privileges that have full con-
vices that have stopped receiving updates from device man- trol over the device and, in theory, can bypass any security
ufacturers. This is probably the reason why most recent de- protection mechanism placed by vendors or manufacturers.
vices provide a way for users to unlock the bootloader and Even if detectors find new rooting traits or employ advanced
install custom builds or recovery OS. Nevertheless, from a detection techniques, evaders could always advance their
mobile app’s perspective, an unlocked bootloader is a strong techniques to evade the detection methods. Therefore, ul-
risk indicator. Once a bootloader is unlocked, all bets are off, timately, mobile apps need a reliable rooting detection API
the entire computing base of the device cannot be trusted provided by Android OS, with its implementation from a
anymore. Thus, vendors and manufacturers should coordi- trusted source, likely relying on hardware root of trust, e.g.,

12
integrity-protected kernels or external trusted execution en- son, which might employ such detection techniques that are
vironments. How such an API can certify correctness of the more difficult to evade. In addition, the majority of the
result is a subject of future research. apps in our sample were downloaded from Google Play, ex-
cept for a small number of popular root apps downloaded
5.1 Additional Observations from third-party app stores (because they are available only
During our studies, we also observed two new detection tech- there). We plan to address these limitations as part of a
niques that could complicate current root cloakers. These larger-scale version of the confirmatory study.
new techniques were tested against two popular root cloak- Rooting method samples. We used XDA Developers
ers [22, 21]. Forums as our primary source for studying existing rooting
Exception Call Stack Inspection. We found that methods. There may be other existing rooting methods from
Java exception call stack can be leveraged by apps to infer other sources that we are unaware of.
whether the device has been rooted. When performing root-
ing detection using a shell command via [Link]("su")
5.3 Future Work
or ProcessBuilder("su"), a Java IO exception will be thrown In addition to addressing the limitations of our current study,
to the app if the su binary does not exist. We found that we plan to conduct the following future work:
when the API has been hooked, the call stack will be differ- Understanding user’s risk perception of rooting.
ent. That is, when the API has been hooked, the hooking The security of a rooted device relies on the device user to
function will be presented on the top of the call stack, in- regulate root access properly. Thus, understanding user’s
stead of the hooked API (e.g., [Link]). Thus, apps mental model and risk perception of rooting could provide
could determine whether the API call has been hooked by informed design improvements to raise user awareness and
checking the function name on the top of an IO exception improve root-management functionalities.
call stack. If the API has been hooked, the device must Profiling root apps for reliable detection. Under-
be rooted because API hooking requires root privilege. To standing and characterizing the behaviours of root apps (e.g.,
evade this detection method, the root cloakers need to tam- system calls, objects accessed and actions) might shed lights
per with Java runtime in order to hide its trace left on the on runtime detection of rooted devices, and provide informed
IO exception call stack. design improvements for root-management apps.
Stateful rooting detection. We found that existing Hypothetically, a root detection approach can also look
rooting detection methods are stateless (i.e., detection is for telltale signs that the device was put in a configura-
solely based on the return value of a single API call), and tion state that allowed future (or past) installation of a root
therefore they can be evaded easily. Even when a new root- framework. While we did not find any approaches that do
ing trait has been discovered and used in detection, due to so, it could be part of future studies.
the simplistic nature of stateless detection mechanism, it is
trivial for root cloakers to evade it (e.g., by adding the new 6. CONCLUSION
traits to its configuration). To complicate evasion, a stateful This work uncovers the details of arm race between root-
rooting detection mechanism could be used. For instance, ing methods and prevention mechanisms, as well as rooting
an app can first create an interactive shell that will not detection and evasion techniques. By creating a taxonomy
trigger evasion (e.g., [Link](‘sh’), execv (‘sh’)). of the rooting methods, we found that despite the layers of
Once the shell object has been successfully obtained, the app several countermeasures that, besides other protections, are
then pipes detection commands (e.g., ls /system/xbin/su, supposed to resist rooting, pre-boot rooting methods would
which su) through the input stream of the shell object and remain as options for rooting so long as “freedom of cus-
examines the output to determine whether the device has tomization” is embraced by vendors. For rooting detection
been rooted. In order to evade this detection method, root and evasion, we found a wide variety of techniques used by
cloakers need to intercept both input and output streams of apps to detect rooted devices, but unfortunately, all rooting
the shell object. detection methods studied can be evaded. Our study results
suggest that, ultimately, a reliable rooting detection method
5.2 Limitations should be provided by Android OS, with rooting detection
App samples. In the course of our study, we observed logic implemented in the trusted parts of the system, such
that there are two general reasons why developers add root as integrity-protected kernels or external trusted execution
detection logic to an app. The first reason is to improve environments.
usability—to tell users whether their devices are rooted, to
warn users that their devices have not been rooted when
the app need root access to perform an action, or to display
7. ACKNOWLEDGEMENTS
different options to users based on whether the device has We would like to thank anonymous reviewers for their help-
been rooted. The second reason is for security—to protect ful feedback, which allowed us to improve the paper and our
sensitive or high value user data against the security impact research methods.
of having a persist root access on the device.
Intuitively, apps detecting root for usability reasons might 8. REFERENCES
need a lower quality of root detection than apps detecting [1] ClockworkMod Recovery. [Link] [Online;
root for user data protection. In the confirmatory study, accessed 29-May-2015].
we excluded paid apps and those apps that required hav- [2] CyanogenMod. [Link]
ing accounts that we were unable to register (e.g., banking, [Online; accessed 29-May-2015].
mobile device management apps). Most of those excluded [3] Cydia Substrate: The powerful code modification
apps might be performing rooting detection for security rea- platform behind Cydia.

13
 [Link] [Online; accessed SOUPS ’12, pages 3:1–3:14, New York, NY, USA,
29-May-2015]. 2012. ACM.
[4] Dex2Jar. [Link] [25] Garner Inc. Market Share: Devices, All Countries,
[Online; accessed 29-May-2015]. 4Q14 Update.
[5] Fastboot. [Link] 2014.
[Link] [Online; accessed 29-May-2015].
[Online; accessed 29-May-2015]. [26] Google Inc. Inside OTA Packages.
[6] Heimdall. [Link] [Link]
[Online; accessed 29-May-2015]. inside_packages.html. [Online; accessed
[7] iRoot. [Link] [Online; 29-May-2015].
accessed 29-May-2015]. [27] Google Inc. Android Security 2014 Year in Review.
[8] JAD: Java Decompiler. [Link] https:
[Online; accessed 29-May-2015]. //[Link]/media/source.
[9] Java Decompiler GUI. [Link] [Online; [Link]/en//devices/tech/security/reports/
accessed 29-May-2015]. Google_Android_Security_2014_Report_Final.pdf,
[10] ODIN. [Link] 2014. [Online; accessed 29-May-2015].
[Online; accessed 29-May-2015]. [28] Google Inc. Security Enhancements in Android 4.3.
[11] One Click Root for Android. [Link]
[Link] [Online; accessed security/enhancements/[Link], 2014.
29-May-2015]. [Online; accessed 29-May-2015].
[12] Root Explorer. [Link] [29] Google Inc. Verified Boot.
apps/details?id=[Link]. [Link]
[Online; accessed 29-May-2015]. security/verifiedboot/[Link], 2014.
[Online; accessed 29-May-2015].
[13] Root Genius.
[Link] [Online; [30] Jorrit Chainfire Jongma. How-To SU: Guidelines for
accessed 29-May-2015]. problem-free su usage. [Link]
2014. [Online; accessed 29-May-2015].
[14] Team Win Recovery Project. [Link]
[Link]/wiki/ClockworkMod_Recovery. [31] P. Kelley, S. Consolvo, L. Cranor, J. Jung, N. Sadeh,
[Online; accessed 29-May-2015]. and D. Wetherall. A Conundrum of Permissions:
Installing Applications on an Android Smartphone. In
[15] Titanium Backup. http: J. Blyth, S. Dietrich, and L. Camp, editors, Financial
//[Link]/[Link]. Cryptography and Data Security, volume 7398 of
[Online; accessed 29-May-2015]. Lecture Notes in Computer Science, pages 68–79.
[16] Xposed Framework. Springer Berlin Heidelberg, 2012.
[Link] [Online; accessed [32] Koushik Dutta. ClockworkMod Superuser.
29-May-2015]. [Link] 2014.
[17] S. Bugiel, S. Heuser, and A.-R. Sadeghi. Flexible and [Online; accessed 29-May-2015].
Fine-Grained Mandatory Access Control on Android [33] Y. Shao, X. Luo, and C. Qian. Rootguard: Protecting
for Diverse Security and Privacy Policies. In rooted android phones. Computer, 47(6):32–40, June
Proceedings of the 22nd Usenix Security Symposium 2014.
(Security 13), 2013.
[34] S. Smalley and R. Craig. Security Enhanced (SE)
[18] cernekee. Multiple Android Superuser vulnerabilities. Android: Bringing Flexible MAC to Android. In
[Link] Proceedings of the 2013 Network and Distributed
php?t=2525552, 2013. [Online; accessed 29-May-2015]. System Security Symposium (NDSS’13), 2013.
[19] ChainsDD. su binary for android Superuser. [35] J. Sunshine, S. Egelman, H. Almuhimedi, N. Atri, and
[Link] 2012. L. F. Cranor. Crying Wolf: An empirical study of SSL
[Online; accessed 29-May-2015]. warning effectiveness. In Proceedings of 18th USENIX
[20] China Internet Watch. 80% China’s Mobile Users Security Symposium, pages 399–432, 2009.
Rooted Smartphones in 2014. [36] T. Vidas, D. Votipka, and N. Christin. All your droid
[Link] are belong to us: A survey of current android attacks.
80-china-smartphone-users-rooted/, 2015. [Online; In Proceedings of the 5th USENIX Conference on
accessed 29-May-2015]. Offensive Technologies, WOOT’11, pages 10–10,
[21] devadvance. RootCloak. Berkeley, CA, USA, 2011. USENIX Association.
[Link] 2014. [37] XDA. XDA Developers.
[Online; accessed 29-May-2015]. [Link] 2015. [Online;
[22] devadvance. RootCloak Plus - Completely Hide Root accessed 29-May-2015].
from Apps. [Link] [38] Z. Zhang, Y. Wang, J. Jing, Q. Wang, and L. Lei.
[Link]?t=2607273, 2014. [Online; accessed Once Root Always a Threat: Analyzing the Security
29-May-2015]. Threats of Android Permission System. In
[23] S. Egelman, L. F. Cranor, and J. Hong. You’ve been Information Security and Privacy, volume 8544 of
warned: an empirical study of the effectiveness of web Lecture Notes in Computer Science, pages 354–369.
browser phishing warnings. In CHI ’08: Proceedings of Springer International Publishing, 2014.
the SIGCHI Conference on Human factors in [39] Y. Zhou and X. Jiang. Dissecting Android Malware:
Computing Systems, pages 1065–1074, New York, NY, Characterization and Evolution. In Security and
USA, 2008. ACM. Privacy (SP), 2012 IEEE Symposium on, pages
[24] A. P. Felt, E. Ha, S. Egelman, A. Haney, E. Chin, and 95–109, May 2012.
D. Wagner. Android Permissions: User Attention,
Comprehension, and Behavior. In Proceedings of the
Eighth Symposium on Usable Privacy and Security,

14