Fold 6 breakthroughs

• The render path found: One UI recolours via SemWT (Semantic Wallpaper Theme) — hundreds of fabricated RRO overlays (.frro) in /data/resource-cache/. The framework palette lives in SemWT_MonetPalette + SemWT_G_MonetPalette (+ one per app).
• Format decoded: FRRO magic + 48-byte header + protobuf mapping system_accent1/2/3_<N>, neutral1/2_<N>, sem_* slots to 32-bit ARGB (tone = 100 − N/10). Full byte-perfect codec + HCT recolour generator built (frro.py + monet.py).
• polyqon recolor --seed now regenerates the overlays for any colour. (Apply still needs a full reboot — OverlayManager caches in system_server.)
• See /tools/polyqon/ for the full story.

• New project: PolyQon — free Samsung One UI theming, rebuilding the old closed-source Hex Installer in the open. GPL-3.0, no paywall.
• Theme-system mapped on a live One UI 8.5 Fold 6: engine = themestore/themecenter, data in /data/overlays/ (currentstyle/, main_packages/, jsonfiles/, …).
• Colour-patch core working — polyqon.py does the ARGB ↔ little-endian hex-patch that Hex Installer was famous for.
• Roadmap: map live colour slots → re-sign + apply flow → CLI → GitHub. See /tools/polyqon/.

• Free firehose: S928U_LOADER_BIT4.elf (S24 Ultra, SM8650 = Fold 6 SoC) — a plaintext ELF in leefshitz2/Qualcomm_Loaders (FirehoseLoaders/Samsung_Loaders/). Verified: devprg, lanai/8650, full firehose command set, entry 0x22126000.
• The Alephgsm .rtc "encrypted loaders" are the same firehose, just AES-wrapped DRM. The plaintext was sitting free in a third repo the whole time.
• EDL entry solved: XBL contains dpGnd LOW, enter FEDL + boot_fedl_check → the D+ short cable (D+→GND) is the native EDL trigger, not test points.
• Full route is now $0 + ~$10 cable: firehose free, clients free, GPT map confirmed (init_boot=188944, vbmeta=4159488, devinfo=26556, frp=26428).
• Honest scope unchanged: raw UFS read/write below ABL; does NOT blow QFPROM fuse or bypass AVB.

