Hoy vamos a visitar una de las alas recientemente inauguradas de este museo de los horrores que es 48Bits donde los depravados habitantes de esta web han recopilado todo aquel engendro que han creado en un momento un otro de su malograda vida, normalmente con fines oscuros.

La entrada la pueden encontrar sus mercedes si miran a la derecha de la página, la otra derecha campeones… sí, ESA derecha; en la parte de arriba de la columna, en la sección titulada “Páginas” en la cuarta posición… Cómo que te has perdido? Que qué es una sección? El baño? pero si no llevamos ni 5 minutos de… anda y que os follen a todash perracash del ashverno!

Y para los listillos que ya habían mirado por debajo de la puerta, que sepáis que hemos actualizado el contenido.

No pienso volver a juntarme con gentuza como esta, me vuelvo a mi chamizo… argg

El caso es que tiempo después, me contactó alguien en nombre de una empresa ‘legal’(registrada) de Nevada(EEUU), usando para ello un email “puente” de un dominio registrado en Canada.

Me proponían una cosa curiosa…

Hello,

I am interested in a solution to breaking reCaptcha’s audio captcha as
found on Ticketmaster.com I want to get 30% accuracy with 1 second or
less processing time. A programmer I have worked with previously has
achieved 10% accuracy and under 1 second processing time. If you
provide consulting services that is also something we would be
interested in. Please contact me if you can do this project.

With Respect,
—-

Mi respuesta fue la siguiente

Hello —–,

We have no reference about your company. We do not support any kind of illegal activies. Unless you can demonstrate that your company is a trusted entity we cannot going forward into this issue.

Regards.

A lo que me respondió

Hello,

My company is an established LLC in Nevada. You should be able to verify that, but if not, I can help you figure out how to search the state records. It is not illegal to have an automated way to decipher a captcha. I hope we can discuss this matter further.

With Respect,

“Quizá soy demasiado paranoico” pensé, asi que intenté ser más educado y ver qué había realmente detrás del tema.

Hello,

Sorry if we were too rude but we receive, on a regular basis, requests to develop projects which are either barely legal or simply illegal.

You are right, there is nothing illegal in breaking a captcha, in fact as you probably know we released a method to do so. However, breaking captchas in an automated way is usually exploited to send unwanted emails and that kind of activities.

We do not want to be involved, neither directly nor indirectly, in those issues. We have no doubt that your company is legally registered, but our concerns are on the final usage of the technology we develop. Obviously, you are not required to disclose the purpose of your project but we need to verify that our work is not going to be used to harm users.

Regards.

Esta fue su respuesta:

No your work would not be used to harm users. As you may know, the
reCaptcha solution is one of the strongest available. In particular,
Ticketmaster’s is modified to be even stronger. Our business is testing
the strength of the captcha before implementing reCaptcha. Your ability
to break the captcha would lead us to try different methods. This is
all I can say on this matter. I hope that is sufficient.

With Respect,

Os confieso que estuve tentado de aceptar el reto, pero como este último mail cantaba mucho y no me inspiraba ninguna confianza decidí zanjar el tema.

Hello —-,

We have decided not to go further with this matter. Anyway thanks for writing.

Regards.

Curiosamente mencioné esta “anécdota” en una entrevista recientemente. Pues bien, hace escasos minutos a través de twitter me llegó esta noticia.
http://www.nj.com/news/index.ssf/2010/03/wiseguy_tickets_is_accused_of.html

Reconozco que me dió un pequeño vuelco el corazón,eran los mismos fulanos. Y se han comido todo el tinglado.

Si hubiera aceptado ahora mismo estaría camino de dormir con el polilla, finálmente.

Pase lo que pase, no hay que dejarse tentar por el dinero “fácil”. No se suele acabar bien.

Introducción

Y ahora vamos al lío. Cuando voy a reconstruir código de un procesador nuevo estos son los pasos que yo sigo:

• Obtener los manuales oficiales del fabricante del procesador para aprender como funciona la arquitectura.
• Crearme u obtener un compilador cruzado (GCC) para dicha arquitectura.
• Crear códigos en C muy básicos para empezar a averiguar como se genera el código ensamblador, es decir, las construcciones más habituales.

El tema de crear un compilador cruzado no es totalmente necesario pero si que ayuda mucho, porque de este modo sabemos exactamente como debe de quedar el resultado final y aprender a ajustarlo/corregirlo, especialmente si tenemos acceso al mismo compilador que se ha utilizado para compilar el binario a recuperar Sea como sea, lo que debemos de identificar y comprender como funciona son los siguientes aspectos y, en mi opinión, por este orden:

