[HELP] scan_lk.py reports 100% COMPATIBLE and correct sector, but RPMB erase/write silently doesn't persist on SK Hynix UFS (H9QT1G6DN6X132, MT6877)

[LucaCraft89]

Device model

Redmi Note 12 Pro+ 5G

Codename

rubypro

SoC

MT6877

Firmware version

HyperOS OS2.0.15.0.UMOEUXM

Which step failed?

Step 3 — seccfg unlock (da seccfg unlock)

Full terminal output

TOO LONG cannot post

Operating system

Fedora 44

USB port type

USB 2.0 (black port)

Did you use a preloader file?

No — let mtkclient auto-detect

What have you already tried?

Summary

Reporting a new hardware data point for the compatibility database, and a hardware-level blocker that isn't a problem with this repo's logic.

scan_lk.py correctly identified my device as COMPATIBLE (100/100), correctly found the magic string, correctly identified all 8 functions and the 3 fastboot OEM commands, on both lk_a.bin and lk_b.bin. The RPMB magic string was also found at the expected byte offsets via grep, matching the documented sector math exactly. Everything about the detection side worked perfectly.

However, actually erasing/overwriting the RPMB magic region does not work on this hardware — the RPMB write reports success at the mtkclient level but the underlying flash never changes. I've filed the mtkclient-side details as a separate issue there ([link once filed]), since it looks like an mtkclient RPMB-write bug rather than something wrong in this repo. Posting here too because it's relevant to the compatibility database and the "Other UFS types (unverified)" section of the README.

Device / Environment

• SoC: MT6877 / MT6877V / MT8791N (Dimensity 900/1080/7050)
• UFS chip: H9QT1G6DN6X132 — SK Hynix, MID 0xad
• HyperOS device, HW code 0x959, Target config 0xe7, SBC/SLA/DAA all enabled
• Exploit: Kamakiri, via mtkclient, mt6877_payload.bin

scan_lk.py output (both slots)

$ python3 scan_lk.py lk_a.bin
══════════════════════════════════════════════════════════
  LK BINARY SCAN REPORT — MTKClient Unlock Analyzer
══════════════════════════════════════════════════════════

  File size  : 8,388,608 bytes (8.0 MB)
  MD5        : c54a9fb0cc6f2ddf5ab558822e6b4746
  SHA256     : 604ce2891c3a8d658e5f1d00363e7358...

  ┌─────────────────────────────────────────┐
  │  VERDICT: COMPATIBLE                     │
  │  Score  : 100/100 (100%)                       │
  │  Method: RPMB erase (sector 57344) + sec│
  └─────────────────────────────────────────┘

  [MAGIC] Jz8PNRUF : ✓ FOUND
    @ 0x0013F254

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

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

  [SECCFG] Version : generic

  [FUNCTIONS] 8 detected:
    ✓ mi_check_magic: Checks RPMB magic — returns 0 (present) or 3 (absent)
    ✓ 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] 3 OEM commands:
    ✓ oem lks @ 0x000AB428
    ✓ oem unlock @ 0x000AB49C
    ✓ oem lock @ 0x000AB4A8
══════════════════════════════════════════════════════════

lk_b.bin scan produced an identical verdict/score/functions (different MD5/SHA256: 56b82bad9a89f80f8262f1a87d004a80 / bd7e482599c681d1fc820a8ee38ca2af...), same magic offset 0x0013F254. Both slots agree, so this isn't the slot-mismatch issue documented elsewhere in the README (fire/MT6769Z case).

Note: the scanner labels the RPMB type as UFS_Samsung_0x400000 — this may be worth flagging in the report output for non-Samsung chips, since my actual UFS is SK Hynix and it's possible the offsets/frame layout constants baked in for "Samsung" don't transfer 1:1 to Hynix's actual RPMB controller behavior, even though the magic string itself was found at the matching location in the LK binary.

grep confirmation of magic location

$ grep -boa "Jz8PNRUF" rpmb_dump.bin
14680064:Jz8PNRUF
31457280:Jz8PNRUF

14680064 / 256 = 57344 — matches the scanner's predicted sector exactly. 31457280 / 256 = 122880 is a second, undocumented occurrence (possibly a backup/mirror copy — not currently covered in the README's sector reference table).

What went wrong

Following the documented Path A procedure exactly (RPMB erase both sectors → seccfg unlock), then verifying:

fastboot getvar unlocked → unlocked: no
fastboot oem lks         → lks = 1
fastboot getvar secure   → secure: yes

Never moved off the locked state, across:

• initial erase + unlock
• forced seccfg lock → unlock cycle (to rule out a "no-op because already unlocked" skip)
• full cold power-off + fresh fastboot boot before every check (to rule out cached-state reads)
• explicit zero-fill write instead of erase (to rule out an erase-specific mtkclient bug)

Every RPMB write/erase operation reported success with a consistent derived key, but a re-dump immediately after each operation showed the magic string still present, byte-for-byte unchanged, at both offsets. Full logs are in the mtkclient-side issue.

Ask

