Preloader & boot logs analysis.

[shomykohai]

Logs can be dumped via mtkclient:

mtk r expdb expdb.bin --loader sources/MT6768_USER.bin --preloader sources/preloader_penangf

[shomykohai]

Proinfo partition loading

[151] [LK_BOOT] Load 'proinfo' partition to 0x4c5c0b80 (1024 bytes in 0 ms)

[shomykohai]

@progzone122 do you have any idea of what the 1s and 0s sequence in proinfo stands for? Isn't that the file with serial number etc?

Also, what is -SkipMD? I could only find this project that has that same string. https://github.com/Mubshr07/MotoTool_MTK

[progzone122]

Also, what is -SkipMD?

Theory:

• Skip MarkDown
• Skip MD5

[shomykohai]

Given the context, it doesn't seem like it.
Could it be some carrier verification? We would need a carrier locked device dump to confirm it tho

[shomykohai]

https://xdaforums.com/t/mtk-mddb-write-imei-mauimeta-v10-1816-0-01.3899267/
I think it's related to Metamode

[progzone122]

https://xdaforums.com/t/mtk-mddb-write-imei-mauimeta-v10-1816-0-01.3899267/ I think it's related to Metamode

Sounds plausible, perhaps

[shomykohai]

Boot mode & boot reason:

BOOT_REASON: 4
BOOT_MODE: 0

This article explains all the details

https://www.lieberbiber.de/2015/07/05/mediatek-details-little-kernel/

[shomykohai]

We can know the time of the logs!

Current RTC time:[2024/12/12 18:35:19]

This helps a lot to identify specific logs for various tests we do

[progzone122]

Yeah, it's good that the RTC time shows

[shomykohai]

Good news is that we can also identify times where the battery is removed (or not identified, or the RTC reset for some reason like flashing):

Current RTC time:[2010/1/1 0:0:50]

This is from your logs, to be precise the latest occurrence of the Current RTC log

[shomykohai]

Unrelated from preloader, but

[sys.oem_unlock_allowed]: [1]

[ro.boot.flash.locked]: [1]

And finally no output for what we actually care about

[progzone122]

Can you try to unlock the bootloader via fastboot and then send logs?
There might be something interesting there

[shomykohai]

logs.txt
I'm also gonna remove old logs i've sent after i found out sensitive device information (like serial number) are included. I cleaned these.

I also found out that it doesn't matter how the logs ends: after the end of the available partition space is reached, it starts writing from the beginning. So maybe your logs end in a random stage but continue at the beginning

[progzone122]

logs.txt I'm also gonna remove old logs i've sent after i found out sensitive device information (like serial number) are included. I cleaned these.

I also found out that it doesn't matter how the logs ends: after the end of the available partition space is reached, it starts writing from the beginning. So maybe your logs end in a random stage but continue at the beginning

I deleted my logs too, thanks for the warning

[progzone122]

logs.txt I'm also gonna remove old logs i've sent after i found out sensitive device information (like serial number) are included. I cleaned these.

I also found out that it doesn't matter how the logs ends: after the end of the available partition space is reached, it starts writing from the beginning. So maybe your logs end in a random stage but continue at the beginning

Interesting

[7676] fastboot: processing commands
[27852] [fastboot: command buf]-[flashing unlock]-[len=15]
[27852] [fastboot]-[download_base:0x4e000000]-[download_size:0x0]
[27852] [Cmd process]-[buf:flashing unlock]-[lenBuf:]
[SEC_USBDL] 0x22, SC

[2471] [set_hw_locked_in_atf]
[2471] [set_hw_locked_in_atf] error: MD_HW_REMAP_LOCKED fail: 0xFFFFFFFF
[2471] lk info.lk_info_base_addr: 0x9fff0000
[2471] lk info.lk_info_size:      0xa30
[2471] lk info.lk_info_tag_num:   0x14

[shomykohai]

Mmmh maybe we can understand how the bl key is derived?

We need to get more logs for sure.
If you can gather logs from other devices it would be useful, I've made a new utility to gather logs and clean them to make it easier moto-penangf/fuckyoumoto@592f8c4

[shomykohai]

