Working with a binary (arm64) file that seems to be some sort of a broken ELF file. The header data is missing and for some reason it contains a symbol table in a format that to me seem to be equal to the output when running
objdump -t <filename.elf> on a valid ELF, concatenated after all the code.
(To avoid misunderstandings; if I run mentioned command on a different, valid ELF, I get a symbol table output in the format below, and it's a symbol table in this format that I find inside the broken ELF.)
However, neither IDA pro nor Ghidra manage to utilize this information, so for now the only way I've managed to use some of this to my advantage is to write a (IDA)python script and parse it "manually" to add functions, function names, etc based on the content of the symbol table.
This procedure works to some extent but it's not that great (probably due to my limited experience with writing good IDA-python parsers). It got me wondering if there maybe exist some other tool for this already?
I'm not very experienced with IDA or Ghidra, so it could be one/both of them have a feature to load symbol tables in this format, but if so, I've overlooked that at least.
Here's a small excerpt from the symbol-table data included in the broken ELF (just changed some of the names). As mentioned, the format is equal to what you get when running
objdump -t randomfile.elf > table.txt on a valid ELF file.
randomfile.elf: file format elf64-littleaarch64 SYMBOL TABLE: 0000000010c00000 l d .text 0000000000000000 .text 0000000010e2a550 l d __ex_table 0000000000000000 __ex_table 0000000010e2a570 l d .text.unlikely 0000000000000000 .text.unlikely 0000000010e2a5a0 l d .data 0000000000000000 .data 0000000010ebf380 l d .got.plt 0000000000000000 .got.plt 0000000010ebf398 l d .module 0000000000000000 .module 0000000010ebf740 l d .bss 0000000000000000 .bss 0000000000000000 l d .debug_info 0000000000000000 .debug_info 0000000000000000 l d .debug_abbrev 0000000000000000 .debug_abbrev 0000000000000000 l d .debug_loc 0000000000000000 .debug_loc 0000000000000000 l d .debug_aranges 0000000000000000 .debug_aranges 0000000000000000 l d .debug_line 0000000000000000 .debug_line 0000000000000000 l d .debug_str 0000000000000000 .debug_str 0000000000000000 l d .comment 0000000000000000 .comment 0000000000000000 l d .debug_frame 0000000000000000 .debug_frame 0000000000000000 l d .debug_ranges 0000000000000000 .debug_ranges 0000000000000000 l df *ABS* 0000000000000000 init.o 0000000000002000 l *ABS* 0000000000000000 STACK_SIZE 0000000010c00034 l .text 0000000000000000 init_start 0000000010c00024 l .text 0000000000000000 fw_magic 0000000010c00328 l .text 0000000000000000 feature_init 0000000010c00370 l .text 0000000000000000 subfeature_init 0000000010c001d4 l .text 0000000000000000 twee_init . . . 0000000010d541a0 g F .text 0000000000000004 memset 0000000010e5e510 g O .data 0000000000000080 acFont_ASCII 0000000010c2bd5c g F .text 0000000000000004 get_curve 0000000010c29d24 g F .text 0000000000000118 inject_mem
Based on an older version of the ELF file that I found, which contains both headers and a "proper" symbol table (proper as in I can run
readelf etc on the file without errors), I've started on "reconstructing" a header for the broken ELF - basically copying the header from the older ELF version and adjusting the load address, etc. It's far from 100% correct, but it seems to make things a bit easier for me since IDA pro is analyzing the file automatically. Ghidra, on the other hand, doesn't manage to load the ELF at all if I include my partial ELF-header.
If I also could either load the symbol table from the broken ELF - as is - in IDA with some feature, that'd be great. Even better if there is a way to incorporate the symbol table in some other format into the ELF so that IDA/Ghidra automatically manage to use this information while analyzing.
Might be this is a far fetched dream, but worth a shot. For all I know there could be some existing feature for this.