When do you reach for Ghidra or IDA versus a debugger like x64dbg, and how do they complement each other?
Short answer
A disassembler like Ghidra or IDA gives you the full static map: cross-references, decompiled pseudocode, and every code path whether or not it runs. A debugger like x64dbg lets you execute the sample under control — set breakpoints, inspect registers and memory, watch decryption happen, and follow the path the code actually takes with real inputs. You read structure and intent statically, then attach the debugger to resolve what static analysis cannot: runtime-decrypted strings, dynamically resolved APIs, packed payloads, and which branch a condition takes. The two together close each other's gaps.
Deep reverse engineering happens in two complementary tools: a static disassembler/decompiler and a runtime debugger. Interviewers ask this to see whether you understand what each can and cannot tell you, and that you switch between them deliberately rather than living in one.
The disassembler — the map
Ghidra (free, open source, with a strong decompiler) and IDA Pro turn machine code into navigable assembly and decompiled pseudocode. Their power is completeness and context: cross-references (who calls this function, who reads this global), the full call graph, type recovery, and every branch laid out — including code that never executes in a given run. You use the disassembler to understand structure and intent: what a function does, where the config is parsed, where the C2 logic lives. You can annotate, rename, and script (Ghidra scripts, IDAPython) to automate deobfuscation.
The debugger — the ground truth
A static view stalls on anything resolved at runtime. x64dbg (and WinDbg for kernel work) lets you execute under control: software and hardware breakpoints, memory and register inspection, stepping, and patching. It shines at exactly the things static analysis cannot see: strings decrypted in memory, APIs resolved dynamically via GetProcAddress, unpacked payloads that only exist after the stub runs, and which branch a check actually takes with live data.
The workflow
Read statically to build a mental map and find the interesting functions; set breakpoints there in x64dbg to watch them with real values; feed observations (decrypted strings, resolved API addresses) back into the disassembler as annotations. A senior answer stresses this loop — static for breadth, dynamic for the runtime truth static cannot reach.
Likely follow-ups
- How does Ghidra's decompiler help you understand a function faster than raw assembly?
- What kinds of breakpoints in x64dbg help catch runtime-decrypted strings?
- Why can't static analysis alone resolve dynamically imported APIs?