[UPDATE 2] SM-F956B bit-4 — VerifiedBoot protocol identified, KernelSU probe underway, and the exploit's timing secret

(Follow-up to the first write-up: the OEM-unlock flag verdict + bootchain map. Quick recap for newcomers at the bottom.)

TL;DR

Our device's QCOM VerifiedBoot protocol GUID is identified: {8e5eff91-21b6-47d3-af2b-c15a-01e0-20ec}. It matches the PUBLIC GBL-class PoC — the unlock primitive is fully understood, only the staging path is missing.
The entire DXE driver set was extracted from the plaintext UEFI stage — including VerifiedBootDxe (the RPMB device-state writer) and VariableDxe (the policy-engine consumer).
KernelSU on the locked bootloader is being actively probed: the E3Q (S24 Ultra, SM8650) module panics our kernel exactly as the Samsung KDP/RKP/DEFEX docs predict — the fix is an exact module build from Samsung's published F956B source.
Biggest practical finding: the GhostLock payload ships a BUILT-IN timing search (rotates 6 delays, persists its index across reboots). Setting FOPS_DELAY_USEC disables it. Our multi-hour miss streak was self-inflicted — don't pin the knob.

============== 1. THE VERIFIEDBOOT PROTOCOL (the unlock primitive, solved) ============== The DXE drivers inside uefi.elf's embedded firmware volumes decompress with the stock uefi_firmware tool. The driver set includes VerifiedBootDxe — the component that reads/writes the RPMB device state through QSEE ("VB: RWDeviceState", "VB: DeviceInit: Device is unlocked! Skipping verification!").

Its protocol-registration table (file offset 0xd0b8) contains the GUID:

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

This is NOT the SM8850 variant from the published 8-Elite writeup ({98f41539-...}) — but it IS the GUID used by the public qualcomm_gbl_exploit_poc (kasnria001). That PoC's flow:

unsigned EFI app, staged in a boot-chain load path
  -&gt; LocateProtocol(8e5eff91-...)
  -&gt; VBRwDeviceState(READ_CONFIG, Buf, 3344)
     Buf[0] = 1;   // device unlock
     Buf[8] = 1;   // critical-partition flashing
  -&gt; VBRwDeviceState(WRITE_CONFIG, Buf, 3344)
  -&gt; the ABL's own trusted path performs the RPMB write (TZ does it, pre-milestone)

No crypto is broken — the authorization check around the caller is what's missing. The remaining piece on Samsung's DZI1: there is no efisp/android_esp partition, so the staging path is still open research (candidates: the OEM Setup App path in the encrypted imagefv, FVUtilsDxe's LaunchAppFromGuidedFv, or CVE-2026-24088's "specific partition").

============== 2. THE DXE DRIVER SET (what else is in there) ============== VariableDxe (cecd0e2b...) reads EnableVariablePolicyEngine — the consumer of the policy config we found DISABLED in the previous write-up. FVUtilsDxe has LaunchAppFromGuidedFv. QseeComDxe loads TZ apps from partitions. BDS, ScmDxeCompat, QcomChargerApp, SamsungDdrApp, and ~100 more — all from the plaintext stage. Build paths leak the platform: LanaiLAA (= SM8650) with RELEASE_CLANG16.

============== 3. KERNELSU ON THE LOCKED BOOTLOADER (in progress) ============== The community chain is complete for our device family: - GhostLock-Galaxy (wxxsfxyzm) targets the q6q Fold 6 (F9560 DZI1) with payload + ksud — our payload is from the same source family (its default ksud path literally names the F9560 binary). - Root-My-Galaxy-Payloads documents the full Samsung KernelSU recipe: KernelSU v3.2.5 + the samsung-kdp-rkp-defex patch (KDP credential refcounts, RKP syscall-table fallback to kretprobe, DEFEX credential sync), with ksud bind-mounted over /system/bin/logcat for the privileged late-load. - The E3Q (S928U) module is from the SAME kernel drop lineage as ours (vermagic 6.1.145-android14-11-33419968 vs our 33418572), and the Rust ksud patches the embedded module's vermagic at runtime + parses /proc/kallsyms + uses init_module directly.

Probe result: the E3Q module panics our kernel at init — exactly the documented KDP/RKP behavior for a wrong-kernel module. Next: build the exact module from Samsung's SM-F956B_16_Opensource tree (the OSRC download exists) using the same recipe, then late-load + KernelSU Manager. Target end state: app-level su + Zygisk + LSPosed, bootloader locked, Knox untripped.

Community-artifact gotcha worth sharing: the RMG/GH binaries are committed UTF-16LE-encoded in git — the GitHub raw API serves them doubled. Clone the repo for real bytes. (Cost us an "Exec format error" debugging detour.)

============== 4. THE EXPLOIT'S TIMING SECRET (biggest practical finding) ============== Reading the payload source: with no FOPS_DELAY_USEC set, the payload rotates through {70000, 60000, 80000, 40000, 90000, 50000} with a persistent on-device index (.ghostlock_fops_delay_index) — a built-in search that survives reboots. Setting the env var pins ONE value and disables the rotation.

Our multi-hour miss streak = pinned 30000 (a value outside the rotation range) + thermal drift (a hot charging phone shifts the race window — cold + settled + plugged + manually unlocked = hits on attempt 1, repeatedly). If you're fighting this exploit: don't pin the knob, cool the phone, settle 60-90s post-boot, and unlock the screen by hand.

============== RECAP FOR NEWCOMERS ============== - Bit-4 F956B: the bootloader IGNORES the OEM-unlock flag (proven as uid 0) — Track A closed. - Temp root (CVE-2026-43499) works on DZI1; per-boot, re-run after every reboot. - NEVER take the October 2026 SMR (kills the exploit). OTA agents stay disabled. - Research repos: github.com/plomens/f956b-bootchain-research (device), github.com/plomens/android-rooting-field-guide (general), github.com/plomens/rooting-breakthroughs (milestones).

Standard disclaimer: own device, no unlock yet, wrong RPMB/boot-state writes can brick.