ghidra-delinker-extension turns an analyzed program back into object files

The linker is the missing half of a disassembled program

A program that has been through a linker has had its relocation table thrown away. The README lays out the anatomy plainly: object files are made of relocatable section bytes, a symbol table and a relocation table, and when a linker builds an executable from them it lays out the sections in memory, computes the addresses of symbols in the virtual address space, and applies the relocations based on the final addresses of the symbols onto the section bytes. Afterwards, the relocation table is discarded, and the symbol table too if debugging symbols are not kept. What is left is un-relocatable bytes.

That is why a disassembled program cannot simply be edited and reassembled. Every absolute address baked into the code is meaningless once the code moves.

This extension recreates the discarded half. It exports parts of a Ghidra program as object files with valid metadata, symbols and relocation tables, which the documentation says means they can be reused directly by a toolchain for further processing. In other words, it turns a flat binary back into something a linker understands, which is the whole trick. The stated use cases follow from that: advanced binary patching where the linker mends the original and modified parts together instead of a human doing it by hand, software ports where system independent code is isolated and the rest replaced, converting programs or object files from one file format to another, creating libraries by extracting parts for reuse in another context, and decompilation projects where a program is split into multiple object files and reimplemented piece by piece.

The relocation table synthesizer is the analyzer that does the work

The extension is really two pieces that must be used in order. The first is an analyzer called the relocation table synthesizer, which reconstructs the relocation information inside a Ghidra database. The second is a set of exporters that consume those results and write object files out.

The usage flow follows directly. You select a set of addresses in the Listing view to extract, run the relocation table synthesizer analyzer (available in one-shot mode), and then invoke a relocatable object file exporter through File > Export Program. The reconstructed relocations can then be inspected in a dedicated Window > Relocation table (synthesized) view, which is the practical way to check that the analyzer found what you expected before you trust the export.

The analyzer has options of its own, reachable from the Analysis > Auto Analyze... dialog, where an Evaluation report policy setting enables detailed evaluation reports. That report is how you find out which references were resolved and which were not.

One thing the documentation is explicit about: you do not need to reverse engineer the entire program before using the extension. What matters is the metadata inside the subset you are exporting and around its external references, namely functions and pointers acting as relocation locations, symbol footprints acting as relocation targets, and the references between the two. Analyse the region you care about and the references it makes, and the rest of the binary can stay unexplored.

Building the extension needs a Ghidra path and a Gradle step

The build is a Gradle build driven from the command line. The documented sequence is to clone the repository, point an environment variable at the Ghidra installation, and run the Gradle task, after which the extension archive appears inside the dist directory:

 * Run `gradle buildExtension`.

The dependency story is where a first build can stop. The note in the documentation says GitHub Maven repositories require authentication to download packages, and gives two ways out: create a GitHub classic token with the read:packages right and add it to the Gradle properties file, or build and install vendored dependencies from submodules:

> * Create a GitHub classic token with the `read:packages` right, then add `githubToken=ghp_xxx` to `${GRADLE_USER_HOME}/gradle.properties` (usually defaults to `~/.gradle/gradle.properties`).
> * Run `gradle installStandaloneDeps` to build and install vendored dependencies from submodules.

The repository layout backs that up, with a standalone directory alongside src, ghidra_scripts, developer_scripts and a build.gradle at the root, plus submodules pulled in through .gitmodules. The gradle.properties approach means a token sits in a file on your machine, so the vendored submodules path is the one to prefer on a shared or build machine.

Two plugin steps are needed before the exporter appears

Installing the extension is separate from enabling the feature, and the documentation treats them as two steps because the analyzer lives behind an experimental flag. You download the extension from the releases page or build it locally, install it in your Ghidra instance through File > Install Extensions..., and then enable the RelocationTableSynthesizedPlugin with File > Configure > Experimental inside a CodeBrowser window.

The Experimental designation is a real caveat for anyone planning a workflow around this. A plugin hidden behind that flag in Ghidra is by definition not covered by the same stability expectations as the core tool, and the extension's own release history suggests a fast moving project where the plugin name or the analyzer's location may change between versions. v0.9.2 came on 2026-09-26, v0.9.1 on 2026-06-24 and v0.9.0 on 2026-05-15.

