Me he quedado atascado en el nivel 11. El proceso de solución que he seguido es el que plantea Txipi, el organizador de la prueba, en su blog. En esa página podemos encontrar indicaciones para solucionar casi todos los retos planteados, pero en ocasiones son precisamente eso, indicaciones, no se muestra el proceso en detalle.
El nivel 11 nos plantea el siguiente reto: dado un fichero ejecutable ELF, crackearlo para obtener la clave que esconde. Tras analizar el fichero vemos que está cifrado/comprimido con UPX (upx.sourceforge.net) Este tipo de compresión no es como la típica .zip, .rar, etc. sino que UPX comprime las ecciones internas del ELF, añadiendo al ejecutable una rutina de autodescompresión.
Lo anterior, si fuera tal cual, cual no sería problemático: se descomprime con el propio upx y listo (upx -d fichero_elf) . Pero estando en el nivel 11 del juego, lógicamente, la cosa no es tan sencilla. El autor del reto ha eliminado cadenas del ejecutable de tal forma que al intentar la escompresión (upx -d) el UPX dice que ese fichero NO está comprimido con él. Así que hay que reconstruir las secciones del UPX (básicamente, saber qué han eliminado/cambiado y volverlo a poner). El proceso consistiría en comprimir con UPX varios archivos ejecutables onocidos y extraer las cadenas o características propias de UPX. Una vez hecho eso y con el conocimiento de las cadenas típicas que un fichero comprimido con UPX muestra, comparar con el archivo que nos dan y ver qué demonios han eliminado. Tras hacer este trabajo, podemos ver que han sustituido las apariciones de la cadena UPX (55 50 58 en hexadecimal) por (20 20 20).
¡Ah! parece pan comido. Más adelante, se ve que no sólo han hecho la sustitución previamente indicada, sino que también han cambiado una cadena más completa del tipo «This program has been compressed using UPX version .01…» o similar, convirtiéndola también a caracteres 20 20 20.
Hay distintos editores de hexadecimal, pero como últimamente uso VIM para casi todo, he editado también el fichero ELF con este editor (hay que teclear :%!xxd para convertirlo a hexadecimal y poder editar. Una vez terminada la edición, hay que realizar el proceso inverso con :%!xxd -r y guardar :wq) Tras arreglarlo, intentamos la descompresión y upx dice que tururú, que las cabeceras siguen estando mal.
Analicemos más a fondo: los últimos bytes de un fichero UPX suelen seguir también un patrón del tipo XXXXnumeritosYYYY. Y podemos comprobar que el fichero que nos dan, NO lo sigue. Añadimos esa última sección y ahora, el comando «upx -l» indica que OK, que eso sí es un fichero UPX, pero cuando lanzamos el comando «upx -d» contra el fichero arreglado, para descomprimirlo, nos indica el siguiente error
Exception: compressed data violation
y no descomprime nada. El problema es que no sé cómo arreglar este problema, me he atascado :-O . En mi opinión l error se debe a que en la cadena del final, XXXXnumeritosYYYY, los numeritos, tras distintas pruebas, he visto que son DISTINTOS dependiendo del
archivo que comprimamos. Y ahí me pierdo, porque no sé qué algoritmo seguir para generarlos… Aunque tal vez no sea ese el problema. ¡ Agradecería cualquier ayuda !
El archivo level-11-solved es el que he reconstruído a partir del original para conseguir que UPX lo detecte como propio.
Creo que te seria mas sencillo implementar un descompresor con algún lenguaje sencillo visto el tiempo que se tarda en deducir los cambios por «fuerza bruta», yo buscaría las especificaciones.
Un saludo.
Disculpa que no tengo idea y opino, pero los numeritos podrian tener algo que ver las direcciones de comienzo y fin del bloque a descomprimir, o bien el tamaño del mismo?
A lo mejor esos numeritos son algún tipo de resumen de los datos comprimidos a modo de CRC.
Lo más rápido es buscar información de cómo funciona UPX. El resto sale solo.
Me alegra mucho que incluso un año después, el hackit del 2006 sigue dando horas de «diversión» 😀
Happy hacking 😉