Minotauro nº11:(TEXT_002.11A):19/04/1997 << Back To Minotauro nº 11
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