README structure: scan_lk verdict should drive the procedure, not appear as optional tooling

[miromraz]

Hi, first off — the Ghidra work and scan_lk.py are great. Sharing a data point that exposes a README structure issue.

Device: Redmi Note 11 4G (fleur, 2201117SY), MT6781, SK Hynix UFS H9HQ54AECMMDAR
Firmware: HyperOS V816.0.1.0.TKEEUXM (Android 13, EEA)
LK build string: fleur-d01540d34-20220430143603-20230313203522
LK md5: 701bbd3ee76e780b030d8568368a7a4e

scan_lk.py verdict on lk_a.bin:

VERDICT: COMPATIBLE_SECCFG_ONLY  (52/100)
[MAGIC] Jz8PNRUF : ✗ ABSENT

Successfully unlocked with da seccfg unlock alone — no RPMB erase needed. lks=0, unlocked=yes, secure=no verified in fastboot.

The issue

The README lists the 3-step (rpmb-read → rpmb-erase → seccfg-unlock) as the primary procedure for HyperOS / MIUI 14+. scan_lk.py is introduced afterwards as a "Compatibility Scanner." But for the substantial set of fleur units shipped with the older MIUI-era LK (mine builds on 2022-04-30 per the string above), the magic is genuinely absent and the RPMB erase step is unnecessary — it zeros already-zero bytes.

A less careful reader would do an irreversible RPMB write on a device that didn't need it.

Suggested change

Flip the flow in the README:

1. Dump LK: mtk r lk_a lk_a.bin
2. python3 scan_lk.py lk_a.bin ← decision point
3. Branch:
   • Verdict COMPATIBLE_FULL → full 3-step procedure
   • Verdict COMPATIBLE_SECCFG_ONLY → da seccfg unlock only

This also strengthens the COMPATIBILITY table — fleur should arguably be split by LK build / firmware version (the OS1.0.11.0 LK that proves the Tier 1 case is a different binary from many other "fleur" units in the wild), not lumped by codename alone.

Happy to PR a restructured README if that's helpful.

[Jz8Root]

---

You're right — scan_lk.py should be the decision point, not an afterthought. Restructuring the flow.

The current README assumes the worst case (HyperOS LK with RPMB magic). Your device proves that even within the
same codename (fleur), different firmware builds ship fundamentally different LK binaries — yours from April 2022
doesn't implement mi_check_magic() at all.

New flow will be:

1. Dump LK
2. Run scan_lk.py → decision point
3. Branch: COMPATIBLE_FULL → 3-step / COMPATIBLE_SECCFG_ONLY → seccfg only

I'll also split the compatibility table by LK build hash, not just codename. Your data point makes it clear that
"fleur" spans at least two distinct LK generations.

Adding your device to Tier 1:

• Redmi Note 11 4G (fleur, 2201117SY) — SK Hynix UFS — COMPATIBLE_SECCFG_ONLY — UNLOCKED via seccfg only
• LK build: fleur-d01540d34 (2022-04-30) — no RPMB magic

Go ahead and PR the README restructure — you found it, you should own the fix.

Thanks for the thorough analysis — three solid issues in one day, all actionable. This is exactly the kind of
contribution that makes the project better.