• Should the "Other UFS types (unverified)" section / compatibility DB include a note that scan_lk.py detection succeeding doesn't guarantee the RPMB write itself will persist on non-Samsung UFS chips?
• Is there a known-good SK Hynix device in the confirmed list I could cross-reference (I saw a Redmi Note 11 4G / fleur variant 2201117SY with SK Hynix UFS was confirmed via "Path B" in the XDA thread — mine scanned as full COMPATIBLE (Path A profile), not COMPATIBLE_SECCFG_ONLY, so Path B doesn't apply here as far as I can tell. Happy to be corrected.)
• Willing to provide any further dumps/tests — device is dedicated to this debugging right now.

Related

• mtkclient-side issue with full logs: [link once filed on bkerler/mtkclient]

[Jz8Root]

Thanks for this. It's the most useful failure report the project has had, specifically because you re-dumped after every operation instead of trusting the tool's exit status. That habit is what made the rest of this findable.

I went looking for why a refused write would look like a successful one, and I found it. Four things.

1. You're not an isolated case

Issue #11 (Redmi Note 11 Pro, pissarrro) is the same SoC as yours, MT6877, and his grep output is byte-identical to yours:

14680064:Jz8PNRUF
31457280:Jz8PNRUF

Same offsets, same LK function set, same outcome. He didn't re-dump to verify, so he filed it as a plain failure. Two independent MT6877 reports with an identical RPMB layout makes this a SoC cluster rather than a quirk of your unit.

2. Why it reports success: this is an mtkclient bug, and it's still in main

custom_rpmb_write() in mtkclient/Library/DA/xflash/extension/xflash.py:

resp = unpack("<H", self.xread())[0]
if resp != 0:
    if resp in rpmb_error:
        self.error(rpmb_error[resp])
        status = self.status()
        return False

And rpmb_error is a plain list of strings:

rpmb_error = [
    "",
    "General failure",
    "Authentication failure",
    "Counter failure",
    "Address failure",
    "Write failure",
    "Read failure",
    "Authentication key not yet programmed"
]

resp is an integer. rpmb_error holds strings. So resp in rpmb_error performs a value membership test against a list of strings, which is false for every possible integer:

resp=0x2 -> resp in rpmb_error -> False
resp=0x4 -> resp in rpmb_error -> False
resp=0x5 -> resp in rpmb_error -> False

The intent was clearly to index the list, not search it. And since there is no else branch, a non-zero result code doesn't merely go unnamed, it goes entirely unhandled: the loop continues, falls through to status = self.status(), and returns True.

So the controller can reject every frame and the function still reports success. That is literally the "silently" in your issue title.

Worth noting that custom_rpmb_read() contains the same faulty test but does have an else fallback printing the raw value, which is why reads behave sanely and writes don't.

I checked bkerler/mtkclient at main today, not just my local copy. Still there, unchanged.

Minimal fix:

                resp = unpack("<H", self.xread())[0]
                if resp != 0:
                    if resp < len(rpmb_error):
                        self.error(rpmb_error[resp])
                    else:
                        self.error(f"Unknown RPMB error: {hex(resp)}")
                    self.status()
                    return False

One distinction I want to be clear about, because I don't want to oversell this: the bug explains why the failure is silent, not why the write is refused. The controller is refusing for some reason, and that reason lives in the result code this branch discards. Patch it and the device will tell us which one. My guess order would be authentication failure (0x2), address failure (0x4), or counter expired, but that's a guess, and the fix turns it into a measurement.

3. About the UFS_Samsung_0x400000 label

You're right that it's misleading, though not for the reason you assumed, and the difference works in your favour.

The label has nothing to do with your UFS chip. The scanner never sees your chip. It searches the LK binary for the 32-bit constant 0x400000 and names the type after whichever constant it finds. It describes something the bootloader carries, not a vendor. Bad naming on my part, I'll rename it.

The consequence is that the offsets in your report are not "Samsung constants that might not transfer to Hynix". Your own grep confirmed the magic sits exactly where the sector math predicted, on your hardware. Detection and localisation are correct. Combined with point 2, the problem is entirely on the write path.

4. Erase 57344 only. Leave 122880 alone.

Your two hits are exactly 16 MiB apart:

31457280 - 14680064 = 16777216 = 0x1000000 = 16 MiB

That is not two copies of the magic, it's one location seen twice. mtkclient's dump exposes the RPMB mirrored at a 16 MiB stride, so 122880 is an alias of 57344.

The rule, which I had in the CHANGELOG for miel back in May but never carried into the README: hits separated by exactly 16 MiB are mirrors of each other, so collapse each mirrored pair and write only to the lower member of the pair. On miel that reduced four hits (16352, 57344, 81888, 122880) to two real locations, of which 57344 turned out to be the effective one. On your layout there is only one real location, 57344.

The README tells you to grep for your sector and says nothing about what to do when grep returns several hits. That's a documentation gap on my side, not a mistake on yours.

Worth ruling out as well: if the physical RPMB LUN is 16 MiB, sector 122880 sits at 30 MiB, past the end of the partition, and an out-of-range authenticated write returns an address failure. With the bug in point 2 that rejection was invisible, and depending on how the DA sequences frames, a refused write can take the following one down with it. So your earlier attempts may have been poisoned by the second erase rather than blocked by the hardware.

What would help

Patch custom_rpmb_write as above, then, in one clean session:

mtk.py da rpmb e --sector 57344 --sectors 4
mtk.py da rpmb r rpmb_after.bin
grep -boa "Jz8PNRUF" rpmb_after.bin

Single sector, nothing else. Then post whichever you get:

• no error and 14680064 gone: it works, the second erase was the problem
• a named RPMB error: that's the actual root cause, and it's the number I need
• Unknown RPMB error: 0x...: better still, that's a code outside the JEDEC set and worth reporting upstream on its own

Also useful for the compatibility database: the full DAXFlash - UFS ... block from your log (ID, MID, LU0/LU1/LU2 sizes). The LU sizes will give us the real RPMB extent and settle the out-of-range question.

On my side

• Renaming the RPMB type label so it stops implying a vendor
• README section on mirroring, with the 16 MiB pair rule
• Warning in the scanner when its predicted sector and the grep result disagree
• rubypro and pissarrro added to COMPATIBILITY.md as MT6877, detection confirmed, write pending
• Fix filed upstream at mtkclient: Fix RPMB result codes being silently discarded bkerler/mtkclient#307, and commented on your #305 with the analysis

Keeping this open until we have the result code. I found your mtkclient issue (#305) and posted the analysis there too, so let's keep the tool-side discussion in that thread and the device-side compatibility work here.

[LucaCraft89]

Hi, out of curiosity, i asked Claude Opus and he said this:

Decoded the changed bytes as ASCII — this is the real story:

0xe00000:  "Jz8PNRUF"          (magic — UNCHANGED)
0xe10000:  0x0c → 0x11          (RPMB write counter, +5 = writes DID authenticate)
0xe20000:  "milock state"  →  "wrong unlock data"

Three hard facts now proven:
1. Key is correct. Write counter incremented — the controller accepted authenticated writes. No auth wall.
2. The magic did not erase. Writing "sector 57344" did not touch byte 0xe00000. Your read offsets ≠ write offsets for this UFS.
3. The device flipped its lock-state field to "wrong unlock data" — Xiaomi anti-tamper. LK validated the record, saw tampering, kept lks=1.

So writes land somewhere, just not on the magic. Need to find the true write→read offset mapping. Zeros are invisible against a zero region — probe with an unambiguous 0xAA marker.

[LucaCraft89]

anyhow here it is:

dump:

root@fedora:/home/luca/xiaomi/mtkclient# cd /home/luca/xiaomi/mtkclient
python mtk.py da rpmb e --sector 57344 --sectors 4
python mtk.py da rpmb r rpmb_single.bin
grep -boa "Jz8PNRUF" rpmb_single.bin
Preloader - Status: Waiting for PreLoader VCOM, please reconnect mobile/iot device to brom mode

Port - Hint:

Power off the phone before connecting.
For brom mode, press and hold vol up, vol dwn, or all hw buttons and connect usb.
For preloader mode, don't press any hw button and connect usb.
If it is already connected and on, hold power for 10 seconds to reset.


Port - Device detected :)
Preloader - Detected regular mode !
Preloader - 	CPU:			MT6877/MT6877V/MT8791N(Dimensity 900/1080/7050)
Preloader - 	HW version:		0x0
Preloader - 	WDT:			0x10007000
Preloader - 	Uart:			0x11002000
Preloader - 	Brom payload addr:	0x100a00
Preloader - 	DA payload addr:	0x201000
Preloader - 	CQ_DMA addr:		0x10212000
Preloader - 	Var1:			0xa
Preloader - Disabling Watchdog...
Preloader - HW code:			0x959
Preloader - Target config:		0xe7
Preloader - 	SBC enabled:		True
Preloader - 	SLA enabled:		True
Preloader - 	DAA enabled:		True
Preloader - 	SWJTAG enabled:		True
Preloader - 	EPP_PARAM at 0x600 after EMMC_BOOT/SDMMC_BOOT:	False
Preloader - 	Root cert required:	False
Preloader - 	Mem read auth:		True
Preloader - 	Mem write auth:		True
Preloader - 	Cmd 0xC8 blocked:	True
Preloader - Get Target info
Preloader - BROM mode detected.
Preloader - 	HW subcode:		0x8a00
Preloader - 	HW Ver:			0xca00
Preloader - 	SW Ver:			0x0
Preloader - ME_ID:			EE3E87A9DE67D42BEEB689886339EA51
Preloader - SOC_ID:			40843624D57D39AFBBC72A277D043B59FDB85E096512E06E69C2857736B2F922
Preloader
Preloader - [LIB]: Auth file is required. Use --auth option.
DaHandler - Device is protected.
DaHandler - Device is in BROM-Mode. Bypassing security.
PLTools - Loading payload from mt6877_payload.bin, 0x264 bytes
Exploitation - Kamakiri Run
Exploitation - Done sending payload...
PLTools - Successfully sent payload: /home/luca/xiaomi/mtkclient/mtkclient/payloads/mt6877_payload.bin
Port - Device detected :)
DaHandler
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 - UFS Blocksize: 0x1000
DAXFlash - UFS ID:       H9QT1G6DN6X132
DAXFlash - UFS MID:      0xad
DAXFlash - UFS CID:      ad0148395154314736444e3658313332
DAXFlash - UFS FWVer:    41303033
DAXFlash - UFS Serial:   333232384237323039423238
DAXFlash - UFS LU0 Size: 0x3b96000000
DAXFlash - UFS LU1 Size: 0x400000
DAXFlash - UFS LU2 Size: 0x400000
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 - Generating sej rpmbkey...
Sej - AES128 CBC - HACC init
Sej - AES128 CBC - HACC run
Sej - AES128 CBC - HACC terminate
XFlashExt - Setting rpmbkey: ok
XFlashExt - Derived rpmb key: 2737465aa6a1217c4c030c960fb1df5d8f9d42c1a64fdf733cae1d9609b661ea
Done |██████████| 100.0% RPMB erase: (0x400/0x400),0.00 MB/s
XFlashExt - Done erasing rpmb
Main - Handling da commands ...
Progress: |██████████| 100.0% RPMB read: (0x2000000/0x2000000), 818.2 KB/s   s left 
XFlashExt - Done reading rpmb to rpmb_single.bin
root@fedora:/home/luca/xiaomi/mtkclient# grep -boa "Jz8PNRUF" rpmb_single.bin
root@fedora:/home/luca/xiaomi/mtkclient# echo "fresh BROM session fom here"
fresh BROM session fom here
root@fedora:/home/luca/xiaomi/mtkclient# python mtk.py da rpmb r rpmb_single2.bin
Preloader - Status: Waiting for PreLoader VCOM, please reconnect mobile/iot device to brom mode

