Replies: 7 comments 17 replies
-
|
Signature here is RSA2048 encrypted, pub key is in the firehose loader. Signature currently used in this repo decrypts to: This works because token is 0(at least in my firehose), before requesting it(TargetName="req") and there is no check. |
Beta Was this translation helpful? Give feedback.
-
|
It seems that it works the same way in my Poco X3 NFC as well, given that I attempted going through the entire auth process (requesting the token/blob and then sending this signature and yet it would fail. |
Beta Was this translation helpful? Give feedback.
-
|
Is it time to make lookup charts for devices with broken PBL code? |
Beta Was this translation helpful? Give feedback.
-
|
The 3 signatures that I mentioned earlier were released with a chinese tool that took advantage of the BFF (Batch Framework for Flashing), though it had a modified version of this framework in order to be able to use EDL and authentication, either by those signatures or an user-provided signature. |
Beta Was this translation helpful? Give feedback.
-
|
I've been testing a few ideas for sending the custom signature over to the phone and there's a "Xiaomi" module that contains a function for attempting EDL authentication with a signature that's hardcoded into the tool, I made it so that I could enter the path to my own signature instead of hard coding it in. This is the code responsible for checking the device's response after sending the signature if I'm not mistaken. That doesn't mean authentication is unsuccessful though, because it does go through and then I was able to send other commands. |
Beta Was this translation helpful? Give feedback.
-
|
This is a screenshot of the output of the command This is how it looks like to use the same command without I don't think it's normal for it to not output anything like this and keep in mind that I executed the "edl" that was installed in my system, not the local one in the current directory, otherwise it would've been something like |
Beta Was this translation helpful? Give feedback.
-
With the help of commit 9c9c489: Fix xiaomi edl auth check I was able to get authentication to work properly with custom signatures and the one that was hard coded into the tool
|
Beta Was this translation helpful? Give feedback.
-
|
Tested on a redmi note 10 pro. Bought in June of 2021. |
Beta Was this translation helpful? Give feedback.
-
|
Sweet prog_ufs_firehose_sm7150_ddr.elf has this check: |
Beta Was this translation helpful? Give feedback.
-
|
Do you know if sweet's firehose from the engineering ROM also has that check? |
Beta Was this translation helpful? Give feedback.
-
|
eng loader has same check, device should replay with "Blob should init first" |
Beta Was this translation helpful? Give feedback.
-
|
Just as I was about to say that "it failed!".. anyway: Here's the engineering loader itself. A bit smaller. Change extension so that it's an elf. So we know that the poco X3 that started with android 10 has the bug but the rn10p on a11 doesn't. Good baseline but more confirmation needed for "phones older are flawed, phones newer aren't". |
Beta Was this translation helpful? Give feedback.
-
|
PR #569 |
Beta Was this translation helpful? Give feedback.
-
|
I'd hotspot the host PC to another PC that has wireshark running and then sniff the wifi. As for serial... Not exactly sure. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Does it have some sort of anti VM? if not then it should be workable. |
Beta Was this translation helpful? Give feedback.
-
USB over network can also be used to capture USB. |
Beta Was this translation helpful? Give feedback.
-
|
What exactly do you suggest? The site tells you to remove flexihub, which is a USB mirroring tool. |
Beta Was this translation helpful? Give feedback.
-
|
Well, seeing what has happened so far, I think we can count out the Mi 9, the Mi 9T, the Redmi Note 10 Pro and the Mi 11 Lite 4G. The Redmi Note 9S/9 Pro on the other hand is very likely to be vulnerable and the reason why I believe so is because that device and the Poco X3 NFC seem to share the same firmware to some extent, seeing how ABL/LinuxLoader has references for their codenames and such. To me, it's kinda weird that LinuxLoader has such references on devices that are different in a lot of ways, but that's just ABL, not XBL. |
Beta Was this translation helpful? Give feedback.
-
|
Pls bro how to sand auth.sig |
Beta Was this translation helpful? Give feedback.
-
|
Am tasted note 10 pro and note work |
Beta Was this translation helpful? Give feedback.
-
|
We already know that. The task is to figure out if there's anything that can be done to simulate things properly. The X3 fell short, after all. |
Beta Was this translation helpful? Give feedback.
-
I looked into how the process of sending the EDL authentication signature to a Xiaomi device works, and it works like this:
<?xml version="1.0" ?><data><sig TargetName="sig" verbose="1" size_in_bytes="256" /></data>The way this could work is that the user gets a hex editor and writes the signature's hex data to a file, not in plain text no, but to the file, for example:
The signature above is a leaked signature that seems to work in all Xiaomi SM8150 devices, this may also include all Xiaomi SM7150 devices (I tested it on my Poco X3 NFC and it worked) but more testing is required, as there are 3 signatures and it isn't known which of them work for specific SoCs, what is known is that one of those 3 keys work on the following SoCs:
One key may work on, say for example, SD 855, SD 845 and 636, while it may not work in the others and require a different key out of the 3.
So the way this new feature could work is that the tool is launched with the following command arguments
edl auth --signature=<path/to/signature>The tool does it's usual stuff, then it sends the command for authentication, aka the XML file with "sig", waits for the device to send ACK and if the device sends ACK, then continue, but if it says NAK, error out and check if it had a "log value", if it continues, it writes the signature file directly to the device's COM port, after that, it listens in to check for response's value, if it's ACK, it means that EDL is authenticated, but it's NAK, then it means that authentication failed and that this could be due to a "signature verification error", maybe there are more errors, however, these are yet to be documented.
The reason why I think it should focus on the response value is because I don't think it would be a great idea to hardcode the string that the device sends when EDL is authenticated or when it fails, the log value's string could be different.
This is how my Poco X3 NFC responds to the signature that I took a screenshot of.
Beta Was this translation helpful? Give feedback.
All reactions