INTRODUCCION AL CRACKING CON OLLYDBG PARTE 31 NOCIONES INICIALES SOBRE DESEMPACANDO Ustedes diran este se volvio loco, anuncio una tercera parte de PCODE y ahora comienza con desempacado, lo que pasa es que estoy viendo que en nuestra lista y en muchos crackers que me consultan, estan ansiosos por mejorar su perfomance en el unpacking, y PCODE hay muchos tutes incluso con WKT, ademas que no hay tantos programas hechos con PCODE, que creo que mas vale empezar con el tema de desempacado, ya que packers hay miles, por supuesto no veremos todos aquí pero daremos ideas generales y ejemplos que nos ayudaran a pensar packers que no hemos visto, por nosotros mismos, sin desesperarnos en buscar un tute por alli, (bueno a veces una ayuda puede servir jeje) En esta primera parte veremos algunos conceptos e ideas basicas que nos serviran para trabajar en unpacking, luego en futuras partes, pondremos manos a la obra, desempacando ejemplos. Bueno cual es la idea de empacar un programa, antes que nada Pues ya vimos que un programa desempacado es sencillo de modificar pues los bytes estan accesibles desde el inicio del mismo y no cambian (estan en el ejecutable), el listado es constante, y en cualquier momento podemos modificar cualquier byte sin problemas y guardar los cambios. Si un programa se automodifica y va cambiando a medida que corre, es mas dificil de parchear pues , lo que debes parchear no esta al inicio, y va cambiando a medida que corre el mismo, De esta manera, un programa empacado, al no tener el codigo original visible en un inicio, el codigo importante del programa original, no puede ser modificado facilmente, ya que no lo hallaremos, al estar encriptado inicialmente. Pues el tema es que cuando empacas una aplicación con un determinado packer, este encripta y guarda el codigo original del programa, bien escondido, y le agrega generalmente una o mas secciones,y en ellas le agrega una especie de cargador y redirige el Entry Point hacia este cargador-desempacador. Como resultado de esto el codigo del programa original no estara visible en el inicio, si arrancamos el programa en OLLYDBG y se detiene, lo hara en el ENTRY POINT del desempacador, desde donde comenzara a ejecutarse. Este desempacador, buscara la informacion guardada del codigo original encriptado, lo desencriptara y guardara en la ubicación original, una vez que el proceso de desencriptado ha concluido, saltara el OEP o Original Entry Point que es el punto de entrada que tenia el programa antes de ser empacado, o sea seria la primera linea del codigo original ejecutada. Buscaremos el empacador mas sencillo que existe, que es el UPX, bajaremos la version con GUI que es mas sencilla de usar se llama GUIPEX y se baja de: http://www.blueorbsoft.com/guipex/

Bueno lo instalamos en nuestra maquina y lo corremos.

Bueno alli tenemos al empacador mas sencillo, pero que a algunos les ha hecho pasar un mal rato jeje, usaremos como victima el famoso CRACKME DE CRUEHEAD antes que nada abramoslo en OLLYDBG sin empacarlo aun.

Alli lo tenemos abierto en OLLYDBG, el Entry Point es 401000 o sea que si lo corremos, esta seria la primera linea de codigo que se ejecutaría. O sea que si lo empacamos el GUIPEX le agregara y cambiara las secciones, y encriptara el codigo original, y lo guardara en algun lugar, luego cambiara el EntryPoint para que apunte al cargador-desempacador y listo. Entonces cuando corramos el programa empacado, el desempacador sacara del baul, el codigo original encriptado, lo desencriptara y ubicara en la primera seccion y luego de terminar su trabajo saltara a la primera linea de codigo original que se va a ejecutar, que es el famoso OEP, o ENTRY POINT ORIGINAL, que en nuestro caso ya sabemos que estara en 401000, ya que el programa original empieza alli y esa sera la primera linea que ejecute del mismo. Logicamente cuando nosotros atacamos un programa empacado, no tenemos el original para comparar y saber cual es el OEP o primera linea del codigo original ejecutado, por lo cual debemos aprender diversas tecnicas para hallarlo, antes que nada practiquemos con el CC (Crackme de Cruehead, jeje para abreviar) Guardemos una copia del CC en un lugar seguro por ejemplo el escritorio ya que el UPX modificara el que tenemos y necesitamos el original tambien, para comparar. Abro el GUIPEX

Pues eso, arrastro y suelto el crackme alli

Alli vemos que lo tomo ya que figura el path al crackme, y en COMMANDS elijo COMPRESS

para que comprima , pues tambien puedo descomprimir con esta tool, y el resto de las opciones las dejo como muestra la figura. Una vez hecho eso apreto el boton RUN del GUIPEX para que haga el trabajo.

lli vemos el OK de que la operación ha sido correcta y que el crackme en UPX OUTPUT ha sido

kme le cambiare el nombre para diferenciarlo del original le pondre CRACKME

omo vemos el crackme empacado es mas pequeño que el original, en una epoca esto era asi, ahora

Aempacado. A este cracUPX.exe

Chay packer que agregan tanto codigo para proteger que son mucho mas grandes los empacados que el original, jeje.

Si ejecutamos el empacado vemos que funciona igual que el original, ahora miremos un poco ambos, abramos dos OLLYDBG uno con el CRACKME UPX.exe y otro con el CRACKME.exe para comparar. ENTRY POINT DEL CRACKME.exe

ENTRY POINT DEL CRACKME UPX.exe

Como vemos son diferentes el CRACKME UPX cambio el entry point por 409bf0, donde comenzara a ejecutarse el desempacador, y si en este ultimo voy a mirar que hay en la direccion 401000 por supuesto no encuentro ni rastros del codigo original.

Como vemos la primera seccion esta completamente vacia, asi que el packer quito todos estos bytes los encripto y los guardo en alguna parte del codigo, ademas en este caso vacio la primera seccion completa. En general la mayoria de los packers, crean una propia seccion y se ejecutan desde alli, para tomar

los bytes encriptados guardados del codigo original y arreglar la primera seccion, desencriptando el codigo original en ella. Si miramos nuevamente la rutina del desempacador sin ejecutarla, y bajamos.

Seguimos bajando hasta que vemos

Este es un packer muy inocente, vemos que arranca hace sus desencriptaciones y cuando termina todo su trabajo salta al OEP, sin ni siquiera ocultarlo, al ver los packers actuales da un poco de risa ver esto aun, pero bueno, asi trabaja. O sea que si pongo un BP en ese JMP

Y doy RUN

Alli paro y como termino de arreglar la primera seccion, salta al OEP o la primera linea original de codigo apretemos F7.

Ahi vemos el OEP con el mismo codigo que el Cracme de Cruehead original, el desempacador termino su trabajo y desencripto todo el codigo original, que como habiamos visto en un inicio no estaba alli, pues todo esto eran ceros, y una vez que termino salto al OEP, para empazar a correr el programa. Este esquema de funcionamiento de un programa empacado 1)EJECUCION DEL DESEMPACADOR 2)REPARACION Y DESENCRIPTADO DE LA SECCION DONDE CORRE EL CODIGO ORIGINAL 3)SALTO AL OEP 4)EJECUCION DEL PROGRAMA Ha sido un esquema que ha funcionado durante años y muchisimos packers trabajan asi, con el tiempo los programadores de packers se han dado cuenta que debian modificar un poco el esquema y han agregado ardides para ocultar el OEP, y otro trucos que veremos mas adelante, pero normalmente el funcionamiento general es ese. Reinicio el CRACKME UPX Obviamente si la primera seccion estaba vacia como en este caso o tenia basura y alli se contruye el codigo original, debera escribir en dicha seccion, por lo cual si uso un BPM ON ACCESS en la misma, parara en la rutina que desencripta el codigo veamos. Vayamos a M

Vemos que las secciones han sido cambiadas en tamaño con respecto al original, el cual vemos sus secciones abajo.

Vemos que la seccion CODE empieza en 401000 y tiene 1000 bytes de largo en el original, meintras que en el CRACKME UPX, cambio la seccion CODE a la que empieza en 409000. Bueno igual no importa pongamos un BPM ON ACCESS en la primera seccion del empacado a ver si para cuando desempacay damos RUN.

Vemos exactamente que para cuando va a guardar AL=6A en 401000, si vemos el original en 401000.

Vemos que esta guardando el primer byte 6A que el original posee en 401000, si apreto F9 de nuevo, deberia guardar el byte siguiente o sea el 00 que esta a continuacion, veamos.

Y asi podemos seguir byte por byte, mientras guarda los bytes desencriptados y reconstruye el codigo original, por supuesto no todos los packers desempacan en orden ni desde el inicio como este que es buenito, pero vemos el ejemplo de algo lo mas sanito posible para empezar jeje. Si nos tomamos el trabajo de tracear veremos que esto es un LOOP donde lee un byte de los guardados encriptados, le realiza las operaciones matematicas para desencriptarlo, (sumas, multiplicaciones etc por ejemplo) y cuando obtiene el valor original, lo guarda a continuacion del anterior. Si quitamos el BPM ON ACCESS, podemos si apretamos ANIMATE INTO, divertirnos viendo como se va llenando la primera seccion con los valores originales somo si fuera una pelicula, hasta que llega al BPX que pusimos que es el JMP al OEP.

Vemos como trabaja el programa desencriptando la seccion CODE

Arriba vemos moviendose y ejecutandose al desempacador transpirando la camiseta en un loop, mientras va llenando la primera seccion de valores originales, hasta que termina y llega al JMP al OEP. Una vez que para en el JMP estamos nuevamente a un pasito del OEP apretamos F7

Alli estamos en el OEP, porque decimos que no podemos cambiar con OLLYDBG el codigo y guardarlo como lo hacemos habitualmente, jeje. Si yo por ejemplo agarro los dos primeros bytes 6A 00 y los quiero cambiar por ejemplo por 90 90, y trato de guardar los cambios OLLYDBG me despierta con un

O sea que no puedo hacer eso, porque OLLYDBG no encuentra el codigo en el ejecutable, para cambiarlo. Pero si insisto y con un EDITOR HEXA pongo 90 90 en 401000 y abro en OLLY el crackme modificado, y voy a mirar que hay en 401000, tendre el 90 90 y a continuacion todos ceros, y cuando el packer corra y guarde los valores originales en la primera seccion, mis cambios seran sobreescritos, por los bytes 6A 00 nuevamente, que el desempacador guardara alli en ejecucion y al llegar al OEP en 401000 tendre 6A 00, por mas que en el archivo esten guardados 90 90, han sido sobreescritos en tiempo de ejecucion por el desempacador. O sea que si yo quisiera cambiar esos dos bytes realmente, deberia buscar donde lee el desempacador los bytes originales encriptados, ver que operaciones le aplica para transformarlos en originales, asi poder calcular que valor devberian tener ufff, demasiado trabajo mas facil es desempacar el archivo asi puedo cambiar lo que se me antoje cuando quiero, jeje. Por supuesto hay otras tecnicas para parchear en memoria mediante loaders, que no son motivo de esta parte, los loaders cargan el crackme, esperando que se desempaque en memoria y luego hacen los cambios en alli mismo en la memoria, para que al correr, encuentre los bytes modificados, pero eso es otra historia vamos despacio que despacio se llega jeje ya eso lo veremos mas adelante. Bueno aquí termina esta breve y sencilla reseña inicial, en la parte dos continuaremos investigando el desempacado del famoso CC. Hasta la parte 32 Ricardo Narvaja 16/02/06

INTRODUCCION AL CRACKING CON OLLYDBG PARTE 32 En la parte anterior tratamos de dejar claro el concepto de OEP, o sea la primera linea ejecutada del programa original que el 99 por ciento de las veces esta en la primera seccion (aunque aquí en esta parte he puesto uno que no esta en la primera sección de molesto que soy jeje) Vimos que cuando llegamos alli, y mirabamos la memoria, el contenido es similar al del original, lo cual nos da la posibilidad de intentar dumpear y generar el archivo mas parecido posible al original para reconstruirlo. El metodo clasico seria: 1)ENCONTRAR EL OEP 2)DUMPEAR 3)REPARAR LA IAT 4)VERIFICAR SI EL ARCHIVO TIENE ANTIDUMPS O CHEQUEOS QUE LE IMPIDAN CORRER Y REPARARLOS Este es el metodo clasico que con pequeñas variaciones según el packer, normalmente se utiliza como metodo de trabajo, nos enfocaremos en esta parte en los metodos que podemos utilizar para llegar al OEP, que pueden funcionar en diferentes packers. Hay que decir que muchas veces es necesario probar e intentar, muchas veces estos metodos funcionan, otras veces hay packers que evitan que estos metodos funcionen, por lo cual hay que usar un poco de inventiva, pero teniendo la idea que cual es el punto a hallar (el OEP) veremos como podemos arreglarnos utilizando las herramientas que poseemos. Por ahora para explicar utilizare el Crackme de Cruehead empacado, mas adelante veremos otros packers, pero en esta explicacion general, el mismo nos servira.

1) MIRAR O BUSCAR OPCODES EN EL LISTADO MUERTO DEL PACKER ANTES DE EJECUTAR

Esto solo puede funcionar en packers inocentes ni se me ocurriria intentarlo en un asprotect por ejemplo jeje, pero a veces sirve buscar los opcodes del JMP LARGO (0E9) o CALL LARGO (0E8), pensando que el packer necesitara un salto o call largo a la primera sección para llegar al OEP, y rezando que el mismo este presente en el inicio, o sea que no se automodifique el packer jeje. Pues en este caso seria

Cuando para miro a ver si es un salto a la primera sección y si no es, apreto CTRL+L para que busque el siguiente E9.

Hago CTRL+L

Empiezo a hallar salto largos que no van a la primera seccion, y asi hasta que llego a

El cual es un salto a la primera seccion al que le puedo poner un BPX y cuando para apretar f7 y

estare en el OEP. Tambien si uno tiene ganas de buscar en el codigo del packer deberia intentar CALL EAX, CALL; EBX, JMP EAX, porque muchos packers utlizan los registros para disimular el salto al OEP, en el caso de estos comandos lo bueno es que como son comandos completos los podemos buscar todos con SEARCH FOR - ALL COMMANDS y ponerle BPX a todos juntos, veamos un ejemplo.

Y en este caso no sale ningun resultado, pero si hubiera varios resultados que me salen en la lista, puedo haces click derecho en los resultados y elegir la opcion de ponerle BPX a todos ellos, y con eso tendria la posibilidad de que pare en los mismos, y alli cuando para fijarme en este caso el valor que toma EAX y si vemos que es un CALL o JMP a la primera seccion, pues apreto f7 y llego. Este metodo de buscar en el listado muerto no es muy utilizado, porque la mayoria de las rutinas desempacadoras modernas se automodifica, cuidando especialmente de que la parte del salto al OEP no este visible en el inicio, para evitar este tipo de busquedas, pero bueno, mencionamos la posibilidad que en un packer antiguo o malo, puede funcionar. 2)USAR EL BUSCADOR DE OEPs que trae incluido el OLLYDBG Abramos el crackme UPX y vayamos a DEBUGGING OPTIONS-SFX

Alli vemos las dos opciones que en la pestaña SFX, tiene el OLLYDBG para hallar OEPs, la que esta señalada con rojo es la mas rapida, y la que esta señalada con verde es mas lenta aunque puede funcionar un poco mejor a veces, probemos, pongamos la tilde en la de la flecha roja. Al reiniciar veo que no funciona en este caso, porque es eso, veamos las instrucciones del caso.

Veo en la ayuda del OLLYDBG que esto solo funciona cuando OLLYDBG detecta que el Entry point esta fuera de la seccion code como en la mayoria de los programas empacados, pero en este caso no nos advrtio OLLYDBG de ello, el problema es que UPX cambia la seccion CODE a esta en la cual se ejecuta el desempacador, por lo cual el EP esta en la misma seccion CODE y OLLYDBG no detecta como que es un empacado y en este caso el metodo no funciona, aunque es raro que un packer realice ese cambio, pues aquí no va. Pues para poder demostrar como va este metodo, usare otro crackme empacado que adjunto, es el crackme empacado con aspack, otro sencillo packer. Primero coloco la tilde en su posicion nornal y veo que OLLYDBG me lo reconoce como packer según su metodo de ver si el EP esta dentro de la seccion CODE.

Y me muestra el cartelito de aviso y al aceptarlo llega al EP.

Ahora cambio la tilde por la de la flecha roja, me fijo que las tildes en EXCEPTIONS esten marcadas para que no pare por excepciones y renicio el programa en OLLYDBG.

Doy RUN. Vemos que alli para en 404000 que me marca REAL ENTRY POINT OF SFX CODE (aunque no esta en la primera seccion ya veremos que este crackme es un caso especial que se desempaca en la

tercera seccion algo inusual pero posible)

. En este caso el metodo funciono, ese es el OEP, veamos si tarda mucho mas si hubieramos puesto la flecha verde en vez de la roja. Reinicio y no tarda muchisimo mas ya que el codigo del desempacador es breve, en ambos casos funciono y me dio el OEP correcto. Siempre debemos recordar cuando termino de usar este metodo de ir y quitar la tilde y volverla a su posicion original, pues si no OLLYDBG no parara en los ENTRY POINTS comunes normalmente y siempre buscara parar en OEPs. 3)USANDO EL OLLYDBG PARCHEADO PARA BUSCAR OEPs Este es el mismo OLLYDBG que usamos para las partes sobre Visual Basic, que cuando pones un BPM ON ACCESS, para solo por ejecucion y no cuando lee y escribe (ON READ o ON WRITE) y es ideal para hallar OEPS, veamos el caso del UPX, vayamos a M y miremos las secciones.

Alli esta la primera seccion, en ella el desempacador escribira mientras desencripta los bytes originales, y no queremos que pare mientras trabaja, ya que si no, parara miles de veces antes de llegar al OEP cuando lee y escribe, gracias a este OLLYDBG modificado, no para cuando lee y escribe en dicha seccion, si no solo cuando ejecuta, y eso es lo que queremos hallar nosotros, que pare en la primera linea que se ejecuta en la primera seccion la cual sera casi siempre el OEP.

Me fijo en la pestaña EXCEPTIONS que esten todas las tildes marcadas para que no pare por EXCEPCIONES, y doy RUN y me voy a tomar unos mates, (café o te para los que no son argentinos jeje, aunque yo no tomo mate ju) Por supuesto este metodo es un poco mas lento por eso le digo que se tomen unos mates, depende el packer puede tardar unos segundos hasta varios minutos. Cuando vuelvo de los mates esta detenido en el OEP

Si lo hago en el aspack

