Add RzBin plugin for Qualcomm peripheral images (.mdt).#4953
Add RzBin plugin for Qualcomm peripheral images (.mdt).#4953Rot127 merged 3 commits intorizinorg:devfrom
.mdt).#4953Conversation
You could see how it's done for PE and MDMP currently. |
PE has proper header files to include. So I would expose the elf functions as well like this. |
|
I open this for review now so you folks can give some early comment. Especially on the ELF thingy (see above). But no need to do a full review. It is mostly about the ELF thing and the overall mdt design. |
Rot127
requested review from
kazarmy,
ret2libc,
thestr4ng3r and
wargio
as code owners
Rot127
force-pushed
the
bin-mdt
branch
2 times, most recently
from
117ee01 to
0fe69db
Compare
notxvilka
left a comment
notxvilka
left a comment
There was a problem hiding this comment.
Nice refactoring along the way! Please address my comments and it will be good to go.
Yes, I am afraid this is the case. ELF parser was refactored multiple times during its lifetime, gradually becoming more untangled and modular but there are still many warts left, including the need to extract relocation processing and parsing into a separate file at the very least. I think for now, you can do a copy and add support for 64-bit modules, we will deal with more refactoring later. It's already the case for the ELF after all. |
Rot127
force-pushed
the
bin-mdt
branch
3 times, most recently
from
09b32e4 to
853cb8c
Compare
DO NOT SQUASH |
It exposes commonly used ELF parsing functions in elf_parser. They don't rely on RzBinFile but take only the ELF object. This allows access for other RzBin plugins which rely on ELF files.
It loads .mdt firmware layout files, searches for the other parts in the same directory and loads them. It resolves symbols, sections etc automatically, and maps them according to the layout to the virtual address space. - The iH command provides details about each firmware part as well. - Memory maps and segment names are prefixed with the parts file name to make them distinct. - If a firmware part is an ELF library it loads, and resolves its functions, segments etc. Due to the design of the ELF binary plugin (code duplication with macros for 32/64bit versions), this only supports 32bit firmware images for now. This can relatively easily be fixed, by duplicating this plugin but including the 64bit ELF headers. This requires more tests though.
3 participants
DO NOT SQUASH
Your checklist for this pull request
RZ_APIfunction and struct this PR changes.RZ_API).Detailed description
I am sick of using the wonky Python scripts. And then load the whole pseudo-ELF binary, it doesn't resolve the nested ELF file(s) properly and just generally hurts my wish for order.
Also this allows for future extension, automatic decompression and such.
Besides this, it is just convenient to have.
Example, loading an
modem.mdt. The symbols from the embedded ELF file (modem.b32) can be listed directly. No need to work with brokenob:Example sections of the embedded ELFs:
Example of
oml:Example of
iH:Some questions to discuss:
This needs access to the ELF RzBin functions. Re-implementing all the ELF parsing doesn't make sense. But including everything a third or fourth time via
bin_elf.inc(how it was done so far) is not ok either.So I choose a middle ground here. I exposed versions of commonly used ELF parsing functions in
elf_parser. They don't rely onRzBinFile, but take only the ELF object. This allows access for otherRzBinplugins which rely on ELF files.BUT, the design of the ELF module, only allows to be used either as ELF32 or ELF64. This is due to the ELF module being implemented twice with macros. This means every single module depending on it also is forced to copy itself (once for 32 and once for 64bit). Or am I missing something?
Unfortunately, due to this this bin loader only supports 32bit firmwares for now. Which is a shame, because these peripheral images are also used for AArch64 based sub-components.
Test plan
Added
Closing issues
...