Redmi 12 4g - seccfg says "already unlocked" but fastboot still shows it as locked

[MrMatias123]

Device model

Redmi 12

Codename

fire

SoC

MT6769Z

Firmware version

HyperOS 1.0.8.0.UMXMIXM

Which step failed?

Verification (fastboot oem lks)

Full terminal output

python mtk.py da seccfg unlock

DaHandler - [LIB]: Device is in BROM mode. No preloader given, trying to dump preloader from ram.
DAXFlash - Uploading xflash stage 1 from MTK_DA_V5.bin
XFlashExt - Patching da1 ...
Mtk - Patched "Patched loader msg" in preloader
Mtk - Patched "hash_check" in preloader
Mtk - Patched "Patched loader msg" in preloader
Mtk - Patched "get_vfy_policy" in preloader
XFlashExt - Patching da2 ...
XFlashExt - Security check patched
XFlashExt - DA version anti-rollback patched
XFlashExt - SBC patched to be disabled
XFlashExt - Register read/write not allowed patched
DAXFlash - Successfully uploaded stage 1, jumping ..
Preloader - Jumping to 0x200000
Preloader - Jumping to 0x200000: ok.
DAXFlash - Successfully received DA sync
DAXFlash - Sending emi data ...
DAXFlash - DRAM setup passed.
DAXFlash - Sending emi data succeeded.
DAXFlash - Uploading stage 2...
DAXFlash - Upload data was accepted. Jumping to stage 2...
DAXFlash - Boot to succeeded.
DAXFlash - Successfully uploaded stage 2
DAXFlash - DA SLA is disabled
DAXFlash - EMMC FWVer:      0x0
DAXFlash - EMMC ID:         Y0S256
DAXFlash - EMMC CID:        9b010059305332353600ed5408e7ca8f
DAXFlash - EMMC Boot1 Size: 0x400000
DAXFlash - EMMC Boot2 Size: 0x400000
DAXFlash - EMMC GP1 Size:   0x0
DAXFlash - EMMC GP2 Size:   0x0
DAXFlash - EMMC GP3 Size:   0x0
DAXFlash - EMMC GP4 Size:   0x0
DAXFlash - EMMC RPMB Size:  0x1000000
DAXFlash - EMMC USER Size:  0x3a3e000000
DAXFlash - Starting DA extensions ...
DAXFlash - Extensions were accepted. Jumping to extensions...
DAXFlash - Boot to succeeded.
DAXFlash - DA Extensions successfully added at 0x4fff0000
Main - Handling da commands ...
XFlashExt - Detected V4 Lockstate
Sej - AES128 CBC - HACC init
Sej - AES128 CBC - HACC run
Sej - AES128 CBC - HACC terminate
Sej - AES128 CBC - HACC init
Sej - AES128 CBC - HACC run
Sej - AES128 CBC - HACC terminate
SecCfgV4 - hwtype found: V4
Sej - AES128 CBC - HACC init
Sej - AES128 CBC - HACC run
Sej - AES128 CBC - HACC terminate
Done |██████████| 100.0% Write: (0x200/0x200),0.00 MB/s
DaHandler - Successfully wrote seccfg.
PS C:\Program Files\mtkclient>


______________________________________________________________
 python .\scan_lk.py "C:\\lk_b.bin"
[*] Reading C:\\lk_b.bin...
[*] Size: 8,388,608 bytes
[*] Scanning...
══════════════════════════════════════════════════════════
  LK BINARY SCAN REPORT — MTKClient Unlock Analyzer