Doy RUN

Veo que la primera linea ejecutada es esta, veamos que pasa si apreto f7

Vuelve a la rutina del packer, por lo cual le doy RUN de nuevo y vemos que el programa se ejecuta sin parar, porque ocurre esto? Si nos fijamos, cuando halllamos el OEP con OLLYDBG en este caso el packer varia y no se desempaca en la primera seccion por lo cual hay que poner un BPM ON ACCESS en otra seccion y no en la primera, para determinar en cual, podemos correr el crackme sin poner BPM ni nada. .

Una vez que aparece la ventana del mismo ya sabemos que esta desempacado en memoria, para saber en que seccion esta corriendo, probamos poner BPM ON ACCESS, en cada seccion, si el programa sigue coriendo y no para en OLLYDBG quiere decir que no esta corriendo en esa seccion y probamos la siguiente.

Alli pongo un BPM ON ACCESS en la primera y no pasa nada sigue como si nada, hago lo mismo en la segunda y nada, al poner en la tercera que empieza en 404000.

Veo que para en OLLYDBG, al tratar de ver la ventana del crackme, eso quiere decir que esa es la

hi si se toman unos mates cafes lo que quieran y al volver esta parado en el OEP, jeje, otro

4) EL METODO DEL PUSHAD

seccion que se esta ejecutando, asi que repitamos el proceso desde el inicio para buscar el OEP, pero en este caso, poniendo un BPM ON ACCESS en la tercera seccion.

Ametodo que suele funcionar bien en muchisimos packers.

ste metodo funciona en una buena cantidad de packers y se basa en lo siguiente, muchos packers

eamos el CRACKME UPX

emos el PUSHAD alli en el inicio, a veces puede estar un poco mas adelante, otra veces hay

i nosotros pasamos el PUSHAD con f7

Een sus primeras lineas ejecutan un PUSHAD para guardar los valores iniciales de los registros, luego desempacan, y antes de saltar al OEP, recuperan los valores iniciales de los registros con un POPAD. V

Vpackers que hacen PUSH de cada registro uno a uno, (PUSH EAX, PUSH EBX, etc) pero para el caso es lo mismo guardan en el stack los valores iniciales de los registros, los cuales recuperan antes de saltar al OEP. S

Vemos que alli estan guardados los valores iniciales de los registros, y si los lee antes de saltar al OEP podemos ponerle un HARDWARE BPX ON ACCESS en alguno de esos valores para que pare justo cuando lo lea, y estaremos justo antes de saltar al OEP. Busquemos estos valores en el DUMP, marcando el registro ESP y haciendo FOLLOW IN DUMP

Eso nos mostrara en el DUMP el contenido del stack

Alli vemos los valores que guardó, normalmente lo que se hace es marcar el primer byte o los primeros 4 bytes y colocarle un HARDWARE BPX ON ACCESS.

Es lo mismo que sea BYTE o WORD o DWORD, la cuestion es que pare cuando lea ese valor, demos RUN ahora.

Vemos que al ejecutar el POPAD para restaurar esos valores guardados en el stack, los lee y para, y justo abajo tenemos el salto al OEP, asi que estamos de parabienes aquí este metodo funciono de maravilla. Probemos en el aspack

Alli veo un PUSHAD, lo paso con f7 y luego ESP-FOLLOW IN DUMP

Y doy RUN.

Vemos que para alli justo antes del salto al OEP que en este caso es un PUSH 404000 y luego un RET si traceamos con f7.

Llegamos al OEP perfectamente Debemos decir que muchos packers nuevos vienen protegidos contra este metodo, pero bueno, hay que conocer de todo, y intentarlo para saber si va o no. Sigamos con mas metodos posibles.

5) PARA PROGRAMAS EN VISUAL BASIC (NATIVE O PCODE) Bueno es muy sencillo hallar el OEP de programas de VB empacados, ya que como vimos siempre hay un PUSH y un CALL a la api de VB, al inicio, asi que utilizo el OLLYDBG para VB y cuando arranco el programa y estoy parado en el entry point, voy a M y busco la dll de visual, y en la seccion code de dicha dll, le coloco un BPM ON ACCESS. De esta forma el programa se descomprimira y parara justo en la primera linea que ejecute la dll de visual basic, y en la primera linea del stack tendre la direccion de retorno del call inicial, con lo cual yendo a esa direccion, justo arriba estaran el push y el call incial que se encuentran en el OEP, con lo cual lo habre hallado. Es cierto que el metodo del OLLYDBG modificado para VB tambien funcionara si pongo un BPM ON ACCESS en la primera seccion del programa directamente, pero hay packers que protegen esto muchisimo, por lo cual se pueden intentar ambos metodos y por eso lo dejo asentado aquí ya que

ambos funcionan. No veremos ejemplos en este caso pues es muy sencillo de entender, mas adelante si nos toca un crackme de VB empacado veremos el ejemplo en la practica. 6)METODO DE LAS EXCEPCIONES Si tenemos un packer que genera muchas excepciones al desempacarse, el metodo es el siguiente, usaremos el crackme bitarts que adjunto. Lo abrimos en el OLLYDBG para VB, protegido con los plugins necesarios para no ser detectado. Coloco todas las tildes en EXCEPTIONS y lo corro en OLLYDBG hasta que veo que arranca

una vez que arranco me fijo en el LOG del OLLYDBG apretando L.

Me fijo la ultima excepcion que se produjo, que no sea producida en la primera seccion o sea que no

se haya producido en la ejecucion del programa si no antes, en el desempacado, en este caso la ultima se produjo en 46e88f. Ahora reinicio y quito todas las tildes en exceptions solo dejo la 1ra.

doy RUN y cada vez que para voy pasando con SHIFT+ f9 hasta que llego a la ultima que anote,

lli paro como no es la que anote, hago shift + f9 para saltar la excepcion, recordemos que como es

lli estamo ue arranque el

varias posibilidades, podemos poner un BPM ON ACCESS en la seccion code, y

Yen este caso 46e88f.

Aun INT3 OLLYDBG parara en la direccion justo siguiente o sea 46e890.

A s justo en la ultima excepcion generada por el desempacador, antes qprograma.

quí tengoAmuchos se preguntaran porque no lo coloque en un inicio, y la respuesta es porque muchos packers pueden detectar el BPM si lo coloco desde el inicio, y al llegar aquí, quizas ya paso la detección,

probemos si va.

hora no olvidemos que debemos apretar SHIFT mas f9 ya que estamos en una excepcion.

lli paro en el OEP, podemos probar si el packer detectaba el BPM realizando esto mismo desde el

einicio y coloco todas las tildes en exceptions nuevamente y voy a M y le coloco un BPM ON

emos que llego perfectamente pero es bueno conocer el metodo de las excepciones para cuando el

A

Ainicio. RACCESS en la primera seccion y como estoy usando el OLLYDBG para detectar OEPs pues me voy a tomar unos mates jeje, ya que vemos que en este caso tardara unos cuantos largos minutos, en llegar al OEP.

VBPM ON ACCESS sea detectado por el packer y en ese caso hay que llegar lo mas cerca posible

del OEP, para evitar la deteccion del mismo. Vemos que en este packer incluso usando el metodo del buscador de OEPs que trae el OLLYDBG

asta el metodo del PUSHAD funciona perfectamente, vemos en el inicio

ue si traceamos con f7 unas lineas llegamos a un PUSHAD

o pasa

tambien para perfectamente en el mismo y rapido.

H

Q

L mos con f7 y marcamos ESP-FOLLOW IN DUMP

Damos RUN

Y para cuando lee los valores guardados en ese POP, traceo con f7 hasta el ret al pasarlo llego al OEP.

7)EL METODO DE UNA API MUY USADA POR EL DESEMPACADOR Reinicio este BIT ARTS con el OLLYDBG para OEPs, con todas las excepciones marcadas y buscare una api muy usada normalmente puede ser GetProcAddress, Load Library tambien es muy usada, ExitThread, esto variara según el packer, probemos el metodo con GetProcAddress.

Alli veo en la commandbar la direccion de la api le pondre un BP

En la api elegida, al menos debe poder ponersele BP, si no se puede desde la comandbar habra que buscarla a mano y ponerselo directo. Demos RUN.

Ahora cambiare este BP por un BP CONDICIONAL LOG que no pare, solo LOGUEE.

Ponemos que nunca pare, pero que loguee siempre y que ademas nos loguee el valor de [esp] o sea el valor de retorno, para poder saber desde donde fue llamada la api, limpiamos el LOG, haciendo click derecho-CLEAR LOG.

Damos Run hasta que arranque el programa y miraremos en el LOG la ultima llamada a la api que no sea hecha desde la primera seccion.

Vemos que hay todas llamadas desde el descompresor, hasta que la siguiente es desde 428c2B que ya es desde la primera seccion o sea que corresponde al programa, o sea que la ultima vez que usa el descompresor esta api, es cuando [esp]==47009A, asi que podemos poner como condicion que pare cuando se de eso. Reiniciemos.

Editemos el BPX CONDICIONAL

Ahora le colocamos la condicion y ponemos la tilde para que pare ON CONDITION Y damos RUN

Alli vemos que paro, este metodo se puede completar como antes poniendo BPM ON ACCESS en la seccion CODE, para evitar la deteccion del BPM aunque tiene como problema que muchos nuevos packers detectan el BPX en las apis, por lo cual muchas veces conviene no hacerlo en la primera linea de la api si no en el RET de la misma, el metodo es similar, la idea es buscar que pare lo mas cerca posible antes del oep ya sea para poner un BPM ON ACCESS o ya sea para tracear desde aquí con el trazador automatico que tiene el OLLYDBG (TRACE INTO) Si hemos llegado bastante cerca del OEP, tendremos mas suerte y habremos elegido bien la api, si no, pues deberemos cambiar de api, si miramos el LOG de este programa vemos que una de las cosas que hace antes de arrancar este, es terminar un thread

Por lo cual tanto poner un BP ExitThread como cambiar en el OLLY la configuracion para que pare cada vez que se cierra un thread es posible tambien.

Demos RUN

para alli al terminar el thread

Alli poniendo el BPM ON ACCESS en la seccion CODE parara perfectamente tambien. 8)METODO DE LA PRIMERA API EJECUTADA POR EL PROGRAMA Este metodo es poner un BP directamente en una api sospechosa de ser la primera que ejecuta el programa, normalmente los programas ejecutan al inicio GetVersion, GetModuleHandleA, con mirar unos cuantos programas desempacados obtendremos una lista de las apis mas usadas al inicio no son muchas, en el caso del bitarts vemos que es GetVersion, en el Cruehead es GetModuleHandleA, por ejemplo probemos en el BIT ARTS con BP GetVersion.

Doy RUN

Me debo asegurar que la llamada sea hecha por el programa o sea, desde la primera seccion. Cuando para miro el primer valor del stack que es la direccion de retorno y voy alli.

Alli veo el OEP que lo obtuve con el metodo de la primera api utilizada por el programa, si el programa detecta el BP en GetVersion, se puede poner tambien en el RET de la api. Creo que metodos hay como packers hay y son miles, estos son los ejemplos de los mas usados, ya veran cuando desempaquemos como estos metodos se pueden flexibilizar y adaptar al caso, pero es bueno que tengan una idea de los metodos generales, para poder tener una buena base de los mismos. Adjunto un crackme para practicar que hallen el OEP el UnPackMe_tElock0.98.exe que tiene algunos trucos y que no le van todos los metodos anteriores, auqnue es bueno que practiquen y hallen el OEP por ustedes mismos. Recuerden que si un desempacador detecta un BP o HBP, y no corre, deben revisar bien que no haya ningun BP mi HBP puesto, para que vuelva a correr, recuerden que el metodo del PUSHAD deja un HBP puesto que si no funciona el metodo, hay que borrar antes de intentar otro. Por supuesto el proximo nivel sera un rar con clave, la clave para abrir el mismo sera el OEP del telock0.98 jeje, a practicar y a probar que tienen que ser expertos en hallar OEPs antes de pasar al dumpeo y reparacion de IATs. Hasta la parte 33 Ricardo Narvaja 20 de febrero de 2006

INTRODUCCION AL CRACKING CON OLLYDBG PARTE 33 Que es la IAT y como repararla Antes de ponernos a reparar IATs como loco haremos una introduccion de que es exactamente la IAT y veremos en el CRACKME DE CRUEHEAD original donde esta ubicada y que le hace el packer a la misma, comparandolo con el crackmeUPX empacado. Primero demos una idea generica de para que sirve todo esto que vamos a explicar: El tema es el siguiente, como vimos las apis tienen una direccion en nustra maquina, por ejemplo si abro el Crackme de Cruehead original en OLLYDBG y tipeo

Veo que en mi maquina la direccion donde se encuentra la api es 77D504EA, si ustedes ven la direccion de esta api en vuestras maquinas, algunos tendran la misma direccion, otros no, depende de la version de Windows que tengan, y de las actualizaciones que hayan bajado tambien, que como saben son muchisimas, y en cada una al bajar nuevas versiones de la dll que contiene la api en este caso User32.dl, generalmente cambiara la direción.

Cada vez que Microsoft saca una nueva version de esta dll, casi siempre cambiara la direccion de las apis que contiene, por lo tanto si yo programara el Crackme de Cruehead, al saltar a la api MessageBoxA, lo haria saltar a 77D504EA, y funcionaria pefcetamente en mi maquina, y en las que tuvieran la suerte de tener la misma version de User32.dll que yo, en el resto de los demas Windows que o bien no sean XP, o bien no tengan la misma version de la User32.dll, saltaria a una direccion donde no estaria la api, lo cual produciria error y no correria. El tema entonces es que el sistema operativo debe suministrar alguna forma de compatibilizar para que mi crackme funcione en otros Windows (dentro de ciertos limites) y en otras versiones de la dll debe funcionar perfectamente. Para ello se crearon estas famosas tablas llamadas IT (Import Table), y IAT (Import Adress Table) No se austen son puro nombre una vez que uno sabe donde esta ubicada cada una en un programa desempacado y para que sirven no hay mas miedo.

Ahora hagamos SEARCH FOR-ALL INTERMODULAR CALLS y veamos los CALLS que van a otros modulos o dlls, que pueden ser calls a apis.

Alli vemos varios Calls a la api MessageBoxA como ejemplo, si hacemos doble click en el primero de ellos

Vemos que en realidad es un CALL 40143A que OLLYDBG para aclararnos nos pone que saltara a la api MessageBoxA, cambiando la notacion por CALL <MessageBoxA> pero no es un call indirecto, es un call directo CALL 40143A

emos que en las opciones del OLLYDBG en la pestaña DISASM si le quitamos la tilde a SHOW

emos que igual nos aclara a la derecha los parametros y la api a la cual ira, pero ahora nos muestra

ALL 40143A

n SEARCH FOR INTERMODULARS CALLS

VSIMBOLIC ADDRESSES el listado queda mas claro.

Vel CALL realmente como call directo. C E

Vemos que en realidad los tres calls a MessageBoxA son calls a 40143A, pues veamos que hay alli.

Aquí vemos el quid de la cuestion, para llegar a la api hace un JMP indirecto, que al tenerlo en esta forma de visualizacion se ve claro que toma el valor a donde saltara de 4031AC JMP [4031AC]

Tambien vemos que si ponemos la tilde, se nos complica un poco entender que es un salto indirecto, por lo cual la quitaremos mientras estamos trabajando con IATs. Y aquí esta el truco, el programa salta a la api con un JMP indirecto que toma la direccion que la api tiene en nuestra maquina de 4031AC, y vemos que para todas las otras apis, hay otros JMPS INDIRECTOS similares. Ahora empezamos a ver un poco mas claro el tema de la compatibilidad entre maquina, cuando el programa tiene que ir a una api, hace un salto indirecto, leyendo la direccion de la api de una especie de deposito, si vemos en el dump este deposito.

Alli vemos realemente que 4031AC es una parte de un deposito que contiene todas las direcciones a las apis en mi maquina, ahora este DEPOSITO es la famosa IAT o IMPORT TABLE ADDRESS, aquí esta la clave de la compatibilidad, quiere decir que todos los programas tendran los mismos JMPS INDIRECTOS a las apis, lo que cambiara es el valor guardado en el deposito, para cada maquina tendra direcciones diferentes que llevaran el salto indirecto, a la direccion correcta de la api. Pero un momento me diran algunos, 4031AC es una direccion del programa, por lo cual si tiene diferentes direcciones para cada maquina, pues entonces el programa seria diferente para cada maquina? Jeje buena pregunta ahora veremos como funciona el sistema, pero ya sabemos el objetivo, el cual es llenar la IAT de las direcciones correctas para cada maquina.

Sabemos que si hacemos VIEW- EJECUTABLE FILE podemos ver lo que hay en la direccion

4031AC, realmente en el archivo ejecutable guardado en nuestro disco rigido.

Vemos que el valor en el exe, es 60 33, y que nosotros parados en el entry point ya tenemos en la memoria en la misma posicion la direccion de la api EA 04 D5 77 guardada alli, quiere decir que el sistema al arrancar el programa, tomo el 3360 que habia alli en el OFFSET 0FAC que corresponde a la direccion 4031ac y lo machaco con el valor de la direccion real de la api en mi maquina. Magia? No no asi trabaja Windows, cada archivo que arranca, el sistema operativo llena la IAT de las direcciones correctas de las apis en mi maquina, en este caso lleno 4031AC con el valor de la api MessageBoxA y los valores alrededor, con las direcciones de oras apis, para completar la tabla IAT o deposito de direcciones de las apis en mi maquina. Ahora el sistema no es mago como hace esto, vemos que en 0FAC tiene un valor 3360, le indicara algo al sistema este puntero, para que sepa que api es la que debe llenar alli? Pues si 3360 es el valor al cual si le sumamos la imagebase queda 403360 y si miramos en el sump esa direccion que vemos?

Pues aquí esta el truco es un puntero a la string MessageBoxA, eso quiere decir que el sistema mira ese puntero, busca que api es por el nombre y con GetProcAddress, saca la direccion de dicha api en