The counterpoint is that the design is unusually careful about staleness. The documentation carries a caution that the object file exporters rely on the results of the relocation table synthesizer analyzer, and that when in doubt you should run the analyzer right before exporting an object file to make sure the relocation table contents are up to date. That is the opposite of how most Ghidra workflows are treated, where analysis is assumed to be done once.

The supported architecture and format matrix is small and explicit

The README publishes a matrix of supported instruction set architectures against object file formats, and it is worth reading before you plan a port. ELF is covered for x86, x86_64 and MIPS. COFF is covered for x86 and x86_64, so Windows targets are supported for those two. OMF, the older sixteen bit object format, is covered for x86 only, and x86_64 is explicitly not covered there.

ELF being the one combination covered across all three architectures is not a coincidence, given that ELF is the format most of the reverse engineering world deals in.

Anything outside that matrix is simply not implemented, and the practical consequence is that a delinking workflow is available for a fairly narrow set of targets. The project marks each cell of its table with a symbol, and the meaning is unambiguous: a mark means the exporter exists and the opposite mark means it does not.

For the porting use case, which is arguably the most interesting one, that means a program can be split into system independent code and the rest replaced, but only when the architecture and target format fall inside those rows. A port from an ELF x86_64 target to a COFF x86_64 target is inside the matrix. A port to OMF from x86_64 is not, and no amount of analysis in Ghidra will produce that exporter.

The failure mode is the same as the input: the Ghidra database

The documentation carries a warning that deserves to be read as the project's main caveat: the relocation table synthesizer analyzer relies on the accuracy of the Ghidra database, and incorrect or missing information may lead to broken or missed relocations during the analysis.

That is a different kind of warning from the usual one about a tool crashing. Nothing here throws an error you can catch. The analyzer produces a relocation table that looks reasonable, the exporter writes an object file, the linker consumes it, and the resulting binary is wrong in a way that is tedious to trace because the link succeeded. The quality of the output is bounded by the quality of the analysis that produced the database, and there is no validation step in between that catches a missing symbol footprint.

This is what makes the recommended workflow sensible. You do not need to reverse engineer everything, but you do need the exported subset and its external references to be right, and the practical way to establish that is the synthesized relocation table window and the evaluation report from the analyzer, both of which exist so you can inspect the reconstruction before you export anything.

There is a second structural limit worth naming. This extension works on a program you have already loaded and analyzed in Ghidra. It does not parse object files for you. The format conversion use case means converting a program or an object file from one file format to another, but the entry point is the Ghidra database, not the file on disk.

What the extension is for, in practice

The clearest way to judge this tool is to ask what it replaces. Hand patching a binary means computing addresses by hand, writing bytes at the right offsets, and repeating the whole calculation every time the file layout shifts. The extension moves that work into the linker, which is the tool already designed to lay out sections and resolve symbol addresses. The claim that the exported object files can be reused directly by a toolchain for further processing is the claim that the linker can now do its job on code that came out of a binary.

The same reasoning covers the library use case. Extracting a function into an object file and linking it into a new context is only possible if the references leaving that function are described as relocations, which is exactly what the synthesizer tries to recover.

And the decompilation use case, splitting a program into multiple object files and reimplementing them in the style of a Ship of Theseus, only works if each extracted piece carries its own relocation and symbol metadata rather than a flat blob of bytes.

On the licensing and cost side, the repository is licensed Apache-2.0, which permits reuse and modification of the extension itself. What it does not change is the licensing status of the binaries you run it against, and the effort of the reverse engineering itself remains entirely on the person doing it. The last push was on 2026-09-26, and the default branch is master.

Editorial conclusion

ghidra-delinker-extension fits reverse engineers who need to lift a function out of a stripped binary and hand it to a real toolchain, or who want to patch a binary by reassembling two versions through the linker rather than by hand. It is the wrong tool when the region you want to export was never analyzed in Ghidra, because the relocation synthesizer can only reconstruct what the database already knows, and it is the wrong tool for architecture and format combinations outside the supported matrix, where the exporters simply are not present. Before relying on an exported object file, check the three things the documentation names: that functions and pointers inside the exported subset are marked as relocation locations, that symbol footprints exist for the external references, and that the relocation table synthesizer analyzer was run again immediately before the export, since a stale table is the documented cause of broken relocations. The project is licensed Apache-2.0 and the last push was on 2026-09-26, with v0.9.2 released the same day.

Frequently asked questions

Official sources

1. boricj/ghidra-delinker-extension on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases