A Novel approach for bootkit detection in Android
Platform
1st Khireddine Garri
Institut National de Criminalistique et de Criminologie
Universitdes Sciences Technologie Houari Boumediene
Algiers, Algeria
dine.garri@gmail.com
Abstract—Detection of Malware in Android is already a
challenging task, even worse Bootkits add more complexity and
because it shifts the infection to the early stage of system’s
booting, it makes it more stealthy and by far more persistent.
In this paper, we discuss the challenge of malware analysis and
detection in Android mobile phones platforms, especially at the
boot and Kernel levels. To deal with this problem, we present a
new approach for Bootkit detection based on malicious behaviour
characterisation. Firstly, we identify and extract files from both
the boot and the system partition from 3897 different firmware,
then we establish a correlation mechanism for each sample.
Secondly, we define the main characteristics vector of a normal
booting stage behaviours, then a second characterisation vector
for malicious boot behaviour. The experiment is performed on
7794 boot files from 87 different vendors and we show that our
approach can successfully detect malicious data manipulation.
Also, we highlight and give details about several key challenges
that need to be addressed in future research.
Index Terms—Malware, SoCs, forensic, embedded system, IoT,
android, bootkit, bootloader.
I. I NTRODUCTION
Android platform has been the most targeted one by mal-
ware in 2017 compered to others mobile platform(Windows,
IOS) [1]. The main reason, aside from its popularity [2],
is the long-system patch update cycle caused by the highly
fragmented Android ecosystem [3]. In general, developing
and deploying a patch for a vulnerability can take months,
because it needs the co-operation of multiple actors, such as
OS vendors, device vendors, carriers, even SoC chipset makers
such as Qualcomm, MediaTek. Such delays in security patch
and update deployment, often leave a large number of devices
vulnerable to attacks.
Therefore, thousands of anti-virus applications based on
innovative detection techniques [4] [5] [6] [7] [8] have been
built. However, several studies such as in [9] and more
recently in [10] show the emergence of more serious threats.
Also, the study in [11] have shown the limits of the static anal-
ysis and the need for dynamic approach, but some constraints
such as mobility, limited resources (energy and calculation)
limit the possibility of monitoring applications at run-time
level. Before being replaced by the ART runtime [12], the
Dalvik VM was introduced to offer portability for codes
written in Java, so by design, any dynamic analysis methods
built on Dalvik virtual machines cannot disclose the behaviour
978-1-5386-9493-0/18/$31.00 ©2018 IEEE
2nd Tayeb Kenaza 3rd Mohamed Aissani
Ecole Militaire Polytechnique Ecole Militaire Polytechnique
Algiers, Algeria Algiers, Algeria
ken.tayeb@gmail.com mohamed.aissani@gmail.com
of native code that runs the VM. The Virtual Machine intro-
spection Based on Malware Behaviour [13] should overcome
this limitation but, unfortunately, malware is executed in
simulated environments. Today most serious malware such as
Zeus, SpyEyec, and their variation families Kazy, Dromedan,
detect easily the use of the VM and emulator environment
and use advanced techniques to disrupt their use [14]. These
malware families are able to implement different complex anti-
forensic techniques to hide illegal behaviours.
In summary, the high-risk of these new threats is mainly
the result of the early stage malicious code injection, at the
boot/kernel. The Bootloader is the lowest level of the mobile
phone design, it is inherently a root of trust, therefore any
vulnerability or malicious code in these components will lead
to a disastrous scenario.
This work aims to build platform for malware code detection
at the boot sequence. To do so, we start by evaluating the
use of the two main approaches and their variation, static
and dynamic approach as they were successfully used on the
PC platform. As we will see later in this paper, the dynamic
approach was promising but it suffers from multiple drawbacks
especially due to the hardware diversity as it needs Multi-SoCs
emulator, which does not exist. The static approach showed
its limitations, especially for analysing an early stage code, to
overcome its limitations, we adopted a new approach based
on several steps, to highlight this challenge and give the key
steps of the solution. We have prepared and used a specific
dataset in our experimentation, we use it to define a normal
boot behaviour, and manually analysis all documented bootkit
as well Android custom image to define a malicious boot
behaviour, the approach has shown promising results. The
platform was successfully tested on (30) different firmware
and can efficiently detect security breaches like rooted device
or pre-charged application with superuser privileges.
This paper is organised as follows. Section II introduces
the Kernel malware injection mechanism and gives a set of
concepts definitions necessary for the other sections. Also,
examples of a major attacks case are exposed. In Section III,
we present the challenge of malware analysis regarding SoCs
in general and Android specifically. In this section, we also
present the adopted strategy. In section IV, we present our
data set. Section V introduces our proposed solution as well
277
as the behaviour model. Section VI this last section presents
the conclusions and give details about several key challenges
that need to be addressed in future research.
II. K ERNEL M ALWARE I NJECTION
The globalisation of manufacturing and the multi-actors
(Figure 1) involved in the building/customisation process of
a mobile phone, put the control procedures in a challenging
situation [15]. Frequently, Android Phones are shipped
with major system/hardware errors, and even embedded
malware within the firmware [16] [17]. Original Equipment
Manufacturers (OEMs) (Samsung, Motorola, Lg...) Built
mobile phones by combining multiple hardware and software
components, the most important parts are the SoC chipsets
as hardware and the operating system as software. SoCs are
made and sold by chipset makers like Qualcomm, MediaTek
(Figure 1). They are then integrated with other hardware (PCB
1
, transistors, screen) and software components, essentially
Android builds from Google (for the Android platform).
Phone Bootloader which is a part of the mobile phone
firmware is provided by SoCs chipset makers and customised
by these OEMs.
Fig. 1: Building and Customisation Process Mobile Phone
Finally, phones are sold and distributed by mobile phone
carriers, who may add other modifications by installing some
specific applications whether at the phone manufacturer level
or at his own level. When security patches are required,
the mobile phone must flow through this supply chain. That
process often takes weeks or even months. As we see in
Figure 1, it is a long chain with multi-actors, which leaves
a large window for malware injections. We distinguish two
main levels for bootkit code injection, the hardware and the
software levels.
A. Software level
The injection of a bootkit at software levels can occur by
flashing the device (firmware full flash/update). Documented
attacks related to code injection at the boot stage are not
popular, but the few reported cases show the high complexity
of the attack and demonstrated the scale of the security risk.
Here we cited some of major reported cases.
1 PCB: Printed Circuit Board
978-1-5386-9493-0/18/$31.00 ©2018 IEEE
1) Lenovo [18] and Sony CD cases. [19]. The mal-
ware (bootkit / backdoor) was implemented within the
firmware by the manufacturer itself.
2) OLDBOOT case. [20], the malware injects the code at
the boot partition and modify the ’init.rc’ to gain an
earlier launch priority with high running permission.
3) Quadrooter case [21]. It exploits a set of vulnerabilities
affecting devices based on Qualcomm chipsets. As the
chipsets are widely used, it affects more than 900 million
phones and tablets.
B. Hardware Level
It is possible for a malicious code to be injected at any phase
of the industry supply Chain; the semiconductor foundry, at
the house design by the Intellectual Property provider (IP
core), or even in the integration tools. But real hardware level
attacks are not popular. The very few reported cases like the
attack on Actel/Microsemi ProASIC3 reporte by Skorobogatov
and Woods [22], considered to be present the first real
world detection of hardware backdoor in military grade FPGA
chipsets. The chip is largely used in military-systems and
aircraft such as the Boeing 787. But most of the case are
still a lab test scenario. [23]
III. A NALYSE TECHNIQUE EVALUATION
The goal of malware forensic analysis is to find the origin of
the malicious code, to determine its functionality and to assess
the potential impact of the malware on a given system. To do
so, two approaches exist, static and dynamic analysis. The
static approach consists to study the code without executing
it. It is often limited by encryption and obfuscation used in
the malicious code to prevent analysis [11]. To overcome these
limitations, the dynamic approach was introduced. It involves
the execution of the code and the observation of its behaviour.
The dynamic process uses either an emulated environment or
real hardware for the execution of the suspicious code. The
behaviour is observed through a hardware interface such as a
JTAG debugging card or in the case of emulation environment
through Sandbox software [24].
There are a set of existing tools and emulators for dynamic
analysis and their efficiency varies largely depending on some
questions:
1) The complexity of the malware code: is the code consists
of few lines without library dependency or it consists of
thousands of lines with external calls?
2) The running targets: is the running target a well-known
Micro-controller?, a bare metal?, is it an open source
RTOS?, or is the code running on multiple SoCs?
3) The execution phase of the malware code: is the code
running at the booting stage or at the kernel level or at
the userland.
4) Type of code: is it hardware code (bootrom) depended
or platform compatible (VM)?
Conceding these four characteristics, debugging a suspect
boot sequence code of an android mobile phone represents
the most complex scenario (Figure 2), as mobile phones is
278
multiple SoCs based [25]. Without taking in consideration
the use of obfuscation or encryption by the malware, or any
other anti-forensic techniques, the emulation of multiple SoCs
for bootloader or kernel debugging is not possible, as the
current state of technology of available tools (e.g. QMEU or
android emulator) does not permit such analysis. There is some
debugging hardware provided by ARM, such as JTAG and
Coresight, but due to the hardware diversity of the target (high
number of chipsets and devices), the solution is not applicable.
Fig. 2: ARM ARCHITECTURE-DEBUGGING TOOLS
In order to reduce the complexity of the problem, essentially
due to the diversity of technology and the multitude of
vendors, we performed a study on a large-scale data set as
follows: We started by performing a market study of SoCs
and Android mobile phones to assess the existing diversity of
used technology. Also, we performed a large-scale study of
the boot sequences, we targeted the most sold android mobile
phones. The preliminary results of this study were as follows:
• The architecture used in 95% of all SoCs in mobile
phones are ARM based.
• 90% of the SoCs of the Android phone market is supplied
by three vendors, MediaTek, QUALCOMM, SAMSUNG.
• Android Bootloaders aboot used in mobile phones de-
pends on the SoCs in use but also on the vendor (e.g.
HTC uses a special second stage Hboot),
• We identified the two most used android (last stage)
bootloaders: uboot for MediaTek and LK (Little Kernel)
for QUALCOMM.
• Version of the kernel in use depends on the android
version (see Table I).
Based on these observations when analysing the firmware
code, we will take into consideration the following : When
we use reverse engineering techniques, we will look for
ARM code signature. For firmware analysis (compression,
partition code), we will take in consideration, not just the
vendor but also the SoCs in use (MediaTek, QUALCOMM
and SAMSUNG). For code analysis of the bootloader, we will
use the Android Open Source Project, Uboot and Little Kernel
as roadmaps.
IV. B UILDING THE DATASET
The main objective of the data set is to perform a large
static analysis of the boot sequence, as the ’init.rc’ is the
cornerstone of android systems behaviour, the analysis was
978-1-5386-9493-0/18/$31.00 ©2018 IEEE 279
TABLE I: Corespondent kernel version
Android Version API Level Linux Kernel in AOSP
1.5,Cupcake 3 2.6.27
1.6,Donut 4 2.6.29
2.0/1 Eclair 5-7 2.6.29
............ .. ......
7.1,Nougat 25 4.4.1
8.0,Oreo 26 4.10
performed mainly on the ’init.rc’ and the configuration files.
Also, we use a correlation engine based on Shannon entropy
algorithm to propagate security problems as well as comparing
similarities between codes. When Building the database, we
have to manage five (5) challenges:
• The android hardware diversity: Due to the big diversity
of the Android hardware, our database had to be rep-
resentative. To overcome this challenge, we performed
an android mobile phone market study and selected the
maximum of different SOCs-based for each mobile phone
brand.
• The big size of database and a large number of unpacked
files : The total size of the compressed firmware exceeds
5 Tera Oct, and encloses more than 7 500 000 files,
to manage the huge size, we built a sub-database that
includes only files involved directly in the boot sequence
and computed Shannon entropy for the rest of files.
• The firmware packaging : The difficulty was to unpack
firmware, as they have multi specific packaging (Table
II), we used the results obtained in the last section to
investigated the used format.
• A malicious database : We needed aside the OEMs
firmware data set, a malicious bootloader or at least with
an abnormal bootloader database, we built this second
data set from the popular Android custom recoveries
(Twrp, ClockworkMod, and PhilZ Touch), documented
malware and published exploit.
• A reference database : We also needed a reference
data of init file; the reference database was constructed
from Google depository by downloading all versions of
released kernels and ram-disk, this database is used later
for cleaning the ’init’ .
A. Firmware collection
Firmware has two states. The first one has a multitude of
partitions in the NAND memory, The second state is a single
packed file that can be flashed into the mobile phone.
After having performed the market study, we started a large
firmware collection for analysis, by using two methods:
1- A web crawler that automatically downloads files from
manufacturers OEM websites and some specialised mirror
sites like Carrier distributors.
2- The download service provided by the mobile phone flash
box solution (Octopus, Infinity-Box, ..)2 . The download was
2 These boxes are a piece of hardware and software for repairing damage
mobile phone and also for unlocking network
 TABLE II: firmware extraction
