v2.1.0 — Evidence-driven scanner, Tier 3b mapping, 10 hardware confirmations

v2.1.0 — Evidence-driven scanner, Tier 3b mapping, 10 hardware confirmations

This release changes the project from a largely SoC-guided recipe into an
evidence-driven workflow: scan both LK slots, inspect the live RPMB state, use
the measured sector, and treat contradictory signals as an investigation rather
than guessing a destructive path.

Since v2.0.0, the repository has accumulated 22 commits, new hardware families,
two hard-block clusters, upstream mtkclient work and the first scanner regression
suite.

Scanner Safety Gates

scan_lk.py now distinguishes binary capability from live device state.

• COMPATIBLE_FULL requires both the known Jz8PNRUF mechanism and detected
  seccfg support.
• A magic-absent LK that still exposes exact mi_get_lock_state now returns
  MAYBE instead of a false COMPATIBLE_SECCFG_ONLY. Issue
  #10
  supplied the real counterexample.
• COMPATIBLE_SECCFG_ONLY is now explicitly a clean Path B candidate, not proof
  that every magic-absent build will unlock.
• RPMB size constants remain informational and carry no score because they occur
  naturally in unrelated binaries.
• COMPATIBLE_FULL no longer claims the live RPMB record is initialized merely
  because the LK contains the code.

Five regression tests cover full Path A, clean Path B, contradictory RPMB
signals, missing seccfg and preloader-like input.

Important Upgrade Note

Do not reuse a v2.0.0 scanner verdict without rescanning.

1. Dump and scan both lk_a and lk_b.
2. Use the result for the active slot.
3. For Path A, dump RPMB and locate Jz8PNRUF; never select a sector from the
   SoC name alone.
4. Treat MAYBE and UNKNOWN as stop conditions requiring manual analysis.
5. Remember that the Path B score tops out at 44/100 by construction; it is not
   a confidence percentage.

New Hardware Evidence

The project now records 10 hardware unlock reports across HyperOS 1, 2 and 3 on
three confirmed SoC families.

• POCO M4 5G thunder / MT6833 light was unlocked persistently by
  @ogmkp in
  #18.
• POCO M4 Pro 4G fleur / MT6781 received another independent persistent
  confirmation from staxifrage in
  #19.
• Redmi Note 13 5G gold / MT6833 received a second independent confirmation
  from Gkhupo in
  #17.

Issue #19 also confirmed slot-asymmetric LK generations on fleur: lk_a was a
Path B candidate while active lk_b was Path A. This independently reproduces
the earlier fire A/B divergence and makes scanning both slots mandatory.

MT6833 Is Driver-Family-Specific

MT6833 no longer has one universal sector:

LK family	Device family	Measured sector	Dump offset
gold	Dimensity 6080	65504	0xFFE000
light	Dimensity 700	57344	0xE00000

The light LK truncates the selected internal address with uxth, reducing its
base candidates to 0xE000. This is measured hardware behavior, not a
storage-vendor guess.

Tier 3b: Writes Persist, Boot Restores The Magic

MT6877 (rubypro and pissarro) and Redmi 12C earth form two measured
hard-block clusters for the RPMB method. A matching pissarropro failure was
reported separately, but without the same public dump-level trace.

• The erase reaches flash and survives a cold BROM re-entry.
• seccfg can persist as state 3.
• A normal boot path restores exactly the eight Jz8PNRUF bytes.
• Fastboot therefore remains locked.

vivaad's cold-cycle experiment in
#8
proves restoration occurs during the normal boot chain, but does not isolate the
exact writer. Documentation now says early boot chain, not preloader, until
a call trace or instrumented stage identifies it.

MT6893 Reclassified

The Xiaomi 11T agate logs in
#14
prove Kamakiri runs on MT6893. The SoC has been removed from the old numeric
Tier 4 inference.

The unlock path remains unresolved:

• MIUI 12.5 persisted seccfg state 3 but remained locked with no live RPMB magic.
• A supplied HyperOS 1.0.15 LK scans COMPATIBLE_FULL and contains the explicit
  string 1st time run MI Lock, write magic.
• Active slot, second LK slot and live HyperOS RPMB state are still pending.

mtkclient Contributions

• mtkclient #307, already
  merged, prevents RPMB result codes from being silently discarded.
