En el curso de Coursera de Malicious Software and its Underground Economy (https://class.coursera.org/malsoftware-002) que estoy siguiendo estos días nos pusieron un reto de un "crackme" donde había que ejecutar un programa e intentar introducir la palabra clave secreta correcta por teclado.
El ejecutable se puede encontrar aqui.
La pregunta era simple, e incluso traía pista, cosa que a mi al final me dio mas problemas que ayudas, ya que como veremos la pregunta no esta muy bien hecha (Hacer click para aumentar las imágenes):
Lo primero, pues era probar el ejecutable, que resultó ser un ejecutable ELF de Linux:
Como vemos a veces devolvía "Maybe" y a veces se quedaba bloqueado. Un "strings" también daba información interesante.
Así que el siguiente paso fue abrirlo en el IDA Pro, que nos descubrió un total de 5 funciones interesantes. Todas ellas sin nombres reales, solo mis amigas Sub_80489E3, Sub_8048776... vamos, muy agradable todo. No tardamos en encontrar una subrutina que tenia todo el aspecto de ser un main, el sub_8048A24 y que además contenía la parte donde se nos pide la cadena de texto:
...donde a grandes rasgos, se llamaba a una funciona anti-debugging, nos mostraba un texto, nos pedía el código y comprobaba si el primer carácter eran una C, una A o una N y en función de la letra que fuera, llamaba a una subrutina diferente.
La subrutina de anti-debug (la sub_80489E3) es bastante simple:
...y la sorteé modificando el ejecutable y sustituyendo el JNZ loc_8048A21 por un JMP 0x8048A21.
La subrutina de la "C", como yo la llamé, es decir la que se ejecuta cuando el texto introducido comienza por "C", básicamente no hacía nada. Creaba un fichero temporal en el que escribía "Woot!":
La subrutina de la "A" era más compleja, pero después de un rato me di cuenta que lo unico que hacia era conectarse con una IP y un puerto y hacer un netcat al mismo. Luego veremos por qué. Esta subrutina no tocaba para nada la cadena introducida por teclado.
Así que el meollo tenía que estar en la rutina "N", como yo la llamé o sub_8048743 como lo hizo mi amigo IDA. Sin embargo esta rutina es muy simple. Liosa, pero simple:
No tenía mucho sentido... hasta que me fijé en la linea roja del final de la función. Resulta que cuando IDA Pro detecta algún tipo de error en la instrucción RET, la pone en rojo. ¿A ver si es que no la va a ejecutar... y no vuelve a la funcion main?. ¿Y que hay despues de la funcion "N"?. Pues esto:
Al instante me llamó la atención la cadena "@EHJ@DZEL" de la ultima línea. Tras un rato de desensamblaje y con la ayuda del GDB (ya que parece que IDA no deja debuggear ejecutables en ELF, o al menos yo no se) descubre que ese trozo de código del centro lo que hace es sumar uno a cada caracter introducido y hacerle un XOR con 02Ah. Y claro, luego se compara con ese "@EHJ@DZEL" para sacar un texto u otro. Dos minutos más y sacamos el codigo descifrado: "ina_Simone". Siempre con la "N" delante, claro. Lo probamos en nuestro Linux y Eureka:
De ahi lo de hacer el netcat a esa IP y puerto.
Ahora ya sólo tenemos que escribir la respuesta (ina_Simone) en el "examen". Pues no, resulto que lo de "it's part of the input you provide and it is not the output the program produces" no era exactamente así. La respuesta correcta es "NiXx_SimXxe" (Lo haré publico cuando termine el periodo de evaluación) que es la entrada completa (no parte de ella) y la salida del programa también. En fin, a veces dar pistas lleva a mas confusión que ayuda.
Y esto es to, y esto es to, y esto es todo amigos!!
No hay comentarios:
Publicar un comentario