3 ms·
That assumes you have a source tree to build. Decompilation output generally is meant for human consumption and is not suitable for a compiler without significa
by boricj 2y ago
That assumes you have a source tree to build. Decompilation output generally is meant for human consumption and is not suitable for a compiler without significant rework and carrying out a full decompilation project (even a non-matching one) is a lot of work.
This is why traditional binary patching is the usual go-to option, because it doesn't require much upfront effort to perform. The downside is that you're constrained by the memory map of the original program and contorting your modifications to fit can be a huge pain.
There are alternative, less widely known techniques out there with different tradeoffs. For example, if you can make the original program bytes relocatable then you can run those through a linker and let it mend both original and new parts together. I've built tooling to help do that specifically (delinking programs back to object files [1]), it's faster than a decompilation project because you merely need to figure out and undo all the relocation spots, but you don't get source code at the end.
[1] https://github.com/boricj/ghidra-delinker-extension https://github.com/boricj/ghidra-delinker-extension