boricj
commented
6 months ago Hi @gynt,
I've never attempted to delink C++ code before. I've given it some thoughts and did some tests on my side, here's my brain dump on this. I tried to keep this accessible without going into too many details, which is why there's a TL;DR at the end if you just want a "what would it take?" answer.
That being said, I'll preemptively answer these two questions first:
How does this program delink this?
Short answer: it's transparent to the end-user of the extension.
Long answer: the relocation synthesizer analyzer leverages symbols, references and data types present inside a Ghidra database to identify and undo relocation spots, whose work can be audited using Window > Relocation table (synthesized). Parts 7 to 10 of my series of articles on reverse-engineering break down an example by hand in a manner similar to how my extension works.
Because how would it know these came from different files?
It doesn't. You can export any subset of a program at the symbol granularity as an object file, regardless of how the program was structured initially. It's just section bytes, symbols and relocations at this point.
Put it in another way: as long as you don't cut across a variable of function, you could theoretically cut up a program into any arbitrary shape you want and this extension should generate a set of object files that, if all linked together, should produce a working program that is functionally identical to the original one.
C++ and delinking in theory
My whole delinking shtick relies on the fact that traditional linkers work on object files and are language agnostic. From their point of view, an object file built using a C++ compiler is no different than an object file built using a C compiler or the output produced by an assembler. Within that assumption, delinking C++ (or any language following the traditional compile-assemble-link toolchain flow) should be theoretically possible... but there are some ABI concerns nevertheless to keep in mind.
Symbol name mangling
C++ mangles symbol names. That's not a direct concern for delinking, but the symbol names do need to be correct for subsequent linking to work and my extension currently doesn't have any specific support for that. You could mangle the symbol names by hand inside Ghidra, but a saner option would be to add mangling options to the object file exporter. There might be some corner cases to account for (like handling export "C"), but it should be fairly straightforward to implement.
C++-specific data
While traditional linkers are blind to C++'s considerations, compilers do emit C++-specific data like RTTI or unwind tables. If you try to delink code using these features, that data must be exported alongside the rest of the object file for it to work correctly. If annotated properly, that data should be theoretically delinkable like any other piece of data (hopefully).
C++ and delinking in practice
The test case
Rather than just blindly guessing, let's put my extension to the test with a very basic C++ program, which should return 2 as its status code:
#include <stdint.h>
class A
{
public:
int32_t number = 0;
int32_t touchB();
};
class B
{
public:
int32_t number = 1;
int32_t touchA();
};
A a;
B b;
int32_t A::touchB()
{
this->number = this->number + b.number;
return this->number;
}
int32_t B::touchA()
{
this->number = this->number + a.number;
return this->number;
}
int main()
{
a.touchB();
b.touchA();
return b.number;
}I've done this exercise with both -Og and -O3:
- Build it with
i686-linux-gnu-g++with-fno-picand-no-pie(no need to add GOTs and PLTs to the mix). - Import the ELF program into Ghidra as-is, without touching up the Ghidra project in any way.
- Identify the subset of addresses that come from the object file and create a program tree to keep track of them (for convenience).
- Delink that subset into a
.delinked.oELF object file. - Link that exported object file into a
.delinked.elfELF program. - Run both
readelfandi686-linux-gnu-objdumpon every artifact for some human-readable output.
I've attached an archive with all those files for reference.
The results
- The relinked programs do work exactly like the originals.
mainhas the correct symbol name (C linkage), but bothA::touchB()andA::touchA()aren't mangled. It works out in this specific case because the object file is self-consistent.- The relocation table synthesizer analyzer failed to identify the relocations within
.eh_framefor some reason and therefore these sections were not delocated properly. ldwasn't happy with the corrupted.eh_framesections of the delinked object files:ld: error in main.O3.delinked.o(.eh_frame); no .eh_frame_hdr table will be created.
Overall there are things to fix (symbol name mangling, missed .eh_frame relocations), but it did work out on this test case. I can make the following observations:
- To the extent that C++ code is assembled into machine code, it doesn't appear significantly different than C code in this regard.
- Due to lack of symbol name mangling, C++ symbol references that cross an object file boundary will not be found by the linker.
- Due to improper delocation of
.eh_frame, I do not expect that stack unwinding will work should an exception be thrown due to the corrupted unwind tables. - No data on RTTI.
- No data on global constructors/destructors.
- Since
lddid mind the corrupted.eh_framesections, it is not strictly a traditional, C++-oblivious linker as assumed by my delinking technique.
TL;DR
It sorta works in the current state with a bunch of pitfalls. There are things I didn't test, but with some fixes/improvements I think delinking C++ code can be made to work well enough to be useable in practice.
I did assume that you want to delink C++ programs back into object files for the same toolchain/platform, so no crazy Linux-to-Windows or PlayStation-to-Linux chimeras like I do. This side-steps a whole bunch of cross-platform ABI compatibility issues that are too scary to contemplate for C++. Also, looking at your GitHub profile I can probably bet that you want to delink Windows executables built using the MSVC toolchain. You won't be able to cheat with MinGW like I did once since these two toolchains are reportedly compatible only at the C interface level.
Therefore, you'll probably need a COFF object file exporter in order to produce object files that MSVC can grok. I only have an ELF object file exporter at the moment, but my data model and analyzers should be generic enough for COFF. A prototype could probably be banged out in a week-end binge, but object file exporters are very finicky to get just right and a fairly exhaustive regresssion test suite is all but required to have any confidence in the results.
Also, I only have code analyzers for i386 and 32-bit MIPS. CISC architectures are fairly easy to analyze so adding x86_64 support should be fairly easy. RISC architectures on the other hand... Let's just say I'm at my fifth attempt for MIPS and it's still wonky.
Post-scriptum
Sorry for the huge wall of text. I've found that delinking is an esoteric topic that requires paying attention to a lot of very fine details in order to work. I've automated it down to a couple of clicks with my extension in practice, but unfortunately there are no such shortcuts available for theory.
I should probably write a book at some point because there's hardly any resources about delinking out there, let alone an authoritative source I could cite for brevity's sake. At the very least, it might make for a very scary bedtime reading for linker developers.
gynt
widberg
I am planning on using this!
I am wondering how you deal with the following scenario:
Two singleton C++ classes (A and B) reference each other's data inside functions.
In optimized compiled code, A and B may be placed next to each other in memory, and therefore the reference to b->number in machine code might look something like:
or like
How does this program delink this? I am guessing that it puts these functions in the same object file, especially in the latter example. Because how would it know these came from different files? (and therefore different obj files).
Of course I can try this out for myself, but I figure I ask before I embark down this rabbit hole! It will set my expectations