On Root Detection Strategies for Android Devices

Raphael Bialon
Department of Computer Science, Heinrich-Heine-University Düsseldorf, Germany
raphael.bialon@hhu.de

Abstract—The Android operating system runs on the majority they are executed on and the confidentiality of communication
of smartphones nowadays. Its success is driven by its availability channels used.
to a variety of smartphone hardware vendors on the one hand, This can directly contradict with users enjoying the cus-
and the customization possibilities given to its users on the other
hand. While other big smartphone operating systems restrict user tomizability of their devices, as one popular method to enable
configuration to a given set of functionality, Android users can broad control over ones’ device is the act of gaining elevated
leverage the whole potential of their devices. This high degree privileges through a process called rooting.
of customization enabled by a process called rooting, where the As our main contribution we propose a method for remote
users escalate their privileges to those of the operating system, rooting detection in wireless tethering networks provided by
introduces security, data integrity and privacy concerns. Several
rooting detection mechanisms for Android devices already exist, an Android device. Such networks define a special case of
arXiv:2012.01812v1 [cs.CR] 3 Dec 2020

aimed at different levels of detection. This paper introduces wireless networks, as all communication is routed over the
further strategies derived from the Linux ecosystem and outlines device offering the hotspot, and can thus be manipulated by
their usage on the Android platform. In addition, we present said device. One example for extensive tethering hotspot usage
a novel remote rooting detection approach aimed at trust and and a matching use case for this remote rooting detection is
integrity checks between devices in wireless networks.
Index Terms—Android, Smartphone, Rooting, Tampering, the application framework opptain [2]. Additionally, to lay out
Root Detection the options available for applications to secure that the envi-
ronment they run in allows for processing confidential data,
I. I NTRODUCTION we provide an overview of rooting methods, corresponding
mitigating actions, and present available options for rooting
Privacy and data integrity play an important role in digitized detection.
services people use in their every day lives. When using The remainder of this paper is structured as follows. We
such services, both the end user and the institution offering outline other publications related to our work, and reason on
the service have great interest in using secure communi- the placement of our work within existing research. Giving
cation channels and being able to verify the integrity of definitions of different types of rooting and their impacts,
the applications used. For those actions, smartphones have the third section defines the rooting methods we focus our
evolved to become popular devices to interact with digitized work on. In the next section, available rooting mitigations
services. Applications or so-called Apps aim at providing an and their prospective effects on device usability are stated.
immersive user experience and integrate deeply within the Those measures can impede the rooting process of a device,
operating system. Naturally, the aforementioned privacy and but as there is no guaranteed security as new exploits can
data integrity concerns apply to these applications, too. emerge any time, we list rooting detection strategies com-
The widely used Android operating system [1] allows a monly used by frameworks deployed on Android devices. We
large range of device vendors to more easily present a variety name additional rooting detection strategies aimed at a variety
of devices all using a common operating system. This open- of rooting techniques using existing functionality included in
ness has led to a global popularity of Android-based smart- either the Linux kernel or available applications. As our main
phones and other devices using the Android operating system. contribution, we then provide a novel strategy aimed at remote
It also allows users to gain higher levels of customization of root detection on devices connected to a tethering hotspot. We
their devices as compared to other competitors. conclude our paper by summarizing our work and depicting
Institutions offering digitized services provide applications the impact of our contribution regarding existing techniques
to be used on Android devices. For some applications, relying and rooting scenarios.
on the user to provide device security is sufficient, as no
private data may be processed and no sensitive information II. R ELATED W ORK
is communicated over the internet. Other applications, e.g. The process of privilege escalation and gaining root access
mobile banking applications, are in need of trusted execution on Linux- and UNIX-based devices exists since long before
platforms. If data processed by those applications can be the introduction of the Android operating system. Methods
obtained by malicious actors, serious consequences such as have been adapted to fit the altered environment provided
identity theft and fraud can occur. Those applications, but by Android. In this section, we give an insight on existing
also others having a common interest in data privacy and work focussing on rooting and impeding rooting on Android
protection, have to somehow ensure the integrity of the device devices.
 To give a general overview on available and applicable the detection mechanism itself has to have extended privileges.
