[HN Gopher] "Unstripping" binaries: Restoring debugging informat...
___________________________________________________________________
"Unstripping" binaries: Restoring debugging information in GDB with
Pwndbg
Author : aa_is_op
Score : 88 points
Date : 2024-09-08 17:23 UTC (5 hours ago)
(HTM) web link (blog.trailofbits.com)
(TXT) w3m dump (blog.trailofbits.com)
| robin_reala wrote:
| I read "pwndgb" as Welsh for a good 5 seconds before realising
| which site I was on.
| senkora wrote:
| "Welsh or C standard library name?"
|
| https://www.reddit.com/r/ProgrammerHumor/comments/1f123qw/le...
| bieganski wrote:
| sounds like an interesting direction, but I don't understand why
| should we have it coupled to specific tool (pwndbg)? Why not
| implement a BinaryNinja plugin to dump all user-defined names
| (function names, stack variables), together with an original
| (stripped) binary to the new ELF/.exe file, with symbol table and
| presumably with DWARF section?
| 5- wrote:
| that's already available in binaryninja out of the box, via the
| (seemingly undocumented) 'plugins' -> 'export as dwarf' menu
| item.
| boricj wrote:
| I've developed a Ghidra extension that exports object files.
| I've considered generating debugging symbols in order to
| improve the debugging experience when reusing these object
| files in new programs, but I keep postponing that feature for
| various reasons.
|
| Executable formats have at least one and often multiple
| debugging data formats which are very different from each
| other: ELF has STABS and DWARF version 1 to 5, MSVC has at
| least COFF symbols and PDB (which isn't documented)... Even
| discarding the old or obsolete stuff, there's no universal
| solution here. gdb+pwndbg seems to side-step this issue by
| integrating the debugger with Binary Ninja.
|
| Projecting reverse-engineered information into a debugging data
| format would also be a technical challenge once you go past
| global variables and type definitions. Debuggers already have a
| terrible user experience when stepping through functions in an
| optimized executable ; I doubt that reverse-engineered
| debugging data would be any better.
|
| Toolchains also don't do a lot of validation or diagnostics on
| their inputs and I can tell from experience that writing
| correct object files from scratch is already quite tricky. I
| expect that serializing correct and meaningful debugging data
| would be much harder than that.
|
| Doing this at the native executable level has the obvious
| advantage of working out of the box with standard tooling, but
| it would be a _lot_ of work. I 've already taken 2 1/2 years to
| make an object file exporter that's good enough for my needs
| and I'm still balking at generating DWARF debugging data every
| time I've considered it. I'm resigned to a terrible debugging
| experience and so far I've managed to muddle through it.
| jcranmer wrote:
| > Debuggers already have a terrible user experience when
| stepping through functions in an optimized executable ; I
| doubt that reverse-engineered debugging data would be any
| better.
|
| Actually, I suspect it could be a world of difference. The
| main failures of optimized debugging are that code motion
| makes line number tables more of a suggestion, the source
| code values may disappear in favor of other related values
| (e.g., SROA or changing A[i] to p++), live ranges of
| variables may shrink, and debugging information may only
| support variables in stack slot or other specific locations.
| If you generating debugging based on decompiled code, you can
| control the output code to make the first two problems more
| or less go away, and so you only really have to worry about
| narrow live ranges (can't do much about that) or debuggers
| not supporting the features you need (which, given DWARF, is
| a very real possibility).
| saagarjha wrote:
| I'm curious how this compares with
| https://github.com/mahaloz/decomp2dbg
| userbinator wrote:
| _GDB loses significant functionality when debugging binaries that
| lack debugging symbols_
|
| IMHO from experience with other debuggers, GDB is actually
| hostile to debugging at the Asm level, due to many perplexing
| design choices which may or may not be deliberate. Things like
| needing to add a superfluous asterisk when breakpointing on an
| address, the "disassemble" command not being able to do what it
| says and instead complaining about a lack of functions, etc.
| kuroguro wrote:
| +1 there are many pain points, probably for historic reasons.
| *nix almost always comes with the source, so binary only
| debugging is never a priority.
| jchw wrote:
| I have definitely gotten to the point of "Fine, I'll just use
| IDA Pro then".
|
| Of course, visual debuggers are another story entirely, but I'm
| not really thrilled with them either. For example I don't
| recall there being a good way to say "Decode the address at rax
| as a WNDCLASSA" or something like that in IDA. (I'm crossing my
| fingers for a Cunningham's Law here.)
___________________________________________________________________
(page generated 2024-09-08 23:00 UTC)