Copy Link
Add to Bookmark
Report
Minotauro Magazine Issue 11 02A Como conviene infectar NE
MINOTAURO MAGAZINE #11
¨Como conviene infectar NE?
por Trurl
Esta peque¤a nota va como complemento de la nota de infeccion de NE.
Su objetivo es responder a la pregunta del titulo, es decir, que metodos de
infeccion, de los varios posibles, conviene poner en un virus de Windows si
queremos que este tenga posibilidades. En la nota de infeccion mencione
algunas veces datos tales como que la mayoria de los NE tiene espacio en
tal lugar, etc; estos datos los obtuve sencillamente analizando todos los
NEs de mi disco y de todos los discos a que tengo acceso (en total fueron
como 10, pero para los datos de la nota son 6, todos de 1G; no es suficien-
te como para decir que los datos son contundentes y definitivos pero si
para dar una idea bastante clara de como son las cosas). Esto obviamente no
lo hicimos a mano sino con un programa especial hecho ad-hoc, que les
entregamos en este numero por si ustedes quieren verificar nuestros dichos.
Las varias preguntas que me hice son:
1) Cuantos NE hay respecto al total de ejecutables (en ambientes tanto
de W31 como de W95)? (Para saber hasta que punto conviene seguir
infectando NEs).
2) Cuantos NE tienen espacio en la tabla de realocacion del MZ,
cuantos al final del stub MZ, y cuantos entre el final de la
ultima tabla y el primer segmento, y cuanto espacio tienen en
cada uno de estos lugares? (Para saber de cual de estos tres
lugares conviene sacar espacio para la segment table).
3) Cuantos NE tienen, en el segmento de codigo del entry point, al
menos una realocacion hacia algunas de las APIs InitTask, Create-
Window, RegisterWindow, InitApp, DispatchMessage, GetMessage,
PeekMessage?
4) Cuantos NE tienen FastLoad area?
5) Cuantos NE importan KERNEL, cuantos GDI, cuantos USER y cuantos
TOOLHELP? (Para saber hasta que punto tendria posibilidades un
virus que usara APIs de alguno de estos cuatro modulos; y saber
que porcentaje de NEs descartamos al no infectar NEs que no
importen KERNEL).
--- Estadisticas :
[ Datos tomados alrededor del 8 de enero en 6 maquinas ]
[ Se buscaron todos los archivos de extensiones EXE, DLL, y DRV. ]
Los resultados son:
De un total de 4741 ejecutables, 2336 eran NE (un 49.27%).
ESPACIO. De todos los NE:
- 1004 tenian espacio en la tabla de realocacion MZ (un 42.97%).
Promedio de espacio: 467.6 bytes.
- 2292 tenian espacio al final del stub (98.116%). Promedio de espa-
cio: 172.4 bytes.
- 2336 tenian espacio al final de la ultima tabla (100.00%). Promedio
de espacio: 663.2 bytes.
MODULOS IMPORTADOS. De todos los NE:
- 2218 importaban KERNEL (94.95%)
- 1825 importaban USER (78.12%)
- 1102 importaban GDI (47.17%)
- 107 importaban TOOLHELP (4.58%)
REALOCACIONES. De todos los NE, tenian relocacion a la API en el
primer segmento:
API nro de NE % de NE
InitTask 593 25.38%
InitApp 578 24.74%
RegisterClass 369 15.79%
CreateWindow 284 12.15%
DispatchMessage 402 17.21%
GetMessage 316 13.53%
PeekMessage 228 9.76%
OTROS. De todos los NE:
- 1989 tenian gangload area, tambien llamada fastload area (un 85.14%)
- 776 eran ejecutables con autoload (un 33.22%)
- 293 tenian segmentos cuyo offset era menor al offset del header NE
(12.54%)
- 2336 tenian a la nonresident names table como ultima tabla (100.00%)
- El promedio de bytes que habria que mover si se quisiera hacer
espacio para la segment table utilizando el espacio libre entre
la ultima tabla y el primer segmento (el 3er metodo) es de 1348.2
bytes.
En primer lugar tomar en cuenta que el porcentaje de NE es el promedio
de todas las maquinas. De las seis maquinas, tres tenian Windows 95; las
demas tenian Windows for Workgroups una, y Windows 3.1 las otras dos. Yo
pensaba que en un Windows 95 encontraria menos NE que en un Windows 16; sin
embargo fue al reves. En las maquinas con Windows 16 encontre que el
porcentaje de NE estaba alrededor de 45%; en maquinas con Windows 95, el
porcentaje de NE estaba bien por arriba del 50%. La primera observacion de
esto es que el DOS no esta muriendo; ya esta muerto. Increiblemente aun en
maquinas en las que el Windows no es usado mucho (por ejemplo una maquina
usada casi exclusivamente para juegos) el porcentaje de NE es de 45%; eso
quiere decir naturalmente que el porcentaje de EXEs de DOS esta alrededor
del 55%. Eso es increiblemente poco. Para ese 55% de EXEs de DOS, hay 5000
virus. Para el otro 50% de EXEs de Windows, hay 5 virus. Y ni hablar de
maquinas con Windows 95 en las que el porcentaje de NE no solo es mayor
sino que habria que tomar en cuenta todos los PE que debe haber; eso deja
practicamente nada para los EXEs de DOS.
Por otro lado lo mas interesante sin duda es lo de la nonresident-name
table. Como ya dije en la nota de infeccion, es increiblemente ventajoso
encontrarla siempre ultima, y la encontramos siempre ultima en un 100% de
los casos de los NEs de mis 6 discos.
En cuanto a los modulos importados, el panorama es alentador. Ese 94%
que importa KERNEL nos salva las cosas. Los demas porcentajes en realidad
son inutiles; una vez que tenemos el KERNEL importado, no es necesario nada
mas ya que podemos usar las APIs de KERNEL para "importar" otros modulos
nosotros desde el codigo. Osea que podemos usar APIs y olvidarnos de ese 6%
de NEs que no importan KERNEL con toda tranquilidad.
El tema de las realocaciones lo inclui en el analizador por lo dicho
sobre como diverger el control hacia el codigo del virus, lo de modificar
la tabla de realocacion del host, etc. En realidad no tiene ninguna
utilidad ahora y pueden ignorarlo.
Nos quedan solo tres cosas. La primera es lo de la gangload area, que
esta explicada brevemente en la nota de NE. Como vemos el porcentaje de NEs
que lo tienen es mas o menos alto, por lo cual es un tema que no se puede
ignorar.
Lo segundo es el autoload. Lo inclui en el analizador porque pense que
su infeccion seria imposible; ahora se que no lo es, asi que tambien pueden
ignorarlo.
Para finalizar, nos queda el asunto de los EXEs con "segmentos de
offset menor al offset del NE". Sucede lo siguiente; yo habia hecho mi
rutina para calcular el espacio entre la ultima tabla y el primer segmento
y me empezo a salir que muchos NE no tenian nada de espacio. Esto me
parecio muy extra¤o; individualice algunos NE que me estaba marcando como
sin espacio y los mire. Como yo pensaba, tenian espacio. Pero tambien
tenian un segmento con un offset de 0 (cero), osea que apuntaba al header
MZ; e incluian el NE y todas sus tablas. Esto es un truco muy interesante
porque lo que produce es que el sistema lee los headers del file y los pone
a nuestra disposicion. Podria llegar a ser util. Como sea, cambie mi codigo
para que descartara los segmentos que estuvieran antes del NE a la hora de
encontrar el primer segmento; pero ademas le puse que los fuera contando
para ver cuantos eran. El resultado esta a la vista; no tiene ningun
significado ya que esos files se pueden infectar tranquilamente. Solo
queria ver cuantos usaban ese truquito.
Respecto al uso del programa, solo pongan SEARCHNE C:\ *.EXE *.DLL
*.DRV, y les analizara todos los NEs de su disco. NO contiene un virus ni
codigo malicioso (para los desconfiados de siempre...)
Now you know...
Trurl tgc
