When Analysis Becomes a Shared Artifact
Ghidra's shared workflows ask a harder question than “Can another analyst open this project?” They ask whether an interpretation can move between programs and people without losing the evidence that supports it. This chapter focuses on Version Tracking, shared projects, and Ghidra Server: how candidate markup is generated and reviewed, how local copies synchronize through a repository, and which identity, storage, memory, backup, and compatibility conditions protect the shared analytical artifact.
A match is a controlled transfer, not a copy operation
Version Tracking begins with a source program and a destination program. The source contains markup that an analyst wants to carry forward; the destination is usually a newer or otherwise related program where that context may still be useful. The tool can match functions and data using multiple correlators, keep the state of each proposed match, show differences, and apply accepted markup. That sounds like copying until the preconditions are considered.
The two programs need enough structural comparability for a match to mean something. Ghidra's training material calls attention to similar memory maps, mostly correct disassembly, correctly defined functions, compatible calling conventions, and the absence of unresolved flow problems. If one program has been analyzed more completely than the other, a missing function may look like a removed function. If a memory map changed, an address-based relationship may no longer describe the same object. If a function boundary is wrong, a correlator may compare the wrong bodies while still returning a candidate.
Version Tracking therefore begins with readiness checks rather than optimistic transfer. Validators report issues such as errors, analysis coverage, memory-map similarity, function counts, non-returning functions, and off-cut references. These checks do not prove that the programs are equivalent or that a candidate match is correct. They tell the analyst whether the input models are prepared well enough for the correlators to produce useful evidence.
A correlator produces a candidate relationship, not a final decision. Different correlators can use exact or similar data, symbol names, function properties, or references from matches already accepted. Their value is that they reduce the search space and expose plausible relationships. The analyst still needs to inspect the match, compare the source and destination views, and decide whether the proposed markup fits the destination's instructions and data flow.
The tool's match table and stored match state make that review explicit. A candidate can remain available, be accepted, rejected, or revisited as the session develops. Markup can then be applied selectively rather than transferred as an undifferentiated block. This matters because a name, type, or function definition can be useful in one program and misleading in another. The transfer is valuable precisely because it is reviewable.
The source/destination distinction also protects against a subtle error in language. The source is not automatically the older program in every possible investigation, and the destination is not automatically a blank copy waiting to receive everything. They are roles in a comparison: one program supplies the markup under consideration, and the other is the program in which the analyst evaluates its fit. Keeping those roles explicit prevents a match score or a convenient address correspondence from becoming a claim about historical identity.