ELF: Apply the header fields a p-code opinion constrains - #740
Conversation
Ghidra's ELF opinions state their secondary attribute as e_flags: the RISC-V opinion documents "e_flags: used as secondary" and the AVR8 one says "Elf e_flags are used for the secondary attribute". The matcher compared it against e_type, which pyelftools reports as a name such as ET_EXEC, so a decimal secondary never matched, and a hexadecimal or bit-pattern secondary raised ValueError and kept its opinion unconditionally. The opinions also frequently omit endian, and nothing else held the selected language to the byte order the file declares, so a language of the opposite byte order stayed a candidate and could be selected on the order pypcode.Arch.enumerate() happened to return. EM_PARISC therefore did not load at all, since its one ELF opinion is keyed to e_flags 528; a double-float LoongArch object resolved to lp64f rather than lp64d; and a little-endian NDS32 object resolved to NDS32:BE:32:default.
|
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS Validation record for head
Measured over a private corpus of 234056 ELF objects, 91402 of which reach
Every e_machine any ELF opinion names was then enumerated against both byte orders, both ELF classes and every e_flags value any opinion distinguishes, 11832 combinations. The only ones that lose their last candidate are byte orders no language exists for at all (big-endian V850, Hexagon, CR16 and LoongArch) and LoongArch with an ABI modifier outside 1 to 3, which the psABI does not define. No corpus object is either. Blast radius, the same 300 randomly chosen corpus ELFs scored through Caveats: |
|
Corpus decompilation diffs can be found at angr/dec-snapshots@master...angr/cle_740 |
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS
Ghidra's ELF opinions state their secondary attribute as e_flags, but the matcher
compared it against e_type, and a hexadecimal or bit-pattern secondary raised
ValueError and kept its opinion regardless. The opinions also often omit endian,
and nothing else held the chosen language to the byte order the file declares.
So EM_PARISC did not load at all, its one opinion being keyed to e_flags 528; a
double-float LoongArch object resolved to lp64f rather than lp64d; and a
little-endian NDS32 object resolved to NDS32:BE:32:default. Both constraints now
come from the ELF header.
Where several languages stay genuinely compatible, as for RISC-V or 68000, they
all still do. The regression loads the hppa fixture, which does not load today,
and a new NDS32 one.
Validation: #740 (comment)
sync: angr/binaries#177