Question / discussion about the future of Boomerang
ceeac opened this issue · comments
Hello,
I'm opening this issue here since this still seems to be the most popular Boomerang repository.
For the past months I have been refactoring/writing tests/fixing bugs in my fork of Boomerang here (Changelog). This is still a work in progress, however I would like to spark a discussion on how to best revive the project.
I would be happy to merge my changes back to this repository; I can make a PR if that is the outcome of this discussion.
What are your opinions on this matter?
Nice list of changes, it would be good to see this revived again
Agreed, it would be awesome if the boomerang was revived.
Question is, what would be the project's direction, since there are a few active decompiler projects now ?
https://github.com/avast-tl/retdec - restricted to a small set of 32 bit architectures.
https://github.com/uxmal/reko
The problem with RetDec is that it suffers from serious memory allocation issues; I was unable to decompile anything serious without it exhausing all of my RAM and swap (>200 GB).
For Reko, it did not even properly decompile most of the x86 samples Boomerang ships with when I tried it; same for SmartDec/Snowman.
My point is that currently no generally available decompiler (except maybe IDA, I don't have access to it, though) I tried, including Boomerang, is issue-free when it comes to automatic decompilation or even human-assisted decompilation (not that I expected no issues when tackling such a hard problem as machine code decompilation).
So Boomerang is not so much behind the times as one would think given there has not been a proper release in more than ten years.
What I am planning to do now (in chronological order):
- Fix remaining issues with the SPARC decoder/frontend (I mentioned them in ceeac#1)
- Fix any remaining small issues that creep up
- Release 0.4.0
- Finish the Capstone x86 decoder (in the
capstonebranch) and replace the other decoders by Capstone-based decoders - Replace the old parsers. There is already an implementation for an SSL parser based on flexc++/bisonc++ in the
parsersbranch, but I'm likely going to abandon it, since it does not work neither with clang nor with MSVC. I'm not even sure whether it works with C++17, either. - Do another round of bug fixing/cleanup
- Release 0.5.0
After that, I haven't really decided what to do yet. However, those items are high on my eternal to-do list:
- hot-save/hot-reload (save/reload while the decompilation is running). This might even be in a format that other decompilers can understand; I haven't yet investigated how feasible this is, though.
- Implement a better high level code generator based on the No More Gotos paper
- Implement better function detection based on e.g. Nucleus, maybe combined with Function Interface Analysis
- Refactor SSL IR into something that does not need any hard-coded decoder hacks e.g. for call or jump instructions.
- Proper multicore support
- C++ decompilation, including RTTI, vtables etc.
Hopefully this cleared up some of your questions. :)
This looks like a big bag of goodies for all of us,
As You've probably noticed, I have moved this repository to BoomerangDecompiler 'organization', I'll add You to it, feel free to merge your changes into it as well :)
Give me a holler when you want to discuss file formats for decompiler interoperability.
Finally! Boomerang definitely needs its own organization.
@uxmal Sure.
@nemerle Thanks. I'll merge my changes now; afterwards I'll go through all the old issues and close them if they don't apply any more.
Edit: Doesn't seem that I have push access yet. I wanted to push develop directly and work from there. Or should I make a PR to another branch @nemerle ?