nuestra maquina, y lo completa en la IAT, machacando el 3360, con la direccion real de la api en nuestra maquina, y de esta forma se asegura que el programa funcione para cualquier version de la dll, porque halla la direccion antes de llegar al Entry Point del programa y una vez que llego alli, queda la iat completita con las direcciones de las apis en mi maquina, si miro la iat de otra maquina diferente vere que el contenido de 4031AC es diferente pues la direccion de la api, es diferente, pero cuando haga. JMP [4031AC] ira a su MessageBoxA al igual que en mi maquina, el programador no se tiene que preocupar, siempre que haga calls o jmps indirectos al valor que se encuentra en el deposito de la IAT, este estara correcto, al arrancar el sistema coloco en tiempo real la direccion correcta, apuntando a MessageBoxA en todas las maquina para asegurar compatibilidad. O sea que para que el sistema me complete correctamente la direccion de la api en la iat, debe el archivo tener varios punteros como vimos. 1)en la entrada de la iat en el ejecutable en mi rigido, debe tener un puntero a una cadena de texto que le identifique al sistema que api debe colocar en esa entrada. 2)Por supuesto debe tener la cadena de texto con el nombre de la api Pues con estos dos puntos, podemos cocluir que el programa arrancara y el sistema me llenara la IAT con los valores correctos. (mas adelante veremos el trabajo cmpleto de este sistema) Ahora ya vimos como llegamos al OEP de un programa empacado, porque se dice que cuando llegamos alli y dumpeamos un programa debemos reconstruir la IAT, los packers la rompen? Que hacen con ella, pues si la rompen algunos mas otros menos, el truco es que el packer no necesita la iat del programa en si porque arranca desde el mismo desempacador, y puede leer las apis que deberian ir en la IAT, mientras va desempacando el programa, y una vez que leyo cada api, y lleno la iat con las direcciones correctas de cada api, pues las strings que le indicaron cual era cada api, las borrara, ya no las necesita, pues el programa ya arranco y tiene ya en la IAT las direcciones correctas. Es mas en los packers ni siquiera existen esas strings ya que el programa o bien las guarda encriptadas o bien las guarda en alguna otra direccion que no sean facil de hallar por nosotros los crackers. Veamos el ejemplo con el empacado UPX para ver la diferencia y como nos queda al dumpearlo, y porque hay que repararlo.

Aquí tenemos el Crackme de Cruehead que esta empacado con UPX que habiamos hecho en partes

anteriores. Miremos la direccion 4031AC donde estaba el deposito de apis en el original

ada borro todo, y las strings de las apis estaban en 403360 que haya alli?

ada, de nada, lleguemos al oep y veamos que hay en estas mismas direcciones, ya que para que el

MP [4031ac]

estar vacio dara error, o sea que el packer hara el trabajo que hace normalmente el sistema y

n

Nprograma corra en la iat debe haber algo si no al saltar a la api, y hacer J yllenara la iat, lleguemos al OEP.

Ponemos un BP en el salto al OEP y damos RUN y llegamos alli Veamos que hay en el lugar de la iat

Vemos que para que el programa funcione el desempacador lleno la iat con las direcciones correctas de la api en mi maquina, pero si nosotros dumpeamos aquí habra un problema, el ejecutable que salga del dumpeado le faltan datos para arrancar. Ya de por si las strings que identificaban cada api y estaban en 403360 no estan

Veamos hagamos un dumpeado a ver que queda, pero ya nos damos cuenta que tendremos el

codigo del programa correcto, pero el dumpeado no correra al no poder el sistema llenar la iat por falta de datos. Por ahora utilizaremos un programa externo al OLLYDBG para dumpear este es el LORDPE DELUXE que se puede bajar desde mi HTTP. http://www.ricnar456.dyndns.org/HERRAMIENTAS/L-M-N-O-P/lordpe-delux1.4.zip

Alli tenemos al LORD PE DELUXE busquemos el proceso a dumpear que es el crackmeUPX que tenemos detenido en el OEP.

Alli esta el crackmeUPX, marquemoslo

Haciendo click derecho cambiemos a INTELLIDUMP que dicen que es mejor dumpeando, jeje y luego hagamos click en DUMP FULL.

Lo hemos guardado con el nombre DUMPED.exe

Si corremos el dumpeado vemos que no arranca tratemos de abrirlo en OLLYDBG Y nos da el mismo error pero si vemos el LOG del OLLYDBG los errores

El error se produjo en 7c929913 en mi maquina vayamos a esta direccion, ustedes en su maquina a la direccion que figure en el LOG.

Le pondre un HARDWARE BREAKPINT ON EXECUTION y un BP a ver si para antes de dar el error. Pues veo que no para, pero tengo otra forma de parar en un error y es quitarle la tilde a las excepciones, al reiniciar

Vemos que si para antes de llegar al Entry Point en el error que no deja arrancar al dumpeado,. Ya que estamos miremos que hay en la iat

Alli vemos que el dumpeador, logcamente guardo los valores que habia en la iat al momento de llegar al OEP que son los valores correctos en mi maquina de cada API, pero el tema como habiamos visto es que para que un exe arranque sin error y en cualquier maquina, en el ejecutable, alli debe haber un puntero a cada string con el nombre de la api, y el ejecutable contiene el mismo valor este que estamos viendo, que el sistema esta tratando de leer y al no hallar el puntero a la string de la api, le da error.

Pues no hay que ser un genio para darse cuanta que para que arranque el programa hay que restaurar los nombres de las apis, y los punteros a ellas,si quisiera hacerlo a mano es un trabajo terrible deberia cambiar el contenido de 4031AC por un puntero a la string de MessageBoxA y con ciertos arreglos de algunos punteros, pues arrancaria. Aquí tenemos planteado el desafio, esto es lo que debemos reparar para que nuestro dumpeado ademas de tener el codigo correcto, que por supuesto lo tiene, corra perfectamente. De que tiene el codigo correcto no hay duda vayamos a 401000 y miremos que hay alli

Si vamos a la zona de los saltos a las apis Alli vemos el call a la MessageBoxA que habiamos visto anteriormente

En el CALL el codigo esta correcto, nos lleva al mismo JUMP que antes

Los JUMPS estan lo unico que falta es hacer funcionar el sistema de que llene la IAT con el contenido correcto, para que tenga en la misma antes de correr el programa, los punteros a las strings y que el sistema lo llene con las direciones correctas sin error. Antes de acometer esta tarea veremos las definiciones y ubicación correcta en el programa original sin empacar de la IAT y la IT. Abramos el CC original en OLLYDBG.

Bueno ubicaremos las partes que hacen que este sistema funcione bien en el original. En el header, tenemos algunos punteros importantes. Vayamos al mismo

hora cambiemoslo a modo SPECIAL-PE HEADER

ajemos

os datos realmente empiezan en 100 donde comienza la PE SIGNATURE

A

B

L

El chico no miente alli empieza jeje en 400100 o sea en offset 100.

alli tenemos los punteros a la IT o sea la Import Table que no debemos confundirla con la IAT a pesar de que tengan nombres parecidos. IT= IMPORT TABLE IAT=IMPORT ADDRESS TABLE Como ya vimos la IAT es el deposito donde el sistema guarda las direcciones correctas de mi maquina al arrancar, y que es la IT, pues vayamos alli, como vemos dice que empieza en 3000 (403000) y su largo es 670 o sea que termina en 403670, vayamos a mirar. Como esta fuera del header quitamos el MODO SPECIAL-PE HEADER

Esto que parece un chorizo sin interpretacion posible, es facil de interpretar, si sabemos que es cada cosa, lo detallaremos y veran que esto es muy importante. Esto es la famosa IT, aquí la tenemos si comprendemos esto, y aunque no sepamos los nombres de cada puntero, sepamos que es cada cosa y donde apunta, pues estamos salvados. Lo malo que tenemos para explicar esto en OLLYDBG es que es mucho mas comodo y visible hacerlo en una visualizacion de 5 columnas asi queda ordenado, ya veremos por que. La famosa IT esta compuesta por los denominados IMAGE IMPORT DESCRIPTORs que son varias lineas de 5 valores dword, de la cual hay una por cada dll que cargara el programa. Veamos la IT, por eso les digo que esto se ve mejor con 5 columnas para ordenar cada IID uno en cada linea. Pero bueno no nos queda otra aquí vemos el primero

Ese es el primer IID de nuestra IT y tiene 5 DWORDS cuyos nombres son estos • OriginalFirtsThunks. • TimeDateStamp. • ForwarderChain. • Puntero al nombre de la dll. • FirtsThunk (Apunta a donde debe buscar en la IAT la primera entrada de dicha dll). Los tres primeros no son importantes para el cracking hasta siendo cero, normalmente arranca igual el programa, son para usos muy determinados, los importantes son el 4 y el 5to puntero de nuestro primer IID.

Alli esta como vemos el 4to apunta al nombre de la dll a la cual pertenece este IID, veamos cual es la dll en 403290.

Alli esta la primera dll que el sistema buscara es USER32.dll y el 5to puntero marca donde comienza en la IAT las entradas de esta dll, en este caso es 403184.

Alli esta es la IAT, y su primera entrada, todo esto esta dentro de la IT, ya que terminaba en 403670, asi que tenemos que la famosa IT, tiene una linea para cada dll, estas lineas son llamadas IID o IMAGE IMPORT DESCRIPTOR y dentro de la IT esta la IAT o deposito de las direcciones de las apis, todo compacto y para

el uso del sistema. Muchos crackres experimentados diran que no siempre la IAT esta dentro de la IT, ya que el 5to puntero de cada IID puede apuntar a cualquier lado y tranquilamente puede estar fuera, ubicada en cualquier lugar del programa que tenga permiso de escritura, para que cuando arranque el exe, alli el sistema vaya guardando las direcciones correctas de las apis, la cuestion es que ya vemos como trabaja mejor el sistema para llenar la IAT,

1) Busca la IT 2) Busca la primera IID y se fija en el 4to puntero a que dll pertenece 3) Luego mira en el 5to puntero donde esta la primera entrada de la IAT 4) Alli hay un puntero a la string con el nombre de la api 5) Con GetProcAddress busca la direccion y la guarda en la misma entrada. 6) Cuando encuentra en la IAT una entrada con ceros, eso le indica que termino la primera dll y que

debe pasar a mirar el segundo IID para buscar cual es la segunda, y repetir el proceso. O sea que si el sistema hara esto en imagenes y es importante que lo entiendan bien porque si al sistema le falta algo o encuentra punteros incorrectos dara error y es importante entenderlo a fondo. 1)Busca la direccion de la IT

2)Va a esa direccion

3)En el primer IID busca el 4to DWORD que le apunta al nombre de la dll donde empezara a trabajar en este caso sera USER32.dll.

Luego mira el 5to puntero para buscar la primera entrada de la IAT que es 403184 y va alli.

Alli lee el valor que no es ese pues alli ya esta machacado, sino el que esta en el ejecutable, veamos

alli ve que el nombre de la primera api esta en 4032CC, va alli

Ve que la primera api es KillTimer con GetProcAddress halla su direccion que nosotros hallamos con el OLLYDBG.

Y ese valor que en mi maquina es 77d18c42 lo guarda en la misma entrada de la IAT machacando el existente.

Alli lo vemos es la primera entrada de la IAT ya cuando llego al entry point y muestra el valor que tiene esa api en mi maquina. Asi saltara a la siguiente entrada de la IAT, que halla facilmente sumandole 4 a esta, y busca el siguiente puntero al nombre de la proxima api.

Por supuesto mira en el ejecutable y este es

32d8 o sea 4032d8, mira el nombre de la api siguiente alli y como no hallo un cero en la entrada, sabe que continua con las apis de user32.dll.

La segunda api es GetSystemMetrics hallara la direccion y la guardara en la segunda entrada de la iat y asi, seguira buscando apis en user32.dll hasta que llegue a una entrada con todos ceros si vemos la iat en el ejecutable.

Vemos que seguira buscando en user32.dll hasta que halle ese cero donde retorna al siguiente IID

Cuyos 4 y 5to puntero son esos, el 4to le dice que en 40329b esta el nombre de la 2 dll donde buscara nombres.

Que es Kernel32.dll y la primera entrada de la iat donde buscara sera la que esta a continuacion del cero o sea 40321c.

Alli vemos el cero que determino que no hay mas apis de user32.dll y en 40321c empiezan las de Kernel32.dll donde buscara en el ejecutable el primer puntero a la string y llenara aquí con el valor de la api correcta. Creo que es muy importante entender bien esto, trate de explicarlo y repetirlo varias veces para que quede pero creo que con solo una leida eso no queda en la mente traten de grabarselo con fuego pues esto es la base de todo el tema de la reconstruccion de las IATs y aunque ya veremos en la parte siguiente que hay tools que nos ayudan a hacer el trabajo pesado sin tener que revisar todo esto, es muy importante saber como trabaja todo, asi cualquier problema o caso raro, no nos quedaremos a un costado del camino y siempre podremos entender que esta pasando. En la parte siguiente arreglaremos IATs no lloren jeje ya tienen suficiente con comprender como trabajan por ahora jejejejeje. Hasta la 34 Riardo Narvaja 27/02/06

INTRODUCCION AL CRACKING CON OLLYDBG PARTE 34 En la parte 33 vimos como funciona el sistema de la IT y IAT, yo se y los que saben reparar una IAT, pueden pensar que no es necesario saber como funciona, ya que hay tools que reparan una iat casi automaticamente, pero yo les aseguro que es bueno saber como funciona y que ocurre en cada momento, porque hay muchos packers que engañan a las tools y las hacen fallar, por lo cual en esos casos hay que saber razonar y pensar que esta pasando para hacer alguna correcion a mano, o poder moverse con facilidad. Empezaremos con algo facil el Crackme de Cruehead empacado con UPX, realizaremos el proceso de desempacado completo aquí para unir todo lo que vimos y al final repararemos la IAT, para que quede funcional. Como vimos el primer paso era llegar al OEP, por lo cual abro en OLLYDBG el CC o sea el Crackme de Cruehead.

Aplicare el metodo del PUSHAD para llegar al OEP apreto f7 para pasar el PUSHAD.

Ahora marco ESP-FOLLOW IN DUMP. Y en el dump vere los registros que guardo, y marcare los primeros 4 bytes, y pondre un HARDWARE BPX ON ACCESS.

Y doy RUN, parara en el salto al OEP.

Bueno ya estoy en el salto al OEP, apreto f7 y llego al mismo.

Bueno ya llegamos, al punto donde el programa esta desempacado en memoria ahora lo dumpearemos. Como vimos en partes anteriores, existen muchos dumpeadores, incluso el OLLYDBG tiene un plugin llamado OLLYDMP que dumpea muy bien, pero como ya vimos como se hace con el LORD PE, ahora utilizaremos PE -TOOLS que pueden bajarse desde: http://www.uinc.ru/files/neox/PE_Tools.shtml Como nos cansaremos de desempacar, y de practicar mas adelante en futuros desempacados tambien usaremos el plugin OLLYDMP asi aprendemos a usar todos. Abramos el PE-TOOLS sin cerrar el OLLYDBG que esta detenido en el OEP.

Bueno alli esta el proceso que en este caso se llama crackme.exe ya que perdi el que se llamaba crackmeUPX y lo hice de nuevo y me olvide de cambiarle el nombre, pero es lo mismo, se llame como se llame es el crackme de cruehead empacado con UPX y detenido en el OEP.

Haciendo click derecho-DUMP FULL

Bueno ya esta dumpeado ahora vamos a la reparacion de la IAT cerramos el PE TOOLS vimos que el DUMPED lo guardo en la carpeta del PE TOOLS, asi que lo buscamos y lo copiamos a la carpeta donde esta el mismo Crackme de Cruehead empacado con UPX.

Bueno ya sabemos que aun falta reparar la iat, igual probamos ver que pasa si lo ejecutamos, hacemos doble click en el dumped.exe y..

Bueno como ven hay que reparar la IAT, aunque corriera en nuestra maquina, debemos reparar la IAT para que funcione en cualquier maquina y no solo en la nuestra, para ello usaremos el IMPORT RECONSTRUCTOR, por supuesto no cerramos el OLLYDBG con el CC empacado con UPX detenido en el OEP, pues el IMP REC trabaja sobre el. http://www.ricnar456.dyndns.org/HERRAMIENTAS/F-G-H-I-J-K/ImportReconstructor16f.zip user y pass:hola pueden bajarlo desde alli.

Lo abrimos y buscamos el proceso del crackme de cruehead con UPX que esta detenido en el OEP. Ahora bien un tema que complica a muchisimos newbies es hallar el inicio y final de la IAT, por supuesto en el crackme que tenemos detenido en el OEP ya vimos que el packer destruyo la IT, por lo cual el primer Image Import descriptor cuyo 4 puntero marca el nombre de la dll y el 5to marca la primera entrada de la iat correspondiente a esa dll, no los tenemos, por lo cual debemos utilizar otros metodos para hallarla. Por supuesto sabemos que las llamadas a las apis generealmente son realizadas con JMPs indirectos o CALLs indirectos del tipo. JMP [xxxxxxx] o CALL [xxxxxx] y como hemos visto en la parte anterior el programa toma la direccion de la api en nuestra maquina de la IAT, que es el deposito de direcciones de las apis en nuestra maquina, busquemos un salto a una api en el empacado, para lo cual miremos en el OLLYDBG con el CC empacado, parado en el OEP.

Alli en la segunda linea vemos un CALL que ollydbg nos dice que ira a una api, aunque previo paso por los JMPS INDIRECTOS, asi que marquemos esa linea y hagamos FOLLOW

Alli encontramos la tabla de saltos que tomando valores de la IAT, nos lleva a cada API, como vemos estos saltos comienzan con los opcodes FF 25, por lo cual muchas veces veran en tutes que directamente haces un search for bynary string y buscan FF 25, y llegan hasta aquí mas rapidamente. El tema es que no todos los programas usan saltos indirectos para llegar a las apis, por lo cual a veces ese metodo falla, pero lo mejor y que nunca falla es buscar una llamada a una api, y ver de donde toma el valor guardado que nos llevara a la api, y ese valor tiene que estar guardado en la IAT. Aquí en el ejemplo JMP [403238]

lli esta bien claro 403238 es una entrada de la IAT donde esta guardada la direccion de la api

or supuesto mirar todos los JMPS INDIRECTOS y ver cual es la minima y maxima direccion

lli vemos la organización de la IAT, vimos en la parte anterior que estan continuadas todas las

lgunos packers ma basura para que se haga mas dificil la

29 B5 80 7C 0E 18 80 7C )µ€|##€|

AGetModuleHandleA, de esta forma en el DUMP estamos viendo parte de la IAT, lo que necesitamos es ver donde comienza y donde termina la misma. Ppodria ser un metodo, aunque es muy lento, lo mejor es ir al DUMP e ir subiendo de a poco, y como sabemos cada entrada tiene una direccion de una api, en este caso es 7C80B529, que vista al reves es 29 B5 80 7c, cambiare a la vista de dos culumnas para que se aprecie mas.