rooting methods, several publications such as Yan et al. [3] Those rooting methods usually rely on a security flaw that can
and Sun et al. [4] describe a variety of different rooting options be exploited to elevate permissions.
for Android devices. 2) Hard Rooting: Hard rooting maintains root access
Vidas et al. [5] focus on attacks using rooting methods through persistent changes to the file system or a specific
and their impact on device integrity. Following their research, partition. This is usually done by flashing a custom firmware
having activated rooting techniques on a device leads to an or ROM to the device, voiding the device warranty in most
increased risk of further attacks and can enable malicious cases. The most prominent example is Magisk [7], which only
behavior by other applications. While we are well aware modifies the boot partition, leaving the Android system —
of this situation, we solely focus on the rooting process on usually located on another partition — as is.
devices without arguing on the usefulness and security impact
in general. B. Impact
With a variety of rooting techniques to choose from, appli- Once a device has been rooted, the Android environment has
cations aimed at mitigating rooting exploits also have to make to be seen as compromised. Previously secure data channels
use of a large repertory of counter-measures. This arms race may leak data now [8]. Application data can be manipulated,
between new rooting techniques and mitigations is detailed in system functions can be replaced, and assumptions on return
the work of Nguyen et al. [6]. values and function behavior can differ from what was pre-
Our work provides an overview of the most common rooting viously assumed. This situation creates new challenges for
detection strategies and the rooting method they focus on. In determining the rooting status of a device.
addition, we provide further detection strategies enabled by The end user might not be able to identify the device
functionality of the Linux kernel, as well as a novel detection as rooted itself, as previous functionality can be continued
strategy aimed at remote devices connected to a tethering unaltered and additional, malicious processes can be run in
hotspot. the background without the need for any user interaction.
III. ROOTING T ECHNIQUES
IV. ROOTING M ITIGATION
Rooting an Android device can be done using a multitude of
techniques. Some rely on unwanted behavior of applications or Most Android smartphone vendors adapt the open-source
the operating system, while others follow established ways of Android operating system [1] to their needs. This can be
gaining higher privileges through tools provided by the device necessary to enable device-specific functionality or include
manufacturer or operating system developer. vendor branding. Sometimes, optimizations that should enable
For our work, we highlight the two main types of rooting sophisticated security functions are introduced, but often the
in the following and detail the differences in how privilege inverse is true as shown in [9].
escalation is executed and can be detected. As proposed by Google’s Project Zero, mitigation measures
and security functionality included in the Linux kernel should
A. Definition be used instead of “homemade” extensions. Prominent exam-
In this section we state a definition of when an Android ples are SELinux [10] and AppArmor [11]. Both strategies
device shall be called rooted. As Android as an operating are well-established in the Linux ecosystem and can thus be
system builds upon the Linux kernel, it supports a multi- applied on Android-based operating systems with little effort.
user concept with multiple distinct user roles and privilege Google continues to enable secure default configurations and
separation. A super user account, usually referred to as root, includes further and recent hardening techniques and tools in
has advanced permissions granted by the kernel. Usually, it can newer Android releases [12].
override permissions set by any other user and has access to A wide range of vendor specific mitigation measures, both
every system function. Regular apps, on the other hand, should in software and hardware, exist. While hardware-based mea-
be run from an unprivileged user account, restricting direct sures are hard or impossible to circumvent, software solutions
access to various functions of the kernel and other functions may not be of as high quality as features present in the Linux
and files offered by the operating system. kernel. This is due to vendor capacity laid out on software
A device is called rooted, if an application originally run- architecture, testing and bug fixing to maintain a valid security
ning as an unprivileged user elevates its permissions to those measure.
of the super user, e.g., gained root access. One example of vendor-specific security hardening both
1) Soft Rooting: Soft rooting is usually not persistent across in hard- and software is Samsung Knox [13], a platform
device reboots. It could also be fixed through software updates. offering various security techniques and tools. As mentioned
Root access gained by soft rooting is hard to detect as in Section II, there is an arms race between the development of
there are no changes to the file system. By investigating new rooting techniques and mitigations. For older versions of
the behavior and permissions of currently running processes, Samsung Knox, some attack vectors such as the one mentioned
those using some sort of soft rooting can be detected. As this in [14] exist and provide well documented instructions for
detection mechanism relies on inspecting foreign processes, achieving elevated privileges.
 Concluding, mitigation measures do not prevent security One prevalent open source detection app and library is