logs.txt I'm also gonna remove old logs i've sent after i found out sensitive device information (like serial number) are included. I cleaned these.
I also found out that it doesn't matter how the logs ends: after the end of the available partition space is reached, it starts writing from the beginning. So maybe your logs end in a random stage but continue at the beginning

Interesting

[7676] fastboot: processing commands
[27852] [fastboot: command buf]-[flashing unlock]-[len=15]
[27852] [fastboot]-[download_base:0x4e000000]-[download_size:0x0]
[27852] [Cmd process]-[buf:flashing unlock]-[lenBuf:]
[SEC_USBDL] 0x22, SC

[2471] [set_hw_locked_in_atf]
[2471] [set_hw_locked_in_atf] error: MD_HW_REMAP_LOCKED fail: 0xFFFFFFFF
[2471] lk info.lk_info_base_addr: 0x9fff0000
[2471] lk info.lk_info_size:      0xa30
[2471] lk info.lk_info_tag_num:   0x14

Also, I've only tried fastboot flashing unlock without using using a key, maybe we get different output if we do?

[shomykohai]

@progzone122 there's a thing called usb2jtag in fastboot.
I don't know if we have access to this command, but take a look here: https://github.com/tanish2k09/venom_kernel_aio_otfp/blob/master/drivers/misc/mediatek/usb2jtag/Kconfig

This is what it should do

[progzone122]

@progzone122 there's a thing called usb2jtag in fastboot. I don't know if we have access to this command, but take a look here: https://github.com/tanish2k09/venom_kernel_aio_otfp/blob/master/drivers/misc/mediatek/usb2jtag/Kconfig

This is what it should do

WOW! It worked and it rebooted into the system

diablo-pc :: ~ 130 » fastboot oem usb2jtag 1
(bootloader) Enable USB2JTAG
(bootloader) rebooting device for usb2jtag support..

OKAY [  0.011s]
Finished. Total time: 0.011s

[progzone122]

It stopped being detected by my PC, so it definitely worked for me

Note: Parallel-wired JTAG Debugging and USB driver would be disabled in USB2JTAG debug mode.

[shomykohai]

Could we use this somehow?

[progzone122]

Could we use this somehow?

idk, maybe the pins on the usb output are reassigned to JTAG?

[shomykohai]

I can't find anything online.

Though I found something for UART related to this command

https://www.stevenhoneyman.co.uk/2014/11/mtk-mediatek-debug-cable.html

[progzone122]

I decided to remove my serial number from proinfo and as we can see the default one was assigned, but this did not lead to anything

diablo-pc :: ~ 130 » fastboot devices
0123456789ABCDEF	 fastboot
diablo-pc :: ~ » fastboot flashing unlock
(bootloader) Start unlock flow

FAILED (remote: 'Unlock key length is incorrect!')
fastboot: error: Command failed

[shomykohai]

Try with a 20 character key like
AABBCCDDEEFF11223344

Motorola keys are alphanumerical and 20 characters long

[progzone122]

Try with a 20 character key like AABBCCDDEEFF11223344

Motorola keys are alphanumerical and 20 characters long

diablo-pc :: ~/Desktop/fuckyoumoto 1 » fastboot oem unlock AABBCCDDEEFF11223344
FAILED (remote: 'unknown command')
fastboot: error: Command failed

[shomykohai]

What about flashing unlock?

[progzone122]

What about flashing unlock?

It doesn't need a key, there'll be an error

[shomykohai]

Uh, i remember one day getting the wrong key error.
Maybe I was in fastbootd?

[progzone122]

What is the “Test code” in lk?

[shomykohai]

I have no idea, maybe some test key to see if it works correctly? I dont think it can help us

[shomykohai]

@progzone122 try decompiling lk as ARM v8 (32bit) little endian, I was able to found stuff, I used AARCH64 before

[progzone122]

@progzone122 try decompiling lk as ARM v8 (32bit) little endian, I was able to found stuff, I used AARCH64 before

That's what I did

[shomykohai]

Good!
Do you think we'll be able to find how the key is derived by decompiling lk? Apparently the implementation of this part is proprietary code, so not available under public repos

[shomykohai]

It's our only way to find the specific algorithm imo

[progzone122]

I found something interesting!

[progzone122]

