Ikasten.IO

Y con este SolveIt3 llegamos al final de los hackits y solveits que conseguimos resolver… fuera de tiempo, la mayoría, pero hey! No se puede tener todo… 🙂

Se trata de una imagen de un disco formateado con un sistema de archivos FAT.

# fdisk -l disk.img.gz
Disk disk.img.gz: 146.5 MiB, 153600000 bytes, 300000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb24b8602

Device       Boot Start    End Sectors   Size Id Type
disk.img.gz1       2048 299999  297952 145.5M  c W95 FAT32 (LBA)

Podemos montar la imagen (renombrar primero para añadirle la extensión .dmg si estás en macOS):

➜ hdiutil attach disk.img.gz.dmg
/dev/disk2              FDisk_partition_scheme
/dev/disk2s1            Windows_FAT_32                  /Volumes/NO NAME

Es curioso, en macOS monta la imagen sin problema, pero Linux se queja de que la imagen tiene algún error:

# fsck.vfat disk.img.gz
fsck.fat 4.1 (2017-01-24)
Logical sector size is zero.

# mount -o loop -t vfat disk.img.gz /tmp/q/
mount: /tmp/q: wrong fs type, bad option, bad superblock on /dev/loop10, missing codepage or helper program, or other error.

En macOS la imagen se monta por defecto en /Volumes/NO NAME. Si pedimos un listado de ese directorio:

$ ls -al
total 218505
drwxrwxrwx@ 1 juanan  staff        512 Aug  7 21:53 .
drwxr-xr-x  4 root    wheel        128 Aug  7 21:53 ..
drwxrwxrwx  1 juanan  staff        512 Aug  7 21:53 .fseventsd
-rwxrwxrwx  1 juanan  staff  111873298 Jul 22 10:00 video.avi

El .fseventsd es un artefacto de macOS. Y el vídeo, bueno… no hacía falta ni abrirlo para saber de qué se trataba:

Desmontamos la unidad con umount /Volumes/NO\ NAME. Y empezamos a analizar el contenido de las particiones de esa imagen.