Port - Hint:

Power off the phone before connecting.
For brom mode, press and hold vol up, vol dwn, or all hw buttons and connect usb.
For preloader mode, don't press any hw button and connect usb.
If it is already connected and on, hold power for 10 seconds to reset.


^CTraceback (most recent call last):
  File "/home/luca/xiaomi/mtkclient/mtk.py", line 348, in <module>
    sys.exit(main() or 0)
             ~~~~^^
  File "/home/luca/xiaomi/mtkclient/mtk.py", line 344, in main
    return mtk.run(parser)
           ~~~~~~~^^^^^^^^
  File "/home/luca/xiaomi/mtkclient/mtkclient/Library/mtk_main.py", line 739, in run
    mtk = da_handler.connect(mtk, directory)
  File "/home/luca/xiaomi/mtkclient/mtkclient/Library/DA/mtk_da_handler.py", line 116, in connect
    mtk.preloader.init(directory=directory)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "/home/luca/xiaomi/mtkclient/mtkclient/Library/mtk_preloader.py", line 164, in init
    res = self.mtk.port.handshake(maxtries=maxtries)
  File "/home/luca/xiaomi/mtkclient/mtkclient/Library/Port.py", line 200, in handshake
    time.sleep(0.3)
    ~~~~~~~~~~^^^^^
KeyboardInterrupt

root@fedora:/home/luca/xiaomi/mtkclient# python mtk.py da rpmb r rpmb_single2.bin
Preloader - Status: Waiting for PreLoader VCOM, please reconnect mobile/iot device to brom mode

Port - Hint:

Power off the phone before connecting.
For brom mode, press and hold vol up, vol dwn, or all hw buttons and connect usb.
For preloader mode, don't press any hw button and connect usb.
If it is already connected and on, hold power for 10 seconds to reset.


...........
^CTraceback (most recent call last):
  File "/home/luca/xiaomi/mtkclient/mtk.py", line 348, in <module>
    sys.exit(main() or 0)
             ~~~~^^
  File "/home/luca/xiaomi/mtkclient/mtk.py", line 344, in main
    return mtk.run(parser)
           ~~~~~~~^^^^^^^^
  File "/home/luca/xiaomi/mtkclient/mtkclient/Library/mtk_main.py", line 739, in run
    mtk = da_handler.connect(mtk, directory)
  File "/home/luca/xiaomi/mtkclient/mtkclient/Library/DA/mtk_da_handler.py", line 116, in connect
    mtk.preloader.init(directory=directory)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "/home/luca/xiaomi/mtkclient/mtkclient/Library/mtk_preloader.py", line 164, in init
    res = self.mtk.port.handshake(maxtries=maxtries)
  File "/home/luca/xiaomi/mtkclient/mtkclient/Library/Port.py", line 200, in handshake
    time.sleep(0.3)
    ~~~~~~~~~~^^^^^
KeyboardInterrupt

root@fedora:/home/luca/xiaomi/mtkclient# python mtk.py da rpmb r rpmb_single2.bin
DaHandler - Please disconnect, start mtkclient and reconnect.
root@fedora:/home/luca/xiaomi/mtkclient# python mtk.py da rpmb r rpmb_single2.bin
Preloader - Status: Waiting for PreLoader VCOM, please reconnect mobile/iot device to brom mode

Port - Hint:

Power off the phone before connecting.
For brom mode, press and hold vol up, vol dwn, or all hw buttons and connect usb.
For preloader mode, don't press any hw button and connect usb.
If it is already connected and on, hold power for 10 seconds to reset.


Port - Device detected :)
Preloader - Detected regular mode !
Preloader - 	CPU:			MT6877/MT6877V/MT8791N(Dimensity 900/1080/7050)
Preloader - 	HW version:		0x0
Preloader - 	WDT:			0x10007000
Preloader - 	Uart:			0x11002000
Preloader - 	Brom payload addr:	0x100a00
Preloader - 	DA payload addr:	0x201000
Preloader - 	CQ_DMA addr:		0x10212000
Preloader - 	Var1:			0xa
Preloader - Disabling Watchdog...
Preloader - HW code:			0x959
Preloader - Target config:		0xe7
Preloader - 	SBC enabled:		True
Preloader - 	SLA enabled:		True
Preloader - 	DAA enabled:		True
Preloader - 	SWJTAG enabled:		True
Preloader - 	EPP_PARAM at 0x600 after EMMC_BOOT/SDMMC_BOOT:	False
Preloader - 	Root cert required:	False
Preloader - 	Mem read auth:		True
Preloader - 	Mem write auth:		True
Preloader - 	Cmd 0xC8 blocked:	True
Preloader - Get Target info
Preloader - BROM mode detected.
Preloader - 	HW subcode:		0x8a00
Preloader - 	HW Ver:			0xca00
Preloader - 	SW Ver:			0x0
Preloader - ME_ID:			EE3E87A9DE67D42BEEB689886339EA51
Preloader - SOC_ID:			40843624D57D39AFBBC72A277D043B59FDB85E096512E06E69C2857736B2F922
Preloader
Preloader - [LIB]: Auth file is required. Use --auth option.
DaHandler - Device is protected.
DaHandler - Device is in BROM-Mode. Bypassing security.
PLTools - Loading payload from mt6877_payload.bin, 0x264 bytes
Exploitation - Kamakiri Run
Exploitation - Done sending payload...
PLTools - Successfully sent payload: /home/luca/xiaomi/mtkclient/mtkclient/payloads/mt6877_payload.bin
Port - Device detected :)
DaHandler
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 - UFS Blocksize: 0x1000
DAXFlash - UFS ID:       H9QT1G6DN6X132
DAXFlash - UFS MID:      0xad
DAXFlash - UFS CID:      ad0148395154314736444e3658313332
DAXFlash - UFS FWVer:    41303033
DAXFlash - UFS Serial:   333232384237323039423238
DAXFlash - UFS LU0 Size: 0x3b96000000
DAXFlash - UFS LU1 Size: 0x400000
DAXFlash - UFS LU2 Size: 0x400000
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 ...
Progress: |██████████| 100.0% RPMB read: (0x2000000/0x2000000), 819.24 KB/s  s left 
XFlashExt - Done reading rpmb to rpmb_single2.bin
root@fedora:/home/luca/xiaomi/mtkclient# grep -boa "Jz8PNRUF" rpmb_single2.bin
14680064:Jz8PNRUF
31457280:Jz8PNRUF
root@fedora:/home/luca/xiaomi/mtkclient# 

Applied your #307 patch. Ran the clean single-session test — --sector 57344 --sectors 4, nothing else. No RPMB error, resp=0. So on this unit the controller accepts the write; this is not the swallowed-error case. But I found why every prior report looked like "success but unchanged," and it's more interesting than a refused write.

The magic erase is real in-session but reverts on cold boot. Only the magic.

Three dumps, all grep -boa:

• rpmb_dump.bin — cold, baseline: magic at 14680064 + 31457280
• rpmb_single.bin — read in the same live DA session as the erase (note: no BROM handshake / no Kamakiri in my log before this read — the second mtk.py reattached to the still-live DA): magic gone, grep returns nothing
• rpmb_single2.bin — read after a forced cold BROM re-entry (full handshake + Kamakiri + DA re-upload): magic back at both offsets

Byte-diff of the in-session dump vs the cold dump = exactly 8 bytes at 0xe00000 and 8 at 0x1e00000, nothing else:

                   0xe00000 magic     0xe10000 ctr   0xe20000 string
dump  (cold)       Jz8PNRUF           0x0c           "milock state"
single(in-session) 00 00 00 00…       0x11           "wrong unlock data"
single2(cold)      Jz8PNRUF  <-back   0x11           "wrong unlock data"

So the write counter (0x0c → 0x11, +5) and the adjacent lock-state string (milock state → wrong unlock data) committed and survived the power cycle. Ordinary RPMB writes in this structure persist. Only the 8-byte magic at 0xe00000 fails to persist — it reads as zeroed within the session and is restored to Jz8PNRUF after any cold cycle. And the cold entry only runs BROM, so LK never executes — whatever restores the magic isn't the bootloader re-provisioning it at boot.