• Overturns two prior conclusions. The bit-4 abl is NOT AES-encrypted — it's an LZMA-compressed UEFI Firmware Volume. Extracted the 5 ABL apps (LinuxLoader 2.0 MB, Odin, Cryptest, QuestSOD/USB) with fiano. The whole bootloader is now RE-able offline.
• The OEM-unlock code was never stripped — setOEMFlags/IsUnlocked/IsUnlockCritical/ GetUnlockCount/milestone are present in BOTH bit-2 and bit-4. The real block is one hardcoded androidboot.other.locked=1 in SecUpdateCmdLine (bit-4 only).
• Unlock primitive mapped: setOEMFlags → SCM 0x2000801 → vaultkeeper qsee_fuse_write(oem_sw_fuse = 0xc1) → QFPROM (one-way OTP, TZ-gated). Confirms the milestone/fuse is the one-way gate (the keymaster 0x202 READ -15).
• SM8650 VerifiedBoot GUID = {8e5eff91-21b6-47d3-af2b-c15a01e020ec}.
• CVE-2026-24090 stays ruled out (compile-time VB2 / atlas fix — the runtime GetVbmetaType() is Samsung's BLDP partition-type tracker, not the libavb VB2 gate).

• su -c id from adb shell → uid=0(root) context=u:r:ksu:s0, SELinux Enforcing, kernelsu 499712 0 - Live in /proc/modules. KernelSU v3.4.2 (250965249 fork, KDP/RKP/DEFEX/NO_PATCH_TEXT, vermagic byte-exact DZI1) loaded at runtime — no boot image touched, nothing flashed.
• Root = per boot. Reboot returns to stock; the re-root runbook takes ~2 min: exploit (hits 1/1: CPU-70% limit off + mm_struct_sz 0x400) → one root request running f956b-chain.sh (bind ksud→/system/bin/logcat + .ko→/system/etc/hosts, logcat insmod /system/etc/hosts allow_shell=1 — DEFEX-safe paths, insmod only, no post-fs-data → no reboot) → su.
• Two hidden killers cracked: Samsung's restricted_device_performance 70% cap (silently destroyed the race timing) and DEFEX Safeplace (kills /data execs from root; the bind-over-/system trick + shell-context exec both pass).
• Loading the module flips SELinux to Enforcing instantly → the bootstrap daemon socket dies → all post-load work must be same-request or via su (the BuSung-dev PR #317 playbook, verified on our device).
• The unlock itself remains closed (bit-4 abl ignores the flag — proven). The milestone fuse is the gate. Next: QSEE/RPMB research resumes with reliable su.

• The GPT surgery executed byte-exact: vbmeta_s → xbmeta_s in both GPT copies (the name, the entry CRC recomputed), verified live on the disk.
• The reboot: the boot SURVIVED (no crash) — but the state = unchanged: locked, green, the milestone still set. The READ = still -15.
• The verdict: the Samsung ABL uses the compile-time VB2 status (the atlas fix), so the runtime vbmeta check that the 24090 exploit leans on is not present on this build. The milestone fuse = the gate, and it is one-way.
• The devinfo + the vbmeta-rename = both ruled out. The remaining doors: the EDL firehose (no public F956B loader), the KernelSU module (the OSRC build), or a TZ-side primitive.

• The devinfo partition (4 KB) holds the Samsung device-state struct — the magic “SAMANDR-BOOT!” + the is_unlocked / is_unlock_critical flags — in a PLAIN, non-AVB-verified partition.
• The VerifiedBootDxe’s RWDeviceState reads it (“Succeed using devinfo!”) — a whole new lever: a 4 KB flag flip with a trivial revert, versus the high-risk vbmeta-rename.
• The patch is staged (the backup + the unlocked variant on disk). Not flashed yet — the write awaits the explicit go.

• The MINK secure-world transport = fully alive on the F956B: the AppLoader object loaded the keymaster TA, the CKMHal opened, and GET_VERSION answered: Keymaster 5.3, app 5.3000.
• READ_KM_DEVICE_STATE (0x202) EXECUTED — ret=0, status=0, the TA processed the unlock-state read.
• The inner rsp = -15 = decoded: it is the MILESTONE GATE (the normal AVB2 boot set the milestone, so the TA refuses the device-state commands — the documented behavior). The buffer was never the problem. The READ/WRITE unlock after the vbmeta-rename → the NO_AVB boot → the milestone never called. One prerequisite left before the unlock state is readable.
• The public reference (the kasnria001 noavb poc) is still a work in progress at this step — happy to document the full chain end-to-end for anyone picking it up.

• Pulled + decoded the atlas4381 CVE-2026-24090 PoC end-to-end: the exact LOAD_APP → SET_MEM_PARAM → GET_VERSION → READ_KM_DEVICE_STATE (0x202) flow, the DeviceInfo layout (magic “ANDROID-BOOT!”, 0xCA8), and the crucial “tolerate the load failure, use the returned app_id” detail.
• Extracted libQSEEComAPI.so from the device: TAs register under PLAIN names (vaultkeeper, skm), QSEECom_app_load_query = stubbed in the lib, and the Samsung ioctl scheme is NOT the QCom 0x97 numbers (send_cmd = 0x424).
• Built kmstate-read (our READ-only 0x202 probe) + ran it live: qseecom open OK, DMA OK — the boot keymaster LOAD_APP = EINVAL with no app_id returned.
• Safeplace hardened since yesterday: the bind-mount trick is flaky now; the workaround = shell-context exec + chmod 666 /dev/qseecom.

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:

• Device-specific deep dive: f956b-bootchain-research
• General knowledge: android-rooting-field-guide
• Firmware tooling: Orbit

---

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)

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)

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)

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)

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)

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.

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)

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)

---