Categoría: HackIt

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?)
	

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…

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.

¡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!) 🙂