Este nivel nos trajo por la calle de la amargura. Tenemos como pista el cómic de la izquierda. Lo siguiente que nos dicen es que la solución está en este fichero. También tenemos esta otra imagen como pista…. ¿Qué es? ¿Un S.O.S.? No lo sabemos…
Finalmente, si sacamos los strings del fichero binario obtendremos algo de información. Se ve que hay una cadena que podría ser el password cifrado de alguna forma… también vemos un 2061 (¿tercera parte de la saga de una odisea del espacio?) Pero no sabemos cuál es el método a usar para pasar esta fase. ¿Y cómo nos la pasamos nosotros? Jugando con lo que supuestamente debería ser el pass cifrado (M5O1V0R81)… pero no nos gustó el procedimiento, así que… ¿alguien (marcan, lothwen, abeaumont…) sabe cuál es la forma ortodoxa de superar este nivel? Agradecería comentarios al respecto, para que no se me quede esta espina clavada 🙂
Este nivel lo sacaron dani y ramandi, realmente les corresponde a ellos explicarlo 😛
pero antes de irme a sobar me pelee un rato con el.
mi forma de proceder: hd binario copio los 4 primeros bytes y a google 😀
«01 08 0B 08»
lo que sigue es trivial 🙂
Bueno, este nivel a nosotros nos costó más saber de qué era, que ver como atacarlo. Una vez vimos algunas cadenas que nos podían dar pistas hicimos una búsqueda en google, sobre todo la pista de que las primeras letras de algunas cadenas estaban con el bit7 a 1. Lo mismo en la cadena que se entiende ha puesto el compilador para interpretar números hexadecimales.
Una vez identificado que es un archivo de C64; lo intentamos decompilar con IDA, y sacamos poca información, así que nos aventuramos con un emulador con debugger incorporado… y ahí empieza toda la aventura. Lo primero de todo, una vez cargado el archivo en el emulador, si tecleamos «list», para ver qué basic hay cargado, nos sale una sola linea: 723 sys2061 .
El comando sys en C64 ejecuta código máquina en esa dirección, así que ya sabemos que ahí se inicia el programa que pide la password… a partir de ahí, pelearse con el debugger del commodore 64. En nuestro caso probamos 2 emuladores, el vice, que a mí me liaba mucho el debugger en modo consola… :/ Y el no$c64 ; cuyo debugger si pinchabas en la pantalla del emulador entendía que era «run»… Una vez fuimos debuggeando en el emulador de C64, vimos que la cadena que nosotros introducíamos la iba xoreando con unos valores incrementales de multiplos de 2. 1, 1, 2, 2, 4, 4, 8, 8, y 16; y que después la comparaba la cadena hardcodeada y mencionada ya en vuestro artículo.
@thEpOpE : muchas gracias por desarrollar la solución! Nos tuviste un buen montón de horas con tu máquina polaca RPN, nos acordamos mucho de tí, pero en el fondo nos gustó mucho XDDD Ya lo verás en el post del level 8.
Hola,
os cuento cómo lo resolvimos nosotros… es más que posible que haya fallos, así que si los detectáis no dudéis en decírnoslo.
En primer lugar… el cómic a priori no era una pista, sino la triste realidad de los troleos que aguantamos de marcan habitualmente xDD. A los que nos visitaron en el canal les dirigimos a la verdadera pista, que es el logotipo de SOS.
Buscando por imágenes a partir de dicho logotipo llegamos al logotipo de MOS Technologies (https://www.google.com/search?q=mos+technologies&ie=utf-8&oe=utf-8&channel=suggest) y nos lleva a pensar que es un binario de Commodore. Esto se refuerza porque también aparece en alguno de los resultados buscando por «01 08 0B 08», como apuntaba aMoK.
aMoK localizó el emulador con debugger no$c64 que resultó imprescindible para nuestra resolución: http://nocash.emubase.de/c64.htm
Además de debuguear, el emulador nos permite exportar el desensamblado a un fichero de texto para analizarlo cómodamente. Desensamblamos a partir de la dirección 801h de memoria, que es donde encontramos la primera instrucción del binario (sin haberlo analizado en profundidad, parece que los 2 primeros bytes del fichero indican que se cargue el programa a partir de esta dirección).
Si recuerdo bien, a partir del listado y jugando con el debugger, identificamos dos bucles en lo que parecía el programa principal (en el offset 124Fh): uno con algún tipo de inicialización que no tuvimos que analizar; otro para leer caracteres que no sale del bucle hasta recibir al menos 8 caracteres. Tras salir de este segundo bucle identificamos las direcciones de GoodBoy (0A8Eh) y BadBoy (0A95h) y vemos que la decisión de salto se toma en función de la respuesta de la funcion 1117h a la que se llama desde 0A83h, por lo que decidimos analizar dicha función.
Pese a la dificultad de trabajar con un ensamblador que no conocíamos, llegamos a identificar que estas dos instrucciones se encargaban de la comparación de cada carácter:
RAM :1135 B1 0A mov a,[[0A]+y]
RAM :1137 D1 0C cmp a,[[0C]+y]
Con el debugger pudimos comprobar que no veíamos nuestra entrada tal y como la habíamos introducido, aunque las variaciones parecían pequeñas y enseguida sospechamos que se estaba efectuando algún xor. Para ver con qué estábamos comparando, dani tuvo la gran idea de sustituir la instrucción de 1135 por «mov a,[[0C]+y]», de manera que las comprobaciones siempre eran correctas y podíamos ir viendo el valor con el que comparábamos en el registro ‘y’ de forma muy rápida. Como cabía esperar, era la cadena que se veía en el binario haciendo un strings: M5O1V0R81
En una segunda fase, volvimos a dejar la instrucción original y fuimos comparando lo que introducíamos con el valor que veíamos en ese punto, y parecía que se estaba haciendo un xor carácter a carácter con la siguiente secuencia: x21x01x22x02x24x04x28x08x10
Realmente no era así, el xor se realizaba contra x01x01x02x02x04x04x08x08x10, pero la codificación de caracteres era distinta. Pudimos comprobarlo en la dirección de memoria CFF2h en la que se dejaba la password que metíamos (y se modificaba sobre la misma dirección). Posteriormente marcan nos ha aclarado que usa codificación PETSCII en vez de ASCII, por lo que el valor de las minúsculas ASCII coincide con el de las mayúsculas PETSCII, mientras que las mayúsculas se van al rango C1h-DAh. Dicho de otro modo, lo que con strings veíamos como M5O1V0R81 al hacerlo desde máquinas ASCII, era en realidad m5o1v0r81 para el Commodore, mientras que si hubiera contenido mayúsculas de Commodore habría caracteres extraños para nosotros. Tengo serias dudas de qué habría pasado si la contraseña hubiera incluido letras mayúsculas, porque incluso el debugger de C64 interpreta las cadenas como ASCII en el dump de memoria ;-).
Ya sólo nos quedaba aplicar el xor (en realidad íbamos haciéndolo sobre la marcha) para descubrir la contraseña: l4m3r4z0!
Uhm… después de todo el cómic sí era una buena pista 😉
Delicioso análisis. Mila esker! Ah! el S.O.S era la «farsa» (pun intended) de icono de MOS Technologies! Con este desarrollo (yo estaba probando con vice tras la explicación de aMoK… ya veo que mejor no ;-P ) y la explicación del gráfico ya me puedo ir tranquilo a dormir. El año que viene nos pasaremos por el canal #w0pr a saludar 🙂
@ramandi: no es casualidad que no aparezcan mayúsculas… se eliminaron para evitar problemas.
Lamentablemente no tengo el código original a mano para postearlo, pero la rutina era bastante simple, un read de los caracteres + el xor que mencionáis y la comparación con el string. Escrito con un compilador de C para 6502: http://www.cc65.org/