7 ms·

Over the past two years I've been working on tooling that allows me to delink programs back into object files. What started out as a bunch of Jython scripts is

by boricj 2y ago

Over the past two years I've been working on tooling that allows me to delink programs back into object files. What started out as a bunch of Jython scripts is nowadays a full-blown Ghidra extension that can export working object files from a program selection in two mouse clicks. I'm using it as part of a video game decompilation project, but it also enables a whole bunch of other use cases I've documented on my blog. It's not that it is meant for my use only (any capable reverse-engineer familiar with Ghidra should be able to pick it up and use it) nor that it will never see the light of the day (it's open-source). However, it is such an esoteric capability and outright heresy according to computer sciences that I'm having a hard time just finding people who can wrap their heads around the concept, let alone people who would actually want to use this. Simply put, it's so far out there that I don't even know where or how I could even advertise it in the first place, which makes it de facto for my own use only. A couple of people did end up reaching out to me in the last couple of weeks about it, so it might be on the cusp of sprouting a very tiny user base. Still, I've made it for my own use and until very recently I've never expected anybody else would use it. If someone wants to check out the dark magic: https://github.com/boricj/ghidra-delinker-extension https://github.com/boricj/ghidra-delinker-extension (disclaimer: might give nightmares to linker developers).

vintagedave 2y ago
I know a linker developer, I'm going to send this to him :) Not sure about heresy according to computer science. Sure, it's not intended, but it's a very clever thing to be able to do.
- boricj 2y ago
  Delinking by itself isn't a heresy (no more than disassembly or decompilation), but what I do with it definitively is. Ripping out MIPS code from a PlayStation video game and shoving it into a Linux program, dismembering a x86 Linux program and turning it into a native Windows program... It's when you get creative and throw ABIs out the window in order to create some cursed chimeras that this really becomes heresy.
  - nrr 2y ago
    One person's heresy is another person's sickos.png. This sounds exactly like my favorite sort of object code vivisection.
- liamYC 2y ago
  Technology like this will create huge selection pressures against desktop apps if it becomes easy for people to reverse engineer, remove payment mechanisms, and then freely distribute. Wouldn’t you think?
  - pmontra 2y ago
    Freely redistribute, I don't know. If a program can extract code from another one, a program can detect that code. It looks similar to virus signatures. A company with some IP would run the detector on the software of competitors.
  - boricj 2y ago
    Delinking isn't a miracle technology in that regard, you still need to put in the work to reverse-engineer the artifact. It does allow a couple of nifty tricks, like pervasive binary patching (if the program is chunked into relocatable object files, then you're no longer constrained by the original program memory layout when patching/replacing stuff). It's also useful for decompilation projects, where you can reimplement a program one piece at a time until you no longer have binary pieces left and still create a fully working program at each step (you don't even need perfectly matching decompilation since the linker will mend stuff back together anyway).
  - fragmede 2y ago
    The tools and know-how to remove payment mechanisms from binaries have existed basically as long as binaries themselves have.
jart 2y ago
Something like that really deserves to be written in C so you don't need to install Ghidra to use it. The way I imagine it working is if I want the function `foo` then I'd say `objsuck -ffoo -ofoo.o prog.elf` and it'd look at the elf symbol table to find the `.size` of `foo` and copy that symbol into the .o. I guess you would then need to use xed to disassemble the opcodes to see what other symbols it jumps into or calls, and grab those too, along with any memory references, and then emit relocations. Overall I support this, since it'd be the easiest way to expropriate content from open source codebases whose source code is too byzantine to let me extract one teensy tiny little feature without the bloat. To me this is perfectly normal. You'd also be smart to only support COFF if the person uploads the binary to a hosted service you control and pays you money. In fact this would be even better if it could generate .s files from the object content, so no one would get triggered by binaries.
- cxr 2y ago
  > Something like that really deserves to be written in C so you don't need to install Ghidra to use it. By that logic, it should be written in JS so you don't need to install a C build toolchain for it.
