live
root@f956b: ~/research
$ cat status.log
device  = SM-F956B (q6q) — bit 4, KG prenormal
bootloader = LOCKED — but we keep digging
root      = temp, per boot, automated
status   = never giving up
$ _

GetYahRootBack

Unlocking + rooting a Samsung Galaxy Z Fold 6 the hard way — documented, in the open, for the community.

read the logdevice research
[*]just shippedorbit v2.0.0 — firmware straight from Samsung’s FUS servers · per-partition extraction · full speed · GPL-3.0open orbit →

// tracks

bl swapclosed

Bootloader swap on the unlock flag — proven dead: the abl ignores the OEM-unlock flag entirely. Full verdict written up.

read →
temp root + kernelsuactive

Per-boot temp root works. KernelSU exact-module build + GhostLock research = the live thread.

read →
orbit downloaderpublic

Our FUS firmware downloader — straight from Samsung’s servers, per-partition extraction, GPL. Open source.

read →
vb protocol / gblhunting

The VerifiedBoot protocol door: CVE-2026-24090 + the GBL-class attack surface. Current focus.

read →

// breakthrough log

context

Rooting Breakthroughs

Rooting Breakthroughs

One entry per unlock-level discovery in the SM-F956B (Z Fold 6, q6q, SM8650) bootloader/KernelSU research. Chronological. Every entry links to the detailed repos:

2026-10-22

The bootloader ignores the unlock flag (Track A closed with proof)

Wrote the official OEM-unlock flag as uid 0 through the official service path (persistent partition last byte = 0x01, valid SHA-256 digest, every service getter TRUE). Reboot: other.locked=1, vbmeta=locked, warranty=1. The bit-4 abl does not read the flag — and the flag was TRUE from the factory anyway. The unlock path is stripped from the bootloader, not hidden in the UI.

→ docs/oem-unlock-verdict.md (device repo)

2026-10-22

The OEM-unlock gate stack fully decompiled

Samsung's entire gate chain decoded from services.jar: "carrier" = a user restriction (no_oem_unlock), the carrier signature is ignored, the flag = the last byte of the persistent partition + digest, full IOemLockService transaction map. Includes the self-inflicted-lock pitfall (a no-arg tx2 probe sets the restriction).

→ docs/oem-unlock-gate-stack.md (field guide)

2026-10-22

Temp root with a persistent per-boot su daemon

GhostLock (CVE-2026-43499) on DZI1: one exploit run per boot, then pompomsu-helper <cmd> = uid 0 from any adb shell until reboot (SU_PERSIST_ONE_SHOT build). Timing recipe dialed (fresh boot, one shot, no quiesce).

→ docs/temp-root.md (device repo)

2026-10-22

The variable policy engine ships DISABLED on bit 4

Confirmed at two independent levels: the UEFI platform config (EnableVariablePolicyEngine = 0, AllowNonPersistentVarsInRetail = 1, SecurityFlag = 0xC4 with SecBoot bit clear) and the runtime gate flag in uefisecapp (byte 0x1f114 initializes 0x00, never written). The SM8850-class weakness, verified on our own SM8650 firmware.

→ docs/uefi-config.md (device repo)

2026-10-22

The full boot chain mapped: what's encrypted, what's not

All 33 BL members classified. abl.elf + imagefv.elf = encrypted at rest (why nobody REs them). Everything else plaintext — including the entire secure-boot library in uefisecapp (SetupMode/KEK/db/dbx, secboot_hash*, pbl_secx509_*, TzSet/GetVariable, key label SM-F956B_EUR_XX_QKEY1). UEFI auth vars = TZ-stored.

→ docs/bootchain-map.md (device repo)

2026-10-22

The DXE driver set extracted from the encrypted-bootloader firmware

uefi.elf's embedded FVs decompressed with uefi_firmware: VerifiedBootDxe (RPMB device-state R/W via QSEE), VariableDxe (the policy-engine consumer), FVUtilsDxe (LaunchAppFromGuidedFv), QseeComDxe (TZ app loader), BDS, and ~100 more drivers — all from the plaintext UEFI stage. Build paths leak LanaiLAA = SM8650.

2026-10-22

Our VerifiedBoot protocol GUID identified: {8e5eff91-21b6-47d3-af2b-c15a-01e0-20ec}

