Curso basico practico de crackeo de virus

      4488

Autor: +NetBul

-[ 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
                                                ++++++++++++++++