[DEVICE] Successful unlock on Redmi Note 12S Helio G96

[katavnnn]

Device model

Redmi Note 12S

Codename

sea

SoC

MT6781

Firmware version

HyperOS 2.0.210.0 VHZMIXM

Unlock result

SUCCESS — unlocked

fastboot oem lks output

C:\Mysterious-Dev>fastboot oem lks
...
FAILED (remote: Unable to do OEM command Status(-7, EX_UNSUPPORTED_OPERATION)
finished. total time: 0.007s

C:\Mysterious-Dev>fastboot getvar unlocked
unlocked: yes
finished. total time: 0.001s

Commands used

Backup first :)
python scan_lk.py lk_a.bin
python scan_lk.py lk_b.bin 

python mtk.py --loader C:\MTK_AllInOne_DA.bin --preloader C:\Users\katav\Downloads\Compressed\mtkclient-2.1.4.1\mtkclient-2.1.4.1\preloader_sea.bin da rpmb r rpmb_dump.bin

python -c "data = open('rpmb_dump.bin', 'rb').read(); idx = data.find(b'Jz8PNRUF'); print('\n>>> Your sector:', idx // 256, '<<<\n') if idx != -1 else print('\n>>> Not found! <<<\n')"

python mtk.py --loader C:\MTK_AllInOne_DA.bin --preloader C:\Users\katav\Downloads\Compressed\mtkclient-2.1.4.1\mtkclient-2.1.4.1\preloader_sea.bin da rpmb e --sector 57344 --sectors 4

python mtk.py --loader C:\MTK_AllInOne_DA.bin --preloader C:\Users\katav\Downloads\Compressed\mtkclient-2.1.4.1\mtkclient-2.1.4.1\preloader_sea.bin da rpmb r rpmb_check.bin


python -c "data = open('rpmb_check.bin', 'rb').read(); idx = data.find(b'Jz8PNRUF'); print('\n>>> Magic Still Exist:', idx // 256, '<<<\n') if idx != -1 else print('\n>>> Congratulation! Done <<<\n')"

python mtk.py da seccfg unlock --loader C:\MTK_AllInOne_DA.bin --preloader C:\Users\katav\Downloads\Compressed\mtkclient-2.1.4.1\mtkclient-2.1.4.1\preloader_sea.bin


fastboot oem lks                 # Expected: (bootloader) lks = 0
fastboot getvar unlocked         # Expected: unlocked: yes
fastboot getvar secure           # Expected: secure: no


fastboot erase userdata
fastboot erase metadata
fastboot reboot

RPMB sector used

57344

Persistent after reboot?

Yes — still unlocked after reboot

Additional notes

I have tried to unlock bootloader on my phone 2 days with many time until i reach your repo. Thank you for all. Here is my problem: I am not sure if my method is correct, but it works.

The Problem & Consequences I Encountered: I realized that after finishing a command on mtkclient (like the RPMB erase) and unplugging the cable, my phone got stuck in a "wedged state" between BROM and Preloader. I tried to hold Vol Up and Down then plug the cable but it doesn't work. The worst part is, 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, completely undoing all my efforts to erase the magic string in the previous step.

My Ultimate Solution: To stop this from happening entirely, I decided to physically cut the power:

I directly disconnected the battery socket from the motherboard to cut the power 100%, completely clearing the wedged state.

When I was ready for the next command, I reconnected the battery socket.

Immediately, I held down both the Volume Up + Volume Down buttons and then plugged in the USB cable.

The Result: The phone went straight back into BROM mode in a perfectly "clean" and safe manner. My RPMB erase was kept completely intact, and I could proceed smoothly to the final seccfg unlock command without worrying about the phone reverting and locking itself again.

[Jz8Root]

Confirmed and added. Redmi Note 12S (sea, MT6781, HyperOS 2.0.210.0 VHZMIXM) goes into COMPATIBILITY.md as Tier 1, seventh hardware unlock, and the first sea on record. Thanks for the full command list, it makes the report reproducible by anyone.

But the compatibility entry is not the valuable part of what you posted. Three separate things in here are going into the documentation.

1. The wedged state, and cutting power at the battery

This is the important one, and it exposes a defect in my own procedure.

