Price model:<p>> Very briefly:<p>> 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.<p>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<p>[1] <a href="https://www.hopperapp.com/index.html" rel="nofollow">https://www.hopperapp.com/index.html</a>
Checking the team about: <a href="https://rev.ng/about" rel="nofollow">https://rev.ng/about</a><p>And looking at the code contributions: <a href="https://github.com/revng/revng/graphs/contributors">https://github.com/revng/revng/graphs/contributors</a><p>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 coding.<p>Anyway, if this works, then I guess it's a lot of fun for them.<p><i>Edit</i> Ah right, I didn't check the timeline.
A cool company fueled by one of the best PLT books out there: <a href="https://link.springer.com/book/10.1007/978-3-662-03811-6" rel="nofollow">https://link.springer.com/book/10.1007/978-3-662-03811-6</a><p><i>"He also met a partner in crime, Pietro. Romantically enough, he met him thanks to a book which will turn out to be foundational for company."</i><p><a href="https://rev.ng/about" rel="nofollow">https://rev.ng/about</a><p>Congrats on the launch.
Idea: automatically name variables and members of structs based on how code interacts with them.<p>Eg. The next pointer in a linked list should be easy to identify as 'next'.<p>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.
It doesn't work with my ELF file:<p><pre><code> [orchestra] [darkstar@shiina revng]$ ./revng artifact --analyze --progress decompile-to-single-file ../maytag.ko
[=======================================] 100% 0.57s Analysis list revng-initial-auto-analysis (5): import-binary
[===================> ] 50% 0.57s Run analyses lists (2): revng-initial-auto-analysis
[=========> ] 25% 0.57s revng-artifact (2): Run analyses
Only ELF executables and ELF dynamic libraries are supported
[orchestra] [darkstar@shiina revng]$ file ../maytag.ko
../maytag.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
</code></pre>
Does it not support FreeBSD binaries?<p>Edit: Ah I missed that it doesn't support kernel modules, probably has nothing to do with FreeBSD but the fact that this is not a simple executable
I hope collaborative workflows get a lot of attention. I haven't used IDA teams or anything, but a reverse engineering experience that felt as frictionless as Google Docs would be amazing.
Are there any plans to support type inference? It seems like it currently shows all variables as generic64_t. Would be nice to automatically detect their types like Ghidra does (albeit sometimes incorrectly)
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.
Always 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 :)<p>> `source ./environment`<p>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).<p>It sets `AWS_EC2_METADATA_DISABLED="true"` which won't break me (I don't use AWS) but in general seems dubious.<p><pre><code> export RPATH_PLACEHOLDER="////////////////////////////////////////////////$ORCHESTRA_ROOT"
export HARD_FLAGS_CXX_CLANG="-stdlib=libc++"
... "-Wl,-rpath,$RPATH_PLACEHOLDER/lib ...
</code></pre>
This is suboptimal. The very long PATH setting with mingw32 and gentoo and mips strings in it also looks very fragile.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>Thanks again for shipping, and I hope some of the above feedback is helpful!