This project was something that I had in the back of my head for a long time.
I'm analyzing golang malware for my dayjob most of the time and I was annoyed by the typical decompiler pipelines that always try to generate Pseudo C code instead of reusing the information of known symbols to try to reconstruct the actual source code in the actual language it was written in.
So I'm using ImHex a LOT because it's by far the best hex editor out there, and it uses a (custom) pattern description language which is really useful for container formats, binary formats, and finding things that "come after known byte headers". The pattern descriptors are useful because they can replace binwalk and similar tools if you know how to write the patterns for the file formats you're looking for.
Coming back to Go binaries: A lot of times the assembled binaries still contain useful symbol names or strings that you can use to reconstruct what the source code looked like, but most decompilers don't care about intelligent symbol matching, and they always focus on pure disassembly workflows which are kind of useless for any binary that's been compiled by a VM based programming language.
This decompiler tries to use pattern matching to reconstruct things that are part of the stdlib in Go. Theoretically, you can extend this pattern database with whatever standard libraries are the most common ones out there to get better results (gin, gorilla, etc?).
I have no idea about other VM based binaries like C#, but if there's a runtime-specific header in that binary, and if the symbol names aren't obfuscated, this project could be ported to those languages, too.
However, this is a prototype that's been written with a lot of LLM assistance.
I would have never had the months of time needed to just write those thousands of demo code programs, debug the headers in the symbol/hash tables, find out how the Plan9/Go assembler looks like, and then add the pattern matchers and end to end unit tests for those.
Thought I'd share this approach, might be useful for a lot of other VM-based languages that have their own stdlibs. For the next couple weeks I'm probably going to refactor this, and try to find more efficient ways to lookup/replace known matching symbols.
cookiengineer•4h ago
I'm analyzing golang malware for my dayjob most of the time and I was annoyed by the typical decompiler pipelines that always try to generate Pseudo C code instead of reusing the information of known symbols to try to reconstruct the actual source code in the actual language it was written in.
So I'm using ImHex a LOT because it's by far the best hex editor out there, and it uses a (custom) pattern description language which is really useful for container formats, binary formats, and finding things that "come after known byte headers". The pattern descriptors are useful because they can replace binwalk and similar tools if you know how to write the patterns for the file formats you're looking for.
Coming back to Go binaries: A lot of times the assembled binaries still contain useful symbol names or strings that you can use to reconstruct what the source code looked like, but most decompilers don't care about intelligent symbol matching, and they always focus on pure disassembly workflows which are kind of useless for any binary that's been compiled by a VM based programming language.
This decompiler tries to use pattern matching to reconstruct things that are part of the stdlib in Go. Theoretically, you can extend this pattern database with whatever standard libraries are the most common ones out there to get better results (gin, gorilla, etc?).
I have no idea about other VM based binaries like C#, but if there's a runtime-specific header in that binary, and if the symbol names aren't obfuscated, this project could be ported to those languages, too.
However, this is a prototype that's been written with a lot of LLM assistance.
I would have never had the months of time needed to just write those thousands of demo code programs, debug the headers in the symbol/hash tables, find out how the Plan9/Go assembler looks like, and then add the pattern matchers and end to end unit tests for those.
Thought I'd share this approach, might be useful for a lot of other VM-based languages that have their own stdlibs. For the next couple weeks I'm probably going to refactor this, and try to find more efficient ways to lookup/replace known matching symbols.