A close relative of the elf is the programmer
P.S.
While reviewing the draft article, I received several questions.
1. Question: Snapdragon 8+ Gen1 processors use version 7 programmers. Will they be supported in FhF?
Answer: I can't answer with certainty. I try to understand the algorithms of the new version as much as possible, but the matter is complicated by the fact that in addition to changing the algorithms of the programmer of the new version, vendors have also started to use the new version of the Sahara protocol (v.3). The old approach – receiving processor data using Sahara commands and comparing them with the programmer's parsing – cannot be applied to new processors. The new processor rejects some necessary Sahara protocol commands as unknown.
2. Question: For the programmer from the given example, the calculated data of the hashes by the Temblast project (https://www.temblast.com/qcomview.htm) do not match the data written to the hash table for entries 6 and 10. Does this mean that the programmer's code was changed after the table was signed with the certificate chain?
Answer: Most likely, no. It is impossible to completely exclude such a possibility, but for this example, the modified hash verification algorithm will be correct. The official documentation mentions that in addition to a single signature (described above), a double signature may be present. And this is exactly the case. When parsing the file with the binwalk command, it was clear that the file has two ELF headers and two certificate chains. The address of the beginning of the second header shows that it matches the address of the beginning of the last (16th) record. Thus, we have a kind of “virtual matryoshka”. One elf inside the sector of another elf. The second elf is parsed using similar algorithms, but I do not have a ready-made solution yet. Therefore, I will simply provide a translation of part of the official documentation.[2] By the way, it is in the second part of the user data that the processor identifier is located, for which this programmer is intended, that is, JTAG_ID 0x00000000 must be changed to 0x00E060E1.
“Hardware manufacturers and QTI may double-sign an image. QTI-signed images have a different metadata table with SW_ID and hash. Some fields are masked when checking the authenticity of the segment hash during QTI verification. If the hash in the hash table does not match the segment hash, check if the image is signed and verify using legacy methods.
The authentication steps for a dual-signed image are as follows:
1. Authenticate metadata table 1 using the OEM key.
2. Authenticate metadata table 2 using the QTI key.
3. Check that the hash of a specific hash segment matches that of metadata table 1 and 2.
4. Check that the hash of a specific ELF segment matches the hash in the hash segment.”
[1] 80-NL239-45 Secure Boot Enablement User Guide. November 11, 2019
[2] 80-PG596-42 Secure Boot Enablement User Guide. July 29, 2019.
