search

Vector35 / dwarf_import

This loads DWARF info from an open binary and propagates function names, arguments, and type info
MIT License
24 stars 7 forks source link

Support for mangled names #17

Closed oskarwirga closed 1 year ago

oskarwirga commented 2 years ago

Hi Kyle,

I have come across a small hiccup when using this plugin. The DWARF info for the mangled name does not make it to the symbol.

My current workaround is to just get the address and then use objdump to get the mangled name at that address. Not a huge thing, but the mangled name is specifically useful for things like ignorelists.

Thanks!

ElykDeer commented 2 years ago

Hey Oskar!

Do you have an example? I'm not able to reproduce what you're describing; function symbols with updated names maintain their raw_name fields in my test binaries.

oskarwirga commented 2 years ago

I have spent some time delving into the fb build system to see what exactly is happening, but I still don't know exactly why this is happening or if it's even something you can address:

  1. I get the unstripped library and disassemble it in binja
  2. The function at 0xba0 has a name _5
  3. I run the dwarf plugin and now the unmangled name is operator()(class* this)
  4. The underlying "mangled name" is still _5 but running nm or readelf will show the 'true' mangled name as _ZZN8facebook5build13getAndroidSdkEvENK3$_0clEv

If this is not relevant to this plugin feel free to close and dismiss this task. I was thinking this plugin would overwrite the mangled name, but now that I am typing it, that doesn't make sense.

ElykDeer commented 1 year ago

That is very strange. If you have a sample you're able to share, I'd be happy to look in to it more.

Are you looking at all the forms of the symbol's name? function.symbol.short_name is usually what get displayed, where as function.symbol.raw_name should be the actual original mangled name. If that's not the case, I suspect it would be a bug in our ELF loader (recently open sourced).