1. Prólogos y epílogos de función.
2. Cómo se crean variables locales, de heap y globales (cómo se reserva memoria para las variables locales, etc…).
3. Cómo se llama a funciones y como se pasan los argumentos a dichas funciones (si existen diferentes convenciones de llamadas, como funciona cada una de ellas, como y cuando se arregla la pila en caso de ser utilizada, etc…).
4. Cómo se construyen las sentencias condicionales (IF && ELSE).
5. Cómo se construyen los switches (al menos los más típicos).
6. Cómo se construyen los bucles (FOR y WHILE).

Muy breve introducción a la arquitectura MIPS

Los procesadores MIPS son RISC (Reduced Instruction Set Computer) y existen versiones de 32 y 64 bits. Los registros que se utilizan son los siguientes (extraído del artículo en wikipedia):

De esta tabla podemos aprender que los argumentos a funciones se suelen pasar por registro ($a0-$a3), que el stack pointer se representa por $sp, el frame pointer como $fp y la dirección de retorno como $ra. Además sabemos que registros del procesador son preservados cuando se llama a una función. Veamos ahora ya un código C básico y como queda su correspondiente código ensamblador:

Y el siguiente es el código ensamblador generado por un compilador cruzado para MIPS Big Endian de 32 bits:

Con este código tan básico ya hemos aprendido lo siguiente:

• Cómo se pasan los argumentos a una función (registros $a0, $a1, etc…).
• Cómo se reserva espacio para variables locales (addiu $sp, -0×30) y cuanto espacio se reserva para variables locales, por lo cual, podemos saber el tamaño de las variables locales. Excluyendo el espacio utilizado para guardar la dirección de retorno ($ra) y el framepointer ($fp).

El caso es que lo que se necesita identificar siempre, indiferentemente del procesador, es lo siguiente:

• Prólogo de la función para saber cuanto espacio se va a reservar para variables locales. También para saber que código hay que ignorar (el que no nos vale para reconstruir el código C).
• Epílogo de la función (para saber hasta donde hay que decompilar, osea, que otra parte hay que ignorar).
• Cómo se pasan los argumentos a función, como se llaman a las funciones y como se devuelve el valor retornado por la función llamada.

Empecemos a generar código C para esta función. Lo primero, sabemos que los argumentos se reciben y se pasan vía $an. También sabemos que para llamar a una función se utiliza la instrución JAL (Jump And Link) y que las variables de stack se reservan con ADDIU (Add Immediate Unsigned). El tamaño reservado para la única variable local es de 0×20 tal y como nos lo muestra el IDA. De todos modos, en MIPS, se alinea todo a 8 bytes y, si lo necesitásemos, podemos sacar el espacio real reservado para variables restando 16 (decimal) al tamaño total que se reserva (0×30-0×10 = 0×20). Bueno, ya sabemos todo lo que necesitamos para descompilar a manopla esta función tan simple, que queda como sigue:

Este código que hemos creado, aunque perfectamente válido, no es el mismo código que ha escrito el programador ya que, por ejemplo, los tipos no coinciden. Viendo la función a la que se llama podemos sacar los tipos así que, corregimos la función:

Ahora es un poco más acertado el código De hecho, quitando los nombres de variables, el código es exactamente el mismo excepto por otro leve detalle: El tamaño de la variable de stack no coincide. El motivo es que todo se alinea a 8 bytes y 20 (decimal) no es un tamaño divisible por 8 por lo que el compilador lo alinea, quedando el tamaño de la variable a otro diferente del que ha puesto el programador.

Vamos al siguiente ejemplo. En el anterior caso habíamos visto como se reservaba espacio para una variable de stack con un programita de juguete que tenía un overflow como una casa. Ahora vamos a ver ese mismo programa calcado pero con un puntero:

Para reconstruir código, por lo general, tanto el prólogo como el epílogo nos dan un poco igual (nos interesa para saber cuanto espacio se reserva para variables locales y poco más), así que, ignoramos el prólogo y empezamos donde está el código que escribió el programador. En este caso, a diferencia del anterior, se carga la dirección de la variable “var_10″ en el registro “$a0″ (primer argumento a función) en vez de utilizar la instrucción ADDI (“add immediate”) como en el caso anterior, la instrucción LW es la utilizada para esta acción, lo cual nos indica que es un puntero. Después de esto, se establece arg_0 como el 2º argumento a función y se hace un “JUMP AND LINK” a la función strcpy. Con esto ya podemos reconstruir un poquito de código:

