live
log / status

Unlock status

One page, always current: the state of the SM-F956B bootloader-unlock research on our own device (F956BXXS4DZI1, update bit 4). Every line below was observed on hardware — no speculation presented as fact. Full evidence lives in OEM unlock gate anatomy.

Right now

AreaStateHow we know
Root (temporary) Working — until reboot su -c id → uid=0 … u:r:ksu:s0; kernelsu LKM live
Re-root after reboot Reproducible — ~2 min hash-pinned reroot.sh; 2/2 cold-boot runs, root at ~40 s
OEM-unlocking row Restorable — hidden by one boot flag resetprop -n ro.boot.other.locked 0 → row appears (RAM-only)
OEM-unlocking switch ON (verified) switch checked=true; stored as settings global oem_unlock_allowed=1
Bootloader LOCKED ro.boot.flash.locked=1, vbmeta.device_state=locked, verifiedbootstate=green
Download Mode unlock Not offered shows only “press up to continue”; never “hold up to unlock bootloader”
Why the request is not seen Toggle writes no partition persistent + devinfo byte-identical to pre-toggle dumps; no oem_lock HAL
KnoxGuard Checking — suspect, not proven ro.boot.kg=0x1; DL app carries PRENORMAL/COMPLETED/BROKEN/CHECKING + tz_kg

What changed today

What we are doing next

  1. Prove what Download Mode actually gates on (the unlock screen is drawn only when a state dword equals 1 — tracing that state).
  2. Byte-diff the toggle live (off → on) to see whether anything besides the framework setting changes.
  3. If the gate holds: factory reset is the standard way to move KnoxGuard Checking → Prenormal, then retry Download Mode.

No partition has been written and nothing has been flashed for any of this. Root is temporary and disappears on reboot by itself. Research is on our own hardware only.