Análisis de virus: Predator 2
Por Fernando Bonsembiante


Hay un virus nuevo que en muy poco tiempo se convirtió en epidemia en
Argentina: el Predator 2. Veremos como funciona y por qué puede ser que
se haya difundido tanto.

El virus Predator fue escrito por Priest, un miembro del grupo de
creación de virus Phalcon/Skism. En el número 11 de la revista 40HEX, de
dicho grupo, salió publicado el código fuente de una versión anterior
del virus, un infector de .com con algunas características ligeramente
stealth y encripción variable. No es polimórfico, aunque trata de variar
levemente la rutina de desencripción en cada infección. El stealth que
usa es simplemente esconder el aumento en la longitud del programa
infectado. Si se mira el archivo con algún programa o si se chequea con
un testeador de integridad, aún estando el virus en memoria se vería que
el archivo está cambiado.

Predator 2

Esta nueva versión del virus está basada en la primera, aunque agrega a
la anterior una gran cantidad de técnicas interesantes. Infecta .com,
.exe, sectores de boot en diskettes y tablas de partición en discos
rígidos. Esta característica, que lo convierte en un virus multipartito,
puede explicar por qué se expandió tanto por el país. También,
obviamente, ayudó a eso que se haya distribuido deliberadamente desde el
BBS de intercambio de virus de Buenos Aires, Satanic Brain. Y también
podemos agregar que la mayoría de los antivirus que se usan en el país
lo detectaban solamente en los archivos, y no lo buscaban en los
sectores de boot. Además de ser multipartito, tiene una técnica muy
interesante de tunneling, que lo hace invisible a la mayoría de los
chequeadores residentes de comportamiento. Puede modificar un archivo
ejecutable o un boot sector sin que ningún residente se entere. Por otro
lado, la rutina de encripción variable se mejoró muchísimo con respecto
a la versión anterior. No es polimórfico todavía, pero el desencriptor
es mucho más variable y utiliza distintos mecanismos de encripción
además de usar distintas claves. A pesar de que la rutina es muy
variable, quedan las suficientes instrucciones constantes como para
detectar el virus con una cadena simple de identificación.

La rutina de desencripción es así:

PUSH CS ; Copia CS a DS
POP DS

; Desencripta el virus desde el final. CX = 1213 words,
; 2426 bytes + 22 del desencriptor = total de 2448 bytes.
; Clave de encripción (variable) en AX

MOV DI,01A92
MOV AX,01964
MOV CX,04BD

DESENCRIPTAR:

DEC CX
JS BEGIN ; si termina, ejecuta el virus

ROR W[DI],CL ; método de encripción
XOR W[DI],AX ; variable

DEC DI
DEC DI
JMP DESENCRIPTAR

Además de esto, tiene el mismo grado de stealth que su predecesor.

Funcionamiento

El virus puede haberse cargado en memoria desde un archivo ejecutable o
desde un sector de booteo. Su funcionamiento no varía en los dos casos,
lo que cambia es su método de carga y de tomar las interrupciones.
Empecemos describiendo su carga y funcionamiento como si entrara desde
un archivo.

Lo primero que hace es poner BP en 0 para saber que está siendo cargado
desde un archivo. Luego va a llamar a la interrupción 13h con 50FDh en
AX. Si el virus está residente en memoria debe devolver FD50h en AX. Si
está residente, vuelve al programa infectado sin hacer nada. Si no está
residente, busca el final de la memoria libre, cambia el valor de la
memoria disponible para el DOS, reservando lugar para el virus, y se
copia al final de la memoria. Cuando está copiado, empieza a ejecutar
este código apilando en el stack la dirección a donde fue copiado, y
luego haciendo un return far a este lugar. Si el virus no estaba
residente, recupera el comienzo del programa original que había
modificado, en caso de que sea un .com, y salta al principio del
programa. En el caso de que Predator no estuviese previamente en
memoria, va a capturar las interrupciones 13h (40h en caso de que no
haya disco rígido) y 21h. Primero guarda los valores actuales de las
interrupciones en variables, y toma la interrupción 13h, redefiniéndola
con su propio código. En el caso de que no haya disco rígido instalado,
lo hace con la interrupción 40h. Luego continúa con la interrupción 21h.
Pero en este caso hace algo muy interesante. Antes de hacer apuntar la
interrupción 21h a su propio código, lo que va a hacer es instalar las
rutinas de tunneling.

Tunneling

