OEM key generation algorithm / Exploit lk

[progzone122]

https://moto-penangf.github.io/documentation/#/dev/oem-key-algorithm

@shomykohai

[shomykohai]

Might want to add that if the bootloader is the same as the public stock ones (or very similar), there's a chance the key has to be reversable to get the serial number.

But in that case, the serial number has to be in what format? 🤔

Anyway, I might try to reimplement the code in c later to see how it behaves

[shomykohai]

@progzone122 can you try unlocking bootloader using "Test code" as the key? Im decompiling lk and i want to check something 🤔

Not enough characters, there'll be an error

@progzone122 if you set the bootloader key to a random md5 hash, and then do get_key, do you get back the same key right?

[progzone122]

@progzone122 can you try unlocking bootloader using "Test code" as the key? Im decompiling lk and i want to check something 🤔

Not enough characters, there'll be an error

@progzone122 if you set the bootloader key to a random md5 hash, and then do get_key, do you get back the same key right?

I will get the same key as before. Most likely, this key is used to generate the oem key

[shomykohai]

Interesting... I have to find where this functions is

[shomykohai]

For some reason there's only one instance of "finish dump" in the lk file??
And it's from soc_id

Edit: Nvm, I found it

[shomykohai]

@progzone122 there's something really interesting:

The oem get_key command seem to be just a shorter clone of get_socid, which in fact only outputs the first line of it

What confirms this is that the error message for both of the functions is: = "\nget_socid failed - Err:0x%x\n"

[progzone122]

Through mtkclient we can find additional data that can participate in key generation

SOC_ID is the combined two keys from the fastboot oem get_socid command.

[shomykohai]

Iirc also ME_ID could be related in moto devices, don't know for ours though.

Try looking for the Moto G keygen thread on xda to find how the data is converted to unlock data.

[shomykohai]

@progzone122 I have the impression that moto devices have a fixed size serial number, and thus I was wondering if this is something that limits us, because I can't revert the hash function without a 16 character long serial num, so maybe we it's better to stick with the default mediatek serial, so maybe we can avoid these

from be used

[shomykohai]

@progzone122 what happens if you set the second part of the SoC ID as the fastboot key?

[progzone122]

Oh wait!! It's not sha256, it's sha512!!

Edit: Correction, could be sha512

💀💀💀

[shomykohai]

I'm trying to understand if they have a custom implementation of sha256 or what, I don't find any reference to the code I'm seeing

[progzone122]

I'm trying to understand if they have a custom implementation of sha256 or what, I don't find any reference to the code I'm seeing

I used both Ghidra and IDA. Nothing...

[progzone122]

I think as a last ditch effort we need to fill out everything we know in the documentation and make some posts on Reddit and XDA.
We've done all we can for now.

Maybe a solution will be found later

[shomykohai]

I really hope so, there must be a solution given the fact that the logic to unlock is there, especially because theoretically we know the input of the sha256 function, so it should be easier to find the right key compared to retrieve the original data from the hash.

These days I'll cleanup the code of the decomp and maybe add it to the documentation with the needed functions.

I saw there were already some posts of yours on XDA, could you make a post asking for ideas linking the documentation?
I don't know why we don't have a section there too, Moto g24 is there but g23 is not??

[progzone122]

I'm so pissed off at Motorola Agents
https://forums.lenovo.com/t5/moto-g23/Bootloader-unlocking-is-available-Provide-us-with-a-possible-unlock-key/m-p/5355412?page=1#6516106

[shomykohai]

It's a shame that they even reply saying they'll forward the request to the development team, I dont think they will

[progzone122]

It's a shame that they even reply saying they'll forward the request to the development team, I dont think they will

No, they responded

[progzone122]

But they don't guarantee it. WHY WHY WHY?

[progzone122]

I noticed something strange...
@shomykohai Can you check where these messages are coming from and how they are displayed?

[progzone122]

I'll continue to fill out the documentation.
We need to get as much of what we know in there as possible before we start asking for help on XDA and Reddit

