Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The only unusual part about my toolkit is the delinker. Since it outputs relocatable object files, you can then make use of them with conventional tooling.

I've mostly used a linker to build new programs with the parts I've exported. Some of my users use objdiff to compare the output of their decompilation efforts against recreated object files. Others use objcopy or homemade tools to further modify the object files (mostly tweaking the symbol table) prior to reuse. One can generate assembly listings with objdump, although Ghidra already gives you that.

Ironically, the hardest part about using my delinker I think (besides figuring out errors when things go wrong) is just realizing and imagining what you can do with it. It's rather counter-intuitive at first because this goes against anything one might learn in CS 101, but once you get it then you can do all kinds of heretical things with it.

To take this to the next level, beyond adding support for more ISAs and object file exporters, I'd need to generate debugging symbols in order to make debugging the pilfered code a less painful experience. There are plenty of ways delinking can go wrong if the Ghidra database is incorrect or incomplete and troubleshooting undefined behavior from outer space can get tedious.

But in the context of a post-collapse scenario, what one would be really after is some kind of linker that can stitch together a working program from just about any random bunch of object files, regardless of ABI and ISA. My experiments on cross-delinking remained rather tame (same ISA, similar ABI) because gluing all that mess by hand gets really complicated really fast.



Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: