ALSchwalm/dwarfexport

Section corruption for certain Go binaries

Sin42 opened this issue · 4 comments

Sin42 commented

I have found some cases where the sections get corrupted and the symbols added are unreadable.

The most simple way to replicate the bug is to take a Go binary (linux, 64 bit) and see what happens. I have attached a sample binary (before and after loading it in IDA and immediately applying dwarfexport)
Check with readelf -S test_binary.dbg

test.zip

Thanks for the report. Are you sure that go uses dwarf debug info? objdump -g and dwarfdump don't show anything for that binary.

Sin42 commented

Yes, I am sure. That binary was stripped so it's not going to show anything using objdump or dwarfdump. I am attaching another binary test_binary2.zip which is not stripped so you can verify that it uses dwarf debug info. Note that if you strip it and apply dwarfexport it doesn't seem to have the same section corruption problem.

By the way, thank you for this tool. I've used it successfully in a lot of situations!

Whoops, reading comprehension fail on my part. Looks like this bug was caused by my not shifting the section heading string table to the end of the binary, so the new section names would sometimes overflow in to other sections. Should be fixed in 06cee12. Glad to hear you're having success with the tool!

Sin42 commented

I can confirm that it now works with the initial binary. I can add the symbols and gdb and dwarfdump load it correctly. (However, loading the new binary in IDA dies when processing the DWARF data.)

As a side note, I am not sure how gdb or dwarfdump differ from readelf --syms or nm in checking if a binary has symbols. I am currently developing a Pintool and it seems to still see the binary as stripped even after having added the symbols with dwarfexport probably because it uses the same mechanism as readelf --syms and nm (maybe through .symtab ?) . It would be a nice future improvement if these also worked.