El virus busca el punto de entrada a las interrupciones 21h, 13h y 40h
definidos por el DOS y el BIOS originalmente. De esta forma el virus
evita ser detectado por controladores residentes de comportamiento. Para
hacer esto, lo que hace es seguir la ejecución de estas interrupciones
paso a paso, usando el trap flag del procesador, que genera una
interrupción 01h cada vez que procesa una instrucción. El virus busca el
segmento del DOS utilizando la función 52h de la interrupción 21h, para
luego buscar el código original del DOS. Redefine la interrupción 01h
con un código que buscará los puntos de entrada originales de estas
interrupciones. A continuación, enciende el trap flag del procesador y
llama a las interrupciones 13h, 21h y 40h. El handler de la interrupción
01h es el que hace todo el trabajo de tunneling. Compara el segmento
desde donde se está ejecutando cada interrupción con el del DOS en caso
de la 21h y con uno comprendido entre C800 y F000 en caso de las
interrupciones 13h y 40h. Cuando el código se empieza a ejecutar en esos
segmentos, guarda el valor del offset donde empieza el código, apaga el
trap flag, y deja de seguir paso a paso la interrupción. De esta forma
obtiene los puntos de entrada originales. A partir de este momento, todo
lo que haga el virus para infectar lo hará a través de los vectores
originales, de esta forma ningún programa residente podrá notar sus
intentos de modificar el sector de booteo o archivos. Ahora, para
redireccionar la interrupción 21h a su propio código, hace otro truco
muy interesante. Intercambia los 5 primeros bytes de la interrupción 21h
original del DOS por un jump far a el handler de la interrupción
definido por el virus. Los 5 primeros bytes quedan en el lugar donde
antes estaba almacenado este código. Para esto usa una rutina que cada
vez que se llama intercambia el código, de esta forma activando o
desactivando la interrupción 21h del virus. De esta forma, cada vez que
se ejecute la interrupción 21h se ejecutará en su lugar la del virus,
pero a partir del código y la dirección de la interrupción original.
Esto lo hace solamente si el primer byte del código de la interrupción
no es un jmp far o una interrupción 03h (breakpoint), para no tener
conflicto con programas que hagan algo similar a él. Entonces, la
secuencia de llamado de la interrupción 21h sería como vemos en el
gráfico. Si el código de la interrupción 21h empezaba con un jmp far o
con un breakpoint, simplemente toma la interrupción 21h desde la tabla
de interrupciones como si fuese un residente normal. En ese caso,
desactiva la rutina que intercambia el jump far al virus por el
principio de la int 21h.

Infección del boot

Después de hacer todo esto, ya instalado en memoria, va a intentar
infectar la tabla de particiones. Lee el sector 1, cilindro 0, del
primer disco rígido, y compara el principio con los ocho primeros bytes
del código de su propio boot sector infectado. Si estaba infectado,
vuelve al programa original y termina.

Si no está infectado, encripta la tabla de particiones recién leída y
luego lo hace con todo el virus. Estas encripciones son siempre iguales,
no intenta modificar la clave ni el método. A partir del sector 2 del
cilindro cero, un área no usada por ninguna partición, guarda la tabla
de particiones original y el virus en seis sectores contiguos. Luego
infecta la tabla de interrupciones, copiando primero un desencriptor y a
continuación el código de boot del virus, encriptado con una clave al
azar. El desencriptor es siempre igual, sólo cambia el valor de la
clave. Una vez que la tabla de particiones está infectada, simplemente
la escribe en el disco rígido en el lugar de la anterior.

Interrupción 13h

La interrupción instalada por el virus tiene dos puntos de entrada,
según si el virus se instaló desde boot o desde un archivo. Vamos a ver
por ahora lo que hace si el virus entró desde un archivo, para más
adelante ver qué pasa si entró desde el boot sector.

El handler instalado por el virus en la interrupción 13h (o 40h si no
había disco rígido), cumple tres funciones. Una es verificar la
presencia del virus en memoria, mediante la función 50FDh. Si recibe ese
pedido, devuelve FD50h en AX. Si la función llamada es leer el sector 1
del cilindro 0 de cualquier disco, o sea, el sector de booteo, se
activan las otras dos funciones. Para elegir cual de las dos usar,
verifica si el boot leído estaba previamente infectado. Si es así, se
activa la rutina de stealth. Lo que hace es leer el boot record guardado
por el virus en el disco, desencriptarlo, y copiarlo al buffer donde el
programa que llamó a la interrupción lo espera. De esta forma, lo que se
verá será el sector sin infectar. Si no está infectado, y se trata de un
diskette, se activa la tercer rutina, con la cual lo infectará. No
intenta infectar discos rígidos, porque ya lo intentó al cargar el
programa infectado por primera vez. Con los diskettes, lo que hace es
redefinir el boot record para que parezca que tienen una pista menos.
Luego de esto, copia al final del disco, en la pista que definió como
que no existe, el virus encriptado, de la misma manera que vimos antes,
salvando el boot original, e infectando el nuevo boot al igual que con
los discos rígidos.

