4 ms·
If you ran the transpiled binaries with a security flag prohibiting execution of generated code, that would cause anything with a jit to crash neatly and possib
by api 3y ago
If you ran the transpiled binaries with a security flag prohibiting execution of generated code, that would cause anything with a jit to crash neatly and possibly with an informative error message. Docs for this system would have to be clear that jits will not work and must be native.
I think Linux has some kind of no-exec flag like that. I know macOS does.
- dmitrygr 3y agothat would not save you from someone doing things like: ((void (*)(void))(((uintptr_t)&myfunc) + 1))(); and there you go - on x86 this could plausibly be a way to obfuscate code since it has variable-length instrs. And your static analysis may not catch this. This does not require writeable executable pages or JIT. Hell, i can receive a uint32 from the network, cast to a func pointer, and jump to it. And for all you know, my protocol relies on a lack of ASLR and sends me a valid entry point addr in my executable, which will have changed in the translation you do. (Fun story: long ago, AIM's anti-protocol-cloning code did that - server would send a VA and ask for a few bytes at that VA. Unless you had a current copy of the aim executable in memory running you had no way to correctly reply) The long tail of valid but freaky shit is ....very long, and disallowing W&X pages will not protect you from it all
- akoboldfrying 3y agoCorrect, your incremented function pointer won't be caught -- but now we're really getting down to the parts-per-million of programs that use this. Demoscene code, sometimes, maybe? I would say W^X protection will protect you from all non-adversarial programs.
- dmitrygr 3y agoDue to anti piracy and anti cheat mechanisms, games are also likely to pull shit like that