Secure Boot is a foundational security mechanism ensuring that only verified, authorized software executes during a device’s boot process. It establishes a cryptographical certificate chain of trust that begins in read-only-memory (ROM) and extends through each software layer.

On the applications processor the first piece of ROM-based software mentioned above, which we call the Primary Bootloader (PBL), typically loads and authenticates a Secondary Bootloader (SBL) or eXtensible Bootloader (XBL) as the next image to be run. This image then loads and authenticates a feature-rich applications bootloader such as Little Kernel (LK) or the UEFI that is specific to the OS that it will subsequently load. In modern Qualcomm products, these software images are all standard ELF images.

An abstract overview of the boot process of Qualcomm MSM devices is as follows:

[ Primary Bootloader (PBL) ]
|
`---EDL MODE---.                                    # Sahara Protocol
|              [ Firehose Programmer ]
|              `- Commands (through USB)
|
`---NORMAL BOOT---.
                  [ Secondary Bootloader (SBL) ]
                  |-.
                  | [ Android Bootloader (ABOOT) ]  # Sahara Protocol
                  | `-.
                  |   [ boot.img ]
                  |   |-- Linux kernel
                  |   `-- initramfs
                  |       `-.
                  |         [ system.img ]
                  |
                  `-[ TrustZone ]

Emergency Download (EDL) Mode

Emergency Download (EDL) Mode is a low-level recovery and flashing mode built into Qualcomm MSM-based devices, designed for secure device servicing, recovery, and reprogramming even when higher-level boot stages are damaged or inaccessible. EDL is implemented directly by the primary bootloader (PBL) stored in ROM. Because the PBL is immutable, EDL cannot be modified or corrupted by software, ensuring that the device remains recoverable even if other partitions or bootloaders are compromised.

When a device boots into EDL mode (with USB PID 9008), it presents itself to a connected computer as Qualcomm HS-USB QDLoader 9008 device on the USB bus. This unique identifier signals to host-side tools, such as Qualcomm’s official utilities (QDL) or third-party software (EDL), that the device is in a special recovery mode and ready for low-level servicing or firmware updates. Upon connecting, the host sends a Firehouse programmer binary to the device. The primary bootloader takes responsibility for verifying the received piece of software, including several security checks and validations.

• Address and Size Validation: As each image is loaded, its address and size are verified against whitelisted, permitted ranges. Integer overflow checks are applied when calculating offsets and end addresses to prevent out-of-bounds access and security flaws.
• Header and Hash Segment Loading: The image’s ELF and Program headers are parsed first, followed by the specialized “hash segment.”
• Hash Segment Signing: The hash segment contains SHA-256 digests of each included ELF segment and headers, not of the entire image. Its signature is validated using a chain of two or three X.509 v3 certificates (Attestation, optional Attestation CA, Root CA).
  • With a three-certificate chain, each certificate’s signature is validated by the public key in the certificate above it: Attestation is checked by Attestation CA, and Attestation CA is checked by Root CA.
  • With a two-certificate chain, the Attestation certificate is directly signed by the Root CA.
  • The Root CA itself is anchored by comparing its SHA-256 hash with a value stored by the OEM in on-device hardware (eFuse or ROM).
• Signature Enforcement: The signature on the hash segment is then checked using the public key in the Attestation certificate. This step also enforces policy “bindings” embedded in the certificate, such as disallowing rollback to older images, restricting use to certain device models, or ensuring the image is from the intended OEM.
• Per-Image Attestation Certificates: Each time an image is signed, a fresh Attestation certificate is generated, making signature verification unique for every image instance.

Only if the validation steps turn out to be valid, the PBL execute the programmer as a secondary bootloader. This hardware-enforced process ensures that only authentic and authorized software can interact with or modify the device at this fundamental level, protecting against tampering or unauthorized access.