flaws per se, but can limit the exploitable surface offered RootBeer [16]. Its rooting detection methods include those
through security flaws. listed in [17], which are part of our outline in the following.
Another framework broadly used on Android devices is
V. ROOTING D ETECTION Google’s SafetyNet [18]. This framework is deeply integrated
into the operating system and collects information on a de-
With the development of rooting techniques, detection
vices’ state locally. This information is then submitted to a
mechanisms have evolved, too. Applications handling sensitive
common backend, where device behavior can be observed in
data, such as financial applications or those associated with the
an aggregated way. Google does not disclose methods used for
health sector, are in a dire need of verifying the environment
rooting detection, but we assume at least some overlap with
they are run in as to not leak any sensitive data to unknown
the methods presented below.
others.
1) Installed Packages: Most rooting applications are in-
While rooting techniques either work or fail, detecting root
stalled as regular Android packages, i.e. regular apps. The
access cannot give a distinct answer. If evidence for achieved
easiest approach to detect if a device is possibly rooted is
root access can be found, the detection mechanism can clearly
accordingly to check if known rooting apps are installed.
state that the examined environment has been rooted. If, on the
2) su binary and other installed applications: The su
other hand, no evidence can be detected, the only assumption
application commonly found in Linux environments allows the
that can be taken is that no evidence for a rooted environment
execution of commands and applications with the permissions
was found — it could still be rooted, but not leaving any traces
and privileges of another user. If such an application can
behind that the detection mechanism in use can identify.
be found, the user can utilize this application to elevate its
We state that this statement is true for all rooting detection
privileges and gain root access.
mechanisms, as the root account and associated privileges are
Other applications not found on regular Android environ-
a part of how the kernel runs the system and will always be
ments can be installed by the rooting application. If such an
existent. Therefore, a rooting detection mechanism can only
application can be found and the user is permitted to access
search for indications of these privileges made available to
and execute it, this also indicates the presence of a rooting
a regular user. These checks run within the possibly rooted
application.
environment and can be deluded by other mechanisms of
3) Directory permissions: Most rooting applications mod-
the rooting software. Examples of such cloaking applications
ify permissions of system directories, giving access to other
are Magisk [7] and [15]. These applications conceal files,
users than those permitted regularly. On regular Android
directories and processes most commonly evaluated by root
environments, applications should not be able to examine
detection applications. As cloaking applications also only
the contents of other applications and processes, but instead
define a predetermined list of actions, rooting detection mech-
communicate through interfaces provided by the environment.
anism applications can advance their detection mechanisms by
If access to other applications and data belonging to other ap-
including the latest indications not yet covered by the cloaking
plications or personal directories for which the user explicitly
applications. This leads to an arms race between cloaking and
has to grant permissions can be found, another indication of
detecting applications as described in [6].
a rooted environment is found.
In the following, we outline common rooting detection
4) Inspecting available processes: This method is sub-
methods already in use by Android applications. Afterwards,
stantially different to the aforementioned methods, as it can
we detail additional sophisticated rooting detection methods
only be employed while a rooting technique is active. Three
and introduce a remote rooting detection strategy.
possible methods for detecting an active rooting mechanism
or manipulated processes are outlined in [19]. These methods
A. Common Rooting Detection Methods
focus on static checks on application integrity as well as
The most common rooting detection methods listed below behavior analysis. For analyzing foreign processes and appli-
can be found in open source applications as well as in cations, an elevated privilege level is needed by the application
proprietary applications. While it is straightforward to obtain conducting the analysis. In general, examining differences in
knowledge of those methods used by open source applications, device behavior after a rooting attack has been carried out is
the methods used in proprietary applications might differ or of greater interest, as it is not time-bound to the moment of the
extend those listed here, as analyzing their processes is more attack. Most applications in need for rooting detection can only
complex and may not even be permitted. examine the environment during the time they are executed,
Most rooting detection mechanisms only work for devices so the other methods are the most commonly chosen.
using a soft rooting technique, as they rely on changes in the
Android environment as indications for their detection mecha- VI. A DDITIONAL D ETECTION S TRATEGIES
nisms. Hard rooting techniques introduce elevated privileges in In addition to the detection methods detailed in Section V,
early stages of the system booting and therefore enable access we conducted research on further detection strategies. Those
to otherwise unavailable functionality without leaving traces strategies build upon existing functionality of the Linux kernel
in the Android environment. and additional programs and were evaluated for their use
 16

4000 400
14

12
Response time in ms

Response time in ms

Response time in ms
3000 300

10
2000 200
8

1000 100 6

4
0 0
0 20 40 60 80 100 0 20 40 60 80 100 0 20 40 60 80 100
DNS request DNS request DNS request

(a) rooted Samsung Galaxy S4 (b) rooted Samsung Galaxy S5 (c) stock Samsung Galaxy S5
Figure 1. DNS request and response measurements, three runs of 100 samples each