Interrupción 21h

Lo primero que hace al entrar a la interrupción 21h redefinida por el
virus es reponer los 5 bytes que modificó en el DOS, para que funcione
normalmente. El virus chequea si se intenta hacer buscar un archivo,
funciones find first o find next del DOS. Dependiendo si se está
haciendo esta función con handles o con FCB lo trata de una forma
distinta. Lo que intenta hacer es mostrar el tamaño del archivo donde
esté el virus como si no estuviese infectado, y recuperar la fecha
original del mismo, ya que suma 200 al año del archivo como marca de su
presencia. Aquí hay un gran bug. La rutina de manejo de FCB tiene los
offsets del FCB mal definidos. No entendemos como le pudo pasar esto al
autor del virus, ya que la versión anterior manejaba esto bien. En el
caso de handles lo maneja bien. Lo que hace es llamar a la int 21h
original. Con lo que retorna, si el año del archivo es mayor a 200, le
resta su longitud al campo tamaño del archivo y 200 al campo fecha del
bloque de control de find first o find next. En el caso de que se use
FCB, lo hace mal, y modificaría otros campos que pueden causar desde
nada en absoluto hasta corrupción de datos en el disco, dependiendo de
lo que haga el programa que use esos datos. Luego de hacerlo, vuelve de
la interrupción después de volver a reemplazar los primeros 5 bytes de
la interrupción 21h.

Otras funciones que chequea son open (abrir archivo), exec (ejecutar
programa) o extended open or create (abrir o crear archivo). En el caso
de esta última, lo único que hace es mover SI a DX para que el formato
de llamada sea igual a la función open normal, y luego sigue con la
rutina que trata open. Si exec no es load and execute (cargar y
ejecutar), no hace nada, y vuelve. A continuación, entra en la rutina de
infección de archivos. Redefine la interrupción 24h para que siempre
retorne fail en los errores críticos. Antes de infectar, se fija si el
archivo al que se hace referencia es algún antivirus de los que tiene en
una tabla encriptada. La tabla contiene lo siguiente: PROT SCAN CLEA
VSAF CPAV NAV. DECO

Obviamente se trata de F-Prot, Scan de McAfee, Clean de McAfee, Vsafe de
McAfee, CPAV (Central Point Anti Virus), NAV (Norton Anti Virus) y otro
que no conocemos que contiene las letras DECO dentro de su nombre. La
misma rutina que hace esto pone en DI 0 si el archivo es .com. Si es un
anti virus de estos no lo infecta. Si no lo es, se fija si el archivo
tiene el atributo de system. Si es así, no lo infecta. Si va a
infectarlo, borra todos los atributos del archivo (para evitar que esté
como read only), y lo abre. Verifica con la fecha si está infectado, y
si no lo está procede con la infección.

Infectando los archivos

Lee 24 bytes del principio del archivo, y chequea que los dos primeros
bytes sean 'MZ' o 'ZM'. En esos casos supone que se trata de un archivo
.EXE. Si el archivo es .COM, o sea DI estaba en 0 de la rutina que
verificaba los anti virus, verifica la longitud del mismo. Si está entre
62088 y 1000 bytes, salva los tres primeros bytes del programa, agrega
en ese lugar un jump al final (donde irá el virus) y procede a
infectarlo. En el caso de que sea un .EXE, modifica el header de forma
en que el punto de entrada apunte al final (donde irá el virus). También
cambia la longitud del archivo en el header como para que cargue el
virus junto con el programa, y modifica los requerimientos de memoria
declarados por el programa para que el virus pueda funcionar. Si la
longitud del archivo es mayor a la declarada en el header, supone que
hay overlays adosados al programa o que hay algo agregado al mismo, y no
lo infecta. Luego de modificar los headers, infecta al archivo.

El encriptor

Antes de infectar el archivo, el virus tiene que generar una versión
encriptada de sí mismo y una rutina para desencriptarse al ejecutar el
programa. Cada vez que infecta el archivo elige al azar una rutina
diferente de encripción. Para esto va a utilizar una zona de trabajo,
donde primero va a copiar un desencriptador que tiene como modelo. Luego
lo va a modificar, poniendo una clave al azar. Elige de una tabla de
siete posibles una instrucción que va a ser la operación que se le
aplicará al código junto a la clave que ya eligió al azar, y luego elige
otra de la misma u otra tabla, 14 posibilidades distintas. Esas dos
instrucciones son copiadas al desencriptador, y las complementarias a la
rutina de encripción que luego generará el código del virus encriptado.
Una vez generado el desencriptador, copia a continuación todo el código
del virus encriptado. El desencriptador es variable, pero tiene una gran
parte que es constante en todas las infecciones. Por este pequeño
detalle el virus no puede considerarse polimórfico. Una vez generado
todo esto, copia el virus de la zona de trabajo al final del archivo.

