search

msm8916-mainline / qtestsign

Simple tool to "sign" ELF Qualcomm firmware images using dummy certificates ("test keys")
GNU General Public License v2.0
41 stars 8 forks source link

test signing sdm636 soc hyp.mbn, something weird #2

Closed 99degree closed 2 years ago

99degree commented 2 years ago

Hi,

I know this qtestsign is not made for other/newer SOCs. I still wanna try this out with a minor branded sdm636 phone and found something strange. please take a look if you are willing to support other SOCs.

the weird happened in Program Headers, looks like the load address altered. and the supposed hash/cert section is absent/stripped in the output mbn file. the source mbn and the output mbn file is zipped.

e3_hyp.zip

~/source/qtestsign# readelf -a e3_hyp-test-signed.mbn ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: AArch64 Version: 0x1 Entry point address: 0x85810000 Start of program headers: 64 (bytes into file) Start of section headers: 0 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 4 Size of section headers: 64 (bytes) Number of section headers: 0 Section header string table index: 0 There are no sections in this file. There are no sections to group in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align NULL 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000120 0x0000000000000000 0x0 NULL 0x0000000000001000 0x0000000085a18000 0x0000000085a18000 0x00000000000009a8 0x0000000000001000 0x1000 LOAD 0x0000000000002000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x1000 LOAD 0x0000000000002000 0x0000000085810000 0x0000000085810000 0x000000000003f000 0x0000000000208000 RWE 0x1000 There is no dynamic section in this file. There are no relocations in this file. The decoding of unwind sections for machine type AArch64 is not currently supported. Dynamic symbol information is not available for displaying symbols. No version information found in this file.

and the original:

~/source/qtestsign# readelf -a e3_hyp.mbn ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: AArch64 Version: 0x1 Entry point address: 0x85810000 Start of program headers: 64 (bytes into file) Start of section headers: 0 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 4 Size of section headers: 64 (bytes) Number of section headers: 0 Section header string table index: 0 There are no sections in this file. There are no sections to group in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align NULL 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000120 0x0000000000000000 0x0 NULL 0x0000000000001000 0x0000000085a18000 0x0000000085a18000 0x00000000000019a8 0x0000000000002000 0x1000 LOAD 0x0000000000002000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x1000 LOAD 0x0000000000003000 0x0000000085810000 0x0000000085810000 0x000000000003f000 0x0000000000208000 RWE 0x1000 There is no dynamic section

99degree commented 2 years ago

Before: Elf(ehdr=Ehdr(ei_magic=b'\x7fELF', ei_class=2, ei_data=1, ei_version=1, ei_os_abi=0, ei_abi_version=0, e_type=2, e_machine=183, e_version=1, e_entry=2239823872, e_phoff=64, e_shoff=0, e_flags=0, e_ehsize=64, e_phentsize=56, e_phnum=4, e_shentsize=64, e_shnum=0, e_shstrndx=0), phdrs=[Phdr(p_type=0, p_offset=0, p_vaddr=0, p_paddr=0, p_filesz=288, p_memsz=0, p_flags=117440512, p_align=0), Phdr(p_type=0, p_offset=4096, p_vaddr=2241953792, p_paddr=2241953792, p_filesz=6568, p_memsz=8192, p_flags=35651584, p_align=4096), Phdr(p_type=1, p_offset=8192, p_vaddr=0, p_paddr=0, p_filesz=0, p_memsz=0, p_flags=0, p_align=4096), Phdr(p_type=1, p_offset=12288, p_vaddr=2239823872, p_paddr=2239823872, p_filesz=258048, p_memsz=2129920, p_flags=7, p_align=4096)]) Header(version=0, type=3, flash_addr=0, dest_addr=2241953832, total_size=2432, hash_size=128, signature_addr=2241953960, signature_size=256, cert_chain_addr=2241954216, cert_chain_size=2048) After: Elf(ehdr=Ehdr(ei_magic=b'\x7fELF', ei_class=2, ei_data=1, ei_version=1, ei_os_abi=0, ei_abi_version=0, e_type=2, e_machine=183, e_version=1, e_entry=2239823872, e_phoff=64, e_shoff=0, e_flags=0, e_ehsize=64, e_phentsize=56, e_phnum=4, e_shentsize=64, e_shnum=0, e_shstrndx=0), phdrs=[Phdr(p_type=0, p_offset=0, p_vaddr=0, p_paddr=0, p_filesz=288, p_memsz=0, p_flags=117440512, p_align=0), Phdr(p_type=0, p_offset=4096, p_vaddr=2241953792, p_paddr=2241953792, p_filesz=2472, p_memsz=4096, p_flags=35651584, p_align=4096), Phdr(p_type=1, p_offset=8192, p_vaddr=0, p_paddr=0, p_filesz=0, p_memsz=0, p_flags=0, p_align=4096), Phdr(p_type=1, p_offset=8192, p_vaddr=2239823872, p_paddr=2239823872, p_filesz=258048, p_memsz=2129920, p_flags=7, p_align=4096)])