I think I've got it! We use fastboot oem key command to set the unlock key and then use fastboot flashing unlock command to unlock the bootloader! We need to find the unlock code

I think you're right!!

https://github.com/DavidBuchanan314/lk-mt6765/blob/20ecf47387a0e88f8db1e774e9bd86ba0609c935/lk/app/mt_boot/sec_unlock.c#L301-L315

By default fb_unlock_key_str is empty, so setting it does surely something! We always got the length error because what we had was an empty string buffer!

The unlock key is tied to the serial number, in fact the serial number is extracted from said key, and then compared; Given the fact that you cleared your serial number, we might get a universal key for default serial number if the SoC id is not used!!

Yes, after reboot, an error about the key length appears again

[shomykohai]

We just need this to return the B_OK and we will successfully unlock the device!

[progzone122]

We just need this to return the B_OK and we will successfully unlock the device!

I'll try to bruteforce the key. If there is no brute force protection - IT WILL BE VERY EASY and we will crack this shit!

[shomykohai]

@progzone122 did get_key give you a different output everytime or does it stay the same? Mine is the same as before after reboot

[cxzstuff]

I'll try to bruteforce the key. If there is no brute force protection - IT WILL BE VERY EASY and we will crack this shit!

Remembered this. Not the same but might give some ideas etc.
https://xdaforums.com/t/huawei-bootloader-brute-force.4151859/post-83904467

Problem is that our fastboot gets stuck easily. Happens even with Moto's RSA ...

[progzone122]

@shomykohai We can also get socid!

[shomykohai]

I thought we already had access with it with mtkclient, but good to know we can get it with fastboot too!

[shomykohai]

@progzone122 WAIT! I just noticed the first line of the socid is the same as the key in get_key!!

[progzone122]

@progzone122 WAIT! I just noticed the first line of the socid is the same as the key in get_key!!

yes

[progzone122]

[progzone122]

Found a command that outputs fastboot logs -> fastboot oem dump_pllk_log

[shomykohai]

Using expdb logs works better imo, they're formatted better and give more insight.

Anyway, here the full list of commands from lk

