4 ms·
Quote: "Self-modifying programs were fine under MS-DOS, but modern operating systems won't let it fly" This is wrong on 2 accounts: 1 - Even on MS-DOS you wer
by unnouinceput 5y ago
Quote: "Self-modifying programs were fine under MS-DOS, but modern operating systems won't let it fly"
This is wrong on 2 accounts:
1 - Even on MS-DOS you weren't able to directly modify your executable. I remember having to launch a copy, which would see from the name is a copy, exit and let the copy modify the original .exe. Later I simply did this using batch files.
2 - Even on modern operating systems you can actively destroy the link/handle between the operating system and the executable, allowing you to actively modify your own executable. See "Unlocker" as example on Windows for a legit application that can do such a killing (I used that to get rid of that crap called BitDefender, who after installation is behaving like a rootkit)
- blibble 5y ago1. you can bypass DOS and write directly to the sectors on the disk 2. Linux won't let you open() a file that's a resident executable for write... you'll get ETXTBUSY you can write out a new file and change the directory entry to point to a new one, but then you haven't technically modified the other file
- evanelias 5y ago> you can write out a new file and change the directory entry to point to a new one, but then you haven't technically modified the other file Yep, this. Meanwhile, on MacOS, code signatures (for signed binaries) are cached by inode. If the file contents at that inode change, the signature no longer matches, and Gatekeeper will SIGKILL the binary immediately when you try to run it. The cache is only kept in memory though, and rebooting clears it.
- deleted 5y ago[deleted]