The Verified Boot protocol + the GBL-class attack (Track D, current focus)

Our device's protocol (confirmed by RE)

VerifiedBootDxe (extracted from uefi.elf's embedded FVs) registers the protocol:

QCOM_VERIFIEDBOOT_PROTOCOL GUID: {8e5eff91-21b6-47d3-af2b-c15a-01e0-20ec}

(Found in the driver's protocol-registration table at file offset 0xd0b8, next to the Disk I/O, FAT and SimpleFileSystem GUIDs. This is not the SM8850 variant {98f41539-…} — the PoC structs from that writeup don't apply; the 8e5eff91 family does.)

The attack pattern (public PoC: kasnria001/qualcomm_gbl_exploit_poc)

[unsigned EFI app staged in a boot-chain load path]
    -&gt; gBS-&gt;LocateProtocol(&gEfiQcomVerifiedBootProtocolGuid, …)
    -&gt; VbProtocol-&gt;VBRwDeviceState(VbProtocol, READ_CONFIG,  Buf, 3344)
       Buf[0] = 1;   // device-unlock bit
       Buf[8] = 1;   // critical-partition flashing bit
    -&gt; VBRwDeviceState(WRITE_CONFIG, Buf, 3344)
       -&gt; the ABL's trusted path writes the RPMB device state (TZ performs the
          authenticated RPMB write itself — no crypto broken)

Timing constraint from the PoC author: the write must happen before the TEE "milestone" locks device-state changes — which is why the GBL stage (early boot) is the natural carrier.

GBL / staging status on SM-F956B DZI1

The upstream pattern stages the payload in an efisp partition (GBL = an unsigned UEFI app loaded by the ABL).
Our device has no efisp / android_esp / GBL strings anywhere in the plaintext chain — Samsung did not adopt the standalone GBL partition here.
Ruled out as staging: toolsfv / catefv / testparti (no boot-chain component references them — catefv is a factory/test hook only), uefivarstore (XBL config vars only), param/misc (no app-load path found yet).
Remaining candidates:
The OEM Setup App launch path (EnableOEMSetupAppInRetail, disabled in the platform config) — lives in the encrypted imagefv BDS.
FVUtilsDxe::LaunchAppFromGuidedFv — launches apps from "FV2" handles; the FV2s come from uefi.elf + imagefv (both signed/encrypted → not attacker-writable).
CVE-2026-24088's "specific partition" (unauthorized write → customized bootloader) — the exact partition is not publicly documented.
CVE-2026-24090 GPT-redirect behavioral test (high risk).

Files

references/ (local research dir, not in this repo): the public PoC source (VbRwStateApp.c), the 50 KB Qualcomm-unlock playbook (o0xmuhe, OnePlus 7 Pro based — covers the VB protocol internals + the devinfo layout), the prebuilt gbl_efi_unlock.efi / gbl_efi_relock.efi.
Our VerifiedBootDxe driver: GUID table at 0xd078, protocol GUID at 0xd0b8.

Open questions

Where does the DZI1 boot chain load an unsigned UEFI app from? (The unlock itself is solved — only the staging is missing.)
What is the "specific partition" in CVE-2026-24088?
Can the imagefv encryption be unwrapped via SM-F956B_EUR_XX_QKEY1 / oem_image_encryption_key1?