How much work is it to figure out which sections of the executable to export?
Would it be realistic to be able to export a modern-ish (2008-2015) Win32 game into objects and then compile/link it into a full executable again with less than a few hours work?
> How much work is it to figure out which sections of the executable to export?
As long as you do not cut across a variable or a function, you can export pretty much however you want, you don't have to follow the original object file boundaries. What to export is a separate matter and requires some knowledge about the program. Having debugging symbols makes this much easier, otherwise by the time you've made the Ghidra database accurate enough for exportation you'll usually have an idea of where's what.
> Would it be realistic to be able to export a modern-ish (2008-2015) Win32 game into objects and then compile/link it into a full executable again with less than a few hours work?
About the user report in my submission, they first raised an issue in early July and by mid-August they got a fully working, functionally identical relinked executable. To be fair, the COFF exporter had a lot of bugs that needed to be fixed and the i386 analyzer needed some touch-ups, things that somebody else should hopefully won't stumble over now.
I don't know how long it would take, but unless you have debugging symbols and are really lucky it will take more than a few hours of work. A skilled reverse-engineer can probably manage to get something executing in that timeframe (even if it crashes halfway during the first loading screen), but it's one of these tasks that you won't know when it will be done until it is done.
> As long as you do not cut across a variable or a function, you can export pretty much however you want, you don't have to follow the original object file boundaries.
Would it be possible to export basically the entire program at once and then slice off individual functions one by one?
Do you have any guides/examples of the
> Decompilation projects, by splitting a program into multiple object files and reimplementing these Ship of Theseus-style
> Would it be possible to export basically the entire program at once and then slice off individual functions one by one?
Yes. The exporters can handle whatever meaningful address selection you can throw at them, including multiple disjoint ranges within the same section. So you can keep carving holes inside your selection until nothing remains of the original program.
> Do you have any guides/examples of the Ship of Theseus-style style project?
Not quite. My own decompilation project is on a hiatus due to one version tracking session too many in a row, so I only have one article on this so far [1] and the way I've done it is a bit wonky.
Another user has recently started a decompilation project [2] with a better framework than I've used in that article, but no actual decompilation has taken place there yet. Incidentally, that would also make for a good modding framework, if one decides to not write functionally identical replacement code.
> Yes. The exporters can handle whatever meaningful address selection you can throw at them, including multiple disjoint ranges within the same section. So you can keep carving holes inside your selection until nothing remains of the original program.
Will this also work without painstakingly reversing things in the binary, say in the case of a giant game executable?
If possible, I would be very interested in a simple tutorial that takes an arbitrary Windows executable, delinks it and replaces a single function, without all the extra steps necessary to run it on the PS1.
It might even be preferable if it worked with MingW, since I'm on Linux as well.
> Will this also work without painstakingly reversing things in the binary, say in the case of a giant game executable?
You can get away with a Ghidra database that isn't accurate, as long as you know what you're doing. Basically, as long as the analyzers manage to identify all of the relocation spots inside your exportation, the rest doesn't matter that much. You can even get away with missing relocation spots inside your exportation, if you don't end up executing that code or accessing that data at run-time (if you do, then exotic undefined behavior ensues).
The most important thing here is getting references right and addresses typed as pointers (the type itself doesn't matter). I'm not going to discuss this into more details than that, because it would require a deep understanding of the internal algorithms of the extension. Any shortfall between a less-than-accurate Ghidra database and experience will be filled in by luck.
> If possible, I would be very interested in a simple tutorial that takes an arbitrary Windows executable, delinks it and replaces a single function, without all the extra steps necessary to run it on the PS1.
It's essentially the same steps regardless of the platform. Select the bits you want in your object file, run the analyzer, invoke the exporter, use the linker to create a new program.
I've made my Ghidra extension as user-friendly as possible, the rest is standard native development stuff (up to the point where you hit exotic undefined behavior and can't figure it out at a glance, hopefully you're well acquainted with your debugger if that happens).
> It might even be preferable if it worked with MingW, since I'm on Linux as well.
Actually, I've created a native port of a proprietary, statically-linked, Linux a.out i386 to Windows with MinGW [1] using my delinker. It was back when I didn't have a COFF object file exporter either, so it was the only toolchain for that target that could ingest ELF object files.
That being said, MinGW and MSVC are reportedly only compatible at the C ABI level. Mixing and matching different toolchains can increase the odds of something going wrong, so you're probably better off using the toolchain that the program was originally built with (hopefully it runs on Wine).
PS: remember that you are throwing your CS 101 handbook into the trashbin when you're using a delinker (and its teacher is unlikely to be of much help).
Would it be realistic to be able to export a modern-ish (2008-2015) Win32 game into objects and then compile/link it into a full executable again with less than a few hours work?