Field notes / Software archaeology

The software you run is not the software you understand.

Ghidra, Fourier series, and the discipline of reconstructing knowledge without confusing the model for the original.

Compiled artifact4D 5A 90 00 03 00 00 00
Bytes

The artifact that actually runs.

Instructions

A processor-aware reading of those bytes.

Pseudocode

A useful interpretation, not original source.

Judgment

Names, tests, evidence, and revision.

Artifact → interpretation. Each step adds structure. None should hide the evidence below it.

A supplier disappears. A device still runs. A security alert points to a component no one owns. The source repository is incomplete, the documentation is older than the system, and the people who understood the original design have moved on.

The software still executes. Its explanation does not.

That is where reverse engineering becomes more than a specialist exercise. A team may need to understand a program well enough to investigate an incident, plan a migration, maintain an inherited product, or decide whether a component can be trusted. The compiled artifact is available. The original reasoning behind it is not.

Ghidra was built for this kind of gap.

It is a software reverse-engineering framework created and maintained by the National Security Agency Research Directorate. Its public toolset includes disassembly, decompilation, graphing, scripting, support for many processor and executable formats, and both interactive and automated analysis.8

The interesting part is not that Ghidra can make machine instructions easier to read. The interesting part is how it lets an analyst move between a readable interpretation and the evidence underneath it.

A model earns trust when it preserves a visible route back to evidence.

A program can outlive its explanation

Organizations accumulate software faster than they preserve understanding.

A system survives a merger. A vendor stops answering. A factory controller keeps doing its job long after the integration team has gone. An internal utility becomes operationally critical even though no one planned for it to last.

Running code can create a false sense of knowledge. If the program starts and the screen looks familiar, the organization feels as though it still owns the capability. That confidence disappears when someone has to change the software, prove what it does, or explain an unexpected behavior.

Execution is not understanding.

Reverse engineering starts with the artifact that remains. Ghidra can load a compiled program, identify instructions and likely functions, trace references, draw control-flow relationships, and produce C-like pseudocode. An analyst can add names, types, comments, and structure as evidence accumulates.

Each layer makes the program easier to reason about. None of them restores the missing past.

The Fourier connection is about the route, not the mathematics

In the Fourier essay, I started with a drawing. A path became two coordinate signals. Those signals became coefficients. The coefficients drove rotating vectors that drew an approximation of the path again.

The result was convincing because the recipe stayed visible. We could change the number of frequencies, reconstruct the path, and compare the output with the chosen input. We could see what the model preserved and what it smoothed away.

Software reverse engineering is not a Fourier transform.

A Fourier series has a defined mathematical relationship to the signal we choose. Compilation is often lossy. It can discard variable names, comments, source organization, and type information. Optimization can combine operations, move them, split them, or remove them entirely. There is no general inverse that recreates the one true source file.

Ghidra does something more practical. It builds useful views of the evidence that survived compilation.

The analogy begins and ends there: both exercises become trustworthy when the transformation is inspectable, the assumptions are visible, and the result can be checked against something real.

Readability is not provenance

A decompiler window can look authoritative. The output has functions, loops, conditions, variables, and familiar syntax. It resembles source code closely enough that the distinction is easy to forget.

The decompiler did not recover the developer’s original file.

It produced a high-level representation that is consistent with its analysis of the binary. That representation can be extremely useful, but it is still a working model. Change a type, correct a function boundary, select a different processor language, or add a known symbol and the readable output may improve while the underlying bytes remain unchanged.

This is where the analyst matters.

Renaming FUN_001012a0 to validate_header is not clerical cleanup. It is a claim. A careful analyst ties that name to cross-references, constants, data flow, runtime behavior, or other evidence. If the evidence changes, the name should change too.

A useful reconstruction tells us three things separately:

  1. what the tool observed;
  2. what the analyst inferred;
  3. what testing confirmed.

Blurring those levels makes software look better understood than it is.

The intelligence-community origin matters for a specific reason

NSA is a member of the U.S. Intelligence Community, but the agency’s public Ghidra materials describe the framework in the context of its cybersecurity mission.18 NSA says Ghidra was created in the late 1990s and built to address scaling and teamwork in complex reverse-engineering efforts.24

That history can tempt people into an easy story about secret tools escaping into the public. The public record supports a more useful story.

NSA released Ghidra at the RSA Conference on March 5, 2019.2 It released the source code on April 4 so developers could build it, create patches, and extend it for their own cybersecurity needs.3

