Introducción a los 'crypters'

Año 2013

En la pasada edición de la NcN tuve la oportunidad de poder exponer sobre 'crypters', tema sobre el
que no es sencillo, en mi opinión, encontrar información de cierta calidad. Este artículo es el primero
de una serie en la que pretendo explicar, con cierto nivel de detalle, el funcionamiento y uso de los
'crypters', así como las técnicas que se utilizan para lograr dejar indetectable un ' crypter' ya
'quemado'.

Para evadir la detección de malware por parte de los programas Antivirus, en adelante AVs, se
utilizan diferentes técnicas, una de ellas es el uso de 'crypters'. Éstos permiten cifrar cualquier
archivo binario para hacerlo 'invisible' a los AVs.

Es cierto, que los 'crypters' tienen mala fama, pero también la tenían los exploits hace unos años y
hoy en día están integrados en todo tipo de aplicativos de seguridad, como Metasploit por ejemplo.
Obviamente los 'crypters' son usados por los delincuentes para evitar la detección de los AVs e
infectar los ordenadores, llevando a cabo todo tipo de tropelías, pero también pueden ser utilizados,
entre otros casos, en el contexto de una auditoría de seguridad.

¿Quién no se ha encontrado con detecciones de AVs en el transcurso de una auditoría usando

Metasploit u otras herramientas? Especialmente en aquellos casos en los que se 'dropean' (vuelcan)
binarios al disco. De hecho, metasploit cuenta con una gran variedad de técnicas de ofuscación cuyo
objetivo es hacer indetectable el binario a los programas AV. Las técnicas o herramientas que
ofrece Metasploit  Community para llevar a cabo las tareas de indectección son básicamente:
  Utilizar plantillas de programas ejecutables conocidos (Calculadora de Windows, Notepad,
etc.)
 Codificar mediante múltiples 'pasadas' del algoritmo que más nos guste el código del archivo
ejecutable, todo ello a través de la herramienta msfencode. 

Estas técnicas son muy efectivas con algunos AVs pero sobre otros no tienen ningún efecto. Por lo
tanto, pueden servir en ciertos escenarios pero desde luego no sirven para evitar la detección de
todos, o la mayor parte de los AVs. En la versión Metasploit Pro se proporcionan además binarios
firmados que aumentan el nivel de 'indetección'.

En la imagen puede verse un  ejemplo de uso de msfencode combinado con msfpayload para tratar
de evadir la detección por parte de los AVs del payload shell_reverse_tcp, en el que se utilizan 10
pases de la codificación shikata_ga_nai, la plantilla del ejecutable calc.exe y como resultado se
genera el archivo outputfile.exe.

En definitiva, si queremos asegurarnos de volver 'indetectable' un

determinado binario que es detectado por múltiples AVs,
necesitamos un 'crypter' indetectado o FUD (Full UnDetectable).

Cryters vs. Packers

Hay que puntualizar que en algunos entornos se habla indistintamente de ' crypters' y 'packers', pero
en realidad son cosas distintas. El objetivo de un packer es 'empaquetar' o 'comprimir' el archivo
ejecutable. Sería como usar un ZIP pero sin perder la estructura de un archivo ejecutable PE (Portable
Executable). El objetivo del 'crypter' es 'cifrar' el ejecutable. Sería como usar PGP o TrueCrypt, pero
sin perder la estructura PE.

Programas AntiVirus

En lo que sigue vamos a centrarnos en explicar qué son y cómo funcionan los 'crypters', pero antes
debemos entender de forma básica cómo funcionan los AVs. Éstos, son cada vez más sofisticados y
utilizan todo tipo de técnicas para identificar el malware, entre estas técnicas destacan dos: las
firmas binarias y las firmas heurísticas.
Las primeras buscan secuencias de bits características del malware previamente identificado. Es
decir, buscan secuencias de bits, a modo de patrón, de aquel malware que haya pasado por el
laboratorio de la empresa de AVs. Es decir, que en algún momento del tiempo, en la empresa de AV
han recibido una muestra del malware para analizarlo y una vez identificado como malicioso han
fijado o definido un patrón característico que constituye la firma binaria del mismo. En definitiva, un
malware totalmente nuevo, recién 'codeado', difícilmente será detectado por este tipo de firmas.
Para poder anticiparse y detectar malware que no haya sido analizado previamente, existen las
denominadas firmas heurísticas. Básicamente lo que hacen es detectar elementos que típicamente
forman parte de los programas maliciosos, como el uso de determinadas funciones, algoritmos de
cifrado, etc. Mediante estás técnicas, es posible detectar de forma anticipada malware 'nuevo', pero,
además de ser más compleja su implementación y consumir más recursos del sistema que las firmas
convencionales, también implican un mayor nivel de riesgo debido a la detección de falsos positivos.

Análisis o escaneo en disco

Las tareas de análisis o escaneo de los archivos binarios son realizadas por los AVs a nivel de disco, no
en la memoria RAM. Cuando un AV nos indica que está escaneando la memoria, lo que está haciendo
realmente es buscar el binario en disco que arrancó un determinado proceso que en ese momento
está ejecutándose en la memoria RAM y una vez ha localizado el mismo, escanea dicho binario (en el
disco) en busca de firmas de malware. Así es como funcionan los AVs, escanean los archivos en el
disco y los 'crypters' basan su existencia en este principio básico.
 Funcionamiento de los 'crypters'

Tal y como avanzamos en el anterior capitulo, los Antivirus, en adelante AVs, escanean los archivos
en el disco del ordenador y no en la memoria RAM y este comportamiento es el que aprovechan los
'crypters' para evadir la detección de los AVs. Veamos como lo hacen.

Cifrado
Los 'crypters' utilizan técnicas de 'cifrado' para ocultar los
archivos maliciosos. Repasemos rápidamente en qué consiste un cifrado. Un cifrado es
un procedimiento que utiliza un algoritmo y una clave para transformar un mensaje legible en otro
indescifrable.

Veámoslo con un ejemplo: vamos a 'cifrar' el mensaje "HOLA" con el algoritmo de cifrado ROT
(también conocido como cifrado César) y la clave de cifrado será "1". Este algoritmo lo que hace es,
para cada carácter del alfabeto, avanza tantas posiciones como el valor de la clave de cifrado
establecida, en este caso "1". Así pues, tras aplicar el algoritmo, la letra "A" se transforma en la "B",
la "B" en la "C" y así sucesivamente. Por tanto el mensaje "HOLA" se transforma en "IPMB". De este
modo hemos ocultado nuestro mensaje y para que alguien pueda descifrarlo, necesitará conocer
tanto el algoritmo empleado (ROT) como la clave de cifrado (1). Obviamente este es un algoritmo
muy sencillo y una clave igualmente sencilla, lo cual permitiría llevar a cabo ataques con el propósito
de deducir el algoritmo y la clave, sin embargo, existen infinidad de algoritmos de cifrado
enormemente complejos que pueden utilizarse y son utilizados para cifrar 'malware'.

