Trabajando con imágenes forenses comprimidas

Hola,

Hace un tiempo hablamos en el blog sobre cómo trabajar con imágenes forenses fragmentadas. Hoy vamos a hablar de otro aspecto importante: el uso de imágenes comprimidas.

Es curioso como muchas personas siguen trabajando sólo con capturas de medios brutas sin prestar atención a los beneficios de la compresión en el tratamiento de imágenes forenses. A mí me sorprende esto bastante, ya que con los tamaños que manejamos últimamente en los medios, ¿por qué no sacar ventaja de la compresión?

El objetivo de este artículo es exponer, utilizando AFF como ejemplo, cómo se trabaja con imágenes forenses comprimidas. Ejecutaremos varios escenarios prácticos para ver cómo se realizan las capturas, y cómo podemos convertir los formatos entre sí.

Nuestro medio a capturar

Nuestro medio para trabajar es una llave USB de 1GB de tamaño (/dev/sdb) con una partición que usaremos para trabajar (dev/sdb1) que está formateada con un sistema de ficheros ext3

fsstat

El tamaño de bloque es de 4096 bytes

blocksize

Dentro de esta partición tenemos un documento PDF, concretamente un manual de usuario de un dispositivo Synology:

ls

Ejercicio 1. Generación de una imagen bruta bit a bit

dd

Ejercicio 2. Generación de una imagen comprimida en formato AFF

El formato Advanced Forensics Format (AFF) es un formato muy recomendable para el análisis forense. Además de permitir la incrustación de metadatos, ofrece dos poderosos medios de compresión y posibilidad de cifrar. Por un lazo, zlib, que es rápido y efectivo (es el que usa EnCase, por cierto). Adicionalmente soporta re-compresión con LZMA, que aunque es lento, produce reducciones de tamaño drásticas.

aimage

Además de obtener la imagen comprimida, aimage nos proporciona información útil, como los hashes resultantes. Nótese que tanto para la imagen bruta como para la imagen comprimida, el número de bytes leídos es el mismo: 1059061760 bytes. En este caso el ratio de compresión es muy bueno, del orden del 98%, algo razonable teniendo en cuenta que la unidad estaba sometida a ceros y dado el tamaño del fichero que contiene.

Ejercicio 3: Conversión de una imagen bruta en una imagen comprimida

Para ello empleamos afconvert, que también es parte de AFFLIB.

raw to aff

Ejercicio 4: Conversión de una imagen comprimida en una imagen bruta

Nuevamente empleamos afconvert

aff to raw

¿Pasa algo raro?

pasa algo

¿Nos hemos cargado la cadena de custodia? ¿Sí? ¿No? ¿Todo lo contrario?

En principio partíamos de una imagen bruta bit a bit (imagenbruta.dd) cuyo MD5 es 26e0aa3a91e850340bc0f63f3f684ebd. Posteriormente, hemos generado una imagen comprimida directamente del medio (imagenaff.aff) que también nos ha advertido (ver la ejecución) que el MD5 del medio original es 26e0aa3a91e850340bc0f63f3f684ebd. El MD5 de la imagen comprimida es sin embargo 97860b9c2cc2c94056346a08cad94bde.

A continuación hemos tomado la imagen bruta y la hemos convertido a AFF empleando la utilidad de conversión, generando el fichero imagenbruta.aff cuyo MD5 es 86f115c2b0e009757cb202dd7ccf9eb2. Por último hemos descomprimido la imagen AFF capturada del medio original y hemos generado el fichero imagenaff.raw. El MD5 de este fichero es nuevamente, 26e0aa3a91e850340bc0f63f3f684ebd.

Es obvio que existe una discrepancia entre tamaños y MD5 entre los formatos AFF obtenidos directamente del medio o convertido desde la imagen bruta. Yo no consideraría la cadena de custodia rota, ya que tanto mediante obtención de imagen bit a bit del medio como como por adquisición directa de un formato comprimido que después puede ser descomprimido a imagen bruta, el MD5 resultante es el mismo. El problema que se nos presenta es determinar por qué difieren los formatos comprimidos entre sí, y si esto tiene implicaciones en el proceso. Esto os lo dejo a vosotros :)

pasa algo

Un saludo,