armadillo 4.62 + debug blocker + copy mem ii + import table elimination + code splicing + nanomites

CracksLatinoS! 2007

-* *-

Programa

STGThumb – Concurso N. 4 nivel 2Download Lista Crackslatinos

DescripciónHerramientas Ollydgb – Imp Rec – ArmaFP – ArmInline - DificultadCompresor/Compilador DELPHI Protección ArmadilloObjetivos desempacarCracker Solid Fecha: 21-04-2007Tutorial nº

-** Introducción **-

Este tutorial esa escrito pura y exclusivamente para alentar a todos aquellos que no se animan a los packers difíciles, en este caso ARMADILLO con todas sus protecciones activadas, para demostrar que si uno realmente se propone algo, puede lograrlo, con todas las buenas teorias que hay escritas por los integrantes de esta lista. yo les aseguro que es muchisimo mas facil de lo que ustedes se imaginan. Obviamente gran parte del desempacado, me ayudare con las tools que existen para dicho proposito, si estan disponibles y funcionan, es bueno aprovecharlas, aunque tambien seria ideal poder hacerlo 100% manual. Pero en por algo se empieza, y este puede ser un buen comienzo para los que no nos animabamos con este tipo de protecciones, solo por prejuicio o miedo.

Tambien quiero recalcar, que lo que van a leer aquí, absolutamente NADA fue idea mia, todo lo he aprendido de las teorias que lei y trate de tomar lo que a mi criterio era mas sencillo o mejor para hacer, asi que tomenlo como un RESUMEN del resto de las teorias sobre armadillo. Esto quiere decir que con este tutorial, posiblemente desempaquemos un

Armadillo 4.62 + Debug Blocker + CopyMem II + Import Table Elimination + Code Splicing + Nanomites – PARA PRINCIPIANTES – USANDO TOOLS – Por Solid.

gran porcentaje de armadillos, pero si se entusiasman y quieren mas información yo les recomiendo que no dejen de leer el resto de lo que hay escrito ya sobre este tema, porque realmente son muy buenas. Algunas que puedo mencionar son:

368-Armadillo 4.x Tutep1v2 por TlatoaniMT001616-Armadillo v4.40_StandardProtection + DebugBlocker_by_+NCR.rar 617-Armadillo v4.40_StandardProtection + DebugBlocker_by_+NCR.rar679-Armadillo v4.30 + Nanomites por Hiei.rar657-Armadillo v4.40 CopyMemII DebugBlocker Import Table Elimination NCR y marciano

Tambien si quieren profundizar sobre NANOMITES tienen las de Ricardo Narvaja:

71-Antidump de armadillo por nanomites (1ª)72-ANTIDUMP de ARMADILLO por NANOMITES (2ª)

Hechas todas estas aclaraciones, y resumiendo un poco, la principal finalidad de este tutorial, es de desempacar un armadillo con todas sus protecciones, aprovechando al maximo las tools que tenemos para ello. Aunque para mi lo mas importante es poder hacer todo el trabajo a mano, cosa que tambien me he propuesto, pero como dije antes, para empezar esta bien hacerlo con las tools.

Vamos antes que nada a analizar el archivo con una herramienta especial para detectar versiones de armadillo, es el ArmaFP. Abrimos este programita y cargamos el ejecutable protegido y nos da la información:

<------- 22-04-2007 00:58:20 -------> C:\Archivos de programa\stg\thumb\thumb.exe!- Protected ArmadilloProtection system (Professional)!- <Protection Options>Debug-BlockerCopyMem-IIEnable Import Table EliminationEnable Strategic Code SplicingEnable Nanomites Processing!- <Backup Key Options>Variable Backup Keys!- <Compression Options>Best/Slowest Compression


!- <Other Options>!- Version 4.62 27November2006

Bueno todo eso la verdad que asusta, pero vamos para adelante, que para eso somos CrAcKsLaTiNoS!!!Ante todo una aclaracion, debemos tener un plugin que elimine el bug de olly de OutputDebugStringA como por ej: ollyAdvanced

Empezamos por la primera

COPYMEM II

Aquí una breve explicación de cómo funciona la proteccion, en si no es tan complicado para entender. Transcribo el texto de la teoria 368

Ejecutamos el primer proceso Thumb.exe [padre] El primer proceso [padre] crea un segundo proceso [hijo]

copiándose a si mismo en memoria El proceso padre funge como debugger para con el hijo El padre modifica el EP [no el OEP] del hijo para crear un bucle

infinito El padre hace comprobaciones y otras basuras para preparar la

