3 ms·
The idea is that the JITed code is executed much more often than it's (re)written, right? So each time the JIT (re)compiles the code, it can call mprotect on t
by cvwright 10y ago
The idea is that the JITed code is executed much more often than it's (re)written, right?
So each time the JIT (re)compiles the code, it can call mprotect on the target page to allow writes and disable execution. Then after it's done, it calls mprotect again to disable writes and allow execute.
- EthanHeilman 10y agoThe shell code is in the code which is compiled. 1. Put shell code in a string in some js, 2. get browser to JIT js and thus write the string that contains the shell code to an execute page in memory, 3. exploit a vulnerability and point the instruction pointer to the location of the string which contains the shellcode. Normally, i.e. outside of a JIT, this wouldn't work because the string would be saved to a non-executable page.
- cvwright 10y agoAh, so it's not that you inject your shellcode directly onto an exectuable page, but instead you get the JIT to create it there for you. That makes sense. Thanks!