Replies: 11 comments 19 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.
-
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.
-
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.
-
PR #569
|
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.
-
Am tasted note 10 pro and note work |
Beta Was this translation helpful? Give feedback.
-
Iam ready to test this on redmi note 9s, I just need a Lil bit of guide on how to |
Beta Was this translation helpful? Give feedback.
-
Where is the 3rd signature? I only see 2. |
Beta Was this translation helpful? Give feedback.
-
@David112x would you please share the signature files if possible , i will test with my poco x3 pro |
Beta Was this translation helpful? Give feedback.
-
@David112x How could I send the signature binary file through fh_loader.exe? Could you give an example of the commandline? Can I just use Thanks! |
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