DisidentS Team

Muy bien, he encontrado por ahí un buen crackme, un poco raro, con una proteccion linda de explicar, mas adelante les explicaré algunas técnicas y trucos de cómo podemos encontrar “pistas” para poder vencer estos hermosos juguetes llamados crackmes.

Empezaremos por el principio, como siempre debemos empezar, mirando la víctima, ejecutemoslo… listo? ¿Que tenemos?, una hermosa ventanita con un menú file, con la opción exit, y otro menú help con la opción register y about.

Experimentando con la bestia

Bueno, que sucede si hacemos click en la opción register del menú help?, nos aparece una ventanita que nos dice “Kill the nagscreen”, estas ventanitas, con esos iconos característicos son generalmente llamadas con una API llamada MessageBox o MessageBoxA, dependiendo si la aplicación es de 16 o 32 bits respectivamente.

Aquí ya tenemos una pista, estas eran las “pistas” que yo les mencioné anteriormente, que sirven para guíarnos a través del código.

Otra cosa interesante, es que aparece una ventanita aleatoriamente diciendo algunas cosas sin sentido e incitándonos a crackearlo. Destruyámosla.

Si hacemos click en la opción About, nos da datos sobre el autor del crackme, y demás cosas, que no tienen mucha importancia.

Reglas de juego

Ahora veamos que nos pide el autor del crackme, y seamos chicos aplicados cumpliendo con todo lo que él dice, al pie de la letra, ¿están listos? ¡¡Adelante!!

Bueno, dice que saquemos el messagebox que aparece cuando hacemos click en register, lo haremos, y luego debemos matar la ventanita chiquita que nos incita a crackearlo.

Sobre las “pistas”, API’s, y reconociendo patrones de código

Tenemos siempre, que tratar, debido al gran caos del código desensamblado de un programa, tener referencias y entender lo útil y principal, lo que verdaderamente está sucediendo en partes o en la totalidad del programa, para poder “descifrar” el funcionamiento del programa, encontrar la protección y poder anularla.

Otras veces, deberemos entender, varias cosas antes de desensamblar un programa, cuando veamos ejercicios del tipo reverseme’s, ya verán de lo que les hablo.

Las pistas que debemos encontrar, son las API’s, debemos conocer las más comunes , sus parámetros, sus valores de retorno, su función principal, aquí les detallo algunas:

MessageBox SystemTime Hmemcpy
OpenFile GetLocalTime
DialogBoxParamA createwindow
GetDlgItemText createwindowexa
WriteFile showwindow

Bueno, la mayoría de estos nombres de API’s se explican por sí solos, así que no hay que preocuparse mucho, lo que sí, les mostraré ahora algunos que he estado descubriendo, por ejemplo en este crackme, encontré uno que me sirvió y me dio la pista para poder matar la nagscreen que nos incita a crackear el crackme.

La API que me guió hasta esa ventana es, CreateThread , en breve les mostraré porqué y como razoné para deducir que esa API era la responsable.

Los patrones de código son reconocibles, con la práctica, el ojo humano al principio debe acostumbrarse a leer ensamblador, como dije antes, todo código sea ensamblador, c++, basic, pascal, es caótico, tiende a ser caótico.

Cuando programamos un sistema por ejemplo, un programa muy grande, debemos documentar debidamente cada función, cada proceso creado, que valores retorna, porque, y como funciona, para futuros arreglos o implementaciones, debemos organizar, e identar todas las instrucciones correctamente, sino sería ilegible, o muy difícil de entender, y aunque ustedes no lo crean, se hacen concursos de “ofuscados” son programas que hacen algo, como un cálculo o alguna cosa simple, pero que el ganador es aquel que lo hace “menos entendible”, sin querer decir que programe “suciamente”, simplemente hacerlo lo mas ilegible posible. Pero no nos meteremos en esos campos extraños de la informática.

Un programa desensamblado, es lo mas terrorífico que un programador se puede encontrar, el algo verdaderamente ilegible, si no se tiene el conocimiento real de la situación a bajo nivel, y cierta práctica como para reconocer los patrones de código de los cuales les hablo.

Cuando usamos Vc++, VB, Delphi, o algún otro RAD, el código generado por estos compiladores, se repite muchísimas veces en distintos programas programados bajo el mismo lenguaje, permitiéndonos, con la práctica ( o un buen tutorial a mano sobre el tema ) poder reconocer por ejemplo, cuando el programa chequea si las opciones de los menúes fueron clickeadas, etc.

¡¡Al Ataque!!

Muy bien, aclaradas algunas cosas antes, vayamos a nuestro pequeño ejercicio, haber si podemos calentar un poco nuestras neuronas…

Veamos de que se trata, a mí me gusta saber en que lenguaje está programada mi víctima, para saber con quien estoy “hablando”, es como una presentación…… bueno dejenme, son mañas.

Corramos el programa Language 2000, arrastremos la víctima hacia language 2000, y que nos dice…. Que está programado en Visual C++, ohps! muy bien, y ¿ahora que?, bien respiremos profundamente, porque cuando los programas están programados en Vc++, en C++ o en C, significa, que su código desensamblado, será más entendible (eso no significa más fácil). ¿Por qué digo esto?, porque cuando trabajamos con programas programados en VB, por ejemplo , este lenguaje es interpretado, y necesita runtimes, utiliza funciones propias del lenguaje, las cuales debemos analizar para que sirve cada una, porque raramente llama a una API, salvo que sea una llamada directa hecha por el programador.

