Before
- Run auto-analysis and trust the decompiler
- Rename from strings
- Report every import as behavior
Module 6 of 17
Ghidra and Decompiler Workflow
Use Ghidra to answer a bounded defensive question about a transparent, source-built utility.
Start here
Learning objectives
- Create a reproducible Ghidra project with recorded artifact, tool, language, and import settings.
- Navigate memory, symbols, strings, references, functions, control flow, and decompiler output efficiently.
- Rename and retype items only when evidence supports the interpretation.
- Produce an evidence-linked function summary and compare it with source and harmless observed output.
After
- Record settings and validate key claims
- Rename from references and data flow
- Separate presence, reachability, and observed execution
Begin With a Bounded Question
Do not open Ghidra with the goal “understand everything.” Begin with a question tied to an authorised decision. For the course utility, the question is: Which functions read the fixed instructor-authored input, validate records, calculate the summary, and write the declared output? The question defines which code paths deserve attention.
Record artifact hash, provenance, architecture, tool version, project location, loader choice, language, compiler hints, image base, and analysis options. Import a verified working copy and keep the supplied original unchanged. Ghidra projects contain analyst-generated metadata and must remain inside the authorised lab.
Survey Before Renaming
Start with program information, memory map, entry points, discovered functions, external symbols, imports, exports, strings, and analysis messages. Look for parse errors and regions not analysed. Use strings and references as navigation aids, not as proof that a behavior executes.
Trace from a known boundary such as the program entry, a harmless error message, a fixed fixture filename, or an imported library function. Review callers and callees. Mark the evidence that connects a function to the bounded question before giving it a descriptive name.
Automatic analysis is a starting point. It may misidentify code, data, function boundaries, parameters, or types. A polished decompiler view can still be wrong.
Use Listing and Decompiler Together
The listing preserves instructions, addresses, references, and raw data. The decompiler presents a high-level hypothesis. Keep both visible. When the decompiler shows a condition, confirm the comparison and branch in the listing. When it proposes a parameter type, inspect call sites, instruction width, memory use, and relevant ABI rules.
Follow data from a controlled input to validation and output. Identify bounds checks and error paths. The course utility operates only on fixed, instructor-authored text, so there is no reason to introduce arbitrary input paths or modify the program. The exercise is analysis, not feature development.
Refine the Model Conservatively
Rename a function after evidence supports a role, and keep uncertainty in the name or comment when it does not. Apply types when size, use, call sites, or known API contracts justify them. Add comments that separate observation from interpretation. Avoid names that claim intent, actor, or malware family.
Use a function-summary table: entry address, proposed name, purpose, inputs, outputs, important calls, side effects, evidence, confidence, and open questions. Save notable address references so another authorised reviewer can reproduce the path.
If analysis options or types change, record the change and reconsider affected decompiler output. Analyst edits can improve a model, but a wrong type can also make later code look convincingly wrong.
Validate Against Independent Evidence
Compare the recovered flow with the harmless source, compiler-generated assembly, known test input, and declared synthetic output. The point is not to prove Ghidra agrees with source; it is to understand where the binary supports, transforms, or leaves ambiguity around the source-level model.
Write conclusions with evidence locations and confidence. Note unanalysed regions, indirect calls, missing symbols, parser warnings, and assumptions. If the utility's hash, filesystem scope, privilege, or observed behavior differs from its manifest, stop, power off the guest, and follow the course escalation path.
Translate Findings Into Developer Controls
Decompiler findings become valuable when they improve engineering. A hard-coded endpoint can become a reviewed configuration with an allowlist. An ambiguous parser boundary can gain explicit validation and telemetry. A release with weak provenance can gain reproducible build metadata and signature verification.
Keep recommendations proportional. Do not infer a hidden capability from an unreachable string or unused import. State which path is proven reachable, which is merely present, and what test or source evidence would reduce uncertainty.
Suggested Study Plan (10 hours)
The published duration includes active practice, not video playback alone. Complete each block with the course-owned evidence and retain the stated deliverable so another reviewer can reproduce your reasoning.
| Study block | Time | Required evidence |
|---|---|---|
| Guided lesson and primary-source review | 1h 48m | Annotated notes that separate observations, hypotheses, limits, and version-sensitive facts. |
| Worked evidence walkthroughs | 1h 30m | Reproduce the lesson's tables or decision flow and challenge at least two assumptions. |
| Independent practice rounds | 1h 30m | Apply the method to two alternate records in the sanitized evidence pack and compare the conclusions. |
| Required lab | 4 hours | A reproducible Ghidra project record, evidence-linked call and control-flow map, function-summary table, source comparison, limitations, confidence labels, and teardown record. |
| Knowledge check and review | 1h 12m | Answer the evidence check, review the rubric, and record one production follow-up. |
Evidence Check
Question: Ghidra automatically names a function and shows a clean parameter list in the decompiler. What should an analyst do before using that interpretation in the report?
Reveal the defensive reasoning
Validate the function boundary, callers, call sites, argument locations, instruction widths, references, and relevant ABI or known API signature. Treat automatic names and types as hypotheses, record supporting evidence, and keep uncertainty visible.
Primary References
Use these primary sources for the current standard or tool behavior. The course records framework versions so mappings can be reviewed when upstream guidance changes.
Real world
Where this shows up
- Reviewing a proprietary or legacy component when source and build records are incomplete.
- Comparing deployed control flow with an expected source-built release.
- Explaining a native crash or suspicious code path to application and incident-response teams.
Production notes
Keep these close
- Pin and patch the reverse-engineering toolchain and run it in an isolated analysis environment.
- Store project metadata with access controls because annotations may contain sensitive implementation details.
- Preserve import settings and analysis warnings so another reviewer can reproduce the project.
- Prefer narrow, decision-linked analysis over open-ended exploration of unrelated code.
Common mistakes
What usually breaks
- Renaming functions from a single string without checking references and reachability.
- Trusting automatic types, function boundaries, or decompiler syntax as ground truth.
- Ignoring import settings, architecture, image base, analysis warnings, or indirect calls.
- Reporting present code or data as executed behavior without independent evidence.
Security risks
Threats to watch
- Malformed artifacts may exploit analysis tooling, so the toolchain remains isolated.
- Incorrect analyst types can distort decompiler output and propagate false conclusions.
- Project annotations may expose sensitive paths, names, or implementation details.
- Open-ended analysis can exceed authority and delay urgent containment decisions.
Tradeoffs
Design choices you should be able to defend
Aggressive automatic analysis
Pros
- Finds many functions and references quickly
- Creates a useful first navigation model
Cons
- May infer incorrect code, data, types, or boundaries
- Can make weak assumptions look polished
Question-led incremental analysis
Pros
- Keeps work proportional and evidence-linked
- Makes analyst assumptions easier to review
Cons
- May leave unrelated regions unexplored
- Requires careful note-taking
Think like an engineer
Questions to answer before shipping
- What exact decision will this reverse-engineering question inform?
- Which decompiler claim is supported by the listing and multiple call sites?
- Is a suspicious string reachable from the observed path or merely present in data?
- Which source, build, or telemetry evidence can independently validate the model?
Key terms
Vocabulary used in this module
Disassembly
A representation that decodes machine-code bytes into architecture instructions.
Decompilation
A reconstruction of a plausible high-level representation from lower-level program information.
Cross-reference
A recorded relationship showing where an address, function, or data item is referenced.
Reachability
Whether control flow can arrive at a block or function from a stated entry path under given conditions.
Analyst annotation
A name, type, comment, bookmark, or other interpretation added during analysis.
Exercises
Practice inside the lesson
Reconstruct a Harmless Utility in Ghidra
Answer a bounded question about the course utility and produce a reproducible function map without analysing or executing an unknown binary.
- Restore the clean isolated VM, verify the source-built utility hash from Module 5, and record the Ghidra version and project settings.
- Import the verified working copy with the documented architecture and loader settings; record automatic-analysis options and all warnings.
- Survey memory regions, functions, imports, strings, and cross-references before renaming or retyping anything.
- Trace the fixed input path through validation, summary calculation, and fixed output; capture evidence addresses for each transition.
- Rename and type only evidence-supported items, then create a function-summary table with confidence and open questions.
- Compare the result with source, compiler-generated assembly, and declared harmless test output; export only notes and screenshots, then restore the snapshot.
Expected evidence
A reproducible Ghidra project record, evidence-linked call and control-flow map, function-summary table, source comparison, limitations, confidence labels, and teardown record.
Assessment criteria
- Artifact hash, Ghidra version, architecture, loader, analysis settings, and warnings are recorded.
- Function names, types, and purposes are supported by listing, call-site, reference, or ABI evidence.
- The report separates reachable behavior from present-but-unproven strings or imports.
- Independent source, assembly, and harmless-output evidence is used to validate conclusions.
- Unknowns and analysis limitations remain visible, and the isolated environment is restored.
Course-owned resources
Teardown
- Export only the expected notes or synthetic logs.
- Power off the VM.
- Restore the clean snapshot and verify network isolation.
Recap
Key takeaways
- A bounded question keeps reverse engineering useful and proportionate.
- Automatic analysis and decompiler output are hypotheses that need listing and call-site evidence.
- Renaming and retyping should improve an evidence-backed model, not hide uncertainty.
- Independent source, build, and harmless-output evidence strengthens conclusions.
- A good report links every important claim to a reproducible location or record.
Related resources