Seems exciting. I'm keen to try the fully standalone version. Is there any news about tentative pricing? Hopefully its affordable enough for hobbyist as well.
The rev.ng decompiler goes open source
31–40 of 63 posts
Re: The rev.ng decompiler goes open source
#32Price 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 up…
Binary 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 f…
Students 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).
Re: The rev.ng decompiler goes open source
#33Earlier quoted context omitted.
Curious what you do when you encounter an instruction you don't model
That's unlikely, since we use QEMU as a lifter, which sometimes supports new instructions before they hit silicon. However, I think we'll emit a call to some `noreturn` function. Basically we emit a call to `abort`.
Right but you do see how this means that you need to lift code that has semantics that cannot be modeled in C?
Re: The rev.ng decompiler goes open source
#34Checking the team about: https://rev.ng/about And looking at the code contributions: https://github.com/revng/revng/graphs/contributors Isn't it a bit weird that the CEO (aleclearmind) has most commits, even much more than the CTO (pfez)? I often hear the complaints from other CEOs that they don't really find any time anymore to code... Even the CTO usually is more on the managing side and less active in actual codin…
I wonder a bit about the downvotes. I didn't mean this as a criticism or so in any way. In fact, I like this very much. I just found this interesting and unlike what I saw elsewhere. So the downvotes are because this is not interesting or not unusual?
your observation was spot on and your question was answered by the ceo. People on hn can be oversensitive.
Re: The rev.ng decompiler goes open source
#35Price 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 up…
Binary 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 f…
They are now offering a free version: https://binary.ninja/2024/02/28/4.0-dorsai.html
Re: The rev.ng decompiler goes open source
#36Earlier quoted context omitted.
That's unlikely, since we use QEMU as a lifter, which sometimes supports new instructions before they hit silicon. However, I think we'll emit a call to some `noreturn` function. Basically we emit a call to `abort`.
Right but you do see how this means that you need to lift code that has semantics that cannot be modeled in C?
Sure, in those cases we emit calls to C functions. The only thing we need to know is what registers are taken as input, what registers are output and what registers are preserved.
In QEMU parlance, these are helper functions, and they have actual implementations. But for decompilation purposes, you don't need to implement them. You just need to know how they interact with the registers.
Re: The rev.ng decompiler goes open source
#37Earlier quoted context omitted.
Decompilation 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.
> Decompilation is often the least important (and least reliable) part of IDA/Ghidra This is something all people using decompilers say and sort of shows how low is trust towards decompilers. Expectations have always been rather low. I've been there, but this does not have to be the case, the whole reason why we started rev.ng is to prove that expectations can be raised. Apart from accuracy, which is difficult but en…
What happens if you put in a binary which outputs C-like machine code, like Rust (llvm) or zig?
Re: The rev.ng decompiler goes open source
#38Earlier quoted context omitted.
> Decompilation is often the least important (and least reliable) part of IDA/Ghidra This is something all people using decompilers say and sort of shows how low is trust towards decompilers. Expectations have always been rather low. I've been there, but this does not have to be the case, the whole reason why we started rev.ng is to prove that expectations can be raised. Apart from accuracy, which is difficult but en…
What happens if you put in a binary which outputs C-like machine code, like Rust (llvm) or zig?
Languages with a rich standard library and generating a lot of code for you usually need some love to get rid/represent idiomatically common patterns and to detect common data structures.
We haven't looked into it yet, but the automatic data structure recognition might help.
Frankly, Rust looks particularly scary: https://media.ccc.de/v/37c3-11684-rust_binary_analysis_featu...
Re: The rev.ng decompiler goes open source
#39Always pleased to see more binary hacking tools. A load of overly-precise suggestions on the chosen packaging format follows because I might want to use this tool myself :)
> `source ./environment`
That's a bad omen. I downloaded the tar to find it does indeed set a bunch of environment variables including PATH, though thankfully not LD_LIBRARY_PATH. Mostly prefixed "HARD_" which is maybe unique (REVNG would be a more obvious choice, colliding with existing environment variables is a bad thing).
It sets `AWS_EC2_METADATA_DISABLED="true"` which won't break me (I don't use AWS) but in general seems dubious.
export RPATH_PLACEHOLDER="////////////////////////////////////////////////$ORCHESTRA_ROOT"
export HARD_FLAGS_CXX_CLANG="-stdlib=libc++"
... "-Wl,-rpath,$RPATH_PLACEHOLDER/lib ...
I usually bail when the running instructions include "now mangle your environment variables" because that step is really strongly correlated with programs that don't work properly on my non-ubuntu system. Wiring your application control flow through the launching environment introduces a lot of failure modes - it's not as convenient as it first appears. Very like global variables.
Clang will burn a lot of this stuff in as defaults when you build it if you ask, e.g. `-DCLANG_DEFAULT_CXX_STDLIB=libc++` would remove the stdlib setting environment variable. DEFAULT_SYSROOT is useful too.
Using rpath means you're vulnerable to someone running this script with LD_LIBRARY_PATH set as the environment variable will override your DT_RUNPATH setting in the binaries. The background on this is aggravating. Abbreviating here, '-Wl,rpath' no longer means rpath, it means 'runpath' which is a similar but much less useful construct. The badly documented invocation you probably want is `-Wl,rpath -Wl,--disable-new-dtags` to set rpath instead of set runpath, at which point the loader will ignore LD_LIBRARY_PATH when looking for libraries.
There's a good chance you can completely remove the environment mangling through a combination of setting different flags when building clang, static linking and embedding binaries in other binaries.
Related, your clang-16 binary is dynamically linked. As in it goes looking for things like libLLVMAArch64CodeGen.so.16 at runtime. A lot of failure modes can be removed by LLVM_BUILD_STATIC=ON. E.g. if I run your dynamically linked clang with a module based HPC toolchain active, your compiler will pick up the libraries from the HPC toolchain and it'll have a bad time. The tools are all linked against glibc as well, pros and cons to that.
Tools are also linked against libc++.so, which is linked against libc++abi.so and so forth. Worth considering static libc++, but even if you decline that, libc++abi and libunwind can and probably should be statically linked into the libc++. The above rpath rant? Runpath isn't transitive so dynamic libaries finding other dynamic libraries using runpath (the one you get when you ask for rpath) works really poorly.
Context for there being so many suggestions above - I am completely out of patience with distributing dynamically linked programs on Linux. I don't want a stray environment variable from some program that had `source ourhack` in the readme or a "module system" to reach into my application and rewire what libraries it calls at runtime as the user experience and subsequent bug report overhead is terrible. Static linking is really good in comparison.
Thanks again for shipping, and I hope some of the above feedback is helpful!
Re: The rev.ng decompiler goes open source
#40Idea: automatically name variables and members of structs based on how code interacts with them. Eg. The next pointer in a linked list should be easy to identify as 'next'. That would be done by downloading all of GitHub, then seeing what variables in GitHub code have the most similar layouts and interactions, and then if the confidence is high enough, using those names.
Would be very cool indeed, something like http://jsnice.org/
Paper that describes what JSNice is doing behind the scenes: https://files.sri.inf.ethz.ch/website/papers/jsnice15.pdf