The move changed the verification perimeter.

Before the public source release, an outside user could not inspect the implementation, propose a patch through a public workflow, or build a specialized extension against a shared repository. After the release, the tool itself became available for examination alongside the programs it was designed to examine.

That does not erase Ghidra’s institutional origin. It turns the origin into part of a public maintenance relationship.

GitHub made the feedback loop concrete

Open source is often discussed as an attribute: public or private, open or closed. The more important question is whether a working feedback loop exists.

Ghidra’s contributor guide invites bug reports, feature proposals, documentation, pull requests, review, support, and teaching. It also warns that maintainers have a large backlog and that unsolicited changes may receive lower priority.9

That is healthier than pretending community review happens automatically.

By 2023, NSA said it had adopted contributions created by public GitHub users.6 Expertise moved in both directions. The agency released a mature internal tool. External users returned code, edge cases, documentation, extensions, and operational knowledge.

Public code did not make every analysis correct. It made more of the instrument available for challenge.

The project’s current contributor guide contains an especially relevant line for the agent era. If AI assists with development, contributors should apply “extra scrutiny” to correctness and legal requirements.9

That is the right posture. AI can accelerate a patch. It cannot absorb responsibility for the patch.

The command line turns analysis into a process

Ghidra is known for its graphical interface, but it also includes a first-party Headless Analyzer. The command-line workflow can create and populate projects, analyze binaries, and run scripts without opening the interface. The documentation points to repetitive and bulk work as direct use cases.10

That matters because serious analysis should not depend entirely on one person’s clicks.

A command can record the project, import path, scripts, logs, processor selection, timeouts, and output location. A team can rerun the analysis against a new build. It can diff exported function lists, call relationships, or selected findings. It can preserve the tool version and the binary hash with the report.

The point is not to automate judgment away. The point is to make the repeatable part genuinely repeatable.

This is the same reason I keep returning to the command surface. When a system can affect code, infrastructure, accounts, or decisions, I want visible inputs, options, logs, artifacts, and failure states. A polished explanation is not enough.

Ghidra’s headless mode does not guarantee identical conclusions from two analysts. It gives them a common operational surface on which differences can be found.

Open source changes the evidence, not the obligation

A public repository does not prove that every release is safe. It does not prove that every processor model is correct, every pull request receives review, or every decompilation deserves confidence.

Visibility is a condition for scrutiny. It is not a substitute for scrutiny.

A responsible workflow still records the exact binary, its hash, the Ghidra version, the analysis settings, the scripts used, the analyst’s annotations, and the behavior that was tested. It still separates observation from inference. It still respects contracts, licenses, authorization, and applicable law.

The same standard applies to AI systems.

When an agent produces a plan, patch, explanation, or action, ask what representation it built. Ask which assumptions shaped that representation. Ask whether the output can be traced to source evidence, rerun with the same settings, challenged by another operator, and corrected without starting over.

This is more useful than asking whether the model is intelligent. It asks whether the work is inspectable.

Keep the chain of custody

Fourier drawing begins with a path and ends with a path we can compare. Ghidra begins with a compiled artifact and produces several linked views that help people form and test an understanding of it.

The second journey is less exact. Lost names and comments may stay lost. Developer intent cannot be decompiled from instructions. A clean pseudocode window can still contain uncertainty.

That does not make the reconstruction worthless. It defines the terms under which it is useful.

A team can trace a readable claim back to instructions. It can record why a function was renamed. It can test behavior. It can rerun scripts. It can review changes. It can let another analyst disagree with evidence in hand.

The software may never become fully transparent. The work can still become accountable.

The model earns trust by keeping its chain of custody intact.

Sources and method

This article uses Ghidra’s public documentation and official NSA statements about its origin, public release, source-code release, contribution model, and headless operation. It does not make claims about classified systems or intelligence operations. The Fourier comparison is an editorial analogy about representation and verification, not a claim that Ghidra uses Fourier analysis.

Reverse engineering should be performed only on software and systems you are authorized to examine. Contracts, licenses, copyright rules, and local law may constrain what is permitted.

Sources

  1. About NSA/CSS
  2. Ghidra is Here
  3. Attention Ghidra Users: Full Source Code Released
  4. Ghidra Roars into World Recognition
  5. Four Years Later: The Impacts of Ghidra Public Release
  6. Ghidra README at commit 9a723ce
  7. Ghidra Contributor Guide at commit 9a723ce
  8. Ghidra Headless Analyzer README at commit 9a723ce