Vendor extention Extracting tools
Huawei .app Huawei Update Extractor
Samsung .tar.md5 Tar compressed file
Lg .Kdz Lg Extractor
Motorola .sbf sbf flash
not entirely performed in an automatic way, as we needed to
document each firmware individually.
B. The boot sequence
When the power button is pressed, a chain-of-trust of
a multistage boot will start by reading a hard-coded root
certificate. The first running code is the Primary Bootloader
(PBL) implemented in the Boot ROM within the SoC, it starts
by loading and verifying the authenticity of the next stage, the
next bootloader loads and verifies the one after and so forth.
This series of bootloaders ends with Android (Applications)
Bootloader (ABOOT) as the last stage bootloader. Depending
on the key combination strike, the ABOOT will verify and
load the boot (Normal bootup) or the Recovery, or a fastboot
mode for upgrade/flash. The aboot prepares the Linux kernel,
the Device Tree Blob and initramfs , it ends by handling out
the execution to the Linux kernel. The ABOOT will loads the
boot or the recovery image, there are no structural differences
between the two images. But they have a different kernel,
Ramdisk, and Init. When the Android kernel starts (boot or
recovery) it setup cache, protected memory and prepares and
loads drivers, and looks for and runs init in the system files.
Init is the root of all processes. The most important task of the
init process is the mounting of directories like ’/sys’, ’/dev’ or
’/proc’ and the running of the ’init.rc’ script (for the recovery
a user interface is loaded and Waits for the user interaction).
C. The boot data set
As discussed in the last section, we limited our work to
the last boot stage (boot/recovery). Android’s boot images
contain the core components of the operating system (the
kernel and the RAM disk), the boot image header has the
unique magic value ’ANDROID!’. The Data record for each
download firmware (see table III), includes: the firmware
name, the name of the involved files in the boot process
(mostly boot.img and recovery.img), the computed Shannon
entropy for each individual file, model, the vendor, carrier if
it exists, the Android version, date of release.
We did use the ’build.prop’ file extracted from the system
partition, as it contains details about android and kernel
version, the SoCs in use..etc.
D. Unpacking the boot files
Android’s boot images (boot.img and recovery.img) have a
special partition format defined by the Android Open Source
Project (AOSP). The image contains the kernel binary image
and the RAM disk, also among them, a 32 bytes Id, a set of
kernel commands line, and optionally, a 2-nd stage Bootloader.
The AOSP provides the exact structure of the boot image (boot
978-1-5386-9493-0/18/$31.00 ©2018 IEEE 280
TABLE III: Data SET exemple
Vendor Samsung
Model GT-I9500
Chipset Exynos 5410 Octa
File2 boot.img
Shannon Entropy 7,98402840147599
Android version 5.1
Kernel version 3.16.1
Android Boot Id 1 3564B1A5EC7589240E0....
System FW version XXKE4
............. .......
and recovery image files) as shown in (Figure 3) 3 . The AOSP
provides also an official utility for boot image manipulation
(packing and unpacking) the ”mkbootimg” alongside with an
alternative utility used to both pack and unpacks boot images
”abootimg”.
Fig. 3: The layout of an Android boot image
E. The init file
The Android init files are the key component in the boot
sequence. Instructions in the init.rc file defines, not just the
behavior of the android boot sequence but also the behavior
of the system itself, as it is responsible for setting up of
all services, daemons and propriety declaration among other
settings.
The android init language consists of 4 classes of statements:
(1. Action, 2. Commands, 3. Services, 4. Options).
Note that the init consists of a set of files, in general with
the structure name init.rc and init.<machine name>.rc. The
machine name is the name or abbreviation of the hard-
ware name that Android is running on, for example for a
phone based on Qualcomm SoC, we will find files named
’init.qcom.rc’ / ’init.qualcomm.rc’ and ’init.qcom.factory.rc’ /
’init.qualcomm.factory.rc’.
’init.rc’ is the main file, when executed it imports all other
files by using special instruction ’import’.
V. T HE PROPOSED APPROACH
A. Cleaning the init file
The cleaning phase in the proposed solution consists of tak-
ing off all basic instructions, configurations, and initialization.
We achieved this action by xoring the candidate init file (from
the build Stock database or submitted firmware for analysis)
with the corresponding init from the ASOP.
B. Bootkit malicious behavior characterization
The number of documented bootkits are too small to be
used alone in any detection model. Alternatively, we adopt
the following solution : First, we build a reference vector
3 Details on the internal structure can be found in bootimg.h an-
droid.googlesource.com
(Nv) for normal behavior characterization out of the already
built database, by extraction the ’init’ files and cleaning the
code (see the cleaning section).Normal behaviour vector : Nv=
(Nc1, Nc2, Nc3,..). In the second step, we manually analyzed
the few documented bootkit code and exploits, aiming their
behavior characterizations (Table IV). Also, we extracted
behavior characteristics of the boot sequence in the Android
custom recoveries. These recovery images are not directly
used in a malicious way, but they opened all the doors for
it (unlocking, installing busybox, root privilege) which can be
classified as malicious behavior.
The characterization consists of attributing a scoring vector
S = s1,s2,s3,s4 where s1..s4 are considered to be malicious
characteristic behavior. Note that Before validating the vector
’s’ as malicious, we check if it doesn’t exist in the Nv vector.
Extracted malicious behavior characterization through cases’
study (see Table IV):
• Behaviour 1: Insert/ Hide the malicious code. Bootkits
need to tamper with the devices boot partition in order
to insert and hide the malicious code.
Achieved by adding executable sh files/ ELF binaries/ Fig. 4: Proposed solutions
KLM in the system partition (/xbin/bin) or in a newly
mounted partition and placing a call for the copied files TABLE IV: Analysed sample
in the init file (insmod ,Insert a kernel module). Attack init Code in init
• Behaviour 2: Mechanism to hide the code. Malware use Service imei chk
/sbin
library from busybox in order to reduce it code size. Oldboot.a
Adding service /imei chk
Achieved by a installing busybox and calling function. Open socket Socket imei chk
bootkit
(Instructions of busybox installations in the init file) stream
666 root root
• Behaviour 3: Ex-filtrating data. Bootkits have a central
Service adb6
character, a function for ex-filtrating data. Add service /sbin/boot tst
Oldboot.b
Achieved by adding services and opening communication Open socket Socket adb6
canals. Also, by adding interruption related to setup or stream 666
/xbin/su8
opening the network in the early start up the process /xbin/sugote
Android.Troj. Add service
(using a socket and adding service network) at Seed.a Open socket
/xbin /
• Behaviour 4: Trigger for execution. Bootkits will exploit supolicy
xbin/ daemon
the trigger instruction or the android property system Add service service
Achieved by adding a trigger instruction (exp on fs) Add triggers
• Behaviour 5: Code run as a Root Rooting Creat directory root script /
mount partition sbin/busybox
For bootkit to be able to access to the restricted user data Install bbox /assets/run.sh
or system propriety and overthrow the anti-malware. The CVE2016-2420 ............ ...............
malicious code need to be launched as the root process.
Achieved by using in the ’init’ file instructions chmod,
chroot with permissive parameters. result, we did find that in the official database, 6 firmware
• Behaviour 6: Rooting the device. Some malware and that should be malware free, contain a malicious code ”
bootkits exploit the pre-rooted device. libgooglekernel.so”. The concerned firmware was downloaded
Achieved by replacing the binary ’su’ by an modified one by the repair box (infinity)
in ’system/xbin/su’.
D. The proposed approach
Behaviors (1,3,5) confirm the presence of a bootkit. Behav-
iors (2,4,6) probability of the presence of bootkit. The solution consists of the following methodology(Figure
Note that in the Behaviour 1, if the correlation engine does 4) : The first phase was building the database, download-
not confirm the launched binary as a malware, the binary code ing and unpacking the firmware. For all extracted files, we
have to be manually analysed . compute the Shannon entropy algorithm. The result is used
to propagate vulnerability or known malware binary. Then,
C. Correlation Engine we build the second database of extracted files from the
With a simple correlation engine based on Shannon entropy, Boot.img and the Recovery.img. We extract the init files from
we show that we can find easily malicious codes. As a first the boot and recovery. In the second phase, we clean the ’init’

