3 ms·

> compiler frameworks (LLVM, but GCC would work too) that provide you with a lot of tools to start with. While I agree with this, the binary code to LLVM IR up

by xvilka 3y ago

> compiler frameworks (LLVM, but GCC would work too) that provide you with a lot of tools to start with. While I agree with this, the binary code to LLVM IR uplifting loses a lot of context and semantics information because LLVM IR was designed to do precisely the opposite. Moreover, the increasing popularity of using "middle level" IRs in LLVM-based compilers, like MIR and Swift IR, makes the "distance" between code and the IR representation even bigger. This is why IRs specifically designed to tackle RE tasks would perform better (RzIL and any relatively modern intermediate representation). > They simply do not scale. I agree with this notion, but you don't need to "solve" a whole program; it's impossible for any real-world software; you can selectively pick places to do so. Currently, existing binary analysis software already does that, but usually in a more "manual" way, e.g., by emulating pieces of the code sparsely to figure out indirect jumps and so on.

aleclm 3y ago
> 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/test/tests/analysis/CollectCFG/arm/switch-disjoint-ranges.S https://github.com/revng/revng-qa/blob/master/share/revng/te...

by xvilka 3y ago

aleclm 3y ago

> 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/test/tests/analysis/CollectCFG/arm/switch-disjoint-ranges.S https://github.com/revng/revng-qa/blob/master/share/revng/te...