Ala! Así de difícil ha sido esta vez. De momento ya sabemos identificar prólogos y epílogos, como se pasan argumentos a función así como identificar variables de stack y punteros. Lo que todavía no tenemos claro es como se retornan valores y demás. Vamos a ello:

En esta función en C, copiamos un buffer con un tamaño máximo y devolvemos el tamaño de la cadena. Su código ensamblador MIPS sería el siguiente:

Ahora que vamos viendo como funciona esto podemos ver que, aunque hay más código, la diferencia no es para echar cohetes: Es más de lo mismo. Se reservan 0×20 bytes de espacio para una variable de stack, se llama a la función strncpy pasándole 3 argumentos que son, respectivamente, la variable local, el primer argumento a función y el segundo argumento a función. Después, se llama a otra función (strlen) pasándole la variable de stack que habíamos creado antes. Después, simplemente restaura la pila y se pira de la función. Empecemos a crear pseudo-código aplicando ya los tipos que las funciones utilizadas nos indican que tienen que tener las variables y argumentos:

Este código es “casi” el que escribió el programador. ¿Qué es lo que falta aquí? ¿Qué es lo que no cuadra? Que se está llamando a una función (strlen) y no se hace nada con su valor de retorno. ¿O si se hace? Si volvemos a la tabla de registros que he puesto en la introducción del artículo vemos que el valor de retorno es guardado en $v0 así que, en $v0, es donde se deja el valor de retorno de una función. Pero, ¿Y dónde se está poniendo ese valor de retorno en nuestra función? Respuesta: En ninguna parte, es en la función strlen donde se está poniendo (de hecho, en los ejemplos anteriores, el valor de retorno es el de la última a llamada a una función). Sabido esto, ya podemos cambiar nuestro código C:

Este código si que es “casi” exactemente el que escribió el programador, exceptuando temas cosméticos como indentaciones y nombres de variables, claro está.

Bueno, pues hasta aquí la parte I que ya se hace demasiado largo el post. En el siguiente, sentencias condicionales, bucles y switches. Espero que os haya gustado!

Herramientas a utilizar:

Ollydbg
IDA
Java JRE ( el compilador del redtamarin es un jar )
redtamarin ( http://code.google.com/p/redtamarin )
Alchemy ( http://labs.adobe.com/downloads/alchemy.html )
Process explorer o task manager

En su blog hace tiempo escribió una entrada llamada “Getting Pointers from Leaky Interpreters”, en la que explica como armando diccionarios de hash tables, se puede obtener un puntero hacia nuestro código.

En ese post, el mostró un ejemplo hecho en actionscript que en ese momento no supo como compilarlo como SWF, pero menciono que compilador estaba utilizando a la hora de sus pruebas.
Nuestro objetivo sera crear un SWF con un texto al estilo “Hola mundo”, y algunos XORs asi probamos que tan bien nos va identificando el código.

Primer paso: Herramientas.

Para poder generar nuestro swf a partir de un archivo .as ( actionscript ), necesitaremos descargar el redtamarin y el Alchemy.
El redtamarin es el compilador ( asc.jar ) que utilizaremos para nuestro actionscript, el Alchemynos dara la lib playerglobal.abc.
Copiaremos este ultimo file dentro del folder del tamarin como primer paso.

Segundo paso: example.as

Creo que no hace falta describir que hace esto xD

Tercer paso: Hacer nuestro swf !

Para generar un swf a partir de nuestro example.as iremos al cmd y ejecutaremos el asc.jar de la siguiente manera:

java -jar asc.jar -swf example,400,400 -import builtin.abc -import playerglobal.abc example.as

Lo único a comentar aquí es que el parámetro swf tiene como parámetros: classname,width,height.

El resultado de la ejecución en nuestro caso es: example.swf, 645 bytes written

Para ver nuestro swf podemos simplemente volcarlo dentro de nuestro navegador, o hacer algún simple html que lo cargue:

Vemos que va bien.. ahora le agregamos un simple while(true) para que podamos usarlo para encontrar el código JITeado.

Aprovechamos y también le agregamos algunos valores para que los xoree, y de paso ver si lo podemos identificar en el debugger mientras vamos traceando.

Cuarto paso: Debuggear el codigo JITeado.

Abrimos nuestro html, y antes de cargar el swf nos pide permiso para ejecutarlo, aquí nos attacheareamos con el Olly al IE8 en nuestro caso y veremos mínimo dos procesos del iexplore.exe corriendo, vamos a attacheanos al que tiene como window name Sysfader.

El taskmanager o el process explorer lo dejaremos minimizado al tray asi podemos estimar que cuando entramos al loop infinito en nuestro código JITeado.

Le daremos Run al Olly, parara algunas veces en memory breakpoints en el flash10b pero nosotros seguiremos hasta que no tire excepciones y el cpu este como mencionamos anteriormente trabajando de manera constante al 100% ( en caso de que sea single core ), en este momento pausamos el proceso.

Iremos a la ventana de Threads, y buscaremos el nuestro que estará en el heap, ya que la mayoría van a estar parados en la ntdll sera sencillo encontrar el único thread diferente.

Aquí pueden pasar dos cosas: la primera es que no estemos en el loop infinito, entonces empezaremos de 0 nuevamente, o bien puede ocurrir que encontremos el thread parado en el heap como en este caso:

Ahora veamos el codigo algo mas completo:

<span style="font-size: x-small;">019C01E1 MOV EAX,DWORD PTR DS:[25EB0D8]
019C01E7 TEST EAX,EAX
019C01E9 JNZ 019C025F
019C01EF MOV EAX,1
019C01F4 TEST EAX,EAX
019C01F6 JNZ 019C01E1
019C01FC PREFIX REPNE:
019C01FD MOVUPS XMM0,DQWORD PTR DS:[25815E0]
019C0204 PREFIX REPNE:
019C0205 MOVUPS XMM1,DQWORD PTR DS:[25815E8]
019C020C PREFIX REPNE:
019C020D MOVUPS DQWORD PTR SS:[EBP-2C],XMM1
019C0211 PREFIX REPNE:
019C0212 MOVUPS DQWORD PTR SS:[ESP-8],XMM0
019C0217 SUB ESP,8
019C021A CALL Flash10d.101F1C30
019C021F ADD ESP,8
019C0222 MOV EBX,EAX
019C0224 PUSH DWORD PTR SS:[EBP-28]
019C0227 PUSH DWORD PTR SS:[EBP-2C]
019C022A CALL Flash10d.101F1C30
019C022F ADD ESP,8
<strong>019C0232 XOR EBX,EAX</strong>
019C0234 PREFIX REPNE:
019C0235 MOVUPS XMM0,DQWORD PTR DS:[25815F0]
019C023C PREFIX REPNE:
019C023D MOVUPS DQWORD PTR SS:[ESP-8],XMM0
019C0242 SUB ESP,8
019C0245 CALL Flash10d.101F1C30
019C024A ADD ESP,8<strong>
019C024D XOR EBX,EAX
019C024F XOR EBX,DDDDDDDD</strong><strong> ; It looks familiar right ?
019C0255 MOV EAX,4
019C025A JMP 019C0267
019C025F MOV ECX,DWORD PTR SS:[EBP+8]
019C0262 CALL Flash10d.1020E410</span>

Quinto paso: Automatizando con un script

Hay varios caminos para tomar a la hora de llegar a donde empieza realmente nuestro código JITeado, adjunto un simple ODbgScript que mediante hardware breakpoints en VirtualProtect nos guiara hacia la presa
Ejecutarlo una vez que tira la primer excepción como explicamos mas arriba en el posteo.

De aquí en mas pueden agregarle código a su Actionscript y seguir jugando

Se agradece a Acid y Gera que colaboraron con el debugging del engine de Flash.

Pero sin iPad ni iPod, ni siquiera es Steve Jobs. Es un servicio que ofrecemos a la “comunidad” esperando que pueda ser útil para alguien, en éstos tiempos tan jodidos que estamos viviendo.

http://jobs.48bits.com es un apartado dedicado exclusivamente a ofertas de trabajo que estén relacionadas con la seguridad informática, en mayor o menor medida.

48bits tiene una media de 1000 visitas únicas al día, incluyendo mucha gente técnica, por lo que es un lugar ideal para dar a conocer aquellos puestos que requieren habilidades “no habituales”.

Dejar claro que nuestro objetivo con esto es facilitar que jóvenes, o no tan jóvenes, encuentren un puesto de trabajo. Por ello no buscamos un beneficio económico, este servicio es totalmente GRATUITO para las empresas.

Todas las empresas que deseen insertar sus ofertas de trabajo en 48bits, o publicar cualquier tipo de información laboral de interés para la comunidad, nos pueden escribir a jobs(at)48bits(dot)com.

Si tienes dudas acerca de los términos de la publicación de la oferta de trabajo, escríbenos sin dudarlo.

Suerte!