Code auto-modificateur

L' IBM SSEC , présenté en janvier 1948, pouvait modifier ses instructions ou les traiter comme des données. Cependant, cette capacité fut rarement utilisée en pratique. Aux débuts de l'informatique, le code automodifiable était souvent employé pour réduire l'utilisation de la mémoire limitée, améliorer les performances, ou les deux. Il servait aussi parfois à implémenter les appels et retours de sous-programmes lorsque le jeu d'instructions ne proposait que de simples instructions de branchement ou de saut pour modifier le flux de contrôle . Cet usage reste pertinent dans certaines architectures ultra- RISC , du moins théoriquement ; voir par exemple l'ordinateur à jeu d'instructions unique . L'architecture MIX de Donald Knuth utilisait également du code automodifiable pour implémenter les appels de sous-programmes.

Le code automodificateur peut être utilisé à diverses fins :

• Optimisation semi-automatique d'une boucle dépendante de l'état.
• Optimisation dynamique du code sur place pour améliorer la vitesse en fonction de l'environnement de charge.
• La génération de code à l'exécution , ou la spécialisation d'un algorithme à l'exécution ou au chargement (pratique, par exemple, dans le domaine du graphisme en temps réel), comme un utilitaire de tri général – préparer le code pour effectuer la comparaison de clés décrite dans un appel spécifique.
• Modification de l'état intégré d'un objet , ou simulation de la construction de haut niveau des fermetures .
• Correction de l'appel d'adresse de sous-routine ( pointeur ), généralement effectuée au moment du chargement/initialisation des bibliothèques dynamiques , ou bien à chaque invocation, en corrigeant les références internes de la sous-routine à ses paramètres afin d'utiliser leurs adresses réelles (c'est-à-dire une auto-modification indirecte).
• Les systèmes informatiques évolutionnaires tels que la neuroévolution , la programmation génétique et d'autres algorithmes évolutionnaires .
• Dissimulation du code pour empêcher la rétro-ingénierie (par l'utilisation d'un désassembleur ou d'un débogueur ) ou pour échapper à la détection par les logiciels antivirus/antispyware, etc.
• Remplir toute la mémoire (dans certaines architectures) avec un motif roulant d' opcodes répétitifs , pour effacer tous les programmes et les données, ou pour effectuer un rodage du matériel ou réaliser des tests de RAM .
• Compression du code à décompresser et à exécuter lors de l'exécution, par exemple lorsque la mémoire ou l'espace disque est limité.
• Certains jeux d'instructions très limités n'offrent d'autre choix que d'utiliser du code automodificateur pour réaliser certaines fonctions. Par exemple, un ordinateur à jeu d'instructions unique (OISC) qui utilise uniquement l'« instruction » de soustraction et de branchement si négatif ne peut effectuer une copie indirecte (équivalente à une opération similaire *a = **ben langage C ) sans recourir à du code automodificateur.
• Démarrage . Les premiers micro-ordinateurs utilisaient souvent du code automodifiable dans leurs chargeurs de démarrage. Comme le chargeur de démarrage était saisi via le panneau avant à chaque mise sous tension, il importait peu qu'il se modifie de lui-même. Cependant, même aujourd'hui, de nombreux chargeurs de démarrage sont auto-relocalisables , et certains sont même automodifiables.
• Modification des instructions pour la tolérance aux pannes.

répéter N fois { si l'ÉTAT est 1 augmenter A de un autre diminuer A de un faire quelque chose avec A }

répéter N fois { augmenter A de un } faire quelque chose avec A lorsque l'ÉTAT doit changer { Remplacez le code d'opération « augmenter » ci-dessus par le code d'opération correspondant à la diminution, ou inversement. } }

Sur les architectures sans cache de données et d'instructions couplé (par exemple, certains cœurs SPARC , ARM et MIPS ), la synchronisation du cache doit être effectuée explicitement par le code de modification (vider le cache de données et invalider le cache d'instructions pour la zone mémoire modifiée).

Dans certains cas, de courts segments de code auto-modificateur s'exécutent plus lentement sur les processeurs modernes. Cela s'explique par le fait qu'un processeur moderne tente généralement de conserver des blocs de code dans sa mémoire cache. Chaque fois que le programme réécrit une partie de lui-même, cette partie doit être rechargée dans le cache, ce qui entraîne un léger délai si le pointeur d'instruction est modifiée, le processeur ne le détectera pas et exécutera le code tel qu'il était avant la modification. Voir la file d'attente de préchargement (PIQ). Les processeurs PC doivent gérer correctement le code automodifiable pour des raisons de rétrocompatibilité, mais ils sont loin d'être performants dans ce domaine.systèmes d'exploitation veillent à corriger ces vulnérabilités dès qu'elles sont connues. Le problème n'est généralement pas que les programmes se modifient intentionnellement, mais qu'ils puissent être modifiés de manière malveillante par une faille de sécurité .

Un mécanisme de prévention des modifications de code malveillantes repose sur une fonctionnalité du système d'exploitation appelée W^X (pour « écriture XOR exécution »). Ce mécanisme interdit à un programme de rendre une même page mémoire à la fois accessible en écriture et exécutable. Certains systèmes empêchent qu'une page accessible en écriture ne devienne exécutable, même si l'autorisation d'écriture est supprimée. D'autres systèmes offrent une sorte de « porte dérobée », autorisant plusieurs mappages d'une même page mémoire avec des permissions différentes. Une méthode relativement portable pour contourner W^X consiste à créer un fichier disposant de toutes les permissions, puis à mapper ce fichier en mémoire à deux reprises. Sous Linux, il est possible d'utiliser une option de mémoire partagée SysV non documentée pour obtenir de la mémoire partagée exécutable sans avoir à créer de fichier.Des chemins d'exécution rapides peuvent être établis pour un programme, réduisant ainsi certaines branches conditionnelles autrement répétitives .

Le code automodifiable est plus difficile à lire et à maintenir car les instructions figurant dans le listing du programme source ne sont pas nécessairement celles qui seront exécutées. L'automodification consistant en la substitution de pointeurs de fonction peut être moins obscure s'il est clair que les noms des fonctions à appeler sont des espaces réservés pour des fonctions qui seront identifiées ultérieurement.

Le code automodificateur peut être réécrit comme un code qui teste un indicateur et effectue des branchements vers des séquences alternatives en fonction du résultat du test, mais le code automodificateur s'exécute généralement plus rapidement.

Le code auto-modifiable entre en conflit avec l'authentification du code et peut nécessiter des exceptions aux politiques exigeant que tout le code exécuté sur un système soit signé.

Le code modifié doit être stocké séparément de sa forme originale, ce qui entre en conflit avec les solutions de gestion de la mémoire qui, normalement, suppriment le code de la RAM et le rechargent à partir du fichier exécutable selon les besoins.

Sur les processeurs modernes dotés d'un pipeline d'instructions , un code qui se modifie fréquemment peut s'exécuter plus lentement s'il modifie des instructions déjà chargées en mémoire. Sur certains de ces processeurs, la seule façon de garantir la bonne exécution des instructions modifiées est de vider le pipeline et de relire de nombreuses instructions.

Le code automodifiable ne peut pas être utilisé du tout dans certains environnements, tels que les suivants :

• Un logiciel d'application fonctionnant sous un système d'exploitation doté d'une sécurité W^X stricte ne peut pas exécuter d'instructions dans les pages auxquelles il est autorisé à écrire ; seul le système d'exploitation est autorisé à la fois à écrire des instructions en mémoire et à exécuter ultérieurement ces instructions.
• De nombreux microcontrôleurs d'architecture Harvard ne peuvent pas exécuter d'instructions dans une mémoire en lecture-écriture, mais seulement des instructions dans une mémoire dans laquelle ils ne peuvent pas écrire, comme la ROM ou la mémoire flash non auto-programmable .
• Une application multithread peut comporter plusieurs threads exécutant la même section de code auto-modifiable, ce qui peut entraîner des erreurs de calcul et des défaillances de l'application.