Editing Self-modifying code (section)

==Usage==
Self-modifying code can be used for various purposes:

* Semi-automatic [[Program optimization|optimizing]] of a state-dependent loop.
* Dynamic in-place code optimization for speed depending on load environment.<ref name="Caldera_1997_DOSSRC"/><ref name="Paul_1997_OD-A3"/><ref group="nb" name="NB_DR-DOS_386"/>
* [[Run time (program lifecycle phase)|Run-time]] code generation, or specialization of an algorithm in runtime or loadtime (which is popular, for example, in the domain of real-time graphics) such as a general sort utility&nbsp;– preparing code to perform the key comparison described in a specific invocation.
* Altering of [[inline function|inlined]] state of an [[object (computer science)|object]], or simulating the high-level construction of [[closure (computer programming)|closure]]s.
* Patching of [[subroutine]] ([[pointer (computer programming)|pointer]]) address calling, usually as performed at load/initialization time of [[dynamic libraries]], or else on each invocation, patching the subroutine's internal references to its parameters so as to use their actual addresses (i.e. indirect self-modification).
* Evolutionary computing systems such as [[neuroevolution]], [[genetic programming]] and other [[evolutionary algorithm]]s.
* Hiding of code to prevent [[reverse engineering]] (by use of a [[disassembler]] or [[debugger]]) or to evade detection by virus/spyware scanning software and the like.
* Filling 100% of memory (in some architectures) with a rolling pattern of repeating [[opcode]]s, to erase all programs and data, or to [[burn-in]] hardware or perform [[RAM test]]s.<ref name="Wilkinson_1996"/>
* [[Executable compression|Compressing]] code to be decompressed and executed at runtime, e.g., when memory or disk space is limited.<ref name="Caldera_1997_DOSSRC"/><ref name="Paul_1997_OD-A3"/>
* Some very limited [[instruction set architecture|instruction set]]s leave no option but to use self-modifying code to perform certain functions. For example, a [[one-instruction set computer]] (OISC) machine that uses only the subtract-and-branch-if-negative "instruction" cannot do an indirect copy (something like the equivalent of "*a = **b" in the [[C (programming language)|C language]]) without using self-modifying code.
* [[Booting]]. Early [[microcomputer]]s often used self-modifying code in their bootloaders. Since the bootloader was keyed in via the front panel at every power-on, it did not matter if the [[bootloader]] modified itself. However, even today many bootstrap loaders are [[self-relocating]], and a few are even self-modifying.<ref group="nb" name="NB_DR-DOS_707"/>
* Altering instructions for fault-tolerance.<ref name="Ortiz_2015"/>

===Optimizing a state-dependent loop===
[[Pseudocode]] example:

 repeat ''N'' times {
     if STATE is 1
         increase A by one
     else
         decrease A by one
     do something with A
 }

Self-modifying code, in this case, would simply be a matter of rewriting the loop like this:

 repeat ''N'' times {
     ''increase'' A by one
     do something with A
     when STATE has to switch {
         replace the opcode "increase" above with the opcode to decrease, or vice versa
     }
 }

Note that two-state replacement of the [[opcode]] can be easily written as 'xor var at address with the value "opcodeOf(Inc) xor opcodeOf(dec)"'.

Choosing this solution must depend on the value of {{Var|N}} and the frequency of state changing.

===Specialization===
Suppose a set of statistics such as average, extrema, location of extrema, standard deviation, etc. are to be calculated for some large data set. In a general situation, there may be an option of associating weights with the data, so each x<sub>i</sub> is associated with a w<sub>i</sub> and rather than test for the presence of weights at every index value, there could be two versions of the calculation, one for use with weights and one not, with one test at the start. Now consider a further option, that each value may have associated with it a Boolean to signify whether that value is to be skipped or not. This could be handled by producing four batches of code, one for each permutation and code bloat results. Alternatively, the weight and the skip arrays could be merged into a temporary array (with zero weights for values to be skipped), at the cost of processing and still there is bloat. However, with code modification, to the template for calculating the statistics could be added as appropriate the code for skipping unwanted values, and for applying weights. There would be no repeated testing of the options and the data array would be accessed once, as also would the weight and skip arrays, if involved.

