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