bkerler
Xiaomi Redmi Note 13 Pro/POCO X6 5G - possible EDL loaders
I've extracted the EDL loader for this phone from the official rom image files (Xiaomi hides it in a file called xbl_s_devprg_ns.melf). I used the fhloaderparse.
It's locked by EDL Auth (which is expected), however I then pulled a loader from a different brand with the same chipset (think it was Realme, although the signatures in the loader file would lead me to believe its OnePlus), which fhloaderparse gives the same IDs as the Xiaomi version, but it's not EDL locked.
Chipset is: Snapdragon 7s Gen 2 (SM7435-AB)
The non-EDLAuth one won't load on my Xiaomi phone. Think it might be "VIP" or the EDL loaders are vendor specific, but would like to confirm?
0000000000020000_467f3020c4cc788d_fhprg.bin.dmp
0000000000020000_467f3020c4cc788d_fhprg_edlauth.bin.dmp
hey, can you pull the loader from Realme for OnePlus Ace5 sm8650? Thx
0000000000030000_467f3020c4cc788d_fhprg.bin.dmp
Got this from Realme GT5 Pro RMX3888 Firmware which has the same chipset (SM8650). Naming convention comes out the same as my phone, suggesting a similar issue.
OEM:0003 MODEL:0000 HWID:0000000000030000 SWID:0000000000000003 SWSIZE: PK_HASH:467f3020c4cc788d2a27a6e097ffa7bfc24e82c2d56953d3b45b494cdba5c2422a947d2c81b5752b8a2ac9eac8acdf34 in/prog_firehose_ddr.elf 1549988 OEMVER:ip-10-195-203-22 QCVER:BOOT.MXF.2.1-01661-LANAI-1 VAR:SocLanaiLAA
Can't use it, ace5 is Sahara v3, please share the realme GT6 CN RMX3800 Edl loader, Thanks
Not surprised. They'll almost certainly be no difference for the Realme GT6 CN RMX3800 loader as it's the same chipset. Please find this yourself - to get the OnePlus Ace5 file all I did was search on Google, download the firmware package, and extract the prog_firehose_ddr.elf from the images directory...
Please can someone give me some advice on my original question?
Hey, @dsclee1 I am also looking for the loader for this phone (RedMi Note 13 Pro 5G/ Poco X6 5G).
If is helps you out I ran those files (the two dumps and 'xbl_s_devprg_ns.melf') through the qcomview.exe (found here: https://xdaforums.com/t/identifying-edl-firehose-loaders.4525079/) and got the following results which might explain why it didnt run.
C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m 0000000000020000_467f3020c4cc788d_fhprg.bin.dmp
QCM_CLARENCE
QCS_CLARENCE
SM7475
SM_CLARENCE
SM_FILLMORE
SM_KAILUA
SM_NETRANI
SM_PALIMA
SM_PUNA
SM_TOFINO
SM_WAIPIO
SM_WALES
SMP_CLARENCE
SMP_FILLMORE
SMP_NETRANI
SMP_PALIMA
SMP_WAIPIO
SXR_AURORA
C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m 0000000000020000_467f3020c4cc788d_fhprg_edlauth.bin.dmp
QCM_CLARENCE
QCS_CLARENCE
SM_CLARENCE
SM_FILLMORE
SM_KAILUA
SM_NETRANI
SM_PALIMA
SM_PUNA
SM_TOFINO
SM_WAIPIO
SM_WALES
SMP_CLARENCE
SMP_FILLMORE
SMP_NETRANI
SMP_PALIMA
SMP_WAIPIO
SXR_AURORA
C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m xbl_s_devprg_ns.melf
QCM_CLARENCE
QCS_CLARENCE
SM_CLARENCE
SM_FILLMORE
SM_KAILUA
SM_NETRANI
SM_PALIMA
SM_PUNA
SM_TOFINO
SM_WAIPIO
SM_WALES
SMP_CLARENCE
SMP_FILLMORE
SMP_NETRANI
SMP_PALIMA
SMP_WAIPIO
SXR_AURORA
I noticed the two edl auth protected ones dont show the processor model, but the RealMe/OnePlus shows a different processor (SM7475).
I like to know what you think of this and if you have had any progress on this question since asking it?
Hey, @dsclee1 I am also looking for the loader for this phone (RedMi Note 13 Pro 5G/ Poco X6 5G).
If is helps you out I ran those files (the two dumps and 'xbl_s_devprg_ns.melf') through the qcomview.exe (found here: https://xdaforums.com/t/identifying-edl-firehose-loaders.4525079/) and got the following results which might explain why it didnt run.
C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m 0000000000020000_467f3020c4cc788d_fhprg.bin.dmp QCM_CLARENCE QCS_CLARENCE SM7475 SM_CLARENCE SM_FILLMORE SM_KAILUA SM_NETRANI SM_PALIMA SM_PUNA SM_TOFINO SM_WAIPIO SM_WALES SMP_CLARENCE SMP_FILLMORE SMP_NETRANI SMP_PALIMA SMP_WAIPIO SXR_AURORA C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m 0000000000020000_467f3020c4cc788d_fhprg_edlauth.bin.dmp QCM_CLARENCE QCS_CLARENCE SM_CLARENCE SM_FILLMORE SM_KAILUA SM_NETRANI SM_PALIMA SM_PUNA SM_TOFINO SM_WAIPIO SM_WALES SMP_CLARENCE SMP_FILLMORE SMP_NETRANI SMP_PALIMA SMP_WAIPIO SXR_AURORA C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m xbl_s_devprg_ns.melf QCM_CLARENCE QCS_CLARENCE SM_CLARENCE SM_FILLMORE SM_KAILUA SM_NETRANI SM_PALIMA SM_PUNA SM_TOFINO SM_WAIPIO SM_WALES SMP_CLARENCE SMP_FILLMORE SMP_NETRANI SMP_PALIMA SMP_WAIPIO SXR_AURORAI noticed the two edl auth protected ones dont show the processor model, but the RealMe/OnePlus shows a different processor (SM7475).
I like to know what you think of this and if you have had any progress on this question since asking it?
Unfortunately I haven't made anymore progress since I last posted.
Thanks for running them through qcomview. I previously had a go at that, and I think the loaders I've found are correct, and it's qcomview itself having a hard time identifying the correct chipset as the loaders are some kind of newer format.
I went to the extent of decompiling the loader in Ghidra to try and find a bug. Unfortunately it looks like Xiaomi implemented their encryption function too well (it has a couple of minor bugs, but nothing major enough). I did get a dump of their public key. Obviously of no use unless someone can get the private key...
If you or anyone is interested in a little write up of how their token system works I'd be happy to provide it?
Hey, @dsclee1 I am also looking for the loader for this phone (RedMi Note 13 Pro 5G/ Poco X6 5G). If is helps you out I ran those files (the two dumps and 'xbl_s_devprg_ns.melf') through the qcomview.exe (found here: https://xdaforums.com/t/identifying-edl-firehose-loaders.4525079/) and got the following results which might explain why it didnt run.
C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m 0000000000020000_467f3020c4cc788d_fhprg.bin.dmp QCM_CLARENCE QCS_CLARENCE SM7475 SM_CLARENCE SM_FILLMORE SM_KAILUA SM_NETRANI SM_PALIMA SM_PUNA SM_TOFINO SM_WAIPIO SM_WALES SMP_CLARENCE SMP_FILLMORE SMP_NETRANI SMP_PALIMA SMP_WAIPIO SXR_AURORA C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m 0000000000020000_467f3020c4cc788d_fhprg_edlauth.bin.dmp QCM_CLARENCE QCS_CLARENCE SM_CLARENCE SM_FILLMORE SM_KAILUA SM_NETRANI SM_PALIMA SM_PUNA SM_TOFINO SM_WAIPIO SM_WALES SMP_CLARENCE SMP_FILLMORE SMP_NETRANI SMP_PALIMA SMP_WAIPIO SXR_AURORA C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m xbl_s_devprg_ns.melf QCM_CLARENCE QCS_CLARENCE SM_CLARENCE SM_FILLMORE SM_KAILUA SM_NETRANI SM_PALIMA SM_PUNA SM_TOFINO SM_WAIPIO SM_WALES SMP_CLARENCE SMP_FILLMORE SMP_NETRANI SMP_PALIMA SMP_WAIPIO SXR_AURORAI noticed the two edl auth protected ones dont show the processor model, but the RealMe/OnePlus shows a different processor (SM7475). I like to know what you think of this and if you have had any progress on this question since asking it?
Unfortunately I haven't made anymore progress since I last posted.
Thanks for running them through qcomview. I previously had a go at that, and I think the loaders I've found are correct, and it's qcomview itself having a hard time identifying the correct chipset as the loaders are some kind of newer format.
I went to the extent of decompiling the loader in Ghidra to try and find a bug. Unfortunately it looks like Xiaomi implemented their encryption function too well (it has a couple of minor bugs, but nothing major enough). I did get a dump of their public key. Obviously of no use unless someone can get the private key...
If you or anyone is interested in a little write up of how their token system works I'd be happy to provide it?
IIRC one of the primes for the private key for their token system is derived from the IMEI, CPUID and serial number, however i'm not sure how they actually produce it, but i suspect that for this specific model the second prime is not random, but just a single number chosen for each batch of phones, i got this from back when i tried to reverse engineer some auth tools that were supposedly developed by ex-xiaomi engineers
Hey, @dsclee1 I am also looking for the loader for this phone (RedMi Note 13 Pro 5G/ Poco X6 5G). If is helps you out I ran those files (the two dumps and 'xbl_s_devprg_ns.melf') through the qcomview.exe (found here: https://xdaforums.com/t/identifying-edl-firehose-loaders.4525079/) and got the following results which might explain why it didnt run.
C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m 0000000000020000_467f3020c4cc788d_fhprg.bin.dmp QCM_CLARENCE QCS_CLARENCE SM7475 SM_CLARENCE SM_FILLMORE SM_KAILUA SM_NETRANI SM_PALIMA SM_PUNA SM_TOFINO SM_WAIPIO SM_WALES SMP_CLARENCE SMP_FILLMORE SMP_NETRANI SMP_PALIMA SMP_WAIPIO SXR_AURORA C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m 0000000000020000_467f3020c4cc788d_fhprg_edlauth.bin.dmp QCM_CLARENCE QCS_CLARENCE SM_CLARENCE SM_FILLMORE SM_KAILUA SM_NETRANI SM_PALIMA SM_PUNA SM_TOFINO SM_WAIPIO SM_WALES SMP_CLARENCE SMP_FILLMORE SMP_NETRANI SMP_PALIMA SMP_WAIPIO SXR_AURORA C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m xbl_s_devprg_ns.melf QCM_CLARENCE QCS_CLARENCE SM_CLARENCE SM_FILLMORE SM_KAILUA SM_NETRANI SM_PALIMA SM_PUNA SM_TOFINO SM_WAIPIO SM_WALES SMP_CLARENCE SMP_FILLMORE SMP_NETRANI SMP_PALIMA SMP_WAIPIO SXR_AURORAI noticed the two edl auth protected ones dont show the processor model, but the RealMe/OnePlus shows a different processor (SM7475). I like to know what you think of this and if you have had any progress on this question since asking it?
Unfortunately I haven't made anymore progress since I last posted. Thanks for running them through qcomview. I previously had a go at that, and I think the loaders I've found are correct, and it's qcomview itself having a hard time identifying the correct chipset as the loaders are some kind of newer format. I went to the extent of decompiling the loader in Ghidra to try and find a bug. Unfortunately it looks like Xiaomi implemented their encryption function too well (it has a couple of minor bugs, but nothing major enough). I did get a dump of their public key. Obviously of no use unless someone can get the private key... xiaomi_edl_public_key.txt If you or anyone is interested in a little write up of how their token system works I'd be happy to provide it?
IIRC one of the primes for the private key for their token system is derived from the IMEI, CPUID and serial number, however i'm not sure how they actually produce it, but i suspect that for this specific model the second prime is not random, but just a single number chosen for each batch of phones, i got this from back when i tried to reverse engineer some auth tools that were supposedly developed by ex-xiaomi engineers
Interesting, that they might batch the private keys by models. Would be fairly easy to find out if someone logged all the public keys from the various model firmwares. From a couple I've seen different models were definitely using the same key.
When a request for a token is made to their server the structure looks like this: 55 01 01 - header? 22 - size (34 bytes) 02 - command (serial number) 08 - size (8 bytes) 00 00 04 3F AA 21 98 01 - (serial number (0x0000043faa219801)) 04 - command (chip id) 04 - size (4 bytes) 00 00 02 12 - (chip id 0x212 - hardcoded) 01 - command (randomness) 10 - size (16 bytes) E8 12 6B 73 8F 52 61 ED BD 32 05 E6 A0 41 FE D4 - random bytes
Which could mean the EDL commands don't contain model info (altough chip id could be unique per model? And they could derive model from serial number if they had a lookup table).
are those bytes at the end actually random? AFAIK they are derived from the key inside the device, maybe they are the model number encrypted with the key inside the device?
Also this doesn't apply to newer models, the old ones used batch keys, the newer models don't
On Mon, Dec 22, 2025 at 5:19 AM David @.***> wrote:
dsclee1 left a comment (bkerler/edl#692) https://github.com/bkerler/edl/issues/692#issuecomment-3680979903
Hey, @dsclee1 https://github.com/dsclee1 I am also looking for the loader for this phone (RedMi Note 13 Pro 5G/ Poco X6 5G). If is helps you out I ran those files (the two dumps and 'xbl_s_devprg_ns.melf') through the qcomview.exe (found here: https://xdaforums.com/t/identifying-edl-firehose-loaders.4525079/) and got the following results which might explain why it didnt run.
C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m 0000000000020000_467f3020c4cc788d_fhprg.bin.dmp QCM_CLARENCE QCS_CLARENCE SM7475 SM_CLARENCE SM_FILLMORE SM_KAILUA SM_NETRANI SM_PALIMA SM_PUNA SM_TOFINO SM_WAIPIO SM_WALES SMP_CLARENCE SMP_FILLMORE SMP_NETRANI SMP_PALIMA SMP_WAIPIO SXR_AURORA
C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m 0000000000020000_467f3020c4cc788d_fhprg_edlauth.bin.dmp QCM_CLARENCE QCS_CLARENCE SM_CLARENCE SM_FILLMORE SM_KAILUA SM_NETRANI SM_PALIMA SM_PUNA SM_TOFINO SM_WAIPIO SM_WALES SMP_CLARENCE SMP_FILLMORE SMP_NETRANI SMP_PALIMA SMP_WAIPIO SXR_AURORA
C:\Users\cam\Downloads\Xiaomi>qcomview.exe /m xbl_s_devprg_ns.melf QCM_CLARENCE QCS_CLARENCE SM_CLARENCE SM_FILLMORE SM_KAILUA SM_NETRANI SM_PALIMA SM_PUNA SM_TOFINO SM_WAIPIO SM_WALES SMP_CLARENCE SMP_FILLMORE SMP_NETRANI SMP_PALIMA SMP_WAIPIO SXR_AURORA
I noticed the two edl auth protected ones dont show the processor model, but the RealMe/OnePlus shows a different processor (SM7475). I like to know what you think of this and if you have had any progress on this question since asking it?
Unfortunately I haven't made anymore progress since I last posted. Thanks for running them through qcomview. I previously had a go at that, and I think the loaders I've found are correct, and it's qcomview itself having a hard time identifying the correct chipset as the loaders are some kind of newer format. I went to the extent of decompiling the loader in Ghidra to try and find a bug. Unfortunately it looks like Xiaomi implemented their encryption function too well (it has a couple of minor bugs, but nothing major enough). I did get a dump of their public key. Obviously of no use unless someone can get the private key... xiaomi_edl_public_key.txt https://github.com/user-attachments/files/22393934/xiaomi_edl_public_key.txt If you or anyone is interested in a little write up of how their token system works I'd be happy to provide it?
IIRC one of the primes for the private key for their token system is derived from the IMEI, CPUID and serial number, however i'm not sure how they actually produce it, but i suspect that for this specific model the second prime is not random, but just a single number chosen for each batch of phones, i got this from back when i tried to reverse engineer some auth tools that were supposedly developed by ex-xiaomi engineers
Interesting, that they might batch the private keys by models. Would be fairly easy to find out if someone logged all the public keys from the various model firmwares. From a couple I've seen different models were definitely using the same key.
When a request for a token is made to their server the structure looks like this: 55 01 01 - header? 22 - size (34 bytes) 02 - command (serial number) 08 - size (8 bytes) 00 00 04 3F AA 21 98 01 - (serial number (0x0000043faa219801)) 04 - command (chip id) 04 - size (4 bytes) 00 00 02 12 - (chip id 0x212 - hardcoded) 01 - command (randomness) 10 - size (16 bytes) E8 12 6B 73 8F 52 61 ED BD 32 05 E6 A0 41 FE D4 - random bytes
Which could mean the EDL commands don't contain model info (altough chip id could be unique per model? And they could derive model from serial number if they had a lookup table).
— Reply to this email directly, view it on GitHub https://github.com/bkerler/edl/issues/692#issuecomment-3680979903, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEU2JTUDMPGLWHRNUCDSSGT4C6SQTAVCNFSM6AAAAACCAJBSGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMOBQHE3TSOJQGM . You are receiving this because you commented.Message ID: @.***>
They're actually random. The MIToken module requests the random bytes from the Qualcomm Random Number generator.
interesting... do you know if the number is just sent raw or if it is encrypted before being sent? it could be simply that it generates a random number -> encrypts it-> sends it to xiaomi servers, xiaomi servers generate the key from the other info thats sent -> token is actually the decrypted value
does the size of the token match the size of the random number? (i don't remember if the token was a 2048 bit key or if it was a short string, if its a key its likely generated by a combination of the random number and the other information being sent, if so it should be possible to reverse engineer how the token is formed)
could it be possible to bruteforce the token? (if its a short string the same size as the random number)
On Mon, Dec 22, 2025, 2:05 PM David @.***> wrote:
dsclee1 left a comment (bkerler/edl#692) https://github.com/bkerler/edl/issues/692#issuecomment-3682946832
They're actually random. The MIToken module requests the random bytes from the Qualcomm Random Number generator.
— Reply to this email directly, view it on GitHub https://github.com/bkerler/edl/issues/692#issuecomment-3682946832, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEU2JTWOR7SUVMSQ6QL7UNT4DAQFRAVCNFSM6AAAAACCAJBSGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMOBSHE2DMOBTGI . You are receiving this because you commented.Message ID: @.***>
Here's a full example of how the Xiaomi token signing system works:
Your phone generates a token request using serial no, chip id, and 16 random bytes, in the format as in my previous post. e.g. 55 01 01 22 02 08 00 00 04 3F AA 21 98 01 04 04 00 00 02 12 01 10 E8 12 6B 73 8F 52 61 ED BD 32 05 E6 A0 41 FE D4
This is base64 encoded before being sent to the Xiaomi server. e.g. VQEBIgIIAAAEP6ohmAEEBAAAAhIBEOgSa3OPUmHtvTIF5qBB/tQ=
The Xiaomi server receives that data, base64 decodes it, and runs it through the private key encryption.
Xiaomi returns back a file with the now encrypted data, and calls it an "unlock token". It's 256 bytes - impossible to brute-force.
This unlock token is read by your phone, and decrypted using the stored public key.
The decrypted value must match the original bytes that were sent.
It's a pretty standard encryption model (if a little backwards conceptually), and pretty safe.
Short of getting the private key itself a reasonable attack would be to change the bytes at the phone end. In fact previously Xiaomi screwed up on older phone models so the bytes weren't set until requested, meaning they were initially all zeroes, meaning all someone had to do was get the unlock token once (for a byte string of all zeroes) and it would work for all those phone models. Unfortunately Xiaomi implemented a very simple fix for this - they made sure the bytes total sum is greater than zero...
Only other way to edit the data now would involve flashing the partition, which you can't do without the signing keys (which no one is ever getting hold of, and if you had them you probably wouldn't need EDL anyway).