APT593

CPCTF : Chunkicidio (Francia)

13/07/2020

Descripción:

Recibi este archivo pero parece corrupto. ¿Me puedes ayudar? (Envolver en formato flag PCTF{flag}

Archivo:

data

Resolución

Revisando a que nos enfretamos vemos que el comando file no reconoce ningún formato conocido en el archivo entregado. 

$file data
data: data

Viendo el contenido en raw con hexedit o hexdump nos damos cuenta fácilmente que es un archivo en formato PNG (Al menos es lo más probable)

image-20200712200344658

Sin embargo haciendo una búsqueda rápida en Google de PNG y su formato nos damos cuenta que inicialmente la cabecera es errónea:

Byte(s) Propósito
89 Tiene el bit más alto puesto a 1 para detectar sistemas de transmisión que no soportan datos de 8 bits y para reducir el riesgo de que un fichero de texto sea erróneamente interpretado como PNG.
50 4E 47 En ASCII, las letras “PNG” permitiendo que una persona identifique el formato en caso de verlo en un editor de texto.
0D 0A Una nueva línea con estilo DOS (CRLF) para detectar las conversiones de final de línea entre DOS y UNIX.
1A Un byte que detiene el despliegue del fichero bajo DOS cuando se ha usado el comando TYPE.
0A Una nueva línea en UNIX (LF) para detectar la conversión de final de línea entre DOS y UNIX.

Con hexedit o cualquier editor hexadecimal se corrige la cabecera:

00000000   89 50 4E 47  0D 0A 1A 0A

Sin embargo, después de la corrección el formato sigue apareciendo corrupto. Y el nombre del reto nos da una pista de que en este archivo ocurrió un “chunkicidio” (Que es como un homicidio pero de chunks)

Los chunks son secciones que componen un archivo PNG. Son algunos pero estos son los más esenciales:

  • IHDR, debe ser la primera sección, contiene la cabecera.
  • PLTE, contiene la paleta (lista de colores).
  • IDAT, contiene la imagen que debe ser dividida en múltiples secciones IDAT, haciendo esto se incrementa el tamaño de la imagen ligeramente pero hace posible generar imágenes PNG en streaming.
  • IEND, marca el final de la imagen.

Además es necesario saber que cada chunck consta de 4 partes:

Campo Cantidad de bytes Descripción
Lenght 4 bytes La cantidad de bytes del campo Chunk Data. Unicamente cuenta el campo Data, no el resto de campos.
Chunk Type 4 bytes Código en ASCII que identifica el chunk (Ej: IHDF, IDAT, IEND)
Chunk Data 0 a [lenght] bytes El contenido del chunk
CRC 4 bytes CRC (Chequeo de Redundancia Ciclica). Sirve para validar integridad del archivo.

En nuestro archivo analizado se puede reconocer estos chunks pero todos tienen un error con el identificador de su tipo:

00000000   89 50 4E 47  0D 0A 1A 0A  00 00 00 00  49 48 44 51  .PNG........IHDQ
..
00000020   55 00 00 80  00 39 44 41  54 78 5E EC  DD 77 6F E3  U....9DATx^..wo.
..
00039790   AA 64 19 EC  E1 00 00 00  00 49 49 4E  44 AE 42 60  .d.......IIND.B`

Corregido esto nos damos cuenta además que existe el campo “lenght” del chunk IHDR tiene longitud cero. (De acuerdo a la especificación sabemos que este campo esta antes del tipo de chunk)

00000000   89 50 4E 47  0D 0A 1A 0A  00 00 00 00  49 48 44 52  .PNG........IHDR

Para corregir esto nos toca contar la cantidad de bytes del campo data. Es decir la cantidad de bytes entre IHDR y el CRC. Podemos usar el inicio del chunk IDAT como referencia para saber cuales son los últimos 4 bytes correspondientes al chunk IHDR. Contamos y vemos que son 13 (0D en HEX)

00000000   89 50 4E 47  0D 0A 1A 0A  00 00 00 0D  49 48 44 52  .PNG........IHDR
00000010   00 00 04 B0  00 00 03 20  08 02 00 00  00 BA 82 0D  ....... ........
00000020   55 00 00 80  00 49 44 41  54 78 5E EC  DD 77 6F E3  U....IDATx^..wo.

Sin embargo el archivo sigue corrupto y nos falta analizar el CRC. Realizar este cálculo es una operación sencilla pero para comodidad, en este punto les introduzco pngcheck.

La herramienta pngcheck nos puede ayudar a revisar los CRC y de hecho si la hubiéramos usado desde el principio también nos hubiera apuntado a los otros errores que ya corregimos. Sin embargo nos va advirtiendo de uno en uno y toca correrlos varias veces mientras vamos corrigiendo. A continuación presento la salida del comando después de realizar cada una de las correcciones:

root@d6a86bb24f83:/data# pngcheck data.png
data.png  invalid IHDR length

root@d6a86bb24f83:/data# pngcheck data.png
data.png  CRC error in chunk IHDR (computed bc820c55, expected ba820d55)

root@d6a86bb24f83:/data# pngcheck data.png
data.png:  invalid chunk name "9DAT" (39 44 41 54)
  
root@d6a86bb24f83:/data# pngcheck data.png
data.png  CRC error in chunk IDAT (computed 6448ef03, expected 6419ece1)

root@d6a86bb24f83:/data# pngcheck data.png
data.png  illegal (unless recently approved) unknown, public chunk IIND

root@d6a86bb24f83:/data# file data.png 
data.png: PNG image data, 1200 x 800, 8-bit/color RGB, non-interlaced

La herramienta pngcheck nos advierte que existen dos inconsistencias en los CRC de dos chunks. Una vez corregido esto, el archivo ya es reconocido como un PNG y podemos abrirlo:

image-20200712205208467

Que tiene la palabra Locot3 escondida en el estereograma. Y ese es nuestro flag una vez que lo envolvemos en el formato:

CPCTF{Locot3}

O si son aburridos pueden usar programas como stegsolve (modo Stereogram Solver) para dar con la palabra. O buscar un sitio web que resuelva stereogramas.

image-20200712205600701