Reading this as: on MT6877 + SK Hynix H9QT1G6DN6X132, the magic cell is effectively write-protected/regenerated — writes are ACKed into a volatile view (visible same-session) but not committed, while neighboring cells commit normally. That single fact explains all three MT6877 reports (mine, pissarrro/#11): the method's erase can never survive to the next boot, so mi_check_magic always sees the magic and overrides seccfg.

This also means verification must be a separate cold session — a chained rpmb r reattaches to the live DA and shows the volatile buffer (magic gone), which is exactly the false-positive that makes this look like it worked. Might be worth a README warning: re-dump only after a full power-cycle + fresh BROM entry.

Open questions

1. For UFS, does the extension's RPMB read serve from a DA-side buffer / can an in-session write shadow a subsequent read? The same-session "erased" read strongly suggests a write buffer or read cache the cold cycle discards.
2. Could the magic offset be reconstructed/served rather than raw-read on a fresh session? Its unconditional return cold looks like regeneration, not storage.
3. UFS LU1 Size and LU2 Size are both 0x400000 (4 MiB), but the magic sits at 14 MiB / 30 MiB with a 16 MiB mirror stride, and the dump is 32 MiB. So the region mtkclient exposes as "rpmb" isn't the 4 MiB RPMB LU wrapped. What LUN/size does the UFS RPMB read vs write path actually target — could read and write hit different views?

UFS block

UFS ID:       H9QT1G6DN6X132
UFS MID:      0xad
UFS CID:      ad0148395154314736444e3658313332
UFS FWVer:    41303033
UFS LU0 Size: 0x3b96000000
UFS LU1 Size: 0x400000
UFS LU2 Size: 0x400000
UFS Blocksize: 0x1000

Happy to run a cold-only marker test next (write 0xAA to the magic offset, verify in a separate cold session) to confirm the revert with a non-zero pattern and rule out any zero-region ambiguity, and a UFS RPMB write-protect attribute query if the DA exposes one.

[LucaCraft89]

Follow-up — cold 0xAA marker test. This narrows it further: it's not the record that's protected, it's exactly the 8 magic bytes.

Wrote 0xAA across the whole 256-byte sector at 57344 (da rpmb w, reported success, resp=0), then cold power-cycle + fresh BROM entry, then read.

0xe00000 after cold reboot:

0xe00000: 4a7a38504e525546 aaaaaaaaaaaaaaaa
          ^^^^^^^^^^^^^^^^^ "Jz8PNRUF" restored
                           ^^^^^^^^^^^^^^^^ 0xAA marker persisted

So:

• bytes 0xe00000..0xe00007 (the 8-byte magic) snapped back to Jz8PNRUF, regardless of what was written (zeros last time, 0xAA this time)
• bytes 0xe00008.. (rest of the same 256-byte sector) kept my 0xAA across the power cycle

Conclusion: the surrounding RPMB is ordinary writable, persistent storage. Only the exact 8 magic bytes are pinned — restored on every cold boot independent of the written value, and cold entry runs BROM only so it isn't LK re-provisioning at boot. The magic signature behaves like a fixed/regenerated header, not a stored cell.

Practical upshot for the compatibility DB: on MT6877 + SK Hynix H9QT1G6DN6X132, mi_check_magic will read Jz8PNRUF on every boot no matter what the RPMB-erase step writes, so the erase-magic method can't unlock this layout. It's not a write failure to flag as "unverified" — it's a hard block. The earlier same-session "magic gone" reads were the volatile DA view; every cold verification shows the magic present.

Repro notes for anyone verifying: (1) the #307 patch is still needed and correct; the controller returns resp=0 here, so nothing to catch — the write is accepted. (2) Verification must be a separate cold session; a chained rpmb r reattaches to the live DA and shows the erased buffer, which is the false positive.

Still happy to run a UFS RPMB write-protect / attribute query if the DA exposes one, to pin down the mechanism (WP sub-region vs regeneration).

[Jz8Root]

The 0xAA test is the right experiment and it settles one thing definitively. It also kills a theory I was about to post, so let me get that out of the way first, then raise one objection to your conclusion, because I think your own log contradicts part of it.

What your test proves, and what I was wrong about

I had worked out that LU1 is 4 MiB, so sector 57344 sits 3.5 times past the end of the physical RPMB, and that both grepped offsets reduce to physical sector 8192. The address field in an RPMB frame is two bytes, so 122880 mod 65536 = 57344, which also means the apparent 16 MiB mirror stride is just 16-bit wraparound rather than UFS mirroring. That part still holds and is worth documenting.

What I was going to conclude from it was wrong. I was going to say the write never lands because the address is out of range. Your 0xAA result rules that out cleanly:

0xe00000: 4a7a38504e525546 aaaaaaaaaaaaaaaa

248 of 256 bytes survived a cold cycle. An address that led nowhere could not persist anything. So writes at that address do reach flash, and the only anomaly is the 8-byte magic itself. Good experiment, and it saved me from posting something wrong.

The objection: cold BROM entry did not run BROM only

Your conclusion rests on this line:

the cold entry only runs BROM, so LK never executes

The first half is not what your log shows. Twice, mtkclient reported:

DaHandler - [LIB]: Device is in BROM mode. No preloader given, trying to dump preloader from ram.
Mtk - Patched "Patched loader msg" in preloader
Mtk - Patched "hash_check" in preloader
Mtk - Patched "get_vfy_policy" in preloader

Those patch lines only appear when the preloader dump succeeded. And dump_preloader_ram() works by reading SRAM at 0x200000 and searching for the MediaTek preloader header signature 4D 4D 4D 01. It found it, twice.

BROM does not place the preloader in SRAM. If it is sitting there, it was loaded and executed during a preceding power-on. Your log also shows two KeyboardInterrupt aborts during handshake and one Please disconnect, start mtkclient and reconnect, so there were at least three connect attempts where the BROM window was not caught cleanly. Each of those is an opportunity for the boot chain to proceed past BROM into the preloader.

That matters because the MediaTek preloader is the stage that initialises RPMB. It is the natural place for a vendor to validate or restore a lock-state header.

Why I think that is a better fit than regeneration

Your reading requires the UFS controller to recognise 8 specific bytes of payload and regenerate them. An RPMB controller stores and authenticates blocks, it does not parse their contents. There is no mechanism in the spec for content-aware restoration, and no vendor I know of implements one.

The preloader explanation needs nothing exotic, and it accounts for every observation you made:

Observation	Under preloader restoration
only the 8 magic bytes return	that is all the preloader rewrites
the rest of the sector persists	the preloader does not touch it
restored value identical regardless of what was written	the string is hardcoded in the preloader
happens even on what looks like a cold entry	the preloader ran during one of the uncaught connect attempts
resp=0, no controller error	the write genuinely succeeded, then was overwritten

Both theories predict what you saw. Only one of them requires new hardware behaviour.

The test that separates them

@katavnnn (#12) hit something related on sea/MT6781 and found the workaround. On his unit, unplugging left the phone wedged between BROM and Preloader, and holding power rebooted it instead of shutting it down:

if I tried to hold 10s, the phone didnt turn off, it reboot and the logo appear. I think it is the reason why it automatically rewrite the recovery key back into the RPMB

He fixed it by disconnecting the battery connector from the board. That does two things at once: it guarantees no Xiaomi code executes, and it clears SRAM so no resident preloader can be reused.

So:

1. Write your 0xAA pattern, or erase, at sector 57344
2. Disconnect the battery connector. Not power off, not hold power, physically cut it
3. Reconnect, hold Vol Up and Vol Down, then insert the cable, catching BROM on the first attempt
4. Read and check 0xe00000

If the magic stays gone, it was never pinned. If it comes back from a genuinely dead-cold device caught on the first handshake, then your reading is right and I will document it as a hard block on my side.

Your UFS write-protect attribute query is worth running either way. If the DA exposes the RPMB WP descriptor, that settles the mechanism question mechanically instead of by inference. Please do.

Why I am pushing back rather than just accepting it

If I write "MT6877 is a hard block, method impossible" into the compatibility database, that closes the door on three reported devices, in what is currently the reference document for this method. I would rather spend one more test on it than condemn a whole SoC family on an inference, especially when a second tester independently found that a boot stage was undoing his erase.

If the battery-disconnect run still shows the magic, I will write it up as a hard block with your name on the finding, and it will be a solid one because the alternative was properly eliminated.

Going into the README regardless of the outcome

• verification is only valid in a separate cold session, since a chained rpmb r reattaches to the live DA and shows the volatile view with the magic gone. That false positive would fool anyone and it is the single most useful procedural thing to come out of this thread. Credited to you
• physical RPMB size comes from LU1, and a grepped sector must be reduced modulo that size before being used as a write target
• the 16-bit address wraparound as the real explanation for the apparent mirror stride, replacing my mirroring wording
• the battery-disconnect recovery for units that wedge between BROM and Preloader, credited to @katavnnn
• your full UFS block in the compatibility database

And thanks for applying #307. Its whole purpose was to turn a guess into a measurement, and resp=0 is exactly the measurement that made the rest of this possible.

[Jz8Root]

One correction on the byte reading, and it matters because a load-bearing part of the analysis you pasted rests on it.

The README has had that region mapped since May, in the RPMB Sector Reference table:

| Lock magic         | 0xE00000 | 57344 |
| Lock state length  | 0xE10000 | 57600 |
| Signature data     | 0xE20000 | 57856 |

0xE10000 is not a write counter. It is the length field for the string stored at 0xE20000. Check it against your own bytes:

len("milock state")      = 12  = 0x0C
len("wrong unlock data") = 17  = 0x11

Exact match, both before and after. The +5 is 17 - 12, the difference in string length. Nothing incremented.

Which means this claim does not hold:

Key is correct. Write counter incremented — the controller accepted authenticated writes. No auth wall.

There is no evidence in your dumps that an RPMB write counter moved, because none of the bytes you diffed is a write counter. The real counter is not in the addressable data area at all, it lives in the controller and comes back inside the response frame. Whether your writes authenticated is still an open question, not a settled one.

I missed this for a couple of hours too, and it was in my own documentation the whole time. Not a criticism of you, just worth nailing down before anyone builds on it.

What it does to the two competing readings

It works against the hardware-regeneration theory rather than for it.

Something wrote wrong unlock data at 0xE20000 and updated its length field at 0xE10000 to match. Two fields, consistent with each other, one semantic operation. A UFS controller does not do that. It stores and authenticates blocks, it has no notion of a lock-state record with a length prefix.

Code that owns that structure does exactly that, and on this platform the candidates are LK and the preloader. Combined with the preloader being resident in SRAM during your session, and with @katavnnn independently finding that a boot stage was restoring his magic, the balance still points at a boot-time actor rather than at the flash controller.

So the battery-disconnect run is still the test I would like. It is the only one that guarantees neither of those two ever executes between the write and the read.

Useful either way

This gives the project a much better diagnostic than "is the magic still there", and I am adding it to the docs:

wrong unlock data in the signature field means LK has seen a tampered RPMB record. That distinguishes "erased then restored" from "never erased", which a magic-presence check cannot do. Anyone whose unlock fails can now read that field and know which situation they are in.

That came out of your dumps, so it goes in credited to you.

[LucaCraft89]

thanks, i am open to help, i am for now just keep trying the mi app community method

[Jz8Root]

Better test than the one I gave you, and it does not involve opening the phone. It also came out of something you observed.

You noted that your second invocation reattached to the live DA:

note: no BROM handshake / no Kamakiri in my log before this read, the second mtk.py reattached to the still-live DA

That is the piece that makes this work. mtkclient has a real power-off, and a chained invocation can deliver it without unplugging.

mtk.py reset is a shutdown, not a reboot

mtk_da_handler.py:

elif cmd == "reset":
    mtk.daloader.shutdown(bootmode=0)
    print("Reset command was sent. Disconnect usb cable to power off.")

xflash_lib.py:

# bootmode 0: shutdown 1: home screen, 2: fastboot
...
leaveusb = 0   # Disconnect usb

bootmode=0 is a shutdown, and leaveusb=0 means the device drops off the bus and powers down when the cable comes out. Nothing in the boot chain executes.

Why your phone was in a strange state to begin with

After erase_rpmb(), the handler calls neither close() nor shutdown(). The command simply returns, leaving the DA running and the device powered. That is the state you were unplugging from, and it is why the Power button behaves oddly for @katavnnn on a different SoC.

So every cold entry you performed started from a device that had to get from "DA running" to "off" by itself, with the Power button as the only tool. That is exactly the window where a boot stage can run.

The test

python mtk.py da rpmb e --sector 57344 --sectors 4
python mtk.py reset
#   -> "Reset command was sent. Disconnect usb cable to power off."
#   unplug. The phone is now genuinely off, and nothing has booted.
#   re-enter BROM from cold, first attempt, no aborted handshakes
python mtk.py da rpmb r rpmb_after.bin
grep -boa "Jz8PNRUF" rpmb_after.bin

Two outcomes, both worth having:

• magic still gone: the erase persists on MT6877 and this was never a hard block. It was a procedural trap in my documentation, and the fix is a one-line addition rather than a device limitation.
• magic back: then it survives a clean shutdown with no boot stage involved, which is much stronger evidence for your reading than the earlier runs were. At that point I would document it as a hard block on your finding.

Either way this is a better experiment than the battery disconnect I suggested, because it removes the Power button from the equation entirely and there is nothing to disassemble.

If you also run the 0xAA variant through this path, that settles the write question at the same time.

On the record

I put mtk.py reset into the README as the recommended recovery, explicitly flagged as not yet confirmed on hardware, with the battery disconnect kept as the proven fallback. If your run confirms it, that flag comes off and it becomes the standard step between A1 and A2.

[LucaCraft89]

luca@fedora:~$ sudo su
[sudo] password for luca: 
root@fedora:/home/luca# cd xiaomi/mtkclient/
root@fedora:/home/luca/xiaomi/mtkclient# python mtk.py da rpmb e --sector 57344 --sectors 4
Preloader - Status: Waiting for PreLoader VCOM, please reconnect mobile/iot device to brom mode

Port - Hint:

Power off the phone before connecting.
For brom mode, press and hold vol up, vol dwn, or all hw buttons and connect usb.
For preloader mode, don't press any hw button and connect usb.
If it is already connected and on, hold power for 10 seconds to reset.


......Port - Device detected :)
Preloader - Detected regular mode !
Preloader - 	CPU:			MT6877/MT6877V/MT8791N(Dimensity 900/1080/7050)
Preloader - 	HW version:		0x0
Preloader - 	WDT:			0x10007000
Preloader - 	Uart:			0x11002000
Preloader - 	Brom payload addr:	0x100a00
Preloader - 	DA payload addr:	0x201000
Preloader - 	CQ_DMA addr:		0x10212000
Preloader - 	Var1:			0xa
Preloader - Disabling Watchdog...
Preloader - HW code:			0x959
Preloader - Target config:		0xe7
Preloader - 	SBC enabled:		True
Preloader - 	SLA enabled:		True
Preloader - 	DAA enabled:		True
Preloader - 	SWJTAG enabled:		True
Preloader - 	EPP_PARAM at 0x600 after EMMC_BOOT/SDMMC_BOOT:	False
Preloader - 	Root cert required:	False
Preloader - 	Mem read auth:		True
Preloader - 	Mem write auth:		True
Preloader - 	Cmd 0xC8 blocked:	True
Preloader - Get Target info
Preloader - BROM mode detected.
Preloader - 	HW subcode:		0x8a00
Preloader - 	HW Ver:			0xca00
Preloader - 	SW Ver:			0x0
Preloader - ME_ID:			EE3E87A9DE67D42BEEB689886339EA51
Preloader - SOC_ID:			40843624D57D39AFBBC72A277D043B59FDB85E096512E06E69C2857736B2F922
Preloader
Preloader - [LIB]: Auth file is required. Use --auth option.
DaHandler - Device is protected.
DaHandler - Device is in BROM-Mode. Bypassing security.
PLTools - Loading payload from mt6877_payload.bin, 0x264 bytes
Exploitation - Kamakiri Run
Exploitation - Done sending payload...
PLTools - Successfully sent payload: /home/luca/xiaomi/mtkclient/mtkclient/payloads/mt6877_payload.bin
Port - Device detected :)
DaHandler
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 - UFS Blocksize: 0x1000
DAXFlash - UFS ID:       H9QT1G6DN6X132
DAXFlash - UFS MID:      0xad
DAXFlash - UFS CID:      ad0148395154314736444e3658313332
DAXFlash - UFS FWVer:    41303033
DAXFlash - UFS Serial:   333232384237323039423238
DAXFlash - UFS LU0 Size: 0x3b96000000
DAXFlash - UFS LU1 Size: 0x400000
DAXFlash - UFS LU2 Size: 0x400000
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 - Generating sej rpmbkey...
Sej - AES128 CBC - HACC init
Sej - AES128 CBC - HACC run
Sej - AES128 CBC - HACC terminate
XFlashExt - Setting rpmbkey: ok
XFlashExt - Derived rpmb key: 2737465aa6a1217c4c030c960fb1df5d8f9d42c1a64fdf733cae1d9609b661ea
Done |██████████| 100.0% RPMB erase: (0x400/0x400),0.00 MB/s
XFlashExt - Done erasing rpmb
root@fedora:/home/luca/xiaomi/mtkclient# python mtk.py reset
Main - Handling da commands ...
DeviceClass - [Errno 2] Entity not found
Reset command was sent. Disconnect usb cable to power off.
root@fedora:/home/luca/xiaomi/mtkclient# python mtk.py da rpmb r rpmb_after.bin
Preloader - Status: Waiting for PreLoader VCOM, please reconnect mobile/iot device to brom mode

