Disassembly With Ghidra

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

When behaviour and strings aren't enough — you need to understand how a sample works, its exact logic, a decryption routine, or a capability that only runs under specific conditions — you read the code. Ghidra (NSA's free reverse-engineering suite) disassembles and decompiles compiled binaries into something readable. This skill covers using Ghidra effectively on malware, with the crucial discipline of knowing what to read, because reading a whole binary instruction-by-instruction is a losing game.

When to use it

Deep analysis, after triage/unpacking, when you need code-level understanding: to confirm capability, extract a hardcoded key or C2 config, understand an algorithm, or analyse logic that dynamic analysis won't trigger. It's the most time-intensive skill in the domain, so reserve it for when you genuinely need code-level answers.

Procedure

1. Load the (unpacked) sample into Ghidra and let its auto-analysis run — it disassembles, identifies functions, and produces decompiled C-like pseudocode. Analyse the unpacked payload, not a packed stub (unpacking-basics skill).
2. Don't read linearly — navigate to what matters. The skill is targeting your reading, not reading everything. Use anchors to jump to the interesting code:
   • Strings — find an interesting string (a URL, a command, an error), then find where it's referenced in code; that's often the function that matters.
   • Imports/API calls — cross-reference calls to interesting APIs (network, crypto, process injection, registry) to find the code that uses them.
   • Entry point / main — orient from the top-level flow.
3. Use the decompiler as your primary view. Ghidra's decompiled pseudocode is far faster to read than raw assembly; use the disassembly to confirm details the decompiler gets wrong. Read the pseudocode to understand logic, drop to assembly when precision matters.
4. Rename and annotate as you go. Malware functions have no names; as you understand a function, rename it (decrypt_config, send_beacon) and add comments. This turns an unreadable mess into a map and is how you make progress on anything non-trivial.
5. Focus on the analysis goal, not completeness. You rarely need to understand every function — you need the specific thing (the C2 config, the decryption routine, the trigger condition, the capability). Follow the code toward that goal and stop when you have the answer.
6. Extract what you came for — a hardcoded key/config, an algorithm, a decision point — and feed it into IoC extraction and reporting. Sometimes reversing a decryption routine lets you decode config that yields the real indicators.

Cheatsheet

load the UNPACKED payload (not the packer stub) -> let auto-analysis run
primary view = the DECOMPILER (C-like pseudocode) ; drop to asm for precision

navigate to what matters (don't read linearly)
  interesting STRING  -> find its XREF -> the function using it
  interesting API     -> XREF network/crypto/injection/registry calls -> the code
  entry point / main  -> top-level flow

work the code
  RENAME functions/variables as you understand them (decrypt_config, send_beacon)
  COMMENT your findings -> build a map out of the mess

focus on the GOAL, not completeness
  need: C2 config? decryption routine? trigger condition? a specific capability?
  follow code toward it, STOP when answered (you don't need every function)

extract: hardcoded keys/config, algorithms, decision points -> IoCs + report

Reading the code

• A string's cross-reference leading to a key function = the fast path; interesting strings and their XREFs are usually the shortest route to the code that matters. Start here rather than at the top.
• Calls to crypto/network/injection APIs = the capability-bearing code; cross-referencing them jumps you to what the malware actually does.
• A decryption/decoding routine = high value — reversing it often reveals a hardcoded C2 config, key, or encoded strings that yield the real indicators. Worth the effort.
• A trigger/condition check (date, environment, target check) = why dynamic analysis "did nothing"; the code reveals conditions the sandbox didn't meet.
• Decompiler output that looks wrong (odd casts, missing logic) = drop to the disassembly to confirm; the decompiler is a fast approximation, not gospel.
• A renamed, annotated function graph = your progress made visible; on anything non-trivial this is what makes the analysis tractable.

Pitfalls

• Reading linearly / trying to understand everything. Binaries are huge; instruction-by-instruction from the top never finishes. Navigate from strings and APIs to the code that matters, and target the analysis goal.
• Analysing a packed stub. You'll reverse the packer, not the malware. Unpack first (unpacking-basics).
• Not renaming/annotating. Malware code is nameless; without building a map as you go, you lose track and re-derive the same things. Rename relentlessly.
• Trusting the decompiler blindly. It's a fast approximation and can misrepresent logic; confirm critical details in the disassembly.
• Reversing when you don't need to. Disassembly is expensive; if dynamic analysis or strings answer the question, don't reverse. Reserve it for genuine code-level needs.

References

• Ghidra documentation and the official Ghidra course/book
• Practical Malware Analysis (disassembly/IDA chapters — concepts transfer to Ghidra)
• The unpacking-basics, static-triage, and extracting-iocs skills
• MITRE ATT&CK (map discovered capabilities)

Inputs

• Relevant source code, logs, network traces, or system specifications.

Outputs

• Analysis findings, security audit report, or generated code artifacts.