back
7 comments
In case you were also unable to figure out from context exactly what McSema is: https://github.com/trailofbits/mcsema

> McSema is an executable lifter. It translates ("lifts") executable binaries from native machine code to LLVM bitcode.

Once you lifted the code to LLVM, you can do some interesting things, like fuzzing with libFuzzer: https://github.com/trailofbits/mcsema/blob/master/docs/Using...
The technique is derivative of machine-code to machine-code translation ("dynamic recompilation"), which isn't new. For instance, it was used in a Mac emulator¹ for the PC, released in 1990. Valgrind performs code-to-code transformation to do its tricks.

—

1. https://en.wikipedia.org/wiki/Executor_(software) "Executor translates 68k big-endian binary code into x86 little-endian binary code."

Depending on the situation it may be simpler to just use AFL's qemu mode.
From the description:

Translated bitcode can be analyzed or recompiled as a new, working executable with functionality identical to the original.

One of my personal annoyances is the invention of new terminology when there are perfectly fitting existing words which are precise and unambiguous. That's basically a decompiler.

I don't think McSema pretends to be anything other than a native-to-LLVM decompiler.

That said, decompiler is pretty ambiguous. Do you target a readable output? A retargetable output? An executable (and functionally equivalent) output? An analyzable output? Are you going to try to preserve undocumented but reliable behavior, or are you going to permit the output to vary in undefined behavior? Do you guarantee that a single function can be recompiled and substituted in the original binary? There are going to be cases where your implementation is going to have to vary based on what your output is.

The problem is many people would think "decompiler" means it outputs source code.