HackIt, SolveIt and SmashCTF (II). カッター注意

Nos pasan una captura .pcap que abrimos con Wireshark. Vemos en los primeros paquetes UDP que el dispositivo 10.10.0.78 se está comunicando con el 10.10.0.70.

Según la MAC, el .78 ha sido fabricado por CASIO (lo que cuadra con la pista del level). Se trata de un tagger (según los strings de los primeros paquetes), y parece que el modelo es un MEP r2 (?). Buscando Casio Tagger MEP en Google, sale una pequeña impresora o etiquetadora. Si buscamos en el Twitter de marcan algo relacionado con las palabras clave:»casio marcan42 twitter»… Bingo!

Es más, el tweet en cuestión apunta a un Gist con un programa en Python que implementa el protocolo de la impresora para poder convertir, enviarle e imprimir imágenes a partir de ficheros.

Leyéndolo mientras tenemos el pcap abierto, vemos que inicialmente se realiza un primer intercambio de mensajes de protocolo (donde se especifica, entre otras cosas la altura y anchura de la imagen)

>>> import struct; struct.unpack("

Hay 368 filas * 16 columnas de bytes. Por tanto 16x8 = 128 bit en cada fila.

Los datos de la imagen en sí comienzan a enviarse a partir del paquete 43 (todos aquellos con un payload de 512 bytes). Ya tenemos todo preparado para extraer los datos que forman la imagen.

Si ejecutamos el script:

python leer.py > payload.bin

Podremos resolver directamente con:

xxd -b -c 16 payload.bin

Pero ya que tenemos el código para hacer el encoding de una imagen a 1's y 0's, podemos invertir el proceso fácilmente:

Y resolver 🙂

PD: カッター注意 = Cutter Attention ? (algo así como, "cuidado con la cuchilla" - que corta los trozos de papel de la impresora?)

HackIt, SolveIt and SmashCTF: aprender es un regalo (I)

Como todos los años, desde la Euskal Encounter 7 (antes Euskal Party), acudimos a la cita. La cuestión no es sólo intentar ganar (que también), sino aprender. Y aunque cada vez conocemos más técnicas, herramientas y teoría de nuestra área, en muchas ocasiones, tras pelearme con las pruebas del HackIt y SolveIt, me da la sensación de que mis lagunas de saber son también cada vez mayores. ¿Qué sé de la codificación Manchester? ¿Qué demonios es Toslink S/PDIF? Por no hablar de conocimientos olvidados hace muuucho tiempo (¿cuál es la estructura química de la aspirina?). Pero…

«El éxito es aprender a ir de fracaso en fracaso sin desesperarse (Winston Churchill)»

Así que, cada Euskal, los incombustibles de DiarioLinux (tal vez el año que viene seamos Ikasten.io, ahora que está de moda cambiarse de nombre, ¿eh Failrz? :), volvemos a intentarlo.

En el HackIt de 2018 quedamos en tercera posición, pero conseguimos resolver tres pruebas (y la tercera, tras mucho dolor, a eso de las 5am del sábado). En el SolveIt no nos solemos obcecar tanto, y este año, sólo pudimos resolver la primera prueba. Un FAIL doloroso, sí.

«Aprender es un regalo, aunque a veces el maestro sea el dolor» (Anónimo)

Nos gusta comentar las pruebas una vez que termina el deadline. Las locuras (trolleos) de marcan y cómo nos hemos buscado la vida para resolverlas. En esta edición, hubo un debriefing con las tres secciones (HackIt, SolveIt, SmashCTF) a las 00:00 del domingo (justo tras el deadline) y ahí, cuando aún tienes frescas las ideas que has ido probando durante unas 60 horas -y tienes una terrible curiosidad -«jakin-mina»- por conocer la respuesta de ciertos retos que no te han dejado dormir, es cuando realmente prestas atención a las explicaciones. Cuando tienes sed por aprender. Y cuando aplaudes los esfuerzos de otros grupos por superar el dolor – sueño, cabreos y dolores de cabeza 🙂 de intentar avanzar una prueba más, de leer con más detalle una especificación, de entender hasta el más mínimo detalle un binario de una plataforma arcaica… Creo que ese esfuerzo, esa motivación por mejorar, es lo que me contagia y hace que, año tras año, deje todo por estar ahí.

Y sin más preámbulos ( ni citas ! 🙂 , vayamos con la chicha. Prueba 1 del HackIt.

Simple código en JavaScript que opera con los valores introducidos en el input, realizando 10 comparaciones (2 por cada vuelta, 5 vueltas) para confirmar que cumplen los criterios que lo validan como contraseña. La variable c lleva el contador de condiciones que se cumplen. Lo único que despista inicialmente es que suma dos booleanos ( condición booleana + condición booleana). La idea es que false se evalúa como 0 y true como 1.

Aunque inicialmente pensamos en resolver el level de manera ortodoxa (resolver el sistema de ecuaciones), al final consideramos mucho más rápido usar fuerza bruta – pulsa sobre la imagen para ampliar – 🙂


Y con un console.log(solucion), pasamos al siguiente nivel…

HackIt! 2017 Level 5. Desempolvando el viejo MacOS

Ojo, ¿qué ha pasado con el nivel 4? W0pr lo ha descrito a la perfección usando Radare. La verdad es que es una delicia leer sus posts. En lo que a DiarioLinux respecta, lo solucionamos usando IDA Pro (en casa del herrero cuchara de palo) Bueno, realmente lo solucionó Kotxerra mientras nosotros dormíamos plácidamente a las 4AM. Echadle la culpa a él, por ser tan eficiente 😉 De hecho, nos impartió un mini-taller sobre la solución. Lo tengo documentado en uno de los backups que hice, así que en cuanto tenga un rato, lo desempolvaré para dar otra posible solución.
Lo que me interesa ahora es mostrar cómo abordamos el nivel 5. Poca gente lo solucionó… si no recuerdo mal (y el pantallazo de este post así lo ratifica), sólo W0pr (hats-off again) Por lo que comenté con ellos, hicieron análisis estático del código desensamblado. Nosotros seguimos otra vía, seguramente más tortuosa (y obviamente con peores resultados) pero interesante como ejercicio. Pero vayamos por partes. ¿De qué trata el level 5, Infinite Loop? Nos pasan un archivo infiniteloop.sit que hay que crackear. Los ficheros .sit son archivos comprimidos (Stuffit) que guardaban el ejecutable de los viejos MacOS 9. Ojo al parche, porque lo primero que se nos ocurrió fue encontrar un descompresor para Linux, ejecutar un emulador de MacOS9 sobre el ejecutable y depurar. No íbamos mal encaminados… Salvo que los .sit guardan datos de recursos (conocidos como «resource forks«) y metadatos del ejecutable y, sin ellos, el ejecutable realmente no sirve para nada. Nótese la «gracia» del título del level (A fork in the road…)

Long story short, encontramos la forma de instalar un emulador de MacOS 9 (la versión 9.2, no valía ni la 9.0, ni la 9.1, por experiencia) sobre qemu… sobre MacOSX Sierra :), tras muchas vueltas, usando SheepShaver. Cuando digo muchas vueltas estoy hablando de unas 5-6 horas, con gente muy experimentada. Fallaba por todos los lados: la instalación, el sistema de archivos, cuelgues en medio de la instalación, and the kitchen sink.

Pero finalmente, conseguimos instalarlo, subir el .sit.hqx y ejecutar. ¡Magia!

Cuando lo comentamos con @marcan42 vimos brillo en sus ojos: «¡Por fin alguien que lo ha ejecutado!». Y no me extraña, la verdad. Sin embargo, las cosas no eran tan fáciles como nos esperábamos…

Lo primero que llama la atención es que, tras teaclear el código de unlock, asumíamos que podríamos cancelar y volver a intentarlo con otro código (básico para poder depurar). Pero no, la ventana de FAIL se quedaba fija en pantalla y NO había forma de quitarla, teniendo que resetear la máquina entera (OMFG!)
Lo siguiente que intentamos fue instalar un debugger en MacOS 9.2. Como puede observarse en la primera pantalla, donde se ve el logo de MacOS y debajo el texto «Debugger installed», tenemos instalado MacsBug, un debugger un tanto arcaico para Motorola 68000. La gracia es que para activar el debugger, es necesario pulsar la combinación de teclas «Command-Power» (Programmer’s key), lo cual, en qemu, y con un teclado de un MBP moderno, no logré hacerlo ¯\_(ツ)_/¯

HackIt! 2017 Level 3


usbmon es una funcionalidad ofrecida por el kernel Linux para recolectar trazas de entrada/salida que usen el bus USB. El level 3 nos plantea unas trazas de texto plano obtenidas a través de usbmon.

Tras mucho analizar, allá donde esperábamos información sobre el dispositivo USB en concreto, vimos que había tres líneas censuradas.

Intentamos también convertir la salida ascii de usbmon a formato .pcap para manejar el dump más cómodamente desde wireshark, pero no lo conseguimos. Así que tocaba parsear el fichero de texto. Antes de ponernos a programar un parser, buscamos alguno ya existente y encontramos varias alternativas, entre ellas este script en python que además generaba su salida en un bonito HTML.

Lo intentamos por todos los medios. Lo primero fue extraer los datos de tipo isochronous e interpretarlos: como raw image, como audio, como señal de unos y ceros… agua.

Hasta muchas horas después de planteado el reto, nadie lo solucionó. Si no recuerdo mal, el lunes 24 pusieron la primera pista: «Audio parece, pero audio no es.» que nos dejó igual que estábamos (bueno, redujo el espacio de búsqueda, eso sí). La madrugada del lunes al martes (a eso de las 4am) se publicó la segunda pista, pero nos pilló exhaustos, y a la mayoría dormidos. La segunda pista restauraba parte de las líneas del dump eliminadas, facilitando información sobre el dispositivo que las generó. Un láser. Seguramente se nos tenía que haber ocurrido antes, conociendo al autor de la prueba y su afición por estos dispositivos

No sé si w0pr solucionó este reto con esta segunda pista o con la primera… pero ¡lo solucionó! Así que espero que publiquen el write-up para actualizar este post con el enlace directo.

UPDATE (30/07/2017): w0pr ha publicado la solución completa a este reto.

HackIt! 2017. Level 2

¡Y vamos a por bingo! El nivel 2 nos pide que encontremos el secreto que esconde una captura de tráfico de red. Realmente esto me sonaba a otra prueba del hackit… de 2007 (!). Abriendo la captura con un wireshark moderno, vemos tramas bluetooth. Probablement de algún dispositivo que envía datos, y en concreto, este SoundCore-Sport-XL-Bluetooth-Speaker.

Seleccionamos Telephony / RTP / RTP Streams…

Y oímos la señal, pero muy distorsionada. Aquí tuvimos un problema: queríamos exportar el audio para poderlo tratar con Audacity. Pero oh, sorpresa, no era posible:

Aquí se nos ocurrió una solución tal vez no muy «ortodoxa», pero que funcionó perfectamente 🙂 Abrimos Camtasia, lo configuramos para grabar sonido del sistema y le dimos al Play stream en Wireshark. Exportamos luego el resultado de la grabación a formato mp4 (en Camtasia) y lo abrimos con Audacity, aplicándole el efecto de cambio de speed, encontrando la solución (fuaaaa!) 🙂