after finishing a command on mtkclient (like the RPMB erase) and unplugging the cable, my phone got stuck in a "wedged state" between BROM and Preloader. (...) 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

My README currently tells everyone this:

Between every da command, the phone needs a fresh BROM entry. Unplug, force-off if needed, redo the key combo, replug.

Read that against what you observed. The force-off I recommend is the hold-power that, on your unit, reboots the phone instead of shutting it down. So the documented recovery step is literally the action that triggers the boot, LK runs, sees the magic missing and puts it back. The step meant to prepare the next command is the step that undoes the previous one, and I wrote it.

Your fix, disconnecting the battery connector from the board to cut power completely, is going in as the recommended recovery. It does two useful things at once: nothing Xiaomi-side executes, and SRAM is cleared so no resident preloader can be reused on the next entry.

I would not have found this from my own devices, because mine do not wedge. Credited to you.

It is already useful elsewhere. Issue #13 is a MT6877 case where the erase reports success and a later dump shows the magic back in place, and there are two more reports of the same thing on that SoC. Your mechanism is currently the leading explanation and the test is running.

2. oem lks can fail on a device that is genuinely unlocked

fastboot oem lks
FAILED (remote: Unable to do OEM command Status(-7, EX_UNSUPPORTED_OPERATION)

fastboot getvar unlocked
unlocked: yes

The hidden OEM command is not implemented on your build, yet the device is unlocked. My README presents oem lks as the verification step, which means anyone in your situation reads that failure as a failed unlock and stops one step short of success.

Going into the README: fastboot getvar unlocked is the source of truth. oem lks is a bonus when the LK exposes it. Two currently open issues on this repo report a failure at exactly that verification step, so this is not a rare corner.

3. Your Python one-liner

python -c "data = open('rpmb_dump.bin', 'rb').read(); idx = data.find(b'Jz8PNRUF'); ..."

Better than my grep -boa for anyone on Windows without a POSIX toolchain, and the before-and-after pair with a clear message is the right shape for a procedure. I am adding a small find_sector.py to the repo based on it, credited to you, with two changes:

• it lists every occurrence rather than the first. find() returns the lowest offset, and some layouts have more than one hit
• it reduces each hit modulo the physical RPMB size from UFS LU1 Size in the mtkclient log, because the dump mtkclient produces is larger than the physical RPMB and the raw offsets can point past the end of it. That part came out of the [HELP] scan_lk.py reports 100% COMPATIBLE and correct sector, but RPMB erase/write silently doesn't persist on SK Hynix UFS (H9QT1G6DN6X132, MT6877) #13 investigation

One thing I would like for the database

The DAXFlash - EMMC ID or DAXFlash - UFS ID block from your log. Everything else on the entry is complete, that field is the only gap, and storage vendor is turning out to matter more than I assumed when I built the table.

Also, since you mentioned spending two days on it before finding the repo: if there is a step where the README sent you in the wrong direction, tell me. You have already found two, so I would rather hear about a third than have the next person hit it.

[Jz8Root]

Follow-up on the battery disconnect, and I want to be clear that your method stays the reference.

While writing your finding into the README I went looking for something less invasive, and mtkclient turns out to have a real power-off already:

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

bootmode=0 is a shutdown rather than a reboot, and leaveusb=0 means the phone powers down when the cable comes out. So in principle:

python mtk.py da rpmb e --sector <SECTOR> --sectors 4
python mtk.py reset
# unplug, phone powers off, nothing boots
python mtk.py da seccfg unlock

Yours is the one that is proven. Mine is read off the source and has not been run on a device yet, so the README lists mtk.py reset as the recommended first attempt with a note saying it is unconfirmed, and keeps your battery disconnect as the fallback that actually worked on hardware, credited to you.

Your report also explained why the wedged state exists in the first place. After erase_rpmb() returns, mtkclient calls neither close() nor shutdown(), so the device is left with the DA still running and still powered. That is the state your phone was in when the Power button started rebooting it instead of shutting it down. You described the symptom precisely enough to find the cause in the source, which is why it is now documented at all.

If you still have the phone in that state at some point, mtk.py reset would be worth trying before reaching for the back cover again. No pressure either way, you already did the hard part.