Karpoff Spanish Tutor

Programa:

Aspack.exe


 

PROTECCION:

El archivo está enpacado y no puede ser editado

Descripcion:

Tal tal tal

Dificultad:

Si sigues bien los pasos es fácil, pero hay que aprender, no copiar

DOWNLOAD:

http://xxxx

Herramientas:

Softice, editor de encabezado PE (recomiendo Procdump)

CRACKER:

R!SC

  FECHA:

../../....

 

 INTRODUCCION

Algo de teoría

 Un compresor o encriptador de archivos PE (portable executable) tiene que agregarle al exe comprimido/encriptado el código descompresor/desencriptador. Si encripta/comprime la tabla de importaciones, tiene también que cargarla (punto de ataque). También, mientras el exe se carga, tiene que tener suficiente memory reservada para descomprimir/desencriptar el código/datos (más un bit de más para su propio código(y por ahí más, para los datos comprimidos)). No sabemos el tamaño del programa en sí, pero mirando a la cabecera podemos obtener el tamaño del proceso, que será lo suficientemente amplio para que el proceso se cargue/desempaque en ella y corra.

 Yo, cuando desempaco un archivo, trato de detectar la tabla de importaciones antes de que sea iniciada, la vuelco a disco (dump), después traceo hasta el punto de entrada original y vuelco también el resto del proceso. Los pego juntos, y luego arreglo la cabecera y trabajo hecho. Algunos packers, dejan los segmentos en la cabecera, haciendo que encontrar la dirección virtual para la tabla de importaciones realmente fácil, otros "desaparecen" las secciones para crear una vacía para desempacar los datos comprimidos, y una última sección conteniendo su propia tabla de importación, ícono, código de desempaque, etc... Es un trabajo fácil, pero se necesita un acercamiento diferente, que será probablemente cubierto en el número dos de estos tutoriales.

 

 AL ATAKE

Primera parte

Ensuciándonos las manos.

 Bien, prendomos el editor PE del ProcDump y saquémosle algo de información a nuestro blanco. Queremos el tamaño del proceso y si es posible, el yamño y dirección virtual de la tabla de importaciones. Por suerte, en este archivo, cada sección ha sido dejada intacta.

Así verás en el editor PE:

 Size of image : 00079000 ; Cuanta memoria reservar para este archivo pe

Image Base : 00400000 ; bah

 .idata

Virtual Size : 00002000 ; tamaño de idata en la memoria

Virtual Offset : 00046000 ; Dirección virtual de idata (+Image Base == 00446000)

 .rdata

Virtual Size : 00001000

Virtual Offset : 00049000

 Bueno, será un mal momento para decir esto, pero me cago en esto. La tabla de importaciones podría estar en .idata, or en .rdata. Mirando sus tamaños, pondría mi dinero por .idata.

Parte 2

Volcando una virgen (la tabla de importaciones:)

 Prendamos el Frogsice, ya que esta versión de .aspr tiene algo de trucos anti-softice. Ponemos un bpx en LoadLibraryA, and run aspack.exe...... Cuando Sice salte, chequea la memoria en 446000 y 449000, para ver si la tabla de importaciones ha sido desempacada.

 :bpx loadlibrarya

Break due to BPX KERNEL32!LoadLibraryA

Break due to G

:dd 446000 l 40

0030:00446000 00000000 00000000 00000000 0004669C .............f..

0030:00446010 0004612C 00000000 00000000 00000000 ,a..............

0030:00446020 000468B6 000461AC 00000000 00000000 .h...a..........

0030:00446030 00000000 000468D0 000461B4 00000000 .....h...a......

 

Bien!!, 446000 no son todos ?? ?? ?? ??, lo que significa que ya ha sido desempacada! Y las mejores noticias son que se ve exactamente como lo que buscamos. Los descriptores_de_importacion_de_imagen, una estructura de 5 palabras (words, de 2 bytes) conteniendo los punteros a el primer_thunk, , y primer_thunk_original. (por supuesto, no en ese orden). Sigue la parte aburrida:

 ¿Cual es el formato de los descriptores_de_importacion_de_imagen? Bueno, contienen 5 dobles palabras (dword, 4 bytes), y.... sigue leyendo.

 Dd offset del primer_thunk_original

Dd estampa de tiempo y fecha

Dd forwardchain

Dd offset del nombre_de_librería

Dd offset primer_thunk

 Timedatestamp y forwardchain son usualmente puestos en cero, el primer_thunk_original no es necesario, ya que es una copia exacta del primer_thunk. nombre_de_librería es el puntero al nombre de la librería :d y el primer_thunk es el array de los ascii's. Es entonces el primer_thunk el que se sobreescribe con las direcciones de las apis de la tabla. Los descriptores _de_ importacion _de_ imagen se terminan con cinco dobles palabras NULL (de valor 0). Una buena pista para encontrar esto es buscar el comienzo del primer_thunk (que contendrá o los punteros a los asciis o la verdadera dirección de la api (xx xx F7 BF o algo para las apis dl kernel (en 9x))), o buscar un nombre de librería, luego, usando la dirección de ese nombre, puedes encontrar los descriptores_de_ importacion_de_imagen.

 Solo una pequeña sesion de ingerniería inversa para nuestros descriptores _de_ importacion _de_ imagen:

 :dd 446000 l 40

0030:00446000 00000000 00000000 00000000 0004669C .............f..

0030:00446010 0004612C 00000000 00000000 00000000 ,a..............

 4669c es el puntero a nuestro nombre de librería (RVA, debes sumar la imagebase)

 :db 44669c l 10