Cuando infectó el archivo, lo cierra, vuelve a ponerle los atributos que
tenía previamente, recupera la interrupción 24h original, y sigue con la
interrupción 21h original, con un jump far. Pero como debe cambiar los 5
primeros bytes para que vuelvan a apuntar al virus, lo que hace es
volver a prender el trap flag, y utilizar una rutina instalada en la
interrupción 01 que cuenta 5 instrucciones y vuelve a modificar el
código de entrada a la interrupción 21h. Con esto se ejecuta la
interrupción 21h del DOS normalmente y luego el virus recupera el
control.

Cargando desde boot

Si se carga del boot sector, lo que hace es primero desencriptar el
resto del boot sector recién cargado, que como vimos antes estaba
encriptado. Luego disminuye la cantidad de memoria declarada por el BIOS
en 6k, y lee el virus a esa zona de memoria. En este punto usa una
estrategia que no es muy inteligente. Si en algún momento que está
leyendo un sector recibe un error, en vez de reintentar llama a la
interrupción 18h, que llamaría al Basic en una IBM PC, pero que causa un
reboot en la mayoría de los clones. Como muchas veces que se lee un
diskette hay que hacer un par de reintentos antes de lograr leer bien,
muchas veces falla la carga del virus desde diskette.

Después de cargar el virus en memoria, copia una rutina inmediatamente
antes de la posición donde se cargó el boot sector (0:7C00h), y salta a
ese punto. Esta rutina carga el boot sector original guardado por el
virus en el disco sobre el infectado, lo desencripta, y hace un call al
virus en memoria. El virus hace lo que ya vimos antes: toma la
interrupción 13h y trata de infectar el sector de arranque del disco
rígido. Cuando termina ejecuta el sector de booteo cargado previamente.

El detalle a tener en cuenta es que sólo tomó la interrupción 13h, y no
la 21h. Obviamente, en este punto el DOS no está cargado, así que no
tiene sentido tratar de tomar la interrupción 21h. Lo que hace es
activar una rutina dentro del handler de la interrupción 13h instalada
por el virus que espera que se instale el DOS para tomar la interrupción
21h. Para esto espera que el vector cambie a un offset superior a 0800h,
donde se cargará seguramente el DOS. Una vez que lo detecta, desactiva
esta rutina de la int 13h, hace apuntar el vector al virus, y sigue con
la interrupción 13h original. Notemos que en este caso no activa la
rutina que modifica la interrupción 21h, y que la toma como si fuera un
programa residente normal. Como en el punto donde tomó la interrupción
21h no hay cargado ningún residente, el virus no tiene que preocuparse
por hacer tunneling ni redireccionar la entrada de la interrupción.

Código muerto

Dentro del virus, luego de desensamblarlo completamente, notamos que hay
tres trozos nunca referenciados. Dos de ellos contienen mensajes
encriptados: 'Here comes the Predator!' y 'THE PREDATOR'. El tercero
todavía no sabemos que significa, aunque parece una rutina nunca usada:

MOV SP,09C9B
XCHG AX,DI
POPF
LAHF
MOV W[BP+DI+0E09C],DS
MOV W[BX+DI+0BFE0],SS
SCASB
MOV BP,0D2AA
RCL DL,CL
RETF

Conclusión

Este virus es, como diría Borges, 'más complicado que complejo'. Tiene
muchos mecanismos muy interesantes de ocultamiento, pero por momentos la
implementación es muy confusa y difícil de seguir. Esto explicaría por
qué los anti virus tuvieron tantos problemas en detectarlo
correctamente. De todas formas, usa algunos conceptos ya conocidos pero
en una forma muy creativa e inteligente, y funciona lo suficientemente
bien como para ser un problema. Si el polimorfismo estuviese mejor hecho
y tuviese un stealth más completo, sería casi un virus perfecto.

Fernando Bonsembiante es jefe de redacción de Virus Report y está
estudiando los virus informáticos dese hace varios años. Es consultor de
seguridad informática de varias empresas. Tambien es miembro de la
comisión directiva del Círculo Argentino de Ciencia Ficción, (CACyF) y
participa como columnista de varias revistas sobre informática. Puede
ser contactado por Fido en 4:901/303 o en Internet en ubik@ubik.to