• mtkclient #426 proposes a
  generic fix for the optional Thumb NOP that shifted the MT6833 UFS HBA literal.
• mtkclient #427 proposes
  restoring MEID correctly from saved JSON DA state.

PRs #426 and #427 are open and passing CI at release time; they are not described
as merged.

Documentation And Procedure Corrections

• Sector selection is dump-driven and indexed by LK/storage-driver family.
• Hits exactly 16 MiB apart are documented as 16-bit RPMB address aliases, not
  independent copies.
• USB 3.x write failures and Tier 3b boot restoration are treated as separate
  failure modes.
• fastboot getvar unlocked remains authoritative; oem lks is optional.
• Userdata/metadata wipe guidance is conditional. Assume data loss, but issue
  #18 proves an explicit wipe is not universal.
• Dead legacy issue links and unsupported device/SoC pairings were removed.
• Device reports now request storage identifiers and active-slot/LK-build data.

Known Limitations

• No verified RPMB-method bypass exists yet for the Tier 3b restoration clusters.
• The exact early-boot writer restoring Jz8PNRUF is not identified.
• Issue #10 still needs its RPMB dump and current fastboot identity.
• Issue #14 still needs lk_b, active-slot and live RPMB data.
• Issue #19 still needs exact LK build strings and hashes.
• The alternative LK-public-key/token-forging approach linked in issue #13 has
  no public persistent-unlock proof for rubypro yet.

Credits

Hardware evidence and corrections in this cycle came from ogmkp, staxifrage,
vivaad, LucaCraft89, burg1ar, Gkhupo, katavnnn, miromraz, piotrurban and the
other testers who preserved logs, hashes and negative results instead of only
reporting success or failure.

Full comparison:
v2.0.0...v2.1.0

v2.0.0 — 6 devices, 3 SoCs, full HyperOS lifecycle

Community expansion release: 6 hardware unlocks confirmed across 4 SoCs, covering the full HyperOS lifecycle (1, 2, 3). New SoC-specific RPMB sector discovery, A/B slot divergence after OTA documented, and community-contributed improvements.

What's new since v1.0.0