Cifrando malware
La idea básica que subyace en el concepto de 'crypter' es la siguiente: si se cifra un archivo malicioso,
éste será transformado en un archivo 'ininteligible' para el AV y por tanto no será detectado. Lo cual
es cierto, pero claro, existe un pequeño problema, y es que el archivo malicioso cifrado no funciona,
no puede ejecutarse, así que es necesario encontrar una solución, una técnica que se encargue de
descifrar y ejecutar el archivo malicioso. Esta pieza de software se denomina 'stub'.

'Crypter' y 'stub'
Por regla general un 'crypter' consiste en dos elementos: el 'crypter' y el 'stub'.
Esta última es la pieza más importante del conjunto.

El 'crypter' consiste generalmente en un programa que permite buscar y seleccionar en el sistema de

archivos del ordenador el ejecutable a cifrar (generalmente un archivo malicioso, pero es posible
cifrar cualquier archivo que se desee). Algunos, permiten adicionalmente introducir la contraseña de
cifrado de forma manual o generarla aleatoriamente. Y en ocasiones, algunos permiten activar
ciertas medidas anti-forenses, pero esto es otra historia que trataremos más adelante.

Una vez seleccionado el archivo a cifrar y pulsado el botón de 'cifrar' (Build en el ejemplo de la
imagen) nos generará un 'nuevo ejecutable', el cual en realidad consiste en una composición del
'stub' y un 'payload', que no es más que el malware cifrado.

Crypter (malware) = Stub + [malware cifrado]

Como puede observarse, 'crypter' y 'stub' están relacionados, ya que el 'crypter' se encarga de
ejecutar el algoritmo de 'cifrado' y el 'stub' se encarga de ejecutar el algoritmo de 'descifrado'. Para
que el 'stub' pueda descifrar el malware necesita conocer la clave utilizada en el proceso de cifrado.
En algunos casos, el programador del 'crypter' no da opción al usuario a elegir una clave, sino que la
ha definido de antemano en su código, y en otras sí permite elegirla o generarla aleatoriamente, en
cualquier caso, al generar el 'nuevo ejecutable' el 'crypter' ha de almacenar la clave en el algún lugar
para que el 'stub' pueda encontrarla y descifrar el malware.

Si se observa en detalle este 'nuevo ejecutable', lo que vemos es una configuración bastante
habitual, en la que tras el archivo ejecutable que constituye el 'stub', se añaden unos separadores
que delimitan el lugar en el que se encuentra almacenada la clave y a continuación se añade el
malware cifrado. Obviamente cada programador puede organizar esta distribución como más le
guste y en ocasiones, en lugar de añadir directamente el malware cifrado tras el stub, lo introducen
en un recurso del ejecutable  PE.

Cuando este 'nuevo ejecutable', valga la redundancia, es ejecutado, el 'stub' se

encarga de copiar a la 'memoria RAM' el malware cifrado, descifrarlo allí
mismo, y a continuación ejecutar dicho 'malware' ya descifrado. Trataremos
este punto en detalle en el siguiente artículo de la serie.
 El 'Stub': la pieza clave del 'crypter'

Hasta ahora hemos visto que un 'crypter' es un conjunto compuesto por un elemento habitualmente
denominado también 'crypter', pero como ya se ha puntualizado en los comentarios de posts
anteriores sería más correcto designar como 'builder' y otro elemento conocido como 'stub'. El
'builder' es una parte del código relativamente sencilla, pues se encarga de conformar un ejecutable
compuesto por el 'stub' y el 'malware cifrado'. El 'stub' es algo más complejo, pues se encarga de
descifrar el 'malware cifrado' y, sin tocar el disco, arrancar el 'malware descifrado' directamente en
memoria.

¿Cómo consigue el 'stub' arrancar el 'malware cifrado' directamente en memoria sin que este
toque el disco?. Para ello, el 'stub' utiliza una técnica o procedimiento llamada 'Dynamic
Forking' o 'RunPE'. Está técnica es muy antigua, pero sigue siendo totalmente válida y
funcional al día de hoy.

Uno de los objetivos que me marqué al comenzar a escribir los artículos de esta serie sobre 'crypters'
era que fuesen sencillos de entender por todos los lectores y no solo por aquellos que tienen
conocimientos avanzados de malware y reversing. Por ello, voy a explicar los aspectos más
importantes de la técnica 'Dynamic Forking' o 'RunPE' de forma sencilla, sin abusar de tecnicismos. Si
alguno quiere profundizar en ella solo tiene googlear un poco y encontrará múltiples descripciones
técnicas de la misma. En la imagen que he preparado con los pasos del proceso puede verse un
mayor nivel de detalle.

Dynamic Forking o RunPE

Una vez el 'stub' se ha ejecutado, lo primero que suele hacer es localizar dentro del binario el
'malware cifrado', a continuación localiza la clave de 'cifrado/descifrado' e inicia el proceso de
descifrado del 'malware' en memoria. Acto seguido, el stub arranca un segundo proceso, de sí mismo
o de un ejecutable cualquiera del sistema, es indiferente. Pero lo hace invocándolo con una
propiedad denominada CREATE_SUSPENDED. Con ello lo que se consigue es cargar en memoria
dicho ejecutable y los datos  de contexto necesarios para su ejecución, pero no llega a arrancarlo,
está 'suspendido'. A continuación, a partir de la dirección de memoria donde se encuentra la
cabecera y secciones del proceso suspendido, sobrescribe éstas con las del ejecutable malicioso ya
descifrado que tiene en memoria. A partir de ahí, obtiene los datos de contexto del archivo
suspendido y los sustituye por los datos del nuevo ejecutable, el malware. Estos datos son
básicamente la dirección base y el punto de entrada del nuevo ejecutable (EP: Entry Point). Por
último, relanza el proceso suspendido, consiguiendo que se ejecute el archivo malicioso en lugar del
ejecutable suspendido invocado inicialmente. Así de simple y así de elegante.

Detección del 'stub'

Hay que entender que aunque el 'builder' sea detectado por un Antivirus, en adelante AV, esto no
supone problema alguno, dado que el 'builder' funciona como una herramienta para componer el
'nuevo ejecutable malicioso', pero no forma parte del mismo. Al 'stub' le toca la parte más difícil,
dado que él sí viaja (junto al malware cifrado) por el mundo y debe parecer un 'buen chico' para no
ser detectado por los AVs.

