À mon humble avis, le virus de test est d'avoir quelque chose qui est à la fois connu pour être inoffensif, et accepté comme un virus afin que les utilisateurs finaux puissent vérifier que le logiciel AV est allumé , et peut voir l'effet d'une identification de virus. Pensez exercice d'incendie, pour les logiciels AV.
J'imagine que la plupart ont une signature pour cela, et le reconnaissent directement comme tel. Je ne serais pas surpris si le modèle binaire du test EICAR réel est arrivé à inclure des modèles de bits qui sentaient comme des opcodes pour une activité suspecte, mais je ne sais pas si c'est le cas. Si c'est le cas, il peut s'agir d'un test valide d'un simple outil de reconnaissance de virus heuristique. Cependant, depuis que le test EICAR a été autour d'un long temps, j'imaginerais aussi que toute heuristique qui le met en cache n'est pas assez bonne pour attraper quelque chose maintenant dans la nature. Je ne m'attendrais pas à ce que la reconnaissance d'EICAR soit la preuve d'une réclamation plus forte que "l'AV est installée et qu'elle scanne ce qu'elle était censée scanner", et si je développais un système AV, je ne tenterais pas de rendre plus fort réclamer à ce sujet.
Mise à jour:
Le virus de test EICAR réelle est la la chaîne suivante:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
qui a été soigneusement conçu (selon le Wikipedia article) d'avoir quelques propriétés intéressantes. Tout d'abord, il se compose uniquement de caractères ASCII imprimables. Il comprendra souvent des espaces et/ou un saut de ligne à la fin, mais cela n'a aucun effet sur sa reconnaissance ou sur sa fonction.
Ce qui soulève la deuxième propriété: il s'agit en fait d'un programme exécutable pour un processeur 8086. Il peut être sauvegardé (via Notepad, par exemple) dans un fichier avec l'extension .COM, et il peut être exécuté sur MSDOS, la plupart des clones de MSDOS, et même en mode de compatibilité MSDOS de l'invite de commande Windows (y compris sur Vista, mais pas sur Windows 64 bits car ils ont décidé que la compatibilité avec le mode réel 16 bits n'était plus une priorité.)
Lors de l'exécution, il produit en sortie la chaîne "EICAR-STANDARD-ANTIVIRUS-TEST-FILE! " puis quitte.
Pourquoi sont-ils allés à cet effort? Apparemment, les chercheurs voulaient un programme dont on savait qu'il fonctionnait sans danger, en partie pour que les scanners en direct puissent être testés sans avoir besoin de capturer un vrai virus et risquer une véritable infection. Ils voulaient aussi qu'il soit facile à distribuer par des moyens conventionnels et non conventionnels.Comme il s'avère qu'il existe un sous-ensemble utile de l'ensemble d'instructions en mode réel x86 où chaque octet répond à la restriction qu'il s'agit également d'un caractère ASCII imprimable, ils ont atteint les deux objectifs.
L'article wiki a un lien vers un blow-by-blow explanation de la façon dont le programme fonctionne réellement qui est également une lecture intéressante. Ajoutant à la complexité est le fait que la seule façon d'imprimer sur la console ou quitter un programme en mode DOS réel est d'émettre une instruction d'interruption logicielle, dont l'opcode (0xCD) n'est pas un caractère ASCII 7 bits imprimable. De plus, les deux interruptions nécessitent chacune un paramètre immédiat d'un octet, dont l'un doit être un caractère espace. Comme la règle auto-imposée était de ne pas autoriser les espaces, les quatre derniers octets du programme ("H + H *" dans la chaîne) sont modifiés avant que le pointeur d'instruction ne les exécute.
Désassemblage et le dumping EICAR.COM avec la commande DEBUG à une invite de commande sur ma boîte de XP, je vois:
0C32:0100 58 POP AX
0C32:0101 354F21 XOR AX,214F
0C32:0104 50 PUSH AX
0C32:0105 254041 AND AX,4140
0C32:0108 50 PUSH AX
0C32:0109 5B POP BX
0C32:010A 345C XOR AL,5C
0C32:010C 50 PUSH AX
0C32:010D 5A POP DX
0C32:010E 58 POP AX
0C32:010F 353428 XOR AX,2834
0C32:0112 50 PUSH AX
0C32:0113 5E POP SI
0C32:0114 2937 SUB [BX],SI
0C32:0116 43 INC BX
0C32:0117 43 INC BX
0C32:0118 2937 SUB [BX],SI
0C32:011A 7D24 JGE 0140
0C32:0110 45 49 43 41 EICA
0C32:0120 52 2D 53 54 41 4E 44 41-52 44 2D 41 4E 54 49 56 R-STANDARD-ANTIV
0C32:0130 49 52 55 53 2D 54 45 53-54 2D 46 49 4C 45 21 24 IRUS-TEST-FILE!$
0C32:0140 48 DEC AX
0C32:0141 2B482A SUB CX,[BX+SI+2A]
Après l'exécution d'instructions jusqu'à JGE 0140, les deux dernières instructions ont été modifiées pour être:
0C32:0140 CD21 INT 21
0C32:0142 CD20 INT 20
appels système DOS la plupart ont été envoyés par INT 21 avec la valeur du registre AH ou AX spécifiant la fonction à exécuter. Dans ce cas, AH est 0x09, qui est la fonction de chaîne d'impression, qui imprime la chaîne commençant à offset 0x011C, terminée par le signe dollar. (Vous deviez imprimer un signe dollar avec une astuce différente en DOS pur.) L'appel INT 20 met fin au processus avant que des octets supplémentaires dépassant ce point puissent être exécutés.
Le code auto-modifiable a été une première tentative de virus, mais il est ici utilisé pour préserver la restriction sur les valeurs d'octets qui peuvent être utilisées dans la chaîne. Dans un système moderne, il est possible que la fonction de protection d'exécution de données capture la modification, si cela est appliqué en mode de compatibilité MSDOS exécutant un fichier COM.
Comment cela est-il même légèrement lié à la programmation? – user73993
Peut-être qu'il pense à la façon d'écrire un système AV? Bien sûr, il pourrait réfléchir à la façon de contourner un tel système aussi .... – RBerteig
Je lisais juste sur les mécanismes de détection de virus et comment les implémenter dans les programmes. Puisque l'heuristique et la médecine légale sont liées à la programmation, j'ai pensé que c'était un bon endroit pour poser la question :) –