stephan-gh commented 2 years ago

I know this qtestsign is not made for other/newer SOCs.

qtestsign is not strictly SoC-specific, but it implements the v1.0 image format. The v2.0 image format used by newer SoCs is a bit different I think, and would probably need some adjustments. Not sure what SDM636 is using.

the weird happened in Program Headers, looks like the load address altered.

qtestsign repacks the program segments in the binary, so it can happen that they are arranged a bit differently in the output binary. The logs you show above look correct to me, not the load address was changed but just the load offset. This can happen if the program segments are placed a bit differently in the output file.

and the supposed hash/cert section is absent/stripped in the output mbn file.

The hash/cert is located in the two NULL segments, which is still present according to your logs. What makes you think that it is missing?

Please be careful when "trying out" qtestsign. Make sure your device actually has secure boot disabled. Otherwise it will not boot anymore if you flash the new firmware.

99degree commented 2 years ago

Thx for reply.

Not sure what SDM636 is using.

Confirm this is a stripped SDM660 and similar to MSM8998 which is started to use xbl thus belong to v2.0 img format. Had took a glance on the spec and sounds like below difference, maybe more, not confirmed yet.

(1) 2 more certs (OEM meta, aka general OEM atte; and QTI meta, aka general OEM root ca), then QTI meta contain some new field below. there is not sure if these two are chained cert or not. The printf specifier might incorrect. "02 %016X HW_ID" "04 %016X OEM_ID" "05 %016X SW_SIZE" "06 %016X MODEL_ID" "07 %016X SHA256" "03 %016X DEBUG" "13 %016X IN_USE_SOC_HW_VERSION" (2) hash for sections together with above 2 certs need to hash again(might not need? hash table in color yellow?) with QTI root ca cert(alt, OEM root ca) and chain with OEM cert

The logs you show above look correct to me,

Yes and this make me less puzzled. and might be due to versioning difference the original elf have a Header dump as below and eventually not in the resulting elf dump log.

Header(version=0, type=3, flash_addr=0, dest_addr=2241953832, total_size=2432, hash_size=128, signature_addr=2241953960, signature_size=256, cert_chain_addr=2241954216, cert_chain_size=2048)

The hash/cert is located in the two NULL segments,

Yes by grep qtestsign and strings, confirm certs are present. not sure if it is within NULL segments. if this is the case then perhaps a new segment is needed or being specified, otherwise the "Header(version=0)" aka header log dump might appeared too.

What makes you think that it is missing?

Confirmed certs present as above, sorry for that.

Please be careful when "trying out" qtestsign. Make sure your device actually has secure boot disabled. Otherwise it will not boot anymore if you flash the new firmware.

Thx for reminding. The device is secured boot is enabled as told by "fastboot getvar all". So flashing this is high risk being out of a signed firehorse fw. I might get back with this once after "qhypstub_loader" method verified with the concept first. The driving for this is trial is due to a nice catch of my hyp mbn ver grep as below, which is similar to redmi note 5 whyred thus the api should be quite the same:

QC_IMAGE_VERSION_STRING=TZ.BF.4.0.7-00082 IMAGE_VARIANT_STRING=KAJAANAAA OEM_IMAGE_VERSION_STRING=CRM

In case you have a bit of time on this project, could you please help to grep with those hyp.mbn and see if this VERSION_STRING is a strong indicator for compatible hyp file in various model you have?

My daily phone with sdm720, aka joyeuse have below: QC_IMAGE_VERSION_STRING=TZ.XF.5.0.3-395881 IMAGE_VARIANT_STRING=MAUAANAAA OEM_IMAGE_VERSION_STRING=CRM

stephan-gh commented 2 years ago

In case you have a bit of time on this project, could you please help to grep with those hyp.mbn and see if this VERSION_STRING is a strong indicator for compatible hyp file in various model you have?

The hyp firmware on MSM8916 and similar (which is what qhypstub is meant for) is just a couple of KiB, I don't think it has any of those strings. From what I heard the hyp does a lot more stuff on newer SoCs and might therefore be harder to replace there.

99degree commented 2 years ago

noted with thx