boricj
commented
2 months ago Ooh neat!
Interestingly, with some careful delinking, I can take a program compiled by MSVC for Windows, delink it to ELF and relink it with glibc to make it run on Linux, and delink it to COFF and relink it with MinGW to make it run on Windows again. 🤯
Yeah, delinking tends to do that to one's mind. I don't know what it would do to a CS101 teacher's mind, but I expect either some pretty fireworks or a one-way trip to a psychiatric hospital.
Feel free to leave a lot of comments. I can try to address comments, though I may take a bit depending on how busy I am. Not sure if you want to merge this upstream but I'm eager to get delinking into the world of Windows reverse engineering as it seems extremely promising for a wide variety of reverse engineering tasks.
I definitely want to merge this once it's ready. I expected that object file formats and ISAs to be mostly orthogonal, which is why I went for exporting object files rather than assembly when designing my tooling. This PR proves my theory.
Overall the code itself looks fairly good for a first draft. I'll add code comments later today, but I have some general observations:
- I'm using conventional commits to generate release notes automatically with Git Changelog. The COFF exporter code should be in a commit titled
feat(COFF): relocatable object file exporter, similar to this one. - I try to keep commits self-contained and the history clean, so code moved from the ELF exporter to
src/main/java/ghidra/app/util/should be separated into multiplerefactor: move xxx class out of ElfRelocatableObjectExportercommits. Similarly, the COFF x86 relocation mapper should be in its own commit, like this one and this one. Ideally, the commit adding the COFF exporter should only contain the COFF exporter itself and no other changes. - I'd like to have some COFF tests to ensure some level of regression testing. I found out that it's way too easy to silently break the delinker in non-obvious ways when making changes, so this is the only way I've found to stop my Ghidra extension from collapsing on itself.
- I have CICD running on this repository and the PR needs to pass it successfully in order to merge it.
I can deal with these issues myself if you need (and in particular I'll handle the tests myself, I need to make some adjustments to the test harness to support COFF anyways). This is the first ever non-trivial PR I'm receiving on one of my repositories, so this is kind of uncharted territory for me. I'll try to make the process as smooth as possible.
Some notes:
- Only tested for i386; would love to make sure at least AMD64 and AArch64 work. If I could track down old WinNT ports to other architectures, I could try to get some of those working, too.
- Not tested with UNIX COFF. I don't have a toolchain to try it with. I think it is very plausible that we could make this exporter work for other COFF variants.
- I exported out some code that seemed sharable between different exporters. I'm not sure if I put them in good places. I am not a Java programmer :)
- I expect that adding x86_64 would be easy since I already have a x86 relocation synthesizer and CISC ISAs are easy to analyze. RISC ISAs are trickier because the lack of pointer-sized immediate constants requires building them out of multiple instructions (
HI16/LO16). Branch delay slots are a nightmare to deal with, but I've pulled it off with MIPS. I don't know about EPIC or VLIW ISAs, so who knows what pitfalls lurk inside Itanium... - One COFF variant that might be interesting to look into would be DJGCC, used to build programs that run on top of MS-DOS extenders (it's not a requirement at all for this PR). I don't know enough about the other COFF variants to have an opinion on them.
- There's probably more code that can be shared, but it's one of those things that are obvious only in hindsight. So far I've mostly worried about supporting multiple ISAs than multiple object file formats. At any rate, I can deal with that at a later time.
jchv
gynt
About a month ago you mentioned on Hacker News that adding COFF support should be easy and fairly self-contained. You were right.
This is an implementation of the delinker exporter that outputs the Microsoft COFF format. It's still very rough around the edges but I was able to use it to successfully delink and relink an i386 Windows executable. Interestingly, with some careful delinking, I can take a program compiled by MSVC for Windows, delink it to ELF and relink it with glibc to make it run on Linux, and delink it to COFF and relink it with MinGW to make it run on Windows again. 🤯
Feel free to leave a lot of comments. I can try to address comments, though I may take a bit depending on how busy I am. Not sure if you want to merge this upstream but I'm eager to get delinking into the world of Windows reverse engineering as it seems extremely promising for a wide variety of reverse engineering tasks.
Some notes: