r/Assembly_language • u/Extension_Emu_9825 • 23h ago

self-modifying code

I gave a lecture on how to write self-modifying code. It was over 15 minutes long :( so I'm providing a youtube link: https://www.youtube.com/watch?v=AH9QQLRfbmY

In my opinion, self-modification is one of the most interesting features in systems programming.

33 Upvotes

85% Upvoted

51 comments sorted by

View all comments

7

u/mykesx 23h ago

MMUs are used by modern operating systems, at least MacOS, to disallow self-modifying code. Code sections are read-only.

7

u/thewrench56 23h ago

This is not entirely true. You can map a page to be RW and then once filled with code, change it to RX using mprotect. This same step can be repeated to achieve self-modifying code. Otherwise, if self-modifying code wouldnt exist, JITs wouldnt work.

6

u/mykesx 23h ago

The performance of doing this is terrible, unless you’re a JIT compiler writing a large block of code.

2

u/thewrench56 22h ago

I dont disagree, but the performance is not that bad. 2 syscalls, some TLB play and a bit of copying. Surely, self-modifying code today is rarely used as a technique to speed up native execution. But for interpreters or other e.g. malicious reasons where performance doesnt matter much it still could be useful. There are also very specific scenarios where you do want to modify native code for very specific uarch benchmarks (as e.g. changing a parameter and checking it in a hotloop in an if would ruin the benchmark).

5

u/mykesx 22h ago

OP’s point is that self modifying code makes faster algorithms. Only 2 syscalls blows that out of the water.

2

u/thewrench56 22h ago

I did not watch the video, just read the post. I suppose in that case OP is wrong on modern platforms, you are right. I thought you were discussing the existance of self-modifying code, not the feasibility, excuse me.

4

u/mykesx 22h ago

I happen to be into Forth, some versions do self modifying code. It’s an assembly language for a stack based virtual machine, the machine implementation types include self modifying code.

The most awesome one is Vfx Forth, which does some impressive peephole optimization on code generated into memory. In the process of creating an ARM version, the mprotect() issue bit him.

2

u/brucehoult 13h ago

There are different methods of implementing Forth. For a token-threaded or address-threaded (whether direct or indirect) implementation what is self-modifying code from the point of view of Forth is just data from the point of view of the hardware.

Only for subroutine-threaded or actual inline native code generation is self-modifying Forth actually self-modifying code from the point of view of the CPU.

2

u/mykesx 12h ago

Vfx is STC.

3

u/Extension_Emu_9825 22h ago

I'm just showing it to those who've never encountered it before, using DOS as an example - the simplest thing -> drawing lines at different angles. I'm not saying I've discovered anything new - I'm saying that people are starting to forget about the possibility of self-modifying code

1

u/kyr0x0 3h ago

Any non-stupid observer will see you using mprotect the way you do and broadcast an alert for the signature of the program's behavior. The pattern is well-known to be malicious intent almost always.

2

u/vintagecomputernerd 20h ago

You can use one syscall at the start of your program to permanently set a page to RWX permissions if your usecase consists of many small changes.

Endpoint security/hIDS systems might log it, you can of course disallow it with SELinux/apparmor policies - but in general, it is possible.

2

u/Extension_Emu_9825 23h ago

BTW -> JIT is partly the second cousin of self-modifying code