ejecución del hijo El padre modifica el EP del hijo para quitar el bucle infinito El hijo ejecuta el mismo código del armadillo que el padre pero

ahora como hijo El hijo llega al OEP y causa un error al estar

encriptado/ausente El padre capta el error con la API WaitForDebugEvent El padre ve el registro EIP, comprueba el error y se prepara

para desencriptar de la zona del OEP El padre desencripta la zona necesaria con la API

WriteProcessMemory [1000h bytes] Si el padre ve que hay una zona que no este en uso la

encripta/destruye El padre le regresa el control al hijo en el OEP ya

desencriptado y se pone en modo de espera El hijo se sigue ejecutando hasta llegar al próximo error y

vuelve a comenzar el bucle

Los dos pasos que marque son las zonas calientes de este esquema, así que vamos a por el.

Sigo. Sabiendo esto, lo que debemos hacer para librarnos de la proteccion seria lo siguiente:

1) Localizar el CALL ENCRIPTADOR para Nopearlo y de esa forma evitar la encriptacion

2) Averiguar el OEP del HIJO y colocarle un LOOP INFINITO3) Realizar un injerto para que los bloques de 1000h bytes se

copien desencriptados y de esa forma tener un HIJO totalmente desencriptado y loopeando en su OEP

4) Desatachear al HIJO

Con eso nos libraremos del COPYMEM II, y sera lo unico que haremos de forma manual, sin herramientas, por lo tanto es lo mas entretenido de todo, y veran que después de intentarlo 2 o 3 veces


no tardaran mas de 5 minutos en realizarlo la proxima vez y sin necesidad de leer este tutorial.

Empecemos entonces:

LOCALIZANDO EL CALL ENCRIPTADOR

Cargamos el ejecutable en olly, y colocamos un bp en WriteProcessMemory, damos run.La primera vez que se detiene, escribira 2 bytes, veamos la pila:

0012D9D8 006E6312 /CALL to WriteProcessMemory from thumb.006E630C0012D9DC 00000048 |hProcess = 00000048 (window)0012D9E0 006F1B43 |Address = 6F1B430012D9E4 0012DCC8 |Buffer = 0012DCC80012D9E8 00000002 |BytesToWrite = 20012D9EC 0012DCCC \pBytesWritten = 0012DCCC

En el buffer tenemos la direccion de donde se tomaran los bytes a escribir en la direccion 6F1B43, lo que hace esta primera vez que para, es colocar un LOOP INFINITO (EB FE) en el EP del HIJO.

nuevamente RUN y vuelve a parar:

0012D9D8 006E633A /CALL to WriteProcessMemory from thumb.006E63340012D9DC 00000048 |hProcess = 00000048 (window)0012D9E0 006F1B43 |Address = 6F1B430012D9E4 0071C384 |Buffer = thumb.0071C3840012D9E8 00000002 |BytesToWrite = 20012D9EC 0012DCCC \pBytesWritten = 0012DCCC

Al igual que la vez anterior, escribira 2 bytes, desde la direccion apuntada por el Buffer a la direccion apuntada por Ardess, si observamos esta segunda vez, lo que hace es QUITAR el loop infinito que habia puesto en la parada anterior:

Nuevamente hacemos correr con F9 y estamos en la tercera parada:

0012DB78 006E5DE4 /CALL to WriteProcessMemory from thumb.006E5DDE0012DB7C 00000048 |hProcess = 00000048 (window)0012DB80 0066B000 |Address = 66B0000012DB84 00EC0048 |Buffer = 00EC00480012DB88 00001000 |BytesToWrite = 1000 (4096.)0012DB8C 0012DC94 \pBytesWritten = 0012DC94

Ahí escribira el primer bloque de 1000h bytes, a partir de la direccion 66B000 quiere decir que cuando lleguemos al ret de la api,


ya habra pasado por ambos CALLS, encriptador y desencriptador, para obtener cuales son, damos CTRL+F9 y luego F8 para pasar el RET de la API, y estaremos aquí:

006E5DE4 . 85C0 TEST EAX,EAX006E5DE6 . 75 4B JNZ SHORT thumb.006E5E33006E5DE8 . 50 PUSH EAX006E5DE9 . F7D0 NOT EAX

nuevamente CTRL+F9 para llegar al ret:

006E5EE0 . C3 RETN006E5EE1 $ 55 PUSH EBP

ahora damos al boton K (call Stack):

Este el call DESENCRIPTADOR, hacemos doble clic y nos manda a la parte del codigo:

006E4A4D . E8 48030000 CALL thumb.006E4D9A006E4A52 > 83C4 0C ADD ESP,0C006E4A55 . 25 FF000000 AND EAX,0FF