Port - Hint:

Power off the phone before connecting.
For brom mode, press and hold vol up, vol dwn, or all hw buttons and connect usb.
For preloader mode, don't press any hw button and connect usb.
If it is already connected and on, hold power for 10 seconds to reset.


.........Port - Device detected :)
Preloader - Detected regular mode !
Preloader - 	CPU:			MT6877/MT6877V/MT8791N(Dimensity 900/1080/7050)
Preloader - 	HW version:		0x0
Preloader - 	WDT:			0x10007000
Preloader - 	Uart:			0x11002000
Preloader - 	Brom payload addr:	0x100a00
Preloader - 	DA payload addr:	0x201000
Preloader - 	CQ_DMA addr:		0x10212000
Preloader - 	Var1:			0xa
Preloader - Disabling Watchdog...
Preloader - HW code:			0x959
Preloader - Target config:		0xe7
Preloader - 	SBC enabled:		True
Preloader - 	SLA enabled:		True
Preloader - 	DAA enabled:		True
Preloader - 	SWJTAG enabled:		True
Preloader - 	EPP_PARAM at 0x600 after EMMC_BOOT/SDMMC_BOOT:	False
Preloader - 	Root cert required:	False
Preloader - 	Mem read auth:		True
Preloader - 	Mem write auth:		True
Preloader - 	Cmd 0xC8 blocked:	True
Preloader - Get Target info
Preloader - BROM mode detected.
Preloader - 	HW subcode:		0x8a00
Preloader - 	HW Ver:			0xca00
Preloader - 	SW Ver:			0x0
Preloader - ME_ID:			EE3E87A9DE67D42BEEB689886339EA51
Preloader - SOC_ID:			40843624D57D39AFBBC72A277D043B59FDB85E096512E06E69C2857736B2F922
Preloader
Preloader - [LIB]: Auth file is required. Use --auth option.
DaHandler - Device is protected.
DaHandler - Device is in BROM-Mode. Bypassing security.
PLTools - Loading payload from mt6877_payload.bin, 0x264 bytes
Exploitation - Kamakiri Run
Exploitation - Done sending payload...
PLTools - Successfully sent payload: /home/luca/xiaomi/mtkclient/mtkclient/payloads/mt6877_payload.bin
Port - Device detected :)
DaHandler
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 - UFS Blocksize: 0x1000
DAXFlash - UFS ID:       H9QT1G6DN6X132
DAXFlash - UFS MID:      0xad
DAXFlash - UFS CID:      ad0148395154314736444e3658313332
DAXFlash - UFS FWVer:    41303033
DAXFlash - UFS Serial:   333232384237323039423238
DAXFlash - UFS LU0 Size: 0x3b96000000
DAXFlash - UFS LU1 Size: 0x400000
DAXFlash - UFS LU2 Size: 0x400000
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 ...
Progress: |██████████| 100.0% RPMB read: (0x2000000/0x2000000), 839.11 KB/s  s left 
XFlashExt - Done reading rpmb to rpmb_after.bin
root@fedora:/home/luca/xiaomi/mtkclient# grep -boa "Jz8PNRUF" rpmb_after.bin
root@fedora:/home/luca/xiaomi/mtkclient# echo now going to use the buttons to power off 
now going to use the buttons to power off
root@fedora:/home/luca/xiaomi/mtkclient# grep -boa "Jz8PNRUF" rpmb_after2.bin
grep: rpmb_after2.bin: No such file or directory
root@fedora:/home/luca/xiaomi/mtkclient# python mtk.py da rpmb r rpmb_after2.bin
Preloader - Status: Waiting for PreLoader VCOM, please reconnect mobile/iot device to brom mode

