revng
revng-qa
revng | revng-qa | |
---|---|---|
7 | 1 | |
1,201 | 6 | |
5.0% | - | |
9.6 | 8.2 | |
7 days ago | 7 days ago | |
C++ | Python | |
GNU General Public License v3.0 only | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
revng
-
The rev.ng decompiler goes open source
We should probably add a warning about `source ./environment`.
Now, let's get to each of your comments :D
> though thankfully not LD_LIBRARY_PATH
We spent a lot of time to have a completely self-contained set of binaries where each ELF refers to its dependencies through relative paths. LD_LIBRARY_PATH is evil.
> Mostly prefixed "HARD_"
Those are just used by our compiler wrappers, I don't think those environment variables collide with anything in practice.
> It sets `AWS_EC2_METADATA_DISABLED="true"`
Original discussion: https://github.com/revng/revng/pull/309#discussion_r12805759...
I guess we could patch the AWS SDK to avoid this.
- Revng translates (i386, x86-64, MIPS, ARM, AArch64, s390x) binaries to LLVM IR
-
Ask HN: Which books do you consider real gems in your field of work/study?
Nielson & Nielson literally saved my PhD and enabled the creation of the company. I'm so grateful.
Do you have any contact? It'd be cool to invite one of the authors to our weekly internal meetings.
> the authors have written a prequel
Oh crap, that's great!
Honestly, we use Chapter 2 a lot, it already provides so much value. And in fact, you could write a whole book only about that.
Here's our C++ implementation of MFP:
https://github.com/revng/revng/blob/develop/include/revng/MFP/MFP.h#L66
-
TMNT Shredder's Revenge has been ported to ARM-based Retro Handhelds!
I'm not certain, but my best guess right now is that the non-open-source games are going through a static binary translator (like this one). Going from a strong-memory-model ISA like x86_64 to a weak-memory-model ISA like ARM, can present performance challenges when memory fencing is added.
-
C++ Jobs - Q3 2022
C++ 20 coroutines: we employ them to achieve "stackless C++";
-
C++ Jobs - Q3 2021
C++20 Coroutines: we employ them to safely and idiomatically transistions from UI thread and long-running computation threads and "stackless C++""
revng-qa
-
Revng translates (i386, x86-64, MIPS, ARM, AArch64, s390x) binaries to LLVM IR
> the binary code to LLVM IR uplifting loses a lot of context
Losing context is good in order to ensure you properly decoupled the frontend from the rest of the pipeline.
We don't even keep track of what a "call" instruction is, we re-detect it on the LLVM IR.
One reason you may want to preserve context is to let the user know where a specific piece of lifted code originated from. In order to preserve this information, we exploit LLVM's debugging metadata and it works pretty well. There's some loss there, but LLVM transformations strive to preserve it.
After all, imagine you have `add rax, 4; add rax, 4`, you'll want to optimize it to a +8 and you'll either have to decide if you want to associate your +8 operation with the first or the second instruction.
> the binary code to LLVM IR uplifting loses a lot of [...] semantics information
Not sure what you mean here, we use QEMU as a lifter and that's very accurate in terms of semantics.
I'm not sure what MIR and Swift IR have to do with the discussion, those are higher level IRs for specific languages. LLVM is rather low level and it's language agnostic.
However, for going beyond lifting, i.e., decompilation, it's true that LLVM shows some significant limitations. That's why we're rolling our own MLIR dialect, but we can still benefit of all the MLIR/LLVM infrastructure, optimizations and analyses. We're not starting from scratch.
> emulating pieces of the code sparsely to figure out indirect jumps and so on
It's hard to emulate without starting from the beginning. Maybe you're thinking about symbolic execution?
In any case, rev.ng does not emulate and does not do any symbolic execution: we have a data-flow analysis that detects destinations of indirect jumps and it's pretty scalable and effective. Example of things we handle: https://github.com/revng/revng-qa/blob/master/share/revng/te...
What are some alternatives?
rellume - Lift machine code to performant LLVM IR
cmm- - Markdown parcer
rizin - UNIX-like reverse engineering framework and command-line toolset.
revng-c
remill - Library for lifting machine code to LLVM bitcode
bookstuff
QEMU - Official QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are ignored. Please only use release tarballs from the QEMU website.