[shomykohai]

I mean, it kinda looks like this fastboot has some bugs with buffers and stuff (I was able to crash/freeze fastboot many times by experimenting, like sending new lines as the unlock key and more)

I, too, when experimenting sometimes got unexpected results. Maybe we can use this to our advantage?

It all depends if we can write to USB while fastboot is hanging.

I wonder though if using sha256 of an empty string could really be a solution.

If not, we might exploit fastboot somehow

[shomykohai]

@progzone122 could you try compiling the file in the private repo and try to use it to generate a key?
I tried to replicate 1:1 (With the resources I had) the actual code.

You just put the first 32 characters of your soc_id in the algorithm and then take the first 32 characters of the buffer string

Also you need to download this to compile
https://gist.github.com/nilswiersma/526da7d85125a034f85da05f9cff85c3

[shomykohai]

@progzone122 If you already tried when I sent this message, could you try again? I forgot to add that about an hour later I've updated the source because I forgot something important

Edit: You might also want to try providing all the SOC_ID and not only the first part, too

[shomykohai]

@progzone122 please check the new things I added to this section: https://moto-penangf.github.io/documentation/docs/dev/bootloader#install-oem-key-to-unlock

They come from the comments above, and may come handy when trying to craft a payload.

I still have to figure out what does the vsnprintf function does to the hash to copy it into the buffer, it's something we need to know too as it may grant us a way to generate unlock codes or exploit the function, too.

[shomykohai]

I think lk uses the same crypto functions as preloader, which is not that great because we don't have the implementation, just the compiled library.

But a positive thing of this is that we have what could be a possible implementation in mtk client.

Another problem is that I don't really understand what the code is actually doing, probably it isn't get decompiled correctly, some functions have 2 declared parameters but then get called with 3 or more...

I only know some sort of sha256 function is involved, but the why isn't it correct? Maybe we aren't parsing it correctly before giving it to the sha256 function?
Or maybe when it gets copied into the buffer it does something weird with it? I only saw many random bit shifting operations in the parameter of the wrapper vsnprintf function

I might try IDA when I have time instead of ghidra to see if I get a different result.

[shomykohai]

@progzone122 I'm not sure, but we might get lucky with this
https://github.com/moto-penangf/lk-mt6765/blob/main/lk%2Fapp%2Fmt_boot%2Ffastboot.c#L400-L406

It doesn't seem to check the buffer after setting it when issuing a command to fastboot. It uses 64 as max size of the buffer, but I don't see it making all the checks it should! Maybe we can exploit this

[R0rt1z2]

This is really interesting, it looks like the UART is not blocked, just the resistors are not soldered on

Exactly! To confirm this, we should see if there's any output on the resistor points too if, for some reason, we cannot solder them back

But I'm pretty confident this will make UART work, or at least give us voltage on the TPs.

This method works, but unfortunately, it ended up killing my device. It turns out you don’t necessarily need a resistor. We used a tin bridge, which seemed to do the job just fine. After that, it’s simply a matter of using the phone’s TX to read data from it.

