To keep things simple, source code files are compiled into object files which are linked into an executable. Object files have sections (named array of bytes), symbols (either defined as an offset within a section or undefined) and relocations (a request to patch up an offset within a section with the final address of a symbol) while executable files only have sections. The linker takes all the object files, lays out the sections in memory, fixes up the relocation and writes out an executable file without the symbols or relocations.
With Ghidra I can reverse-engineer an executable and recreate symbols, data types and references between symbols. Then, with my modifications I can recreate relocations with that information and, once a range of addresses has been fully processed, I can select it and export it as a relocatable ELF object file.
Why? This allows me to extract parts of an executable as object files and reuse these by linking them my own source code ; I don't need to fully-reverse engineer these extracted parts, I just have to basically identify every relocation there was originally in that part. I can also divide and conquer my way to decompiling an executable by splitting an executable into multiple object files and recreate its source code one object file at a time, like the Ship of Theseus.
So far it works with what I've tested it with and I've been meaning to write a series of articles to explain that process in detail, but writing quality technical articles with illustrations on a topic this esoteric is very hard.
- My Ghidra fork: https://github.com/boricj/ghidra/tree/feature/elfrelocatebleobjectexporter
- My initial prototype in Jython (has a readme): https://github.com/boricj/ghidra-unlinker