2 ms·
that 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
by dmitrygr 3y ago
that 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