Port - Hint:

Power off the phone before connecting.
For brom mode, press and hold vol up, vol dwn, or all hw buttons and connect usb.
For preloader mode, don't press any hw button and connect usb.
If it is already connected and on, hold power for 10 seconds to reset.


...Port - Device detected :)
Preloader - Detected regular mode !
Preloader - 	CPU:			MT6877/MT6877V/MT8791N(Dimensity 900/1080/7050)
Preloader - 	HW version:		0x0
Preloader - 	WDT:			0x10007000
Preloader - 	Uart:			0x11002000
Preloader - 	Brom payload addr:	0x100a00
Preloader - 	DA payload addr:	0x201000
Preloader - 	CQ_DMA addr:		0x10212000
Preloader - 	Var1:			0xa
Preloader - Disabling Watchdog...
Preloader - HW code:			0x959
Preloader - Target config:		0xe7
Preloader - 	SBC enabled:		True
Preloader - 	SLA enabled:		True
Preloader - 	DAA enabled:		True
Preloader - 	SWJTAG enabled:		True
Preloader - 	EPP_PARAM at 0x600 after EMMC_BOOT/SDMMC_BOOT:	False
Preloader - 	Root cert required:	False
Preloader - 	Mem read auth:		True
Preloader - 	Mem write auth:		True
Preloader - 	Cmd 0xC8 blocked:	True
Preloader - Get Target info
Preloader - BROM mode detected.
Preloader - 	HW subcode:		0x8a00
Preloader - 	HW Ver:			0xca00
Preloader - 	SW Ver:			0x0
Preloader - ME_ID:			EE3E87A9DE67D42BEEB689886339EA51
Preloader - SOC_ID:			40843624D57D39AFBBC72A277D043B59FDB85E096512E06E69C2857736B2F922
Preloader
Preloader - [LIB]: Auth file is required. Use --auth option.
DaHandler - Device is protected.
DaHandler - Device is in BROM-Mode. Bypassing security.
PLTools - Loading payload from mt6877_payload.bin, 0x264 bytes
Exploitation - Kamakiri Run
Exploitation - Done sending payload...
PLTools - Successfully sent payload: /home/luca/xiaomi/mtkclient/mtkclient/payloads/mt6877_payload.bin
Port - Device detected :)
DaHandler
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 - UFS Blocksize: 0x1000
DAXFlash - UFS ID:       H9QT1G6DN6X132
DAXFlash - UFS MID:      0xad
DAXFlash - UFS CID:      ad0148395154314736444e3658313332
DAXFlash - UFS FWVer:    41303033
DAXFlash - UFS Serial:   333232384237323039423238
DAXFlash - UFS LU0 Size: 0x3b96000000
DAXFlash - UFS LU1 Size: 0x400000
DAXFlash - UFS LU2 Size: 0x400000
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 ...
Progress: |██████████| 100.0% RPMB read: (0x2000000/0x2000000), 831.25 KB/s  s left 
XFlashExt - Done reading rpmb to rpmb_after2.bin
root@fedora:/home/luca/xiaomi/mtkclient# grep -boa "Jz8PNRUF" rpmb_after2.bin
14680064:Jz8PNRUF
31457280:Jz8PNRUF
root@fedora:/home/luca/xiaomi/mtkclient# 