══════════════════════════════════════════════════════════

  File size  : 8,388,608 bytes (8.0 MB)
  MD5        : 4646ef8af86814a0f0c50629389a3411
  SHA256     : 20c514c5d871fea02c7c370e925e6918...

  ┌─────────────────────────────────────────┐
  │  VERDICT: COMPATIBLE_SECCFG_ONLY         │
  │  Score  : 52/100 (52%)                        │
  │  Method: seccfg unlock only (no RPMB loc│
  └─────────────────────────────────────────┘

  [MAGIC] Jz8PNRUF : ✗ ABSENT

  [RPMB] Type : UFS_Samsung_0x400000
    magic                : 0x3FE0
    lock_state_len       : 0x40E0
    signature_data       : 0x41E0

  [RSA]  Modulus : ✓ FOUND
    @ 0x0010E508
    Key size: 2048 bits

  [SECCFG] Version : generic

  [FUNCTIONS] 7 detected:
    ✓ mi_get_lock_state: Reads RPMB lock state — overrides seccfg when magic present
    ✓ get_lock_state: Main lock state function — reads seccfg + RPMB
    ✓ seccfg_set_lock_state: Writes lock state to seccfg partition
    ✓ rpmb_read: Reads N bytes from RPMB
    ✓ rpmb_write: Writes N bytes to RPMB
    ✓ fastboot_oem_lks: Hidden fastboot OEM lock state commands
    ✓ verify_unlock_sig: RSA signature verification for unlock token

  [FASTBOOT] 6 OEM commands:
    ✓ oem lks @ 0x0009D560
    ✓ oem setmtklks @ 0x0009D3B4
    ✓ oem chkmtklks @ 0x0009D3A4
    ✓ flashing get_unlock_ability @ 0x0009D580
    ✓ oem unlock @ 0x0009D568
    ✓ oem lock @ 0x0009D574

══════════════════════════════════════════════════════════
  RPMB magic not found. seccfg alone should work (MIUI13 or older).
══════════════════════════════════════════════════════════
PS C:\Users\xiaomi-hyperos-bootloader-unlock> python .\scan_lk.py "C:\Program Files\mtkclient\lk_a.bin"
[*] Reading C:\Program Files\mtkclient\lk_a.bin...
[*] Size: 8,388,608 bytes
[*] Scanning...
══════════════════════════════════════════════════════════
  LK BINARY SCAN REPORT — MTKClient Unlock Analyzer
══════════════════════════════════════════════════════════

  File size  : 8,388,608 bytes (8.0 MB)
  MD5        : 2f09e417ac0a2795450b68ce2fe9e92e
  SHA256     : 7af84c911cf68a20c5f305a23cea5ce2...

  ┌─────────────────────────────────────────┐
  │  VERDICT: COMPATIBLE_SECCFG_ONLY         │
  │  Score  : 52/100 (52%)                        │
  │  Method: seccfg unlock only (no RPMB loc│
  └─────────────────────────────────────────┘

  [MAGIC] Jz8PNRUF : ✗ ABSENT

  [RPMB] Type : UFS_Samsung_0x400000
    magic                : 0x3FE0
    lock_state_len       : 0x40E0
    signature_data       : 0x41E0

  [RSA]  Modulus : ✓ FOUND
    @ 0x0010E508
    Key size: 2048 bits

  [SECCFG] Version : generic

  [FUNCTIONS] 7 detected:
    ✓ mi_get_lock_state: Reads RPMB lock state — overrides seccfg when magic present
    ✓ get_lock_state: Main lock state function — reads seccfg + RPMB
    ✓ seccfg_set_lock_state: Writes lock state to seccfg partition
    ✓ rpmb_read: Reads N bytes from RPMB
    ✓ rpmb_write: Writes N bytes to RPMB
    ✓ fastboot_oem_lks: Hidden fastboot OEM lock state commands
    ✓ verify_unlock_sig: RSA signature verification for unlock token

  [FASTBOOT] 6 OEM commands:
    ✓ oem lks @ 0x0009D560
    ✓ oem setmtklks @ 0x0009D3B4
    ✓ oem chkmtklks @ 0x0009D3A4
    ✓ flashing get_unlock_ability @ 0x0009D580
    ✓ oem unlock @ 0x0009D568
    ✓ oem lock @ 0x0009D574

══════════════════════════════════════════════════════════
  RPMB magic not found. seccfg alone should work (MIUI13 or older).
══════════════════════════════════════════════════════════


 .\fastboot.exe oem lks
(bootloader) lks = 1

.\fastboot.exe getvar unlocked
unlocked: no

.\fastboot.exe getvar secure
secure: yes

Operating system

windows 11

USB port type

USB 2.0 (black port)

Did you use a preloader file?

No — let mtkclient auto-detect

What have you already tried?

So mtkclient "says" it wrote successfully, but the phone still behaves like it's locked.

Things I already tried:

• Ran the unlock command several times (at first it wasn't writing anything new)
• Locked and unlocked again to force a real write
• Checked that "OEM unlocking" is enabled in Developer Options (it is)

Something that might help:
I looked at the seccfg partition file in hex, before and after writing. There was a value that changed from 3 to 1 after forcing lock/unlock, but even so the phone still doesn't recognize itself as unlocked. So I suspect there's something else (maybe a signature or extra verification) that isn't updating properly, besides that value.

I don't know much about this technically, so any help understanding what might be going on, or if there's anything else I could try, would be really appreciated. Happy to provide more info or run more tests if needed.

[Jz8Root]

Sorry for the thirteen day wait, and this one deserved a faster answer than most: you are the first eMMC report on this repo, everyone else confirmed so far is UFS, and that puts you somewhere the scanner and the README have never actually been tested.

Why this one is a genuine contradiction, not a normal Path B

Your scan says the magic is absent, which normally means straightforward Path B: run seccfg unlock and you're done. But look at what else it found:

✓ mi_get_lock_state: Reads RPMB lock state — overrides seccfg when magic present
✓ rpmb_read / rpmb_write

mi_get_lock_state is not a generic string, it is one of the two functions on this repo that actually proves an RPMB lock layer exists, and by its own description it overrides seccfg whenever the magic is present. A LK that carries this function and the RPMB read/write primitives, but supposedly has no active RPMB layer, is not a clean Path B. It is a LK that either genuinely lacks the layer, or has it with a magic the string search does not recognize, because your device sits on a branch of the RPMB logic nobody has confirmed yet:

DAXFlash - EMMC RPMB Size:  0x1000000

Every Tier 1 device so far is UFS with a 4 MiB RPMB (0x400000). Yours reports 0x1000000, 16 MiB. The decompiled LK has two branches keyed on exactly this value:

if (rpmb_type == 0x1000000) { offset = 0xe000; }        // ALT branch, never confirmed on hardware
else if (rpmb_type == 0x400000) { offset = 0x3fe0; }     // the branch every Tier 1 device uses

You are the first report that lands on the first branch. Nobody has dumped that offset on a real device before, which is the honest reason the scanner's string search might be looking in the wrong place rather than proving there is no lock layer at all.

The detail in your own report that settles part of this

I looked at the seccfg partition file in hex, before and after writing. There was a value that changed from 3 to 1 after forcing lock/unlock, but even so the phone still doesn't recognize itself as unlocked.

Against this repo's seccfg table (1 = DEFAULT, 3 = UNLOCKED, 4 = LOCKED): at some point your seccfg genuinely held 3, UNLOCKED, and fastboot getvar unlocked still did not say yes. That is not "the write didn't take." That is seccfg agreeing to unlock while something else kept the device locked regardless, which is exactly what an active RPMB layer does on every other device in this repo when its magic is present. It argues against "no RPMB layer" more than your scan's absent magic argues for it.

Your later cycle brought it back down to 1, DEFAULT, which is why the current state reads locked again either way.

What actually needs to happen: dump your RPMB

You have run seccfg unlock and hex-inspected the seccfg partition, but you have never run:

python3 mtk.py da rpmb r rpmb_dump.bin
grep -boa "Jz8PNRUF" rpmb_dump.bin

This is the one test that settles it in either direction. If the magic shows up somewhere, this is Path A with an offset this repo has never documented, and the erase procedure applies (with a sector nobody has confirmed yet, so treat the first attempt as exploratory). If it genuinely does not appear anywhere in the dump, that is real evidence for "no lock layer," stronger than an absent string in the 8 MB LK file, and the seccfg discrepancy above becomes the separate mystery to chase instead.

Two more things worth trying

fastboot flashing get_unlock_ability, which your LK exposes (it showed up in your fastboot scan), and this repo's README has never once mentioned it. fastboot oem lks is the one everyone's told to check, but it is a hidden OEM command that some builds don't implement even when genuinely unlocked (seen on two other threads here). Try both and report both.

Don't reboot between attempts. Every confirmed device on this repo turned out to have a preloader that rewrites the RPMB magic on every startup, the Mi logo alone is enough. If your branch has an active lock layer at all, any boot between your erase attempts and your verification would have silently restored it. If you retest, stay in BROM the whole time: unplug, hold Vol+ and Vol-, replug, never the power button, straight through to the next da command.

Also worth ruling out

mtkclient had a bug (fixed upstream last night, bkerler/mtkclient#307) where certain RPMB error codes were silently swallowed and reported as success. "Successfully wrote seccfg" and a write that visibly changed the hex value are not the same category of proof as that bug taught us the hard way on a different device. Worth keeping in mind if anything here doesn't add up after the dump.

If you can run the RPMB dump and post the grep output either way, that's the one answer this whole thread has been missing.