parados sobre el CALL DESENCRIPTADOR, damos ENTER y caemos aquí:

006E4D9A $ 55 PUSH EBP006E4D9B . 8BEC MOV EBP,ESP006E4D9D . 81EC 00010000 SUB ESP,100006E4DA3 . 53 PUSH EBX si miramos la aclaracion de olly:

Ahí tenemos ambos, en rojo el Desencriptador y en celeste el Encriptador, marcado con una flecha, ya obtuvimos el primer dato importante, tomamos nota entonces del call de la direccion 06E4D22, podemos pasar ya al paso siguiente.

AVERIGUANDO EL OEP DEL HIJO

Acabamos de encontrar el call encriptador, no necesitamos reiniciar ahora para hallar el OEP del HIJO, solamente a partir de donde estabamos, (al inicio del la api WriteProcessMemory) colocamos un BP en la api: WaitForDebugEvent, damos RUN y se detiene aquí:

0012DCD8 006E218F /CALL to WaitForDebugEvent from thumb.006E2189


0012DCDC 0012ED70 |pDebugEvent = 0012ED700012DCE0 000003E8 \Timeout = 1000. ms

veamos ese puntero en el dump:

0012ED70 01 00 00 00 B4 13 00 00 ...´..0012ED78 98 14 00 00 01 00 00 80 ˜µ.. ..€0012ED80 00 00 00 00 00 00 00 00 ........0012ED88 2C B9 66 00 02 00 00 00 ,¹f....0012ED90 00 00 00 00 2C B9 66 00 ....,¹f.0012ED98 2C B9 66 00 D8 26 11 00 ,¹f.Ø&.0012EDA0 00 00 00 00 06 EA 56 80 ....êV€0012EDA8 00 00 00 00 00 00 00 00 ........

Teoria 368:

en amarillo vemos las zonas de memoria donde se escribe el tipo de error que fue producido por el hijo

Las marcas verdes nos indican donde se escribe el valor del EIP [del hijo] que crea el error, este valor es 0066b92C este es nuestro OEP, anotémoslo para futuros usos, si recuerdan la zona que va a escribirse es 0066B000, así pues de esto se concluye que como el OEP esta en 0066B92C se tiene que desencriptar la zona del código que va desde 0066B000 hasta 0066C000 [1000h bytes] para que el OEP pueda ejecutarse

Continuemos. Ya tenemos datos muy importantes, conocemos el call encriptador, conocemos el OEP del hijo, ahora lo que vamos a hacer es preparar al hijo para poder desatachearlo, para eso debemos primero colocar un loop infinito en su OEP, y luego por medio de un injerto, forzar al padre a que lo escriba desencriptado.

Reiniciemos entonces el exe en olly, colocamos un BP en WriteProcessMemory damos RUN hasta que pare la tercera vez, o sea cuando escriba el primer bloque de 1000h bytes:

0012DB78 006E5DE4 /CALL to WriteProcessMemory from thumb.006E5DDE0012DB7C 00000048 |hProcess = 00000048 (window)0012DB80 0066B000 |Address = 66B0000012DB84 00EC0048 |Buffer = 00EC00480012DB88 00001000 |BytesToWrite = 1000 (4096.)0012DB8C 0012DC94 \pBytesWritten = 0012DC94

antes de continuar, quitamos el BP y vamos donde se encuentra el CALL ENCRIPTADOR y lo Nopeamos:

006E4D22 90 NOP006E4D23 90 NOP006E4D24 90 NOP006E4D25 90 NOP006E4D26 90 NOP006E4D27 . 83C4 0C ADD ESP,0C006E4D2A . 50 PUSH EAX006E4D2B . F7D0 NOT EAX006E4D2D . 0FC8 BSWAP EAX

El proximo paso sera colocar el loop infinito en el OEP del HIJO, el cual obtenemos con una simple cuenta:OEP - Zona Base = Desplazamiento66B92C - 66B000 = 92C

Zona Base + Desplazamiento = Zona de los bytes del OEP


0EC0048 + 92C = 0EC0974

vamos a esa zona en el DUMP, y vemos que hay:

00EC0974 55 8B EC 83 C4 F4 53 B8 U‹ìƒÄôS¸00EC097C D4 AE 66 00 E8 D3 B7 D9 Ô®f.èÓ·Ù00EC0984 FF 8B 1D 54 1B 68 00 8B ÿ‹Th.‹

Estos son los bytes correspondientes al OEP del hijo, desencriptados, asi que cambiamos el 55 8B por EB FE

