5 ms·
Price model: > Very briefly: > The rev.ng framework is fully open source. You can decompile anything you want from the CLI. > The UI will be available i
by Fnoord 3y ago
Price model:
> Very briefly:
> The rev.ng framework is fully open source. You can decompile anything you want from the CLI.
> The UI will be available in the following forms:
> free to use in the cloud for public projects;
> available through a subscription in the cloud for private projects;
> available at a cost as a fully standalone, fully offline application.
In comparison, Hopper costs 100 USD with one year of updates [1]. Ghidra and Radare2 are FOSS and completely free to use, IDA Pro costs a fortune
[1] https://www.hopperapp.com/index.html https://www.hopperapp.com/index.html
- eyegor 3y agoBinary ninja is another good option. In my experience it's pretty similar to ida but I find it more user friendly. It just has a lot of well thought out features that make me more productive. I haven't tried hopper but ghidra and radare2 both had a bad dev experience and produced c that didn't "read well". Granted it's been a couple of years since I tried either. Binja is $300 (or $1500 for commercial, both cheaper for students). https://binary.ninja/features https://binary.ninja/features
- aleclm 3y agoStudents shouldn't pay a dime. They are poor. Our view is: the engine is 100% open source. The UI is available for free in the cloud for anyone experimenting, which we define as "I'm OK with leaving the project public". Basically, the decompiler engine is Free Software, extensible and available for automation/scripting, while the UI is available for free for students/researchers and we can make a living out of professionals (i.e., when your company is paying for it).
- halayli 3y agoThey are now offering a free version: https://binary.ninja/2024/02/28/4.0-dorsai.html https://binary.ninja/2024/02/28/4.0-dorsai.html
- Nereuxofficial 3y agoOh that is awesome! I've used the cloud version previously but now that the desktop version is free with some small limitations i think I'll probably use it instead of Ghidra
- felipefar 3y agoI really like licensing models of one-time payments with a pre-defined duration of updates. But I wonder how they enforce it while not making internet access a requirement for the app.
- 8organicbits 3y agoI've been planning to use a non-enforcement model for a future project. Some users will always pay, because of corporate policy or ethics. Some will never pay and will reverse engineer out any software license checks. Asking the user if they have a license keeps the honest ones honest and permits ad-hoc free trials, emergency use, and other reasonable "unlicensed use".
- userbinator 3y agoSome will never pay and will reverse engineer out any software license checks. For a long time (and might still be; not paying much attention anymore), it was a "rite of passage" in the scene to crack IDA... using itself.
- mrexodia 3y agoIt never was a “rite of passage”, because removing IDA’s license checks has always been trivial…
- deleted 3y ago[deleted]
- dvzk 3y agoDecompilation is often the least important (and least reliable) part of IDA/Ghidra, so comparing the two is unfair. That said, the scene is perpetually starved for good C decompilers, so more attempts are always exciting.
- saagarjha 3y agoI hear this a lot and in my experience people who Ghidra or IDA and don’t use the decompiler are exceptionally rare. Why would you suffer that when you can use something else for what you actually want?
- dvzk 3y agoI didn't say I never use it, just that it's not always the core feature. This will depend heavily on your field, but in my past work, the features that were way more essential are: scripting (+ IR lifting), xrefs, CFGs, labels/notes (in a persistent DB). In my experience decompilers will totally ignore or fail on certain types of malicious code, so they mainly exist to assist disassembly analysis. And for that purpose, they save us an incredible amount of human hours.
- aleclm 3y agoFor scripting, our approach is to give you access to the project file (just a YAML file), and you can make changes from any scripting language you want. Everything the user can customize is in there, all the rest is deterministically produced from that file. I really disliked the fact that you usually need to buy into the version of Python that $TOOL requires you to use, or the fact itself that you need to use a specific language. Can parse YAML? You're mostly done. The "project file" is what we call the model: https://docs.rev.ng/user-manual/model-tutorial/ https://docs.rev.ng/user-manual/model-tutorial/ For xrefs, CFG and the rest: we have all of that in the UI, but we also produce them in a rich way. For instance, when we emit disassembly and decompiled code, we actually emit plain text + HTML-like markup to provide metainformation for navigation (basically, xrefs) and highlighting. So you can use all that from any language that can parse HTML/XML. It's called PTML: https://docs.rev.ng/references/ptml/ https://docs.rev.ng/references/ptml/ For lifting: we use LLVM IR as our internal representation. This means that: 1) you don't have to learn an IR that no one else uses, 2) you can use off the shelf tools (e.g., KLEE for symbolic execution) but you can also use all the standard LLVM optimizations and analyses and 3) you can recompile it, but we're not into the binary translation business anymore.