Nada aun
Páginas: 6 (1326 palabras)
Publicado: 19 de marzo de 2011
Victima Protección Herramientas Objetivo
VB6.exe (Aimboyd DXL) Asprotect 2.4 Olly, ODBGscript 1.67, ImportREC Desempacar Asprotect
Introducción
Bueno volvemos a la carga con otro Asprotect de los nuevos, esta vez a petición de un amigo de la lista el_chavo. En este tutorial solo trataremos el unpack de protector, no el crackeo del programa. Esta vez el packer es un poco más sencillo que elde mi último tuto. Como veremos el programa está hecho en VB Nativo lo cual hace más sencillo localizar el OEP, en resumen el packer tiene: Detección de depuración Byte Stolen IAT (una entrada mala) Reparación de los famosos CALL
Conociendo al enemigo
Si pasamos el programa por el PEID vemos esto:
Como este PEID es viejito y no tengo mantenido las signaturas pues lo único que podemossacar en claro es la protección pero no su versión. Si lo pasamos por el ASPrINF que es específico para el Asprotect nos da:
Bueno vemos que es de lo más nuevo que hay, el último es el 2.5 Como el nombre del fichero (vb6.exe) es un tanto sospechoso vamos a ver si realmente es un VB. Para ello simplemente vamos a cargarlo en Olly, lo ejecutamos para que se descomprima en memoria, ponemos un bmp enla sección de código y miraremos la IAT a ver si canta. Antes de nada este packer si está configurado para comprobar la existencia de debugger, esta vez no me compliqué la vida y usé el plugin phantom configurado de la siguiente manera:
Bueno con esto lo ejecutamos paramos y llegamos aquí.
Como podemos ver hemos caído en el módulo msvbvm60, por lo que estamos ante un VB, lo cual nosfacilitará mucho la vida.
Buscando el OEP
Como estamos ante un VB la búsqueda del OEP se facilita muchísimo. Todos los VB llaman al comienzo a la API ThunRTMain. La cosa es sencilla vamos a poner un HE (Hardware Breakpoint on Execute) rearrancamos el Olly y esperamos a que pare, vamos a ver. Una vez parado vemos la pila
Nos dice que viene de 1ED0000. Eso es malo ya que es una zona del packer, estoquiere decir que estamos ante Stolen Bytes. Si miramos el EP de un programa en VB tenemos la siguiente estructura: JMP DWORD PTR DS:[dir a IAT] … JMP DWORD PTR DS:[dir de IAT a ThunRTMain] PUSH Dir a string con la versión del VB CALL a dir del JMP DWORD PTR DS:[dir a IAT a ThunRTMain] 4 ceros Lo que faltan son las líneas en Rojo y los JMP de la IAT a saber cómo nos lo encontraremos. Lo que vamosa hacer es buscar a partir de la sección .code la dirección de ThunRTMain, en mi PC es la dirección 733ADE3E, como siempre en la búsqueda alteramos los bytes.
Y se detiene aquí
Si vemos la dirección en la ventana Dump queda un poco más bonito. Bueno los siguiente es buscar el JMP DWORD PTR DS:[4011F0] Lo buscamos en Binario FF 25 F0 22 40 00 Y llegamos aquí
Pues bien el OEP está en40249A. Y reponiendo los Bytes que faltan la cosa debe de quedar así.
El valor del PUSH lo sacamos de la pila, y no olvidar poner los 2 BYTES a 0 después del CALL, sino el VB no arrancará.
Reparando la IAT
Bueno sabemos ya que la IAT se encuentra a partir de la dirección 40100 vamos a ver como se encuentra.
Inicio de IAT
Fin de IAT Y en medio una entrada mala.
Bueno solo 1 no esta mal.Para averiguarla lo que vamos a hacer es poner un HW on Write DWORD sobre la dirección de la entrada mala (401124) y justo la anterior (401124), para ver donde realiza el cambio y reiniciamos Olly.
Reiniciamos, ponemos la dirección de la IAT en la ventana DUMP y vamos pasando los BP donde va parando hasta llegar a esta zona
Si vemos el DUMP la IAT ya se está formando
Acabamos deescribir la API buena de la dirección 401120 y lo ha realizado en la dirección 00E453AD. Damos a RUN y veamos donde pone la mala.
Pues la ha escrito un poco más arriba en la dirección 00E4538D Si miramos un poco arriba vemos que tenemos 2 JMP que va a una función no alineada, es decir tenemos ofuscación.
Vamos a situarnos encima de una de ellas y damos a Enter a ver a donde nos lleva.
Pues...
VB6.exe (Aimboyd DXL) Asprotect 2.4 Olly, ODBGscript 1.67, ImportREC Desempacar Asprotect
Introducción
Bueno volvemos a la carga con otro Asprotect de los nuevos, esta vez a petición de un amigo de la lista el_chavo. En este tutorial solo trataremos el unpack de protector, no el crackeo del programa. Esta vez el packer es un poco más sencillo que elde mi último tuto. Como veremos el programa está hecho en VB Nativo lo cual hace más sencillo localizar el OEP, en resumen el packer tiene: Detección de depuración Byte Stolen IAT (una entrada mala) Reparación de los famosos CALL
Conociendo al enemigo
Si pasamos el programa por el PEID vemos esto:
Como este PEID es viejito y no tengo mantenido las signaturas pues lo único que podemossacar en claro es la protección pero no su versión. Si lo pasamos por el ASPrINF que es específico para el Asprotect nos da:
Bueno vemos que es de lo más nuevo que hay, el último es el 2.5 Como el nombre del fichero (vb6.exe) es un tanto sospechoso vamos a ver si realmente es un VB. Para ello simplemente vamos a cargarlo en Olly, lo ejecutamos para que se descomprima en memoria, ponemos un bmp enla sección de código y miraremos la IAT a ver si canta. Antes de nada este packer si está configurado para comprobar la existencia de debugger, esta vez no me compliqué la vida y usé el plugin phantom configurado de la siguiente manera:
Bueno con esto lo ejecutamos paramos y llegamos aquí.
Como podemos ver hemos caído en el módulo msvbvm60, por lo que estamos ante un VB, lo cual nosfacilitará mucho la vida.
Buscando el OEP
Como estamos ante un VB la búsqueda del OEP se facilita muchísimo. Todos los VB llaman al comienzo a la API ThunRTMain. La cosa es sencilla vamos a poner un HE (Hardware Breakpoint on Execute) rearrancamos el Olly y esperamos a que pare, vamos a ver. Una vez parado vemos la pila
Nos dice que viene de 1ED0000. Eso es malo ya que es una zona del packer, estoquiere decir que estamos ante Stolen Bytes. Si miramos el EP de un programa en VB tenemos la siguiente estructura: JMP DWORD PTR DS:[dir a IAT] … JMP DWORD PTR DS:[dir de IAT a ThunRTMain] PUSH Dir a string con la versión del VB CALL a dir del JMP DWORD PTR DS:[dir a IAT a ThunRTMain] 4 ceros Lo que faltan son las líneas en Rojo y los JMP de la IAT a saber cómo nos lo encontraremos. Lo que vamosa hacer es buscar a partir de la sección .code la dirección de ThunRTMain, en mi PC es la dirección 733ADE3E, como siempre en la búsqueda alteramos los bytes.
Y se detiene aquí
Si vemos la dirección en la ventana Dump queda un poco más bonito. Bueno los siguiente es buscar el JMP DWORD PTR DS:[4011F0] Lo buscamos en Binario FF 25 F0 22 40 00 Y llegamos aquí
Pues bien el OEP está en40249A. Y reponiendo los Bytes que faltan la cosa debe de quedar así.
El valor del PUSH lo sacamos de la pila, y no olvidar poner los 2 BYTES a 0 después del CALL, sino el VB no arrancará.
Reparando la IAT
Bueno sabemos ya que la IAT se encuentra a partir de la dirección 40100 vamos a ver como se encuentra.
Inicio de IAT
Fin de IAT Y en medio una entrada mala.
Bueno solo 1 no esta mal.Para averiguarla lo que vamos a hacer es poner un HW on Write DWORD sobre la dirección de la entrada mala (401124) y justo la anterior (401124), para ver donde realiza el cambio y reiniciamos Olly.
Reiniciamos, ponemos la dirección de la IAT en la ventana DUMP y vamos pasando los BP donde va parando hasta llegar a esta zona
Si vemos el DUMP la IAT ya se está formando
Acabamos deescribir la API buena de la dirección 401120 y lo ha realizado en la dirección 00E453AD. Damos a RUN y veamos donde pone la mala.
Pues la ha escrito un poco más arriba en la dirección 00E4538D Si miramos un poco arriba vemos que tenemos 2 JMP que va a una función no alineada, es decir tenemos ofuscación.
Vamos a situarnos encima de una de ellas y damos a Enter a ver a donde nos lleva.
Pues...
Leer documento completo
Regístrate para leer el documento completo.