Comment les programmes antivirus détectent-ils le virus de test EICAR?

Question

Le virus de test EICAR est utilisé pour tester la fonctionnalité des programmes anti-virus. Pour le détecter en tant que virus,

Le programme antivirus doit-il avoir la définition de virus pour le virus de test

OU

Les méthodes heuristiques le détectent comme un motif suspect et le détectent comme un virus.

(J'ai vu un programme antivirus supprimer le fichier en cours de téléchargement, mais sans l'identifier en tant que virus de test EICAR. Exactement comme un objet suspect - > c'est-à-dire que s'il a la définition, il doit identifier le nom du virus, détails, n'est-ce pas?)

Answer 1

À mon humble avis, l’essentiel du virus de test est d’avoir un élément réputé inoffensif et accepté comme virus afin que les utilisateurs finaux puissent vérifier que le logiciel antivirus est activé et voir les effets du virus. identification. Pensez à un exercice d’incendie pour un logiciel audiovisuel.

J'imagine que la plupart ont une signature et la reconnaissent directement comme telle.

Je ne serais pas surpris si le modèle de bits du test EICAR réel incluait des modèles de bits qui sentaient les opcodes pour une activité suspecte, mais je ne sais pas si c'est le cas. Si tel est le cas, il peut s'agir d'un test valide d'un simple programme de reconnaissance de virus heuristique. Cependant, comme le test EICAR existe depuis un long temps, j’imaginerais également que toute heuristique qui le cache n’est pas suffisante pour capturer quoi que ce soit dans la nature.

Je ne m'attendrais pas à ce que le fait de reconnaître EICAR soit la preuve d'une revendication plus solide que "le système audiovisuel est installé et à numériser ce qu'il était censé numériser", et si je développais un système audiovisuel, je ne tenterais pas de renforcer réclamer à ce sujet.

Mise à jour:

Le virus de test EICAR actuel est la chaîne suivante:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

qui a été conçu avec soin (selon article de Wikipedia ) pour avoir quelques propriétés intéressantes .

Premièrement, il ne contient que des caractères ASCII imprimables. Il inclura souvent des espaces et / ou une nouvelle ligne à la fin, mais cela n’a aucun effet sur sa reconnaissance, ni 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 enregistré (via le Bloc-notes, par exemple) dans un fichier portant l’extension .COM et 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 sous Vista). mais pas sous 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 son exécution, il génère 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 réputé sûr pour être exécuté, en partie pour permettre de tester les scanners réels sans avoir à capturer un vrai virus et à risquer une véritable infection. Ils souhaitaient également une distribution facile par des moyens conventionnels et non conventionnels. Puisqu'il s'avère qu'il existe un sous-ensemble utile du jeu d'instructions en mode réel x86 dans lequel chaque octet est soumis à la restriction qu'il s'agisse également d'un caractère imprimable ASCII, ils ont atteint les deux objectifs.

Cet article de wiki contient un lien vers une explication détaillée, détaillée . de la façon dont le programme fonctionne réellement qui est également une lecture intéressante. La complexité vient également du fait que le seul moyen d'imprimer sur la console ou de quitter un programme en mode réel DOS consiste à émettre une instruction d'interruption logicielle dont l'opcode (0xCD) n'est pas un caractère imprimable ASCII 7 bits. De plus, les deux interruptions nécessitent chacune un paramètre immédiat d'un octet, dont l'un doit être un caractère d'espacement. Étant donné que la règle auto-imposée ne permettait pas d'espaces, les quatre derniers octets du programme ("H + H *" dans la chaîne) sont modifiés sur place avant que le pointeur d'instruction ne les exécute.

Désassemblage et vidage du fichier EICAR.COM à l'aide de la commande DEBUG à l'invite de commande de mon ordinateur 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 des instructions jusqu'à JGE 0140 , les deux dernières instructions ont été modifiées pour devenir:

0C32:0140 CD21          INT     21
0C32:0142 CD20          INT     20

La plupart des appels système DOS ont été envoyés via INT 21 avec la valeur du registre AH ou AX spécifiant la fonction à exécuter. Dans ce cas, AH vaut 0x09, qui est la fonction de chaîne d'impression, laquelle p