program and possibly change instructions or register values

Listing 1
F UNCTION OVERRIDE EXAMPLE FOR F O P E N during runtime. This approach enables a broader cloaking
FILE * f o p e n ( c o n s t char * p a t h , methodology, as not only a predefined list of functions and
c o n s t char * mode ) { system calls can be intercepted, but function return values can
i f ( s t r s t r ( p a t h , " t e s t " ) ! = NULL) { be inspected and modified to increase the amount of rooting
r e t u r n ( FILE * ) −1; indications successfully cloaked.
} else {
1) Detection strategy: To identify if a process is traced by
FILE * ( * o r i g _ f o p e n )
( c o n s t char * , c o n s t char * ) ; ptrace, the process itself can try to call the ptrace system
o r i g _ f o p e n = dlsym (RTLD_NEXT , " f o p e n " ) ; call on itself. By definition, only one process can attach and
r e t u r n ( * o r i g _ f o p e n ) ( p a t h , mode ) ; trace a process. If there is already another process attached, the
} process itself can evaluate the return value of its own ptrace
}
call to see if it was successful.
Some rooting techniques may also ptrace the init process
to tamper with the whole Android environment. Detecting such
within the Android operating system. In the following we attempts can be hard to impossible, as every own attempt to
present the method of rooting the given strategy can detect attach to the process to verify its integrity can lead to the
as well as an outline of how the detection strategy works. process being detected as manipulated by other measures.
A. Detecting custom linked libraries
VII. R EMOTE S IDE -C HANNEL ROOT D ETECTION
Using library preloading [20], we can inject a custom library
into any process we start. For our tests, we replaced the All previously stated rooting detection strategies have to be
function fopen as can be seen in Listing 1. This function is run on the device assumed rooted. For some use cases where a
usually called to open files from the file system. For our root device needs to verify the integrity of another Android device
detection mechanism, we return an invalid call when trying to it communicates with, those local rooting detection strategies
open the file test and simulate regular function behavior for cannot be applied. From an outside perspective, analyzing any
all other calls. This test file can then be changed to files known internal information of a remote device relies on information
to be related to rooting and further checks and preventions can provided by that device. Verifying the integrity of a remote
be introduced at the time of access. A detailed investigation on device therefore relies on additional applications installed on
the impact of library preloading on Android devices is given the remote device, which in addition have to assure a secure
in [21]. transmission of integrity check results. And on top, gaining
1) Detection strategy: We conclude that without further remote insight on internal information can also be a security
checks, e.g. a signature-based approach for verifying the risk, as the scope of information gathered has to be restricted
integrity of shared libraries, applications handling sensitive so that no access to private or personal information can be
data should access critical functions by using statically linked obtained.
approaches. Our proposed rooting detection strategy focuses on the use
case of opportunistic hotspot networking as presented in [2].
B. Detecting process tracing and tampering To reduce the needed trust and to focus only on the local
In the previous section, we countered tampering of library device, instead we investigated available services of devices
functions which were replaced upon program start. Using participating in a hotspot network, i.e., over Wi-Fi. Using
ptrace [22], a Linux system call to trace processes, a root nmap [23], we scanned the devices listed in Section VII-A
cloaking mechanism can intercept every instruction of a traced for available services. The results showed that only DHCP
 Table I For the rooted and stock version of Samsung Galaxy S4,
