4 ms·

> One of my research topics last year was self-modifying code mainly for obfuscation. I think obfuscation is generally a really bad idea, but that was brough

by slaymaker1907 3y ago

> One of my research topics last year was self-modifying code mainly for *obfuscation*. I think obfuscation is generally a really bad idea, but that was brought up in the article. One practical application for self-modifying code is hotpatching. Sometimes you really don't want to stop the process but want to change the implementation for some function.

Borg3 3y ago
Hold on, How you can actually do hotpatching on x86 protected mode? code is usualy executable but read only. data + stack is usualy NX but writable.
- slaymaker1907 3y ago
  You do the same thing JIT does and change the permissions on the page to NX, apply whatever update you want, then remove the write permission and make it executable again. Even though it seems like it doesn't make a difference, it's much more difficult for an attacker to change the page permissions than it is for the hotpatcher/JIT. I think this could still fail though depending on how strict your OS is in which case you might need to use explicit function pointers which are obviously writable. Some systems apparently allow you to add executable without removing write as that is what the OP does with "mprotect(page, getpagesize(), PROT_READ | PROT_WRITE | PROT_EXEC);". However,
  - metadat 3y ago
    Why is it more difficult for an attacker to change the code compared the JIT?
    - matheusmoreira 3y ago
      Attackers love overflowing buffers but since that memory is not executable they can't put code in there directly. The JIT compiler is almost always the only component which writes to executable pages so they need to somehow trick it into emitting the code they want. It's my understanding that JIT spray attacks are harder to develop.
- matheusmoreira 3y ago
  You can just change the permissions with mprotect.
- LegionMammal978 3y ago
  The processor itself doesn't enforce W^X protection; even though writable pages are NX by convention, nothing inherently stops you from using (the equivalent of) mmap(PROT_READ | PROT_WRITE | PROT_EXEC) and copying the instructions in, or doing the same with existing pages using mprotect(), at which point you can hotpatch as much as you want. Of course, some OSes forbid this as a hardening measure, but allowing it remains very common.

> One of my research topics last year was self-modifying code mainly for *obfuscation*. I think obfuscation is generally a really bad idea, but that was brough

Borg3 3y ago

Hold on, How you can actually do hotpatching on x86 protected mode? code is usualy executable but read only. data + stack is usualy NX but writable.

slaymaker1907 3y ago
You do the same thing JIT does and change the permissions on the page to NX, apply whatever update you want, then remove the write permission and make it executable again. Even though it seems like it doesn't make a difference, it's much more difficult for an attacker to change the page permissions than it is for the hotpatcher/JIT. I think this could still fail though depending on how strict your OS is in which case you might need to use explicit function pointers which are obviously writable. Some systems apparently allow you to add executable without removing write as that is what the OP does with "mprotect(page, getpagesize(), PROT_READ | PROT_WRITE | PROT_EXEC);". However,
- metadat 3y ago
  Why is it more difficult for an attacker to change the code compared the JIT?
  - matheusmoreira 3y ago
    Attackers love overflowing buffers but since that memory is not executable they can't put code in there directly. The JIT compiler is almost always the only component which writes to executable pages so they need to somehow trick it into emitting the code they want. It's my understanding that JIT spray attacks are harder to develop.
matheusmoreira 3y ago
You can just change the permissions with mprotect.
LegionMammal978 3y ago
The processor itself doesn't enforce W^X protection; even though writable pages are NX by convention, nothing inherently stops you from using (the equivalent of) mmap(PROT_READ | PROT_WRITE | PROT_EXEC) and copying the instructions in, or doing the same with existing pages using mprotect(), at which point you can hotpatch as much as you want. Of course, some OSes forbid this as a hardening measure, but allowing it remains very common.