Verdict

the reset command hangs, i do not know how to interpret it,
as before the write comes back even without fully booting into the rom (force shutdown before hyperos logo)

[LucaCraft89]

still tho i did not try it since i do not want the stupid dm verify error again the sseconfig command should still say still arleady unlocked, if you say that it is worth trying to use the reset to keep the magic as it even tho the command hangs and i cannot tell if the phone shuts down, i confirm that even at the preloader state (only mi logo) even with the dm verify error the magic number gets overridden probably by firmware

[Jz8Root]

Read your log again, closely. You already proved the method works on your device. Look at what you did:

1.  da rpmb e --sector 57344 --sectors 4      ->  Done erasing rpmb
2.  mtk.py reset                             ->  DeviceClass [Errno 2] Entity not found
3.  unplug, Vol+/Vol-, replug, da rpmb r rpmb_after.bin
    grep -boa "Jz8PNRUF" rpmb_after.bin      ->  NOTHING. The magic is gone.
4.  "now going to use the buttons to power off"
5.  da rpmb r rpmb_after2.bin
    grep                                     ->  14680064, 31457280. It is back.

At step 3 the magic was absent after a full cold BROM re-entry, with Kamakiri run again and the DA re-uploaded from scratch. The erase reached flash and stayed there. It came back only at step 5, after you pressed the power button.

So the erase is not being refused, not being reverted by the controller, and not regenerated below the write path. It persists fine. What undoes it is the phone starting up.

And you said it yourself in your next message, without drawing the conclusion:

i confirm that even at the preloader state (only mi logo) even with the dm verify error the magic number gets overridden probably by firmware

That is the answer. The preloader is enough. LK does not need to run, HyperOS does not need to boot. The Mi logo alone is sufficient to rewrite the field, which is why it survived your BROM re-entries and died on your power-button shutdown.

What this means for you

Unplugging and re-entering BROM with the volume keys does not rewrite the magic. Your step 3 proves it. The only thing you must not do is let the phone start.

OK        unplug -> hold Vol+ and Vol- -> replug        magic stays erased
NOT OK    power button to shut down or restart          preloader runs, magic returns

So the sequence that should finish this is:

python mtk.py da rpmb e --sector 57344 --sectors 4
#   unplug, hold Vol+ and Vol-, replug. No power button at any point.
python mtk.py da seccfg unlock
#   then straight to fastboot to check
fastboot getvar unlocked

You are one command away. The seccfg unlock is the step you have not run since the erase held.

About the dm-verity error

i did not try it since i do not want the stupid dm verify error again

That error is not a failure, it is the proof it worked. A locked LK refuses to hand off to Android at all, so seeing Android's own "device is corrupt" screen means the bootloader let it through. It is documented in the README at Step 3, and it clears with:

fastboot erase userdata
fastboot erase metadata
fastboot reboot

You will lose userdata, which the unlock does anyway on first boot. Nothing is broken by it.

About mtk.py reset

It failed on your unit and the tool lied about it:

DeviceClass - [Errno 2] Entity not found
Reset command was sent. Disconnect usb cable to power off.

Looking at the source, that message is printed unconditionally:

mtk.daloader.shutdown(bootmode=0)
print("Reset command was sent. Disconnect usb cable to power off.")

shutdown() returns a bool and nobody checks it, so the confirmation prints whether or not anything was sent. Same class of defect as the one #307 fixes. Worth reporting separately.

It also turns out not to matter. Your step 3 shows a plain BROM re-entry is already safe, so no shutdown command is needed at all. Just never touch the power button between the two commands.

What I am changing on my side

Your three dumps did more for this project than any other report. Going in:

• the rule: unplug and re-enter BROM freely between da commands, never use the power button between the erase and the unlock, because the preloader rewrites the magic on any start-up
• MT6877 out of Tier 4. It was listed as "NOT COMPATIBLE, Kamakiri patched in hardware", which your logs disprove four times over. It was misclassified because "MT6789 or newer" got read as a numeric comparison, and MediaTek part numbers are not chronological. MT6877 is a 2021 part, older than the 2022 MT6789
• the preloader, not LK, as the stage that restores the field, which is what your Mi-logo observation establishes

Post the fastboot getvar unlocked output when you run it and rubypro goes into COMPATIBILITY.md as the first MT6877 Tier 1, credited to you.