Hacker News Reader

Comment by Pannoniae | Hacker News Reader

Self-modifying code is a meme unless you're writing an obfuscator... (but even then you can hook the execution so it's a pretty low-tier anti-reversing effort ngl)

For perf reasons it's the equivalent of shooting your leg off to lose weight. You're flushing the instruction cache and breaking prefetch, leading to a huge stall. Then you do it again. And again. It hasn't been in vogue since the 80s...

View on HN

I don’t think most obfuscators will care about self-modifying code anyway, outside of cases like packing (…and in that case you probably won’t be rewriting the unpacker stub anyway :D). Also self modifying code breaks on targets like Windows kernel drivers, which are a big target for SOTA obfuscation these days.

JIT compilers are essentially producing self-modifying programs (or, indeed, dynamically loaded libraries).

Dynamic languages, like Common Lisp, where things can be redefined at run time likely require modification of running code to achieve high efficiency (the alternative is to just leave a general mechanism in place and accept the runtime overhead and loss of optimization opportunities from that.)

That depends how far in advance of running the code you're modifying it. You could see a JIT compiler as an extreme type of SMC. Or a Monero miner - its hashing algorithm relies on running randomly generated programs.

JIT and SMC are two different things because JIT is write-once-then-execute, SMC is write-many-then-execute-many. Even with reoptimisation like the JVM, you're not modifying the existing code but writing it onto a new page. That is the key difference, you're not modifying existing written-out instructions, you're creating new ones.

Consider a kernel that boots on several different machines with different capabilities. Patching the call instructions at init time, to point to either one version or another of a frequently used function, saves time.

Reply on news.ycombinator.com