Como se ha visto, un 'stub' debe realizar unas cuantas acciones concretas para conseguir descifrar y
ejecutar el 'malware' en memoria. Está claro que los AVs conocen perfectamente dichas acciones y
las funciones y APIs involucradas. Por tanto, no es sencillo para un 'stub' pasar inadvertido.

Recordemos que hay un tipo de firmas denominadas 'estáticas', 'genéricas' o 'binarias', que
simplemente son cadenas de bytes del código que el AV ha marcado como maliciosas, siendo algunas
de ellas instrucciones de código y otras simples cadenas de texto. Las firmas heurísticas son un poco
más complejas, ya que se basan en detectar en el código, entre otras cosas, el uso de los
'procedimientos', 'funciones' y 'API's características de los 'stubs'.

Las firmas de AVs llevan muchos años perfeccionando sus técnicas de detección y por tanto conocen
infinidad de variantes y métodos que han utilizado los desarrolladores para lograr que los 'stubs'
consigan llevar a cabo su misión: descifrar y ejecutar el malware en memoria. Es por tanto
complicado evadir la detección de los AVs, especialmente de las firmas heurísticas. Pero no es
imposible.

Objetivo : Stub FUD (Full Undetectable)

Imaginemos un programador ante lo que podría ser su primer 'stub'. Tiene claro lo que debe hacer,
así que se pone a codear la primera versión de la forma más simple, directa y sencilla que se le
ocurre. Ya lo tiene, su 'stub' funciona y hace exactamente lo que debe hacer un stub, descifrar el
malware y arrancarlo en memoria. La pregunta es, ¿será detectado este 'stub' pos los AVs? Pues sí,
en principio lo será. Básicamente porque aunque no haya reutilizado ni una sola línea de código de
'stubs' anteriores, estará utilizando las mismas funciones, strings y API's que otros programadores ya
han utilizado miles de veces con anterioridad, así que muchos AVs, no todos, seguro que han
reconocido en dicho código intenciones poco loables.

Nuestro programador puede empezar a tocar el código 'reescribiendo' rutinas de la forma más
rocambolesca posible, pero le va a costar sangre, sudor y lágrimas evadir a todos los AVs que le han
pillado. Al menos, haciéndolo desde el código.

Para empezar, nuestro programador ha cometido un error de principiante. Se ha concentrado en

programar y reprogramar su código y no se ha molestado en 'ocultar' su binario a las firmas de AVs.
En su afán por verlo 'indetectado' lo ha enviado a 'Virustotal' u otras páginas similares que lo han
escaneado con múltiples AVs. Al haber sido detectado por varios AVs y ser un 'stub' nuevo, no visto
con anterioridad, como indicará su HASH único, las firmas de AVs dispondrán de la muestra para
estudiarlo a fondo, así que en poco tiempo, lo que eran unas cuantas detecciones se convertirán en
muchas más.

Entonces, ¿cómo es posible conseguir un 'stub' indetectable? Generalmente al proceso de 'retoque'

de un 'stub' para volverlo 'indetectable' se le conoce con el nombre de 'modding', y el éste tiene
dos modalidades, el 'modding' desde 'código fuente' (o 'source') o desde el 'binario'. En general, lo
más óptimo es combinar ambas, ya que hay firmas sencillas de sacar desde el código fuente, pero
para sacar las más complejas, generalmente, hay que recurrir a retocar el 'binario'. Además, el
'modding' se aplica muchas veces para sanear un 'stub' detectado, pero no se cuenta con el código
fuente del mismo, y es por esta razón por la que se utiliza muy habitualmente y de forma exclusiva
el 'modding' desde binario.

Por tanto, a modo de recapitulación, el objetivo de todo 'modder' es dejar el 'stub limpio',

'indetectado', es decir 'FUD' y para ello, ha de 'retocarlo', a través de un proceso conocido como
'modding' que se sirve de múltiples técnicas para conseguir, por una parte, localizar la firma del AV,
es decir, descubrir dónde, en qué bytes, el AV ha 'marcado' el ejecutable, y por otra parte, ser capaz
de alterar esa secuencia de bytes de manera que el AV ya no detecte más el 'stub' y éste continúe
siendo funcional.
 Modding 'Crypters': el arte de la evasión
En el primer post de esta serie vimos en qué consisten los 'crypters'. En el segundo post 
profundizamos en su funcionamiento y en el tercer post analizamos un elemento esencial, el
'stub'. En este cuarto post vamos a comenzar a estudiar las técnicas empleadas en la
localización de firmas y evasión de Antivirus, en adelante AVs.

Luis se levantó y se sentó frente a su computadora. Se puso los auriculares, y arrancó su

playlist favorita de 'reggaeton'. Chequeó su consola de 'Cybergate', un RAT (Remote
Administration Tool) o 'troyano' muy popular, y comprobó el log. La cosa había ido bien, 7
nuevas víctimas, sonrió. Ni siquiera sabía cuántas víctimas tenía ya, calculaba que unas 150
aproximadamente. La última campaña de pesca, como él llamaba a sus operaciones de
obtención de víctimas, había sido un éxito. Había 'bindeado' (unido, juntado) el server de su
troyano con un instalador de Office 2010, pero en el nombre puso 'Office-2012-all-languages-
INSTALLER.exe'. También lo 'bindeó' con un video del último éxito de Shakira y un video
porno. Creó unos archivos torrent y los subió a 'The Pirate Bay', después se pasó por youtube,
buscó algunos vídeos recientes sobre la instalación de Office y Shakira y posteó algunos
comentarios en los que incluyó los enlaces a sus ejecutables. Un par de días después ya tenía
casi sus 150 víctimas.

Luis no era un chico muy popular en las escuela, más bien lo consideraban un bicho raro y
obviamente las chicas no le hacían mucho caso, la mayoría de ellas solo tenían ojos para Juan,
un cachitas que apuntaba a estrella de fútbol. Le constaba que a él le gustaba María y que ella
le correspondía, poniéndole ojitos y contorneándose cuando pasaba por delante suyo. Pero por
lo que se comentaba en la escuela, no habían ido más allá. 
Luis buscó entre sus víctimas y localizó la computadora que andaba buscando, busco la
opción de 'Remote Tools' y pulsó 'Webcam Capture', al cabo de unos segundos, la imagen
apareció y allí estaba ella, María, sobre su cama escuchando música.  Apuesto a que escucha
'Juanes', pensó. Conectó el audio remoto y efectivamente, comenzó a escuchar a 'Juanes',
sonrió. Ese 'cachitas' de Juan va detrás de ella todo el día, pensó, pero aquí el único que ha
visto a María como a él le gustaría he sido yo, y sonrió de nuevo. A continuación, buscó en su
escritorio la carpeta con los archivos utilizados en su última campaña de pesca. Localizó el
server y lo subió a su web de 'scanner on-line' favorita. Al cabo de unos instantes, apareció el
resultado. Maldición, espetó. El informe indicaba que su server era detectado por cinco AVs. 