UART Output (note that you need to press the Volume Up button while the phone boots to keep UART printing output. Otherwise, nothing will be displayed. This behavior is controlled by the Preloader.

After bricking my unit, I removed all the shields and took some microscope pictures. I’ve shared them in the Telegram group but you can take a look at them here.

I guess I’m out of luck for now. These units are really hard to find in Spain, and honestly, I can’t afford to spend much on this. The dead unit already cost me around €55 on Wallapop. Sorry about this guys, I tried my best.

[shomykohai]

This is really interesting, it looks like the UART is not blocked, just the resistors are not soldered on

Exactly! To confirm this, we should see if there's any output on the resistor points too if, for some reason, we cannot solder them back

But I'm pretty confident this will make UART work, or at least give us voltage on the TPs.

This method works, but unfortunately, it ended up killing my device. It turns out you don’t necessarily need a resistor. We used a tin bridge, which seemed to do the job just fine. After that, it’s simply a matter of using the phone’s TX to read data from it.

UART Output (note that you need to press the Volume Up button while the phone boots to keep UART printing output. Otherwise, nothing will be displayed. This behavior is controlled by the Preloader.

After bricking my unit, I removed all the shields and took some microscope pictures. I’ve shared them in the Telegram group but you can take a look at them here.

I guess I’m out of luck for now. These units are really hard to find in Spain, and honestly, I can’t afford to spend much on this. The dead unit already cost me around €55 on Wallapop. Sorry about this guys, I tried my best.

This is really weird and interesting.
So we now know how to use UART, but for some reason it doesn't boot anymore??

I don't think it's related to the metal shield tho, I mean, isn't it just ground? Unless it made the SoC run too hot and fried it, I don't have any idea of what happened..

Especially considering you get logs 🤔 Could it be that brom is setting UART before preloader? From the picture it doesn't seem the preloader hasn't started yet, just PLL (Which seem to be related to the clock of the device), usually we see "Preloader Start!" to be sure...

I'm sorry it happened, hope we'll manage to do something in the meantime, like crafting some payload, at least we can get logs from expdb..

[shomykohai]

Could it be that while removing the shield, ESD damage happened?

I assume in this case the eMMC is dead tho, but it shouldn't relate to UART, because the latter lines are connected to the SoC, thus it should be the SoC dead, not the eMMC..

Are there any shorts in the SoC or in the eMMC?

[R0rt1z2]

This is really interesting, it looks like the UART is not blocked, just the resistors are not soldered on

Exactly! To confirm this, we should see if there's any output on the resistor points too if, for some reason, we cannot solder them back
But I'm pretty confident this will make UART work, or at least give us voltage on the TPs.

This method works, but unfortunately, it ended up killing my device. It turns out you don’t necessarily need a resistor. We used a tin bridge, which seemed to do the job just fine. After that, it’s simply a matter of using the phone’s TX to read data from it.

UART Output (note that you need to press the Volume Up button while the phone boots to keep UART printing output. Otherwise, nothing will be displayed. This behavior is controlled by the Preloader.

After bricking my unit, I removed all the shields and took some microscope pictures. I’ve shared them in the Telegram group but you can take a look at them here.
I guess I’m out of luck for now. These units are really hard to find in Spain, and honestly, I can’t afford to spend much on this. The dead unit already cost me around €55 on Wallapop. Sorry about this guys, I tried my best.

This is really weird and interesting. So we now know how to use UART, but for some reason it doesn't boot anymore??

I don't think it's related to the metal shield tho, I mean, isn't it just ground? Unless it made the SoC run too hot and fried it, I don't have any idea of what happened..

Especially considering you get logs 🤔 Could it be that brom is setting UART before preloader? From the picture it doesn't seem the preloader hasn't started yet, just PLL (Which seem to be related to the clock of the device), usually we see "Preloader Start!" to be sure...

I'm sorry it happened, hope we'll manage to do something in the meantime, like crafting some payload, at least we can get logs from expdb..

I should have clarified my message. After removing the shield and soldering a bridge to replicate the resistor's behavior, the phone started printing logs to UART but never fully booted. The UART logs (which I sadly didn't save) indicated a failure during a "complex memory R/W test," suggesting I might have physically damaged something while removing the metal shield.

I then attempted to clean the entire motherboard to see if that might help, but after that, even UART was completely unresponsive, despite all voltage readings being normal. What you see in the picture is the Preloader (from my experience, PL1 refers to Preloader while PL0 refers to bootrom) operating at a 921600 baud rate. A few seconds before that, bootrom prints its startup logs (parsable via a script) at 115200 baud rate.

Before the device was entirely bricked, I also tested UART logs while shorting CLK / CMD / DAT0, and I observed the System Halt! message. This message is commonly seen on Amazon devices where bootrom mode is disabled through fuses, so it’s reasonable to assume Motorola has similarly disabled bootrom mode in this case.

[shomykohai]

I should have clarified my message. After removing the shield and soldering a bridge to replicate the resistor's behavior, the phone started printing logs to UART but never fully booted. The UART logs (which I sadly didn't save) indicated a failure during a "complex memory R/W test," suggesting I might have physically damaged something while removing the metal shield.

I don't know if this could help, but here's a source code of this test (not sure if it's the same but I assume so)

I assume you removed the shield with a Heatgun, and if so, could it be that while applying heat the little solder balls under the eMMC shorted together, and became a problem only when booting the phone later? Like that the phone booted, but then failed the test with said short and because it stayed there, it completely broke the eMMC?

I then attempted to clean the entire motherboard to see if that might help, but after that, even UART was completely unresponsive, despite all voltage readings being normal. What you see in the picture is the Preloader (from my experience, PL1 refers to Preloader while PL0 refers to bootrom) operating at a 921600 baud rate. A few seconds before that, bootrom prints its startup logs (parsable via a script) at 115200 baud rate.

Before the device was entirely bricked, I also tested UART logs while shorting CLK / CMD / DAT0, and I observed the System Halt! message. This message is commonly seen on Amazon devices where bootrom mode is disabled through fuses, so it’s reasonable to assume Motorola has similarly disabled bootrom mode in this case.

Yeah, I've read about System Halt on a Redmi device with the same SoC as moto g23, and this confirms us even more that BROM is 100% disabled by fuse.

Would be good if you could find another unit for a cheap price, but it would be fair if you wouldn't want invest other money on this device if the risk of bricking it again is this high, it makes a lot of sense.

Either way, thanks for trying hardware stuff!
If you ever find another device to test, it will surely be good. In the meantime we can try exploiting lk

[shomykohai]

It doesn't seem it's easy as filling the file with a bunch of A to overflow the buffer

[256] [LK_BOOT] Load 'proinfo' partition to 0x4c5c0b80 (1024 bytes in 0 ms)
[256] begin read proinfo
[256] [PROFILE] mmc read 2 blks in 0 ms: 8KB/s
[256] [LK_BOOT] Load 'proinfo' partition to 0x4c5c0b80 (1024 bytes in 0 ms)
[256] get channel model name from proinfo: "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
[256] get odm_carrier proinfo: "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
[256] get target product proinfo: "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
[256] channel:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,carrier:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,product:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[257] [secure_lk_method] won't support payjoy
[257] [get_AB_OTA_param:1769] p_AB_suffix: _a, AB_retry_count: 1
[257] [SEC_POLICY] reached the end, use default policy

I'm not an expert in this field though, so I might be doing something wrong.

I've also noticed that the phone doesnt boot now to system, it send me to recovery automatically.

[shomykohai]

The IMEI in fastboot also doesn't show up anymore when doing getvar all, it shows 1414141414141 (A in hex is 41), but it shouldn't be reading it from proinfo... Could it be that proinfo has something which tells fastboot where to get the IMEI?? Or maybe it stores an IMEi string in decimal and not hex?

[shomykohai]

I think this is the memcpy function that we use, or similar at least. Some checks are performed in our memcpy function, so I don't know if we could exploit it that easily..
https://github.com/svoboda18/lk/blob/37ec8bcbc4361c0e267617f517d154656804c17a/lib/libc/string/memcpy.c#L38

[shomykohai]

@progzone122 can we use the fastboot oem ultraflash command?

I saw there's a fastboot oem ultraflash_en which should enable the possibility to use ultraflash.

Maybe we can flash protected partition with it? It seem to be a manufacturer/rescue thing, this is how g24 restores its firmware through fastboot

[progzone122]

@progzone122 can we use the fastboot oem ultraflash command?

I saw there's a fastboot oem ultraflash_en which should enable the possibility to use ultraflash.

Maybe we can flash protected partition with it? It seem to be a manufacturer/rescue thing, this is how g24 restores its firmware through fastboot

Without unlocking the bootloader, we can't

[shomykohai]

Damn, I hoped for it.

Do we have any other idea to unlock this phone? Until we can try UART again

[shomykohai]

I tried to decompile the memcpy function in our LK and for what I was able to decompile, it checks for overlapping memory, but not for the size of the incoming and destination pointer. We might be able to exploit this somehow

[shomykohai]

I think the reason here I wasn't able to overflow the serial number buffer is because they later set the 30st character to a string terminator.

But I think I was still able to break something, because as I said in the other post, the phone doesn't boot and instead automatically sends me to recovery, as if it like it fails doing something.

We might really be able to exploit lk using proinfo @R0rt1z2 @progzone122.

I'd ask if @R0rt1z2 could help us in the finding of this and we can check with our devices, because you don't have the device anymore, but you were able to jailbreak an amazon device so you know how to do this stuff, while me and @progzone122 could test the payload.

This is really our last hope, but it might work

[shomykohai]

I think we might be able to exploit other partitions too, like elable, persist protect1 and protect2

[shomykohai]

@progzone122 could you please try the new python script I've added? I can't try on my device right now, but I'm closer to finding how our device generates oem keys.

[cxzstuff]

I know. Just examples... I asked ChatGPT

https://html-preview.github.io/?url=https://github.com/cxzstuff/stuff/blob/main/Moto-G23-G13-oem-key2.html

Can we put this on the documentation until @progzone122 makes the needed component? Would be useful to have it as a webpage

Of course. You might want to edit the texts even it's temp one. So fork it...

[cxzstuff]

Would be useful to have it as a webpage

Changed the texts and added some info. I don't know if the procedure changes the key to another as on G24 it doesn't do a thing...
The commands indicate that it is the case... but IDK.

[shomykohai]

Would be useful to have it as a webpage

Changed the texts and added some info. I don't know if the procedure changes the key to another as on G24 it doesn't do a thing...
The commands indicate that it is the case... but IDK.

The get_socid should work, because the get_key does two things theoretically: it dumps the first part of the soc_id, and also fills the buffer in fastboot.
I'd specify to only use get_key in the text section, without the get_socid command.

Also, g24 doesn't even need the key (they were too lazy to use another algorithm probably), the command is just blocked because of secure boot

[shomykohai]

@cxzstuff, added to the documentation!

[cxzstuff]

I'd specify to only use get_key in the text section, without the get_socid command.

get_socid removed.

[shomykohai]

@progzone122 @GitFASTBOOT

We need to get our device on xda

https://xdaforums.com/t/new-device-forum-requests.1660354/post-89933856

[cxzstuff]

overboard with moderation

4PDA isn't any better. All forbid linking to competitive sites. F them all... this git too... cannot say a spade a spade here. "Idiot" is ok though...

[progzone122]

overboard with moderation

4PDA isn't any better. All forbid linking to competitive sites. F them all... this git too... cannot say a spade a spade here. "Idiot" is ok though...

I don't know, didn't have a problem when I sent the xda link there

[cxzstuff]

I don't know, didn't have a problem when I sent the xda link there

Xda isn't a problem for 4PDA. One can see its contents without registering, unlike telegram. Which is stupid rule because you cannot see everything on 4DPA without registering. For xda 4PDA is evil. Didn't know that so is Needrom. Both useful occasionally.

[shomykohai]

@progzone122 can you ping the forum admin on xda like they did a few post before my latest one, so we might get a chance for it to get added. The forum they added has only one thread, I'm sure we have more than that regarding g13/g23.

https://xdaforums.com/t/new-device-forum-requests.1660354/page-1343

Also, maybe making another guide would help, but on what topic?

[shomykohai]

@progzone122 I will be making a guide on flashing GSI to increase the number of threads on g13/g23.

Can you tell the other on telegram if they can help with this? By commenting on the thread requesting to add the phone (and maybe ping the admin)

[NCLnclNCL]

.