AVERAGE DNS REQUEST DURATION AND STANDARD DEVIATION no significant difference between our measurements was ob-
served. Measurements on the rooted Samsung Galaxy S5 show
Device Measured Average (ms) Standard Deviation (ms)
a clear distinction to those on stock configuration. On the
S4 rooted 258.01 131.28 rooted device, DNS query measurements are over two times
404.02 520.37
318.38 32.17 higher than on the stock device. We foreclose error introduced
S5 rooted 16.13 43.61 by our Python script, as the overhead generated by running
13.40 38.99 the script is consistent between 0.3 to 0.4 ms and therefore
14.47 45.21
S5 stock 5.90 1.64 too small to be considered.
6.15 2.11 Coming back to the aforementioned difference between cold
5.58 0.86 and warm starts of a device, the rooted and stock S5 did
not show any measurable difference when running our script
against a freshly restarted device compared to a device that has
and DNS were available for remote devices within the hotspot been left running for some time. On the S4 on the other hand,
network. These two services provide local address distribution the average in measured DNS response delays was more often
and global domain name resolving, both are necessary for around 4 to 6 ms on freshly restarted devices, whereas on a
participants of the hotspot network to be able to access it longer running device it occurred in the region around 140 ms.
for further internet access. One of the most feasible and non- This behavior is consistent on rooted and stock devices and
intrusive methods is the analysis of behavior of those regular has to be taken into account when deriving information from
services offered by the device. measurements for root detection.
Multiple measurements can be obtained and evaluated by
again different metrics. As proposed in [24] and [25], time VIII. C ONCLUSION
measurements are one promising method of gaining knowl- In this paper we have shown the motivation and meth-
edge on a device’s internal behavior. We build our rooting de- ods behind Android device rooting and noted the security
tection strategy upon timing measurements using the available implications introduced by rooting. An insight on security
DNS service, which is described in the next section. measures the Android operating system offers, and further
frameworks and technologies made available by Google and
A. Measurement Setup other vendors was given. We reasoned that those measures are
We utilized four devices for our evaluation: Samsung often not completely enabled due to end user convenience or
Galaxy S4 and S5, using a rooted and stock configuration delays in patch adaption by vendors. We gave an overview
each. Other devices, a Huawei Y3 and HTC Desire 510, on existing and widely-used rooting detection mechanisms
were also examined, but no significant difference between and frameworks, and evaluated additional rooting detection
rooted and stock versions were observed. Each device runs strategies.
a vendor adapted version of Android, which — besides the As our contribution, we introduced a supplementary remote
rooting on two devices — has not been modified. No additional rooting detection strategy for use in wireless networks Android
applications were installed as the tethering hotspot can be devices participate in. This strategy makes no assumptions
created using system tools. on available measures on the evaluated device other than
For our measurements, we conducted a series of runs for default services within a created tethering hotspot being avail-
each device separately using the same laptop device as our able. Making it harder for the inspected device to expose
measurement machine to achieve comparable results. Also, an the ongoing rooting detection, we showed that through our
environment showing no other wireless networks on regular measurements we can clearly distinguish between rooted and
network scanning was chosen. Interference between other stock configuration Samsung Galaxy S5.
networks and the device’s hotspot network is reduced this For general rooting detection, we elect Google’s SafetyNet
way. All devices have been left running for some time for the as the most promising framework. It obtains an integration into
following measurements to simulate a warm start as compared the Android operating system which is not available for other
to a cold start, which we will inspect later. apps, as it is integrated by the operating systems’ maintainers.
Using the python script1 , we measured the time it took One concern is the submission of locally sourced data to
the hotspot device to receive and answer a PTR request for Googles’ services for further analysis and detection decision,
8.8.8.8.in-addr.arpa.. For each device in stock and which occurs in a non-transparent way.
rooted configuration, three runs of 100 queries each were Finally, we conclude that rooting detection might not be
conducted. a deterministic decision-making process, as assumptions on
The results are shown in Figs. 1a to 1c and an overview of device environment may not always hold (e.g., they’re ma-
the averages and standard deviation of each run can be seen nipulated by malicious applications having gained elevated
in Table I. privileges). The best result one strategy can offer is therefore a
tendency between rooted and not rooted, not a binary definite
1 https://github.com/hhucn/android-dns-sidechannel decision.
A. Future Work [8] L. Casati and A. Visconti, “The dangers of rooting: data leakage
detection in android applications,” Mobile Information Systems, vol.
With new mechanisms for rooting Android devices continu- 2018, 2018.
ously developed as well as counter-mechanisms, new research [9] (Dec 2020) Project Zero: Mitigations are attack surface, too.
input will be available for the foreseeable future. [Online]. Available: https://googleprojectzero.blogspot.com/2020/02/
mitigations-are-attack-surface-too.html
Remote side-channel root detection, as initially shown by [10] (Dec 2020) Security-Enhanced Linux in Android | Android Open Source
our findings, is one particular topic which can reveal greater Project. [Online]. Available: https://source.android.com/security/selinux/
use in the methods of detecting rooted Android devices. Ex- [11] C. Cowan, S. Beattie, G. Kroah-Hartman, C. Pu, P. Wagle, and V. D.
Gligor, “SubDomain: Parsimonious Server Security.” in LISA, 2000, pp.
tending the evaluated scenarios onto further Android devices 355–368.
from a larger variety of vendors has to be conducted in order to [12] (Dec 2020) Google Online Security Blog: System hardening in
gain deeper insight to general behavior of remotely available Android 11. [Online]. Available: https://security.googleblog.com/2020/
06/system-hardening-in-android-11.html
services which might be affected by rooting. We chose DNS [13] L. Samsung Electronics Co., “Samsung Knox Security
queries as our investigated service, while tethering hotspots Whitepaper,” Samsung Research America, Tech. Rep., May 2017.
on Android smartphones offer additional services as DHCP [Online]. Available: https://images.samsung.com/is/content/samsung/p5/
global/business/mobile/SamsungKnoxSecuritySolution.pdf
and hotspot participants can also use different protocols like [14] D. Shen, “Defeating samsung knox with zero privilege,” BlackHat USA,
ICMP Echo Ping. The relevance of those features has to 2017.
[15] (Dec 2020) devadvance/rootcloak: Open source module for Xposed
be examined, too. We believe that additional conclusions on Framework that hides root from specific apps. [Online]. Available:
device integrity can be derived from the analysis of remotely https://github.com/devadvance/rootcloak
available services. [16] (Dec 2020) scottyab/rootbeer: Simple to use root checking Android
library and sample app. [Online]. Available: https://github.com/scottyab/
ACKNOWLEDGMENTS rootbeer
[17] (Dec 2020) Android Root Detection Techniques. [Online]. Available:
The author of this paper would like to thank Dorian Eiken- https://blog.netspi.com/android-root-detection-techniques/
berg for his work on the mentioned and utilized software con- [18] (Dec 2020) Protect against security threats with SafetyNet | Android
tained in the Github repository, and conducted measurement Developers. [Online]. Available: https://developer.android.com/training/
safetynet
scenarios. [19] W.-J. Jang, S.-W. Cho, H.-W. Lee, H.-i. Ju, and J.-N. Kim, “Rooting
attack detection method on the Android-based smart phone,” in Pro-
R EFERENCES ceedings of 2011 International Conference on Computer Science and
[1] (Dec 2020) Android Open Source Project. [Online]. Available: Network Technology, vol. 1. IEEE, 2011, pp. 477–481.
https://source.android.com/ [20] (Dec 2020) ld.so(8): dynamic linker/loader - Linux man page. [Online].
[2] A. Ippisch and K. Graffi, “Infrastructure mode based opportunistic net- Available: https://linux.die.net/man/8/ld.so
works on android devices,” in 2017 IEEE 31st International Conference [21] N. S. Evans, A. Benameur, and Y. Shen, “All your root checks
on Advanced Information Networking and Applications (AINA). IEEE, are belong to us: The sad state of root detection,” in Proceedings
2017, pp. 454–461. of the 13th ACM International Symposium on Mobility Management
[3] H. Yan, “Methods for avoiding rooting in Android System,” 2017. and Wireless Access, ser. MobiWac ’15. New York, NY, USA:
[4] S.-T. Sun, A. Cuadros, and K. Beznosov, “Android rooting: Methods, Association for Computing Machinery, 2015, p. 81–88. [Online].
detection, and evasion,” in Proceedings of the 5th Annual ACM Available: https://doi.org/10.1145/2810362.2810364
CCS Workshop on Security and Privacy in Smartphones and [22] (Dec 2020) ptrace(2): process trace - Linux man page. [Online].
Mobile Devices, ser. SPSM ’15. New York, NY, USA: Association Available: https://linux.die.net/man/2/ptrace
for Computing Machinery, 2015, p. 3–14. [Online]. Available: [23] (Dec 2020) Nmap: the Network Mapper - Free Security Scanner.
https://doi.org/10.1145/2808117.2808126 [Online]. Available: https://nmap.org/
[5] T. Vidas, D. Votipka, and N. Christin, “All your droid are belong to us: [24] D. Brumley and D. Boneh, “Remote timing attacks are practical,”
A survey of current android attacks.” in Woot, 2011, pp. 81–90. Computer Networks, vol. 48, no. 5, pp. 701–716, 2005.
[6] L. Nguyen-Vu, N.-T. Chau, S. Kang, and S. Jung, “Android rooting: An [25] B. B. Brumley and N. Tuveri, “Remote timing attacks are still practical,”
arms race between evasion and detection,” Security and Communication in European Symposium on Research in Computer Security. Springer,
Networks, vol. 2017, 2017. 2011, pp. 355–371.
[7] (Dec 2020) GitHub - topjohnwu/Magisk: A Magic Mask to
Alter Android System Systemless-ly. [Online]. Available: https:
//github.com/topjohnwu/Magisk