===Use as camouflage===
Self-modifying code is more complex to analyze than standard code and can therefore be used as a protection against [[reverse engineering]] and [[software cracking]]. Self-modifying code was used to hide copy protection instructions in 1980s disk-based programs for systems such as [[IBM PC compatible]]s and [[Apple II]]. For example, on an IBM PC, the [[floppy disk]] drive access instruction <code>[[int 0x13]]</code> would not appear in the executable program's image but it would be written into the executable's memory image after the program started executing.

Self-modifying code is also sometimes used by programs that do not want to reveal their presence, such as [[computer virus]]es and some [[shellcode]]s. Viruses and shellcodes that use self-modifying code mostly do this in combination with [[polymorphic code]]. Modifying a piece of running code is also used in certain attacks, such as [[buffer overflow]]s.

===Self-referential machine learning systems===
Traditional [[machine learning]] systems have a fixed, pre-programmed learning [[algorithm]] to adjust their [[parameter (computer programming)|parameter]]s. However, since the 1980s [[Jürgen Schmidhuber]] has published several self-modifying systems with the ability to change their own learning algorithm. They avoid the danger of catastrophic self-rewrites by making sure that self-modifications will survive only if they are useful according to a user-given [[fitness function|fitness]], [[error function|error]] or [[reward function|reward]] function.<ref name="Schmidhuber"/>

===Operating systems===
The [[Linux kernel]] notably makes wide use of self-modifying code; it does so to be able to distribute a single binary image for each major architecture (e.g. [[IA-32]], [[x86-64]], 32-bit [[ARM architecture family|ARM]], [[ARM64]]...) while adapting the kernel code in memory during boot depending on the specific CPU model detected, e.g. to be able to take advantage of new CPU instructions or to work around hardware bugs.<ref name="linux_self_modifying_Paltsev">{{cite web |author-last=Paltsev |author-first=Evgeniy |title=Self Modifying Code in Linux Kernel - What, Where and How |date=2020-01-30 |url=https://talk.telematika.org/2019/all/self_modifying_code_in_linux_kernel_-_what_where_and_how/ |access-date=2022-11-27}}</ref><ref name="linux_self_modifying_altinstructions">{{cite web |author-last=Wieczorkiewicz |author-first=Pawel |title=Linux Kernel Alternatives |url=https://grsecurity.net/linux_kernel_alternatives |access-date=2022-11-27}}</ref> To a lesser extent, the [[DR-DOS]] kernel also optimizes speed-critical sections of itself at loadtime depending on the underlying processor generation.<ref name="Caldera_1997_DOSSRC"/><ref name="Paul_1997_OD-A3"/><ref group="nb" name="NB_DR-DOS_386"/>

Regardless, at a [[meta-level]], programs can still modify their own behavior by changing data stored elsewhere (see [[metaprogramming]]) or via use of [[type polymorphism|polymorphism]].

==={{anchor|Synthesis}}Massalin's Synthesis kernel===
The Synthesis [[kernel (operating system)|kernel]] presented in [[Alexia Massalin]]'s [[Doctor of Philosophy|Ph.D.]] thesis<ref name="Massalin_1992_Synthesis"/><ref name="Henson_2008"/> is a tiny [[Unix]] kernel that takes a [[structured programming|structured]], or even [[object-oriented programming|object oriented]], approach to self-modifying code, where code is created for individual [[quaject]]s, like filehandles. Generating code for specific tasks allows the Synthesis kernel to (as a JIT interpreter might) apply a number of [[Compiler optimization|optimization]]s such as [[constant folding]] or [[common subexpression elimination]].<!-- Anyone want to go read the thesis and see what other optimizations Massalin lists? -->

The Synthesis kernel was very fast, but was written entirely in assembly. The resulting lack of portability has prevented Massalin's optimization ideas from being adopted by any production kernel. However, the structure of the techniques suggests that they could be captured by a higher level [[programming language|language]], albeit one more complex than existing mid-level languages. Such a language and compiler could allow development of faster operating systems and applications.

[[Paul Haeberli]] and Bruce Karsh have objected to the "marginalization" of self-modifying code, and optimization in general, in favor of reduced development costs.<ref name="Haeberli_1994_GraficaObscura"/>