Aentradas de la misma dll y luego la separacion para comenzar con la siguiente dll, es una entrada con ceros, si marcamos los ceros de separacion.

A s sofisticados sobreescriben los ceros con reconstruccion, total esas entradas no se usan, y como ya no necesita arrancar el programa, no necesita mantener los ceros, pero aquí estan y como ejemplo vemos que entre ellos en una misma dll las direcciones son cercanas ya que van a la misma seccion donde se encuentra esa dll, si ven abajo de 04032380

00403240 A2 CA 81 7C 00 00 00 00

hay tres apis que van a direcciones 7Cxxxxxx y luego esta la entrada con los ceros que separa de la iguiente dll.

IEW-M veremos a que seccion CODE de que dll corresponden esas direcciones tipo Cxxxxxx

Pues alli vemos que todas esas direcciones estan co de la seccion code de la ernel32.dll.

Por supuesto en sus m s, pero aquí veo que n mi maquina esas entradas corresponde a la seccion CODE de la kernel32.dll o sea que las

ues alli vemos todas las e a la kernel32.dll, vemos la separacion con ceros arcada en rojo y mas arriba hay entradas que van a otra dll en este caso su seccion CODE se

seccion CODE de

user32.dll, sigamos subiendo hasta la siguiente separacion.

s Si vemos en V7

mprendidas dentrok

aquinas las dll pueden estar ubicadas en otras direccioneedirecciones de las entradas contiguas caen todas alli en esa dll.

P ntradas correspondientesmencuentra en direcciones cercanas a 77Dxxxxx, miremos en M, a que dll corresponden.

Pues entonces las direcciones que hay arriba de la separacion, corresponden a la la

Pues alli vemos todas las apis que caen dentro de la seccion CODE de la user32.dll y la separacion pero arriba ya no hay mas nada quiere decir que el inicio de la iat es 403184, pues esa es la primera entrada valida.

Vemos claramente mas arriba no hay mas entradas que vayan a ninguna dll, y en este caso, ademas hacia arriba hay todos ceros lo cual nos facilita la tarea de ver el inicio de la IAT, algunos packers mas complejos normalmente llenan de basura antes de la IAT y luego de que termine, para que no sea tan facil identificar el inicio, pero si uno sabe que las entradas de la IAT siempre deben ir a la seccion code de una dll, pues el resto en seguida nos damos cuenta lo que es basura, pues no nos lleva a ninguna seccion code de ninguna dll. Pues alli en la imagen vemos el inicio de la IAT que es 403184, ahora iremos bajando hasta hallar el final de la iat, usando el mismo metodo, mirando siempre que la IAT continuara mientras haya entradas que vayan a una seccion code de una dll. Tambien mas adelante veremos que hay packers que cambian entradas de la IAT y las redireccionan a rutinas propias, desde la cual saltan a la api, ese caso por supuesto no se da aquí, y lo estudiaremos mas adelante, pero por ahora, sabemos que las entradas de la IAT son direcciones de apis, y que deben llevarnos a secciones code de dlls.

Alli vemos las ultimas entradas de la IAT que van a 76xxxxxx veamos a que dll corresponden.

En este caso corresponden a la sección CODE de COMDLG32.dll y luego de esto no hay mas entradas asi que el final de la IAT para que queden todas las entradas incluidas dentro seria 40328C, podria tomarse tambien que la ultima entrada es 403288 y igual funcionara, pero para mas claridad vemos que termina en 40328c y ponemos esa direccion como fin de la IAT. Por lo tanto ya tenemos el inicio y final de la IAT INICIO: 403184 FINAL: 40328C el IMPORT RECONTRUCTOR nos pide tres datos : 1)el inicio de la IAT, pero hay que restarle a 403184 la imagebase que en este caso es 400000 asi que seria 3184. 2) El segundo valor que nos pide es el largo de la IAT por lo cual restando el FINAL menos el INICIO tendremos el largo. LARGO=40328c-403184=108 por lo cual el segundo dato que nos pide del largo o SIZE sera 108 3)El tercer dato es el OEP tambien restandole la imagebase seria 401000-400000=1000

Estos datos los ingresaremos en el IMP REC.

Alli vemos lso daros que pusim os el 1000 ya que a 401000 le restamos la im agebase tambien y en Size el largo de la IAT. Ahora apretamos GET IM

Vemo la IAT, y ademas de hallarla, te com rcando YES, en el caso de entradas

strara NO y en ese caso habra qu ara que el IMP REC reconozca co YES como en el caso actual ya podem

Tenemos cada entrad era que vimos en la IAT que era la entrada co

Si recuerdan esa fue la primera entrada que miramos en la IAT la correspondiente a 403238, por supuesto en IMP REC siempre hay que restar la imagebase por lo cual buscaremos 3238 ademas sabemos que pertenece a Kernel32.dll como vemos en la imagen superior al lado del nombre de la

os en el IMP REC, en OEP pusimagebase, en RVA el inicio de tabla restandole la im

PORTS

s que el IMP REC lo que hace es hallar que apis pertenece a cada entrada deunica si es valida o sea si esta correcta, ma

redireccionadas por ciertos packers que no vayan directamente a una API te moe averiguar esa entrada incorrecta a que api pertenece realmente, arreglarla p

mo entrada correcta y nos diga YES y una vez que esta todoos reparar el dumpeado.

Antes de hacerlo como nos gusta mirar, veremos que en cada dll, si desplegamos el contenido apretando en el +.

a a que api pertenece y si tenemos ganas podemos ubicar la primrrespondiente a GetModuleHandleA.

api.

Alli buscamos el dumpeado y lo abrimos

Bueno alli vemos que el IMP REC lo repara aunque no toca el DUMPED que teniamos guardado

Por lo tanto debemos abrir la kernell32.dll y para ello hacemos click en el + que esta a la izquierda.

Alli vemos la entrada 3238 corresponde a GetModuleHandleA esta todo bien, asi que ahora repararemos el dumpeado, vamos al boton FIX DUMP.

sino que crea uno reparado con el nombre DUMPED_.exe.

os alli en la carpeta donde esta. Veam

si quedo bien.

uchas veces nos ne la solucion abrimos el PE TOOLS

vamo ente ahora lo

jecutamos yyyy...

os reparado la IAT, de

Alli esta podemos intentar ejecutarlo a ver

ejejejeje aun parece que falta algo pero a no asustarse que al reparar la IAT mJ

ocurrira esto, el mismo PE TOOLS tie

Y s a REBUILD PE y buscamos el DUMPED_.EXE y lo repara perfectame

Funcionaaaaaaaaaa y ademas funcionara en cualquier maquina, porque hem

forma que el IMP REC lo que hace es teniendo las apis correctas de cada entrada de la IAT, reescribe los punteros a los nom un IID por cada dll como vimos en la parte anterior que debe quedar todo a para que arranque normalmente sin error. Si abrimos el DUMPED_.exe en OLLYDBG.

emo eccion code y

Llegam

bres de las apis, y arregla la IT poniendo program

V s que OLLYDBG nos dice ahora que el Entry Point, se encuentra fuera de la seso es porque el UPX habia cambiado la seccion code a la 3ra, igual podemos arreglar eso.

os al Entry Point y vamos a ver el header con GOTO EXPRESSION=400000

Alli esta bajamos

Cambiamos a modo SPECIAL-PE HEADER

Vemos que la PE SIGNATURE e

Alli esta el puntero mla primera, la que em

Lo marcamos y vamos a MODIFY INTEGER.

mpieza en 80 vayamos alli a 400080.

aldito dice BASE OF CODE=9000 o sea queremos que la seccion CODE sea pieza en 401000 asi que cambiamos ese 9000 por 1000.

la

Ahora guardaremos los cambios como siempre click derecho COPY TO EXECUTABLE y enventana que se abre click derecho SAVE FILE.

Ahora reiniciamo bien OLLYDBG analiza la seccion y cual suele ser de mucha ayuda.

Si vamoeccion nueva llamada mackt donde colocara la nueva IT, comprobemoslo, en el mismo header en odo SPECIAL vayamos a ver el puntero a la IT.

s y vemos que no solo no sale el cartelito molesto, si no que tama que al interpretarla como CODE, le realiza el analisis, lo

s a ver las secciones del dumpeado veamos que para repararlas el IMP REC le agrega una sm

Vemos que la IT esta ahora en B000 o sea 40B000 que es la direccion de la seccion que agrego el IMP REC vayamos a ver alli quitando el modo SPECIAL.

Alli vem letamente

Alli vemos el primer IID correspondiente a la primera dll, cuyo 4to DWORD nos apunta a su nombre como vimos, en este caso el nombre de la dll estara en B078 o sea 40B078.

os la IT tal cual la vimos en la parte anterior, unicada en otra direccion pero compfuncional, si queremos podemos hallar los punteros como en la parte anterior para repasar.

Es user32.dll. Y el 5to puntero com

habiam

os en el ejecutable, quina, debe

o vimos en la parte anterior apuntara a la primera entrada de la IAT, en este caso el 5to puntero es 3184 por lo tanto la primera entrada de la IAT estara en 403184 como

os visto que era el inicio de la IAT al reconstruirla.

Y por supuesto la primera entrada de la IAT ahora tiene el valor de la api pero si vem antes de ser sobreescrita por el sistema con la direccion de la api en mi ma

tener el puntero al nombre de la api, que llenara dicha entrada si vemos.

eberia estar el nombre de la API que llenara esta entrada.

La cual es KillTimer. Vemo mente arreglando todos los punteros ra que al arrancar el sistema sepa que api debe aravilla. Bueno esta ha sido nuestra prim que puede existir, pero es la base de todo y es tengan bien claro, porque a medida que sigamos desem letemente destrozadas, apis redireccionadas y casos dificiles, para los cual prescindible haber entendido bien comno trabaja todo.

demas este packer no tiene antidumps que es la parte que aun no vimos ya que no fue necesario, e os casos

con ANTIDUMP. De cualquier m

Hasta la parte 35 Ricardo Narvaja 05/03/06

En esa entrada de la IAT en el ejecutable, existe el valor B084 que corresponde a 40B084, donded

s que el IMP REC realizo un trabajo estupendo, detecto cada api, construyo la IT nueva, y reconstruyo la lista de nombres de cada api pa

llenar cada entrada de la IAT una verdadera m

era reconstrucion de una IAT la mas sencilla importante que tanto la parte anterior como esta, la

pacando nos encontraremos con IATs compes es im

Apero a m dida que vayamos avanzando en la complejidad de los packers ya encontrarem

anera iremos incrementando la dificultad suavemente para que se les vaya fijando los conceptos asi que no se asusten, vamos de a poquito jejejejeje

INTRODUCCION AL CRACKING CON OLLYDBG PARTE 35 Seguiremos practicando y desempacando cada vez con packers mas dificiles, aumentando levemente el grado de dificultad. El siguiente packer en la escala de dificultad es el aspack, casi muy parecido al UPX, y para el cual ya tenemos el crackme UnPackMe_ASPack2.12.exe que se envio en partes anteriores, al cual ademas ya le habiamos encontrado el OEP. Coloco para practicar la dll del OLLYDUMP en la carpeta de plugins ya que lo dumpeare con el mismo. http://www.ricnar456.dyndns.org/HERRAMIENTAS/L-M-N-O-P/Plugins_Olly/OllyDump%20parche%20de%20parasito.rar user y pass:hola Esa es la ultima version, parcheado algun bug que tenia por Parasito. Abremos el OLLYDBG protegido con los plugins para ocultarlo, y lleguemos al OEP con el metodo el PUSHAD.

Vemos que aquí nos avisa que el entry point esta fuera de la seccion code como es lo usual, en la mayoria de los packers.

Ahi vemos el PUSHAD inicial al cual pasamos con f7 y luego hacemos.

ESP-FOLLOW IN DUMP para colocar un Hardware Breakpoint on accesss en los valores de los registros que guardo con el PUSHAD en el DUMP.

Luego apeto F9 con lo cual doy RUN

Con lo cual para justo despues del POPAD que restaura los valores guardados a los registros, traceo hasta llegar al OEP con f7.

Como veo que no se entiende el codigo, le quito el analisis.

vemos que si lo vuelvo a analizar mejora aun mas.

uego procedere al dumpeado voy al menu PLUGINS y alli busco el OLLYDUMP

Y

L

Nos aparece la ventana del plugin, en la cual ya vemos las cositas que podemos modificar, ya ahi podemos arreglar lo de la base of code, sin tener que luego cambiarlo en el header, en la ventana vemos base of code 4000, pero si recordamos este aspack corria en esta seccion que no es la primera, por lo cual le dejamos la base of code en 4000 que corresponde a 404000 que es la seccion donde esta el OEP y corre el programa. Otro de los temas es la tilde de REBUILD IMPORT que esta abajo, el OLLYDUMP trata de hacer el trabajo del IMP REC para lo cual tiene dos opciones METHOD1 y METHOD2, que en algun packer sencillo puede funcionar, el que quiere a veces ganar tiempo, puede hacer un dumpeado con cada uno de estos metodos y ver si alguno funciona, aunque no es muy certero, pero alguna vez puede funcionar. Nosotros le quitaremos la tilde en REBUILD IMPORT ya que lo haremos con el IMP REC que es mas confiable.

Bueno ahora podemos dumpear a ver que tal nos va.

Pues alli esta el dumpeado si lo ejecuto sin reparar la iat o bien correra solo en mi maquina con mucha suerte, o bien dara error veamos.

Bueno sin cerrar el archivo empacado que esta detenido en el OEP abrimos el IMP REC y elegimos dicho proceso en la lista del menu desplegable.

Volvemos al OLLYDBG para hallar los valores de INICIO DE IAT, LARGO y el OEP. OEP es 404000 o sea que en el IMP REC ya que le debemos restar la imagebase que es 400000, quedara 4000. Buscaremos el inicio y final de la iat como vimos para ellos hay que buscar una llamada a una api, justo abajo del oep esta la llamada a GetModulehandleA.

Si marco dicha linea y hago click derecho-FOLLOW

Veo que va directamente a la api sin JMPS INDIRECTOS intermedios por lo menos en esta llamada , (ya que si buscamos veremos que si hay JMPS INDIRECTOS lo que pasa es que no siempre los usa como en este caso) Quiere decir aquí usa un CALL INDIRECTO, para saltar a la api, por lo cual es facil deducir que lee la direccion de la API directamente de la IAT para saltar a la misma correctamente.

Bueno es facil de ver que 4011F4 es una entrada de la IAT donde guarda la direccion de la API, GetModuleHandleA. El que gusta de ver los JMPS INDIRECTOS, buscando con FF 25 tambien los hallara.

Y llegara al mismo resultado ya que el JMP a GetModulehandleA lee valores de la misma entrada de la IAT. Vayamos en el DUMP a mirar dicha entrada y la IAT en general.

Alli vemos todas las entradas que son compañeras de la que miramos inicialmente, todas van a la seccion code de la misma dll, miremos en VIEW-M a que dll corresponden.

Todas caen dentro de dicha seccion, por lo cual vemos que son las entradas que corresponden a Kernel32.dll ya que apuntan a su seccion CODE. Alli mismo podemos ver el final de la IAT ya que debajo de 401218 no hay mas nada, asi que el final de la iat es 401218, ahora nos queda hallar el inicio.

Vemos la separacion de ceros y antes otro grupo de entradas.

Que son exactamente estas entradas, vemos que en las direcciones adonde apuntan (10xx o 11xx) no hay dlls ni nada ya que la mas baja direccion en el mapa de memoria es 10000.

Asi que estas entradas ya que no van ni a una dll, ni a una seccion real, ya que podrian apuntar a alguna seccion creada por el packer, lo cual no es este caso, son basura metida para molestar ya veremos lo que hacemos con ellas, ahora sigamos subiendo.

Vemos que entre ceros hay otro grupo de entradas que apuntan a direcciones 77Dxxxxx veamos en el mapa de memoria a que dll pertenecen.

Vemos que pertenecen a la User32.dll Tambien vemos que hay mas dlls en el mapa de memoria como GDI32 y Ntdll las cuales pueden haber sido cargadas por el packer para su uso, y no la usa el programa, para verificar esto, hagamos en el mismo listado SEARCH FOR – ALL INTERMODULAR CALLS.

Vemos que hay llamadas a 3 dll, las dos que hallamos y falta arreglar la Ntdll ya que hay llamados a la misma, veamos. Si vamos a los calls de esas dll por ejemplo.

Vemos que la entrada esta en 401200 o sea que esta mezclada con las de kernel32.dll

Lo mismo la os cuenta por la proxim

IAT, es el que abarca

todas las entradas as

El inicio de la Ia

Ve

ARGO= FINAL MENOS INICIO= 401218-40119c = 7C

ongamos estos valores en el IMP REC a ver que pasa, veamos que paso con las dos entradas que estaban mezcladas de la ntdll con las de kernel32.

otra de dicha dll esta tambien mezclada con las de kernel32.dll no nos dimidad de las secciones code de ambas pero es asi.

Bueno vemos algunos problemas en esto de cualquier forma el inicio de la i que

t es 40119C lo que concuerda con el menor valor hallado en la tabla de saltos.

mos que es el mas pequeño de todos estos valores, asi que ya tenemos

OEP=4000 RVA o INICIO DE LA IAT=119C L

P

emos la parte que dice NO que c os que solo tiene entradas para kernel32, si m correspondian a 401200 y 401210, vemos que

La reemplazo por las sim

emo s de kernel32.dll y seguro cambiadas por el packer para m

s que esas entradas que dicen NO

Marco la prim

V orresponde a las entradas basura, y abajo vem

iramos las entradas raras que

ilares correspondientes a kernel32.dll y nos dijo algo de esto?

V s que si que nos aviso en el log que esas entradas son similares a la

olestar y complicar las cosas.

Bueno entonces solo tenemos que quitar la basura de en medio ya que verificamo, son basura, para verificarlo aquí vayamos a una de ellas.

era y hago click derecho- DISASSEMBLE-HEX VIEW

lli vemos que no cae en ningun lugar que exista, asi que marcamos todas las entradas basura.

pretando SHOW INVALID y alli las tenemos a todas marcadas ahora hacemos click derecho

A

ACUT THUNKS.

Con lo cual las anulamos a todas esas entradas para que al arrancar el sistema no de error tratando de arrancar apis inexistentes. Ahora si, apreto FIX DUMP ya que tengo todas las entradas marcadas como YES o sea validas.

y me crea el dumpaspack_.exe el archivo que supuestamente ya estaria reparado, veamos ejecutemoslo.

