4 ms·

Cute, but Rice's theorem remains, and while they translated every byte as code, still no handling is possible for char buf[] = {0xB8, 0x2A, 0x00, 0x00, 0x00

Cute, but Rice's theorem remains, and while they translated every byte as code, still no handling is possible for char buf[] = {0xB8, 0x2A, 0x00, 0x00, 0x00, 0xC3}; return ((int (*)(void))buf)(); static translation is only possible when you assume no adversarial code AND mostly assume compiler-produced binaries. hand-rolled asm gets hard, and adversarial code is provably unsolvable in all cases. still, pretty cool for cooperative binaries

tlb 5mo ago
But in fact no modern processor/OS executes this either. Pages are marked as executable or not, and static data is loaded as non-executable pages.
- dmitrygr 5mo ago
  that is why it was not "static const char buf[]" ;) it was not an accident executable stacks are still common (incl on windows with some settings), and sometimes they are required (eg for gcc nested functions)
  - diamondlovesyou 5mo ago
    That won't be located on the stack either. The underlying buffer will be a TU local - ie static and not rx
    - lisper 5mo ago
      Good grief, what a useless argument. Isn't it obvious that this could trivially be converted to a non-static array if that's really what was needed?
      - rowanG077 5mo ago
        If you are going to be pedantic, at least be fully pedantic.
fsmv 5mo ago
I only read the abstract but I got the impression that their solution to this is they have both. They translate all the data as if it was code and if it gets called into they use the translation where if it gets read as memory they use the original. 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 5mo ago
It looks like their system would just generate return 42;
userbinator 5mo ago
I read those bytes and immediately thought "mov eax, 42; ret".
IshKebab 5mo ago
No based on the abstract it can handle that code. What it can't handle is runtime code generation.
self_awareness 5mo ago
I think this is handled by Rosetta.

tlb 5mo ago

But in fact no modern processor/OS executes this either. Pages are marked as executable or not, and static data is loaded as non-executable pages.

dmitrygr 5mo ago
that is why it was not "static const char buf[]" ;) it was not an accident executable stacks are still common (incl on windows with some settings), and sometimes they are required (eg for gcc nested functions)
- diamondlovesyou 5mo ago
  That won't be located on the stack either. The underlying buffer will be a TU local - ie static and not rx
  - lisper 5mo ago
    Good grief, what a useless argument. Isn't it obvious that this could trivially be converted to a non-static array if that's really what was needed?
    - rowanG077 5mo ago
      If you are going to be pedantic, at least be fully pedantic.

fsmv 5mo ago

I only read the abstract but I got the impression that their solution to this is they have both. They translate all the data as if it was code and if it gets called into they use the translation where if it gets read as memory they use the original. 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 5mo ago

It looks like their system would just generate return 42;

userbinator 5mo ago

I read those bytes and immediately thought "mov eax, 42; ret".

IshKebab 5mo ago

No based on the abstract it can handle that code. What it can't handle is runtime code generation.

self_awareness 5mo ago

I think this is handled by Rosetta.