After u unlock it, everything on the phone is erased. I just went back into LunarOS and re-enabled USB-debugging and then plugged it into my computer. After issuing
adb devices
it again wanted to authenticate my computer. Then I disabled the lockscreen and then gave
adb devices
adb reboot fastboot
I was then able to get no errors with
fastboot --set-active=a
I will try to flash the 2026 BraX3 files onto my 2025 BraX3 and see if it takes. Iode’ doesn’t have 2 separate branches for BraX3 in their software so this should work!
I’ve installed this numerous times now on my 2025 BraX3 today and from 2 different computers and I keep getting boot loops from the software Daniel made for the 2026 BraX3. I don’t know how to do much with AI but I’ll see if I can get it to make flashable Droidian software for this phone from the file that Daniel provided.
Three cheers, Daniel. Your effort - and the $30 credit for the unshipped SD card - gave me the kick I needed to buy a 2026 brax3 as a playground, since my 2025 is now my daily driver.
I don’t know to much about the actual code side. But you already have it running, do you think it would be hard for a newb to port what you have for a 2025 or beta tester model ?
I already have a beta tester and a first batch brax3 and don’t really want to buy a third one lol but would love to test out your port.
Published a new recovery + unlock kit for the BraX3. Like divde, I ended up with a locked bootloader and a phone that wouldn’t boot after flashing.
The method that’s been going around rebuilds a combined flash image that zeroes any partition it doesn’t have a source for including seccfg and the NV partitions. If your device is already scrambled that’s fine, but if your IMEI/NV are still intact, zeroing them puts you in a worse spot.
This kit takes a different route: it unlocks the bootloader by writing seccfg directly from BROM (patched mtkclient), and restores a bootable preloader to get the phone booting again — without touching NV or wiping unrelated partitions. So you keep your IMEI and your data.
Thank you for writing an improved guide like this.
A small remark: I think it is no longer needed to use my preloader_k6835v1_64_patched.bin. It is based on the old preloader that is only compatible with the first batch and the patches mainly* disable some asserts that prevent it from working on a BraX3 of new batch.
Instead, it is better to use the 2026 official preloader you provided that is fully compatible with the new batch.
*Note: the patched preloader also includes a patch that allows “mtk peek” but this is actually not needed to repair the device.
Good point. In this procedure that patched preloader is only loaded to RAM by mtkclient (–preloader) as a temporary bring-up stage, never written to flash. It works fine on the new batch in practice (tested on newest hardware). You’re right that there’s no reason to depend on the assert-patched old-batch one when the official 2026 preloader is natively compatible, agreed the mtk peek patch isn’t needed for the repair. Thanks!