Y si funciona perfectamente por lo cual terminamos con el segundo packer para ir aumentando la

dificultad progresivamente y muy levemente. Hasta la parte 36 con otro packer Ricardo Narvaja.

INTRODUCCION AL CRACKING EN OLLYDBG PARTE 36 Seguimos aumentando muy suavemente la dificultad en los packers que vamos viendo, en esta entrega veremos dos desempacados, el crunch o bitarts 5.0 y el telock 0.98, que nos servira para introducirlos en el tema de las entradas de la IAT redireccionadas, ambos unpackmes estan adjuntos a este tutorial, por lo que no hay problemas para obtenerlos. Empezaremos con el mas sencillo con el BITARTS lo arrancamos en OLLYDBG.

Vemos que no hay un PUSHAD inicial, asi que traceemos un poco con f7.

Vemos que ahi llega a un PUSHAD asi que pasemoslo con f7 y hagamos ESP- FOLLOW IN DUMP.

Y pongo un Hardware Breakpoint on access en los primeros bytes.

Ahora apreto f9 y despues que pasa alguna que otra excepcion, para por el Hardware Breakpoint.

Traceo unas lineas y llego al OEP.

Al OEP se puede llegar tanto usando el buscador de OEPs de OLLYDBG, el OLLYDBG parcheado para OEPs o casi cualquiera de los metodos que vimos en las partes anteriores de la introduccion. Como vemos dicha direccion esta en la primera seccion despues del header

Por lo cual la cosa parece bien ordenada, incluso esta marcada como seccion CODE asi que no habra problemas

Vemos que en este caso la primera API que llama es GetVersion por lo cual tambien poner un BP en dicha api y cuando para en ella, llamada desde primera seccion, al retornar de la misma, nos hubiera dejado, en la zona del OEP. Bueno el OEP no tiene misterios, miremos un poco la IAT, por supuesto alli a la vista tenemos una llamada directa a una api, por lo cual es facil ver que el CALL INDIRECTO, toma el valor correcto en mi maquina de la api GetVersion, para dirigirse a la misma. Por lo tanto 460ADC es una entrada de la IAT, la correspondiente a GetVersion, vayamos en el dump a verificar la IAT.

Lo que si se ve bien larga jeje, verifiquemos a ver donde van las entradas.

La primera entrada que nos llevo a la IAT era de GetVersion que pertenece a Kernel32.dll, podemos mirar en el mapa de memoria donde cae dicha direccion 7Cxxxxxx.

Vemos que todas corresponden a la Kernel32.dll, por ahi en el medio hay como en la parte anterior

mezcladas un par correspondientes a la ntdll, pero ya verificamos que el sistema hace una excepcionpara esas apis, que originalmente eran de kernel32.dll y como fueron reemplazadas por apis similares de ntdll.dll, pues por compatibilidad, las acepta como si fueran de la kernel32.dll siproblemas, en cualquier otro caso que el sistema no tenga este tipo de excepciones que son muy pocas realmente (creo que las unicas), las apis deben ir ordenadas por dll, y separadas por ceros clos de otra dll, en una IAT correcta.

n hacer

on

ueno despues de la separacion vienen hacia abajo un grupo de apis de direcciones del tipo

i uno tiene alguna duda de alguna entrada a que dll pertenece, ademas de ir al mapa de memoria y

on lo cual buscara en el listado, todas las instrucciones que utilizan dicha entrada, en este

nde

ebo

lli vemos los CALLs que existen en la priumera seccion correspondientes a dicha entrada. La cual

B77xxxxxx. Sfijarse, puede marcarla en la IAT y hacer click derecho-FIND REFERENCES.

Ccaso.(esto funcionara siempre y cuando el listado este mostrando la seccion del programa dotrabaja el mismo, en este caso la primera seccion, si busco referencias, y el listado lo tengo mostrando otra seccion diferente, buscara en ella, y probablemente no hallara nada, asi que dverificar antes de usar este metodo, estar en la seccion correcta donde el programa corre ya desempacado, o la zona del oep, que es lo mismo)

Apertenece a la api VariantClear de la OleAut32.dll.

Mirando en el mapa de memoria, vemos que por supuesto el grupo siguiente cae en la seccion code de la OleAut32.dll, como corresponde.

Si seguimos bajando sin especificar cada dll, vemos grupos de entradas contiguas que van a otras dll, separacion con ceros, otro grupo, otra separacion y asi, seguimos bajando hasta ver donde acaba este esquema para encontrar el final de la iat ya que no se ven ceros donde termina.

Alli vemos la parte final donde se termina este esquema, vemos en celeste un grupo de apis, correspondientes a una dll, luego la separacion, luego en rosado otro grupo de apis, la separacion y vemos una entrada marcada con una flecha y otra separacion, luego de la cual ya no se mantiene el mismo esquema, podemos verificar si esta api de la flecha pertenece a la IAT, pues fijemosnos si va a alguna dll con los dos metodos.

Vemos que es una entrada de la IAT pues nos lleva a una api en este caso OleUiBusyA de la oledlg.dll, si verifico mirando el mapa de memoria.

Vemos que logicamente cae en la seccion CODE de dicha dll, por lo cual es una entrada de la IAT, la unica de esta dll, luego de eso, viene la separacion, y luego vienen grupos de numeros sueltos que no estan agrupados para ir a direcciones contiguas, ni sus direcciones apuntan a ninguna dll.

Si marcamos cualquiera de ellos, y hacemos FIND REFERENCES.

No hay resultados, que nos lleven a apis, por lo cual podemos deducir ya que mas abajo no encontramos mas entradas que nos lleven a apis, que aquí se termino la IAT por lo tanto el final de la misma es FINAL: 460F28

Ahora hagamos lo mismo hacia arriba verificando donde comienza el esquema de la IAT.

Vemos que el esquema se va repitiendo hacia arriba hasta que llegamos aquí, en celeste estan marcadas las separaciones, el grupo marcado en amarillo es el que visualmente reconozco como un grupo ordenado que va a una dll, luego hay una separacion y una entrada que va a 8000008, como no se si no corresponde a alguna entrada suelta de alguna dll, verifico haciendo FIND REFERENCES.

EP= 271B0

ARGO= 710

ueno hacemos el dumpeado con el OLLYDMP.

No hay resultados que vayan a apis, ni en esa entrada, ni en ninguna superior por lo cual, podemos asegurar que la primera entrada es 460818.

por lo tanto ya tenemos el INICIO y FINAL de la IAT, hallamos el largo.

FINAL-INICIO= 460F28 – 460818

o sea que el largo es 710

recopilando para el IMP REC (le restamos ya la imagebase 400000 al OEP y INICIO)

OINICIO o RVA= 60818 L B

Le quitam

Luego abramos el IMP REC sin cerrar el OLLYDBG, con el original detenido en el OEP.

os la tilde a Rebuild Import y dumpeamos.

Buscam

Y apretamos GET IMPORTS

Vemoapretamo

Lo guardo al reparado con el nombre unpacked_.exe, probemoslo a ver si funciona.

os el proceso en el menu desplegable y le colocamos los valores hallados.

s que el packer no hace mucho por molestarnos todas las dlls estan correctas asi que s FIX DUMP y buscamos el dumpeado para que lo repare.

Funciona perfectamente, por lo cual no tiene antidumps, los cuales seguramente encontraremos mas delante en packers mas complejos.

La proxima victim de las entradas de la IAT redireccionadas.

os un poco a ver si hay algun PUSHAD.

asemoslo con f7, luego marcamos ESP-FOLLOW IN DUMP.

a

a es el telock 0.98 que nos servira para empezar el tema

ribemos el metodo del pushad, traceemP

P

Quitem

Vemos que el m RDWARE BREAKPOIcoloque.

Y reincio el OLLYDBG.

os el analisis a si se ve el codigo.

etodo del pushad no funciona y que ademas esta protegido contra HANTS porque si lo sigo corriendo da error, asi que quito el hardware breakpoint que

Pues ese metodo no va, probem pio el LOG y lo hago correr al programa para que me

Pues quitemo pescar la de 4666f1 que es la ultima del desempacador.

Pues luego de pasar varias excepciones con SHIFT mas f9 llegamos a 4666f1.

os con el de las excepciones, lim liste las excepciones que pasa.

s las tildes de las excepciones y reiniciemos tratando de

Pongamos ahora un ME era seccion.

ecordemos que debemos apretar SHIFT mas f9 para pasar la excepcion que estamos parados si no dara error, lo hacemos.

era seccion donde para por MEMORY BRE

Por lo tanto el oep es 4271B0, el m UNCH, por lo cual parece ser el mism o si no supieramos nada de el. Bueno en el ejem sta iba a la api GeVersion, pero en este caso no es asi, aq

i hago

MORY BREAKPOINT ON ACCESS en la prim

R

Bueno para en un par de excepciones del tipo SINGLE STEP y llega al OEP en la primAKPOINT ON EXECUTION.

ismo que el del ejemplo anterior de CRo programa empacado con otro packer, igual lo trataremos com

plo anterior sabiamos que ese call que esta a la viuí comienza el tema de entradas redireccionadas jeje.

S

ay muchismos Calls indirectos que en vez de dirigirse a una api de una dll, van en este aso una seccion 9fxxxx en mi maquina, pero que en su maquina puede variar y ser otra direccion

parecida.. Si miro mas abajo en esta lista

para ver los CALLs que se dirigen a otras secciones, intentando ver si hay calls a alguna api.

Veo que hc

Vemo dio de

Alli tenemmarque

4 es una entrada de la IAT, vayamos en el DUMP a verla.

s que hay algunos CALLS directos que nos marca que van a apis, seguramente por meun JMP INDIRECTO, vayamos a ver alguno de estos CALLS.

os uno, es un CALL 435CDE que ira seguro a los JMPS INDIRECTOS a las apis, moslo y hagamos click derecho- FOLLOW.

Alli vemos los saltos indirectos a las apis, por lo tanto sabemos que toman valores de la IAT, o sea que 460ED

Vemode la IAT aq piezan todos ceros, ahora subam

Ve

emos que pertenece a la api PlaySoundA de la WINMM.dll de alli para arriba, no encuentro mas alores que vayan a dlls, pero si busco referencias.

s que la parte final de la IAT es correcta y coincide con la del ejemplo de CRUNCH, el final uí tambien es 460F28, es facil detectarlo pues aquí si termina la IAT y em

os.

mos ya, que el proximo grupo esta conflictuado, la primera entrada arriba de la separacion corresponde a 76B1A8F7 si la marco y hago click derecho-FIND REFERENCES.

Vv

rama salta a las apis de las dlls, por medio de la IAT, fuera de la misma ya

que hallamsalta a una s o es esto?

agen anterior

Comment= En vez de gu plaza dicha

a debajo del

EP.

Realmente no sabemos que va a GetVersion, solo porque el ejemplo anterior era un programa similar pero empacado con CRUNCH lo sabemos, pero realmente hasta aquí, para nosotros es un CALL INDIRECTO, lleguemos hasata el con f7 y entremos en el a ver donde va.

Veo que si existen referencias, por lo cual aquí hay un punto, cuando llegabamos subiendo y bajando al inicio de la IAT si buscabamos arriba del inicio, por ejemplo, no encontrabamos ninguna eferencia, pues el progr

no encontramos ninguna referencia, ahora aquí vemos que estas son posibles entradas de la IAT, ya os referencias que toman valores de ellas en el codigo, pero, en vez de saltar a las dlls, eccion que en mi caso, esta en Axxxxx o puede variar según cada maquina, com

Pues esto es lo que se llaman entradas redireccionadas, el desempacador al ejecutarse, sobrescribe algunas de las entradas a la IAT con valores que apuntan a rutinas propias, en el caso de la im

004038A6 CALL DWORD PTR DS:[460E48]

DS:[00460E48]=00A00B61

ardar la direccion correcta de la api en mi maquina, el desempacador reemdireccion por una direccion de una seccion propia creada por el, en tiempo de ejecucion, y alli pone una rutina que al final termina yendo a la api correcta.

Para aclarar un poco veamos la entrada a GetVersion que esta en el inicio del programO

Vemos que para ver donde va toma el valor de lo que aun no sabemos con certeza, pero son osibles entradas de la IAT ya que mas abajo vemos entradas correctas a apis.

tanto el programa al ejecutar ese CALL va aquí que en mi maquina a la direccion 9F06F7, en

p

Por lo las suyas puede cambiar.

Esta direccion no pertenece a las secciones del programa en si.

lli vemo bre donde esta bicada la rutina donde salta el programa, fuera de las secciones del mismo.

creada por el programa mientras se va desempacando, ahora, podemos

ues podemos poner un BP VirtualAlloc que es la api encaragada de crear secciones virtuales y bicarlas.

Ahora demos RUN y si pongo todas las tildes en exceptions vemos que el programa no corre y se termina, por lo cual es obvio que detecta el BP que acabo de poner, probemos ponerlo en el RET de la api.

A s las secciones del programa en celeste y mas abajo una seccion sin nomu Si reiniciamos el programa vemos que esa seccion no existe al inicio.

or lo tanto vemos que fueP

verificar el momento en que dicha seccion es creada? Pu

Vemo

o ayuda que cuando el programa crea secciones las que usara, son marcadas como PRIV PRIVADAS, ma as secciones no estaban en el inicio, antes de

desemp mpacar.

or lo tanto quitamos el BP y llegamos al OEP, como anteriormente, quitando las tildes de las o

Ahora doy RUN

Como para en el retorno de la api, la misma devuelve en EAX la direccion base de la seccion creada en este caso paro, y creo una seccion en 3c0000, sigamos.

s que va creando secciones las cuales podemos ver en el mapa de memoria

Vemos como s la ayuda que significa ver que es

acar, pues, sabemos con certeza que son secciones creadas al dese

Pexcepciones y llegando a la ultima, poniendo un BPM ON ACCESS en la primera seccion, saltandla ultima con SHIFT mas F9.

Alli llegamos nuevamente al OEP y si vemos el el mapa de memoria

Vemos secciones creadas que van a se das como PRIV y alli se dirige el call ese indirecto al cual volvemo

emos que llega aquí a un PUSH que pone la direccion de GetVersion en el stack, y luego salta a la

sea que el desempacador reemplazo la entrada de la api GetVersion, con una direccion que apunta a una seccion propia o creada por el y no a una dll, y que si traceamos al final del cuentas nos lleva a la api correcta.

r utilizadas, estan marcas a entrar traceando con f7.

Pues traceemos a ver donde llega esta rutina

Vapi al llegar al RET, por lo cual esta rutina es como un intermediario para llegar a la api GetVersion. O

Pues esta es la definicion de una entrada redireccionada, exactamente. Por lo tanto cuando verificamos el inicio y final de la IAT no solo debemos verificar que una entrada vaya a una dll, si no tambien debemos aceptar como entradas de la IAT, aquellas que tienen referencias y que nos llevan a un codigo propio del packer, que resulta ser un intermediario para llegar a la api finalmente. Por lo cual volvamos a la IAT como estabamos mirando para hallar el INICIO y FINAL.

Todas esas entradas que van a van a codigo creado por el desem sde el OEP no existiria, por lo cual sigam

la seccion 0Axxxxxx en mi maquina son entradas redireccionadas, pacador, que si el programa arrancara de

os subiendo para ver si hallamos el INICIO de la IAT.

Vemoseccion 9Fx

Ademas comprobando, vemos que dichas entradas tienen referencias, por lo cual, son entradas de la IAT, sigamos subiendo.

s que luego hay algunas entradas que van a dlls, y luego mas arriba entradas que van a la xxx otra seccion creada por el desempacador.

Luego vemos entradas que en mi maquina van a A1xxxx que es otra seccion creada por el packer

y que ademas

or lo cual son entradas de la IAT y si sigo subiendo veo que ya llego a

Donde hay entradas que van a una dll, luego la separacion y luego mas arriba ninguna entrada tiene referencias.

si busco tienen referencias.

P

Comola image base. OEP= 271B0INICIO o RVA= LARGO= 710 Por lo tant

Como vemos el IMP REC detecta que hay entradas redireccionadas y nos pone NO en algunas, miremoslas apretando SHOW INVALIDS que nos mostrara las invalidas.

en el CRUNCH el inicio de la IAT es 460818 el largo 710 y el OEP es 4271B0, restandole

60818

o abramos el IMP REC sin cerrar este OLLYDBG.

Y coloquemosle los valores que hallamos.

Ahora apreto GET IMPORTS

emos que el IMP REC nos muestra lo mismo que vimos en la IAT entradas que no van a ninguna

vamos a tracear todas esas entradas incorrectas a mano, hay varios metodos para ae algunas posibilidades, otros metodos pueden hacerse a mano pero no

todos los veremos en la parte 37, para que tengan bien claro el tema de las apis e vemos metodos para repararlas.

choto y eso debem Hasta la paRicardo Narvaja 7/03/06

Vapi, y que van alli en la imagen, a direcciones de secciones creadas por el packer o codigo propio del mismo. Por supuesto norepararlas, el IMP REC trtraceando jeje

odos estos meTredireccionadas repasen bien esta parte, asi en la parte siguient

emos que asi como esta, no podemos reparar un dumpeado, pues debe tener el IMP REC todo VYES o sea todas las entradas deben apuntar a apis de dlls, y no a entradas redireccionadas ni codigo

os arreglarlo nosotros.

rte 37

1

INTRODUCCION AL CRACKING CON OLLYDBG PARTE 37 En esta parte veremos algunos de los posibles metodos para reparar entradas redireccionadas, pero el tema no se agotara aquí, porque al igual que para llegar al OEP, hay tantos metodos como packers existen, y cuando veamos algunos otros packers saldran metodos nuevos tanto para llegar al OEP como para reparar la IAT. El tema es que estos metodos son ideas generales, y en otros packers pueden funcionar o no, o quizas necesitan cierta adaptacion según el caso, por lo cual es bueno siempre intentar y practicar mucho, e ir variando y probando. De la misma forma que cuando vimos como llegar al OEP, daremos los metodos mas generales, y mas adelante cuando veamos distintos packers, adaptaremos estos metodos o usaremos alguno nuevo según el caso, que quizas no este aquí al no ser muy general.

Bueno aquí estamos en el OEP del telock que como vimos la parte anterior tiene entradas redireccionadas a varias secciones que fueron creadas por el mismo packer en tiempo de desempacado.

Ahi teniamos una vista de la IAT con sus entradas para reparar, realmente hay packers que redireccionan uno a dos entradas, por lo cual siempre es bueno conocer metodos para reparar una

