-[ 0x06 ]-------------------------------------------------------------------- -[ CURSO BASICO-PRACTICO DE CRACKEO DE VIRUS III ]--------------------------- -[ by +NetBul ]-------------------------------------------------------SET-14- Curso Basico-Practico de CRACKEO de VIRUS (III) --- Preguntas, respuestas y erratas. --- @98 by +NetBuL Pues eso, aqui estamos de nuevo. En esta entrega voy a intentar comentar unas ideas de un lector respecto al metodo descrito en el numero anterior de SET para aislar la cadena de busqueda de un virus en un archivo infectado, y tambien aclarar un peque€o despiste ... X-D. Bueno, al grano, despues de salir SET 13 nos llego este email de un lector: [- ---------------------->>>--------------------------------------------] Hellow FALKEN. Soy un asiduo lector de vuestro e-zine desde el primer numero y acaba de llegar a mis manos la ultima entrega el SET 13. Leyendo, leyendo he ido a parar a la seccion 0x06, "VIRUS II". Estoy viendo el algoritmo utilizado para descibrir que cadenas utilizan los ANTI-virus para detectar a los virus. Realmente es el tipico metodo de FUERZA-BRUTA, no?? Como pone en el documento si un fichero ocupa 300 bytes te crea 300 ficheros, OCUPANDO 90.000 bytes sino que GASTA 4.915.200 bytes si los clusters son de 16Kb (algo bastante considerable, deberiais haberlo comentado ya que hay mucho "iniciado" que no lo sabe, cada vez menos gracias a vosotros :-> ). El verdadero motivo del mail es deciros que hay otro metodo mas eficaz que realiza la misma operacion y menos tediosa. Ahi va. Se coge el fichero y se parte en dos partes iguales y se pasa el SCAN. Probablemente la cadena que busca el SCAN esta solo en un trozo, el otro se puede "tirar". El proceso se repite hasta que solo quede la dacena que busca. NOTA: Hay que tener cuidado, porqu ela cadena que busca puede estar justo en el punto donde se "corta" el fichero NOTA2: El antivirus puede tener varias cadenas de identificacion para un mismo virus. Llego a encontrar 4 cadenas para el virus NATAS. P.D.:El algoritmo no lo he descubierto o desarrollado yo, sino otra persona. Creo que lo lei en alguna PHRACK. :-[] Un Saludo y Hasta el Siguente SET Ministro [- ---------------------->>>--------------------------------------------] Ahora paso a comentarlo por partes ... [[[ ... habla el lector ... ]]] Hellow FALKEN. Soy un asiduo lector de vuestro e-zine desde el primer numero y acaba de llegar a mis manos la ultima entrega el SET 13. Leyendo, leyendo he ido a parar a la seccion 0x06, "VIRUS II". Estoy viendo el algoritmo utilizado para descibrir que cadenas utilizan los ANTI-virus para detectar a los virus. Realmente es el tipico metodo de FUERZA-BRUTA, no?? [[[ ....................... ]]] Bueno, si hubiese que ponerle un nombre creo que seria el adecuado, aunque como ya dije yo no lo he leido en ningun sitio. Esto no quiere decir que no pueda estar escrito en algun texto anterior al mio (cosa muy probable, yo no soy ningun lumbreras). :) [[[ ... habla el lector ... ]]] Como pone en el documento si un fichero ocupa 300 bytes te crea 300 ficheros, OCUPANDO 90.000 bytes sino que GASTA 4.915.200 bytes si los clusters son de 16Kb (algo bastante considerable, deberiais haberlo comentado ya que hay mucho "iniciado" que no lo sabe, cada vez menos gracias a vosotros :-> ). [[[ ....................... ]]] Para "iniciado" yo, que se me paso por alto. Lo siento pero me patinan las neuronas de vez en cuando. Tienes razon, la cosa quedaria asi: tama€o del archivo x tama€o del cluster (suponiendo que el archivo sea menor que el tama€o del cluster) Entonces, para un archivo infectado de 300 bytes y el tama€o de cluster de 16Kb, no es 300^2 (90.000) el total ocupado despues de lanzar el FREECAD, sino: 300 x 16 x 1024 = 4.915.200 bytes Ahora me enrollo un poco mas para los "iniciados" que tu comentas ... es un justo 'castigo' que me he ganado, no?. Por si alguien no lo sabe, un disco duro se divide en sectores de 512 bytes y estos a su vez se agrupan en clusters (el numero de sectores por cluster depende generalmente del tama€o del HD, mira aqui abajo). Tama€o de volumen hasta | 128MB | 256MB | 512MB | 1028MB | 2048MB | ---------------------------|-------|-------|-------|--------|--------| Tama€o de cluster | 2Kb | 4Kb | 8Kb | 16Kb | 32Kb | Sectores por cluster | 4 | 8 | 16 | 32 | 64 | P.ej, para un disco duro de 540 Mb, el tama€o del cluster sera de 16Kb (32 sectores x 512 bytes). Los archivos se guardan en el disco duro almacenandolos en clusters. Si el tama€o del archivo es mayor que el tama€o del cluster, se fragmentara y se guardara en tantos clusters como sea necesario. Es importante saber que los clusters que contienen a un archivo no tienen por que ser consecutivos dentro del disco duro, esto dependera de la disponibilidad de espacio, asi un archivo puede estar repartido en varios clusters a lo largo de todo el disco duro. Cuando un H.D. esta vacio si que se dispone de clusters consecutivos, pero en cuanto se empieza a almacenar y borrar informacion, las posibilidades de almacenar un archivo de tama€o medio en clusters consecutivos es muy baja. Mediante la fragmentacion de archivos se consigue aprovechar los huecos vacios que vamos dejando despues de borrar archivos. Pero el aprovechamiento del espacio no es total como ahora veremos. Por cierto, el hecho de que un archivo este fragmentado y repartido por todo el H.D. no supone ningun problema para el usuario. Al leer un archivo, el S.O. se encargara de buscar por el disco duro todos los clusters que contienen los fragmentos que forman el archivo. El meollo del asunto esta en que un cluster puede almacenar un archivo o parte de el, pero *nunca* puede almacenar dos o mas archivos. Por eso, si el tama€o de cluster es 16Kb y guardamos un archivo de 15Kb, estamos 'desperdiciando' 1Kb. Igual que si mide 31 Kb, estaremos ocupando 2 clusters, uno estara lleno y en otro 'desaprovechamos' 1Kb. La cosa se pone muy fea cuando queremos guardar en el disco 300 archivos de 300 bytes ... cada archivo ocupara un cluster o lo que es lo mismo, para guardar *cada* archivo de 300 bytes estamos desperdiciando los 16.084 bytes restantes del cluster, que es practicamente todo el cluster!. Si la 'chicha' son 300x300 = 90.000 bytes el espacio desaprovechado son 4.825.200 bytes :-o ----------------- 4.915.200 bytes totales Puesto en modo grafico, en vez de guardar un litro de agua en una botella estamos metiendo ese litro en 300 botellas, en cada botella una gota. Como irremediablemente gastaremos una botella por gota, alguien se preguntara, y si reducimos el tama€o de la botella para no desaprovechar tanto espacio ?. Pues bien, es cierto que la botella (los clusters) podrian hacerse mas peque€os, por ejemplo de 1Kb (2 sectores), entonces el maximo desperdiciado al almacenar archivos siempre seria menor que 1 Kb. Bueno, pues arreglao, dira alguien. Ahora veremos que no ... Si antes necesitabamos 2 clusters para almacenar un archivo de 20.5 Kb (y desperdiciabamos 11.5Kb), ahora necesitaremos 21 clusters para este mismo archivo (y solo desperdiciaremos 0.5 Kb). El *pero* es que como cada cluster puede estar en cualquier lugar del disco duro, el cabezal de lectura/escritura no se desplazara un maximo de 2 veces al leer este archivo, sino un maximo de 21, con la consiguiente perdida de tiempo. (Ahora ya os imaginais para que sirve el defrag, no?) [ NOTA DEL EDITOR: A la hora de seleccionar el tama€o del cluster ] [ hay que tener tambien presente que la FAT no es mas que una forma ] [ de indexar los ficheros, indicando los cluster que ocupan. Si el ] [ tama€o del cluster es peque€o, entonces se requerira mayor numero ] [ de indices en la FAT, por tanto, el tama€o de la FAT aumenta. ] Por eso al decidir un tama€o de cluster se intenta, entre otras cosas, hacer una media de compromiso entre el tiempo perdido / espacio ganado (o tiempo ganado / espacio perdido) :-) Bueno, creo que ya no se me olvidara nunca mas ... X-D Cambiamos de tercio .... [[[ ... habla el lector ... ]]] El verdadero motivo del mail es deciros que hay otro metodo mas eficaz que realiza la misma operacion y menos tediosa. Ahi va. Se coge el fichero y se parte en dos partes iguales y se pasa el SCAN. Probablemente la cadena que busca el SCAN esta solo en un trozo, el otro se puede "tirar". El proceso se repite hasta que solo quede la dacena que busca. NOTA: Hay que tener cuidado, porqu ela cadena que busca puede estar justo en el punto donde se "corta" el fichero [[[ ....................... ]]] Otra vez tienes razon, pero a mi modo de ver, no toda la razon :-). Es cierto que hay otros metodos (lo dije no? :-?), pero creo que lo de mas eficaz y menos tedioso es relativo. Lo que no puedo negar es que es un metodo mas "limpio", pero no mas eficaz. Vamos a repasar lo que dices y de paso veremos que esto tiene algunos puntos 'oscuros': 1- El metodo esta bien, pero (primer pero) no permite hacerlo de un tiron, es decir, el proceso sera cortar y pasar el antivirus, cortar y pasar el antivirus, etc.. no se puede automatizar el proceso. O quizas si, si el antivirus devuelve un valor determinado cuando detecta un virus podria hacerse un programa que a modo de archivo por lotes partiese un archivo en dos, llamase al antivirus y luego repitiera el proceso con la parte que contiene la cadena. Pero cada antivirus es diferente y el programa solo valdria para ese antivirus. Tambien podria combinarse un programa con un archivo por lotes, pero sigue siendo un proceso semi-automatizado ya que habria que adaptar el .bat para cada antivirus, no? 2- Como dices la cadena puede estar justo donde cortamos, con lo que habremos perdido un paso. Al partir el archivo en 2 y no detectarse el virus en ninguna de estas dos partes, sabremos que la cadena esta justo en medio, pero no sabemos cuantos bytes de la cadena estan en el primer trozo y cuantos en el segundo. Ahora lo mas logico seria descartar el primer cuarto y el ultimo cuarto y coger los dos cuartos centrales ... [----------------****----------------] el archivo infectado ^^^^ la cadena de busqueda [----------------**] [**----------------] el archivo en 2 partes Como no se detecta el virus en ninguna de las 2 partes ... [----------------****----------------] el archivo infectado [---------] [-------****-------] [---------] ^^ ^^ desechamos desechamos Pero ahora estamos de nuevo en la misma situacion, no?. Asi que tendremos que coger de nuevo los 2 cuartos centrales del trozo que nos quedaba, es decir, que tendremos una cuarta parte del archivo inicial. Y asi hasta que en uno de estos trozos centrales no se detecte el virus y nos indicara que ya no podemos cortar mas (porque quedaran bytes de la cadena en uno de los trozos laterales desechados). 3- En cualquier caso, al usar el metodo que describes, simpre nos encontraremos, tarde o temprano, en la situacion descrita en el punto anterior, osea que al partir un trozo en dos mitades la cadena quede partida: [------****--------------------------] el archivo infectado [------****--------] [------------------] lo partimos por la mitad [------****--------] y nos quedamos con la parte 'buena' ... [------***] [*--------] ... y tarde o temprano llegaremos aqui ... Cuando llegamos a esta situacion tenemos que retroceder y quedarnos con el ultimo trozo en el que se detectaba la cadena, y escoger entre usar el metodo del punto 2 para seguir 'estrechando el cerco' o quedarnos con todo el trozo y 'suponer' que es la cadena completa: 1.- [------****--------] cogemos el ultimo trozo 'bueno' ... y aplicamos el metodo del punto 2 ... Como vemos, en este caso, la particion no es entera, 18 bytes /4 = 4.5, luego podemos dejarlo en [(4) (9) (5)], [(5) (9) (4)] , [5] [8] [5] , o [(4) (10) (4)] ... Esta ultima particion es con la que nos quedaremos si aplicamos la formula que hay mas adelante. [----][--****----][----] (4) (10) (4) Segun el tama€o del trozo a partir, las divisiones del total de bytes /2 y /4 podran ser enteras o no enteras, luego tenemos que buscar una formula que nos permita dividir el trozo sin problemas. En un principio podremos encontrarnos 3 casos diferentes, aunque finalmente los resumiremos en una unica formula: /-----------------------------------------------------\ | total/2 | total/4 | formula tama€o lados|centro | |-----------------------------------------------------| | entero | entero | lado = total /4 | | | | centro = total /2 | |-----------------------------------------------------| | entero | no entero | lado = [(total /2) -1] /2 | | | | centro = (total /2) +1 | |-----------------------------------------------------| | no entero | no entero | lado = floor(total/4) | | | | centro = total - (lado x 2) | \-----------------------------------------------------/ La formula con la que nos quedamos y que servira para todos los casos es la ultima. La funcion 'floor(double)' es una funcion de 'C' que devuelve un valor redondeado por defecto al entero menor mas cercano. (Creo que SMVLB) X-DD 2.- La segunda opcion seria quedarnos con: [------****--------] ... el ultimo trozo 'bueno' ... y aceptarlo como la cadena de busqueda del antivirus para ese virus. Como vemos en este ejemplo no tiene por que ser la cadena *exacta*, aqui sobrarian unos 'pocos' bytes ;-) Ahora vemos que el metodo es una combinacion de dos metodos, generalmente se usara el primero hasta que haya que usar el segundo, en otros casos solo se usara el segundo: -> metodo 1: partir por la mitad y escoger uno, asi hasta que no nos sirva ningun trozo ... y nos quedaremos con el ultimo antes de cortar. -> metodo 2: partir por el primer y ultimo cuarto y quedarnos con el centro, asi hasta que no nos sirva el trozo ... 4- Ahora viene otro pero. Como ya he dicho, cuando no podemos partir mas por ningun metodo, no tenemos asegurado que ese trozo sea la cadena de busqueda, puede haber varios bytes que no pertenezcan a la cadena y que esten en el trozo, no? Es decir, que de mas eficaz creo que nada. Ej: [--*********---] Supongamos que esto es un trozo con la cadena despues de descartar el resto del archivo por los otros metodos. A este trozo no podemos aplicarle ningun metodo de los anteriores, solo podriamos aplicarle el metodo que llamas de Fuerza Bruta (FREECAD) para descartar los bytes que nos sobran (2 al principio y 3 al final). Solo en algunos casos (poquisimos) coincidiria el trozo que nos queda con la cadena exacta. Evidentemente podemos quedarnos con este trozo y no descartar los bytes que nos sobran, la verdad es que practicamente todo lo que nos queda forma parte de la cadena, pero segun que casos (o usos) necesitaremos la cadena exacta ya que despues nos puede ahorrar un tiempo y trabajo inutiles. 5- Conclusion. El mejor metodo seria una mezcla de los tres. Lo que queda claro es que usando unicamente el FREECAD puedes encontrar la cadena completa (y exacta). Con el metodo que dices casi con toda probabilidad tendrias que complementarlo con el FREECAD (joer, cuanta publicidad). ;-> Repasando lo que decias, un metodo menos tedioso seria partir el archivo, usando ese metodo, 1, 2 o 3 veces segun el gusto y las ganas del consumidor para conseguir un trozo infectado mas peque€o que el original y despues usar el Freecad para obtener la cadena de busqueda exacta. Asi conseguiremos ahorrarnos bastante trabajo al analizar los logs con los archivos infectados y ocupar menos espacio de HD, aunque con los peazo discos duros de hoy en dia ... [[[ ... habla el lector ... ]]] NOTA2: El antivirus puede tener varias cadenas de identificacion para un mismo virus. Llego a encontrar 4 cadenas para el virus NATAS. [[[ ....................... ]]] Creo que te refieres al hecho de que la cadena puede estar partida en varios trozos +o- cercanos, que no tiene por que ser un grupo de bytes consecutivos. Suponiendo que fuera lo que dices, que un antivirus busca 4 cadenas de identificacion *distintas* para el NATAS (natas de satan lo llaman por ahi), imagina que pasaria si partieses el archivo en dos como dices y el virus se detectase en los dos archivos .... X-DD Creo que no quedaria mas remedio que usar la "fuerza bruta" ... ;) [[[ ... habla el lector ... ]]] P.D.:El algoritmo no lo he descubierto o desarrollado yo, sino otra persona. Creo que lo lei en alguna PHRACK. :-[] Un Saludo y Hasta el Siguente SET Ministro [[[ ....................... ]]] Pues nada Ministro, gracias por tus criticas. Esta bien eso de dar los creditos ... :-) ///// (Noticias de ultima hora) ///// Por fin he encontrado el articulo que dices y no aparecio en la 'phrack', sino en el numero 1 de la '40HEX'. Ya me empezaba a picar la curiosidad. ;-> Es un poco viejo pero la idea es basicamente la misma, aunque son apenas 5K de texto frente a los mas de 60K de puro rollo que suman estos 3 articulos que ya llevamos :-) Si os interesa podeis encontrarlo en: ftp://ftp.fc.net/pub/phrack/underground/40hex/40hex_1.zip En esa direccion podreis encontrar todos los numeros de la '40HEX', asi como otros ezines (Phrack,Minotauro,etc). Otras direcciones ftp: ftp://ftp.warwick.ac.uk/pub/cud/ ftp://ftp.eff.org/pub/Publications/CuD/ Y hablando de ezines, el mismo dia que salia el numero anterior de SET (13) (13 de febrero ?), tambien lo hacia el segundo numero del ezine que publica la gente del 29A. Como sabeis es un reconocido grupo espa€ol (o al menos el 50% de sus componentes son espa€oles) de programacion de virus y sus ezines son imprescindibles, calidad SUPERIOR. Ahora mismo son lideres indiscutibles a nivel mundial en el tema virii. Podeis encontrar mas informacion y los e-zines en su web, y tambien podeis leer algo sobre ellos en la revista PC Actual de Feb/98, pag 122, asi como en los PC Mania n§ 57, 58 y 61. http://29A.islatortuga.es http://www.29A.org (proximamente) ///// (Fin Noticias de ultima hora) ///// Bueno, peazo rollo soporifero |-O. Esta bien que hagais comentarios asi para que podamos corregir los fallos y comentar vuestras ideas. Si alguien tiene algo que decir, comentar, desmentir, corregir, criticar etc ... no te cortes y escribenos un mail. Siempre es posible que un articulo contenga fallos, bien por peque€os (y a veces no tan peque€os) deslices, bien por desinformacion del autor, bien por patinazos neuronales, etc. Osea, que si veis algo raro, anormal, curioso o erroneo, pues email al canto, ok? Si ademas crees que puedes mejorar lo presente, no te cortes y envianos un articulo, y si tienes suerte el editor-profesor Falken te lo publica en SET y asi curramos todos un poco ... :-> En cuanto al tema este, creo que lo doy por finalizado. Me parece que ha quedado todo bastante claro y bien explicado, en ocasiones demasiado, no? ;-> Nos vemos en el siguiente ... Un Saludo netbul@altern.org @1998 by +NetBuL ++++++++++++++++ 477274736A743A20 437261636B2C20 506F6C202620 4B69662E ++++++++++++++++