Does GHIDRA have a debugger attached for dynamic analysis of application?
Edit: As the question is a little unclear there might be a misunderstanding. From my point of view there are 2 possible answers:
GHIDRA does not offer a debugger for other binaries currently. (It is a planned feature)
GHIDRA has a debug mode to debug GHIDRA itself. This debugger is even accessible from the network, as the exposed port is not only locally bound.
Ghidra opens up JDWP in debug mode listening on port 18001, you can use it to execute code remotely 🤦♂️.. to fix change line 150 of support/launch.sh from * to 127.0.0.1 https://static.hacker.house/releasez/expl0itz/jdwp-exploit.txt
From WikiLeaks' "Vault 7: CIA Hacking Tools Revealed", I see Ghidra has a plugin for interaction with OllyDbg ("the Ghidra Debugger") but this plugin has not been released in the Ghidra public release yet. https://wikileaks.org/ciav7p1/cms/page_51183656.html
As of December 17th (2020), it has. See the announcement in Twitter https://twitter.com/NSACyber/status/1339652646513291264 and the debugger branch of Ghidra in GitHub https://github.com/NationalSecurityAgency/ghidra/tree/debugger
Ghidra does not have a debugger to date, but can be synchronized with a debugger (eg., x64dbg), with
ret-sync stands for Reverse-Engineering Tools SYNChronization. It is a set of plugins that help to synchronize a debugging session (WinDbg/GDB/LLDB/OllyDbg/OllyDbg2/x64dbg) with a disassembler (IDA/Ghidra/Binary Ninja). The underlying idea is simple: take the best from both worlds (static and dynamic analysis).
Debuggers and dynamic analysis provide us with:
- local view, with live dynamic context (registers, memory, etc.)
- built-in specialized features/API (ex: WinDbg's !peb, !drvobj, !address, etc.)
Disassemblers and static analysis provide us with:
- macro view over modules
- code analysis, signatures, types, etc.
- fancy graph view
- persistent storage of knowledge within IDBs/GPRs
- synchronize graph and decompilation views with debugger's state
- no need to deal with ASLR, addresses are rebased on-the-fly
- pass data (comment, command output) from debugger to disassembler
- multiple IDBs/GPRs can be synced at the same time allowing to easily trace through multiple modules
- disassembler and debugger can be on different hosts / VMs