sola entrada, que es lo que veremos al inicio, obviamente si son muchas entradas a reparar esto no sirve, porque te volves viejo, pero hay que saber como detectar que api corresponde a cada entrada, a veces para verificar alguna entrada que es dudosa. Tomemos la entrada que manualmente habiamos traceado y sabiamos que finalmente va a GetVersion.

Alli esta el CALL y en el DUMP, la entrada de la IAT 460ADC con su contenido que apunta en mi maquina a 9F06F7, tambien tenemos el IMP REC abierto con todos los valores que hallamos a mano, de RVA, SIZE y OEP escritos, y a la vista las entradas malas.

Pongamos el IMP REC tambien para ver esa entrada

60ADC corresponde a la entrada de la IAT 460ADC. Volvamos al OLLYDBG y a nuestra entrada, ya vimos que traceando a mano llegamos a una api, sabemos que el OLLYDBG trae un traceador incorporado, vamos a usarlo para llegar mas rapido, ya que aquí fueron 5 o 6 lineas que traceamos y ya llegamos a la api, pero hay packers que dan vueltas y vueltas antes de llegar a la misma, por lo cual el traceo automatico suele ser util.

Ponemos antes de tracear un BP en el retorno de la api, no sea cosa que nos equivoquemos y quede traceando sin parar nunca.

En DEBUG-SET CONDITION tenemos la posibilidad de elegir las opciones en las cuales el OLLYDBG detendra el traceo.

Alli vemos la ventana de CONDICIONES PARA PAUSAR EL TRACEO, veremos algunas que pueden funcionar y se pueden adaptar según el caso. EIP IS IN RANGE significa que si ponemos la tilde en este renglon, OLLYDBG parara cuando el EIP se encuentre dentro del rango de valores que especifiquemos en la derecha, por ejemplo.

Este ejemplo significa que OLLYDBG traceara hasta que vea que EIP vale algun valor comprendido entre 401000 y 500000 por supuesto esto es un ejemplo, y no nos sirve en este caso, ya que queremos que se detenga en la api. Para hallar los valores entre los cuales queremos que OLLYDBG se detenga en este caso miramos

el mapa de memoria.

lli vemos marcado en celeste la zona que nos interesaria que se detenga OLLYDBG al tracear, o A

sea desde donde se encuentra la primera dll en adelante, no queremos que pare ni en las secciones del exe, ni en las secciones creadas por el packer ya que ese es codigo intermedio, necesitamos que pare en las dlls, por lo tanto si marcamos la primera casilla y ponemos que EIP este entre 58000000 y 7FFFFFFF que es la direccion maxima seguro que parara en alguna dll (aclaracion no importa que no elegimos la direccion exacta de la primera dll ya que vemos que no hay codigo entre 58000000 y el inicio de la primera dll 58c30000 asi que alli no va a parar, pero para evitar poner cifras exactas puedo sin problemas redondear)

Quiere decir entonces que OLLYDBG ejecutara traceando linea a linea y en cada una verificara que se cumpla esa condicion, o sea que EIP este en la seccion de alguna dll y si es asi parara.

Lleguemos hasta el CALL poniendo un BP en el mismo.

Si teniamos puesto un MEMORY BREAKPOINT que usamos para llegar al OEP lo quitamos y llegamos al CALL. Alternativamente si no es un CALL que esta al inicio y no sabemos donde esta el CALL O JMP, podemos marcar los bytes de la entrada y poner un MEMORY BREAKPOINT ON ACCESS en la misma, con los cual al dar RUN, parara cuando lea la entrada o sea en el JMP o CALL correspondiente.

Bueno ya llegamos al CALL con alguno de esos dos metodos.

Pongamos a tracear al OLLYDBG

Es importante elegir TRACE INTO para que tracee linea a linea, si elegimos TRACE OVER no entrara en los calls y puede fallar.

Alli paro por la condicion que colocamos si vemos en OLLYDBG abajo

Paro porque EIP esta en el rango 58000000-7FFFFFFF, es bueno verificar esto para ver que no haya parado por alguna excepcion u otro motivo.

Lo siguiente que hay que verificar es que al ejecutar la api vuelva al programa a continuacion del CALL, porque hay packers que para confundir van primero a una api, y a continuacion a una segunda api, por lo tanto la api verdadera sera la ultima, y en la cual veamos en el valor de retorno de la misma, que retorna al programa a al instrucción siguiente al CALL. Por supuesto en este caso, retorna a la linea siguiente del CALL de donde partimos.

Vuelve a 4271DC como corresponde. Bueno ahora nos falta ver que api es porque OLLYDBG no nos dice nada, la primera forma es analizar el codigo aquí mismo de la dll.

lli vemos justo abajo en la aclaracion que OLLYDBG nos muestra el nombre de la api lo mismo

tra condiciones posibles para el traceo desde el CALL para llegar hasta la api son:

Aque al lado del valor de EIP.

O

Este caso es la inversa del anterior OLLYDBG chequea que EIP este fuera del rango de las secciones del exe, y las secciones que hay antes de la primera dll. Otra posibilidad

Para algun caso raro que el packer cree secciones mezcladas entre las dlls, puede utilizarse un metodo combinado como este que parara cuando halle un RET y ademas cuando la primera linea del stack sea 4271DC que es el retorno de la api. Este metodo apunta a parar en el retorno de la api, y muchas veces es efectivo sobre todo en packers que emulan las primeras lineas de la api y saltan a la tercera o cuarta linea de la misma, generalmente el RET siempre es respetado y parara en el

mismo, si reinicio el OLLYDBG y llego de nuevo al call puedo probarlo rapidamente. O sea aquí se deben cumplir dos condiciones a la vez, que estan unidas por && lo cual asegura que

i fuera que quisiera que se detenga cuando alguna de las dos condiciones solas se cumpla, en ese

sea que

sean las dos condiciones las que se cumplan && equivale a Y. Scaso usaria || que equivale a O. O [ESP]==4271dc && byte [eip]==0C3

ignifica que se cumplan ambas condiciones a la vez, o sea

SP]==4271dc (que la primera linea del stack sea el punto de retorno esperado de la api)