oem p2u -- sets UART logs
oem dump_pllk_log -- dumps preloader and lk logs
oem off-mode-charge -- No idea, doesn't work with security enabled
oem key -- Sets BL key
oem lks -- Return the lockstate (1 -> locked, 0 -> unlocked)
flashing unlock -- unlock bl
flashing lock -- lock bl
flashing get_unlock_ability -- If we can unlock
oem get_socid -- SoC ID
oem get_key -- Need to figure out why it returns the SoC id first part
oem scp_status -- Crashes fastboot
oem scp_log_thru_ap_uart -- Redirects SCP (I don't know what it is) to UART
oem usb2jtag -- I think it allows to use a modded usb cable as a JTAG?
set_active: -- Sets the current active slot, doesn't work with locked state
oem ultraflash: -- Flashes big files
oem ultraflash_en -- Same as above i guess
oem channel_model_name -- We can't use it
oem country_code -- Same
oem target_product -- Same again
oem hw -- We can set phone specific stuff with this, like utags and more, but only on unlocked bootloader

[shomykohai]

Also, we don't have any flashing unlock_critical: https://moto-penangf.github.io/documentation/#/info/fastboot

[progzone122]

Also, we don't have any flashing unlock_critical: https://moto-penangf.github.io/documentation/#/info/fastboot

It works fine for me and nothing hangs up

[shomykohai]

Mmh, interesting.
From my expdb logs i was able to see that considered _unlock part of something else, and not of the command

[shomykohai]

@progzone122 This device uses the same command as ours to unlock bootloader
https://xdaforums.com/t/bootloader-unlock-ne1-nokia-3-guide-to-unlock-the-bootloader-of-nokia-3-ta-1020-ta-1028-ta-1032-ta-1038.4012285/

I don't think they really use md5, but you might give it a try, but first you have to restore your serial number in proinfo (if the default one is used, it seems like the BL tries to recalculate it using soc id and hw key).

Looks like md5 and our unlock key both are 32 characters long too 🤔

[shomykohai]

Mmh, then I guess you were right, they could also be using other stuff to calculate the key.

We need to decompile lk to be sure, but I don't know where to start to find the function related to this.

Also, if we find a way to unlock, in my opinion the keygen should only be made public after the support ends, to avoid eventual patches to the bootloader partition

[progzone122]

Mmh, then I guess you were right, they could also be using other stuff to calculate the key.

We need to decompile lk to be sure, but I don't know where to start to find the function related to this.

Also, if we find a way to unlock, in my opinion the keygen should only be made public after the support ends, to avoid eventual patches to the bootloader partition

Support is already ending, so it's not critical. We will just investigate the algorithm, and the script itself will be made publicly available later

[shomykohai]

What worries me is that apparently Nokia on some of their old phone revoked bootloader unlocking with an OTA, and with other phones they patched an exploit to unlock on the latest OTA before support ending.

What stops Moto from doing the same?

Just to be sure, is lk marked as updatable in our scatter file?

[progzone122]

Just to be sure, is lk marked as updatable in our scatter file?

no

[progzone122]

What worries me is that apparently Nokia on some of their old phone revoked bootloader unlocking with an OTA, and with other phones they patched an exploit to unlock on the latest OTA before support ending.

What stops Moto from doing the same?

Just to be sure, is lk marked as updatable in our scatter file?

Just don't update just in case and that's it

[progzone122]

I look forward to your support from your side
https://forums.lenovo.com/t5/moto-g23/Bootloader-unlocking-is-available-Provide-us-with-a-possible-unlock-key/m-p/5355412

[shomykohai]

Is this another mtkclient wrapper? Found it mentioned under mtkclient issues and someone reported that it worked, but I assume it needs brom too

https://bypassfrpfiles.com/2022/02/mediatek-easy-tool/

[progzone122]

Yeah, it's probably just another wrapper over mtkclient

[progzone122]

@shomykohai https://moto-penangf.github.io/documentation/#/modes/preloader

[shomykohai]

But what if the signature is stored in the device itself?

[progzone122]

MT6768_USER.bin

DAXFlash - Uploading xflash stage 1 from MT6768_USER.bin
DAXFlash - Successfully uploaded stage 1, jumping ..
Preloader - Jumping to 0x200000
Preloader - Jumping to 0x200000: ok.
DAXFlash - Successfully received DA sync

DA_PL_NO_CERT

DAXFlash - Uploading xflash stage 1 from DA_PL_NO_CERT_V6.bin
Preloader
Preloader - [LIB]: upload_data failed with error: DAA_SIG_VERIFY_FAILED (0x7024)
Preloader
Preloader - [LIB]: Error on uploading da data
DAXFlash
DAXFlash - [LIB]: Error on sending DA.

[shomykohai]

Why we can use DA_PL_NO_CERT in Flash Tool, but in mtkclient the error is DAA_SIG_VERIFY_FAILED???

You're right 🤔, do we have another mtk tool apart from mtkclient and sp flash tool to verify if we get the same error?

[progzone122]

Why we can use DA_PL_NO_CERT in Flash Tool, but in mtkclient the error is DAA_SIG_VERIFY_FAILED???

@shomykohai

[progzone122]

Why we can use DA_PL_NO_CERT in Flash Tool, but in mtkclient the error is DAA_SIG_VERIFY_FAILED???

You're right 🤔, do we have another mtk tool apart from mtkclient and sp flash tool to verify if we get the same error?

We should figure this out, maybe it will help us

[progzone122]

I modified DA a little and now I'm stuck in this mode. It seems I need to turn off the battery for it to turn on...
In short, it is possible to edit DA, but only partially

[progzone122]

At what stage do we need to make a failure to get into BROM and have access to mtkclient?

[shomykohai]

At what stage do we need to make a failure to get into BROM and have access to mtkclient?

iirc when sending 1st DA

[progzone122]

At what stage do we need to make a failure to get into BROM and have access to mtkclient?

iirc when sending 1st DA

We can only make a failure in some parts where the signature is not checked. And this is only stage2... But maybe we can somehow allow writing to partitions?

[shomykohai]

Could work, try looking at this: https://github.com/bkerler/mtkclient/blob/main/Tools/patch_preloader.py#L39

[progzone122]

Okay, we can cause a failure, but we can't change anything, because the hash is still being verified somewhere. This is VERY difficult to do.

[progzone122]

If the phone is stuck in preloader: You need to press ALL buttons and hold them for 10 seconds

[shomykohai]

I usually just do Vol- & Power

[progzone122]

I usually just do Vol- & Power

This won't work if your preloader is frozen

[shomykohai]

Better add this to the documentation

[shomykohai]

Moto g22 firmware has some utilities like ewriter (for writing e-fuses), could one of these utilities be useful for us?

[shomykohai]

@progzone122 unrelated for g23, but in the g24 firmware there's a file called "boot-debug.img" and "vendot-boot-debug.img".

Do you think they could be used to unlock g24? It could be something that might help us since they share the same chipset 🤔

[progzone122]

idk, but we also have vendor_boot-debug, trying to flash it gave red state

[progzone122]

@shomykohai @cxzstuff

We can indeed flash protected partitions with DA_PL_NO_CERT, which we cannot flash with MT6768_USER.
Why mtkclient doesn't want to work with DA_PL_NO_CERT? Maybe with this DA we can edit the seccfg partition?

[shomykohai]

@progzone122 now that I think about it, have you tried old sources with spft? like the one which gave us errors like anti rollback etc...
I remember some giving just hash mismatch 🤔

[progzone122]

What I want to know is if RSA uses just one da file or for some reason uses both in a way we don't know...

We can delete one of the DA files and check, but most likely it's just using DA_PL_NO_CERT. Because I threw above how I flash the lk partition just with flash tool

[progzone122]

I remember some giving just hash mismatch 🤔

this error exists in any flash tool when using DA_PL_NO_CERT, you need to disable hash checking (which is done automatically in the flash tool, which is downloaded from RSA).

[progzone122]

now that I think about it, have you tried old sources with spft? like the one which gave us errors like anti rollback etc...

Yes, these errors are all present

[cxzstuff]

What I want to know is if RSA uses just one da file or for some reason uses both in a way we don't know...

For G24 SPFT uses one. I posted the command line to other thread. Standard command.

[progzone122]

@shomykohai Interesting...

[shomykohai]

@shomykohai Interesting...

Yeah, I talked about this in another thread.
Basically it checks the preloader partition and based on a condition I can't understand in the decomp + mtk_detect_key(0), it calls platform safe mode

[shomykohai]

Oh and it also checks for "is_BR_cmd_disabled ()", but I don't understand what this function does. Anyway you can find it in the preloader forked repo!

[shomykohai]

Though I opted for the download keys combination instead of this because in the logs there's no hint of this condition being called, so I don't know if it checks for efuse, or it needs a bricked preloader.

This function is called before the "PL delay for long press reboot" message in the logs and after PL Fatal Error.

I'm sure the function for the download keys is called because I got it to check KPCOL0, which is checked only in these 2 instances + fastboot entering (or at least this is what I've found)

