3 ms·

Show HN: A Ghidra extension that turns programs back into object files

7 points by boricj 3y ago

Hi all, I've been working on tooling that can reverse the work of a linker. It allows one to take bits and pieces of an executable and delink them into working object files, which can then be reused as-is to make new programs or libraries, without having to decompile or disassemble them first. The readme has links to my blog demonstrating some of the use-cases. The most impressive one so far is making a port of a ~100 KiB Linux a.out i386 program to a native Windows PE i386 executable, despite not having access to its original source code or even decompiling it. Currently, 32-bit i386 and MIPS instruction sets are supported, with exportation to ELF object files. Additional ISAs and object file formats can be added by writing a relocation synthesizer and an exporter, respectively.

Ace17 3y ago
> The most impressive one so far is making a port of a ~100 KiB Linux a.out i386 program to a native Windows PE i386 executable, despite not having access to its original source code or even decompiling it. This is indeed really impressive! (direct link: https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html )
- boricj 3y ago
  Thanks! I've been working on-and-off on this for the past 20 months. It's the third prototype, the first one was a set of Ghidra Jython scripts [0] and the second one was a fork of Ghidra [1]. [0] https://github.com/boricj/ghidra-unlinker-scripts [1] https://github.com/boricj/ghidra/tree/feature/elfrelocatebleobjectexporter
RBO2 3y ago
I love the idea of static recompilation. It is a promising way to make statically linked code more reusable/sustainable!
- boricj 3y ago
  My Ghidra extension doesn't perform static recompilation, the bytes that are exported are the ones from the original program (except the ones targeted by a relocation). It's similar to a raw binary exportation, except you get a relocatable object file instead. That being said, maybe it's possible to perform a delinkage and then run a static recompiler on the object file. I don't know how that would compare to running a decompiler on the object file.

7 points by boricj 3y ago

Ace17 3y ago

> The most impressive one so far is making a port of a ~100 KiB Linux a.out i386 program to a native Windows PE i386 executable, despite not having access to its original source code or even decompiling it. This is indeed really impressive! (direct link: https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html )

boricj 3y ago
Thanks! I've been working on-and-off on this for the past 20 months. It's the third prototype, the first one was a set of Ghidra Jython scripts [0] and the second one was a fork of Ghidra [1]. [0] https://github.com/boricj/ghidra-unlinker-scripts [1] https://github.com/boricj/ghidra/tree/feature/elfrelocatebleobjectexporter

RBO2 3y ago

I love the idea of static recompilation. It is a promising way to make statically linked code more reusable/sustainable!

boricj 3y ago
My Ghidra extension doesn't perform static recompilation, the bytes that are exported are the ones from the original program (except the ones targeted by a relocation). It's similar to a raw binary exportation, except you get a relocatable object file instead. That being said, maybe it's possible to perform a delinkage and then run a static recompiler on the object file. I don't know how that would compare to running a decompiler on the object file.