Track A history — bootloader unlock attempts (all closed)
The full progression of bootloader-unlock attempts on the bit-4 SM-F956B. Every flash
was approved by the device owner beforehand; every failure was recoverable via Odin with
the stock firmware.
Attempt matrix
| # | What was flashed | Result |
|---|---|---|
| 1 | Stock EZIH BL with only abl.elf.lz4 replaced by the bit-2 (UI7, F956BXXU2BYD9) abl |
Download mode: "SW REV CHECK FAIL!!!" — anti-rollback fuse refused the bit-2 abl. Safe no-op. |
| 2 | Stock EZIH BL with the bit-4 DZI1 abl alone | Odin PASS → boots to download mode (xbl↔abl handoff mismatch — mismatched chain). |
| 3 | DZI1 abl + xbl_s + xbl_config (full DZI1 chain) in the EZIH BL | Odin PASS → still download mode (older abl can't boot the newer OS). |
| 4 | Full DZI1 downgrade (BL+AP+CP+CSC_OXM, wipe) | Odin PASS → boots coherent (Android 16 / One UI 8.5). No OEM toggle (UI dump: 0 nodes), oem_unlock_supported empty, other.locked=1. |
| 5 | OEM-unlock flag write as uid 0 (no flash — service path) | Flag written + digest valid → reboot → abl ignores it. See oem-unlock-verdict.md. |
What this established
- Anti-rollback fuses are burned to bit 4. A bit-2 abl (which still contains the unlock code) is refused by hardware before execution. There is no way to un-burn.
- The bit-4 abl doesn't just hide the toggle — it doesn't read the unlock flag at all. The DZI1 firmware even ships with the flag set (software "unlock allowed") and the bootloader still refuses. The unlock path is stripped from the bootloader, not the UI.
- Patching a bootloader binary is impossible without Samsung's signing keys — any byte change breaks the verified-boot chain signature. (This is why the bug-hunt in Track D targets behavioral flaws in the shipped code, not modifications.)
- Recovery asset used throughout: the stock EZIH BL + full factory firmware directory — every brick so far was recoverable.