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
El tamaño de bloque es de 4096 bytes
Dentro de esta partición tenemos un documento PDF, concretamente un manual de usuario de un dispositivo Synology:
Ejercicio 1. Generación de una imagen bruta bit a bit
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.
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.
Ejercicio 4: Conversión de una imagen comprimida en una imagen bruta
Nuevamente empleamos afconvert
¿Pasa algo raro?
¿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 :)
Un saludo,
No entiendo el por qué de un ratio de compresión tan reducido. Tratándose de una unidad (¿nueva?) con solo dos documentos a bordo, ¿no sería lógico esperar una imagen microscópica, al quedar comprimido todo el espacio vacío? Al fin y al cabo se trata de un GB de ceros.
¿O funciona de otro modo?
Patxi,
Toda la razón del mundo. Si te fijas en la ejecución de aimage, no contiene parámetros de compresión (–Xn). Para mas inri, la imagen esta realizada en una llave USB que no estaba sometida a ceros previamente, y con una cantidad ingente de datos sin asignar y espacio slack. Esto me hizo pensar que pese a que aparentemente había poco contenido en el disco, realmente había bastante información, motivo por el cual seria normal el escaso ratio de compresión. Lamento terriblemente la confusión, pero me alegro que te hayas dado cuenta del error y que podamos explicarlo.
La compresión de AFF esta basada en zlib, pero conviene matizar que el éxito de la compresión no es dependiente del espacio vacío, sino de la similaridad de los bloques del disco ya que la compresión se realiza agrupando bloques. Estar vacío no implica que haya similaridad en los bloques (puede haber bloques no asignados, slack space) que provoquen, como en este caso, que para el usuario la apariencia sea de sistema de ficheros poco poblado, pero con gran presencia de datos en el disco.
El escenario ideal de similaridad es la presencia de ceros, que por cierto, también implica que la unidad este «vacía» :)
Un nuevo experimento con una unidad de 236 MB con 596 KB a bordo justo después de someterla a ceros aclara la teoría. Como era de esperar, la compresión es dramática (559 KB para AFF y 987 KB para formato EnCase). Ambos formatos no precisan de una unidad sometida a ceros para rendir en compresión ni mucho menos, pero obviamente, cuanto mas nos acercamos al estado de disco poblado con datos aleatorios, mas complicado es comprimir.
El propio autor de AFF documenta que con una ejecución de compresión grado 6 (-X6), y para un disco de 6 GB, una unidad sometida a ceros (similaridad casi total) genera una imagen de 6 megas, 2450 megas si contiene 1200 copias de ciertas obras de Shakespeare y 6301 megas, o lo que es lo mismo, casi el tamaño del disco, si los datos son aleatorios.
Así que, resumiendo: La ejecución que se muestra NO es correcta, ya que implica la generación de una imagen AFF sin compresión (mea culpa). Creo que una vez explicado esto no se hace preciso repetir las ejecuciones, pero desde luego este es el perfecto ejemplo las suposiciones conducen a los errores :)
PD: Para los que quieran saber algo mas de la no concordancia en los MD5, aclarar que:
– El formato AFF incluye metadatos, así que nadie espere concordancia con imágenes brutas
– No obstante, notad la ausencia de bs=512 en la ejecución de DD para la imagen bruta (esta si es intencionada). El ejercicio que propongo a un lector es determinar si la conversión de imágenes respeta la integridad de las mismas o no.
PD2:
He recibido un mensaje de alguien que se queja de que afflib esta fuera de soporte, y no le falta razón. Quizás no sea el mejor ejemplo para imágenes comprimidas pero a día de hoy es el único formato que es, a la vez, extensible, no propietario y compresible.
El estándar de facto es posiblemente EnCase, aunque existen otros dos modos de comprimir muy interesantes para los interesados: ILook, ProDiscover y PyFlag. Ahi quedan para futura referencia.
Un saludo, y disculpas por los errores y la confusión.
ACTUALIZACIÓN
He editado y corregido los errores en el artículo anterior, y he simplificado los ejercicios ligeramente. También he empleado en este caso un sistema de ficheros ext3 en vez de un FAT32, pero esto no tiene importancia.
Una vez más, lamento los errores en el anterior artículo :)
Saludos,