En mi humilde opinión, el objetivo del virus de prueba es tener algo que se sabe que es inofensivo y aceptado como virus para que los usuarios finales puedan verificar que el software AV esté encendido y puede ver el efecto de una identificación de virus. Piensa en simulacro de incendio para el software AV.
Me imagino que la mayoría tiene una firma y la reconoce directamente como tal.
No me sorprendería que el patrón de bits de la prueba EICAR real incluyera patrones de bits que olían a códigos de operación para actividades sospechosas, pero no sé si ese es el caso. Si es así, entonces podría ser una prueba válida de un simple reconocedor de virus heurístico. Sin embargo, dado que la prueba EICAR ha existido durante un tiempo largo, también me imagino que cualquier heurística que lo almacena no es lo suficientemente buena como para atrapar nada ahora en la naturaleza.
No esperaría que el reconocimiento de EICAR sea prueba de ningún reclamo más fuerte que "el AV está instalado y escaneando lo que se esperaba escanear", y si desarrollara un sistema AV, no intentaría hacer nada más fuerte reclamarlo
Actualización:
El virus de prueba EICAR real es el de la siguiente cadena:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
que fue cuidadosamente diseñada (según la Wikipedia article) que tienen un par de propiedades interesantes.
En primer lugar, consta de solo caracteres ASCII imprimibles. A menudo incluirá espacios en blanco y/o una nueva línea al final, pero eso no tiene ningún efecto en su reconocimiento o en su función.
Lo que aumenta la segunda propiedad: de hecho es un programa ejecutable para una CPU 8086. Se puede guardar (mediante el Bloc de notas, por ejemplo) en un archivo con la extensión .COM, y se puede ejecutar en MSDOS, la mayoría de los clones de MSDOS e incluso en el modo de compatibilidad MSDOS del símbolo del sistema de Windows (incluso en Vista, pero no en cualquier Windows de 64 bits, ya que decidieron que la compatibilidad con el modo real de 16 bits ya no era una prioridad.)
Cuando se ejecuta, produce como salida la cadena "EICAR-STANDARD-ANTIVIRUS-TEST-FILE! " y luego sale.
¿Por qué fueron a este esfuerzo? Aparentemente, los investigadores querían un programa que se sabía que era seguro para funcionar, en parte para que los escáneres en vivo pudieran ser probados sin la necesidad de capturar un virus real y arriesgarse a una infección real. También querían que fuera fácil de distribuir por medios convencionales y no convencionales.Como resulta que hay un subconjunto útil del conjunto de instrucciones de modo real x86, donde cada byte cumple con la restricción de que también es un carácter ASCII imprimible, lograron ambos objetivos.
El artículo de la wiki tiene un enlace a un blow-by-blow explanation de cómo funciona realmente el programa, que también es una lectura interesante. Agregando a la complejidad está el hecho de que la única manera de imprimir en la consola o salir de un programa en modo real de DOS es emitir una instrucción de interrupción de software, cuyo código de operación (0xCD) no es un carácter imprimible de ASCII de 7 bits. Además, las dos interrupciones requieren un parámetro inmediato de un byte, uno de los cuales necesitaría ser un carácter de espacio. Dado que la regla autoimpuesta era no permitir espacios, los cuatro últimos bytes del programa ("H + H *" en la cadena) se modifican en su lugar antes de que el puntero de instrucción llegue allí para ejecutarlos.
Desmontaje y el vertido EICAR.COM con el comando DEBUG en un símbolo en mi caja de XP, veo:
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]
Después de ejecutar instrucciones hasta JGE 0140, las dos últimas instrucciones han sido modificados para ser:
0C32:0140 CD21 INT 21
0C32:0142 CD20 INT 20
más llamadas al sistema DOS fueron enviados a través INT 21 con el valor del registro AH o AX especificando la función a ejecutar. En este caso, AH es 0x09, que es la función de cadena de impresión, que imprime la cadena que comienza en la compensación 0x011C, terminada por el signo de dólar. (Había que imprimir un signo de dólar con un truco diferente en DOS puro). La llamada INT 20 finaliza el proceso antes de que se puedan ejecutar los bytes adicionales que pasen por ese punto.
El código de auto-modificación fue un truco temprano de virus, pero aquí se usa para preservar la restricción en los valores de bytes que se pueden usar en la cadena. En un sistema moderno, es posible que la característica de protección de ejecución de datos capte la modificación, si eso se aplica en el modo de compatibilidad MSDOS ejecutando un archivo COM.
¿Cómo se relaciona siquiera esta programación? – user73993
¿Quizás está pensando en cómo escribir un sistema AV? Por supuesto, podría estar pensando en cómo superar ese sistema también ... – RBerteig
Estaba leyendo sobre los mecanismos de detección de virus y cómo implementarlos en los programas. Dado que la heurística y la ciencia forense están relacionadas con la programación, pensé que este era un lugar adecuado para formular la pregunta :) –