978-1-5386-9493-0/18/$31.00 ©2018 IEEE 281

files, we encode the remaining statements (Action, Commands,
Services and the Options), into vector Nv (the normal behavior
vector)
When firmware is submitted for analysis, we extract the init
root, and we use the build.prop to identify the android os
/kernel version and the hardware (SoC) in use, then we clean
the init. We construct with these remaining instructions a
vector S. If the vector does not exist in the normal vector
Nv, then we assume that the firmware has boot sequence with
malicious behavior.
E. Results and Evaluation
The evaluation of the proposed method was done through
a set of 30 sample firmware (infected , rooted, and normal
firmware), the solution successfully detected each class. We
had some false positives exp the secure solution from Samsung
KNOX, as it has a special encrypted partition where user data
are copied and hidden from unauthorized access.
VI. C ONCLUSION
Our first objective was to build a detection platform that can
provide a security validation for an unknown android firmware.
The motivation was the exponentially growing number of
multi-use SoCs in mobile phones and IoT, which introduce
a new kind of security problem at a very high scale, caused
essentially by vulnerability at the root levels.
In this paper, we expose the challenge introduced by the SoC
environment, especially the lack of emulation technology and
we propose a novel approach for bootkit detection. This work
remains incomplete, as we did not look to the vendor-specific
partition where property contexts reside (SELinux). Even if
we did successfully detect the submitted sample, our proposed
behavior model needs to be enhanced for each newly detected
bootkit. Also more work should be done on the kernel code
and the infection vector for bootkit. Which can help to build a
better security validation mechanism for new android mobile
phone
R EFERENCES
[1] Nokia, “Nokia threat intelligence report 2017,” http://nokiamob.net/wp-
content/uploads/2017/11/Nokia-Security-Report.pdf, 11 2017, (Ac-
cessed on 09/14/2018).
[2] G. StatCounter, “Mobile operating system market share
worldwide fab2017 fab2018,” http://gs.statcounter.com/os-market-
share/mobile/worldwide/, accessed fab 4, 2018.
[3] openSignal, “Android fragmentation report august 2015 - opensignal,”
http://opensignal.com/reports/2015/08/android-fragmentation/, 08 2015,
(Accessed on 03/11/2018).
[4] I. Burguera, U. Zurutuza, and S. Nadjm-Tehrani, “Crowdroid: behavior-
based malware detection system for android,” in Proceedings of the 1st
ACM workshop on Security and privacy in smartphones and mobile
devices. ACM, 2011, pp. 15–26.
[5] Y. Aafer, W. Du, and H. Yin, “Droidapiminer: Mining api-level features
for robust malware detection in android,” in International conference on
security and privacy in communication systems. Springer, 2013, pp.
86–103.
[6] A. Shabtai, U. Kanonov, Y. Elovici, C. Glezer, and Y. Weiss, “andro-
maly: a behavioral malware detection framework for android devices,”
Journal of Intelligent Information Systems, vol. 38, no. 1, pp. 161–190,
2012.
978-1-5386-9493-0/18/$31.00 ©2018 IEEE
[7] D. Arp, M. Spreitzenbarth, M. Hubner, H. Gascon, K. Rieck, and
C. Siemens, “Drebin: Effective and explainable detection of android
malware in your pocket.” in Ndss, vol. 14, 2014, pp. 23–26.
[8] D.-J. Wu, C.-H. Mao, T.-E. Wei, H.-M. Lee, and K.-P. Wu, “Droidmat:
Android malware detection through manifest and api calls tracing,” in
Information Security (Asia JCIS), 2012 Seventh Asia Joint Conference
on. IEEE, 2012, pp. 62–69.
[9] Y. Zhou and X. Jiang, “Dissecting android malware: Characterization
and evolution,” in Security and Privacy (SP), 2012 IEEE Symposium
on. IEEE, 2012, pp. 95–109.
[10] H. Ruan, X. Fu, X. Liu, X. Du, and B. Luo, “Analyzing android
application in real-time at kernel level,” in Computer Communication
and Networks (ICCCN), 2017 26th International Conference on. IEEE,
2017, pp. 1–9.
[11] A. Moser, C. Kruegel, and E. Kirda, “Limits of static analysis for
malware detection,” in Computer security applications conference, 2007.
ACSAC 2007. Twenty-third annual. IEEE, 2007, pp. 421–430.
[12] anandtech Andrei Frumusanu, “A closer look at android runtime (art)
in android l,” https://www.anandtech.com/show/8231/a-closer-look-at-
android-runtime-art-in-android-l/, 05 2014, (Accessed on 03/31/2018).
[13] Y. Hebbal, S. Laniepce, and J.-M. Menaud, “Virtual machine intro-
spection: Techniques and applications,” in Availability, Reliability and
Security (ARES), 2015 10th International Conference on. IEEE, 2015,
pp. 676–685.
[14] R. J. Rodrı́guez, I. R. Gaston, and J. Alonso, “Towards the detection
of isolation-aware malware,” IEEE Latin America Transactions, vol. 14,
no. 2, pp. 1024–1036, 2016.
[15] M.-C. M. Chu, “Controlling the uncontrollable. the migration of the tai-
wanese semiconductor industry to china and its security ramifications,”
China Perspectives, vol. 2008, no. 2008/1, pp. 54–68, 2008.
[16] S. Khandelwal, “More firmware backdoor found in cheap android
phones,” https://thehackernews.com/2016/12/hacking-android-
smartphone.html, 12 2016, (Accessed on 03/11/2018).
[17] P. Paganini, “Experts spotted triada trojan in firmware
of low-cost android smartphonessecurity affairs,”
https://securityaffairs.co/wordpress/61467/malware/triada-trojan-
android-smartphones.html, July 2017, (Accessed on 07/24/2018).
[18] M. Guri, Y. Poliak, B. Shapira, and Y. Elovici, “JoKER: Trusted
detection of kernel rootkits in android devices via JTAG interface,” in
Trustcom/BigDataSE/ISPA, 2015 IEEE, vol. 1. IEEE, 2015, pp. 65–73.
[19] J. A. Halderman and E. W. Felten, “Lessons from the Sony CD DRM
Episode.” in USENIX Security, 2006.
[20] H. Z. Xiao, Q. Dong, and X. Jiang, “Oldboot: the first bootkit on
android,” Qihoo 360 Technology Co. Ltd, 2014.
[21] H. Rao and S. Selvakumar, “A Kernel Space Solution for the Detection
of Android Bootkit,” in ICT and Critical Infrastructure: Proceedings
of the 48th Annual Convention of Computer Society of India-Vol I.
Springer, 2014, pp. 703–711.
[22] S. Skorobogatov and C. Woods, “Breakthrough silicon scanning discov-
ers backdoor in military chip,” in International Workshop on Crypto-
graphic Hardware and Embedded Systems. Springer, 2012, pp. 23–40.
[23] S. Ray, S. Bhunia, and P. Mishra, “Security validation in modern soc
designs,” in Fundamentals of IP and SoC Security. Springer, 2017, pp.
9–27.
[24] M. Egele, T. Scholte, E. Kirda, and C. Kruegel, “A survey on automated
dynamic malware-analysis techniques and tools,” ACM computing sur-
veys (CSUR), vol. 44, no. 2, p. 6, 2012.
[25] K. Yaghmour, Embedded Android: Porting, Extending, and Customizing.
” O’Reilly Media, Inc.”, 2013.
282