live

[RESEARCH] SM-F956B (Z Fold 6) bit-4 — OEM-unlock flag IGNORED by the bootloader (empirical proof) + bootchain bug-hunt map + temp-root end state

TL;DR

============== 1. THE EXPERIMENT THAT CLOSED TRACK A ============== Samsung removed the OEM-unlock toggle from bit-4 builds. The question was never "is the toggle hidden" — it's "does the abl still READ the flag the toggle writes?"

So we wrote the flag ourselves, as root, through the official service path.

Decompiling services.jar (Android 16 dex-041 — baksmali can't open it; use jadx 1.5.6 + JDK 17) revealed the whole gate stack on this build:

Fun fact: the PDB flag was ALREADY TRUE from the factory on this firmware. The software ships "unlock allowed" — the bootloader just refuses to act on it.

The write, as uid 0 (kernel-context shells can't reach servicemanager — runcon u:r:shell:s0 fixes that while keeping uid 0):

service call oem_lock 2 i32 1 # setOemUnlockAllowedByCarrier(true) -> clears no_oem_unlock service call oem_lock 4 i32 1 # setOemUnlockAllowedByUser(true) -> writes the flag + digest

Verified: persistent partition last byte = 0x01, digest valid, all three getters (tx 3/5/6) returned TRUE.

Reboot. Verdict:

ro.boot.other.locked = 1 ro.boot.flash.locked = 1 ro.boot.vbmeta.device_state = locked ro.boot.warranty_bit = 1 ro.oem_unlock_supported = (empty)

The bit-4 bootloader does not read the flag. No software state can unlock it. Track A (any kind of flag/toggle/restriction manipulation) is permanently closed — with receipts.

============== 2. TEMP-ROOT END STATE (what you can actually use today) ============== GhostLock (CVE-2026-43499) works on DZI1 (kernel 6.1.145). One exploit run per boot, then root persists until the next reboot:

# after a successful payload run (GHOSTLOCK_ROOT_SHELL=1): # the su daemon stays alive (SU_PERSIST_ONE_SHOT build) and any adb shell can do: adb shell "/data/local/tmp/pompomsu-helper id" # -> uid=0(root) gid=0(root) context=u:r:kernel:s0

SELinux permissive until reboot. Reliable timing notes: fresh boot + unlocked screen, one shot per boot (in-boot retries can panic), and DON'T quiesce the system — modem/scheduler noise actually helps this race land. Hit rate on a fresh boot is ~cycle 1-2.

REMINDER that can't be said loudly enough: DO NOT take the October 2026 SMR — it patches CVE-2026-43499. Keep OTA agents disabled (com.wssyncmldm + com.sec.android.soagent).

============== 3. THE BUG-HUNT: why there's still a chance ============== If the bootloader can't be unlocked by design, it has to be unlocked by bug. And the public landscape in 2026 is wild:

CVE-2026-24090 — Qualcomm ABL missing authentication on partition-table processing. Redirect the boot flow / load unauthorized code. The affected list explicitly includes "Snapdragon 8 Gen 3 Mobile Platform" — that's OUR chip. OEMs notified 2026-03-02, public 2026-06-01. Patch state of Samsung's September builds: unknown.

CVE-2026-24088 — sibling, CVSS 8.2: "unauthorized write access to load a customized bootloader". Same bulletin.

CVE-2026-21385 — Qualcomm graphics zero-day, exploited in the wild (CISA KEV), 235 chipsets incl. SM8650. Kernel-level primitive — patched in our Sept build, but it shows SM8650 is actively targeted.

SM8850 UEFI/GBL chain (tryigit.dev, March 2026) — the playbook. On 8 Elite Gen 5, an UNSIGNED EFI payload rides the bootloader's own staging path (missing PK enforcement = Setup Mode). The payload locates the Qualcomm Verified Boot protocol GUID {98f41539-b818-47e8-9003-ffc19d330d14} and calls VBRwDeviceState(WRITE_CONFIG) — the TrustZone itself flips the RPMB unlock bits. No crypto broken; the authorization check around the caller is what's missing. Full PoC source is published.

============== 4. OUR BOOT CHAIN, MAPPED (this is the part I haven't seen published anywhere) ============== DZI1 BL tar, 33 members. Static scan (entropy/strings):

ENCRYPTED at rest: - abl.elf, imagefv.elf (ELF headers plain, loadable segments = ciphertext, entropy 8.0) That's why nobody REs modern Samsung abl from a firmware tar.

PLAINTEXT, fully RE-able: - uefi.elf — the UEFI DXE firmware. "LoadImage:", and a flag "EnableOEMSetupAppInRetail = 0x0" (an OEM EFI app launch path that's disabled in retail — interesting). - uefi_sec.mbn — the secure UEFI app. Contains the var-name table PK/KEK/SetupMode/ SecureBoot/db/dbx, the ENTIRE secure-boot lib (secboot_hashUpdate, validate_pkcs7_and_get_public_key, pbl_secx509_parse_pub_key), TzSetVariable/TzGetVariable/TzVariablePolicyCheck/AuthenticateVariable, "SecureBootEnable", "VariablePolicyIsPrivAuthVarProtectionDisabled", and a device key label: SM-F956B_EUR_XX_QKEY1. - xbl_s.melf — Qualcomm source paths (AntiRollbackMgr.cpp, arbFuseMapOem). - tz.mbn — "Device is OEM unlocked", "Secure boot is disabled", oem_decryption_service_enabled, sec_deferred_oem_roots_of_trust. - tz_kg.mbn — the KG trustlet: KG_unlock, KGBL_read_fuse/KGBL_write_fuse, HWIO_QFPROM_RAW_OEM_SPARE_1 fuse address (KG state = QFPROM fuses + RPMB). - tz_iccc.mbn — CICCCGetDeviceStatus, Warranty Bit, is_updates_lock_enabled. - vaultkeeper.mbn — warranty-bit fuse + oem_sw_fuse checks, device_info RPMB. - engmode.mbn — em_clear_rpmb, "EngineeringMode20 AES256" key labels (MSTG-signed).

Live partition dumps (temp root): the UEFI auth variables (PK/SetupMode values) are NOT in uefivarstore — they're stored in TrustZone via TzSet/GetVariable, so Android can't read them. uefivarstore only holds XBL config vars, including oem_image_encryption_key1 (+_sel) — a candidate for the key that decrypts the abl/imagefv. devinfo = "SAMANDR-BOOT!" magic; frp partition = all zeros (FRP inactive).

============== 5. WHAT'S NEXT ============== 1. Ghidra on uefi.elf + uefisecapp + xbl_s: find the abl/imagefv decryptor and its key source (QKEY1? oem_image_encryption_key1? fuses?), the SetupMode/PK defaults, the OEM Setup App launch conditions, and the unlock state machine. 2. If an unauthenticated EFI load path exists (Setup Mode), port the SM8850 PoC to our firmware — our GUIDs/offsets will differ and must be mapped from our own RE. 3. Behavioral test for CVE-2026-24090 (GPT redirect) — high risk, needs Odin recovery planning first. 4. Watch KLCERT-25-012 (Qualcomm BootROM write-what-where) for the chipset list.

Happy to share the raw scans/dumps with anyone working the same device. If anyone else is already RE'ing the SM8650/SM-F956B boot chain — let's talk.

Credits: GhostLock-Galaxy + the projects credited in its README (NebuSec/CyberMeowfia, JoinChang, x-spy, YuKongA, BuSung-dev), the tryigit.dev SM8850 whitepaper, ZeroPath's CVE-2026-24090 analysis.

Standard disclaimer: research on my own device; no unlock yet — temp root only; don't flash anything you don't understand; wrong RPMB/boot-state writes can brick permanently.