That's why I want to see if there's a way to detect key 8 (pwrkey) during boot, because that's would mean we could really try going to brom.

[shomykohai]

Now that the bootloader can be unlocked, does this mean we can use mtkclient with any DA file? To be able to access all features of it

[progzone122]

@shomykohai please check your commits in fork, we are not the only ones using the site anymore.

[progzone122]

Tested. Now if there's a compilation error, it won't upload the broken documentation to github pages (because the workflow will end before it reaches that step), and there's no more the issue where the site will show a broken page for 30 seconds. We can safely make commit too if needed

But you may have a 404 displayed for a while during deployment.

[shomykohai]

Tested. Now if there's a compilation error, it won't upload the broken documentation to github pages (because the workflow will end before it reaches that step), and there's no more the issue where the site will show a broken page for 30 seconds. We can safely make commit too if needed

But you may have a 404 displayed for a while during deployment.

No more

[shomykohai]

As I said the issue was a double deployment, with one being the plain repo without compiling it with npm, so that's why the 404

[progzone122]

As I said the issue was a double deployment, with one being the plain repo without compiling it with npm, so that's why the 404

oh...ok. Fixed?

[shomykohai]

As I said the issue was a double deployment, with one being the plain repo without compiling it with npm, so that's why the 404

oh...ok. Fixed?

Yup, just had to change this setting from "deploy to branch" to "Github Actions"