00EC0974 EB FE EC 83 C4 F4 53 B8 ëþìƒÄôS¸00EC097C D4 AE 66 00 E8 D3 B7 D9 Ô®f.èÓ·Ù00EC0984 FF 8B 1D 54 1B 68 00 8B ÿ‹Th.‹00EC098C 03 E8 4A AA DE FF 8B 03 èJªÞÿ‹

ahora colocamos un BP en WaitForDebugEvent y damos RUN, para aquí:

0012DCD8 006E218F /CALL to WaitForDebugEvent from thumb.006E21890012DCDC 0012ED70 |pDebugEvent = 0012ED700012DCE0 000003E8 \Timeout = 1000. ms

Vayamos en el dump a la direccion 0012ED70 a ver el reporte del error:

0012ED70 01 00 00 00 F8 03 00 00 ...ø..0012ED78 A8 0A 00 00 01 00 00 80 ¨... ..€0012ED80 00 00 00 00 00 00 00 00 ........0012ED88 2C B9 66 00 02 00 00 00 ,¹f....0012ED90 00 00 00 00 2C B9 66 00 ....,¹f.0012ED98 2C B9 66 00 D0 C2 EE 00 ,¹f.ÐÂî.

vemos el EIP de donde se produjo el error (MARCADO EN VERDE) corresponde al OEP DEL HIJO, y la zona marcada en AMARILLO, es el reporte del tipo de error que se produjo, estos datos (los primeros 6 dwords marcados en amarillo) son los que nos interesan, asi que los copiamos porque los necesitaremos para hacer el proximo paso que es el de realizar el injerto.

Estamos parados al comienzo de la api WaitForDebugEvent. hasta el momento, hemos nopeado el call encriptador, y puesto el loop infinito en el OEP del Hijo, hemos copiado el reporte del error que toma por medio de WaitForDebugEvent. Lleguemos hasta el RET de la api con CTRL+F9, pasamos el RET con F8 y ahora lo que haremos sera cambiar el parámetro TIMEOUT que esta en 1000 ms por 1 esto es solamente para acelerar un poco las cosas, asi que ahora estamos aquí:

006E217B > \3361 68 XOR ESP,DWORD PTR DS:[ECX+68] ; |006E217E E8 0300008B CALL 8B6E2186006E2183 ? 95 XCHG EAX,EBP006E2184 ? D0F5 SAL CH,1006E2186 ? FFFF ??? ; Unknown command006E2188 . 52 PUSH EDX ; |pDebugEvent