0030:0044669C 4B 45 52 4E 45 4C 33 32-2E 44 4C 4C 00 00 00 00 KERNEL32.DLL....

 y 4612c es el puntero al firstthunk para esa librería

 :dd 44612c l 10

0030:0044612C 000466AA 000466C2 000466DA 000466F2 .f...f...f...f..

 estos son punteros a los asciis, los nombres reales de las apis. Pero apuntan a dos bytes antes que los asciis, a la HINT . . 466ªa es la primera api a cargar,

466c2 es la segunda .. .Terminada en NULL, con una simple doble palabra.

 :db 0004466aa l 20

0030:004466AA 00 00 44 65 6C 65 74 65-43 72 69 74 69 63 61 6C ..DeleteCritical

0030:004466BA 53 65 63 74 69 6F 6E 00-00 00 4C 65 61 76 65 43 Section...LeaveC

 Bueno, esa es definitivamente nuestra vigen tabla de importaciones.Abajo con ella!! démosle dump, y recuerda la dirección de los descriptores de importacion de imagen.

 :pagein d 446000 2000 c:\aspack.idata.bin (en el softice)

Parte 3

 Dumpeando el resto y arreglando el encabezado.

 Bueno, supongo que sabrán como seguir la ejecución de un programa (trace, F10 o F8). Breakpoint en loadlibrarya. Poner puntos de ruptura en hardware (hardware breakpoints) antes de pasar sobre una call ayuda bastante, ya que estos bp's no parchean la memoria con un CC (int03h), no son sobreescritos cuando se desempacan datos sobre ellos. 'bpm <dirección> x'. Todo el código del desempacador parece estar alrededor de 00C1xxxx. Entonces, si encontramos saltos a direcciones menores, es probable que el código original se encuentre allí.

 :bpm c10da8 x

Break due to BPMB #016F:00C10DA8 X DR3

:u eip l 30

0167:00C10E98 89C4 MOV ESP,EAX

0167:00C10E9A 89D0 MOV EAX,EDX

0167:00C10E9C 8B1D6C66C100 MOV EBX,[00C1666C]

0167:00C10EA2 89041C MOV [EBX+ESP],EAX

0167:00C10EA5 61 POPAD

0167:00C10EA6 50 PUSH EAX ; push 442b98

0167:00C10EA7 C3 RET ; ret a esa dirección.... mmmm

:?eax

00442B98 0004467608 "D+˜"

:u eip l 10

0167:00442B98 55 PUSH EBP

0167:00442B99 8BEC MOV EBP,ESP

0167:00442B9B 83C4F4 ADD ESP,-0C

 Que bueno que se ve esto... Anotemos esa dirección (el punto de entrada origina) vlolquemos a disco el proceso entero entonces..... sería mejor si borráramos los bp's que pusimos (bc*).

 :pagein d 400000 79000 c:\aspack.volcado.exe

 ahora tenemos que pegar la tabla virgen en este dump que hicimos... arreglar el encabezado y listo!!!

 Ya que el volcado lo hicimos desde 400000, los offsets de archivo (file offsets) serán iguales a las RVAs (o simplememnte las direcciones). Nuestra tabla de importación estaba en la RVA 46000, Entonces estará en el mismo offset... (46000 para aquellos que no la han cachado).

Usa un editor hexadecimal para copiar los 2000 bytes de aspack.idata.bin' sobre los 2000 bytes de datos en 'aspack.dumped.exe',

Desde el offset 46000 al 48000 .. ..

 Psize==vsize => Tamaño físico = Tamaño virtual

Offset==rva => Dirección física = Dirección virtual (en memoria)

 Entonces cada offset será equivalente a su RVA ahora.

 .CODE RVA : 00001000 .. . CODE nuevo file offset : 00001000

 Cada tamaño virtual será igual al tamaño físico de esta sección a menos que . . (Son normalmente alineados en una límite de 1000h bytes. El tamaño virtual podría ser 45001,pero cuando windows lo carga, reservaría 46000h bytes para esta sección)

 CODE virtual size : 00042000 .. CODE nuevo RAW size : 00042000 . .

 Entonces, ve y arregla el encabezado, con el Procdump... Si lo has hecho bien, , cuando salves los cambios y refresques el explorer, el ícono estará de vuelta en su lugar.

 Hay dos cosas más que arreglar antes de que funcione . El punto de entrada del programa y la ubicación de la tabla de importaciones

 El nuevo punto de entrada es 00042B98 . (Punto original de entrada - base de la imagen)

 Haz click en el botón 'directory para editar la dirección de la tabla de importaciones.

 La nueva RVA de la tabla de importaciones es--> 46000 . (Rva de los descriptores _de_ importacion_ de_la_imagen)

¿Tamaño de la tabla de importaciones? Probablemente mayor que cero :b

 Guarda los cambios, sal del procdump, cruza los dedos... y ejecuta aspack.volcado.exe

 Bueno, anda, anda dulcemente. . No está totalmente resaturado, todavía tenemos el viejo código del empacador y la sección de recursos está medio magullada todavía, con algunos recursos movidos a la sección .aspr también. Jeh No puedes desensamblar el archivo!!!!. Edita las características de la primera sección, pasalas de C0000060 (datos, escribibles) a 60000040(código, ejecutable) o E0000060 (codigo, datos, etc....)

 Fin de este hermoso tutorial

 Busquen Unpacking #2 y #3, que ya aparecerán!!!!!!
 

 

 

Karpoff Spanish Tutor: Pagina dedicada a la divulgacion de informacion en Castellano, sobre Ingenieria Inversa y Programacion. Email "Colabora con tus Proyectos"

www.000webhost.com