yte [eip]==0C3 (y que el contenido de EIP o sea el byte que se esta ejecutando sea un RET o

i desde el CALL lanzamos a tracear con esa condicion, vemos que para en el RET de la api.

l dispararse ambas condiciones a la vez, se detiene el traceo.. bre de la api que ejecuto, pues no

s [E bsea C3) S

AAhora que estamos en el RET, se nos complica saber el nomestamos en el inicio de la misma, lo mismo nos ocurre cuando el packer simula las dos o tres primeras lineaas de la api y estamos en la 4ta o 5ta linea de la misma, aquí OLLYDBG no nos muestra el nombre aunque hay varios recursos para hallarlo.

eremos en el listado de lo que traceo, para ello vamos al boton con los tres puntitos. V

Vemos obviamente que la primera linea que traceo en la dll es la marcada por la flecha, aunque no nos muestra el nombre de la api, asi que hagamos analisis del codigo, y luego hagamos doble click en esta linea que marca la flecha.

Vemos que OLLYDBG nos muestra cuanto valian los registros en ese momento, por eso se ponen en gris ya que no son los valores actuales, y ademas nos muestra la informacion como si estuvieramos ejecutando esa linea, entre lo cual podemos ver el nombre de la api, lo mismo ocurriria si luego de un traceo vamos apretando la tecla menos, OLLYDBG ira hacia atrás mostrando la informacion y los valores que guardo al pasar por cada instrucción. En el caso de packers que emulan las dos o tres primeras lineas de la api y al tracear caemos por la cuarta o quinta linea, el traceador no pasara por la primera linea pues ellas son emuladas por el packer, por lo cual a veces hay que arreglarse un poco a ojo, pero un metodo casero que no falla es hacer lo siguiente jeje (perdon por lo berreta pero la verdad que sirve) En cualquier parte vacia abajo del ret escribimos con assemble, o apretando la barra espaciadora, un CALL a la linea que sospechamos es el inicio de la api visualmente, en este caso CALL 7C8114ab Parece el inicio de la api en mi maquina, en la suya ponen la direccion donde les parece visualmente que puede comenzar la api.

Al aceptar, si es el inicio de una api, OLLYDBG nos mostrara el nombre, si nos equivocamos podemos repetir con.

Y asi en la zona alrededor de donde parece que se inicia la api, hasta que OLLYDBG nos de el nombre aunque es generalmente bastante facil darse cuenta de donde se inicia, por los corchetes que pone OLLYDBG al analizar, alli vemos que el corchete empieza en el inicio de la api.

Quitamos lo que escribimos con UNDO SELECTION

Bueno ya sabemos detectar a mano el nombre de la api, una vez que lo tenemos vamos al IMP REC

y hacemos doble click en la entrada mala que estamos reparando y ponemos el nombre bueno.

hora si apretamos SHOW INVALID vemos que dicha entrada ya es tomada como correcta lo cual

en el OLLYDBG en dicha entrada, la direccion de la api

lli esta la e reccion hallada de la

Aes un gran beneplacito para nosotros jeje. Otra forma de reparar la entrada es escribircorrecta en nuestra maquina.

A ntrada que estamos investigando 460aDC, le sobrescribimos la diapi en nuestra maquina, habiamos hallado que la api GetVersion comenzaba en mi maquina en 7C8114AB, pues escribimos dicha direccion en la entrada.

lli vemos la entrada reparada ahora si en el IMP REC limpiamos todas las entradas apretando el

omo vemos es similar colocar la direccion correcta de la api en la entrada correspondiente

Aboton CLEAR IMPORTS y de nuevo apretamos GET IMPORTS veremos que ahora la entrada esta tomada como valida.

Cdirectamente en la IAT en el OLLYDBG o en el IMP REC colocar el nombre de la API en dicha entrada.

Bueno si hacemos eso en cada entrada redireccionada, y las reparamos una a una, y luego rreglamos el dumpeado, funcionara, el tema es que es un metodo muy tedioso, aunque es bueno

l IMP REC permite guardar la tabla on las reparaciones que le hayamos hecho con el boton SAVE TREE y luego si interrumpimos el

tra forma posible de reparar las entradas redireccionadas es usando plugins del IMP REC, en este aso si vamos a la carpeta

s.org/HERRAMIENTAS/L-M-N-O-P/Plugin_Import/

aconocerlo para verificar alguna entrada a mano si esta dudosa. Algo que ayuda a los fanaticos de este metodo manual es que ectrabajo podemos volver al OEP del programa, abrir el IMP REC y una vez puestos los datos del OEP; RVA Y SIZE, cargar la IAT que habiamos guardado en el estado que la dejamos con el boton LOAD TREE.

Oc http://www.ricnar456.dyndn Vemos que hay un plugin para telock el cual puede ser copiado a la carpeta plugins del IMP REC

eamos si funciona este metodo.

Copiam

v

os la dll a la carpeta PLUGIN del IMP REC.

Ahora deberemos reiniciar el IMP REC y una vez que volvemos a ingresar todos los datos, apretamos SHOW INVALID, hacemos click derecho PLUGIN TRACERS y buscamos el del telock, luego de tracear vemos que arregla todas las entradas menos 4, por lo cual vemos la importancia de la reparacion manual ya que el plugin dejo pocas entradas para reparar y estas pueden hacerse a mano.

Alli vemos que el IMP REC nos avisa que quedan 4 por reparar, las cuales podemos tracear a mano con el metodo que vimos al inicio, de cualquier manera, el metodo del plugin es muy limitado ya que dependemos que exista un plugin para el packer que estamos usando lo cual es dificil. El IMP REC posee otros trazadores genericos que en vez de usar los del plugin, se puede intentar a ver si funciona, aunque recomiendo guardar lo reparado hasta ahora, porque la mayoria de las veces terminan en cuelgues del IMP REC.

Marcando una entrada invalida y haciendo CLICK DERECHO vemos tres niveles de traceo, probemos a ver que pasa primero con el de NIVEL 1.

Fallo, probemos con los otros dos, ya con el segundo se colgo el IMP REC, por lo cual a pesar de mencionar estos metodos para otros casos, aquí no funcionan, y generalmente terminan en cuelgues solo sirven para packers muy sencillos. El proximo metodo es el del JMP-CALL MAGICO que hicimos popular en crackslatinos en tantos tutes de diferentes packers. El metodo se basa en tratar de buscar el momento en el que el packer guarda los valores en la IAT, y alli observar un poco y comparar lo que ocurre cuando guarda un valor malo, con lo que ocurre cuando guarda un valor bueno. Usemos como ejemplo la entrada esta que investigamos de GetVersion que es una entrada redireccionada o mala, reiniciemos el crackme empacado con telock, y busquemos dicha entrada al inicio antes de arrancar el programa.

Alli esta en el DUMP la direccion 460ADC que al correr el crackme y antes de llegar al OEP, en algun momento se escribira alli el valor malo de la entrada redireccionada que en mi maquina era 9F06F7, quiere decir que en algun momento el packer escribira ese valor en la entrada.

Para interceptar el moemnto en que escribe dicho valor generalmente se coloca al inicio un HARDWARE BPX ON WRITE en la entrada, pero como este packer detecta los HARDWARE BPX, colocaremos un MEMORY BREAKPOINT ON WRITE, para que pare al escribir el valor malo.

Al dar RUN la primera vez que para por MEMORY BREAKPOINT es aquí

Vemos que no es el lugar buscado porque al ejecutar la linea con F8 no guarda el valor malo en la entrada, asi que damos RUN nuevamente. La proxima vez que para es aquí

Vemos que tampoco guarda el valor malo en la entrada damos RUN de nuevo.

Tampoco luego de pasarla con F8 la entrada sigue con otros valores.

Seguimos buscando el punto donde guarda el valor malo, vemos que va parando pero nunca guarda el valor buscado.

Al pasar el ultimo REP MOVS la IAT quedo con estos valores y aun no tiene el valor malo definitivo, sigamos dando RUN.

Hasta que llega aquí que vemos que ECX tiene el valor malo y lo guardara en la entrada.

ECX es 9F06F7 y lo guardara en el contenido de EAX o sea en 460ADC en la entrada que estamos investigando, este es el punto donde queriamos llegar.

Vemos que al apretar F8 guardo el valor malo, este es el primer paso que debemos hacer cuando utilizamos este metodo, ahora viene la parte mas trabajosa que es hallar el salto magico.

Como vemos al llegar a ese JE un poco mas abajo vemos en los registros, el nombre de la api que corresponde a esta entrada que acaba de llenar con el valor malo o sea GetVersion.

Luego vemos que llega a una llamada a GetProcAddress para encontrar la direccion de GetVersion en mi maquina ya que los parametros son.

Yo entre en la api para ver los parametros pero no es necesario, pasamos con f8 el CALL.

Y en EAX nos devuelve la direccion de GetVersion en nuestra maquina sigamos traceando.

Alli llegamos a un salto, el cual saltara veamos que pasa sin tracearlo, haciendo click en FOLLOW

Vemos que alli guardara la direccion pero en otro lugar no en la IAT ya que EDI vale

luego de guardar esos valores llega a este JMP

Que nos devuelve al inicio del proceso porque al retornar del mismo ya el valor de EAX es machacado. Veamos con FOLLOW donde iria

Alli se ve claramente que EAX en la segunda linea perdera el valor correcto de la api en mi maquina y seguro pasara a repetir el ciclo para la siguiente entrada asi que debemos estar cerca. Podemos fijarnos para entradas malas cuales son los saltos condicionales que saltan, para luego

cuando traceemos para entradas buenas podemos comparar. Mucha veces yo me hago una tablita que suele ayudar mucho y es que en la rutina de este loop anoto que ocurre con los saltos tanto con entradas buenas como con entradas malas. PARA ENTRADAS MALAS (pondre imagenes de todos los saltos a medida que paso por ellos traceando, hasta llegar a donde guarda el valor)

Esto es un miniloop luego de salir de el

Alli ya llega a GetProcAddress y luego salta donde lo guarda

Alli lo guarda este es un traceo completo para una entrada mala, mirando los saltos condicionales como funcionan en ese caso, ahora llegaremos el OEP y buscaremos una entrada buena para hacer el mismo trabajo y comparar. Llego al OEP

Como entrada buena elegimos 460BAC, ahora realizamos el mismo proceso que hicimos con la

mala. Reiniciamos y la buscamos antes de ejecutar el programa.

hora ponemos un MEMORY BREAKPOINT ON WRITE para tratar de interceptar el momento

lli para cuando va a guardar en la entrada el valor bueno.

emos que EAX tiene el valor de una posible api aunque aun no dice el nombre, pero si miramos

Aen que el packer guarda la entrada buena.

A

Vcon GOTO EXPRESSION -EAX

Vemos que nos lleva alli, y al volver al codigo magia aparecio el nombre jeje.

Ahora vamos a hacer el m la, esperemos que siga en orden y que la siguiente sea buena hasta que trabaje con una buena. PARA ENTRADAS BU

ismo trabajo que hicimos con la entrada ma

tambien si no deberemos seguir

ENAS

del loop y comenzamos a tracear. Llegamos hasta el inicio

ste salta igual que en las entradas malas

ste en las entradas malas no saltaba pero es un salto muy pequeño no creo que sea desicivo, igamos.

E

Es

Ese no salta igual que en las malas

aquí vemos una gran diferencia este salto en las entradas malas no saltaba y aca si y vemos que el

Alli vemos que es un salto bastante largo lo cual puede ser la diferencia de la desicion entre si una entrada se guardara buena o mala, o sea este si todo va como imaginamos seria el posible salto magico, un salto que decide si la entrada se guardara buena o mala, quiere decir que para que una entrada se guarde buena este salto debe saltar asi que una posibilidad seria hacerlo JMP. Pero ese salto no se encuentra en el inicio del programa debemos ser muy cuidadosos si reiniciamos el OLLYDBG y buscamos el salto

codigo que salta es mucho.

Vemo

l tema es como parar alli ya que HBP no acepta y BP los detecta asi que deberemos aguzar la

s que al inicio alli hay pura basura, asi que el packer creara ese salto mas adelante.

Eimaginacion. Pondremos un BPM ON WRITE que abarque a toda la IAT para que pare cuando guarda el primer valor. El inicio de la IAT era 460818 y el final 460f28 abarquemos toda esta zona con el BPM ON WRITE.

Alli esta tod er valor.

En los STOS para m os si en este mome

ues estaOEP.

demo

lli llegam

a la IAT con el BPM ON WRITE ahora lleguemos adonde guarda el prim

uchisimas veces ya que abarca toda la IAT el BPM, asi que miremnto ya esta visible el posible salto magico

P alli visible veamos que pasa si lo cambiamos a JMP y quitamos el BPM y llegamos al

Hay dos posibilidades que el packer detecte los cambios y que falle o que corra y llegue al OEP, s RUN.

A os al OEP miremos la IAT

os haberlo

Le quito la tilde a REBUILD IMPORT.

Todos valores correctos, jeje ya tenemos la IAT reparada, ahora dumpeemos, podiamhecho antes no hay diferencia con esto.

Y dump

magico hizo su magia jeje.

Ahora reparo el dum

Alli lo guardo com

Funciona perfecto jeje Bueno hemos visto un m pre varia de un packer a otro, pero comparando y m ena y una mala, siempre lo podemo hasta la parte 38 Ricardo Narvaja 22/03/06

eo, ahora abro el IMP REC y le pongo nuevamente los valores de RVA; SIZE Y OEP.

eo que ahora sale todo valido, el salto V

peado apretando FIX DUMP.

o dumped_.exe y lo ejecuto a ver si funciona.

etodo para hallar el salto magico que siemirando un poco entre lo que hace con una entrada bu

s llegar a ubicar facilmente, continuaremos con mas packers en la parte 38.

INTRODUCCION AL CRACKING CON OLLYDBG PARTE 38 En la ultima entrega vimos nuestro primer programa con entradas redireccionadas y como repararlas y continuaremos levemente aumentando la dificultad de los packers para ir aumentando el nivel, asimismo, empezaremos con los ejercicios para que practiquen un poco. Aquí tenemos un unpackme de Yoda Crypter 1.3 para practicar un poco, por supuesto el OLLYDBG debe tener los plugins necesarios para no ser detectado por el antidebugging como vimos en partes anteriores. Aquí estamos en el Entry Point

Vemos un PUSHAD funcionara? Probemos el metodo, lleguemos hasta alli traceando y pasemos con F7 el PUSHAD. Hacemos ESP-FOLLOW IN DUMP y luego marcamos los primeros 4 bytes como vimos anteriormente y colocamos un HARDWARE BPX ON ACCESS.

Vemos una rutina que creara un manejador de excepciones y luego como salta con un JMP a una zona de ceros para provocar un error, asi que si traceamos y llegamos al JMP.

Alli va a saltar al error, miremos adonde saltara en el manejador de excepciones.

El mismo esta en 46590b, el que no quiere complicarse mucho la vida y llegar al OEP, aquí se puede poner un BPM ON ACCESS en la primera seccion y al pasar la excepcion llegaremos al OEP.

Alli esta el OEP es 4271B0 ya que esta empacado siempre con el mismo crackme, jeje.

manormal

ucho

Los que quieren profundizar un poco mas ya pueden ver que en el manejador de excepciones se nipula el context para modificar EIP y por lo tanto la direccion de la excepcion, que era

mente 465982, o sea donde se produjo la excepcion, y es sobreescrita con la direccion del OEP o sea 4271B0 para que retorne de la excepcion directo al OEP, aunque esto no importa mpor ahora, lo dejamos anotado para futuros estudios que hagamos de la estructura CONTEXT.

Bueno la cuestion es que ya estamos en el OEP, podemos DUMPEAR.

Le quitamos la tilde para que no intente reparar la IAT y DUMPEAMOS.

Por supuesto si ejecutamos el yodadump.exe nos da error, nos podriamos haber dado por muy afortunados si corriera solo en nuestra maquina, pero ya veremos que la IAT tiene entradas redireccionadas lo cual hace que no pueda correr para nada, al tratar de acceder a esas direcciones inexistentes en el dump. Bueno comencemos a analizar la IAT, busquemos una llamada a una api, alli debajo vemos una llamada a GetVersion la misma de siempre jeje.

Bueno vemos que dicho CALL toma valores de 460ADC para ver donde saltara o sea que esta es una entrada de la IAT, vayamos a verla en el DUMP.

Pues se ve esta parte de la IAT como correcta ya que si miro en el mapa de memoria donde van las entradas, todas van a 7C8XXXXX o cercanas y esas direcciones caen en la seccion code de kernel32.dll o sea que estas entradas serian correctas.

Por lo demas si busco referencias en cualquiera de ellas al azar y haciendo click derecho FIND REFERENCES hay referencias.

Si sigo bajando hasta la separacion

Veo que el siguiente grupo va a una zona de memoria 15XXXX veamos que hay alli.

Vemos una seccion queno hay dll asi que seguramente esa seccion fue creada por el packer, si reinicio para comprobarlo.

Vemos que hay una seccion creada por el sistema de 3000 bytes, pero la que usa el packer es de 29000 bytes mucho mas larga asi que el packer agrando esa seccion para su uso. Por lo tanto estas son entradas redireccionadas por el packer a esa seccion, veamos una de ellas a ver como trabaja.

Tomare una de ellas, por ejemplo esta, y buscare la referencia, haciendo click derecho FIND REFERENCES.

Hay dos calls que tom e llevara en el listado

.

emos que la redireccion es muy sencilla, podra el IMP REC con sus traceadores repararla sin

Alli es

an valores de dicha entrada, mirare el primero haciendo doble click en el, madonde esta ubicado.

Alli vemos el CALL, hagamos click derecho FOLLOW a ver que hace en la seccion redireccionada

Vemos que sin muchos prolegomenos salta a la api SysStringLen directamente,por lo cual si lo traceamos a mano ya sabemos cual es la api correcta para esta entrada.

Vnecesidad de hallar el magico?

bramos el IMP REC. A

ta el proceso detenido en el OEP, lo elegimos en el menu desplegable.

No olvidemos que al IMP REC debemos darle 3 datos OEP, INICIO DE IAT y LARGO. OEP=4271B0 al cual restandole la imagebase da 271B0 El inicio de la IAT si subimos en la misma.

Vemos que las entradas de la IAT o bien van a de dlls o bien a la seccion 15xxxxx

el redireccionamiento, si seguimos subiendo a ver cuando acaban las entradas.

Vemos que hasta alli se repite el rencias a ver si hay mas entradas e la IAT, no hallo en ninguna.

Por lo cual la prim 60818 al restarle la

agebase.

la seccion coded

esquema, mas arriba si busco refed

era entrada de la IAT es 460818 para el IMP REC es RVA=im El final lo hallo de la misma manera voy bajando a ver donde termina el esquema de entradas que

van a seccion code de dlls o aredireccionadas a la seccion 15XXXX.

Alli vemos la ultima ay para ninguna entrada, asi qu quede dentro, el final de la IAT es 460f28, ahora

ebemos hallar el largo de la misma.

Asi que poniendo en lim

EP=271B0

IZE O LARGO=710

n el IMP REC.

Al apretar GET IMPORTS

entrada de la IAT es 460f24 mas abajo si busco referencias no he para que la ultima entrada

d LARGO=FINAL -INICIO= 460f28 - 460818= 710

pio

ORVA o INICIO=60818 S Pongamos estos valores e

Vemos que hay 296 entradas sin resolver, lo podra resolver con algun traceador? Si apreto el boton AUTO TRACE se cuelga, probemos con los otros traceadores, apreto SHOW INVALIDS y en las entradas marcadas hago click derecho TRACE LEVEL 1.

Dice que resolvio todo y que no hay mas entradas invalidas, le creemos? Jeje. Si apreto SHOW INVALID nuevamente veo que todas estan YES.

Probemos reparar el yodadump.exe apreto FIX DUMP

Alli me creo el yodadump_.exe que supustamente esta reparado, probemoslo.

Jeje esta vez se porto el IMP REC y me ahorro mucho trabajo. Ahora ademas de esto y para jorobar un poco, tiene salto magico este packer?

Busquemos una mala entrada en la IAT en el programa que esta detenido en el OEP.

e colocare un HARDWARE BPX ON WRITE antes de reiniciar, ya que los HBP se mantienen,

or supuesto el metodo es tratar de parar cuando guarda el valor malo 15XXXX en la entrada, para

lli pa lor de una API.

lo guarda en la entrada la

Laun despues de reiniciar y ya vimos con el metodo del PUSHAD que el packer no es alergico a losmismos.

Pello reinicio el OLLYDBG y doy RUN.

A ro y guardo el valor bueno en la entrada de la IAT vemos que EAX tiene el va

Y cual esta siendo apuntada por EDX, quiere decir que en este caso,

primero guarda el valor bueno y luego lo modifica por el malo, sigamos traceando a ver cuandsucede esto.

o

emos que apenas una cuantas lienas mas abajo, ESI toma el valor malo y lo va a sobrescribir en la

uiere decir que las entradas buenas solo escribiran la primera vez y no llegaran a esta segunda

epitamos el proceso ahora con una entrada buena, la de GetVersion que estaba unas lineas debajo

emos que para a

raceemos un poco.

Ventrada.

Qparte donde sobrescribe con el valor malo. Rdel OEP estaba correcta asi que usemosla era 460ADC pongo un HBP ON WRITE en ella.

V lli, al guardar la direccion correcta que esta en EAX.

T

Vemos que llega al JMP que evita la zona marcada con la flecha roja donde se cambia por el valor malo, asi que el tema es evitar que salte este JMP, algunos de los saltos anteriores que evitan el JMP es el salto magico, veamos cual es ya que hay varios saltos condicionales, delante del JMP. Tambien podriamos intentar como solucion NOPEAR la linea donde guarda los valores malos asi no lo guarda y queda toda la tabla bien, eso seria tambien correcto, podemos probar si funciona.

Para ello marco la linea anterior a la que guarda los valores malos y le coloco un HBP ON EXECUTION y reinicio hasta que pare alli por primera vez, lo coloco en la linea anterior porque el HBP para una instrucción despues de donde lo coloque y no quiero que me guarde el valor malo.

Alli paro, probemos nopeando la linea donde guarda el valor malo.

Ahora sigamos a ver si no detecta el nopeo que hice y llega al OEP.

Quito el HBP y doy RUN

Bueno el maldito detecta los cambios que hice y da error, asi que el nopeo no va, continuemos con el salto magico.

Traceando cualquier entrada mala, veo que es este el salto magico, el que evita el JMP y me lleva a

la zona donde guarda el valor malo, asi que habria que nopearlo para llegar al JMP, aunque dudo que no detecte el nopeo, igual probemos.

ual en ambos metodos el programa nos da error pero luego de haber reparado correctamente toda

eo que la IAT esta toda correcta asi que no hay problema ninguno, tengo dos posibilidades aquí, o

l

Igla tabla si miramos la misma, en el programa que se detuvo por el error.

Vbien abro en otro OLLYDBG otra instancia del crackme, y sin modificar nada, llego al OEP, y le copio y pego la tabla correcta encima de la mala, con BYNARY COPY y BINARY PASTE lo cuaes muy sencillo, tambien puedo utilizar directamente este proceso para el IMP REC que aunque no haya llegado al OEP ya tiene toda la IAT correcta y eso es con lo cual trabaja el IMP REC, el resto no importa, asi que si lo abro en el IMP REC y le coloco los valores correctos de OEP; RVA y SIZE, y apreto GET IMPORTS.

Veo que me salen todos los valores correctos, y aunque el proceso que tengo detenido no me sirva para dumpear ya que no llego al OEP, no importa ya que he dumpeado previamente en uno que si llego al OEP, y a ese dumpeado solo le falta la tabla que este si tiene correcta, por lo cual puedo reparar perfectamente con este proceso el dumpeado que ya tenia hecho, sin problemas y funcionara correctamente, si borro el anterior yodadump_.exe que estaba ya reparado y busco el dumpeado anterior yodadump.exe, y apreto fix dump y lo reparo.

Me crea un nuevo yodadump_.exe veamos si funciona.

Si funciona perfectamente quiere decir que aprendimos que el dumpeado se necesita hacer desde el OEP ya que alli esta todo el programa desempacado en memoria, pero la tabla puede arreglarse desde un proceso que la tenga correcta, aunque no haya llegado hasta el OEP, porque el IMP REC no cambia nada del DUMPEADO, salvo la IAT la cual esta correcta, por eso el dumpeado funciona perfectamente. Como ejercicio les dejo el archivo adjunto para desempacar, es muy sencillo si que espero que lo puedan hacer sin problemas. Hasta la parte 39 Ricardo Narvaja 27/03/06

INTRODUCCION AL CRACKING CON OLLYDBG PARTE 39 Buenoen esta parte y la 40 empezaremos el tema de stolen bytes y scripts para ello usaremos uno unpackme conocido el UnPackMe_PELock1.06.d.exe que tiene su miga, y que del mismo o variaciones del mismo han hecho esta semana grandes tutes en la lista como el de Otup que esta regenial.. Aquí estamos en el inicio del programa paraditos en el OLLYDBG

Usaremos una variacion del metodo de las excepciones mas adelante veran porque, en este caso en vez de confiar en el LOG de OLLYDBG haremos nuestro propio LOG de excepciones, porque en estos packers una excepcion que se te pasa o no sale en el LOG o que es camuflada nos puede hacer mucho lio, lo cual puede ser posible ya que OLLYDBG no es perfecto y ya me ha ocurrido en packers raros y asi terminamos muertos, entonces estudiemos este BP.

Este BP sera nuestro LOGUEADOR de excepciones, por ahi OLLYDBG loguea las mismas pero yo cuando me enfrento a packers con muchas excepciones y mas de un Thread como en este caso que crea un thread, antes de llegar al OEP, siempre confio en el logueo directo hecho por mi y no en el que hace OLLYDBG, el tema es que todas las excepciones deben pasar por este punto en el cual acabamos de poner un BP, si lo vemos en OLLYDBG.

Esta rutina la podemos analizar facilmente de esta forma.

O sea el punto marcado con entrada es el inicio de la rutina que maneja las excepciones en la ntdll.dll, el call marcado con AL MANEJADOR, en un call que detro del mismo, luego de muchas vueltas salta al manejador de excepciones que nos indica VIEW-SEH CHAIN, luego de ejecutar el manejador de excepciones, retorna a esta rutina y llega hasta RETORNO donde dentro de ese call vuelve a continuar la ejecucion del programa. Aclaro por si alguien se pone a tracear, que cuando salto de aquí al programa, no podemos llegar traceando, pues hay rutinas RING0 intermedias que OLLYDBG no puede tracear, en ese caso si queremos parar en el programa desde aquí debemos poner un BP en el manejador o retorno o tambien BPM ON ACCESS en toda la seccion donde se produjo la excepcion, para que OLLYDBG despues de que termine de ejecutarse la parte RING0, pare en el programa nuevamente, digo esto porque no faltara el curioso que quiera tracear desde aquí hasta el programa, y no se puede con OLLYDBG se llega un punto donde se salta a RING0 donde no se puede continuar traceando. Bueno igual con los puntos que tenemos, ya es suficiente, si damos RUN y para en la primera excepcion.

Vemos en el LOG que la misma se produjo en mi maquina en 3a5c74 y luego de ella como teniamos todas las tildes marcadas en DEBUGGING OPTIONS-EXCEPTIONS, paro directamente en el BP que colocamos. Ahora si miramos el stack

Vemos que unas lineas mas abajo esta la direccion donde se produjo la excepcion, excatamente en [esp +14]

Por lo tanto si coloco un BREAKPOINT CONDICIONAL LOG en vez de un BP y hago que loguee [ESP+14] tendre mi logueador propio jeje.

Por lo tanto hago click derecho, y cambio el BP que habia colocado por un CONDITIONAL LOG.

Pongo la tilde para que siempre loguee el valor de [esp+14] cada vez que pase por alli y que no pare, solamente loguee, y doy RUN.

Vemos que el programa arranca, extrañamente casi ningun packer detecta los BP o BP CONDICIONALES en KiUserExceptionDispatcher. Bueno miremos nuestra obra en el LOG.

Alli se ven y OLLYDBG logueo bien las que se ven aquí, la ultima esta un poco mas abajo.

Vemos que la ultima excepcion es una ACCESS VIOLATION en 3A6744, pero alli no podemos poner BP ni HE estos ultimos son detectados por el packer y no corre el programa, veamos

Una opcion que tengo es llegar al punto quitando la tilde de MEMORY ACCESS VIOLATIONS y parar en todas hasta que lleguemos a la ultima, este metodo si bien funciona, pensemos en algo mas generico y rapido y que sirva para todo tipo de excepciones, asi que vuelvo a colocar esta tilde.

Y sin matarme mucho voy a B donde esta la lista de breakpoints y aun esta mi BP condicional alli, hago click derecho- EDIT CONDITION.

Solamente debo agregar la condicion para que pare, si logueabamos [esp+14] y en el momento que queremos que se detenga ese valor era 3a7644, ya que era la intruccion donde se genero la excepcion que nos mostraba nuestro LOG, pues entonces que pare cuando [esp+14]==3a6744 y listo.

Cambio la tilde a que PAUSE PROGRAM-ON CONDITION para que pare cuando se cumpla la comdicion que colocamos y damos RUN.

Alli paro el programa en la ultima excepcion y sin tener que estar contando una a una, ademas si queremos volver a este punto, pues reiniciamos damos RUN de nuevo y parara aquí las veces que queramos sin tener que estar contando excepciones. Por supuesto si desde aquí coloco un BPM ON ACCESS en la primera seccion pararemos en el OEP (sera asi? Jeje hagamoslo)

Vemos que ahi para en la primera seccion en el supuesto OEP, pero que pasa aquí? En este punto comenzaremos a estudiar los stolen bytes. STOLEN BYTES son bytes del programa que son ejecutados por el packer, lo mismo que STOLEN CODE es codigo del programa ejecutado por el packer.

Los stolen bytes generalmente son las primeras instrucciones del programa original a partir del OEP

ara que se hace esto?, muy simple si yo dumpeo aquí y reparo la IAT y coloco como OEP packer,

ue debo hacer?

n metodo es tratar de tracear la rutina del packer, luego de la ultima excepcion y llegar al OEP e

or eso realice el metodo de las excepciones de esa forma, ya que muchas veces el traceo en tengo

.

iremos antes de reiniciar un poco el panorama, cual es la forma de sospechar que hay stolen

einiciemos el programa.

i veo el stack al inicio.

sta en 12FFc4 en mi maquina, y sea cual sea el valor en la suya, en el OEP salvo casos muy

en el

que el packer borra de la primera seccion y los ejecuta en otra seccion propia, y luego en vez de saltar al OEP salta a la 5 o 6ta linea por ejemplo habiendo ejecutado las anteriores en una seccionpropia, generalmente fuera de las secciones del ejecutable. P4271D6, el programa no arranca pues le faltan las primeras lienas, que cuando corrio con el el maldito la ejecuto antes en su propia seccion y luego salto aquí, por lo cual en el dumepado, esas lineas no se ejecutaran. Q UFALSO traceando y guardando en un txt todo lo que ejecuto, cosa de poder analizar que fue lo quejecuto antes de saltar al ahora llamando falso OEP de 4271d6. POLLYDBG tiene unas cuantas posibilidades, tildes y opciones que intentar, y si cada vez queque llegar a la ultima excepcion tengo que contarlas una a una, me volvere loco, por lo cual, tengo la forma de que pare en el punto solo dando RUN, y ya estamos nuevamente en la ultima excepcion Mbytes?, pues mirando el stack. R

S

Eestramboticos, el programa se debe iniciar con el stack en 12FFc4 o cercano, todo lo que haya falso OEP, arriba de esta direccion sera codigo que ya se ejecuto desde el OEP VERDADERO hasta el FALSO

Veamos lleguemos nuevamente al falso OEP.

emos que si este fuera el verdadero OEP, el stack deberia estar en 12FFc4 o cerca, todo lo que hay

ste

Varriba son instrucciones que ya se ejecutaron del programa, unas cuantas lineas que desde el verdadero OEP que el packer quito del programa y lo translado a otra seccion, se ejecutaron instrucciones que deberian estar arriba del falso OEP, y que fueron borradas, si recordamos ecrackme que es el mismo que siempre venimos estudiando el OEP estaba en 4271b0, si miramos esa zona aquí.

Vem

ultim

La m

Tenemos el parametro que nos marca aquí el inicio de la estructura CONTEXT, miremosla en el DUMP.

os que el packer reemplazo los bytes originales del OEP e instrucciones siguientes con basura, que ademas nunca se ejecuto, pues con el BPM ON ACCESS paramos en la primera linea de codigo ejecutada en esta seccion y no paro en esos bytes sino mas abajo en 4271d6.

Pues cuales son los metodos para hallar los stolen bytes, pues hay muchos realmente, el mas clasico es tracear luego de regresar de la ultima excepcion, probemos ese reiniciemos y volvamos a la

a excepcion.

isma se habia generado en 3A6744, por lo cual no me interesa en este caso el manejador de

excepciones, asi que pondre un BP en el retorno, asi salteo el mismo.

Ahora doy RUN, si alguien quiere saber donde retornara al programa para poner directamente un BP alli, pues veamos en el stack.

Los que ya conocen la estructura CONTEXT saben que isma , entre los valores

a al regresar de la excepcion, como ya saben mas delante le dedicaremos un estudio detallado de la estructura CONTEXT por ahora, solo mirando lli saben donde volvera, si no quieren complicarse la vida buscando en el CONTEXT, poniendo un

Y dando RUN vemo

ese es el EIP de la mde los restantes registros que tendra el programaaBPM ON ACCESS en la seccion donde se produjo la excepcion.

s que para en el mismo lugar

lli colocaremos las condiciones del traceo, hay miles posibles, ya que puedo colocar que chequee s valores iniciales de los registros y cuando se cumplan que todos estan igual que antes de correr

l programa, estare en el OEP, por ejemplo, pero miremos si funciona estas dos.

Aloe

La prim e ver en el LOGUEO del

paramos en el m

onemos las dos tildes en la configuracion para intentar si funciona con ellas, lo cual es lo mas robable, si no, probaremos quitandolas.

Tambien hacemos que loguee a una fila. Apretamos TRACE INTO y me molesta la condicion de ESP que me hace parar muchas veces, si la quito y sigo con el trace into, para en el falso OEP, y en la fila de texto tengo todas las instrucciones que ejecuto antes, pero no me funciono lo de parar en el VERDADERO OEP, bueno mala suerte.

era parara en el falso OEP pero traceando, lo cual puede dejarmtraceo, las instrucciones que ejecutó antes de llegar al mismo, la segunda tilde, es para ver si

omento del VERDADERO OEP ya que alli vimos que esp= 12ffc4.

Pp

Una de las posibilidades que se puede intentar es poner que pare en cualquier PUSH EBP o POPAD que generalmente o son el OEP en el primer caso, o la recuperacion de registros en otros casos, uede funcionar o no, ya que muchas vece

esto s los push EBP son emulados, pero bueno veamos,

ongamos a tracear.

Por supuesto como instrucciones verdaderas no debemos considerar los saltos ni los SAL o cualquier otra instrucción basura.

pp

Podria ser el verdadero OEP, traceemos un poco.

Esta parece ser la segun as directamente del original es facil d

Y asi seguimos traceanfalso OEP.

da instrucción faltante, al no ser emuladas y estar copiadetectarlas.

do y copiando las buenas instrucciones que va ejecutando hasta llegar al

RET asi que salta alli.

or supuesto ahora hay que copiar todos los bytes de las instrucciones faltantes fijarse cuantos son y

pegarlos antes del OEP FALSO vea

Alli vemo o ya verificamos que es todo correcto volvem

Y aquí llegamos al falso OEP ya que hizo PUSH 4271D6 que era la direccion del falso OEP y luego

Pmos en el DUMP:

s la zona del falso OEP, y arriba donde deben ir los bytes faltantes, comos para atrás apretando el menos hasta el verdadero OEP

en un bloc de notas notepad sin colocar el push final y el ret pues esos son un salto al OEP falso no son stolen bytes.

asi que le resto a la direccion del

Asi hallamubiera quitado.

Y ahora si, hare binary copy de cada linea que ejecuto y voy copiando los byteso

55 8B EC 6A FF 68 60 0E 45 00 68 C8 92 42 00 64 A1 00 00 00 00 50 64 89 25 00 00 00 00 83 C4 A8 53 56 57 89 65 E8 Son 38 stolen bytes que en hexadecimal es 26

falso OEP esos 26 bytes faltantes.

os la direccion de donde deberia haber estado el verdadero OEP si el packer no lo h O sea que a partir de 4271b0 debemos pegar los bytes que hallamos.

Marco los bytes del notepad y hago COPY y aquí hago click derecho BINARY PASTE.

bytes. s los cuales son necesarios para reparar esta IAT

Hasta la parte 40 Ricardo Narvaja 4/04/06

Alli se copiaron miremos como quedo el codigo

Ahora si quedo mejor, podria dumpear desde aquí y cambiar el OEP a 4271B0 con lo cual estarian olucionados los stolens

En la parte siguiente vamos a comenzar con script demas lios que cometio el packer. y

0

INTRODUCCION AL CRACKING CON OLLYDBG PARTE 40 Antes de continuar con la tabla IAT del pelock, y los antidumps, en esta parte veremos dos temas, uno que quedo en el tintero y otro que es una gran ayuda para continuar con el tpelock o cualquier otro programa similar que anula o detecta los HBP ya veremos. El primer tema es que en la pate 39 si descargaron el tutorial apenas salio, no se dieron cuenta, pero luego fue modificado y aparecia un mensaje de texto que decia. Para realizar este tute se debe utilizar el ollydbg parcheado 4 que esta dentro del rar actual, es un OLLYDBG parcheado que se debe colocar en la misma carpeta que el OLLYDBG.exe, porque el OLLYDBG normal tiene un bug al manejar las ILLEGAL INSTRUCTION, que hace que salga un cartel si o si cuando le pones la tilde en debugging options-exceptions para saltearla, con el parcheado 4, el bug esta reparado, al momento de hacer el tute lo habia olvidado, pero Solid me recordo al no poderlo hacerlo al tute, el problema y al pasarle el parcheado 4 para que ponga en la carpeta del OLLYDBG y usarlo, no tiene ningun problema. Ricardo Narvaja Y traia un OLLYDBG modificado llamado PARCHEADO 4 que se coloca en la misma carpeta del OLLYDBG.exe y usando este ultimo sirve mejor para hacer el tutorial de PELOCK. Lo que queria explicar como primer punto que tiene de especial este parcheado 4. Bueno el OLLYDBG posee un bug al manejar las excepciones ILLEGAL INSTRUCTION; Si en un OLLYDBG normal (sea renombrado o no) con los plugins para ocultarlo, marcamos todas las tildes en DEBUGGING OPTIONS-EXCEPTIONS y damos RUN.

Obtenemos este error, mientras que en el parcheado 4, corre perfectamente que ocurre aquí veamos en el momento que aparece el cartel de error, lo aceptamos y miramos el LOG del OLLYDBG.exe normal.

Vemos que la ultima excepcion antes de que salga el cartel es una ILLEGAL INSTRUCTION, ahora vayamos a debugging options- exceptions y quitemos la tilde de ese tipo de excepcion.

Esa es la tilde que corresponde a esa excepcion, la quitamos y arrancamos el pelock y damos RUN.

Para en la excepcion y si la pasamos con SHIFT +f9, no hay problema para en dos oportunidades mas en excepciones de este tipo y arranca el pelock. Eso quiere decir que OLLYDBG tiene un problema cuando le pones la tilde para que pase esa excepcion automaticamente. Si solo fuera apretar SHIFT + f9 y todo se arregla no habra problema, pero alertados de este bug muchos programadores generaban 200 o 300 excepciones de este tipo las cuales habia que pasar todas a mano con SHIFT + f9 lo cual era pesado al menos. Ahora volvamos a colocarle la tilde y hagamos que aparezca el cartle de error nuevamente.

Al mejor estilo cracker, lo que haremos sera crackear el OLLYDBG para arreglarle el bug, para lo cual abrimos un segundo OLLYDBG vacio, con el cual crackearemos al que esta detenido en el cartel de error.

En este OLLYDBG vacio iremos a FILE -ATTACH para atachear y debuggear al otro OLLYDBG que este detenido en el cartel de error.

En la ventana que se abre buscamos el proceso OLLYDBG.exe cuya ventana o WINDOW tiene el eror como muestra alli, y apretamos attach.

Alli paro ahora damos RUN Ahora miraremos el mapa de memoria.

Por supuesto la victima es el otro OLLYDBG cuyas secciones vemos alli, lo que haremos sera colocar un Bp MessageBoxA

Pero ese no es tan importante solo nos sirve como guia para poner el BP en el RET de la api MessageBoxA, y al aceptar el error, parara en el RET al volver de dicho cartel.

Alli vemos cuando retornamos al programa de la api, al apretar f7.

Si recordamos el texto del cartel decia lo que vemos arriba. Si buscamos entre las strings del OLLYDBG

y alli buscamos la palabra bypass que esta en el mensaje.

Vemos que esa es la string correcta, hagamos doble click para ir al lugar donde esta la misma en el listado.

Vemos que cualquiera de esos JNZ evita que salga el cartel de error podriamos cambialo por JMP y tendriamos nuestro programa parcheado, la guardar los cambios definituvos en memoria con COPY TO EXECUTABLE y SAVE FILE. Abramos el parcheado 4 en OLLYDBG para mirarlo y veamos esta misma zona a ver como es.

Vemos que en este directamente en vez de parchear los saltos que de cualquier manera nos llevan a saltear el cartel, lo que hice en su momento, fue cambiar el ultimo salto justo antes del cartel y cambiarlo a JMP 43528d, por si acaso salte de algun otro lugar siempre evite el cartel por cualquier camino, Bueno esto es todo el secreto del parcheado 4 y porque no tiene el bug de ILLEGAL INSTRUCTION como el OLLYDBG.exe normal, asi que pueden parchearlo por ustedes mismos o usar el que esta dentro de la leccion 39, en la correcion fue agregado dentro tambien el PARCHEADO 4.

La segunda parte de este tutorial sera hacer un simple script, para lo cual usaremos el s del

hora abrimos el Parcheado 4

emos que aparece el PLUGIN

hora abro el pelock que estabamos estudiando, el tema sera hacer un minisript para que funcionen

era un sencillo script veremos los comandos que por supuesto los consultamos en el README del

OLLYSCRIPT 0.92 que adjunto a este tutorial, y pondremos la dll en la carpeta pluginOLLYDBG.

A

V Alos hardware bpx y que no sean detectados por el packer. Splugin OLLYSCRIPT.

La idea es la siguiente como vimos en la parte anterior cada vez que para en

legue al manejador de

omo es nuestro primer script y para no complicarlo demasiado, los BP en estas direcciones tanto

ionDispatcher y en el CALL que va a ZwContinue como vemos en la imagen.

hora que ya pusimos a mano empezaremos el script el cual normalmente se comienza con un

icio:

sto se coloca para que si necesitamos saltar al principio del script facilmente con un Jmp inicio esta

phws 12ffc4, "r"

phws es el comando que coloca un hardware breakpoint en la direccion en este caso 12ffc4, y entre

icio:

phws 12ffc4, "r"

abajo:

uego de la colocacion del o los hardware bpx que quiero usar, pongo otra etiqueta llamada trabajo

KiUserExceptionDispatcher estamos justo antes de que el sistema operativo lexcepciones donde sabemos que pueden ser detectador los HBP y borrados, asi que la idea es hacer un script que cada vez que el programa pare en el Bp KiUserExceptionDispatcher, borre el HBP y cuando llegue al CALL a ZwContinue lo restaure.

Cen KiUserExceptionDispatcher y en el call que va a ZwContinue los colocaremos a mano pues ya sabemos ubicarlos, facilmente y logicamente se pueden colocar sin problemas con el mismo script, pero eso ya lo veremos mas adelante no quiero complicarlo de mas, asi que la idea es ir y colocar a mano un BP KiUserExcept Aetiqueta arbitraria en mi caso use inicio: in esolucionado, luego de inicio viene el Hardware Breakpoint que queremos colocar por ejemplo. b bcomillas la r significa on access o read que es lo mismo, si fuera w seria on write y si fuera x seria on execution. in b tr Lpor si quiero retornar luego de la colocacion de los HBP.

inicio:

phws 12ffc4, "r"

abajo:

ob pirulo

emos alli el comando eob, lo que hace el mismo es que cada vez que el OLLYDBG detecte una

o

ste es la parte principal, alli cuando ejecute el script el OLLYDBG comenzara a correr la victima,

irulo: , 7c91eaec

c91eb03

n mi maquina 7c91eaec es la direccion de KiUserExceptionDispatcher o sea cuando pare en ese

o pare por el otro BP que esta en CONTINUE y cuando

uego solo me queda

uitar: 2ffc4

uando salto a quitar para borrar los HBP el comando bphwc sirve para borrar los mismos y luego

a otra etiqueta es restaurar que s eactiva en el Call a ZwContinue

estaurar:

ue directamente salta al inicio donde se vuelven a colocar los HBP y se reinicia el ciclo.

b tr erun vexcepcion o breakpoint, pasa la ejecucion a la etiqueta que esta al lado del comando en este caso eob pirulo, significa que cuando el programa pare en una excepcion o breakpoint seguira corrienddesde la etiqueta pirulo, y luego doy RUN con el comando llamado run. Edebemos preparar que vamos a hacer cuando detecte una excepcion o BREAKPOINT , para ello escribiremos la etiqueta pirulo: pcmp eipje quitar cmp eip, 7je restaurar jmp final eBP, el eip de mi maquina sera 7c91eaec, por lo tanto compruebo que estoy realmente alli y salto a la etiqueta quitar, para borrar los HBP. Luego hay otra comparacion para cuanddetecte que el programa paro por ese BP, vaya a la etiqueta restaurar, para poner nuevamente los HBP. L qbphwc 1jmp trabajo Cde borrarlos salto a trabajo, para que vuelva a ejecutarse todo y a correr el programa pero sin colocar los HBP. L rjmp inicio q

Por supuesto debemos tener una posibilidad de parar el programa cuando OLLYDBG pare por

omo cuando ejecuta eob para tambien por cualquier breakpoint o excepcion, cuando para por ra

irulo: , 7c91eaec

c91eb03

lli en final:

nal: N "Continuar?"

SGYN es que hacemos aparecer un messagebox con la opcion continuar, para que veamos si nos

l

nte los BP en Bp KiUserExceptionDispatcher y el

nuestro HBP, en ese caso es esta parte final. Cnuestro HBP, tambien ira a pirulo y como no es ninguno de los BP que colocamos a mano seguihasta la etiqueta final: pcmp eipje quitar cmp eip, 7je restaurar jmp final a fiMSGYcmp $RESULT,1 je inicio ret Mgusta el lugar donde paro o queremos que siga corriendo hasta la proxima vez que pare por el HBP. Si apretamos YES en la variable reservada $RESULT habra un 1, y si apretamos no un 0, por lo cual cuando queremos que continue, al apretar YES el script compara $RESULT con 1 y vuelve ainicio a continuar trabajando, si no es 1 va al ret donde termina y para el script y queda el OLLYDBG parado donde nosotros queriamos. El script completo es (recordar poner manualmeCALL que va a ZwContinue) inicio: bphws 12ffc4, "r" trabajo: eob pirulo run pirulo: cmp eip, 7c91eaec je quitar cmp eip, 7c91eb03 je restaurar jmp final quitar: bphwc 12ffc4 jmp trabajo restaurar: jmp inicio final:

MSGYN "Continuar?" cmp $RESULT,1 je inicio ret Abajo lo vemos mejor con unas flechas explicativas, al inicio ponemos los HB y corremos el

r las distintas

ue no sean a

el BP del CALL a ZwContinue saltara nuevamente a pirulo y ahora comparando eip, nos

l

robaremos el script lo guardo en una fila de texto y arranco el pelock, luego pongo manualmente

programa dejando la trampa lista que cuando encuente BP o excepcion salte a pirulo. A pirulo solo saltara cuando hay BP o excepcion y en ese momento tenemos que testeaposibildades, de que sea por los BP que colocamos a mano, o por el HE o por cualquier excepcion. Testeando el eip, podemos determinar si se disparo el salto a pirulo, por el BP de KiUserExceptionDispatcher con lo cual si se verifica, salta a quitar los HBP para qdetectados en el manejador de excepciones, y retorna a trabajo donde vuelve a correr el programsin HE. Luego enllevara a restaurar ya que en este momento ya paso el manejador de excepciones y los puedo volover a colocar, y luego para cualquier otro BP o excepcion o si para por el HE, salta a finadonde decido si parar o continuar, si paro va al ret si continuo va a inicio.

Plos 2 BP y voy al menu del plugin

.

Veo que para por el HBP, igual apreto YES para que siga

Veo que el programa corrio perfectam

El mism ismos sin ningun problema En la parte 41 y despues de esta introducci s haciendo scripts y repararemo Hasta la parte 41

icardo Narvaja

ente y veo en la ventana dehardware breakpoints

o se encuentra colocado por lo cual el programa corre con HBP y para en los m, que era lo que queriamos lograr, jeje.

on que nos ayudara seguiremos el pelock completamente.

R07/04/06