fdisk  disk.img.gz.dmg
Disk: disk.img.gz.dmg   geometry: 595/8/63 [300000 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: 0C    0  32  33 -   18 171  57 [      2048 -     297952] Win95 FAT32L
 2: 00    0   0   0 -    0   0   0 [         0 -          0] unused
 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused

Eliminamos los primeros 2048 bloques y extraemos el resto:

dd if=disk.img.gz.dmg of=/tmp/cabecera3 bs=512 skip=2048 count=297952

Probamos algo típico en un binario (ya hicimos pruebas con binwalk y no salió nada)… abrirlo con Gimp en modo raw 🙂

Si le damos un poco de zoom, veremos lo que estábamos buscando (saludos a Cuartango, que fue el primero en encontrar la medida exacta)

El level 2 del SolveIt se nos hacía conocido. Surgió en alguna otra ocasión, no recuerdo exactamente… tal vez en la Gipuzkoa Encounter de 2019. El autor (@imobilis) dibujó las pistas para solucionarlo en un papel que luego troceó y revolvió en múltiples pedazos. Verdaderamente es un buen rompecabezas.

Conocíamos el procedimiento de resolución: recortar cada una de las piezas e intentar recomponer la imagen original. Un trabajo de chinos. Kotxerra se puso a ello y estuvo dándole al Photoshop durante horas. Al final consiguió una buena imagen:

@ochoto retocó la imagen para hacerla más legible:

Hint2: Los solveits repetidos no son un pecado… 😉

Los bolsillos de un ORG, así se titulaba el level 1 del SolveIt. Venía acompañado de la típica imagen con varios elementos cuyos nombres hay que encontrar para formar la contraseña. Pero otra vez, nos encontramos con un red herring, una falsa pista que nos hizo perder tiempo (jugando con Google Lens para encontrar algunos nombres…) Al final bastaba con seguir la siguiente pista al pie de la letra: buscamos los nombres de los técnicos (orgs) que podrían llevar cualquiera de estos elementos…

Así que buscando en la intranet, pudimos ver esta lista:

Y nuestro compañero Cuartango, después de haber probado otras cuantas posibles soluciones, llegó a la conclusión de que la más simple era la buena: Aitor Aritz Gorka Mikel Oier 🙂

El nivel 3 nos consiguió engañar. Y eso que lo esperábamos… una prueba sobre Asahi Linux va a caer sí o sí; marcan ha estado metiendo miles de horas en este proyecto…

Descomprimiendo el fichero zip que nos adjuntan en la prueba analizamos lo que tenemos:

Lo primero, el nombre del gz indica AGX, la arquitectura GPU del M1 (Apple Silicon). Tras leer los posts de Rosenzweig y curiosear el repositorio GitHub de Asahi, llegamos hasta este script que trata de mostrar en pantalla el conejo típico de testing:

Además, usa variables del cmdbuf.json que nos dan (depth_bias_array, scissor_array…) Así que nuestra idea era ejecutar el código de renderizado del conejo en un m1 y si funcionaba, cambiar los .bin por los que nos daban (y cargar adecuadamente las variables del cmdbuf.json). Había algunos flecos más que arreglar, pero bueno… lo primero era encontra un m1 🙂 Afortunadamente para nuestros bolsillos podemos alquilar el uso de un mac mini m1 por 2.5€ al día.

Seguimos el script de instalación de Asahi hasta el final:

Pero llegamos a un punto interesante… En el último paso Asahi nos pedia apagar el M1 y en el arranque seleccionar Asahi… No contamos con un «pequeño» detalle: en un ordenador remoto al arrancar no tenemos acceso a la pantalla de boot. Así que se nos quedó el m1 en modo rebooting durante toda la party. Dimos la orden de reinstalar el sistema pero no se podía porque estaba en modo rebooting ¯\_(ツ)_/¯

Así que estuvimos dando vueltas y vueltas… sin darnos cuenta de un detalle. Si hay que renderizar algo en pantalla a partir de vértices de un gráfico, necesitaremos esa malla de vértices en 3d… que estará en alguno de los .bin que nos pasan.

En este obj_150138c000.bin, por ejemplo. Si pintamos esos puntos con matplotlib (saludos a @ochoto, que se curró el script):

#!/usr/bin/env python
# coding: utf-8

import numpy as np
import matplotlib.pyplot as plt

with open("obj_150138c000.bin", 'rb') as f:
    data = np.fromfile(f,dtype="f")

numvertex = len(data) // 3
rshp = data.reshape(numvertex,3)

xs = rshp[:,0]
ys = rshp[:,1]
zs = rshp[:,2]

plt.plot(xs,ys)
plt.show()

Y obtenemos el resultado buscado 🙂

En la prueba 2 estuvimos zanganeando. Buscábamos un parser que ya estuviera programado para que nos ayudara a interpretar el contenido del wav. Craso error. marcan siempre evita este tipo de pruebas y si crees que igual tienes que programar el script que interprete este formato… ya puedes ir abriendo el IDE.

El título de la prueba, Visual Legacy viene a indicarnos que el formato que buscamos es algo antiguo y que el wav está codificando imagen de vídeo.

Si abrimos con Audacity el wav, veremos algo como lo siguiente:

Haciendo algo de zoom:

Buscando «video signal» en Google Images, uno de los primeros resultados es este:

¿Cómo saber cuándo termina un frame y empieza el siguiente? Hay una señal de sincronismo vertical:

Con toda esa información, nuestro compañero Joserra se curró un script en Python que iba extrayendo la luminancia de cada pixel. Formando líneas y frames, y exportando cada frame a un png.

El resultado son 12000 y pico frames del famoso vídeo de Rick Astley (cómo no, el Never gonna give you up). Podemos montar los frames para formar un vídeo por el que nos podamos desplazar cómodamente:

ffmpeg -r 60 -f image2 -s 241x385 -i decode%05d.png -vcodec libx264 -crf 25   test.mp4

Y pasándolo con FF, por fin, vemos la ansiada clave: