1

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 objdump, 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.

1
  • This is really just a side note, but tinycc produces .elf files when compiling Windows applications. The resultant code is perfectly normal, and I've never looked at the intermediate format of the .elf files -- they certainly wouldn't be obliged to be compliant with (say) Linux .elf files - though they may be, Fabrice Bellard can certainly do whatever he likes.:) – Orwellophile Apr 25 at 6:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.