He aquí la descripción de la madre de todos los virus.
Sólo quería dejaros esto para que os entretuviéseis. Es el informe sobre el virus Zhengxi, la madre de todos los virus, el mejor del mundo con di- ferencia. Os recomiendo que os acomodéis en la silla, que cerréis persia- nas, descolguéis el teléfono, os desabrochéis la bragueta, os preparéis litros de café, y lo leyéseis con calma, porque tiene tela.
___ Virus Zhengxi ___
El virus Zhengxi es un virus parasítico, residente, infector de ficheros EXE y OBJ, polimórfico y stealth. Además, inserta droppers en formato COM en los ficheros ZIP, ARJ y RAR, además de los EXE self-extracting.
Su tamaño es de tan sólo 7k, y se trata de un virus muy complejo, proba- blemente el virus más complejo que he visto en mi vida. Infecta ficheros EXE, y lo hace de dos formas: o bien de forma parasítica (es decir, modi- ficando la cabecera y escribiéndo su código al final del fichero) o bien, tras haber encontrado subrutinas de tipo C o Pascal en el fichero, sobre- escribiendo una rutina del mismo tipo con un cargador del virus, y escri- biendo la rutina original y el cuerpo encriptado del virus al final.
También, como dijimos, inserta su código en los ficheros OBJ. Estos fi- cheros al ser linkados se convierten en ficheros EXE infectados.
Por último, el virus también introduce droppers en formato COM en los fi- cheros comprimidos con ZIP, ARJ o RAR, usando rutinas internas de descom- presión.
Así pues, tenemos que el virus usa cuatro tipos de infección: EXE appen- ding, EXE inserting, OBJ, y droppers COM. Parece como si pretendiese ser, y de hecho lo es, un 'todo en uno', recogiendo en su código diversas ide- as que aparecieron previamente en otros virus: infección de OBJ (del vi- rus Shifting Objective, de Stormbringer), de ficheros comprimidos (como el virus Dementia), y de EXEs con rutinas tipo C o Pascal (del virus Lu- cretia).
La rutina de desencriptado más compleja que Eugene Kaspersky y, con toda probabilidad, el resto del mundo ha visto en su vida aparece al mirar el código de un fichero EXE infectado. Parece como si fuese una rutina gene- rada por la engine SMEG, de Black Baron, pero muy muy muy mejorada, y mil veces más compleja (hay muchísimas llamadas a rutinas basura, funciones CP/M y de la int 21h, incluyendo llamadas directas a la tabla de vectores de interrupción -IVT-). Esta primera rutina de desencriptado nos descubre otra rutina más (el virus está encriptado con dos loops polimórficos com- plejísimos), que finalmente nos descubre el código vírico. La suma total de la longitud de estas rutinas de desencriptado asciende a más de 2k.
Tras tracear durante horas a través de estas subrutinas, montones de ins- trucciones basura y llamadas a funciones del DOS, el cuerpo del virus a- parece por fin desencriptado, y en él podemos apreciar las siguientes ca- denas de texto:
Abnormal program termination The Virus/DOS 0.54 Copyright (c) 1995 Zhengxi Ltd Warning! This program for internal use only!
+-----------+ ¦ Problemas ¦ +-----------+
El estilo en que está escrito el código del virus Zhengxi es tan extrema- damente complejo que resulta difícil encontrar el propósito de más de cien de sus subrutinas, así como de varios cientos de ramificaciones de las mismas. El virus usa dos tipos distintos de referencias para dirigir- se a los mismos datos: el acceso directo a la dirección (cs:[dirección]), y el acceso indexado (ss:[bp+offset]). A veces el virus usa la primera variante, y a veces la segunda, e incluso los mejores desensambladores (Sourcer, IDA...) no pueden construír las tablas de referencia que nos resultan tan útiles de cara a analizar el código de un virus.
El virus también usa ramificaciones 'escondidas', y es muy difícil encon- trar la dirección de destino de estas ramificaciones, ya que hay varias combinaciones posibles.
Y el último problema que encontramos de cara a analizar el virus es el u- so que éste hace del CRC para comprobar diferentes condiciones, de cara a ejecutar una u otra rutina. Por ejemplo, lo usa para instalarse, para ha- cer las comprobaciones de nombres de ficheros y sus cabeceras, para par- chear diferentes programas, etc.
Un ejemplo: el virus presta especial atención a varios ficheros, pero, a diferencia del resto de los virus que conocemos, no contiene sus nombres entre el código vírico, sino que contiene palabras (2 bytes) de CRC para cada uno de los nombres. Cuando se accede a un fichero, el virus calcula el CRC de cinco caracteres cualesquiera del nombre de dicho fichero, ob- teniendo así una palabra CRC, que va comparando con las correspondientes a los ficheros que requieren una atención especial por su parte, y que se encuentran entre el código vírico, también en formato CRC. Así, tenemos que el virus 'empaqueta' cinco caracteres del nombre del fichero en tan sólo 2 bytes de suma CRC. La rutina inversa a ésta que usa el virus gene- ra aproximadamente 25000 variantes de nombres posibles. El fichero resul- tante con todas estas combinaciones ocupa más de 400k, con lo que nos po- demos ir haciendo una idea de la complejidad del virus.
El virus tiene almacenadas 16 palabras CRC, es decir, a fin de cuentas, 16 nombres de ficheros a los que presta una atención especial por distin- tos motivos. Ahora mismo hay 11 de esos 16 nombres encontrados, es decir, que se ha averiguado a qué programa corresponden:
1: UUENC - UUENCODE.EXE 2: PKLIT - PKLITE.EXE 3: LZEXE - LZEXE.EXE 4: NDD.E - NDD.EXE (Norton Disk Doctor) 5: DIET. - DIET.EXE 6: AFD.E - AFD.EXE 7: SD.EX - SD.EXE (SpeedDisk) 8: SPEED - SPEEDDSK.EXE 9: DEFRA - DEFRAG.EXE * 10: TLINK - TLINK.EXE 12: LINK. - LINK.EXE
En el 10 (*) hay otra variante, AVSCA (AVSCAN.EXE), que se corresponde con el conocido antivirus alemán. Por lo tanto, aún nos quedan cinco de esos 16 nombres sin identificar. Hay muchísimos nombres posibles, y puede ser que se correspondan con nombres de herramientas sobre las que casi nadie ha oído hablar, por lo que aún no han sido identificados. Algunas de las variantes 'legibles' son las siguientes:
11: APPET CGAQW CPUOS FANTY GO.OF MSTST SETIM TARAV TMBRK TPPSA 13: CCPUB GAPP1 SADIB SVCAP VKEYV 14: FDARI FDLEV MTFFD PUEL. RAR3W SDNDW SLIP4 15: CDHK. FMK91 FSIPO MSDKV NDA36 REL1. RUNNO 16: KKBUG RTM32 SDSAT TDROM VADZZ VERT2
Tras haber encontrado la mayor parte de los nombres, aún nos espera otro plato fuerte: el virus también usa CRCs para analizar la cabecera de los ficheros antes de infectarlos. El Zhengxi tiene una tabla que consta de ocho CRCs (y ya van 24 en total); el proceso de comprobación de ficheros válidos para infectar consiste en calcular la suma por CRC de los cuatro primeros bytes de la cabecera y compararla con los CRCs de su tabla. Tras hacer esto, repite el proceso, disminuyendo el número de bytes a calcular de la cabecera hasta dos y uno.
Con la rutina inversa encontramos muy rápido cuatro de las ocho varian- tes: la variante de un byte, de la cabecera OBJ (80h), dos variantes de dos bytes, correspondientes a la cabecera EXE ('MZ' y 'ZM'), y otra más de dos bytes, la de los ficheros comprimidos con ARJ (60eah). El resto de las variantes eran las de cabeceras de cuatro bytes, y aparecieron dos de ellas: la de ficheros ZIP (504b0304h), y la del RAR (Rar!). Las otras dos cabeceras que nos faltan de momento no están identificadas. La primera de ellas parece corresponder a los ficheros generados por otro compresor, ya que la rutina a la que le da el control está muy cerca de las rutinas de descompresión de ARJ, ZIP y RAR, además de usar las mismas subrutinas de infección que éstas. Por estos mismos motivos, también parece ser que la octava y última variante que nos falta está relacionada con los ficheros de formato OBJ.
Para encontrar estas variantes, la rutina inversa estuvo trabajando dos días seguidos y sin interrupción en un 486/66Mhz. El resultado fue de na- da más y nada menos que 65000 variantes para cada suma CRC. Además, como los bytes están 'empaquetados' dentro de dos bytes de CRC, la operación inversa nos da 65000 variantes de cada 'fuente' de cuatro bytes. Los fi- cheros resultantes y correspondientes a cada suma CRC ocupaban más de 1Mb de longitud. Ni qué decir tiene que las combinaciones posibles ascendían a más de 260000 (65000*4). A pesar de esto, ya conocemos seis de ocho.
+-------------+ ¦ Instalación ¦ +-------------+
El código del virus recibe el control desde distintos puntos, dependiendo del modo de infección, pero de todas formas el destino siempre es la ru- tina polimórfica de desencriptado. En los ficheros EXE (appending) la ru- tina de desencriptado recibe el control inmediatamente cuando el EXE es cargado en memoria para ejecutarse; en los ficheros EXE (inserting), ésta recibe el control del cargador del virus (ver infección de EXE); en los ficheros OBJ linkados, desde un call (ver infección de OBJ), y, por últi- mo, en los droppers en formato COM, la ejecución comienza con un jmp, que salta directamente al desencriptado.
Una vez desencriptado, la rutina de instalación del virus recibe el con- trol. Primero, el virus mueve su código para así alinearse por párrafos (16 bytes); engancha la int 1 (traceo paso a paso), y tracea la int 21h.
El virus llama a una función bastante inusual para hacerlo: la llamada 19h del CP/M (obtener unidad actual). Esta llamada CP/M le da el control al handler de la int 21h original del DOS tras haber ejecutado algunas instrucciones, y entonces es cuando el virus empieza a tracear el código de la int 21h original.
Al tracear este código, el handler es interrumpido tras cada instrucción ejecutada. El virus entonces recibe el control, y calcula el CRC (una vez más) de 12 bytes del código de la int 21h. Si el CRC es igual a una de dos posibles variantes, el virus parchea este código, y se instala resi- dente en memoria.
Es absolutamente imposible encontrar las variantes de código que busca el virus. Los 12 bytes de código están empaquetados en 2 bytes de posibles variantes, la primera y la segunda. El resultado de la operación inversa nos da más 2*10000000000h variantes de código... y no, no me he equivoca- do al poner la 'h' después del número... no es un número binario ni deci- mal, sino *hexadecimal*. Por tanto tenemos que el único medio de investi- gación consiste en probar diferentes DOSs en diferentes modos (alto o ba- jo), y mirar cómo ha parcheado el virus la int 21h.
Por el momento sólo se encontró una variante de código que parchea el vi- rus, y que se corresponde con parte del handler de la la int 21h del DOS 5.x/6.x; el dump hexadecimal es así:
06 1E 55 57 56 52 51 53 50 8C D8 (push/push/.../push/mov ax,ds)
Si el virus encuentra este código, comprueba distintas condiciones antes de hacer el parcheo, y termina su instalación en determinados casos:
+----------------------------------------------------------------------------+ ¦ Comprueba ¦ int,ax ¦ Termina su instalación en caso de... ¦ +--------------+-----------------+-------------------------------------------¦ ¦ ¿Windows? ¦ 2fh,1600 ¦ Windows instalado ¦ +--------------+-----------------+-------------------------------------------¦ ¦ Unidad ¦ 21h,3305 ¦ La unidad de disco es A: o B: ¦ +--------------+-----------------+-------------------------------------------¦ ¦ int 8, 13h, ¦ Acceso directo ¦ Todas estas interrupciones apuntan al ¦ ¦ 28h ¦ a la tabla de ¦ mismo segmento (¿comprobación de si al- ¦ ¦ ¦ vectores (IVT) ¦ gún AV residente está en memoria?) ¦ +--------------+-----------------+-------------------------------------------¦ ¦ Fecha del ¦ 21h,2fh,1ah, ¦ El día el fichero es el mismo o está ¦ ¦ host (cam- ¦ 4eh (obtener, ¦ cercano al actual (si los dos bytes más ¦ ¦ po del día) ¦ fijas DTA, ¦ altos del número de día en xor con la ¦ ¦ ¦ findfirst) ¦ fecha del fichero son iguales a cero) ¦ +----------------------------------------------------------------------------+
Si las condiciones de arriba cumplen con los requisitos del virus, éste continúa su instalación. Reubica el bloque de memoria del sistema usan- do las funciones del DOS ChangeMem y AllocateMem (int 21h, ah=4ah, 48h), dejando espacio para la copia residente del virus, y entonces almacena en su código 11 bytes de la dirección del handler de la int 21h para luego parchear el código de esta int con un far call (2fh ffh 1eh ?? ??).
¿Y cuál es la dirección a la que apunta este far call? cualquiera con un mínimo de idea respondería que a su propio handler de la int 21h. Pues de eso nada. El destino es la dirección de la int 25h (absolute disk read).
La siguiente sorpresa consiste en que el virus guarda los cinco primeros bytes del handler de la int 25h, y escribe allí cinco bytes nuevos, que conforman un far jmp al código vírico. El resultado queda así:
El virus sitúa una 'palabra mágica', 06c7h, justo después del call far a la dirección de la int 25h. En principio no parece haber otra razón para hacerlo que para ocultar el parcheo en el código desensamblado. El resul- tado de este parcheo es un código normal, sin comandos extraños.
Por lo tanto, el virus tiene el mismo handler para interceptar la int 21h y la int 25h. Para separar las llamadas a ambas ints, el virus chequea la dirección del programa que las llama (caller_ip); si la llamada va diri- gida a la int 21h, el virus le pasa el control a la rutina del handler de la int 21h propia. En otro caso, el que recibe el control es el handler que usa el virus para la int 25h.
Por cierto, os habréis dado cuenta que el virus no usa ningún chequeo de instalación para evitar ir residente más de una vez. La razón es simple, ya que antes de instalarse, el virus busca código específico en el han- dler de la int 21h y lo modifica. Una vez instalado, ese código no estará presente, por lo que el virus no se (re)instalará.
La rutina de instalación está completa; el código vírico está copiado en un bloque de memoria del sistema, y las ints 21h y 25h ya están intercep- tadas. Pero aún falta por decir que el virus es capaz de mover su código a otros bloques de memoria (ver el análisis del handler de la int 21h). Por tanto, la copia residente del virus no ocupa los mismos bloques de memoria del sistema, y puede moverse a otras direcciones, incluyendo las del UMB.
Una vez instalado, el virus retorna el control al fichero host. Éste tie- ne tres métodos distintos de hacer dicho retorno, dependiendo del tipo de infección. En caso de haberse instalado desde el dropper COM, el virus se limita a enseñar el mensaje:
Abnormal program termination
Y luego retorna al DOS con la función terminate (int 21h, ah=4ch). En ca- so de haberse instalado desde un EXE infectado con el método appending, el virus restaura la cabecera original usando la engine polimórfica (ge- nera una rutina polimórfica de desencriptado y la ejecuta para así poder restaurar la cabecera original; ver infección de EXE). Si el fichero host es un EXE infectado por el método de inserción, el virus simplemente re- torna al host, ya que el cargador del virus insertado en el código res- taura automáticamente el código original. Por último, en caso de ser un fichero OBJ, el virus también se limita a retornar al host (ver infección de OBJ, más abajo).
+----------------------------------------------------------------------+ ¦ Handler de la int 21h ¦ ¦ El Zhengxi intercepta 18 funciones de la int 21h: ¦ +----------------------------------------------------------------------¦ ¦ 3dh, 6ch - Apertura/apertura extendida ¦ ¦ 3eh - Cierre de fichero ¦ ¦ 3fh - Lectura de fichero ¦ ¦ 42h - Movimiento del puntero ¦ ¦ 4bh - Ejecución de un programa ¦ ¦ 41h - Borrado de un fichero ¦ ¦ 11h, 12h - FindFist/FindNext por FCB ¦ ¦ 4eh, 4fh - FindFist/FindNext ASCII ¦ ¦ 00h, 4ch - Terminate ¦ ¦ 31h - Fin y paso a residente ¦ ¦ 67h - Definición del contador de handles ¦ ¦ 48h, 49h, 4ah - Mantenimiento de memoria ¦ +----------------------------------------------------------------------+
El virus lleva a cabo dos acciones para cada una de las funciones inter- ceptadas: cuando recibe el control chequea el número de la función, y e- jecuta la subrutina correspondiente. Entonces le pasa el control al han- dler original de la int 21h, pero lo hace con la instrucción call, en lu- gar de hacerlo con un jmp.
Como resultado, el virus recibe el control una vez o más cuando el han- dler de la int 21h completa la función y devuelve el control a la rutina desde la que ha sido llamado. En este momento el virus lleva a cabo una llamada a una segunda subrutina:
_ Handler del Zhengxi
comprueba función call rutina_1 ; la dirección depende de la función call handler original int 21h call rutina_2 ; la dirección depende de la función retorno
Nota 1: las etiquetas 'rutina_1' y 'rutina_2' se usan como identificado- res de las rutinas que son llamadas por el virus con anterioridad, y tras haber ejecutado la llamada a la int 21h.
Nota 2: el Zhengxi usa dos métodos para saber si los ficheros ya han sido infectados. El primer método consiste en chequear la longitud del fiche- ro. Todos los ficheros infectados tendrán como longitud un valor que, di- vidido por 9dh da 25h como resto.
Para detectar los ficheros EXE infectados (método appending), el virus comprueba otra condición: obtiene los valores de los registros de segmen- to CS y SS, y el registro índice SP; entonces compara CS con SS, y com- prueba el registro SP. En los ficheros infectados por el Zhengxi el valor de CS es igual a SS+1, y el registro SP contiene un número comprendido entre 0080h y 008fh.
El control de las funciones 67h, 48h, 4ah y 4bh está utilizado por el vi- rus para esconder su código entre la memoria del sistema (el virus mani- pula los bloques MCB en memoria), ubicando un nuevo bloque de memoria, ya sea convencional o un bloque de memoria UMB, y copiándose allí para luego redirigir la dirección de la int 25h a la nueva posición en memoria.
Al abrir un fichero (ah=3dh, 6ch), el virus efectúa una llamada a dos ru- tinas, 'rutina_1' y 'rutina_2'. La rutina_1 chequea el modo de apertura; si el fichero ha sido abierto en modo escritura, el virus desinfecta el fichero sobre la marcha (disinfect on the fly).
Antes de desinfectarlo, el virus comprueba si el fichero abierto está in- fectado usando el primer método (división por 9dh y resto igual a 25h); posteriormente comprueba si el fichero es local o remoto (no accede a los discos remotos), y mira los punteros CS, SS y SP de la cabecera EXE. Tras haber hecho esto, finalmente compara el nombre del programa que abrió el fichero usando los CRCs con la lista de los 16 'programas fatídicos', y no lo desinfecta en caso de coincidencia.
En caso de apertura con ah=3d00h (read-only), el virus lleva a cabo cier- tas acciones extrañas. Comprueba el código del programa que abrió el fi- chero y lo parchea. Parece como si estuviese intentando parchear algún antivirus o alguna utilidad por el estilo.
La rutina_2 para la función de apertura le da el control a la rutina de stealth (el virus sustituye la longitud del fichero infectado por su lon- gitud original), usando una SFT (System File Table) indocumentada para e- se fichero.
Al leer un fichero (ah=3fh) el virus llama a la rutina stealth. En caso de leer alguno de los bytes de la cabecera de un fichero infectado, el virus lee, desencripta y copia la cabecera original en el búfer de lectu- ra, de forma que no se apreciarán cambios en el fichero.
Al mover el puntero (ah=42h), el Zhengxi llama a otra rutina stealth que, usando también las SFTs, impide que se llegue hasta el final del fichero, restando justo el tamaño del virus.
Al borrar un fichero infectado (ah=41h), el virus lo desinfecta.
Al buscar ficheros (ah=11h, 12h, 4eh, 4fh), el virus sustituye la longi- tud de los ficheros infectados con la longitud original, usando el mismo método que en la apertura para saber si un fichero está infectado o no.
Las llamadas al FindFirst/FindNext ASCII también son usadas por el virus para infectar. El Zhengxi guarda el nombre de uno de los ficheros encon- trados por FindFirst, y el del quinto fichero, aproximadamente (probabi- lidad 3/16), encontrado por la función FindNext. El virus sólo tiene un búfer para almacenar nombres de ficheros, por lo que el siguiente nombre sobreescribe al anterior.
Finalmente, al cerrar un fichero (ah=3eh), el virus busca e infecta el fichero cuyo nombre conserva en su búfer. Además, también infecta el fi- chero que se está cerrando, sólo que con una probabilidad 1/4 (el resul- tado sale de un randomizer propio).
+-----------+ ¦ Infección ¦ +-----------+
Antes de infectar, el Zhengxi comprueba algunas condiciones:
- El fichero no acaba de ser creado, es decir, no es un fichero recien- te, comparando el número de día actual con la fecha del fichero y el 'sello' o marca del fichero (igual que al instalarse). - El fichero es local, y no está ni en A: ni en B: - El fichero no es *.?V? (*.OVL?) - Hay suficiente espacio en el disco (lo comprueba con ah=36h, int 21h)
En caso de cumplirse estas tres condiciones, el virus lee la cabecera y mira si es válida usando CRCs (ver problemas). El virus infecta tres ti- pos de ficheros: EXE, OBJ y ficheros comprimidos.
También hay que destacar que el virus no sólo comprueba la cabecera, sino que también comprueba otros puntos y campos del fichero para prevenir la destrucción de ficheros de datos.
-* Infectando ficheros EXE *-
Lo más interesante del virus es cuando infecta ficheros EXE. Puede hacer- lo de tres formas: anexándose al final (appending), insertándose (inser- ting) o infectando EXEs autoexpandibles (self-extracting).
Primero el Zhengxi mira la estructura del fichero; en caso de ser un fi- chero autoexpandible (creado con ZIP2EXE, por ejemplo), el virus infecta el fichero adjunto (ZIP, ARJ, RAR) usando el método descrito más abajo: crea un dropper en formato COM y se anexa al fichero.
Después mira la longitud. Hay que destacar que no infecta los ficheros que ocupan menos de 400h (1024) bytes. Además chequea otros campos en la cabecera EXE, como el número de ítems de relocación, marcas de empaqueta- dores (PkLite: el Zhengxi infecta ficheros comprimidos con PkLite), y los campos de longitud. Si la longitud del módulo EXE (ojo, NO la longitud del fichero) es mayor que 32k, el virus inserta su cargador en medio del fichero. Si no, el virus infecta el fichero usando el método appending.
Al infectar ficheros por este método, el virus lee la cabecera, la en- cripta y la guarda al final del fichero. Entonces ejecuta su generador polimórfico y guarda el cuerpo del virus encriptado y los loops polimór- ficos al final del fichero. Para acabar la infección, el virus incrementa la longitud del fichero hasta un valor que, dividido por 9dh, dé de resto 25h (su marca de infección), y modifica los punteros de la cabecera EXE.
Es necesario decir que el virus encripta la cabecera original del host con un loop de encriptación polimórfica, y ese loop es distinto que el de la rutina usada para encriptar el cuerpo del virus; es decir, que el vi- rus llama dos veces a su engine polimórfica: al encriptar la cabecera o- riginal y al encriptar el código vírico.
Durante la ejecución de un fichero EXE infectado, los loops de desencrip- tado 'limpian' el cuerpo del virus, pero la cabecera original permanece encriptada; por tanto, al ejecutar el host el virus tiene que hacer un desencriptado extra, el de la cabecera original. También hay que tener en cuenta que la engine polimórfica genera loops aleatorios con funciones de encriptación también aleatorias, por lo que el desencriptado de la cabe- cera parece imposible... pues no lo es. Para resolver este problema, el virus almacena los valores iniciales del randomizer usados al encriptar los datos del host, y ejecuta el generador polimórfico con los mismos va- lores para el desencriptado. Como resultado, el generador obtiene el mis- mo código que el que fue usado al encriptar los datos del host y, siendo ejecutada esa rutina, consigue desencriptarlos.
-* Infectando ficheros EXE (inserting) *-
Si el tamaño del fichero es superior a 32k, el virus mueve el puntero al principio del módulo principal del EXE (justo después de la cabecera EXE) para leer 6k de código, entre los que busca rutinas de C o Pascal. Estas rutinas suelen empezar con la misma 'cabecera', salvando el registro BP y moviendo allí el puntero de pila (SP):
+---------------------------------------------------+ ¦ Cabecera en C ¦ Cabecera en Pascal ¦ +------------------------+--------------------------¦ ¦ 55 push bp ¦ 55 push bp ¦ ¦ 8B EC mov bp,sp ¦ 89 E5 mov bp,sp ¦ +---------------------------------------------------+
Usando el mismo método CRC, el virus busca este código en el fichero. Si no lo encuentra, el virus le pasa el control directamente a la infección de tipo appending. En caso de éxito, el virus busca en los siguientes 54h (80) bytes de código un ret o un call far (c3h, cbh, cfh, 9ah, cah, c2h) para no pasarse a la siguiente subrutina o dirección relocalizada (la pa- labra que hay en esa dirección es modificada por el DOS al cargar el fi- chero EXE para ejecutarlo). Si se encuentra ese código, el virus abandona la rutina de infección.
Si no, el Zhengxi sobreescribe esos 54h bytes con el código del cargador del virus, encripta el código principal con su engine polimórfica, y se copia al final del fichero. Después de esto, al igual que hacía con el o- tro tipo de infección (appending), escribe un número indeterminado de by- tes aleatorios para usarlos como marca de infección.
Al ejecutar el cargador del virus, éste busca el nombre del host en los campos correspondientes del PSP (Program Segment Prefix), abre el fichero para luego mover el puntero al final, y allí leer, desencriptar y ejecu- tar la segunda parte del dropper. Esta parte restaura la subrutina par- cheada, ubica la memoria del sistema (convencional o UMB), lee el cuerpo del virus y le da el control al loop de desencriptado polimórfico. Con el loop desencripta el cuerpo del virus y le pasa el control a la rutina de instalación; el virus se instala en la memoria del sistema y le devuelve la ejecución al fichero host.
Éste es un tipo de infección muy insidioso. El código vírico está escon- dido en el fichero, y no hay una entrada directa hacia el mismo desde la cabecera del fichero. El virus se inserta a sí mismo en lugar de una de las subrutinas del host. Incluso puede tratarse de una subrutina rara vez ejecutada. Por ejemplo, una subrutina que muestre un mensaje de error por pantalla. De esta forma, el virus está en estado 'latente' durante un largo período de tiempo, hasta que un buen día 'sale al exterior' e in- fecta el sistema bajo determinadas condiciones.
-* Infectando ficheros comprimidos *-
En este tipo de infección, el virus crea en memoria la imagen de un fi- chero COM infectado, un dropper, y lo introduce en el fichero comprimido. Este dropper siempre empieza con un jmp seguido de datos aleatorios, el virus encriptado, y el loop de desencriptado polimórfico. Esta instruc- ción (jmp) salta directamente al inicio del loop.
El nombre del dropper también es aleatorio, y lleva extensión .COM; he a- quí algunos ejemplos de los nombres que puede llegar a tener:
HAIF.COM, UCM.COM, DOO.COM, VLG.COM, etc.
Para procesar los ficheros comprimidos y todos sus campos, el Zhengxi no se ayuda de ninguna utilidad externa, sino que usa sus propias rutinas de descompresión de ARJ, ZIP y RAR. Sin embargo, el virus no comprime el có- digo del dropper; simplemente lo guarda en modo 'stored'.
El virus no introduce su dropper en los ficheros comprimidos con PkZip en caso de que dentro de éstos haya algún otro fichero ya comprimido con es- te método (store). También hace una comprobación de ciertos valores y, en caso de encontrarlos, tampoco introduce su dropper.
Esto está pensado para no introducir el dropper en más de una ocasión dentro de los ficheros comprimidos; es decir, que usa el método de com- presión, o mejor dicho, de no compresión 'store' además de ciertos valo- res como marca de infección.
-* Infectando ficheros OBJ *-
Al infectar módulos OBJ, el Zhengxi comprueba primero los campos del fi- chero OBJ, y crea e inserta allí nuevos registros OBJ, dentro de los cua- les se encuentra el código vírico encriptado con los loops polimórficos.
Cuando el virus chequea los ficheros OBJ, analiza su código, buscando al- guna cabecera correspondiente a subrutinas escritas en C o Pascal, al i- gual que como hace en el tipo de infección inserting. Sólo infectará los OBJ que contengan este código. En caso contrario, el virus no escribe el código del cargador, pero sí que sobreescribe una cabecera de C/Pascal, consistente en un call (e8h xx xx).
Estos ficheros OBJ son linkados y convertidos a ejecutable, y el call anterior pasa a llamar al loop de desencriptado polimórfico. Con ese loop se desencripta el código vírico, y se le pasa el control a la rutina de instalación del virus. Antes de devolver la ejecución al host el programa restaura la cabecera C/Pascal, sobreescribiendo el call con los tres by- tes de la cabecera de la subrutina en C (558bech).
Al igual que pasaba en los EXEs con subrutinas en C o Pascal, puede que este call nunca se ejecute, por lo que el virus puede estar inactivo du- rante mucho tiempo.
Por último, simplemente reseñar que el virus no infecta el mismo módulo OBJ dos veces, ya que antes de infectar comprueba si en determinados cam- pos del fichero están 'sus' valores, los que usa como marca de infección.
+-----------------------+ ¦ Handler de la int 25h ¦ +-----------------------+
Otra de las rutinas inusuales es la correspondiente al handler de la int 25h. Al recibir el control, esta rutina ejecuta un algoritmo stealth en el nivel de la int 25h. Al acceder a entradas de directorio el virus sus- tituye la longitud de los ficheros con la longitud original, y al leer la cabecera de un fichero infectado, restaura la original, por lo que no se aprecia ninguna diferencia entre un fichero infectado y uno limpio si el virus está residente en memoria.
Así, si un antivirus lee los contenidos de los ficheros usando funciones de la int 21h, el virus permanecerá invisible, y el sistema estará apa- rentmente limpio.
+---------+ ¦ Payload ¦ +---------+
El virus sólo tiene un payload o rutina de activación, excepto la que usa para retornar al DOS desde un COM. Esta rutina puede ser ejecutada mien- tras se están procesando los ficheros ZIP. Si el virus encuentra algún registro empaquetado con el modo 'stored', chequea la fecha, la hora y el 'sello' o marca del ZIP. Si el año de la última modificación es igual o superior a 1996, el virus busca todos los ficheros de todos los directo- rios, desde la C: hasta la Z:, y los borra, incluyendo el árbol de subdi- rectorios.
Para borrar los ficheros, el virus usa las funciones FindFirst/FindNext (4eh/4fh), SetAttrib (43h), Delete (41h), RemoveDir (3ah), y otras.
[Indice general] - [Sexo] - [linux] - [humor] - Chat entre usuarios - [miscelanea] - [Novedades]
