MT6589 BROM request
ErfanMG2020 opened this issue · comments
Hi,
I've read nearly all of your notes about these old mediatek devices.
I was recently surfing the internet to figure out how to unlock bootloader of my MT6589 device.
It's Huawei G610-U20 and I wanted to do something to be able to flash modified *.imgs via flash tool to my device.
Currently it only flashes signed imgs with flash tool version 3.1320.0.sn174 (Secboot) and doesn't work on other versions or with unsigned imgs.
I just wanted to know how to unlock this and tried with mtkclient. It gets Handshake failed error : #748 and #716.
Is possible to get BootROM and add support to mtkclient to unlock this device's bootloader or something like this?
I asked you to help and provide MT6589 BootROM you've dumped as you explained in your notes.
Thank you anyway.
It's Huawei G610-U20 and I wanted to do something to be able to flash modified *.imgs via flash tool to my device. Currently it only flashes signed imgs with flash tool version 3.1320.0.sn174 (Secboot) and doesn't work on other versions or with unsigned imgs.
This model seems to have a TWRP, can't it flash .img, can it? Or is it just your specific need to use Flash Tool instead?
Is possible to get BootROM [...] I asked you to help and provide MT6589 BootROM you've dumped as you explained in your notes.
Sure! The BROM dump is available in my SoC-BootROMs repository: https://github.com/arzam16/SoC-BootROMs/tree/5e362df0cc2497d73fc0fce0779becddfebaff87/mediatek/MT6589WTK%201325-ATAH%20DTNGT126 Please keep in mind the BROM dump was made from a device with no security measures enabled. Your Huawei definitely has some and your BROM might differ (with a small chance).
and add support to mtkclient to unlock this device's bootloader
Sorry, this is out of my scope. I don't support mtkclient but you can reach its developer out ;)
By the way, why didn't you dump the BROM yourself? Did you encounter some problem with spft-replay/payloads that needs a fix? If you are going to dump it yourself please avoid killing the preloader like I do because you might have """fun times""" restoring it on your device. The only reason I kill the preloader is because it's the always-working method to get the device to boot into BROM mode with 0e8d:0003 vid/pid. You should check if pulling the battery and/or holding one of the volume keys has same effect. Try some combinations and see if it works.
Can't it flash .img, can it?
Yes, it can. I also have installed my custom firmware (I self compiled from its ALPS 4.4 sources) but there is something I need to do with flash tool; like re-partitioning device and so on.
Sure!
Thanks, I will try it. I plan to contact its developer for add support.
By the way, why didn't you dump the BROM yourself?
Oh, Yes; I really like to do this my self but I am beginner (despite my age in these works) and I need full and detailed advices.
If you help me a bit maybe I can do this my self. So start from where? I have Ubuntu 22.04 installed and a little knowledge about linux commands. How I detect whenever my device is in bootloader / BootROM mode in a simple way? Then what should I do next?
Yesterday I downloaded a software that crashed my device's preloader and switched to BootROM mode and showed some info about chip and so on. But it couldn't unlock bootloader because of unsupported chip. Can it help?
And there is another thing, as I have the source code for MT6589, I can compile preloader for it. Can new unlocked preloader and flashing it help the phone to be unlocked?
[Edit :] I have tested spft-replay.py -i and it waits for device, I tested pushing volume keys and power keys without battery with no luck. Should I install some extra depencies / drivers to detect device or It just doesn't go into BootROM mode?
So start from where? I have Ubuntu 22.04 installed and a little knowledge about linux commands.
First of all, you should tell your operating system to allow you to interact with BROM mode without sudo. It's done with an udev configuration file. I created a file /etc/udev/rules.d/25-mtk-plugdev.rules with the following contents:
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0e8d", ATTRS{idProduct}=="0003", MODE="660", GROUP="plugdev"
Then reloaded the rules: sudo udevadm control --reload. The path for udev configuration files might be different on Ubuntu, you should figure it out. Ensure your current user is in the plugdev group by looking at the output of the id program.
How I detect whenever my device is in bootloader / BootROM mode in a simple way?
The most simple way I know is to run dmesg -w and watch for its live output. Once you connect a USB device its VID/PID will appear in the log. 0e8d/2000 is Preloader mode (spft-replay doesn't work with it), and you need to get the 0e8d/0003 device. The service manual for your device says the following:
And the schematic says:
As you can see, KCOL0 is Volume- so holding this key while connecting the phone to PC should boot it into the BROM mode. However, this 4PDA forum post (russian language) suggests it might not work for some reason. In this case, check if the ID pin on the microUSB connector is connected to the ground because:
Also try connecting with both and without the battery.
btw some Huawei phones are known to have a bit different VID/PID pairs and you might get a USB device with other identificator. Let me know if it's your case and I will add support for them in spft-replay.
Then what should I do next?
Once you figured out how to get into the BROM mode you are ready to use spft-replay. Pay attention to its dependencies. On Debian/Ubuntu you need to install at least libusb-1.0-0 and libusb-1.0-0-dev in advance to get it working. You should connect your phone in BROM mode after spft-replay tells you it waits for a connection. For starters, you can run it in the identification mode: ./spft-replay.py -i.
I can compile preloader for it. Can new unlocked preloader and flashing it help the phone to be unlocked?
Yes and no: If your BROM checks the signature of your Preloader it will refuse to start it. The cryptographic signature is burned into the CPU and cannot be changed. There's no 100%-safe way to check that.
If your BROM doesn't check the preloader signature you are good to go but you must also flash your freshly compiled U-Boot or LK (or whatever does MT6589 ALPS have as an OS loader) because both of them have security measures.
In this case, check if the ID pin on the microUSB connector is connected to the ground
According to your diagram I planned to use a Samsung microUSB OTG connector, because :
The ID pin is connected to GND there and this might be a trick, But I had no luck. same result here :
Now we should move to another way to get into BootROM mode.
A question : Can't we crash preloader and go into BootROM like bypass-utility tool or something?
I said above that I tested a random software that crashed preloader and get into BootROM mode and get some info about chip.
Can't we use this way like them?
And If this all fail I should try your way to get into BootROM.
Thanks for your help and support 👍🏻 .
Can't we crash preloader and go into BootROM like bypass-utility tool or something?
Sure, it's possible. However, spft-replay does not support crashing preloader. Actually, preloader support was the first thing to be removed when I've been working on porting code from bypass_utility's device.py - the idea was to work with BROM mode only because working with preloader is problematic in general. I will not reimplement the preloader support in spft-replay.
I spent some time looking into existing solutions. bypass_utility in crash mode (-m 0/1/2) never worked on my computer, yielding some weird error where it expects to receive 0xFD but actually receives 0x0A. Same with the other crash modes.
mtkclient crash is interesting because modes 0 and 1 didn't work on mt6589 at all but --mode 2 made the device reboot into BROM however I noticed it wasn't stable. I think I has to do something with the USB passthrough on my virtual machine. Try it yourself. Once you reboot into BROM with mtkclient crash --mode 2 try to point spft-replay at it.
Thanks for your support, I really appreciate you.
After I posted the last comment, updated some codes for compiling a new and more compatible preloader for my Huawei device. I also tried for LK/Uboot, but there was a problem with lcm driver that caused device not to start.
If your BROM checks the signature of your Preloader it will refuse to start it.
... If your BROM doesn't check the preloader signature you are good to go.
I accepted some risk and tried to flash new preloader to my device with Old Flash tool which was the only that works to flash my device. Fortunately flash tool did not gave any error and it updated preloader as usual; I turned it on, there was no vibration but started up normally.
Then I tested flashing an unsigned (custom) recovery image using same flash tool, and I surprised; it worked! The real thing is newer flash tool v5.13.52.200 also works after flashing this preloader and phone is somehow unlocked now.
I did flashing in Windows, then I moved back to Linux for further checking.
Now when I connect device to computer without battery and push volume down button while tracking USB devices status in terminal using dmesg -w, device appears with idProduct=0003 which means it goes into BootROM mode by default after flashing new preloader. I think it's because the preloader isn't securing the device and does not have restrictions.
Once you figured out how to get into the BROM mode you are ready to use spft-replay.
I tested ./spft-reply.py -i and it detected device. Now we should move to next step : getting BootROM from device.
Actually my main problem is solved but I want to go further in this way, or finish it if possible.
According to your guide in Dump log, I expected that it can be done with ./spft-replay.py -p ../payloads/build/release/piggyback/mt6589-usb-dump.bin -pr, which needs mt6589-usb-dump.bin payload.
It wasn't available in your repo, but I tried to make them using your sources, I checked your Makefile, it first tries to download a version of flash tool for linux from a link, which has been block by my ISP. I did some changes but made its Makefile dirty. Now I'm asking for help about compiling payloads (ex. to update your Makefile) or use ready ones if is available in your repos.
... turned it on, there was no vibration
There is another minor problem about new preloader, the phone does not vibrate when turning on (like original one) and I think it may depend on source codes, but I don't know where to check. I also asked it in 4PDA but nobody replied.
Thank you anyway.
Then I tested flashing an unsigned (custom) recovery image using same flash tool, and I surprised; it worked! The real thing is newer flash tool v5.13.52.200 also works after flashing this preloader and phone is somehow unlocked now.
This is awesome, good job!
It wasn't available in your repo, but I tried to make them using your sources, I checked your Makefile, it first tries to download a version of flash tool for linux from a link, which has been block by my ISP
One of the possible solution to this is using some sort of proxy to bypass the ISP block (such as: system-wide Socks5 proxy, free OpenVPN config from vpngate) but such topics are out of scope of this repository.
I did some changes but made its Makefile dirty.
In order to get things running, you just needed to put SP_Flash_Tool_v5.1648_Linux.zip into brom-dump/payloads/build/aux, no need to edit Makefile :P For example, you could've tried using Tor browser to download it manually.
Now I'm asking for help about compiling payloads (ex. to update your Makefile) or use ready ones if is available in your repos
This is the USB Dump payload for mt6589, built from commit d865984 using the armdeveloper-11.2-2022.02-arm-none-eabi toolchain:
As I understand, your steps for dumping the BROM should be as following:
- Pull the battery
- (
spft-replaywaits for a connection here) - Connect the USB cable while holding the Vol- key
- Release the Vol- key once the phone connects as a BROM device
- Wait till
spft-replayfinishes - Disconnect the USB cable
There is another minor problem about new preloader, the phone does not vibrate when turning on (like original one) and I think it may depend on source codes, but I don't know where to check. I also asked it in 4PDA but nobody replied.
Sounds like a GPIO mismatch issue. Did you check the DrvGen program before building your preloader?
Today I edited your Makefile again, Downloaded SP_Flash_Tool_v5.1648_Linux.zip manually and added a code to copy this file inside its folder instead of downloading it using wget. It gave some errors related to dependencies which I installed them and finally build was successful. Then I tried :
erfan@Erfan-HP8A50:~/Downloads/brom-dump/spft-replay$ ./spft-replay.py -p ../payloads/build/release/piggyback/mt6589-usb-dump.bin -pr
[2023-08-20 12:54:44,623] <INFO> Waiting for device in BROM mode (0E8D:0003)
[2023-08-20 12:55:03,217] <INFO> Found device
[2023-08-20 12:55:03,224] <INFO> Handshake completed!
[2023-08-20 12:55:03,224] <INFO> Payload size 142804 bytes (0x00022DD4)
[2023-08-20 12:55:03,225] <REPLAY> HW code: 6583
[2023-08-20 12:55:03,225] <REPLAY> Identify
[2023-08-20 12:55:03,225] <REPLAY> HW subcode: 8A00
[2023-08-20 12:55:03,225] <REPLAY> HW version: CA01
[2023-08-20 12:55:03,226] <REPLAY> SW version: 0001
[2023-08-20 12:55:03,226] <REPLAY> Initialize PMIC
[2023-08-20 12:55:03,235] <ERROR> Could not set PMIC reg 0x000C to 0049, got 0009
[2023-08-20 12:55:03,241] <REPLAY> Disable watchdog
[2023-08-20 12:55:03,242] <WARNING> Cannot get PRELOADER version in BROM mode
[2023-08-20 12:55:03,243] <REPLAY> TOPRGU register 0x10000000 == 00000024
[2023-08-20 12:55:03,243] <REPLAY> TOPRGU register 0x10000004 == 0000FFE0
[2023-08-20 12:55:03,244] <REPLAY> TOPRGU register 0x10000008 == 00000000
[2023-08-20 12:55:03,245] <REPLAY> TOPRGU register 0x1000000C == 00000000
[2023-08-20 12:55:03,246] <REPLAY> TOPRGU register 0x10000010 == 00000FFF
[2023-08-20 12:55:03,247] <REPLAY> TOPRGU register 0x10000014 == 00000000
[2023-08-20 12:55:03,248] <REPLAY> TOPRGU register 0x10000018 == 00000000
[2023-08-20 12:55:03,248] <REPLAY> Initialize RTC
[2023-08-20 12:55:03,248] <REPLAY> Identify software components
[2023-08-20 12:55:03,248] <REPLAY> BROM version: 05
[2023-08-20 12:55:03,248] <WARNING> Cannot get PRELOADER version in BROM mode
[2023-08-20 12:55:03,248] <REPLAY> Initialize external memory interface
[2023-08-20 12:55:03,250] <REPLAY> EMI_GENA (0x10203070) set to 00000002, was 00000000
[2023-08-20 12:55:03,250] <REPLAY> Send payload
[2023-08-20 12:55:03,254] <INFO> Uploaded 1024 out of 142804 bytes (0%)
[2023-08-20 12:55:03,555] <INFO> Uploaded 116736 out of 142804 bytes (81%)
[2023-08-20 12:55:03,626] <INFO> Uploaded 142804 out of 142804 bytes (100%)
[2023-08-20 12:55:03,640] <REPLAY> Received DA checksum: A6B7
[2023-08-20 12:55:03,640] <REPLAY> Jump to payload
[2023-08-20 12:55:03,645] <REPLAY> Wait for remaining data
[2023-08-20 12:55:03,650] <REPLAY> <- DA: (unknown) C0
[2023-08-20 12:55:03,705] <REPLAY> <- DA: (unknown) 00000BC4
[2023-08-20 12:55:03,706] <REPLAY> <- DA: (unknown) 0005
[2023-08-20 12:55:03,707] <REPLAY> <- DA: (unknown) 00000000000000000000
[2023-08-20 12:55:03,707] <REPLAY> <- DA: (unknown) 00000000
[2023-08-20 12:55:03,708] <REPLAY> <- DA: (EMMC CID) 484A019064314734A4018604E1C10D70
[2023-08-20 12:55:03,708] <REPLAY> -> DA: (OK) 5A
[2023-08-20 12:55:03,709] <INFO> Waiting for custom payload response
[2023-08-20 12:55:03,709] <INFO> Received HELLO sequence
[2023-08-20 12:55:03,709] <INFO> Reading 65536 bytes
[2023-08-20 12:55:03,814] <INFO> Saved to dump-1.bin
[2023-08-20 12:55:03,814] <INFO> Reading 65536 bytes
[2023-08-20 12:55:03,908] <INFO> Saved to dump-2.bin
[2023-08-20 12:55:03,908] <INFO> Reading 262144 bytes
[2023-08-20 12:55:04,355] <INFO> Saved to dump-3.bin
[2023-08-20 12:55:04,356] <INFO> Received GOODBYE sequence
[2023-08-20 12:55:04,356] <INFO> Closing device
It was done without problems; and I compared dumped files with yours using md5sum, there were not any difference.
And finally it finishes :)!
Sounds like a GPIO mismatch issue. Did you check the DrvGen program before building your preloader?
Oh, thanks for this tip. I will check DrvGen, but kernel is compiled and works well with current DrvGen and codegen.dws.
However I retry to compile preloader with other DrvGen.
Thank you!
It was done without problems; and I compared dumped files with yours using md5sum, there were not any difference.
And finally it finishes :)!
Congrats! Thanks for your effort in dumping the BROM! I will close this Issue because this problem is now resolved.
Hi, every try I've made to enter brom has failed. I can enter preloader and fastboot mode but not brom. Is there a simple and effective method to enter brom?
Thanks in advance.
@cristianc The easiest way to get into the BROM mode is to corrupt/damage the preloader. If your device has root you can execute something like dd if=/dev/urandom of=/dev/preloader oflag=direct bs=32k count=1. I usually use the Write Memory option in SP Flash Tool to write a small chunk (32-64 kB is enough) of random data to 0x0. Please make sure in advance you've got a backup of your preloader. The BROM will try to boot the preloader but will encounter random data instead, and it will enter the USB mode you've been looking for. I use SP Flash Tool to recover the damaged preloader after my experiments to make my device working again.
@arzam16 , since the device is not rooted, I can't use dd. Should I try by SP Flash Tool? In such case, I've to find a way to make a backup, first
@cristianc Yes you can try SP Flash Tool. Please don't assume I'm advocating for closed-source proprietary software, actually you can use any tool you would like, but as I am speaking from my personal experience, out of everything I tried SP Flash Tool worked the best.
Speaking of backup, I recommend searching the internet for a flashable firmware for your device. You should be looking for an SP Flash Tool-compatible firmware (an archive that contains a scatter file, and a bunch of .img and .bin files), not a firmware for android recovery. Once you've got a complete firmware you can load the scatter in SP Flash Tool and damage/corrupt the preloader using the "Write Memory" option. Make sure in advance the firmware you've downloaded has a preloader.bin or a similarly named file. You will use it to restore the original preloader later.
Hello @arzam16,
I just wanted to drop a quick thank you for creating such a great tool. It really came in handy for me, especially after struggling for weeks to dump the bootROM of my BQ Aquaris 5 (MT6589).
I was on a similar path, trying to analyze the SP Traffic data and thinking about making a custom DA for the bootROM dump. But then I saw your work, and it was exactly what I needed, so I ended up scrapping my project :)
Awesome job with this! Keep up the good work.
@arzam16 ,
Yes you can try SP Flash Tool. Please don't assume I'm advocating for closed-source proprietary software, actually you can use any tool you would like, but as I am speaking from my personal experience, out of everything I tried SP Flash Tool worked the best.
I'd like to use open source flash tools as mtkclient but it has no support currently for MT6589: bkerler needs a dump of BROM to add support for this SoC (see bkerler/mtkclient#716 (comment))
Speaking of backup, I recommend searching the internet for a flashable firmware for your device. You should be looking for an SP Flash Tool-compatible firmware (an archive that contains a scatter file, and a bunch of .img and .bin files), not a firmware for android recovery. Once you've got a complete firmware you can load the scatter in SP Flash Tool and damage/corrupt the preloader using the "Write Memory" option. Make sure in advance the firmware you've downloaded has a preloader.bin or a similarly named file. You will use it to restore the original preloader later.
So, do you mean I can use SP Flash Tool only if I've the scatter file (got from a stock firmware)? Can I make a complete backup of the device using SP Flash Tool before trying to damage preloader?
mtkclient but it has no support currently for MT6589
Then your only solution for now is to use SP Flash Tool. If your device has a thread on 4PDA, get the SP Flash Tool and flashable firmware from there, just don't forget to sign in to avoid weird download errors. You need to end up with this kind of firmware files:
(the picture is just an example, and your files might be named slightly different - that's totally okay)
Once you've got the firmware you shouldn't be afraid of experimenting because you'll always be able to restore. Now open the SP Flash Tool (I use v3 on Windows) and load the scatter file (again, the picture is just an example just to give you an idea of what to do):
Click "Window" -> "Write Memory" and navigate to the newly appeared "Write Memory" tab. Click "Open Raw Data" and select the tiny file you will use to corrupt the preloader (32-64 kB of random data), then select the memory type (most likely you'll need EMMC), and enter 0x0 into the "Begin Address (Hex)" field. Once you're ready, hit the "Write Memory" button and connect your device. You must reset its power after the flashing is done. Keep in mind if your device has non-removable battery it will drain quite fast because the device will always try to turn on but will keep hanging in the BROM mode.
Once you're done with everything and when you would like to restore, flash the "preloader.bin" image from the stock firmware to the PRELOADER partition using the "Download" button in SP Flash Tool (uncheck all other partitions).
@R0rt1z2 ,
Thank you so much for your kind words! I'm happy to know this project helped someone. I hope you didn't get frustrated setting up all these dependencies required to build the payloads and run spft-replay. I published a few sweet changes that document all dependencies for all the future users. Oh, and I also published the support for mt6252 and there's more to come!
@arzam16 , my question was just about if I can make a backup of the firmware currently running on the device (I was not talking about firmware downloaded from a website)
Waiting for a reply, Thank you.
Oh, I get it now. Yes you can make a complete backup of the existing firmware but it's quite a cumbersome task which, once again, depends on some proprietary software. The most reliable way I know is dumping the whole EMMC contents as a single huge file and processing it with WwR MTK to obtain flashable firmware files. I have to link the 4PDA thread with amazing guides on this matter, it's in russian language but Google Translate does a decent job at making a comprehensible translation out of this (I checked it myself).
If you are looking for making an incomplete backup such as just the PRELOADER partition you can use the "Readback" tab in SP Flash Tool but keep in mind you can't just flash this kind of backups using the "Download" tab (it's complicated to explain in a single sentence) and you'll have to use the "Write memory" tab.
If you are feeling extra adventurous you might even use "MTK Droid Root & Tools" by rua1. This program was made specifically for mt6577 and mt6589 and it can make a backup of firmware in just a few clicks. There are significant downsides, though! This program is super old, and it runs only on windows.
@arzam16 ,
The most reliable way I know is dumping the whole EMMC contents as a single huge file and processing it with WwR MTK to obtain flashable firmware files. I have to link the 4PDA thread with amazing guides on this matter
I've tried but I can't pass the CAPTCHAs required during registration.
Waiting for a reply, Thanks.
@cristianc please lets head over to the freshly opened issue to avoid spamming other people here with notifications. I'm locking the conversation here.