006E2189 . FF15 E4507100 CALL DWORD PTR DS:[<&KERNEL32.WaitForDeb>; \WaitForDebugEvent006E218F 85C0 TEST EAX,EAX //AQUI ESTAMOS LUEGO DE PASAR EL RET

vemos que el codigo esta ofuscado, lo que debemos hacer es cambiar el parámetro de la api 0X3E8 (1000d) por 1, quedaria de esta forma:

006E217B > \3361 68 XOR ESP,DWORD PTR DS:[ECX+68] ; |006E217E 0100 ADD DWORD PTR DS:[EAX],EAX006E2180 ? 0000 ADD BYTE PTR DS:[EAX],AL006E2182 . 8B95 D0F5FFFF MOV EDX,DWORD PTR SS:[EBP-A30] ; |006E2188 . 52 PUSH EDX ; |pDebugEvent006E2189 . FF15 E4507100 CALL DWORD PTR DS:[<&KERNEL32.WaitForDeb>; \WaitForDebugEvent

Esto podemos hacerlo directamente desde el dump para verlo con mas claridad, marcamos la direccion del codigo 006E217B, follow in dump, selection y cambiamos directamente los bytes ahí:

006E217E 01 00 00 00 8B 95 D0 F5 ...‹•Ðõ006E2186 FF FF 52 FF 15 E4 50 71 ÿÿRÿ§äPq

HACIENDO EL INJERTO

A este punto estamos detenidos justo a la salida de la api WaitForDebugEvent , hemos cambiado el parámetro Timeout, ahora justo desde donde estamos parados:

006E218F 85C0 TEST EAX,EAX

ensamblamos un JMP a la zona donde haremos el injerto, en este caso, yo elegí 401000, asi que lo hago saltar ahí:

006E218F - E9 6CEED1FF JMP thumb.00401000 ; 006E2194 90 NOP006E2195 90 NOP006E2196 90 NOP y ensamblo el injerto:

00401000 90 NOP00401001 C705 70ED1200>MOV DWORD PTR DS:[12ED70],10040100B C705 74ED1200>MOV DWORD PTR DS:[12ED74],3F800401015 C705 78ED1200>MOV DWORD PTR DS:[12ED78],0AA80040101F C705 7CED1200>MOV DWORD PTR DS:[12ED7C],8000000100401029 C705 80ED1200>MOV DWORD PTR DS:[12ED80],000401033 C705 84ED1200>MOV DWORD PTR DS:[12ED84],00040103D 8105 88ED1200>ADD DWORD PTR DS:[12ED88],100000401047 8105 94ED1200>ADD DWORD PTR DS:[12ED94],100000401051 8105 98ED1200>ADD DWORD PTR DS:[12ED98],10000040105B 813D 98ED1200>CMP DWORD PTR DS:[12ED98],thumb.0066B00000401065 ^ 74 D6 JE SHORT thumb.0040103D


00401067 813D 98ED1200>CMP DWORD PTR DS:[12ED98],thumb.0066C00000401071 - 0F8C 1D112E00 JL thumb.006E219400401077 90 NOP

De la teoria 368:

Las líneas en amarillo son las que restauran el reporte a como estaba cuando se produjo el error que causo la desencripción de la zona del EIP del hijo, las líneas en verde son las que aumentan en 1000h bytes las zonas de memoria donde se guarda la dirección de memoria del hijo a ser desencriptada, las línea que están en turquesa son una comprobación para que cuando se llegue a la zona 0066B000 le añada otros 1000h bytes ya que como esa zona ya fue desencriptada si se intenta desencriptar creara un error, las dos líneas en fucsia son la comprobación que reiniciara el bucle justo después del salto que pusimos a esta zona, le regresara el control al código del Armadillo solo si la dirección a desencriptar del hijo es menor a 0066C000 ya que ese es el final de la sección de código del hijo, esto lo podemos ver en el Memory Map

Memory map, item 23 Address=00401000 Size=0026B000 (2535424.) Owner=thumb 00400000 Section=CODE Contains=code

Así pues, si comienza en 00401000 y tiene un tamaño de 0026B000 su valor máximo será 00401000 + 0026B000 = 0066C000

Ya estamos listos para poner a correr el programa, asi que colocamos un HE al final del injerto, en 401077, pero antes de dar RUN, cambiemos el valor del reporte del EIP, en este momento este con el EIP del OEP:

0012ED70 02 00 00 00 F8 03 00 00 ...ø..0012ED78 9C 1C 00 00 60 00 00 00 œ..`...0012ED80 00 D0 FD 7F 59 06 81 7C .Ðý�Y|0012ED88 2C B9 66 00 02 00 00 00 ,¹f....0012ED90 00 00 00 00 2C B9 66 00 ....,¹f.0012ED98 2C B9 66 00 D0 C2 EE 00 ,¹f.ÐÂî.

Lo cambiamos por 400000 para que empiece a desencriptar a partir de 401000, o sea la seccion code, quedando de esta forma:

0012ED70 02 00 00 00 F8 03 00 00 ...ø..0012ED78 9C 1C 00 00 60 00 00 00 œ..`...0012ED80 00 D0 FD 7F 59 06 81 7C .Ðý�Y|0012ED88 00 00 40 00 02 00 00 00 [email protected] 00 00 00 00 00 00 40 00 [email protected] 00 00 40 00 D0 C2 EE 00 ..@.ÐÂî.

Ahora si, damos RUN, y a los pocos segundos parara en nuestro HE al final del injerto,

00401065 ^\74 D6 JE SHORT thumb.0040103D00401067 813D 98ED1200>CMP DWORD PTR DS:[12ED98],thumb.0066C00000401071 - 0F8C 1D112E00 JL thumb.006E219400401077 90 NOP


mailto:..@.%C3%90%C3%82%C3%AE

Ya estamos listos para desatachar al hijo del padre, y como ven solo hemos utilizado 2 bp, uno en WriteProcessMemory y otro en WaitForDebugEvent

Abrimos el PUPE y vemos los 2 procesos:

el HIJO, SIEMPRE es el de arriba, en este caso su PID es 3F8

conociendo esto, escribimos 2 lineas para desatachearlo:

00401071 - 0F8C 1D112E00 JL thumb.006E2194 ; FIN INJERTO00401077 68 F8030000 PUSH 3F80040107C E8 2895457C CALL kernel32.DebugActiveProcessStop

las traceamos con F8, al pasar por la api, vemos eax que devuelve 1 lo que significa que la operación se realizo con éxito:

Sin cerrar este olly, abrimos otra instancia de Olly, y attacheamos el proceso hijo:


Una vez attacheado, damos RUN y luego PAUSA, Y caemos aquí:

Vemos que estamos en el OEP del HIJO 066B92C, con el loop infinito. Restauramos los bytes originales:

0066B92C 55 PUSH EBP ; 0066B92D 8BEC MOV EBP,ESP0066B92F 83C4 F4 ADD ESP,-0C

podemos ver que se ha desencriptado correctamente, observemos que se ven strings:

el proximo paso, sera encontrar la IAT y ver como esta, para eso marcamos el primer CALL y nos metemos con ENTER, caemos aquí:

00407110 50 PUSH EAX00407111 6A 00 PUSH 000407113 E8 F8FEFFFF CALL thumb.0040701000407118 BA 10C16600 MOV EDX,thumb.0066C1100040711D 52 PUSH EDX0040711E 8905 DC246800 MOV DWORD PTR DS:[6824DC],EAX00407124 - E9 6BBE2803 JMP 03692F94

la linea que marque en amarillo, es la zona de los SPLICES o CODE SPLICING. Esto no son mas que saltos a una zona fuera del exe que no


estaran en el dumpeado, pero ya lo repararemos, en principio, tomemos nota de la direccion en la cual estan los SPLICES, esta zona es diferente en cada ejecución, por lo que hay que repararla en esta mimsa instancia del programa., veamos el memory map:

comienza en 3690000 y tiene un largo de 20000.

Continuamos buscando la IAT, estamos dentro del primer call, y dentro de este primer call hay otro call, tambien lo marcamos y apretamos ENTER:

Ahí tenemos parte de la IAT son saltos indirectos que van a una zona 10BXXXX fuera del exe, y es lo que se denomina IAT SCRAMBLE, ademas hay algunas que no tienen en nombre de la api, asi que tendran entradas malas, vamos al dump a buscar el inicio y final de la tabla:

Como nos recomienda HIEI, cambiamos la vista en el dump por LONG, ADDRESS:

Prestemos atención a la primer API, en este caso: FileTimeToSystemTime, ya que esto nos servira para cuando tengamos que buscar esta lista nuevamente en otro hijo, ahora bajamos hasta encontrar el final de la IAT:


ahi termina, entonces tenemos:

INICIO: 10B6550FINAL: 10B7070LARGO: B20

Aquí dejamos por ahora esta instancia PADRE-HIJO, ya que para reparar la IAT, debemos hacerlo desde un HIJO parado en el EP (hay un script que lo hace pero a mi no me funciono, asi que lo tendre que hacer a mano) una vez hecho esto tenemos que correr un script reparador que es elArmadillo V4.0-V4.4.Standard.Protection.osc que va adjunto a este tutorial.

Lo que haremos ahora sera abrir otro olly y cargamos el programa original empacado, colocamos un bp en WriteProcessMemory y damos RUN, si recuerdan lo que habia dicho antes, la primera vez que para, pone un loop infinito en el EP del HIJO :

0012D9D8 006E6312 /CALL to WriteProcessMemory from thumb.006E630C0012D9DC 00000048 |hProcess = 00000048 (window)0012D9E0 006F1B43 |Address = 6F1B430012D9E4 0012DCC8 |Buffer = 0012DCC80012D9E8 00000002 |BytesToWrite = 20012D9EC 0012DCCC \pBytesWritten = 0012DCCC

vamos en el dump a la direccion apuntada por el BUFFER:

0012DCC8 EB FE 00 00 02 00 00 00 ëþ.....

volvemos a dar RUN:

0012D9D8 006E633A /CALL to WriteProcessMemory from thumb.006E63340012D9DC 00000048 |hProcess = 00000048 (window)0012D9E0 006F1B43 |Address = 6F1B430012D9E4 0071C384 |Buffer = thumb.0071C3840012D9E8 00000002 |BytesToWrite = 20012D9EC 0012DCCC \pBytesWritten = 0012DCCC

En esta parada quitaba el loop infinito y restauraba los bytes originalesHacemos lo mismo que antes, y vemos:

0071C384 55 8B 00 00 00 00 00 00 U‹......


asi que cambiamos esos bytes por EB FE:

0071C384 EB FE 00 00 00 00 00 00 ëþ......

ahora quitamos el BP, damos RUN, vamos a la seccion donde comienza el codigo del Armadillo:

y le colocamos un BP con F2, y puede parar en 2 lugares posibles:

uno es este (que no nos sirve)

006DFD75 . 3D 02010000 CMP EAX,102006DFD7A . 75 02 JNZ SHORT thumb.006DFD7E006DFD7C .^ EB D3 JMP SHORT thumb.006DFD51006DFD7E > 68 FA000000 PUSH 0FA ; /Timeout = 250. ms006DFD83 . FF15 A4517100 CALL DWORD PTR DS:[<&KERNEL32.Sleep>] ; \Sleep

asi que damos RUN nuevamente y volvemos a poner el BP en la misma seccion, el otro lugar posible es este:

006E218F 85C0 TEST EAX,EAX006E2191 0F84 BB230000 JE thumb.006E4552006E2197 8B85 F0FDFFFF MOV EAX,DWORD PTR SS:[EBP-210]006E219D . 25 FF000000 AND EAX,0FF

aquí es donde debemos ensamblar las lineas para desatachear, igual que la vez anterior, abrimos el PUPE y veamos cual es el hijo:

ahí vemos los 2 pares del empacado, los de abajo son los de la primer instancia, y los de arriba los de esta ultima, siendo el de arriba del todo, como siempre, el HIJO, asi que con este dato ya podemos ensamblar:

006E218F 68 DC160000 PUSH 16DC006E2194 E8 1084177C CALL kernel32.DebugActiveProcessStop006E2199 90 NOP

traceamos esas 2 lineas con F8 y vemos que EAX nos devuelve 1, lo que indica que todo ha ido de perlas

Abrimos otra instancia de OLLY (teniamos 3 hasta el momento), y attacheamos el nuevo hijo como lo hicimos antes, en este caso el proceso cuyo PID es 16DC, una vez attacheado, damos RUN y luego PAUSA, y caemos aquí:


006F1B43 > - EB FE JMP SHORT thumb.<ModuleEntryPoint>006F1B45 EC IN AL,DX ; I/O command006F1B46 |. 6A FF PUSH -1006F1B48 |. 68 00B07100 PUSH thumb.0071B000006F1B4D |. 68 80186F00 PUSH thumb.006F1880 ; SE handler installation006F1B52 |. 64:A1 0000000>MOV EAX,DWORD PTR FS:[0]006F1B58 |. 50 PUSH EAX006F1B59 |. 64:8925 00000>MOV DWORD PTR FS:[0],ESP006F1B60 |. 83EC 58 SUB ESP,58006F1B63 |. 53 PUSH EBX006F1B64 |. 56 PUSH ESI006F1B65 |. 57 PUSH EDI006F1B66 |. 8965 E8 MOV DWORD PTR SS:[EBP-18],ESP006F1B69 |. FF15 8C517100 CALL DWORD PTR DS:[<&KERNEL32.GetVersion>; kernel32.GetVersion

Vemos que ha parado bien en el EP con el loop infinito, restauramos los bytes originales antes de continuar:

006F1B43 > 55 PUSH EBP006F1B44 8BEC MOV EBP,ESP006F1B46 |. 6A FF PUSH -1006F1B48 |. 68 00B07100 PUSH thumb.0071B000

ahora vamos a PLUGINS, olly script y corremos el script Armadillo V4.0-V4.4.Standard.Protection.osc que se adjunta en este tutorial, y nos aseguramos de tener todas las excepciones tildadas y ningun bp ni HE colocados, y corremos el script, cabo de unos segundos, el script terminara su brabajo, dejandonos parados en el OEP del hijo con la IAT REPARADA.

vemos que se detuvo en el OEP del hijo, aunque el codigo se ve mal ya que esta encriptado,pero eso no nos importa. ahora busquemos la IAT, Vamos al mapa de memoria y hacemos un binary search de la direccion de


la primer api que teniamos en nuestra IAT, si no recuerdan era: FileTimeToSystemTimeLa direccion en mi maquina es: 7C80E7EC :

la primera vez para aquí:

cambio la vista a LONGADDRESS:

Y veo que no es la primera de la lista, y si me fijo bien, esta iat es mas corta que la del primer hijo asi que doy CTRL+L para que encuentre la siguiente, y para aquí:


aquí si esta en primer lugar igual que en el otro hijo, si comparamos un poco esta imagen con la del primer hijo:

Vemos como reparo las entradas malas, y ademas estan en el mismo orden, asi que esta es nuestra IAT reparada, la marcamos y le hacemos un BINARY COPY y la pegamos en el PRIMER HIJO que tenemos parado en el OEP desencriptado.


ahí esta pegadita ya, los valores en rojo son los que se han modificado. Asi que de momento podemos cerrar esta segunda instancia de ollys, y nos quedamos con los 2 primeros de cuando empezamos el tute.

En este punto ya tenemos el HIJO desencriptado, con la IAT reparada pegada, lo que haremos ahora sera remover los SPLICES o Code Splicing y reubicaremos la IAT a una zona vacia del ejecutable, porque recuerden que si bien ya tiene todas las entradas buenas, aun esta en la zona 10BXXXXX que esta fuera del ejecutable. Para estas 2 tareas nos ayudaremos con ArmInline, abrimos el programita, y al cabo de unos segundos, vemos los procesos en ejecución, marcamos el correspondiente a nuestro HIJO, y rellenamos los campos con los datos correctos:

1 – Es la direccion de memoria donde comienza la seccion donde estan los splices la cual ya habiamos anotado cuando buscabamos la IAT

2 – Es el largo de la seccion de los splices 3 – Es la direccion donde comienza la IAT en el hijo desencriptado4 – Es el largo de la IAT5 – Es la seccion dentro del ejecutable donde vamos a colocar la IAT para que precisamente quede dentro del exe. Si buscamos en el memory map entre las secciones del ejecutable, vemos que esa esta vacia:


vemos que esta vacia, es la seccion .adata que comienza en 705000 y tiene 1000h bytes.

Completados los datos damos al boton REMOVE SPLICES y al cabo de unos minutos, nos da este mensaje:

podemos chequear a ver que ha hecho, recuerdan donde estaba el primero que vimos? ENTER sobre el primer call después del OEP y debajo del primer jmp a la iat ahí estaba, veamos como quedo:

ha cambiado el salto que iba a dar error por otras instrucciones.

Ahora debemos colocar la IAT en el ejecutable, para eso damos al boton REBASE IAT, y al cabo de unos segundos, nos da el mensaje:

vamos a ver como estan ahora:


vemos que las ha colocado donde le dijimos, ya no apuntan a la zona 10BXXXX

Ahora es el momento de dumpear, pero antes de hacerlo, vamos a abrir un empacado original y hacemos un binary copy del HEADER y lo pegaremos en el hijo que vamos a dumpear, ya que sino tendremos problemas. dumpeamos ahora con OLLYDUMP:

destildando la casilla Rebuild Import, y guardamos el archivo como tute.exeabrimos ImportReconstructor, seleccionamos el proceso HIJO, colocamos los datos:


Tengo una sola entrada mala, doy al boton Show Invalid, clic derecho sobre la entrada mala, CUT THUNKS, y luego fix dump. Y ya tenemos el archivo dumpeado y con la iat agregada. Pero sin cerrar nada, vamos a probar si funciona. Lo ejecutamos y:

Este error es un error de NANOMITES, acepto ese mensaje y el programa arranca, pero tiene algunos errores:


bueno, como no he cerrado nada, ni los 2 ollys ni el arminline, repararemos los nanomites tambien con esta tool, para ello abrimos el dumpeado en olly, y en ArmInline damos actualizar o F5 para que se actualice la lista de procesos, seleccionamos el tute_.exe, damos al boton LOCATE, seleccionamos el exe original empacado, al cabo de un rato nos da un mensaje y se nos habilita el boton REPAIR DUMP:

Damos a RepairDump y seleccionamos el dumpeado tute_.exe

ahora nos ha creado un nuevo archivo llamado:

lo probamos y vemos que ahora arranca sin errores.

Bueno esto fue todo, se ha hecho un poco mas largo de lo que imaginaba, pero como ven no es algo taaaaaaaaaaan difícil teniendo la ayuda de las herramientas. Pido perdon a todos mis amigos del yahoo y msn si en estos dias no hable mucho con ellos, y justamente era porque estaba con este tema.Quiero agradecer a todos los que han escrito los maravillosos tutes sobre armadillo y todas las teorias en general. Y agradecer el apoyo


que me brindaron NCR, RICARDO y MARCIANO, tambien a KARMANY por confiar en mi, ya que cuando le comente que queria hacer este nivel del concurso me dijo: “Estoy seguro que lo sacaras sin problemas”, y bueno KARMANY no podia defraudarte!!! Mi proximo objetivo es profundizar en el tema de los NANOMITES, asi que ire por ellos tambien, ya que solo tengo una vaga idea de cómo funcionan, y se que Ricardo tiene unos tutes excelentes al respecto.

Espero que les haya gustado y me gustaria mucho que se animen con ARMADILLO, que no es tanto como parece.

[email protected]


mailto:[email protected]

armadillo 4.62 + debug blocker + copy mem ii + import table elimination + code splicing + nanomites

Education

armadillo v4

antidump de armadillo

versiones de armadillo

caso armadillo

tutorial n

buenas teorias

ii enable import

copymemii debugblocker