La cosa se ponía 'chunga', se le había quemado más rápido de lo previsto y eso que no se lo
había pasado a nadie ni lo había publicado en los foros, lo había usado de forma privada. Es lo
malo de las campañas de pesca de 'arrastre', pensó, se consiguen muchas víctimas pero
siempre hay algún capullo que sospecha y envía alguna muestra a alguna empresa de AVs o a
Virustotal y a partir de ahí, empiezan las detecciones.

- Necesito una solución urgentemente o perderé un buen montón de víctimas, comentó.

Chequeó el Messenger y vio que 'DiabloNet' estaba on-line.

- Estassss??, escribió
- ke pasa brother!
- necesito ayuda urgente
- ke necesitas?
- me detectaron el crypter, barias detecciones, me dejas uno FUD?
- hermano siempre igual, pero luego me los quemas
- te prometo que solo lo usaré para reemplazar mis servers, no para enviarlo de pesca
- OK, pero me debes uno y rapidito que últimamente te estas columpiando
- vale colega lo prometo, me pongo ahora mismo con ello

'DiabloNet' le envió el enlace a un crypter FUD por email, lo descargó, lo descomprimió con
la contraseña que siempre utilizaban y FUDeo su server de 'Cybergate' con el nuevo 'crypter'.
Verificó que estaba indetectado y rápidamente se puso a reemplazar el server de sus víctimas
online para no perderlas. Cuando terminó, busco la carpeta 'Modding' en su escritorio y
empezó a trabajar en el crypter que le había prometido a 'DiabloNet'

Preparando el Modding
Para 'modear' un 'stub' determinado lo que se suele hacer en primer lugar es aplicar el
'crypter' a un ejecutable ligero para poder comprobar de forma rápida si éste funciona a
medida que se van alterando los offsets. Puede hacerse con el 'notepad' o la 'calculadora de
Windows', pero es más práctico utilizar unos ejecutables especiales denominados 'anotadores
de offsets' o 'bolita' (ya que muchos de estos anotadores tienen forma circular). Estos
archivos simplemente muestran o anotan en un archivo de texto el nombre del propio
ejecutable. Esto resulta muy útil en el proceso que a continuación se explicará, dado que
permite localizar, entre muchas variantes, cuál es el ejecutable funcional.

Antes comenzar el proceso de 'modding', es necesario escanear el ejecutable cifrado o el 'stub'

mediante un scanner on-line para saber cuantas detecciones tiene. Lo ideal es empezar con un
'stub original', es decir, que no haya sido 'modeado' con anterioridad. Seguramente, tendrá
más detecciones que un 'stub' retocado y reciente, pero es mucho mejor modear desde cero,
desde el original, ya que es un ejecutable mucho más estándar y más fácil de 'modear'. Uno
retocado puede contener un montón de 'retoques' del anterior 'modder' que pueden hacerlo
realmente complicado de manejar. Una vez se obtiene el informe del scanner on-line, hay que
comenzar el proceso por algún AVs en particular, generalmente por uno que tengamos a
mano, o con el que se tenga mucha experiencia o que consideremos relativamente sencillo.
Obviamente algunos AV son muy sencillos de 'modear', sus firmas no son complejas y salen
con cierta facilidad con las técnicas básicas, como 'DSPLIT/AVFUCKER', que
explicaremos próximamente.

Instalación de Antivirus
Para cada AV que detecte el 'stub' habrá que aplicar el proceso de 'modding' y eso implica que
tendremos que disponer de múltiples AVs en nuestro ordenador. Una cosa es segura, la
mayor parte de los AV no va a permitir que haya otro AVs instalado en la máquina y por tanto
nos obligará a desinstalarlos. Una opción es instalar y desinstalar cada AVs para cada proceso
de 'modding' que se desee abordar, lo cual es un poco pesado ya que implica, además del
tiempo de instalación y desinstalación, reiniciar el ordenador en varias ocasiones. Otra opción
es utilizar, siempre que existan, las versiones 'portables' y/o versiones 'command line' de los
diferentes AVs. Además de estas opciones, si disponemos de software de virtualización (y
suficiente potencia en el ordenador para moverlo con soltura) podemos utilizar los 'snapshots'
para tener diferentes antivirus instalados en cada 'snapshot', pero en cualquier caso tendremos
que instalar y desinstalar cada AVs al menos una vez.
Por último, una opción muy interesante es utilizar un programa que nos permita gestionar
copias de seguridad del registro, como por ejemplo 'Registry Workshop'. Mediante este
programa podemos 'engañar' a los AV y que piensen que están ellos 'solitos'. El procedimiento
es sencillo. Se instala el programa, y se hace un 'backup' del estado del registro del ordenador
sin ningún AV instalado, podríamos llamarlo 'backup-sin-AV'. Se instala un AV y se hace un
backup que podríamos llamar 'backup-AV-1'. A continuación, se restaura el 'backup-sin-AV'.
Al instalar el siguiente AV, éste no localizará ningún AV instalado puesto que hemos
restaurado un backup anterior a la instalación del AV-1. Instalado el AV-2, haremos un
backup, al que llamaremos 'backup-AV-2' y así sucesivamente. La cuestión es que todos los
AV estarán instalados juntos, y cada vez que queramos utilizar uno de ellos tendremos que
restaurar el backup correspondiente.
necesario disponer de dichos AVs en el ordenador.

A partir de este punto tenemos todo listo para comenzar a localizar firmas mediante la técnica
'DSPLIT/AVFUCKER', que comenzaremos a explicar en el próximo post.
 'Crypters': Localizando firmas de los Antivirus

En el último post de esta serie sobre 'Crypters' introdujimos el concepto de 'modding', que es una
técnica cuyo objetivo consiste en modificar un 'stub' para hacerlo 'indetectable' a los 'AVs' y de este
modo poder cifrar cualquier 'malware' de manera que éste pueda ejecutarse sin temor a la detección
de los AVs.

Recordemos que un 'crypter' está formado por dos elementos, el 'builder' y el 'stub', aunque en
muchas ocasiones al 'builder' se le denomina simplemente 'crypter', y recordemos también que lo
que se 'moddea' es el 'stub', no el 'builder' ni el 'malware'. Del 'malware' no nos hemos de
preocupar, dado que éste será cifrado por el 'builder' y nunca estará descifrado en el disco duro, solo
en memoria. Y tampoco hemos de preocuparnos por el 'builder', ya que es simplemente una
herramienta para 'crear' el nuevo ejecutable formado por el 'stub' y el 'malware cifrado'. En
definitiva, lo que se 'moddea' es el 'stub' y el primer paso para llevar a cabo el 'modding' es localizar
las firmas de los AVs.

