4 ms·

Ghidra to DWARF was already possible via this plugin: https://github.com/cesena/ghidra2dwarf https://github.com/cesena/ghidra2dwarf. I’ve used this a lot (and c

Ghidra to DWARF was already possible via this plugin: https://github.com/cesena/ghidra2dwarf https://github.com/cesena/ghidra2dwarf. I’ve used this a lot (and contributed some patches) as it’s immensely useful in reverse engineering code. It gives me source-level debug capabilities in GDB on binaries without the original source code, by lining up the decompiled source code with the generated DWARF debug info. It works practically like magic: you get the ability to inspect variables (including complex structure types!), see arguments to functions, get fully symbolicated backtraces, see source code as you step, use line-level breakpoints, and more.

stefan_ 1y ago
Whats wrong with using Ghidra to debug directly?
- nneonneo 1y ago
  Eh, using GDB directly is a lot more convenient for me. Integrations with pwntools, good scripting support, and familiarity are big reasons I keep using GDB. Plus the last few times I’ve tried to use Ghidra’s debugger I ran into weird issues with the debugger freezing or otherwise refusing to update the program state properly; after chasing down and trying to fix some of them I concluded that it wasn’t a sane use of my time.
  - delusional 1y ago
    What do you use GDB scripting for if you don't mind me asking? I always try to use it, but it's such an awkward language ant it never feels quite worth it to me.
    - nneonneo 1y ago
      It’s useful for simple breakpoint automation and conditional breakpoints, as well as basically adding virtual print statements to programs (the printf command in GDB is very powerful). I also used it to find a complex bug that someone posted here on HN once: https://news.ycombinator.com/item?id=22031581 https://news.ycombinator.com/item?id=22031581 Also, GDB supports Python scripting too, which is really good since you can use the full power of Python with a decent debugger API; many of the plugins I use frequently (e.g. GEF - https://github.com/hugsy/gef https://github.com/hugsy/gef) are written using the Python GDB API.
- PennRobotics 1y ago
  I just tried on a microcontroller target. Some instructions cause a ghidra.pcode.exec.PcodeExecutionException but can be manually skipped. I can get to the same stopping points as a commercial simulator, but nothing is displayed in the Stack window in the Ghidra debugger and single stepping ignoring side effects (mostly for cpsie/cpsid/isb/dsb/msr/mrs op codes) takes 10 or 15 seconds for each skipped instruction. Watches on complex variable types (ListItem_t *) are clearly displayed wrong (value { 38 }) and I'd prefer watches to disappear when they're not in scope. I must be doing something wrong because I can step through the machine code but would prefer to step through each C++ line without using line-by-line breakpoints, and I don't know if that exists or how to set it up. Right now, it's easier for me to use a commercial debugger/simulator; it shows the call history, variables are displayed properly once I import their structure, browsing SRAM is fast/intuitive, MCU peripheral registers are displayed/changed on a single screen with a few clicks or keystrokes (even after importing the SVD into Ghidra), op codes don't need to be skipped (so the processor handles the stack, privilege states, and core/system registers correctly). Also, the default debugger windows in Ghidra are bonkers. The entire left side shows meaningless data. The right side has tabs for windows I'd like to see simultaneously (memory and decompilation). I'd also rather have multiple child windows for different memory ranges, since FreeRTOS and application variables are interspersed in the code but separated in RAM. The bottom panel is useless for me except for Stack (which is empty) and Watches. On a laptop, the whole UI is cramped. It's easy to change this, but I'd rather just have a useful workflow as an opinionated default. When I can export what I've manually decompiled to DWARF, I'm more comfortable in a commercial Arm debugger than in gdb or anything that looks/feels like an Eclipse IDE debugger. There's a lot of potential. That is obvious. I do wonder if I'm missing something; if changing the emulator/backend or the right tool setting will unlock nirvana. I also feel like I'm dropping the ball by not opening issues, but I'm sure there are plenty of Ghidra users trying to analyze Arm Cortex who have the same stumbling blocks as me but perhaps more free time.
- l-albertovich 1y ago
  There doesn't have to be anything wrong for people to choose whatever they feel most comfortable with. Back when I used to do a lot of android (and some iOS) based RE I sometimes used gdb on the device itself through ssh because it was the path of least resistance which allowed me to focus on the hard parts of the job.
