7A69 Issue 15 - Manual unpacking AsProtect
|-----------------------------------------------------------------------------|
[ 7a69#15 ] [ 23-11-2003 ]
\ /
\-------------------------------------------------------------------------/
{ 14 - Manual unpacking AsProtect }{ esn-min }
|-----------------------------------------------------------------------|Herramientas: SoftIce, IceDump, ImportReconstructor, Masm 5.0, FileInspector XL, Bonker's PE Fixer v1.0
* Estas herramientas son solo una guia de lo que se podra necesitar, pero tanto da que se use un debugger u otro si los pasos se hacen bien.
(No uso acentos en el tutorial para evitar posibles problemas de compatibilidad entre plataformas)
Este es el indice que se va a seguir a lo largo del tutorial:
- Que es la IAT
- Encontrar el OEP del programa
- Dumpear
- Generar una rutina para reparar la IAT (mas o menos AutoTrace de ImpRec ;P)
- Injertar esta rutina y ejecutarla en la victima (inline patching)
- Arreglar a mano aquellas apis que aun sean invalidas
- Solucion a posibles problemas
Cabe destacar que en este tutorial la reparacion de la IAT sera completamente manual, Import Reconstructor solo sera utilizado para generar la IT en su momento y para saber que partes de la IAT hemos arreglado bien y cuales no.
¿IAT? ¿Institut für Angewandte Trainingswissenschaft?
El termino IAT significa Import Address Table
Como bien sabemos a lo largo de la ejecucion de un programa, este puede llamar a las apis de windows. Si esto lo realizara con un
call direccion_directa_a_la_apiSabiendo que las apis en cada maquina estan situadas en una zona de memoria distinta dependiendo de la version de windows y de las dlls, seria un verdadero problema.
Lo que se hace entonces es rellenar una tabla con las direcciones de las apis y cuando se tenga que acceder a alguna de ellas hacerlo de la siguiente manera:
call direccion
[codigo]
direccion:
jmp dword ptr [IAT] ;(Import Address Table)Esta tabla la rellena windows en funcion de la IT (Import Table), pero resulta que AsProtect la elimina y redirige la IAT a un conjunto de rutinas suyas que ya tienen precalculadas por el packer las direcciones de cada api.
Vayamos manos a la obra. Buscando el OEP (Original Entry Point)
En el caso de cualquier empacador, tarea obligatoria es la de buscar el punto de entrada al programa original. Me explico; cuando empacamos una aplicacion, se modifica el punto de entrada hacia la rutina del packer, que es la que se encargara de descomprimir los datos y de proteger el programa (crc y demas). Asi que ahora hay que distinguir entre el EP y el OEP, el EP es una dword de la cabecera que apunta a la primera instruccion que se ejecutara, el OEP viene a ser esta dword antes de que aplicaramos la "armadura" sobre el programa.
El sistema que se usa para encontrar el OEP consiste en fijarse cuando finaliza la rutina del packer y le pasa el control a la primera seccion de la aplicacion original, la primera instruccion que se ejecute de esa seccion estara en el punto de entrada original.
Esta tarea se puede realizar de distintas maneras, las mas comunes bienen explicadas a continuacion;
Metodo 1
Una facil manera de localizar esta direccion y que ademas el 80% de los casos tiene exito es poner un breakpoint en alguna api que veamos que todos los compiladores la usen al inicio de sus programas. Despues de comprobar que ciertamente es asi con muchos de ellos, y que la api en cuestion es GetVersion, comprobaremos que con este breakpoint caeremos directos casi al inicio de la primera rutina del programa original. Ahora solo haria falta localizar el principio de esta, recordemos que para ajustar la pila se hace de la siguiente manera:
push ebp <--- aqui estaria el OEP
mov ebp, espSin embargo resulta que asprotect redirige las apis y hay algunas de ellas que precisamente lo que hace es sustituirlas por un
mov eax, dword ptr [direccion] (no saltara el breakpoint)Estas apis son funciones y como tales retornan un valor (modifican unicamente eax).
Algunos ejemplos de estas podrian ser:
GetCommandLineA
GetVersion <----- adios OEP :_/
GetCurrentProcessId(Luego se hablara mas detalladamente de esto al reconstruir la IAT)
En fin, siempre podemos probar con otras apis que se usen al inicio de los programas.
Metodo 2
Lo mas rudimentario y basico: tracear desde el principio del programa. Con esto no solo se podra ver que va haciendo AsProtect mas o menos, sino que ademas llegara un momento en que toparemos con el OEP.
Lo dicho, vamos traceando con StepOut y cuando entramos en un bucle colocamos un breakpoint fuera de este y seguimos traceando... y dura... y dura... y despues de un dia entero encontramos nuestro querido punto de entrada. uhmm.. pasemos al metodo 3 xD
Metodo 3
IceDump nos implementa a SoftIce la opcion /Tracex, la funcion de la cual es la de colocar ena especie de bpx en un bloque de memoria. Este sistema puede llevar varios minutos dependiendo de la maquina de la que dispongamos. (TRW tambien tiene una opcion similar)
El sistema seria usar /Tracex abarcando toda la primera seccion (donde debe estar comprendido el OEP) y esperar a que salte softice.
Para realizarlo
Cargamos el programa en el Loader de Softice y traceamos hasta que vayamos a parar fuera de la primera seccion
/tracex 401000 fin_de_la_primera_serccionCuando vuelva a saltar el debugger hay que comprobar que verdaderamente estemos en el inicio del programa, de no ser asi tracearemos hasta un ret cercano que nos conducira otra vez a la memoria del packer y repetiremos el tracex. Una vez no encontremos ningun ret que nos retorne al packer querra decir que habiamos aterrizado en el OEP, lo anotamos x)
Como esto lleva bastante tiempo y consume muchos recursos ahi va un truco que lei en un tutorial de Tsehp. Podemos colocar un breakpoint en GetVolumeInformationA y luego realizar el tracex, de esta manera el tiempo de espera sera muchisimo menor.
Volcando la memoria
Una vez en el punto de entrada se procede a dumpear
/dump imagebase imagesize c:\archivo.exeY luego dejaremos el proceso "en coma" para irle reparando la IAT
a eip
jmp eipSiempre que se dumpea un archivo con IceDump, este no tiene las secciones como es debido. Si nos fijamos no aparece ni el icono. Esto es asi porque ahora los FisicOffsets y FisicSizes han que ser iguales a los virtuales.
Con Procdump se pueden ir igualando el tamaño de las secciones una por una, uff hay muchas eh. Para esto disponemos tambien de la aplicacion Bonker's PE Fixer que lo realiza automatico x)
Tambien cambiaremos el EP por el OEP que encontramos antes. Solo recordar que hay que restarle la imagebase.
Primeros contactos con la IAT. Redireccion y SemiEmulacion
Recordemos lo que tenemos hasta ahora:
- El OEP
- Un archivo dumpeado con secciones ajustadas y el punto de entrada cambiado
- Un proceso "en suspension" con un bucle infinito
Ahora seria aconsejable localizar con Import Reconstructor todas quellas zonas de la IAT que no apunten a una Api directamente.
Para proceder, abrimos ImpRec y seleccionamos el proceso que tenemos en suspension. Introducimos el OEP (sin la imagebase) y le damos al boton de localizar la IAT.
El programa nos devolvera la RVA de la IAT y su tamaño, anotamos estos datos en algun sitio porque luego los vamos a necesitar y le damos al boton de get imports. Nos saldra el carro de importaciones, entonces solo hay que fijarse en aquellos punteros que no muestran ninguna api (Asprotect nos ha redirigido parte de la IAT).
Veamos con que situaciones podemos encontrarnos:
En SoftIce escribimos
u *un_RVA_cualquiera_de_la_IAT_que_sea_malo
- Un salto directo:
jmp direccion_real_de_la_apiEn este caso fabricaremos una rutina que rastree la IAT en busca de algun puntero que nos lleve a un jmp, de ahi saque la direccion de la api y luego la grave en la IAT para, posteriormente, fabricar una IT correctamente.
El opcode de jmp es 0E9h y los 4 bytes posteriores nos indican el numero de bytes que saltara. De esta manera tendriamos:
jmp(largo) aki ;E900000000 (los 4 bytes se leen al reves)
aki: ;Nuestra rutina:
start:
mov edi, RVAiat ;RVA del principio de la IAT (Nos lo dio ImpRec)
mov ecx, tamano ;Tamaño de la IAT
otromas:
mov ebx, edi
mov ebx, [ebx] ;ebx deberia apuntar directamente a alguna api si
;no queremos repararlo luego xD
; Esta dentro del rango?
cmp ebx, rang_inf ;Si le decimos que solo inspeccione aquellos
jb yata ;punteros que se encuentren dentro de cierto rango
cmp ebx, rang_sup ;evitaremos que el programa falle al encontrar
ja yata ;dwords nulas o dwords que ya son buenas
cmp byte ptr [ebx], 0e9h ;ebx apunta al jmp loquesea
jnz no_es_un_jmp
mov eax, [ebx+1] ;En eax se guardan los 4 bytes que indican la
;direccion de destino
add eax, ebx ;Se le suma la direccion actual
add eax, 5h ;Tambien los 5 bytes que ocupa la instruccion
mov [edi], eax ;Guardamos en la IAT el puntero directo a la api
jmp yata
yata:
add edi, 4h ;Apuntemos a la siguiente dword
sub ecx, 4h ;Ahora la IAT a rastrear ocupa 4 bytes menos
jnz otromas
int 3 ;Para que salte sice al terminar con I3Here on
aqui: jmp aqui- Un push directo con su querido ret:
push direccion_real_de_la_api
retEl opcode de push es 68h y el de un ret es 0C3h. Un ejemplo seria:
push aki ;(si offset aki valiese 12345678)
ret ;las instrucciones en hex serian 68 78 56 34 12 C3
aki:En este caso solo tendriamos que añadir otro "check" por si se encuentra un push de estos.
cmp byte ptr [ebx], 68h ;mira si es un push
jnz no_push
cmp byte ptr [ebx+05h],0C3h ;tambien mira si luego del push vendra un ret
jnz no_push
mov eax, [ebx+1] ;si es asi, mete en eax la direccion de destino
mov [edi], eax ;la guardamos en la IAT
jmp yata- Cualquiera de los casos anteriores pero con instrucciones delante:
Uhmm.. depues del trabajo que ha costado elavorar esta rutina, y si miramos la IAT despues de injertar el codigo vemos que no ha mejorado notablemente. Que puede estar sucediendo?
AsProtect no solo redirige la IAT a partes de codigo que nos "rebotan" hacia las apis, sino que algunas veces tambien ejecuta parte de esa api antes de rebotarnos, de tal manera que nos obliga a ir mas alla que mirar si la primera instruccion es un push o un jmp.
La solucion consistiria en tener un acumulador que nos cuente el numero de bytes antes de llegar a una de esas instrucciones y luego restarselo a la direccion de destino. (Tenemos como PreCondicion que el tamaño de los bytes que hay antes del rebote y el tamaño que hay entre el inicio de la api y la direccion donde aterrizamos sean iguales)
La nueva rutina (la definitiva) tendra este aspecto:
.386
.model flat, stdcall
option casemap: none
tamano equ 710h ;<------------ tamaño de la IAT
RVAiat equ 51F178h ;<------------ donde empieza la IAT (con imagebase)
rang_inf equ 1200000h ;<------------ el rango de los jmps y pushes...
rang_sup equ 1300000h ;<----¥
;(estos datos pertenecen al programa NewsPic)
.data
.code
start:
mov edi, RVAiat
mov ecx, tamano
otromas:
mov ebx, edi
mov ebx, [ebx]
; Esta dentro del rango?
cmp ebx, rang_inf
jb yata
cmp ebx, rang_sup
ja yata
; Antiemuling..
xor esi, esi ;Reseteamos contador
dec esi
emulao:
inc esi ;Como lo que hemos mirado no era ni un jmp ni un
;push incrementamos el contador
cmp esi, 50h ;Si ya hemos rastreado 50 bytes mejor pasemos a
;otra api :P
jz yata
; Es un push?
cmp byte ptr [ebx+esi], 68h
jnz no_push
cmp byte ptr [ebx+esi+05h],0C3h
jnz no_push
mov eax, [ebx+esi+1]
sub eax, esi
mov [edi], eax
jmp yata
no_push:
; Es un salto relativo?
cmp byte ptr [ebx+esi], 0e9h
jnz emulao
mov eax, [ebx+esi+1]
add eax, ebx
add eax, 5h
mov [edi], eax
jmp yata
no_salto:
yata:
add edi, 4h
sub ecx, 4h
jnz otromas
int 3
aqui: jmp aqui
end startNotese que segun la rutina puede ser conveniente utilizar delta offset.
Cuando tengamos el codigo escrito lo compilamos con Masm:
ml /c /coff reparaIAT.asm
Link /SUBSYSTEM:WINDOWS reparaIAT.objUna vez con la rutina compilada tenemos que arreglar el exe para injertar solo lo que es codigo, ignorando la cabecera asi como los bytes nulos que haya al final para alinear el codigo.
Para realizar esto entra en accion FileInspector, que nos presenta la opcion de volcar secciones. Volcando la seccion .text de reparaIAT.exe y eliminando los 00s sobrantes con un editor hexadecimal tendremos un archivo .bin listo para ser injertado.
Injertando la rutina en la victima
Abrimos el debugger y justamente caeremos en el proceso que dejamos antes colgado. Ahora con la opcion Load de IceDump cargamos el fichero bin en memoria.
Se puede meter la rutina en 400400h porque de esta manera no tenemos que calcular cada vez la direccion de una zona de memoria que podamos utilizar de hueco para nuestro codigo. Como 400400h es un trozo de la cabecera de todos los archivos que casi nunca suele tener datos importantes, se puede usar sin alterar nada.
/Load 400400 tamaño_del_archivo_en_hexadecimal c:\ruta_del_archivo_bin
Cuando tengamos los bytes en memoria solo queda redirigir EIP a nuestra rutina:
r eip 400400Y seguimos la ejecucion (con el i3Here activado) hasta que salte de nuevo el debugger. Si le hechamos un ojo a la IAT con
d edi ;edi contenia un puntero a las dwords que se iban evaluando de la IAT
podremos comprobar como esta correcta en el 97%.. uhm, aun mas problemas?
Reparacion manual del resto de las apis
Volvamos a dejar el proceso clavado con un bucle infinito para echarle un vistazo a la IAT con ImpRec y, sin cerrar ImpRec, repetimos lo de antes:
u *un_RVA_cualquiera_de_la_IAT_que_sea_malo (contando la imagebase)
Otra vez nos podemos encontrar con distintas situaciones que no cumplan el patron anterior (ni jmp ni push :P)
- Una rutina que llame a GetModuleHandleA o GetProcAddress (esto tambien lo arregla AutoTrace):
0167:0122C90C PUSH EBP
0167:0122C90D MOV EBP,ESP
0167:0122C90F MOV EAX,[EBP+08]
0167:0122C912 TEST EAX,EAX
0167:0122C914 JNZ 0122C91D
0167:0122C916 MOV EAX,[01233560]
0167:0122C91B JMP 0122C923
0167:0122C91D PUSH EAX
0167:0122C91E CALL KERNEL32!GetModuleHandleA
0167:0122C923 POP EBP
0167:0122C924 RET 0004o..
0167:0122C548 PUSH EBP
0167:0122C549 MOV EBP,ESP
0167:0122C54B MOV EDX,[EBP+0C]
0167:0122C54E MOV EAX,[EBP+08]
0167:0122C551 CMP EAX,[012320BC]
0167:0122C557 JNZ 0122C562
0167:0122C559 MOV EAX,[EDX*4+01232218]
0167:0122C560 JMP 0122C569
0167:0122C562 PUSH EDX
0167:0122C563 PUSH EAX
0167:0122C564 CALL KERNEL32!GetProcAddress
0167:0122C569 POP EBP
0167:0122C56A RET 0008Estas dos rutinas comparan eax con un valor, si este es igual eax toma un valor de una tabla y retorna. Si no es igual eax toma el valor que le den esas apis. Lo que hay que hacer es sencillo, modificar a mano el puntero de dentro de la IAT y hacer que apunte a su respectiva api.
Para proceder, tomamos ImpRec (que antes no habiamos cerrado) y hacemos doble click en la api no resuelta que acabamos de consultar. Seleccionamos modulo y funcion y seguimos con SoftIce mirando mas punteros no validos.
Que mas nos puede deparar el packer..
- Emulacion completa de FreeResource y LockResource
Veamos primero el aspecto de estas apis y de su "equivalente" en AsProtect
En el Kernel:
KERNEL32!FreeResource
015F:BFF92E24 XOR EAX,EAX
015F:BFF92E26 RET 0004
KERNEL32!LockResource
015F:BFF92E29 MOV EAX,[ESP+04]
015F:BFF92E2D RET 0004En el packer:
;FreeResource
0167:0122C974 PUSH EBP
0167:0122C975 MOV EBP,ESP
0167:0122C977 POP EBP
0167:0122C978 RET 0004
;LockResource
0167:0122C968 PUSH EBP
0167:0122C969 MOV EBP,ESP
0167:0122C96B MOV EAX,[EBP+08]
0167:0122C96E POP EBP
0167:0122C96F RET 0004La unica diferencia entre ellas esque FreeResource nos pondra eax a cero, eso sucede porque es una funcion nula, y como tal devolvera un valor 0 aunque no lo necesite luego.
Ahora ya podemos arreglar unas cuantas apis mas.
- Modifica eax con el contenido de una tabla:
Mov eax, dword ptr [direccion]Esto solo se encuentra es sustitucion a aquellas apis que se comporten como una funcion, ya que solo importa el valor que devuelven. Luego es logico que cuando AsProtect se cargue, debera llamar a estas apis para guardar en la tabla los resultados y asi poderlos utilizar luego.
Sabido esto colocamos unos cuantos breakpoints en este tipo de apis y ejecutamos otra vez el packedfile (sin cerrar ImpRec porque perderiamos el trabajo :P)
Al principio del tutorial ya mencione un ejemplo de estas ;)
Cuando SoftIce nos salte en una parte de codigo similar a esta:
call GetVersion
mov dword ptr [direccion], eax
call GetCurrentProcessId
mov dword ptr [otra_direccion], eax
call otra_api
mov dword ptr [otra_direccion], eax
...Solo nos queda relacionar estas direcciones de la tabla con lo que nos encontramos antes y, de esta manera, modificar la IAT con su api pertinente.
Aun con todo esto, y el programa sigue sin funcionar? >:/
Es posible que el codigo del programa haga referencia aun a la memoria del packer, pero como esta ahora ya no se inicializa, da un error poque no se puede acceder a ella. La solucion es simple: Faults on
Nos podria salir algo como esto:
lea esi, [memoria_de_nuestro_prog]
lea edi, [memoria_del_packer]
xor ecx, ecx
dec ecx
repz cmpsbrepz cmpsb compara un byte de [esi] con [edi]. Incrementa edi, incrementa esi, decrementa ecx y rep parara de repetir cuando ecx = 0 o cuando lo que haya en [esi] y lo que haya en [edi] sea diferente.
Si hacemos que apunten los dos a la misma zona de memoria y pongamos que tiene alguna relacion con mostrar o no un mensaje de "TRIAL VERSION", cabe la posiblidad de que ya no aparezca mas (zencracking), de hecho con Asniffer me sucedio eso. Que casualidad de que el programa fallaba en el about, claro, de donde miraria sino si hay que mostrar o no el mensajito? Luego a parte de funcionar mostraba el about bien bonito ^^
Finalizando
Cuando este toda la IAT apuntando a donde toca es hora de construir la IT, de esta manera windows rellenara la IAT en funcion de donde esten los modulos cargados (Notese que estos pueden variar de posicion dependiendo de la version de Windows y de sus dlls). Con la opcion FixDump creamos un nuevo ejecutable con esta tabla. Es lo mejor de ImpRec, el solito creara la tabla de importaciones adecuada a la nueva IAT.
Lo bueno de haber desempacado AsProtect es que, como este packer tiene las opciones de incluir de por si las limitaciones (30 dias, crc..) todo esto quedara deshabilitado y por lo tanto, el programa en cuestion crackeado. Unicamente faltaria eliminar algunas cadenas que digan que el programa es demo y todas esas cosas. Se puede realizar poniendo un byte nulo al principio de estas.
Me gustaria dar las gracias a ThePope, Marmota, GaDiX y Skuater por haberme ayudado precisamente con este tema y al resto del canal #crackers, es ahi donde empece a aprender ^^. Tambien a ZaIoTe y MrSilver por revisar el tutorial y aconsejarme sobre el.
P.D. y como diria un cracker loco que anda por ahi...
" si queremos AsProtect desempacar "
" actuaremos con cuidado "
" pues debemos desliar "
" lo que ya viene liado "
bY xgrimator
Saludos, eSn-mIn
*EOF*