Para 'moddear' un 'stub' lo que se suele hacer es utilizar el 'builder' y crear un ejecutable de prueba
para 'moddear', de forma que en realidad se 'modea' el conjunto del 'stub' y el 'anotador' cifrado.
Recordemos que el 'anotador' es un simple ejecutable cuya misión es verificar su correcta ejecución
(como una simple ventana de alerta). Mediante este archivo de prueba para 'modear' es posible
verificar de forma cómoda si los archivos resultantes de las diferentes pruebas de modificación del
ejecutable son funcionales. En definitiva, es mucho más práctico 'modear' este archivo de prueba, y
que además el 'stub' no se puede ejecutar de forma aislada, ya que genera un error en ejecución al
no localizar el 'ejecutable' cifrado.

Técnica DSPLIT/AVFUCKER
Ésta es una técnica muy extendida para la localización y modificación de firmas de los AV's. En
realidad son dos técnicas, una es 'dsplit' y otra 'AVfucker', pero suelen utilizarse siempre de forma
combinada.
Existen diferentes herramientas que permiten llevar a cabo la aplicación de estas técnicas, pero en
este post voy a tratar de explicar el proceso a nivel conceptual en lugar de basarme en la
herramienta. Así que debéis armaos de paciencia, pues este post va a ser duro. En el próximo post,
explicaré un caso práctico de la aplicación de la técnica 'dsplit/AVfucker' mediante el uso de
herramientas.

Técnica DSPLIT
Partiendo de un archivo ejecutable, la técnica 'dsplit' consiste en generar N archivos intermedios de
forma incremental, es decir, cada uno de esos archivos es igual al anterior más unos cuantos bytes.
Para poner un ejemplo visual, pensemos en un pan de molde. El primer archivo sería la primera
rebana, el segundo archivo sería el conjunto de la primera y segunda rebanadas, el tercero tres
rebanadas y así sucesivamente hasta completar el pan completo.

Los 'stubs' suelen tener un tamaño de unos cuantos miles de bytes, así que la técnica 'dsplit' suele
comenzar por 'rebanadas' de 1.000 bytes. Una vez se dispone de estos N archivos de 1.000 bytes, se
escanean con el AV con el que hayamos decido comenzar. Es decir con el AV cuya firma queramos
localizar. La idea es que a partir de un determinado archivo aparecerán detecciones del AVs. Ahora
hay que afinar y ver a partir de qué 'byte' exactamente hay detección. Por ejemplo, si en el archivo
con 6.000 bytes no hay detección y en el de 7.000 bytes y siguientes ya hay detección, tendremos
que ir buscando en esa frontera entre 6.000 y 7.000 hasta localizar el punto exacto en el que se
produce la detección. Lo que se hace es reducir el rango inicial 1.000 bytes a incrementos de 100
bytes, y se aplican entre los offsets 6.000 y el 7.000 y se vuelve a escanear. De nuevo, hay que
localizar el archivo a partir del cual se produce la detección y se continúa con la iteración, pasando
por rangos de 10 bytes y de 1 byte, hasta localizar el offset exacto, el byte exacto, en el que se
produce la primera detección. Una vez localizado, estaremos ante el fragmento más pequeño del
archivo ejecutable en el que el AV es capaz de identificar código malicioso. Todavía no sabemos
donde está la firma, sino que estamos ante una zona, en la que sabemos que seguro que hay una
firma, o mejor dicho, estamos ante un fragmento de código en el que hay uno o varios elementos
que hacen que el AV identifique ese código como malicioso.

Técnica AVFUCKER

A partir de este momento, se aplica la técnica 'AVfucker' sobre el archivo obtenido mediante la
técnica 'dsplit'. El objetivo de la técnica AVfucker es  generar N archivos de igual tamaño, cada uno
de ellos con un bloque de bytes 'tapado'. Donde 'tapado' quiere decir que los bytes originales son
sobrescritos por un valor escogido (un byte del valor que queramos: '00h', '20h', '90h', etc.). Si
pensamos en el pan de molde en el proceso 'AVfucker' tendremos N archivos de igual número de
rebanadas (el pan completo), y a cada uno de ellos le faltará una rebanada. Al primero le faltará la
primera, al segundo la segunda, etc. Lo que se busca con esta técnica es encontrar una o varias zonas
del archivo de forma que al 'taparlas' la detección del AVs desaparezca.

Una vez escaneados los archivos resultantes con el AV, eliminaremos aquellos que estén
detectados y observaremos los offsets que quedan 'indetectados'. Del mismo modo que el proceso
'dsplit', para cada zona de offsets 'indetectados', iremos reduciendo el tamaño de los bloques
'tapados' hasta llegar a bloques de un solo 'byte'. Una vez escaneados los archivos, y eliminados los
archivos detectados, tendremos una serie de archivos que nos indicarán que si se tapa dicho 'byte'
se está 'alterando' la firma y por tanto se evita la detección del AV.

Para llevar el control de los ficheros generados con estas técnicas, lo que se suele hacer es nombrar a
los ficheros resultantes con el offset correspondiente al corte, en el caso de 'dsplit', o a la sección de
'tapados' en el caso de 'AVfuker'. Las herramientas realizan este proceso de forma automática.
Por ejemplo, si tras el proceso 'AVfucker' nos quedan 4 archivos 'indetectados' llamados 7124_1.exe,
7125_1.exe, 7129_1.exe y 7130_1.exe quiere decir que hay 4 bytes, cuyos offsets, en este caso no
consecutivos, son 7124, 7125, 7129 y 7130. 

¿Es esa la firma? Depende. Ahora toca analizar qué hay en esos bytes. En muchos casos, puede
tratarse de unos bytes que corresponden a una o varias instrucciones del ejecutable o a un string
(cadena de texto). En cuyo caso la respuesta es sí, esa es la firma. En otras ocasiones, puede tratarse
de referencias o saltos a direcciones de memoria de funciones o directamente recaer en la tabla de
importaciones. En estos casos, en realidad estamos ante un tipo de firma 'compleja', normalmente
una firma 'heurística'. Y el resultado de 'AVfucker' debería interpretarse con cierta cautela, siendo la
experiencia y conocimiento del 'modder' la que lo llevará a buscar una u otra solución para evadir la
firma.

