============================================================================ V o u s a v e z d i t C o r e W a r ? ============================================================================ On se sait pas exactement aujourdh'ui où s'arrêtera l'évolution des microbes informatique de tout genre. Par contre , on connaît assez bien l'historique de cette évolution. De ce point de vue l'analyse du Core War est assez intéressante , marquant des étapes importantes de cette évolution. Au départ l'idée était un simple jeu , puis les manipulateurs sont devenus des manipulés ... L'idée de "virus informatique" avait déjà germée dans l'esprit du père de l'informatique : Monsieur John von Neumann. Qui était ce personnage ? Un grand mathématicien qui a jeté les bases de l'architecture d'un ordinateur. Les ordinateurs de monsieur "tout le monde" sont encore des machines de von Neumann. ( A côté de ces computers à architecture classique il existe également les machines à architecture parallèle.) C'est en 1949 , dans un document historique portant le nom de "Theory and Organization of Complicated Automata" , qu'il définira pour la première fois un mécanisme auto-modifiant. J'ouvre ici une parenthèse pour vous signaler qu'un code auto-modifiant , différent d'un code de type "virus" , risque de planter royalement sur les machines équipées de mémoires caches et autres buffers accélérant le cycle de recherche et de traitements des instructions machine par le micro-processeur 680xx. Il est d'ailleurs très simple de comprendre pourquoi. Le cycle de recherche copiera par exemple 100 bytes dans le buffer de la mémoire cache et le micro-processeur ne s'occupera que des 4 premiers bytes. Au cycle suivant il voudra traiter les 8 instructions qui suivent consécutivement en mémoire. Or il les a déjà placées dans le buffer. Donc plus besoin de pratiquer un appel pour lire de nouveaux bytes en RAM. C'est le même fonctionnement en pagination, (style GIGAMEM) où on part du principe que le code a toujours tendance à se regrouper autour "d'un centre" évoluant plus lentement que les parties qui le forment. Si le corps complet d'une boucle se trouve en mémoire cache elle s'exécutera beaucoup plus vite. Un problème se pose lorsque le code s'auto-modifie. En effet la mémoire cache n'est pas mise à jour et le programme "plantera" lamentablement ou bien les résultats attendus ne seront plus du tout exacts. C'est pourquoi IL NE FAUT PAS programmer le déroutement d'un vecteur d'interruption en plaçant le code "JMP" et l'endroit du saut par auto-modification du code. Il y a même une autre très bonne raison pour ne pas le faire : l'adresse du vecteur d'interruption ne sera peut-être pas toujours la même d'un Amiga à l'autre. move.l $6c,... est très très mauvais !!! Il n'y a qu'une adresse en absolu sur Miga qui est $4. (on peut taper indifféremment en assembeleur : move.l 4,a6 ou bien move.l (4),a6. Ceci dit revenons à nos moutons ... Dix ans après l'article précursseur de von Neumann un dénommé L.S. Pensrose publia un autre papier dans la revue Américaine "Scientific American". Celui-ci ammorcera le premier d'une longue série discuttant autour des mécanismes auto-modifiant. Mais c'est au cours des années 60 que se multiplièrent les premiers vers, à l'intérieur des environnements multitâches qui permettent l'exécution simultanée de plusieurs programmes par un ordinateur. Une expérience vaut la peine d'être rappelée plus que les autre, car elle fit rapidement de très nombreux adeptes : il s'agit de Core War. C'est dans les laboratoires Bell de la compagnie AT&T, aux Etats-Unis, que naquit l'idée de ce jeu remarquable. Trois informaticiens consacrèrent une grande partie de leur temps libre à en définir les règles et à le mettre au point : M. Douglas MacIlroy, Victor Vysottsky et Robert Morris. Contrairement à la plupart des jeux informatiques développés au cours des vingt dernières années, Core War ne fait pas intervenir l'être humain; il oppose deux programmes entre eux, dans un espace délimité de la mémoire d'un ordinateur. Il tient d'ailleurs son nom des tores de ferrites (en anglais, "ferromagnetic cores") utilisées à cette époque dans la fabrication des circuits de mémoire. Core War débute simplement : deux progammes de très petite taille sont placés dans la mémoire centrale d'un ordinateur. Ils ignorent bien sûr la position de leur adversaire. Leur but est de s'anéantir mutuellement en modifiant le contenu de la mémoire. Chacun peut essayer de localiser l'adversaire, le "bombarder" de 0 (de manière à l'anéantir en détruisant ses instructions), se déplacer pour éviter d'être repéré, s'auto-réparer ou s'auto-copier pour éviter la destruction, etc. Le système d'exploitation multitâches partage le temps de l'ordinateur entre les deux programmes, exécutant tour à tour une instruction du premier puis une instruction du second. Suivant les versions du jeu, le gagnant est celui qui arrive à modifier son adversaire au point de le rendre inactif ou celui dont il reste le plus grand nombre de copies dans la mémoire lorsque le jeu est arrêté. Core War fit des adeptes dans les Laboratoires Bell d'abord, puis dans d'autres hauts-lieux de l'informatique de pointe, tels que le Centre de Recherche Xerox de Palo Alto (PARC) et le Massachussets Institute of Technology (MIT). Mais il allait rester longtemps un jeu ésotérique, pratiqué par un nombre limité d'initiés. Il est vrai que, à cette époque, peu de gens pouvaient consacrer des ressources aussi coûteuses à des choses aussi peu importantes ! De plus, les joueurs n'ignoraient sans doute pas les implications possibles de ce qui pouvait à tout moment cesser d'être un jeu. Et puis, des articles commencent à décrire des programmes dérivés de Core War. En 1972, Darwin est décrit dans le numéro 2 la revue Software : "practice and Experience". Ce jeu a également été inventé par M. Douglas MacIlroy, de AT&T. Puis vient Worm, un programme utilitaire écrit par John Shoch du PARC Xerox... En 1981, dans une publication de l'Université de Dortmund, le scientifique allemand J. Kraus, définit les caractéristiques d'auto-repro-duction des virus. Le célèbre Ken Thompson, père du système d'exploitation UNIX, fut le premier à parler publiquement de Core War. C'était en 1983, alors qu'il recevait le prix A.M. Turing de l'Association for Computing Machinery. Dans son discours, il détailla les grandes lignes du jeu et encouragea même les membres de l'assistance à expérimenter avec ces petites "créatures logiques" dans leurs environnements respectifs. Il est clair qu'un homme aussi brillant et aussi créatif que Ken Thompson ne devait contempler que l'aspect stimulant de Core War. Il serait léger de l'accuser d'être à l'origine de l'épidémie de vers ou de virus que nous connaissons aujourd'hui. Toutefois, il faut croire que certains le prirent au mot... Mais ce qui déclencha un véritable engouement pour Core War, c'est le contenu de la rubrique Computer Recreations de la revue Scientific American de mai 1984. A.K. Dewdney y explique de manière fort détaillée le principe général du jeu et la programmation de différents "programmes de bataille". Assisté par David Jones, un étudiant de Western University (au Canada), Dewdney avait mis au point RedCode, une sorte de langage d'assemblage destiné au développement de tels programmes de bataille, et un programme de contrôle du jeu appelé MARS (acronyme de "Memory Array Redcode Simulator"). Parmi les exemples décrits, Dwarf, un programme bête mais dangereux, bombarde 1 position mémoire sur 5 avec un zéro. Imp, le rampant, se déplace inlassablement à travers la mémoire. Plus sophistiqués, Gemini, Juggernaut et Bigfoot ont des chances de survie déjà plus grandes... plus intelligent, Raidar utilise une logique qui lui assure une supériorité sur les premiers... Si vous désirez en connaître plus sur le Core War lisez la suite dans le bouquin de Micro-Application consacré au "virus informatique". On ne peut pas empêcher le développement des microbes informatiques en tout genre mais on peut essayer d'en limiter la propagation ! N'oubliez jamais de protéger vos disquettes. Armez vous d'un anti-virus et achetez des originaux ! ============================================================================