wcc

wcc can do that for you: https://github.com/endrazine/wcc

While objcopy can do many things, it can't undo the work of the linker. If relocations aren't unapplied and a new relocation table generated, these spots inside the new object file will reference the original program's address space, leading to some exotic undefined behavior. Delinking is a subject with very few resources online, but there are a couple of other tools for it out there: - https://github.com/endrazine/wcc - https://github.com/jonwil/unlinkerida - https://github.com/jnider/delinker

> 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

rundll32.exe is just a way of doing FFI from as a command -- there are few different options on UNIX-likr systems for that. The most obvious is ctypes.sh [0]. There are, though, even more sophisticated options than just FFI, like the Witchcraft Compiler Collection [1], which includes among other things an interactive shell. [0] https://github.com/taviso/ctypes.sh [1] https://github.com/endrazine/wcc

Yeah, seriously. This sounds great. Also, if you found exodus interesting, you may find the following interesting too. https://github.com/endrazine/wcc

If you like this, you might also like the Witchcraft Compiler Collection[1] by Jonathan Brossard. It approaches from a different angle (relinking), but (as far as I understand it) can help to solve the same problem Tavis tackles. In the end they both allow the dynamic analysis of PE files in Linux. Both tools only work if the architecture is the same in both worlds, I think. EDIT: [2] is an intro to the Witchcraft Compiler Collection from Black Hat Europe 2016 which is probably more helpful than the link to the repo. [1] https://github.com/endrazine/wcc/blob/master/README.md [2] https://www.blackhat.com/docs/eu-16/materials/eu-16-Brossard...

You're too optimistic about what it can do, here's a sample output: https://github.com/endrazine/wcc/wiki/wcch This is not what I'd call an "API dump"; all prototypes return void pointers and allow any arguments. Hence, it's just as much of a blackbox as the original executable is because you have no idea what the functions do, what arguments they take and what values they return.

I wonder how many folks are aware that ELF shared libraries and ELF executables are the exact same thing? There's no substantial compiling or decompiling necessary to go from shared object to executable and back. One need only add or remove the appropriate symbols from the object and (perhaps even optionally) change the object type. Have you ever tried to directly execute your libc.so.6 on a linux system? You can. There's nothing at all novel about this process, other than making it easy for folks who've never read the manual for their linker. Edit: Someone downvoted this observation; I imagine they think I'm unfairly trivializing this so I'll add: Read the source code. This tool we're discussing is a simple ~100 line program. It's not complicated: https://github.com/endrazine/wcc/blob/master/src/wld/wld.c

He is just missing the new witchcraft compiler wcc, which can unlink exes into shared libs, load those libs into your exe and inspect any function or variable. And then link it back into an exe. https://github.com/endrazine/wcc