- senkora 1y ago
  I imagine that having access to rr (which wraps gdb) would also be quite useful.
nandkeypull 1y ago
See also https://github.com/aldelaro5/ghidra-ExportDwarfELFSymbols https://github.com/aldelaro5/ghidra-ExportDwarfELFSymbols, which lets you generate an ELF out of a ghidra database for even non-ELF binaries (e.g. bare-metal firmware dumps).

stefan_ 1y ago

Whats wrong with using Ghidra to debug directly?

nneonneo 1y ago
Eh, using GDB directly is a lot more convenient for me. Integrations with pwntools, good scripting support, and familiarity are big reasons I keep using GDB. Plus the last few times I’ve tried to use Ghidra’s debugger I ran into weird issues with the debugger freezing or otherwise refusing to update the program state properly; after chasing down and trying to fix some of them I concluded that it wasn’t a sane use of my time.
- delusional 1y ago
  What do you use GDB scripting for if you don't mind me asking? I always try to use it, but it's such an awkward language ant it never feels quite worth it to me.
  - nneonneo 1y ago
    It’s useful for simple breakpoint automation and conditional breakpoints, as well as basically adding virtual print statements to programs (the printf command in GDB is very powerful). I also used it to find a complex bug that someone posted here on HN once: https://news.ycombinator.com/item?id=22031581 https://news.ycombinator.com/item?id=22031581 Also, GDB supports Python scripting too, which is really good since you can use the full power of Python with a decent debugger API; many of the plugins I use frequently (e.g. GEF - https://github.com/hugsy/gef https://github.com/hugsy/gef) are written using the Python GDB API.
PennRobotics 1y ago
I just tried on a microcontroller target. Some instructions cause a ghidra.pcode.exec.PcodeExecutionException but can be manually skipped. I can get to the same stopping points as a commercial simulator, but nothing is displayed in the Stack window in the Ghidra debugger and single stepping ignoring side effects (mostly for cpsie/cpsid/isb/dsb/msr/mrs op codes) takes 10 or 15 seconds for each skipped instruction. Watches on complex variable types (ListItem_t *) are clearly displayed wrong (value { 38 }) and I'd prefer watches to disappear when they're not in scope. I must be doing something wrong because I can step through the machine code but would prefer to step through each C++ line without using line-by-line breakpoints, and I don't know if that exists or how to set it up. Right now, it's easier for me to use a commercial debugger/simulator; it shows the call history, variables are displayed properly once I import their structure, browsing SRAM is fast/intuitive, MCU peripheral registers are displayed/changed on a single screen with a few clicks or keystrokes (even after importing the SVD into Ghidra), op codes don't need to be skipped (so the processor handles the stack, privilege states, and core/system registers correctly). Also, the default debugger windows in Ghidra are bonkers. The entire left side shows meaningless data. The right side has tabs for windows I'd like to see simultaneously (memory and decompilation). I'd also rather have multiple child windows for different memory ranges, since FreeRTOS and application variables are interspersed in the code but separated in RAM. The bottom panel is useless for me except for Stack (which is empty) and Watches. On a laptop, the whole UI is cramped. It's easy to change this, but I'd rather just have a useful workflow as an opinionated default. When I can export what I've manually decompiled to DWARF, I'm more comfortable in a commercial Arm debugger than in gdb or anything that looks/feels like an Eclipse IDE debugger. There's a lot of potential. That is obvious. I do wonder if I'm missing something; if changing the emulator/backend or the right tool setting will unlock nirvana. I also feel like I'm dropping the ball by not opening issues, but I'm sure there are plenty of Ghidra users trying to analyze Arm Cortex who have the same stumbling blocks as me but perhaps more free time.
l-albertovich 1y ago
There doesn't have to be anything wrong for people to choose whatever they feel most comfortable with. Back when I used to do a lot of android (and some iOS) based RE I sometimes used gdb on the device itself through ssh because it was the path of least resistance which allowed me to focus on the hard parts of the job.
senkora 1y ago
I imagine that having access to rr (which wraps gdb) would also be quite useful.

nandkeypull 1y ago

See also https://github.com/aldelaro5/ghidra-ExportDwarfELFSymbols https://github.com/aldelaro5/ghidra-ExportDwarfELFSymbols, which lets you generate an ELF out of a ghidra database for even non-ELF binaries (e.g. bare-metal firmware dumps).