Bad hashes on a few new loaders

[RenateUSB]

Nice work with the ~70 new loaders!

However six appear to have wrong hashes. Where they patched without re-hashing or was it file corruption? In any case, they won't work even if the device has Secure Boot = off.

8DBB87B8/1/prog_firehose_ddr_ufs.elf
9FCADFE3/2/prog_ufs_firehose_Sdm7150_ddr_phoenix_sig_rb2.elf
9FCADFE3/2/prog_ufs_firehose_Sdm730_ddr_tucana_sig_rb2.elf
9FCADFE3/2/prog_ufs_firehose_Sdm845_ddr_perseus_sig_rb2.elf
9FCADFE3/prog_firehose_Sdm665_ddr_laurel_sig_rb0.elf
F5B53BBC/prog_emmc_firehose_8940_ddr_oppo.mbn

The four Xiaomi have 1 or 2 hashes wrong each. The two Oppo have them all wrong except #0. Very strange.

[hoplik]

Hello, "Hawkeye" :) You're right, as always. The algorithm that counts the hash of the root certificate was written by me while studying the binary code of programmers. This is very far from how it should happen according to the primary documents of Qualcomm, since access to them is closed to independent developers. I have to invent something of your own. I could very likely have made a mistake, and if you have an alternative algorithm, then I would be extremely grateful for the opportunity to familiarize yourself with it. By Xiaomi. These programmers contain "sig" in the file name. I didn't want to publish them without checking, but i have nothing to check their work. It is likely that these are programmers with authorization, that is, when they load into the device's memory, they will ask for authorization to work. If you have such devices and these programmers ask for authorization for them, please write, I will remove them from the directory. According to OPPO, I can assume that there is no authorization, but a VIP, that is, a programmer with additional verification. They are generally a problem, because there, a fixed set of commands in a certain sequence is also digitally signed. In general, if I have published something superfluous, I am ready to remove it. These 6 are the first candidates for departure. This is what the hash calculation looks like in my code: https://github.com/hoplik/Firehose-Finder/blob/master/Func.cs lines 213 to 297 First there is the sequence 3082<4>3082 indicating the beginning of the certificate. Then the second (if there are 2) or third (if there are three or more) certificate is taken as the root certificate. Check Its encoding and the hash is calculated according to it. There may be errors both in choosing the third certificate from everything that is present in the programmer, and in choosing SHA for it.

[RenateUSB]

No, I was talking about the hashes of the ELF programs. (Scroll right.)

qcomview.exe /h 9FCADFE3\2\prog_ufs_firehose_Sdm7150_ddr_phoenix_sig_rb2.elf
64 bit ELF, Version 6, SHA384
 0  000000  000430  691d5e0f0bca5270 07c57ddd6dcd7734 e3dc198c26c9bd95 6abc26e718f035fe e3c4fada7ef2ec0d 70ee59e7f16afa3e  Ok
 1  001000  001d08
 2  07bc90  000000
 3  058660  001dcc  b2d14cbc4449e388 62046ff82aac0f1f 4c62f5e11c94e07b 8211aea7a525e24f 62e61e7e91480faa db0baa3f8bdfa71f  Ok
 4  05a430  000000
 5  07bc90  000000
 6  003000  04e46c  173d1921f234b84b a3a4b886e974ddcc 0f1f967ef171ad37 3e63dd519f5aa191 45d708d0791f085c d1e636a68cbdfda9  Error!
 7  058660  000000
 8  05a430  021858  2e3b26daafe4df2b a05fec5baa07d107 4d48fe9c867a939e 9aa42336dbf02587 fc88b4f47aaede99 fe718a997e4905ea  Ok
 9  051470  000000
10  051470  0071f0  7285c2f867a3886e 7941b9e8577ebb38 8a7f7b8ad00f3101 9c0d18d53783be72 aedee8efc0e06b84 f1fe5d54e475bcb4  Error!
11  07bc90  0000ac  820df4d64077328d 99347ff924cb417f c228858a8af4c9ee 9b69d00e53f8b6c3 cf50e59fbf0ab1f4 8ecebc84cfa52bcc  Ok
12  07bd3c  00a890  32650b7f67130693 c843b1c5278481ee db99e158fe876e63 7b9400430be17ffb 9dd6c78bbe220ade 63e114183b62e452  Ok
13  0865cc  003404  b22357c1f29abaf0 4e07b985dc8d70c8 ae4a404771cecf2a 5113925aa50f1178 ce52b3ba101617e4 7f6c5cdad95ee7f5  Ok
14  0899d0  003404  bd6589d4c242106c 4a9d0a2f24a07c4f e21aad67ef8a0533 ffc6839bbbc883d1 496c4bdc55cd1211 905e129179573064  Ok
15  08cdd4  000010  ae40659da1193cde c8df474b5e36416a 82473b83d32dbbe1 dd6df8ec9499d249 02ca08c334876bc8 e69e818beecc046a  Ok
16  08cde4  017000  417f5424745ec880 a0e102939214faf9 b1d2a6bb0cb347b9 96bbe47533b1f633 d7123050281c250a 364d3f0bf66c8237  Ok
17  058660  000000

I do calculate the hash of the root certificate, but that's separate. (And I don't right now verify the signature.)

Your file naming is correct, mmm, maybe except for the F5B53BBC\prog_emmc_firehose_8940_ddr_oppo.mbn That is named after the end of the SHA256 of the root cert. The other five are named after the end of the SHA384 hash of the root cert.

It's hard to tell whether the PK hash is using 256 or 384 except when querying by EDL I've seen some people use the cert itself to guess which of it is. But logically, there's no reason that it couldn't be either burned into efuses no matter how the SHA is used elsewhere.

[hoplik]

It's hard to tell whether the PK hash is using 256 or 384 except when querying by EDL I've seen some people use the cert itself to guess which of it is.

For example, I define SHA using a binary mask. Here, in the code of pages 142-152. https://github.com/hoplik/Firehose-Finder/blob/master/Guide.cs For the rest, I'll look at the details of the file in Linux. It is quite possible that the issue is not in the cache of the root certificate, but in the hash of the file. They could have made changes to the code, which skewed the signature. Anyway, thanks a lot, I'll figure it out.

[hoplik]

What an interesting question it turned out to be. The answer to it grew into an full article. After its publication, I will leave a link here and close the topic.

[hoplik]

https://habr.com/ru/articles/839936/

[RenateUSB]

Thanks for the link. In your example we disagree about Program 6 & 10 hash. The hidden ELF is in Program 16 and that hash we agree on. This is Program 6, skip, then truncate, then sha384:

C:\>modfile z /s 3000
C:\>modfile z /t 4e46c
C:\>sha384 z
173d1921f234b84b a3a4b886e974ddcc 0f1f967ef171ad37 3e63dd519f5aa191 45d708d0791f085c d1e636a68cbdfda9