[hmfrh]

> 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

style project?

[boricj]

> 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.

[1] https://boricj.net/tenchu1/2024/05/31/part-11.html (which is humorously titled "A modding framework powered by the tears of CS101 teachers")

[2] https://github.com/widberg/FUELDecompilation

[hmfrh]

> 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.

[boricj]

> 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).

[1] https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html