En el caso de que la firma sea una cadena de texto, es probable que solo alterando la cadena se
consiga eliminar totalmente la firma. Este sería el caso más sencillo, pero es real, dichas firmas
existen. No voy a señalar a ningún AVs en particular, pero obviamente un AVs que pone una firma en
un string es, cuando menos, muy ingenuo. 

Supongamos que estamos ante un caso de una firma en un 'string' que contiene por ejemplo el texto
"MyStub". Si alterando esa cadena la firma queda 'rota' y por tanto el archivo indetectado,
deberemos comprobar  además si el archivo es funcional. Recordemos que 'AVfucker' ha sido
aplicado sobre un fichero que había sido obtenido previamente con el proceso 'dsplit' y que, por
tanto, no es funcional, es una sección del ejecutable original. La cuestión es que debemos modificar
el byte que hemos observado que 'rompe' la firma en el archivo funcional previo al 'dsplit', es decir,
en el archivo ejecutable de prueba. Esta tarea se lleva a cabo normalmente mediante cualquier
editor hexadecimal. Si una vez hemos alterado dicho byte, el archivo es funcional, perfecto, hemos
sacado la firma. Hay que tener en cuenta que la modificación la hacemos sobre el archivo funcional
de prueba, formado por el 'stub' y el 'anotador' cifrado. Cada vez que se haga una modificación sobre
este archivo de prueba, deberemos hacerla en paralelo sobre una copia del 'stub' o bien, una vez
realizadas todas las modificaciones al ejecutable de prueba, tendremos que extraerle el 'stub'.

Una vez hecho esto, deberemos volver a escanear el archivo con el mismo AV que hemos hecho todo
el proceso y puede que siga detectando el archivo. ¿Por qué razón? porque existe una segunda
firma en otra sección del archivo. Es necesario volver a aplicar 'dsplit' y otra vez 'AVfucker' para
localizar esa segunda firma.

En principio, cuando se localiza la firma mediante 'dsplit/AVfucker', lo lógico, como he comentado, es

estudiar la sección de dicha firma y proceder en consecuencia mediante diferentes técnicas, que
tiene por objetivo 'partir' la firma alterando las secciones sobre las que recae la misma sin 'romper' el
ejecutable. Un adecuado entendimiento formato ejecutable 'PE (Portable Executable)' es
fundamental para lograr dicho objetivo. Sin embargo, sin demasiado conocimiento del formato PE, es
posible igualmente, en ciertos casos y empleando la técnica 'AVfucker', eliminar algunas firmas del
ejecutable. Una vez que el proceso 'dsplit/AVfucker' ha finalizado, puede aplicarse 'AVfucker' sobre
el ejecutable  de prueba en los offsets que 'indetectaban' al hacer 'AVfucker' sobre el archivo
procedente del proceso 'dsplit'. Una vez se dispone de dichos archivos se va probando la ejecución
de todos y cada uno de ellos para ver si alguno de ellos es funcional. Esto es un proceso tipo 'brute
force' pero funciona en muchos casos. Hay que tener en cuenta que quizá no quede ningún archivo
funcional, pero recordemos que en 'AVfucker' hay que elegir un valor para generar los 'tapados'.
Supongamos que hemos elegido el valor '00' para tapar los bytes originales y no ha quedado ningún
ejecutable funcional. Siempre podemos optar por probar las 255 combinaciones posibles para cada
uno de los offsets que indetectan y ver si alguno es funcional. Son 255, y no 256, porque obviamente
hay una combinación, la del valor de 'byte' original, que seguro que es funcional, pero esa es
detectada por el AV.
 'CRYPTERS': practicando la técnica dsplit/Avfucker
Tal y como ya adelanté, en este artículo vamos a poner en práctica lo que hemos aprendido hasta el
momento sobre la evasión de Antivirus, en adelante AVs. En el último post de esta serie sobre
'Crypters', vimos los fundamentos teóricos de la técnica 'dsplit/AVfucker'. En este post voy a tratar de
ilustrar esta técnica con un ejemplo práctico, valiéndome de un caso muy sencillo de aplicación de
esta técnica.

Herramientas
Existen diversas herramientas que permiten aplicar la técnica 'dsplit/AVfucker', concretamente voy a
utilizar una que es bastante cómoda, tiene muchas funcionalidades y es bastante rápida, pero si
buscáis encontraréis otras por los foros relacionados con el tema. En concreto voy a utilizar 'UdTools
Offset Locator 2.0'. También necesitaremos un anotador, así que voy a utilizar 'Antrax-Labs Offset
Anotator' (by The Swash). Adicionalmente, utilizaré un 'Hex Workshop 6.7' como editor hexadecimal
y 'OllyDbg' como disassembler (desensamblador).

Crypter
Para 'modear' un 'stub' hay que disponder del 'crypter' (tanto el 'builder' como el 'stub'). Es
importante conseguir uno que sea 'original', es decir, que no haya sido 'retocado'. Trabajar un
ejecutable previamente 'modeado' es siempre más complicado. Para este ejemplo voy a utilizar
'Simple Crypter 2010' (by DuNeD@i).

AV
Voy a utilizar para este ejemplo una 'firma' bastante sencilla del AV de origen Checo Avast (avast!).
Ese, con esa voz tan sexy que siempre nos recuerda: "La base de datos de virus, ha sido actualizada".
Lo primero que haremos, será configurar adecuadamente el AV para el proceso de 'modding'. Para
ello, desactivaremos todos los 'escudos' en tiempo real y desactivaremos la opción de envío de
muestras (En el caso de Avast hay que desactivar la opción 'Participa en la comunidad avast!')

Entorno de trabajo

Lo primero de todo es mantener una buena organización del entorno de trabajo. Para ello, vamos a
trabajar en una carpeta en la crearemos varias 'sub-carpetas'. Una se llamará 'original' y en ella
guardaremos el 'Crypter Original'. En otra carpeta guardaremos nuestro 'Anotador' y por último las
dos más importantes, a las que se llamaremos 'offsets1' y 'offsets2', que funcionarán como carpetas
de resultados en las que se almacenarán los diferentes archivos generados mediante la aplicación de
la técnica 'dsplit' y 'AVfucker'. En breve veremos el propósito de cada una de estas carpetas. Para
comenzar a 'moddear' necesitamos aplicar el 'crypter' a nuestro ejecutable de prueba, el 'anotador'.
Para ello abriremos el 'builder' (llamado crypterx.exe en este crypter), y seleccionaremos el
'anotador'. Pulsaremos el botón 'Crypt' y se abrirá una ventana del explorador de archivos para
indicar el nombre y ubicación del ejecutable. En este ejemplo lo llamaré 'modme.exe'.

Hey Ho Let's Go!