• 5 new Tier 1 devices proven on hardware by community testers
• RPMB sector is SoC-specific — MT6781/MT6769Z = 57344, MT6833 = 65504. Always grep before erasing. (Discovered by KTS618)
• lk_a ≠ lk_b after OTA — slot A and slot B can carry different LK builds. Always scan both. (Discovered by piotrurban)
• HyperOS 1 + 2 + 3 confirmed — the RPMB lock mechanism is consistent across all HyperOS generations
• Step 0 added — mandatory sector discovery via grep -boa "Jz8PNRUF" rpmb_dump.bin
• Linux pre-flight documented — ModemManager kill + kernel module unload (PR #6 by miromraz)
• scan_lk.py as decision gate — README restructured to route users through the scanner first (PR #5 by miromraz)
• Windows struct.error FAQ — documented USB bulk driver limitation + WSL2 / Live USB workaround
• Boot flow diagram — mi_check_magic() decision tree added to README

Tested on

Device	Codename	SoC	Firmware	RPMB Sector	Result	Tester
POCO M4 Pro 4G	fleur	MT6781	HyperOS 1.0.11.0	57344	Unlocked, persistent	Jz8root
Redmi Note 11 4G	fleur (2201117SY)	MT6781	HyperOS 1.0	—	Unlocked (Path B, seccfg only)	miromraz
Redmi Note 11S Global	miel	MT6781	HyperOS 1.0.9.0	57344	Unlocked, persistent	ITSME
Redmi Note 11S	miel	MT6781	HyperOS 1.0.9.0	57344	Unlocked, persistent	kwhj4ff67r-crypto
Redmi Note 13 5G	gold	MT6833	HyperOS 3.0.9.0 / Android 15	65504	Unlocked, persistent	KTS618
Redmi 12	fire	MT6769Z	HyperOS 2.0.207	57344	Unlocked, persistent	piotrurban

Quick start

git clone https://github.com/Jz8Root/xiaomi-hyperos-bootloader-unlock
cd xiaomi-hyperos-bootloader-unlock

# Step 0: Scan your LK binary (scan BOTH slots)
python3 scan_lk.py /path/to/lk_a.bin
python3 scan_lk.py /path/to/lk_b.bin

# Step 0b: Find your RPMB sector (do NOT skip)
python3 mtk.py da rpmb r rpmb_dump.bin
grep -boa "Jz8PNRUF" rpmb_dump.bin
# sector = byte_offset / 256

# Then follow README.md → "The Method — 3 Commands"

Warnings

• Backup RPMB and NV partitions before anything
• This wipes your data (factory reset on first boot after unlock)
• BROM V6 (MT6789+) is patched in hardware — this method won't work
• RPMB sector is NOT universal — always grep the dump first. Sector 57344 is only confirmed for MT6781/MT6769Z. MT6833 uses 65504.
• Scan both LK slots — after an OTA, lk_a and lk_b can diverge
• Use Linux for the RPMB erase step — Windows USB drivers cause struct.error
• Voids manufacturer warranty

Help wanted

If you successfully unlock another device, please file a Device Test Report. Each successful report expands the compatibility database for everyone.

Priority targets: Redmi 9A/9C (MT6762), Redmi 12C (MT6765/MT6769) — issue #81 has been waiting since 2021.

Links

• XDA thread
• mtkclient — the foundation

Credits

• bkerler/mtkclient — Xiaomi MTK BROM + DA framework
• The Kamakiri exploit researchers
• miromraz — PR #5 (README restructure), PR #6 (Linux pre-flight), Path B confirmation, SK Hynix RPMB layout
• KTS618 — MT6833 sector 65504 discovery, first HyperOS 3.0 confirmation
• piotrurban — lk_a/lk_b OTA divergence discovery, first HyperOS 2.0 confirmation
• ITSME — first independent hardware confirmation (miel)
• kwhj4ff67r-crypto — miel replication
• Everyone who reported the seccfg bug on GitHub — your reports helped map the scope

Researched by Jz8root. Community tested.

v1.0.0 — Initial public release

First public release of the HyperOS/MIUI14+ bootloader unlock method, reverse-engineered from the Little Kernel bootloader and proven with RPMB dumps.

The problem this solves

Since MIUI 14.0.3 and HyperOS, mtkclient da seccfg unlock reports success but the bootloader remains locked after reboot. This bug has been open in mtkclient for 2+ years across multiple Xiaomi MediaTek devices (#81, #764, #1219, #1405).

Root cause: Xiaomi added a second lock layer in RPMB that overrides seccfg.
The fix: erase the RPMB magic — the LK then falls back to seccfg, which mtkclient can write to UNLOCK.

What's in this release

• Full technical writeup (README.md) — root cause analysis, dual-layer lock mechanism, the 3-command unlock method
• Ghidra decompilation proof (proof/VERIFICATION.md) — decompiled mi_check_magic function, RPMB before/after dumps with SHA256, mtkclient source audit
• scan_lk.py — LK binary compatibility scanner with 0-100% verdict scoring
• Device compatibility database (COMPATIBILITY.md) — Tier 1-4 device classification
• GitHub issue template for structured community device reports
• AGPL-3.0 license

Tested on

Device	Codename	SoC	Firmware	Result
POCO M4 Pro 4G	fleur	MT6781	HyperOS OS1.0.11.0.TKEEUXM	Unlocked, persistent

Quick start

git clone https://github.com/Jz8Root/xiaomi-hyperos-bootloader-unlock
cd xiaomi-hyperos-bootloader-unlock

# Scan your LK binary first
python3 scan_lk.py /path/to/lk_a.img

# Then follow README.md → "The Method — 3 Commands"

Warnings

• Backup RPMB and NV partitions before anything
• This wipes your data (factory reset on first boot after unlock)
• BROM V6 (MT6789+) is patched in hardware — this method won't work
• Only HyperOS 1 has been verified — HyperOS 2/3 untested
• Voids manufacturer warranty

Help wanted

If you successfully unlock another device, please file a Device Test Report. Each successful report expands the compatibility database for everyone.

Links

• XDA thread
• mtkclient — the foundation

Credits

• bkerler/mtkclient — Xiaomi MTK BROM + DA framework
• The Kamakiri exploit researchers
• Everyone who reported the seccfg bug on GitHub — your reports helped map the scope

---

Researched & tested by Jz8root.