I mostly work on stuff from the 90s, but disassemblers make a lot of assumptions about where code starts and ends, but occasionally a binary blob is not discoverable unless you have some prior knowledge (pointer at a fixed location to an entry point).
I would think after a few passes you could refine the binary into areas that are definitely code.
Why only x86_64? It has more sense to convert 32-bit programs, like many old games.
dmitrygr•26m ago
still, pretty cool for cooperative binaries
tlb•23m ago
dmitrygr•21m ago
executable stacks are still common (incl on windows with some settings), and sometimes they are required (eg for gcc nested functions)
diamondlovesyou•9m ago
fsmv•11m ago
Edit I found this in the paper
> Elevator sidesteps the code-versus-data determination altogether through an application of superset disassembly [6]: we simultaneously interpret every executable byte offset in the original binary as (i) data and (ii) the start of a potential instruction sequence beginning at that offset, and we build the superset control flow graph from every one of the resulting candidate decodes. Every potential target of indirect jumps, callbacks, or other runtime dispatch mechanisms that cannot be statically analyzed therefore has a corresponding landing point in the rewritten binary. These targets are resolved at runtime through a lookup table from original instruction addresses to translated code addresses that we embed in the final binary.
genxy•3m ago