Dsplit

Ya tenemos todo lo necesario para aplicar 'dsplit' así que vamos allá. Abrimos 'UDTools Offset
Locator 2.0' y arrastramos (o seleccionamos) el ejecutable 'modme.exe' al primer campo del
formulario 'Archivo & Directorio'. En el segundo campo, arrastraremos el directorio 'offsets1'. A
continuación, en la sección 'Método' seleccionamos 'DSplit'. En la sección 'offsets' veremos que los
valores que se aparecen corresponden al offset inicial: 1.000 (comienzo del ejecutable sin la cabecera
PE) y el offset final del archivo (último byte del ejecutable), en ese caso 45.062. En la sección 'bytes',
aparece por defecto el valor 1.000, que es el bloque de 'bytes' que vamos a usar en la primera
iteración del proceso 'dsplit'. Si por algún motivo, nuestro archivo a 'modear' fuese mucho mayor,
podríamos comenzar por bloques de '10.000' bytes, pero lo habitual es comenzar por 1.000 para que
el número de archivos a generar y sobre todo a 'escanear' por el AV sea manejable. En general suele
ser una buena idea seleccionar la opción 'Borrar todos los archivos del directorio seleccionado', de
este modo, en cada ejecución lo primero que se llevará a cabo es el borrado del directorio
seleccionado, por ahora 'offsets1'. Bien, pues ya solo queda pulsar el botón 'Iniciar' y se generarán en
el directorio 'offset1' los archivos de tamaño incremental (1.000 bytes adicionales cada uno) desde el
offset 1.000 hasta el offset '46.000'.

El nombre de cada archivo, se corresponde con el offset en el que número de bytes añadidos al
archivo, y del tamaño del bloque utilizado. Así pues tendremos: 1000_1000.exe, 2000_1000.exe, ...,
46000_1000.exe. 

A continuación, 'escanearemos' con el AV Avast la carpeta 'offsets1'. Pulsaremos botón derecho

sobre la carpeta y seleccionaremos 'Analizar offsets1'. A continuación, nos aparecerá una ventana
emergente de resumen del scan que indicará 'AMENAZA DETECTADA' y pulsaremos sobre el botón
'MOSTRAR RESULTADOS'. Nos aparecerá el detalle del análisis para cada fichero del directorio
'offsets1'. La firma que detecta es la misma en todos los archivos, en concreto: 'Win32:Malware-
gen'. Si nos fijamos, veremos que no aparece ninguna detección de la firma hasta un offset concreto,
en este caso el offset 11.000. A partir de ahí todos los demás offsets son detectados. Por tanto,
sabemos que en el entorno del offset 10.000 el AV reconoce código malicioso y salta la detección de
la firma. 
Vamos a precisar el offset concreto. Para ello, continuaremos con el proceso 'dsplit' en el entorno del
offset 10.000. Volvemos a la aplicación 'UDTools Offset Locator 2.0' e introducimos el offset inicial
9.000 y el offset final 11.000. Esto lo hacemos para evitar problemas con las zonas fronteras. A
continuación seleccionamos el valor de 'bytes' a 100, reduciendo un orden de magnitud respecto del
valor anterior que era 1.000. De este modo, vamos precisando en cada iteración un poco más.
Pulsamos el botón 'Iniciar' y se generan los archivos en 'offsets1'. Todos los archivos del proceso
anterior se habrán borrado si la opción 'Borrar todos los archivos del directorio seleccionado' estaba
marcada. 

Repetiremos el proceso de 'escaneo' mediante la opción 'Analizar offsets1' que nos aparecerá al
pulsar el botón derecho sobre la carpeta. Una vez 'escaneada' la carpeta y desplegado el cuadro de
'MOSTRAR RESULTADOS' veremos que el primer offset detectado es 10.600. Una vez más volveremos
a la aplicación 'UDTools Offset Locator 2.0' y seleccionaremos el rango 1.500 a 1.700 como offsets
inicial y final y reduciremos los 'bytes' de incremento a 10. Volveremos a 'escanear' y esta vez
veremos que el primer offset detectado es 10.560. 

Una última iteración entre 10.550 y 10.570 con un incremento de 1 byte, nos indicará que el offset
exacto en el que se detecta código malicioso es 10.552. Es decir, hasta el byte anterior el AV no ha
sido capaz de detectar la firma, sin embargo, a partir del byte 10.552 ya la detecta. Parece lógico
pensar que los bytes que definen la firma han de estar exactamente en el entorno de 10.552 pero no
es así. La técnica 'dsplit' nos indica que en ese 'pedazo' de archivo seleccionado de 10.552 bytes el AV
es capaz de detectar la firma. Mediante la técnica 'AVfucker' vamos tratar de localizar los bytes que
conforman la firma. Para poder aplicar la técnica 'AVfucker' lo primero que haremos es copiar el
archivo 10552_1.exe de la carpeta 'offsets1' a la carpeta de trabajo.
AVfucker

