Qualcomm EDL Firehose Programmers Peek and Poke Primitives

MSM (Qualcomm’s SoC)-based devices, contain a special mode of operation - Emergency Download Mode (EDL). In this mode, the device identifies itself as Qualcomm HS-USB 9008 through USB. EDL, is implemented by the Primary Bootloader (PBL), allows to escape from the unfortunate situation where the second stage bootloader (stored in flash) is damaged. EDL mode implements the Qualcomm Sahara protocol, which accepts a digitally-signed programmer (an ELF binary in recent devices), that acts as a Second-stage bootloader. Modern such programmers implement the Firehose protocol.

[Primary Bootloader (PBL)]
|
`---EDL---.
           [Programmer (Firehose)]
           `- Commands (through USB)

For details on how to get into EDL, please see our blog post.

Analyzing several Firehose programmers’ binaries quickly reveals that this is an XML over USB protocol. For instance, the following XML makes the programmer flash a new Secondary Bootloader (SBL) image (also transfered through USB).

<?xml version="1.0" ?>
<data>
  <program SECTOR_SIZE_IN_BYTES="512" file_sector_offset="0" filename="sbl1.bin"
           label="sbl1" num_partition_sectors="1024" physical_partition_number="0"
           size_in_KB="512.0" sparse="false"
           start_byte_hex="0xc082000" start_sector="394256"/>
</data>

Loading the programmer with IDA, quickly revealed that our obtained Firehose programmers also support the peek and poke tags, with the following format:

32-bit programmers:

 <peek address64="ADDR" SizeInBytes="SIZE"/>
 <poke address64="ADDR" SizeInBytes="SIZE" value="VALUE"/>

64-bit programmers:

 <peek address64="ADDR" size_in_bytes="SIZE"/>
 <poke address64="ADDR" size_in_bytes="SIZE" value64="VALUE"/>

These allow for arbitrary code execution in the context of the programmer, as demonstrated in our blog post.

Using these primitives we managed to:

1. Create an exploitation and research framework capable of tracing the execution of Firehose programmers, and the rest of the bootloader chain, specifically on Nokia 6. (Other devices require further research.)
2. Obtain and reverse-engineer the PBL of various Qualcomm-based chipsets (MSM8994/MSM8917/MSM8937/MSM8953/MSM8974) using our research framework.
3. Obtain the RPM & Modem PBLs of Nexus 6P (MSM8994).
4. Manifest an end-to-end attack against our Nokia 6 device running Snapdragon 425 (MSM8937). We believe this attack is applicable to Nokia 5 as well, although unverified.

As for remediation, vendors with leaked programmers should use Qualcomm’s Anti-Rollback mechanism, if applicable, in order to prevent them from being loaded by the Boot ROM (PBL)