- boricj 2y ago
  > Something like that really deserves to be written in C so you don't need to install Ghidra to use it. I think there's the Witchcraft Compiler Collection if you want a freestanding option [1], although I haven't looked into it too closely. The problem is that object files are made up of section bytes, a symbol table and a relocation table. You can't just rip bytes out of a program and call it a day, you need to recreate all that information in order to actually delink code into relocatable object files. Doing that isn't a trivial problem, it requires a lot of analysis and metadata, especially if you don't have debugging symbols or symbols at all. Leveraging Ghidra allows me to concentrate on the specifics of delinking, which can get very tricky depending on the platform (MIPS in particular is a nightmare to deal with). I'm also trying to solve delinking in general and not just for one platform/ISA pair, so reinventing the wheel for every architecture out there is a nonstarter in that context. [1] https://github.com/endrazine/wcc https://github.com/endrazine/wcc

by boricj 2y ago

vintagedave 2y ago

I know a linker developer, I'm going to send this to him :) Not sure about heresy according to computer science. Sure, it's not intended, but it's a very clever thing to be able to do.

boricj 2y ago
Delinking by itself isn't a heresy (no more than disassembly or decompilation), but what I do with it definitively is. Ripping out MIPS code from a PlayStation video game and shoving it into a Linux program, dismembering a x86 Linux program and turning it into a native Windows program... It's when you get creative and throw ABIs out the window in order to create some cursed chimeras that this really becomes heresy.
- nrr 2y ago
  One person's heresy is another person's sickos.png. This sounds exactly like my favorite sort of object code vivisection.
liamYC 2y ago
Technology like this will create huge selection pressures against desktop apps if it becomes easy for people to reverse engineer, remove payment mechanisms, and then freely distribute. Wouldn’t you think?
- pmontra 2y ago
  Freely redistribute, I don't know. If a program can extract code from another one, a program can detect that code. It looks similar to virus signatures. A company with some IP would run the detector on the software of competitors.
- boricj 2y ago
  Delinking isn't a miracle technology in that regard, you still need to put in the work to reverse-engineer the artifact. It does allow a couple of nifty tricks, like pervasive binary patching (if the program is chunked into relocatable object files, then you're no longer constrained by the original program memory layout when patching/replacing stuff). It's also useful for decompilation projects, where you can reimplement a program one piece at a time until you no longer have binary pieces left and still create a fully working program at each step (you don't even need perfectly matching decompilation since the linker will mend stuff back together anyway).
- fragmede 2y ago
  The tools and know-how to remove payment mechanisms from binaries have existed basically as long as binaries themselves have.

jart 2y ago

Something like that really deserves to be written in C so you don't need to install Ghidra to use it. The way I imagine it working is if I want the function `foo` then I'd say `objsuck -ffoo -ofoo.o prog.elf` and it'd look at the elf symbol table to find the `.size` of `foo` and copy that symbol into the .o. I guess you would then need to use xed to disassemble the opcodes to see what other symbols it jumps into or calls, and grab those too, along with any memory references, and then emit relocations. Overall I support this, since it'd be the easiest way to expropriate content from open source codebases whose source code is too byzantine to let me extract one teensy tiny little feature without the bloat. To me this is perfectly normal. You'd also be smart to only support COFF if the person uploads the binary to a hosted service you control and pays you money. In fact this would be even better if it could generate .s files from the object content, so no one would get triggered by binaries.

cxr 2y ago
> Something like that really deserves to be written in C so you don't need to install Ghidra to use it. By that logic, it should be written in JS so you don't need to install a C build toolchain for it.
boricj 2y ago
> Something like that really deserves to be written in C so you don't need to install Ghidra to use it. I think there's the Witchcraft Compiler Collection if you want a freestanding option [1], although I haven't looked into it too closely. The problem is that object files are made up of section bytes, a symbol table and a relocation table. You can't just rip bytes out of a program and call it a day, you need to recreate all that information in order to actually delink code into relocatable object files. Doing that isn't a trivial problem, it requires a lot of analysis and metadata, especially if you don't have debugging symbols or symbols at all. Leveraging Ghidra allows me to concentrate on the specifics of delinking, which can get very tricky depending on the platform (MIPS in particular is a nightmare to deal with). I'm also trying to solve delinking in general and not just for one platform/ISA pair, so reinventing the wheel for every architecture out there is a nonstarter in that context. [1] https://github.com/endrazine/wcc https://github.com/endrazine/wcc