En la campo 'archivo' del formulario de la aplicación 'UDTools Offset Locator 2.0' teníamos nuestro
archivo 'modme.exe', que es con el que hemos estado trabajando hasta el momento. Ahora
arrastraremos el archivo 10552_1.exe a dicho formulario, ya que es sobre este archivo sobre el que
vamos a aplicar la técnica 'AVfucker'. En el formulario 'directorio' no vamos a hacer cambios y
mantendremos la carpeta 'offsets1'. En la sección 'Método' seleccionaremos 'Av-Fuck'. Veremos que
ahora el offset inicial es 1000 y el offset final 10552, mientras que el rango de 'bytes' vuelve a ser
1000. La diferencia fundamental entre 'dsplit' y 'AVfucker' es que con 'dsplit' solo recortamos el
ejecutable en secciones, mientras que con 'AVfucker' lo que hacemos es 'tapar' o 'rellenar' secciones
del ejecutable con un valor determinado. Por tanto, en la aplicación 'UDTools Offset Locator 2.0'
debemos indicar con que valor queremos 'rellenar'. podemos escribir el valor hexadecimal que
queramos, siendo los valores '00' ó '90' los más usados generalmente. También podemos usar el
botón 'A' para rellenar el campo con un valor aleatorio. El valor a escoger puede depender de varios
factores, en general, '90' (instrucción NOP en ensamblador) es un buen valor de 'relleno' para
comenzar. Pulsamos 'Iniciar' y se generan en 'offsets1' 10 archivos con sus respectivas zonas de 1000
bytes rellenos del byte '90'.
Ahora vamos a escanear 'offsets1' mediante el AV. Nos indicará 'AMENAZA DETECTADA' y si
pulsamos 'MOSTRAR RESULTADOS' veremos que hay 9 offsets detectados. Ahora, lo que haremos, a
diferencia del método 'dsplit' es eliminar los archivos cuyos offsets han sido detectados. Podemos
indicar 'Aplicar esta acción a todos: Eliminar' y pulsar 'Aplicar'. Esto dejará en el directorio los
archivos cuyos offsets 'indetectan' la firma. En este caso, solo queda uno, el archivo con offset
10.000. A continuación, desde 'UDTools Offset Locator 2.0' pulsaremos el botón 'Mostrar Offsets' y se
mostrarán los diferentes offsets 'indetectados'. Si hacemos doble-clic sobre un rango concreto éste
se agregará a la herramienta, y automáticamente se reducirá el rango de bytes para la siguiente
interacción. En este caso, hay un único rango de 'indetección' por el momento, offset inicial 10.000,
offset final 11.000 y bytes se reduce a 100. Si pulsamos de nuevo iniciar, aparece un aviso de que el
offset 11.000 es mayor que el tamaño del archivo, si pulsamos aceptar se rellenará como offset final
el valor correcto (10.552) y nos permite continuar. Pulsamos de nuevo 'Iniciar' y se generan los
archivos en 'offsets1' que pasamos a escanear. Curiosamente, no nos detecta amenaza en ninguno
de los archivos. Esto es no es habitual, pero en ocasiones ocurre que hay un rango muy grande de
offsets que 'indetectan' la firma. Lo que podemos hacer ahora, es elegir uno de los archivos, por el
ejemplo el primero de los offsets 'indetectados' y continuar reduciendo el rango de bytes hasta llegar
a 1 byte. En realidad podemos trabajar con todo el rango, pero al ser tan grande vamos a generar
muchos ficheros, especialmente al llegar a valores de un byte. Es preferible hacerlo por bloques. Por
tanto, rellenamos con el valor 10.000 el offset inicial y 10.100 el offset final y reducimos a 10 el rango
de bytes. Analizamos con el AV el resultado y nos detecta los offsets iniciales, pero deja
'indetectados' desde el 10.040 al 10.100. Reducimos a un byte y repetimos. Escaneamos y
observamos que los 60 offsets 'indetectan' la firma.

Si miramos la zona con detenimiento y la ayuda de un editor hexadecimal, Hex Workshop en este
caso, parece que se corresponde con algunas cadenas de texto. Para asegurarnos, examinamos
también la zona con OllyDbg. Podemos probar a ir cambiando algunos de estos valores a ver si
encontramos algún offset que mantenga funcional el ejecutable. Hay que tener en cuenta que hemos
trabajado con un archivo recortado obtenido del proceso 'dsplit', por tanto, no es posible hacer
pruebas sobre dicho archivo. Tendremos que hacer las pruebas de dichas modificaciones sobre el
archivo ejecutable original al que habíamos llamado 'modme.exe'. Si hacemos una copia del mismo
podemos probar a alterar manualmente algunos de los offsets para ver si nos deja 'funcional' el
archivo, aunque también podemos continuar con el proceso 'avfuck' para localizar algún archivo
funcional. 
Si estuviésemos ante una zona de código con instrucciones, lo más práctico sería aplicar técnicas
como RIT o XOR para alterar las instrucciones de forma que se partiese la firma pero no se viese
alterado el resultado del ejecutable. En este caso, como se trata de cadenas de bytes, es más práctico
buscar alguna alteración de las mismas que no dañe el ejecutable. 

Lo que vamos a hacer es aplicar la técnica 'avfucker' sobre el archivo 'modme.exe' en lugar de
trabajar sobre el archivo obtenido mediante 'dsplit' (10552_1.exe) y dejar los archivos resultantes en
la carpeta 'offsets2'. Para ello arrastraremos el archivo 'modme.exe' y la carpeta 'offsets2' a los
correspondientes campos de la herramienta y seleccionaremos el rango de offsets previo: 10.040-
10.100. Pondremos el rango de bytes a 1 y seleccionaremos el relleno con '90'. Una vez tengamos los
archivos en la carpeta 'offsets2' deberíamos eliminar de la misma aquellos cuyos offsets no
'indetectan' la firma. Hasta ahora, este proceso de eliminación lo hemos hecho mediante el 'escaneo'
con el AV, pero hay que tener en cuenta que si hubiese alguna segunda firma en el archivo, el AV la
detectaría y nos eliminaría todos los ficheros. Por lo tanto, lo que tenemos que hacer es eliminar de
'offsets2' los archivos que previamente hemos eliminado mediante la detección del AV de la carpeta
'offsets1'. En este caso concreto, todos los archivos del rango comprendidos entre el offset 10.040 y
10.100 están 'indetectados', y por ende la comparación de 'offsets1' y 'offsets2' quedará igual y no se
eliminará ningún archivo, pero por regla general, esté proceso eliminará archivos de 'offsets2'. La
herramienta 'UDTools Offset Locator 2.0' dispone de un botón en el menú superior que permite
hacer está eliminación. Como en este caso no hay eliminación, probaremos a ejecutar cada uno de
los archivos que se han generado en la carpeta 'offsets2'. Si alguno de ellos es funcional habremos
roto la firma.
En nuestro ejemplo hay numerosos offsets en dicho rango que al ser rellenados con el byte '90' dejan
funcional el ejecutable y por tanto 'indetectan' la firma.

Además no existe una segunda firma del AV para este archivo, sin embargo, en muchos casos, al
conseguir tapar la primera firma, hay que continuar con el proceso 'dsplit' para localizar un segundo
bloque de detección y volver aplicar AVfucker para localizar los offsets de las firmas adicionales.

Aplicar modificación al stub

Hay que tener en cuenta que hemos trabajado con el archivo 'modme.exe' para poder verificar su
funcionamiento, pero en realidad lo que necesitamos es aplicar los cambios realizados al 'stub'. Para
ello podemos hacer una copia del 'strub.exe' original y repetir los cambios realizados sobre
'modme.exe' también sobre el 'stub', o bien podemos extraer el 'stub' del archivo 'modme.exe'.
Mediante un editor hexadecimal podemos llevar a cabo fácilmente esta operación. Simplemente es
necesario conocer el tamaño del 'stub' original y seleccionar desde el primer byte hasta el tamaño
final del 'stub' y guardar los bytes seleccionados a un nuevo archivo.

Como ya comenté al inicio, éste es un caso básico de eliminación de una firma de AV que sirve para
ilustrar la técnica 'dsplit/avfucker' de una manera sencilla. Evidentemente hay multitud de firmas
muchísimo más complejas que ésta, pero este ejemplo confirma la debilidad de algunas de las firmas
que establecen los AVs.