Programas hechos en VB o en Delphi por ejemplo, tienen patrones de código bien reconocibles, y llamadas a rutinas, que realizan el trabajo “sucio”, entonces, el código desensamblado es mayor, mucho más caótico y difícil de descifrar si no tenemos la suficiente paciencia, pero no es imposible, no se me desanimen.

Ahora, tomemos un desensamblador, como por ejemplo el IDA, muy bueno a mi parecer, hace el código muy entendible, y tiene las librerías llamadas FLIRT, que si sabes en que está programada la víctima, puedes cargar una FLIRT para reconocer rutinas propias de los programas generados con X lenguaje, entonces de esa manera se entiende mucho más fácil, y puedes ir al punto directamente sin dar muchas vueltas.

Bueno, empecemos por lo más sencillo, buscar strings references, esto es lo más sencillo, porque nos lleva al punto directo, de cuando el mesagebox o X componente fue creado con X texto que busquemos, que no estará muy lejos de la llamada API correspondiente, les muestro que sucede en nuestro crackme:

Buscamos el texto “Kill the nagscreen.”, y lo encontramos, ahora hagamos doble click en él y nos lleva hasta aquí :

push offset aCanTRegister ; “Can’t register”
push offset aKillTheNagscreen_ ; “Kill the nagscreen.”
call ds:MessageBoxA

por problemas de espacio he dejado las instrucciones más importantes, a continuación explico cada una:
el primer, push es un parámetro al igual que el segundo push, debemos saber por eso que parámetros necesita la API MessageBoxA, para poder saber que esos son los parámetros usados para mostrar nuestra ventanita, que debemos anular.

Miremos un poco mas arriba en esa rutina y encontramos esto:

_text:00401355 loc_0_401355: ; CODE XREF: _text:0040132D j

hagamos click en la parte resaltada con amarillo y nos llevará al lugar desde donde es llamada esta rutina para mostrar la ventanita.

Aquí nos lleva:
jz short loc_0_401355

Ok, este es el salto que produce la ventana, matémoslo bruscamente, para eso usemos la instrucción NOP (No OPeration), para anular ese salto, el código de operación de esta instrucción es 90, ¿Qué es código de operación? Simplemente, el valor que toma la instrucción cuando es compilada por la computadora, entonces para entendernos con ella crudamente, debemos hablar su mismo idioma, esto quiere decir, tomar un editor hexadecimal, como hex workshop por ejemplo e ir al offset, de esta instrucción el cual nos dice IDA debajo de todo en el cuarto campo, este es 132D.

Como estos saltos ocupan dos posiciones compilados debemos poner dos NOP’s, o sea dos 90, en esa posición y en la que sigue.

Ejecutemos la víctima, hagamos click en la opcion Register…… ¡Bingo!

Ahora, vamos por la otra ventanita, esta ventana es creada debes en cuando, no tome el tiempo, pero estimo que si no es por tiempo fijo, es aleatoria, eso mucho no interesa, ya que lo que queremos es anularla, entonces, lo que me guió a mí como ya les comenté es la API CreateThread la cual sirve para crear un nuevo hilo de proceso, mientras la aplicación principal se ejecuta en otro proceso distinto, entonces, los mensajes de una ventana no traba a la otra, permitiendo el efecto “multitarea”, la teoría de programación multihilo es muy interesante pero no profundizaremos en esto más que por la definición que acabo de dar.

Busquemos el string “Kill the nagsreen.” De nuevo, miremos un poco más debajo de esa rutina y aparece nuestra querida API CreateThread, de esta manera: call ds:CreateThread

Ok, hagamos doble click la referencia de que hace al principio de la rutina, como la rutina analizada anteriormente, esto nos dice desde donde es llamada la rutina, viendo directamente el salto que debemos NOPear en nuestro caso.

Nos lleva aquí: jz short loc_0_401374

El cual debemos topear igual que el otro salto, para que ya no tenga más efecto esa rutina, y la asquerosa ventanita aleatoria no aparezca más.

Como verán, existen muchísimas formas de proteger un programa, y yo en particular pienso que deben existir cientos de otras formas, mezclas de protecciones, como por ejemplo la que acabamos de ver, en la que se implementa muy bien la API CreateThread, para crear una ventana nueva, y además una nag screen en la opción register.

Más adelante veremos, protecciones CD-Check, y quizás vayamos mas arriba aun, código automodificable, encriptación, key-files, etc.

Cada una, tiene su pro y su contra, en algún momento quizás también nos topemos, con programas que verdaderamente son DEMOS, y les falta implementar la opción “Save as…”, por ejemplo, en estos casos, usaremos las técnicas de reversing, en la que deberemos saber Win32Asm (ensamblador de 32bits para Windows), hacer injertos de código, conocer la estructura de los archivos PE, y demás cosas muy interesantes.

También, en esta carrera nos toparemos con los “loaders”, programas que parchean en memoria, y desprotegen “runtime” a los programas, veremos como funcionan, como hacer uno propio, en un lenguaje fácil (VB, Delphi), cuando y como usarlos.

Quizás lleguemos a ver mas adelante, protecciones llamadas dongles, las famosas “mochilas”, esta es una protección por hardware, que necesita de un determinado hardware conectado a uno de los puertos de la pc, para que el programa funcione.

El cracker, debe tener una mente abierta, analizar un programa protegido, es toda una aventura, es conocer, aprender, desafiarnos, y crecer, en conocimiento, y sobre todo en paciencia.

Ok, hasta aquí hemos llegado, para la próxima veremos opciones desactivadas y/o cd-checks.

¡Suerte!
¡Happy Cracking!

SparK

convert this post to pdf.