Extracted from VerifiedBootDxe's protocol-registration table. Matches the public GBL-class PoC exactly (kasnria001/qualcomm_gbl_exploit_poc): an unsigned EFI app calls VBRwDeviceState(WRITE_CONFIG, buf) with buf[0]=1, buf[8]=1 and the ABL's own trusted path writes the RPMB unlock state — pre-TEE-milestone. The unlock primitive is solved; only the staging path is missing (no efisp on Samsung DZI1).

→ docs/vb-protocol-poc.md (device repo)

2026-10-22

KernelSU track opened: app-level root on the locked bootloader is buildable

The complete chain documented by the community and verified against our device: GhostLock-Galaxy (q6q payload family = ours) + RMG's Samsung KernelSU recipe (KernelSU v3.2.5 + the samsung-kdp-rkp-defex patch for KDP/RKP/DEFEX) + the ksud-over-logcat bind-mount late-load trick. The E3Q module (S928U = SM8650, same SoC) is from the same kernel-drop lineage (vermagic 33419968 vs ours 33418572), and the loader patches vermagic at runtime. Samsung OSRC publishes the F956B source for an exact build as fallback.

→ CHANGELOG.md (device repo)

The three walls (context for every entry)

  1. Software flag → written as root, abl ignores it (proven).
  2. Old code transplant → anti-rollback fuses refuse (proven).
  3. Patched code → boot-chain signatures refuse (no keys, no bootloader bug… yet).

Track D exists to find bug #4.<br><br>2026-10-23 � KernelSU probe: the exploit is self-predicting + the module hunt

  • Breakthrough detail: the payload ships a built-in timing search (FOPS rotation 40-90ms with a persistent index surviving reboots). Pinning an env var disables it � the miss streak was self-inflicted plus thermal drift. Recovery: cold + settled + plugged + unlocked = hit on attempt 1, repeatedly.
  • The E3Q (S928U, SM8650, same KMI) KernelSU module panics on the F956B kernel as the Samsung KDP/RKP/DEFEX docs predict ? exact module build from Samsung's F956B_16_Opensource tree is the confirmed next step.

  • Community artifacts (RMG/GH) are UTF-16LE-committed in git � raw API serves them doubled; clone for real bytes.<br><br>2026-10-23 � DEFEX Safeplace bypassed (verified on-device) + the Keymaster door is reachable

  • Samsung's Safeplace kills /data binaries exec'd from root sh; the bind-mount-over- /system exec bypass is verified working (uid 0, no kill). General-purpose.

  • The CVE-2026-24090 avb-poc now runs on-device through that bypass (qseecom + DMA heaps OK); the remaining step = the boot-loaded keymaster TA's registry label (in QseeComDxe's KeyStoreLoader table) for the APP_LOADED_QUERY ioctl, then the READ_KM_DEVICE_STATE milestone test.<br><br>2026-10-23 � Novelty audit + the TME/ARB system cracked open

?? First-published-by-us findings (the honest list)

  1. The empirical bit-4 verdict � the abl ignores the OEM-unlock flag (written as uid 0, valid digest, all getters TRUE -> locked after reboot; flag TRUE from factory).
  2. Policy-engine-off, double-proven � EnableVariablePolicyEngine=0 in the UEFI config AND the never-written runtime gate byte (0x1f114) in uefisecapp.
  3. Safeplace /data-exec kill -> /system bind-mount bypass, verified live � a general-purpose DEFEX exec bypass on the F956B.
  4. The FOPS self-rotation � the payload's built-in delay search + persistent index (undocumented publicly).
  5. Device-specific maps � VB protocol GUID 8e5eff91 on Samsung DZI1, the keymaster partition label {a11d2a7c-d82a-4c2f-8a01-1805240e6626}, the full DXE driver extraction, the E3Q-module panic confirmation.

?? The ARB system cracked open (building on the gdrci/Research map)

  • The xbl_s.melf = the TME (Trusted Management Engine) firmware: a RISC-V ELF (e_machine 0xF3 = EM_RISCV; the 0xf3 that broke our AArch64 scan!). The TME = Qualcomm's 'Aurora' security coprocessor running FreeRTOS; the AntiRollbackMgr runs INSIDE it.
  • TZ side: qsee_sfs_is_anti_rollback_enabled (object 0x91) + an OEM spare-fuse WRITER (permissions 0x12 gate + /ac/oem_regions_config) � the writer exists in the shipped firmware.
  • Next: RISC-V disasm of the TME's AntiRollbackMgr (capstone CS_ARCH_RISCV) + the fuse-writer gate audit + the hyp PIL ARB table.