Muchos agradecimientos a el por sus aportes y sobre todo no se olviden de visitar la fuente saludos y que empieze:
fo
Hola de nuevo a todos
En estás últimas semanas estoy siguiendo un curso de Análisis Forense (en el que me lo estoy pasando genial además de aprender y/o reforzar este tipo de asuntos que para eso asisto a clase, claro)
El caso es que estoy pasando los apuntes y demás... y pensé... “por qué no publicarlo en estos foros?”, Claro que sí, por favor....
El curso nos lo imparte un elemento bastante bueno en esta tarea “funcionario”, jeje... vamos de los “Men in Green” :P no daré muchos mas datos, pero solo con oir Unidad Operativa de Delitos Informáticos de la Guardia Civil, Policía Judicial, Master por la INTERPOL, EUROPOL etc..... a mas de uno se le ponen los pelos de punta, jajaja y como no podía ser de otra manera, estamos fraguando una relación y confianza que me da buenas vibraciones...
A ver si he sido buen alumno y consigo ir explicando por partes en estos foros gran parte del contenido de estos cursos y tenemos un bonito hilo acerca de este asunto que a los que nos gusta esto de la seguridad es un tema importante, a veces desconocido y con difícil soporte en español....
Voy a dejar de un lado todo el asunto de Normativas, Código Penal, Legislación, LSSI., LOPD, también me apartaré un poco de lo que se denomina la “escena del Crimen”, la cadena de custodia y demás zarandajas que se han de tomar en cuenta cuando la Guardia Civil o autoridades competentes intervienen en una inspección, es muy importante pero se nos escapa un poco y aunque hay aspectos determinantes para poder inculpar a alguien en este post vamos a ir mas directamente a lo que es el análisis forense.
Decía antes que es importante porque de nada sirve encontrar restos de información o incluso completarla para que luego no sirva ante un eventual juicio, de momento que nos sirva una frase:
“Tan importante es encontrar evidencias de un delito como demostrar que esas evidencias sean veraces, que se haya seguido el procedimiento judicial adecuado, custodiado y desarrollado con profesionalidad”
Ya iremos apuntando algunas de las cuestiones legales, de cómo presentarlas, de la certificación de la evidencia, de la veracidad de la misma, del “no tocar” y demostrar que “no se ha tocado”, de muchas cuestiones que según mi profe, tiran por tierra muchos casos por el simple hecho de alterar un solo bit o que simplemente no entiende lo que se le presenta.
En esta primera parte nos vamos a centrar en Windows, en el análisis con herramientas Windows y del sistema operativo Windows.
Mas concretamente del Sistema de Archivos FAT y NTFS, del análisis de discos, de la recuperación de datos, del sistema de particiones, del logging, del registro, del archivo de paginación, de los slacks, de los data run, de los archivos residentes, de mil cosas.... del logging, de recolectar información perdida por el registro, de identificar todo lo que se pueda para luego presentar a un juez las pruebas obtenidas.
Usaremos herramientas de análisis forense como EnCASE, Helix , FTK y alguna mas como sleuthkit ...
Tal y como se hizo con el Taller de TCP/IP, aprenderemos a analizar los rastros y registros “manualmente” luego con ayuda de herramientas específicas. Así entenderemos a la perfección como trabajan y cómo lo hacen.
Y también, al igual que con el Taller TCP/IP, iré posteando todo por partes, dando algo de tiempo para asimilar los contenidos y mantendremos el hilo cerrado para que quede todo mas legible, si bien, abriremos otro hilo paralelo para que podáis plasmar dudas, comentarios, correcciones, mejoras, etc que se puedan ir añadiendo al hilo “principal”.
Espero que sea de vuestro interés, la verdad es que va a ser un documento grande y de varias horas en su elaboración y desarrollo.
Cuando todo esté maquetado y bien presentado colgaré la documentación en un pdf para que sea mas fácil su lectura y se pueda imprimir de forma más práctica que los post del foro.
Bueno, que empezamos!!!!
Indice (Parte I. Sistema de Archivos FAT)
1.- Análisis Forense. Introducción
2.- Estructuras del Sistema y unidades
2.1.- Estructura Física
2.2.- Estructura Lógica
2.3.- CHS v.s. LBA
2.4.- Impacto en el sistema de archivos. File Slack.
3.- Introducción al Sistema de Archivos FAT
3.1.- Boot Record
3.2.- File Allocation Table
3.3..- Root Directory
3.4.- Data Area
4..- Primeros pasos con EnCase. Herramienta Forense
5.- Análisis de FAT
5.1.- El Registro de arranque al desnudo (Boot Record)
5.2.- Ejemplo de un Boot record a fondo....
5.3.- Áreas FAT1 y FAT2 con ejemplos
5.4.- El Dirty Bit
5.5.- Root Directory
5.6.- El área de datos sin secretos
6.- Ejercicios y Prácticas con FAT
6.1.- El acceso a los Datos.
6.2.- Recuperar de datos tras formateo de una unidad FAT16. File Carving
6.3.- Nombres Largos (Long Names)
6.4.- Recuperación de datos borrados y áreas Slack
6.5.- Particiones. Análisis de la Tabla de Particiones y MBR
No termina aquí, NI MUCHO MENOS!!!!! de hecho en esta primera entrega sólo se entrega hasta el punto 5.2, la próxima será el resto de esta primera parte.
Luego vendrá FAT32, NTFS, Particiones primarias y extendidas, MFT, Forensic de Windows, USB, Registro, El archivo de paginación, firmas de archivos, recuperacion, EnCase a fondo, Helix para Windows, FTK, imágenes y duplicados de volúmenes y un largo etcétera...
También veremos Forensic de Linux, con herramientas Linux y por supuesto, Anti-Forensic
ESTRUCTURA FISICA Y LOGICA DE UN DISCO
En todo disco (ya sea disquete, disco duro, memoria flash, etc..) hay que distinguir entre una estructura física y una estructura lógica.
La estructura física es inherente al disco y se crea cuando se construye el disco en la fabrica.
La estructura física divide al disco en: caras, cilindros o pistas, y sectores.
La estructura lógica se crea por el usuario al formatear el disco por ejemplo con la orden FORMAT. Los datos se almacenan según la estructura lógica. Por eso, siempre hay que formatear un disco antes de usarlo. En el caso de los discos duros, antes del formateo se deberá efectuar su partición o particiones.
ESTRUCTURA FISICA
La estructura física determina la capacidad del disco y viene impuesta por el fabricante.
Cada disco puede tener varias “caras” y/o o “cabezas” los disquetes tienen dos caras, los discos duros suelen tener varias caras.
Las caras de un disco se numeran comenzando por la 0.
Cada cara la podemos imaginar dividida en círculos concéntricos llamados pistas en los disquetes y cilindros en los discos duros.
En los discos duros cada una de las caras también se divide en varias pistas. Sin embargo en los discos duros no se habla de pistas, sino de cilindros. Un cilindro designa el conjunto de todas las pistas con igual número pero distinta cara.
Cada pista se divide en segmentos llamados sectores. El sector es la unidad mínima de información para los discos.
Cuando se lee o escribe información en un disco lo que esta haciendo es leer o escribir uno o mas sectores en el disco.
ESTRUCTURA LOGICA
Los sistemas operativos trabajan con clusters y estructuras lógicas que se crean durante el proceso del formateo.
Cada vez que se formatea un disco se realizan dos cosas:
- 1- Se define el numero de pistas y el numero de sectores por pista.
2- Se divide el disco en zonas
Aunque el numero de pistas de un disco esta impuesto por su estructura física tal y como lo entrega el fabricante es posible crear una estructura lógica (formatear) con menos pistas por cara o con mas.
El número de sectores por pista también puede variar según el formateo, por ejemplo un disquete de 3 pulgadas y 1/2 de 1.44MB con 18 sectores por pista puede ser formateado con 9 sectores por pista (discos de 720K).
División en zonas
La acción de formatear depende del Sistema de Archivos elegido, no son las mismas zonas las que se crean para un disco formateado en FAT que en NTFS u otros... sin embargo hay algo que es común: El Sector de arranque
El sector de arranque (boot sector) se localiza en el primer sector de todo disco y ocupa 512 bytes.
Este sector de arranque se utiliza principalmente para dos tareas:
- a) Contiene un pequeño programa que se ejecuta al encender el ordenador y que permite cargar el sistema Operativo (si se trata de un disco de arranque) en memoria durante la inicialización del sistema.
Cada vez que se inicializa el ordenador se busca el sector de arranque de la unidad A, C ... y se ejecuta este pequeño programa, que puede hacer dos cosas: o bien carga el Sistema Operativo o bien muestra algún mensaje:
No es disco de sistema
Pulse cualquier tecla para continuar
....
....
b) El sector de arranque almacena una tabla con información sobre la estructura física y lógica del disco: número de caras, pistas, sectores por pista, bytes por sector, sectores por cluster, numero de Fats, nombre y versión del sistema operativo, etc.
Un cluster es un conjunto de uno o mas sectores contiguos.
Cuando el Sistema Operativo copia un fichero en un disco, no lo copia en el sector x de la pista x de la cara x, sino que lo copia en el cluster x.
El sector es la mínima unidad de información para el disco; pero el cluster es la unidad mínima de información para el Sistema Operativo.
El numero de sectores que ocupa cada cluster ha de ser potencia de 2 (1, 2, 4, 8, etc) y su valor exacto depende de la capacidad del disco.
Los clusters solucionan el problema del almacenamiento de los ficheros en el disco, pues aunque los clusters se componen de sectores contiguos, los ficheros se almacenan en clusters que no necesitan ser contiguos.
Ahora bien, ¿como sabe el Sistema Operativo en que cluster continua un determinado fichero?
Pues mediante el Sistema de Archivos, ya sea FAT16, FAT32, NTFS y otros...
También se incluyen determinadas marcas para saber si un cluster está ocupado, libre, defectuoso, si es el último, etc.. como ya se ha dicho varias veces, la forma de hacerlo depende del sistema de archivos elegido.
CHS v.s. LBA
Ya hemos hablado de Estructura Física y Estructura Lógica de un disco, físicamente el disco lo entendemos como un conjunto de “platos” en los que existen “cabezas” que leen cada una de las caras que a su vez se disponen es sectores.
Si trazásemos unas líneas imaginarias verticales que segmentasen el conjunto de platos del disco obtendríamos los que se denomina el cilindro.
Hace tiempo las caras de los platos mas exteriores (la de mas arriba y la de mas abajo) no se utilizaban para almacenar datos, se usaban para lo que se denomina el “aterrizaje” el “landing” hoy en día sí que se usan todas las caras de un disco.
Los cilindros “atraviesan” verticalmente cada uno de los platos del disco, es decir, para el acceso físico a un sector determinado del disco se utilizan tres coordenadas, lo que conocemos como CHS.
- * El número de cilindro: 10 bits (del 0 al 1023)
* El número de cara o cabeza: 8 bits (del 0 al 255)
* El número de sector que corresponde a la pista: 6 bits (del 1 al 63, el cero no se usa)
Si atendemos a este tipo de direccionamiento resulta que el tamaño máximo de un disco sería:
| Código: |
| 1024 cilindros x 256 cabezas x 63 sectores x 512 bytes por sector = 8.4 Gbytes |
La BIOS utiliza la interrupción 13 (INT 13h) permiten alcanzar una posición de cualquier sector mediante estos tres números.
Este era un límite hace años, cuando los discos empezaron a fabricarse mas grandes, las BIOS utilizaron los denominados “modo Largo” o modo “extendido” ECHS, hoy en día esos límites y sistemas de traducción han quedado muy lejos por el gran tamaño de los discos y utilizan lo que se llama el modo LBA,
Físicamente se accede a los datos por estas tres coordenadas (CHS) pero para el sistema operativo sería muy lento direccionar los datos atendiendo a esos tres valores, en su lugar se usa otro sistema unidireccional, el LBA (Logic Block Address) no siempre fue así, normalmente es la BIOS quien realiza esa traducción.
La conversión de una dirección CHS a LBA puede hacerse con la siguiente expresión:
| Código: |
| LBA= (NC x NH + H) x NS + S -1 Siendo: NC = Nº de cilindro a direccionar NH = Nº de cabezas totales H = Número de cabeza a direccionar NS= Número de sectores por pista S = Sector a direccionar |
Las extensiones de BIOS actuales emplean direccionamiento LBA de 48 bits lo que nos llevaría a un límite de:
| Código: |
| 2 ^48 x 512 bytes por sector = 144.000.000 Gbytes aproximadamente |
Sin embargo también pueden emplear el direccionamiento [b]CHS [/b]junto con LBA por cuestiones de compatibilidad , el acceso al disco duro durante las primeras fases de arranque se hace por CHS, mas tarde, se comprueba si se pueden usar las Extensiones de INT 13h para acceder al disco mediante direcciones LBA.
Obviamente el acceso LBA es mas rápido, basta con pensar que sólo se necesita una coordenada para llegar a cualquier parte del disco en lugar de las tres que proporciona CHS, para el sistema operativo también es mas rápido, pero de una forma u otra, físicamente se mantiene el formato CHS y el disco físicamente sigue manteniendo una estructura CHS, por tanto, LBA es la forma lógica de acceder a las posiciones físicas determinadas por CHS.
La BIOS utiliza el acceso al disco duro mediante dos formas:
- Servicios estándar con traducción (limitado a discos máximo 8.4GB)
Servicios extendidos (LBA de 48 bits)
La explicación es obvia, si estuviese “partido” horizontalmente, las cabezas del disco tendrían que moverse constantemente “adelante y atrás” para alcanzar los sectores, si lo cortamos verticalmente se pueden leer todas las posiciones de un cilindro “a la vez” por cada cabeza, claro no?
Otra curiosidad es que no todos los sectores de un disco se terminan usando (dejando al margen aquellos que se puedan marcar como defectuosos) existe o puede existir un área de sectores sobrantes (surplus sectors) esto es debido a que el número de sectores totales del disco no es un múltiplo del número total de cilindros, por ejemplo:
Un disco duro de 40 Gbytes cuya estructura física según el fabricante es de:
- Nº de sectores = 78165360
Nº de cilindros = 4865
Nº de cabezas = 255
Nº de sectores por pista = 63
Y si restamos el número de sectores que nos da el fabricante menos el valor calculado, tenemos:
78165360 – 78156225 = 9135 que seran los sectores sobrantes según esa tecnología de disco.
TERMINOLOGÍA
FAT: File Allocation Table, Es la estructura presente en volúmenes FAT, por supuesto…. Volumen
FAT1: También llamada Primary FAT y es la primera copia de FAT
FAT2: También llamada Secundary FAT y es una segunda copia de FAT
FAT12: Sistema de archivos que utiliza 12-bit por cluster en el direccionamiento
FAT16: Sistema de archivos que utiliza 16-bit por cluster en el direccionamiento
FAT32: Sistema de archivos que utiliza 32-bit por cluster en el direccionamiento
FAT or FATxx: Sistema de archivos que usa FAT
VFAT: Código de 32-bit usado por Win9x en modo gráfico (GUI)
Cluster: Unidad de Datos que se usa para el almacenamiento lógico de la información
Sector: Unidad de Datos que se usa para el almacenamiento Físico de la información
Physical sector address: Dirección absoluta de un sector en términos físicos del Hardware
CHS sector address: Cylinder, Head, Sector (Cilindro, Cabeza y Sector)
Logical sector address: Dirección relativa de un sector address
Folder: Eso, las carpetas que podemos ver con el Explorador de Windows, por ejempplo
File Folder: Pues lo mismo de antes en términos “mas modernos”
Directory: Estructura de datos que contiene archivos u otros directorios
Directory entry: Puntero a un archivo o directorio que contiene información acerca de los atributos, marcas horarias, tamaño, cluster de inicio, etc...
Attributes: Colección de bits en una entrada de directorio que lo describe
Algunos de estos términos tienen el mismo significado en otros sistemas de archivos y otros son particulares de FAT.
FILE SLACK
Por el momento, es importante que entendamos la diferencia entre sectores y cluster.
Un sector comúnmente referencia a un espacio físico del disco mientras que un cluster es una agrupación de sectores y los debemos tomar en un sentido lógico.
Todos alguna vez en nuestra vida hemos formateado un disco, jajaja, igual no... bueno, el caso es que una de las acciones que la acción de formatear un disco ejerce es agrupar los sectores en cluster, eso que Microsoft llama Tamaño de unidad de asignación.
Como vemos en la pantalla anterior, podemos usar 512, 1024, 2048 o 4096 bytes
Si nuestro disco utiliza sectores físicos de 512 bytes, podemos hacer agrupaciones de 1 sector por cluster, de 2 sectores por cluster, de 4 sectores por cluster o de 8 sectores por cluster.
El tamaño predeterminado que usa Windows depende de la capacidad del disco y del sistema de archivos elegido (p.e. FAT 16, FAT32, NTFS...), ya lo veremos.
Lo primera duda que nos asalta es qué es mejor... 1, 2, 4, 8... más?
Bien, veamos la problemática:
El archivo test.txt contiene un simple HOLA (4 bytes) sin embargo, observamos que el espacio en disco es de 4KB (4096 bytes) es decir, estamos “desperdiciando” 4092 bytes de espacio en disco, si tuviésemos 85400 archivos de este tamaño resultaría que:
| Código: |
| 85400 x 4096 = 349.798.400 bytes en el tamaño del disco, unos 341 Megas |
mientras que la información útil debería ocupar:
| Código: |
| 85400 x 4 = 341.600 bytes unos 333 KB |
Vamos, que nos chupamos mas de 300 Megas del disco que no se podrán usar pero que están “ocupados”
Obviamente la mejor solución en cuanto al ahorro de espacio en disco sería usar el mínimo posible pero traería consigo un menor rendimiento en archivos mas grandes puesto que el sistema operativo tendría que “enlazar” ese archivo por demasiados sectores.
De todos modos esto no es muy importante puesto que la mayor parte de nuestros archivos son bastante mas grandes.
Lo que sí es importante es que aunque el contenido del archivo es HOLA ocupa realmente 8 clusters (4096 bytes) y... qué pasa con el resto? Que contienen los 4092 bytes restantes?
Pues en Windows, habitualmente, completa el sector del primer cluster con ceros (lo wipea) y el resto lo deja tal cual se lo encontró.
Dicho de otro modo, pongamos un ejemplo:
- * Escribimos un archivo de texto que ocupa 112 byes
* Como usamos un sistema de archivos de 4096 bytes por cluster, necesitaría de 8 sectores de 512 bytes.
* En el primer sector se almacenan los 112 bytes que hemos escrito y el resto (400bytes) se wipean y se marcan con 00
* El resto de los sectores (7) del cluster, quedan con lo que había, esa información sigue estando, susceptible de verse, de recuperarse y/o de investigar. Esto es lo que se llama SLACK FILE
Un ejemplo:
Como vemos aparece la palabra hola y el resto de bytes del primer sector se wipean pero también aparece el contenido anterior (la zona en rojo) que tenían (tienen) esos sectores, por ejemplo, podría tratarse de parte de una imagen, de un archivo de audio o de un log de Chat en texto plano, sencillamente podemos acceder a ello con herramientas forenses y encontrar indicios.
Ya veremos mas adelante que podemos buscar en el contenido de los slack files (también en otros como los slack volume, Ram Slack, ) en el caso de los archivos de audio (imaginemos que buscamos conversaciones grabadas, se puede reproducir esa parte), si se tratan de correos electrónicos igual hay suerte y encontramos las evidencias del posible delito, ni que decir tiene si son log del Messenger u otros...
También veremos mas tarde que no se ha de modificar el contenido de los slack file puesto que si bien no afecta a la propia información del archivo que representa el sistema operativo, el hash de autenticidad del mismo cambiaría y la prueba, la evidencia del presunto delito, podría ser nula.
Sigamos con FAT.....
Estructura del Sistema de Archivos en FAT
El volumen de FATxx está dividido en 4 áreas
- Boot Record
File Allocation Tables (FAT1 y FAT2)
Root Directory
Data Area
Define el volumen y la ubicación del resto de áreas, además si la unidad es de arranque, el primer sector contiene el código necesario para la inicialización del sistema operativo.
En FAT 12 y FAT 16 es sólo el primer sector, mientras que en FAT32 son los 3 primeros sectores.
Recuerda 1 Sector para FAT12 o FAT16 y 3 para FAT32.
Pueden existir mas sectores reservados de forma opcional, de hecho casi siempre es así.
Habitualmente encontramos el valor EB 3C 90 que define este sector
File Allocation Table
Es una serie de direcciones a las que se accede como si se tratase de una tabla de búsquedas cuando se carga un archivo o se atraviesa un directorio.
Existen dos copias llamadas FAT1 y FAT2 tanto para FAT12-16-32 de ese modo si una de ellas se daña, corrompe o falla, se puede recuperar inmediatamente con la otra copia.
FAT12 es mas complicado de calcular (por el momento) puesto que cada entrada ocuparía 12bits (1 byte y medio), FAT16 serían 2 bytes por cada entrada y FAT32, 4 bytes por cada una de ellas.
Vemos un ejemplo para FAT16 que es “mas sencilla” de entender.
Los valores que marcan el inicio de FAT1 y FAT2 son F8 FF FF FF, a continuación existirán valores hexadecimales que le indican a la FAT si un determinado cluster está ocupado o no.
Como estamos hablando de FAT16, necesitamos 2 bytes (16 bits) por tanto tendremos que tomar parejas de bytes para saber si un determinado cluster está ocupado o no.
- Los valores 00 00 indican que el cluster está disponible
Los valores FF FF indican que es el fin de la entrada de un archivo
Otros valores reflejan la posición del archivo en el cluster.
Puede haber mas, pero de momento sólo nos fijaremos en estos.
root directory
Sólo existe para unidades FAT12 y FAT16, en FAT32 no encontraremos el área de Root Directory.
Es un área fija y localizada en el comienzo del volumen de la unidad inmediatamente después de las tablas FAT1 y FAT2.
Cabe destacar que sólo encontraremos aquí entradas a archivos y/o directorios que son accesibles desde el directorio raiz, por ello se llama Root Directory, es decir, en una estructura como esta:
Sólo existirían entradas en Root Directory asus, csrf, nomina.xls y serial.txt puesto que son los que estan en el directorio raiz.
Recuerda: No existe en FAT32
Data area
Es el resto del volumen, dividida en cluster y que almacena el contenido de los archivos y directorios.
Herramienta de Análisis Forense EnCase. Breve Introducción
Para continuar con el análisis del sistema de archivos vamos a necesitar algo que nos permita ver, aprender y estudiar lo anteriormente comentado, podríamos usar cualquiera, hasta un editor hexadecimal pero como una parte de este Taller va dirigido al análisis forense, empezaremos con una de ellas que se llama EnCase.
Desgraciadamente no es gratuita y las versiones Demo que podéis encontrar no son 100% operativas, vamos que hay que disponer de la Licencia correspondiente para ello, es una herramienta muy cara, de precio desorbitado y prácticamente va destinada a Cuerpos Policiales y de Seguridad Nacional.
Yo voy a usar la versión 4.2 aunque ya estamos por la 6, pero de esta última no tengo mas que la versión de prueba y no podre usar todas las funcionalidades que trae.
Una vez instalada, al ejecutar EnCase veremos algo así:
Lo primero ir al menú File y seleccionamos la opción New (Nuevo caso) y completamos el formulario con lo que creamos oportuno:
Luego Finalizar y quedará como se muestra a continuación:
Ahora debemos añadir los discos y/o dispositivos a analizar, para ello elegimos AddDevice en la barra de herramientas y cuando se muestre la pantalla de los dispositivos, verificamos la casilla 1, Local Drives y Siguiente
Aparecerá una serie de discos y unidades que tendremos que verificar para añadirlas al análisis, en mi caso elegí la unidad H que se corresponde con el pen-drive de esta primera práctica.
Después... siguiente y si es correcto Finalizar.
Dependiendo del tamaño de la unidad seleccionada tardará un ratito...
Si seleccionamos la unidad añadida al caso a analizar (en el ejemplo la H) veremos que en la parte derecha de Encase nos muestra diversa información, los archivos y/o carpetas que contiene y como se trata de una unidad FAT16, también informa de Primary FAT, Secundary FAT, Volume Boot, Volume Slack, y Los cluster libres o no asignados.
Vamos a comenzar por el análisis del Boot Record o como lo llama EnCase, Volume Root. También podemos encontrar autores (p.e. Microsoft) que hacen referencia a esta parte de la FAT como BPB (BIOS Parameter Block).
Seleccionamos en la parte derecha Volume Boot y en la zona inferior pinchamos en el icono que pone Disk.
En color Rosa vemos los sectores que pertenecen a los clusteres del Boot Record
En Azul claro (Cyan) tenemos Primary FAT (aparece un 1 en cada cuadradito) y Secundary FAT (un 2 en los cuadraditos)
En Verde se marca la zona que pertenece al Root Directory
En Azul oscuro los sectores ocupados por los archivos
En Gris los sectores no asignados.
En la parte derecha de los cuadraditos vemos que hay unas fichas de herramientas que pone Text, Hex y Legend... si pinchas en esta última tendrás la leyenda de lo que significa cada color
Bien, pues vamos a dejar la pantalla mas o menos como sigue:
Y ahora vamos a destripar la parte que hemos selccionado que es Record Boot o Volume Boot según EnCase.
Los más importantes están situados desde el byte cero hasta el byte 63 (los 64 primeros)
El contenido desde el byte 64 hasta el 510 ambos inclusive corresponden al código máquina del cargador de arranque si se trata de una unidad de inicio del sistema operativo (por ejemplo un disquete de inicio)
Los bytes 511 y 512 son siempre 55 AA que es la firma de la unidad de arranque y final del sector (EBR)
Este es un ejemplo de mi pen drive formateado en FAT16:
Una Tabla Resumen nos guiará en la interpretación:
Destripemos entonces de qué va esto:
EB 3C 90 -> Código de Arranque
4D 53 44 4F 53 35 2E 30 -> etiqueta en el ejemplo es: MSWIN5.0
00 02 - > Bytes por sector en little endian 512bytes
20 -> Numero de sectores por cluster -> 32
08 00 -> Regiones Reservadas en litllen endian (08 )
02 -> Número de Fat’s (2) que son FAT1 Y FAT2
00 02 -> Entradas máximas en el directorio raiz (512 en little endian)
00 00 -> Sectores Totales
F8 -> Descriptor del medio usualmente F0 para disquetes F8 para Discos Duros
F4 00 -> Sectores por Fat en little endian (00 F4) que son 244 sectores
3F 00 -> Sectores por Pista en little endian (00 3F) que son 63
FF 00 -> Número de caras en little endian (00 FF) que son 255
F4 00 00 00 -> Sectores ocultos en little endian (00 00 00 F4) 244 sectores
0C 63 1E 00 -> Longitud total de sectores en little endian (00 1E 63 0C) que son 1.991.436
00 -> Número de unidad
00 -> Banderas
29 -> Firma
2F EF 60 D4 -> Número de serie
4E 4F 20 4E 41 4D 45 20 20 20 20 -> Etiqueta de volumen, en el ejemplo es NO NAME
46 41 54 31 36 20 20 20 -> Identificador de Formato, en el ejemplo es: FAT16
...
55 AA -> Firma de la unidad y fin de sector
UN ANÁLISIS DE LA FAT Boot Record MAS A FONDO
Aunque FAT12 y FAT32 son diferentes de FAT16 muchos de estos valores y significados se pueden aplicar a ellos igualmente (recuerda que de FAT12 no voy a hablar nada) Aún así, algunos de estos campos pueden crear confusión.
No todos los sistemas operativos y/o dispositivos que manejan el sistema de archivos FAT atienden “literalmente” a estos valores, muchos de ellos los tratan sencillamente como comentarios o los ignoran directamente,
EB 3C 90 -> Código de Arranque
Poco mas que hablar.
4D 53 44 4F 53 35 2E 30 -> etiqueta en el ejemplo es: MSWIN5.0
Ciertamente es un comentario, daría igual lo que tengan estos 8 bytes, de hecho el pendrive de origen (sin formatear por Windows) tendría otros valores. En el análisis forense esto nos indicaría que ha sido formateado con un sistema Windows, nada mas. En un caso extremo, supongamos una sala en la que sólo hay dos equipos Windows, un Mac y varios Linux, al menos ya sabemos (o podemos intuir) que esa memoria usb se formateo en alguno de esos dos equipos, pero nada mas relevante.
00 02 - > Bytes por sector en little endian 512bytes
Los valores admitidos para todos los formatos y sistemas operativos son: 512 – 1024 – 2048 –4096
La compatibilidad máxima se obtiene con el valor 512, otros valores pueden no ser bien interpretados y la unidad no reconocerse o no poder usarla.
Recuerda también las diferencias entre lo que son las estructuras físicas y las estructuras lógicas, no por tener un tamaño de sector mas grande mejoraremos el rendimiento, igual es peor o desperdiciamos espacio.
20 -> Numero de sectores por cluster -> 32
Loas valores admitidos son 1 – 2 –4 –8 – 16 - 32 –64 y128
Como antes disponer de muchos sectores por cluster puede reducir el rendimiento y/o la capacidad, también agrupar muchos sectores en un cluster puede dar lugar a un fenómeno que no hemos hablado, la fragmentación interna.
Todos sabemos mas o menos que es la fragmentación, en condiciones óptimas un archivo grande se extiende por varios cluster contiguos, pero no siempre es así, cuando borramos información, volvemos a escribir, etc.. es probable que nuevos archivos ocupen espacios de aquellos que fueron borrados y estén “dispersos” en trocitos (fragmentos) por el disco, el sistema operativo “recompone” esos fragmentos “los sigue” y si está muy fragmentado todo es mas lento porque tiene que ir a buscar esso trozos por muchos sitios distantes. Esto es lo que conocemos como fragmentación, realmente esto es fragmentación externa.
Las utilidades del tipo OoDefrag o el mismo desfragmentador de Windows vuelven a colocar esos fragmentos en posiciones contiguas (siempre que sea posible) y ciertamente mejora el rendimiento del disco.
La fragmentación interna es algo parecido, solo que estas herramientas no la pueden solucionar, los archivos ocupan uno o más clusteres, pero como estos son muy grandes o mas grandes que la propia información del archivo, existe un sobrante (un Slack) muy grande, comprendido no?
Ya veremos cuando toque NTFS que existen otros problemas del tipo fragmentación como los Parse File, en fin.. esto es un mundo...
08 00 -> Regiones Reservadas en little endian (08 )
En FAT16 y FAT12 suele ser cero (observa que en el ejemplo tampoco lo es) rn FAT32 es precisamente 32, lo que nunca debe ser es CERO!!!
02 -> Número de Fat’s (2) que son FAT1 Y FAT2
Aquí no hay mucho mas que comentar, son 2 FAT la Primary FAT y la Secundary FAT. Si bien, valores mas grandes pueden ser perfectamente válidos incluso algunas memorias usb pueden venir marcadas con un 1, pero ni es recomendable ni es lo habitual. El estándar es 2.
00 02 -> Entradas máximas en el directorio raiz (512 en little endian)
Como dice el título del campo son el máximo número de entradas (archivos o carpetas) en el área de Root Directory. Esto solo tiene sentido en FAT12 y FAT16 puesto que Root Directory no existe en FAT32, en FAT32 este campo tiene un valor de 00 00
00 00 -> Sectores Totales
Este campo puede ser cero (como en el ejemplo) y si lo es, el campo Longitud total de sectores que veremos mas abajo, no debe ser cero.
En FAT32 este campo siempre será cero.
F8 -> Descriptor del medio usualmente F0 para disquetes F8 para Discos Duros
El valor F8 es el estándar para discos fijos y el valor F0 para discos removibles como disquetes, los valores admitidos son: F0, F8, F9, FA, FB, FC, FD, FE, y FF.
Lo verdaderamente importante es que lo que ponga en este byte también ha de ser el valor del primer el primer byte en la entrada de FAT1 y FAT2, vamos que en nuestro caso FAT1 y/o FAT2 deben comenzar por F8, veámoslo con EnCase:
Observa los recuadros en rojo que puse para resaltar lo que se ha comentado, el primer byte de FAT1 es F8.
F4 00 -> Sectores por Fat en little endian (00 F4) que son 244 sectores
Pues eso mismo, 244 sectores son los que ocuparán FAT1 (primaria) y FAT2 (secundaria), en FAT32 este campo tendrá el valor de cero (00 00)
Vamos a contarlos con EnCase:
En rojo tienes dos recuadros que marcan el primer sector de FAT1 y a su derecha en otro recuadro rojo se enmarca una “cosa” que dice LS8 (esto es Logical Sector
o dicho de otra forma, desplazamiento hacia la izquierda sector número 8 que es donde comienza FAT1
Ahora vamos a pinchar en el último sector de la FAT1 (ojo no te equivoques y pinches en el último sector de FAT2) y observemos lo que dice el LS
Como ves, ahora el desplazamiento indica LS251, o sea, los 244 sectores que hablábamos... A ver si alguno se confunde... 251 – 8 = 243 y no 244, pero ya sabes: El 8 es el primero, el 9 el segundo.... el 243 es el 250 y el 244 el 251) vamos que le sumes uno a la resta y ya está, es como contar del cero al nueve, si restamos: 9 – 0 = 9 pero son DIEZ elementos no nueve, jejeje... si es que hay que explicarlo todo.
3F 00 -> Sectores por Pista en little endian (00 3F) que son 63
Son los sectores por pista que cargará el gestor de arranque (interrupción 0x13 de la BIOS que es quien se encarga de ello) y sólo tiene significado para unidades divididas en pistas-cabezas-cilindros, vamos habitualmente los disquetes y los discos fijos.
FF 00 -> Número de caras en little endian (00 FF) que son 256
Como antes, este valor es usado por la interrupción ox13 de la BIOS para determinar el número de caras (cabezas) del dispositivo, usado para disquetes y discos duros.
F4 00 00 00 -> Sectores ocultos en little endian (00 00 00 F4) 244 sectores
Es el número de sectores ocultos (sectores no accesibles para datos) que preceden a la estructura FAT (Root Directory para FAT12 y FAT 16) y el propio área de datos para FAT32.
Cuando este campo tiene como valor 00 00 00 00 significa que el volumen no ha sido formateado.
0C 63 1E 00 -> Longitud total de sectores en little endian (00 1E 63 0C) que son 1.991.436
Cuando hablamos del campo Sectores Totales anteriormente ya lo citamos, si Sectores Totales es cero, este campo no debe ser cero y para FAT32 nunca lo será. Y cuenta lo que dice su descripción, la longitud total de sectores de la unidad.
00 -> Número de unidad
También es usado por la interrupción 0x13 de la BIOS y le indica si se trata de un disco fijo o de un disquete. 00 para disquetes y 80 para discos duros (fijos) En este caso el pen-drive lo interpreta como un disquete, también hay que advertir que este campo es específico del Sistema Operativo, Windows lo trata como 00, otros Sistemas pueden no entregar ese valor al formatear la unidad.
00 -> Banderas
Es un campo reservado y sólo lo usa Windows NT, vamos que normalmente es 00
29 -> Firma
Es una firma “extendida” que indica que los siguientes tres campos del sector boot están presentes, estos campos son el número de serie, la etiqueta de volumen y el identificador de formato, sin no están presentes este valor puede ser cero.
2F EF 60 D4 -> Número de serie
Este campo junto con el siguiente (Etiqueta de Volumen) se utiliza para detectar si se ha introducido un disco erróneo.
Este número de serie se genera mediante una combinación de la fecha y hora. En el análisis Forense puede servir para identificar un dispositivo, pero ello no significa que sea único para el mismo, simplemente puede ser una evidencia mas.
4E 4F 20 4E 41 4D 45 20 20 20 20 -> Etiqueta de volumen, en el ejemplo es NO NAME
Lo que dice... la etiqueta de volumen si la tiene (hasta 11 caracteres), y también se escribe en el área de Root Directory para sistemas de archivos FAT12 y FAT16.
46 41 54 31 36 20 20 20 -> Identificador de Formato, en el ejemplo es: FAT16
Es habitual encontrar las cadenas “FAT12 “, “FAT16 “ o “FAT32 “ Mucha gente piensa que estas cadenas son identificadores del sistema de archivos usado, no es cierto.
Sólo tiene un valor testimonial o mera información, no significa que realmente sea el sistema de archivos con el que se ha formateado la unidad, Microsoft no usa estos valores para averiguar si se trata de un sistema FATxx .
55 AA -> Firma de la unidad y fin de sector
Ufff!!!! Y eso que dicen que el sistema de archivos FAT era sencillito... ya veremos que NTFS simplifica bastante el reconocimiento y sistema de archivos, pero en fin... así es la vida, nadie dijo que sería fácil.
Podemos desprender alguna información útil de este ejemplo:
- Según el tercer campo (bytes 11 y 12) EL número de Bytes por sector es de 512
Según el cuarto campo (byte 13) El Numero de sectores por cluster es 32
Por tanto, un archivo cuyo contenido sea nada mas que 59 bytes realmente ocupará en disco: 512 bytes x 32 sectores = 16384 bytes = 16KB
La unidad “parece” haber sido formateada con un sistema Windows tal y como indica el segundo campo del boot record (bytes 3 al 10): 4D 53 44 4F 53 35 2E 30 -> MSWIN5.0
Además el campo Número de unidad tiene un valor 00 que es el que acostumbra Windows
- Según el campo sexto, el número de FAT’s es 02 (primaria y secundaria) este campo debería ser cero si se tratase de un sistema de archivos FAT32
Según el campo séptimo, el número de entradas máximas a Root Directory es 512, si fuese FAT32 este campo debería ser 00 00
El Campo Sectores por Fat tiene un valor de 244 sectores, si fuese un sistema de archivos FAT32 este campo tendrá el valor de cero (00 00)
Además, y aunque esta información puede variar y depende del Sistema Operativo usado para dar formato a la unidad, el campo Identificador de Formato tiene el valor: 46 41 54 31 36 20 20 20 que es:
- 46 --------- F
41---------- A
54 --------- T
31 --------- 1
36 --------- 6
File Allocation Table
Como se ha dicho, para FATxx (12-16-32) existen dos copias, las llamadas FAT1 y FAT2 (primaria y secundaria)
Estas dos copias son una serie de punteros o marcas que le indican al sistema de Archivos si un cluster está ocupado o no dentro del Data Region (Area de Datos)
Los valores que podemos encontrar son:
Observa que:
FAT12 utiliza 3 valores hexadecimales (12 bits)
FAT16 utiliza 4 valores hexadecimales (16 bits)
FAT32 utiliza 8 valores hexadecimales (32 bits)
Por lo demás, el/los rangos son idénticos, como antes vamos a estudiarlos en FAT16 en el que sólo se han de tomar dos parejas hexadecimales (16 bits) pero que podemos exportar lo que vamos a aprender a cualquiera de los otros sistemas, ya sea FAT12 o FAT32.
Volvamos a EnCase y en la vista de disco hacemos doble clic sobre el primer cuadradito de FAT1
A la derecha, teniendo la vista Hexadecimal, vemos los siguientes valores:
| Código: |
| F8 FF FF FF FF FF 04 00 FF FF |
Si le aplicamos lo que ya hemos aprendido y comentado….
F8 FF FF FF -> Indica el comienzo de una Tabla FAT
FF FF -> Cluster ocupado en el área de datos y fin de cluster
04 00 -> Puntero hacia el siguiente cluster
FF FF -> Cluster ocupado en el área de datos y fin de cluster.
El resto son ceros.... luego serán clusters disponibles para albergar mas datos.
¿Cúales son los clusters ocupados?
Pues vamos un momento a comentar cómo están los clusteres....
El primer cluster disponible para el área de datos es el DOS!!!!
Es decir, siempre tendremos que buscar los datos almacenados a partir de ese cluster, es como si los cluster 0 y uno no existiesen... recuerda esto para las futuras prácticas.
Si tras F8 FF FF FF nos aparece (como es en el ejemplo FF FF) significa que el cluster número 2 del área de datos está ocupado y que no hay mas clusteres asociados a ese archivo o carpeta.
Resulta que los siguientes valores del ejemplo son 04 00, esto significa que el cluster 3 “apunta” hacia el cluster 4, recuerda que los valores 04 00 hemos de tomarlo en little endian, hay que “dar la vuelta” a los valores (04 00 se convierte en 00 04) que es el siguiente cluster ocupado por el archivo o carpeta que sea.
Después nos encontramos los valores FF FF, como antes, cluster ocupado en el área de datos y fin de cluster para ese archivo o carpeta.
Por tanto, debemos entender esto:
F8 FF FF FF -> Comienzo de FAT1 ó FAT2
FF FF -> El cluster 2 del área de datos lo ocupa un solo archivo (vamos a llamarle archivo X)
04 00 -> El cluster 3 está ocupado por un archivo y “continua” en el cluster 00 04 (vamos a llamarle archivo Y)
FF FF -> El cluster 4 del área de datos está ocupado por el archivo Y terminando en este mismo cluster.
Dicho de otra forma... en nuestra FAT sólo existen dos archivos:
- El archivo X que ocupa el cluster 2 del área de datos
El archivo Y que ocupa los cluster 3 y 4 del área de datos.
Debemos tomar FAT1 y FAT2 como una tabla que informa de si un cluster está disponible, ocupado, erróneo, reservado, si es el último de un determinado archivo o si continua en otro cluster.
En el ejemplo que te he puesto no hay fragmentación externa, imagina que encontramos una tabla FAT1 o FAT2 que dice algo así:
| Código: |
| F8 FF FF FF FF FF 0A 08 FF FF 00 00 00 00 .... |
Deberíamos entender que hay 3 clusteres ocupados, el número 2, el número 3 y el número 2058 (0A 08 en little endian, 08 0A = 2058 en decimal)
O sea, que el archivo Y estaría fragmentado en los clusteres 3 y 2058, entendido no?
Veamos otro ejemplo, ahora para FAT32 que como utiliza 32bits tendremos que tomar 4 bytes por cada entrada en FAT1 o FAT2
F8 FF FF FF FF FF FF FF -> Marca de entrada en la FAT
03 00 00 00 -> El cluster 2 está ocupado por el archivo y continua en el cluster 3
04 00 00 00 -> El cluster 3 está ocupado por el archivo y continua en el cluster 4
FF FF FF FF -> el cluster 5 está ocupado por el archivo y fin de archivo en este cluster
00 00 00 00 y sucesivos... -> No hay mas archivos en el area de datos.
Se trata de un sistema de archivos FAT32 con una única entrada en el área de datos, no sabemos si se trata de un archivo o carpeta (de momento)
Te preguntarás que por qué esos resaltes en verde el byte 8, ¿a que si?
Bueno, pues esto enlaza con la siguiente parte de este texto... el Dirty Bit
El Dirty Bit
Todos alguna vez nos hemos encontrado con que tras un cierre inesperado del sistema o un mal funcionamiento del disco, etc... al reiniciarlo nos dice que tal disco o tal otro puede presentar errores, si deseamos corregirlos o a veces realiza un chequeo de esa unidad.
Como estamos “pensando en Windows” hay que decir que cuando inicia el sistema Operativo en una unidad FAT, Windows reemplaza un Bit cuando se carga el sistema y si se cierra normalmente vuelve a poner ese bit a su estado original es por ello que se sabe si esa unidad se cerró adecuadamente.
Veamos un ejemplo para FAT32, supongamos una entrada en la Primary Fat para FAT32 que sea como esta (solo nos interesan los primeros 8 bytes, en concreto el octavo)
Si bien Windows utiliza una operación XOR con máscaras 0x8000 y 0x4000 sobre parte de la secuencia (interesan los bits 4 y 5 nada mas, por eso se llama dirty bit y no dirty byte), en la práctica sólo tenemos que recordar esto:
Si el Byte número 8 tiene valores diferentes a FF ó 0F el sistema no se cerró adecuadamente.
- FAT16 F8 FF
FAT32 F8 FF FF 0F o también F8 FF FF FF
- Cuando Windows arranca el sistema operativo sobre una unidad FAT32 el octavo byte se cambia a 0F sólo para la unidad que corre el sistema y a FF para cualquier otro volumen que está siendo accedido y que no sea el de arranque. Estos valores se mantienen si arrancamos en el modo “seguro” o en el modo “consola”
Una vez que el sistema terminó de cargar por completo (mientras no hayamos elegido un arranque en modo seguro o símbolo de sistema) el octavo byte se cambia a 07 ó a F7 para la unidad de arranque u otras que no lo sean respectivamente, sólo si Windows se cierra adecuadamente vuelve colocar en el byte numero 8 los valores 0F y/o FF.
En FAT12 no se utiliza este tipo de comprobaciones.
Root Directory
Este area sólo existe para FAT12 y FAT16, la podemos ver en EnCase identificada por cuadraditos verdes en el área de disco:
Vamos a hacer doble clic en el primer cuadradito verde que representa el área Root Directory y luego observemos lo que muestra en la vista texto (Text)
Al menos como estás viendo ya se muestra en texto claro los nombres de los archivos... vemos serial.txt y cocoto.jpg como nombres de los archivos... pero hay mas... mas que decir de Root Directory.
Para empezar diremos que cada entrada en el área de Root Directory son de 32 bytes por cada entrada, esto es, 32 bytes por cada archivo y/o carpeta creada, y en ella se guardan mas cosas que el nombre del archivo... toca de nuevo hacerlo a mano, vamos a resaltar los primeros 32 bytes
Y como antes una tabla que nos explica cada uno de los valores es importante...
Comezamos con la “disección”
Los valores hexadecimales son:
Nombre del archivo
11 primeros bytes en el formato 8:3 (8 caracteres para el nombre y 3 para la extensión)
53 45 52 49 41 4C 20 20 54 58 54
| Código: |
| 53 -> S 45 -> E 52 -> R 49 -> I 41 -> A 4C -> L 20 -> [espacio] 20 -> [espacio] 54 -> T 58 -> X 54 -> T |
El archivo se llama serial.txt como ya esperábamos y sabíamos, seguro que mas de uno se estará preguntando qué pasaría si el nombre del archivo fuese numerodeserie.txt.
En ese caso no sería un “nombre corto” sino un “nombre largo”, dejaremos este caso para mas adelante, por ahora lo mas simple, es un nombre corto y el archivo se llama serial.txt.
Los archivos eliminados en sitemas FATxx se marcan al principio de los mismos con un carácter especial (E5 hexadecimal) como primer byte del nombre, ya lo veremos.
Atributos
| Código: |
| Sólo Lectura 01 Oculto: 02 Sistema: 04 Volumen: 08 Directorio: 10 Archivo: 20 |
En nuestro ejemplo es 20, es decir, un simple y sencillo archivo...
Podemos combinarlos, por ejemplo 20 + 1 + 2 + 4 = 27 y sería un archivo de sólo lectura, oculto y de sistema... lo mismo para directorios. ¿Está claro, no?
Byte reservado para Windows NT
En nuestro ejemplo es 18, nada significativo para el estudio de este caso.
Tiempo en mlisegundos
Pues lo que nsu nombre indica, una medida “mas granular” del momento de la creación.
El sistema operativo no nos muestra este valor y habrá que sumarlo para obtener la hora de creación del archivo. En nuestro ejemplo es 9E ó 158 milisegundos en decimal.
Hora de creación
En el ya sabido formato little endian, nuestro ejemplo nos dice que es 43 9B
Esta es la última vez que lo vamos a hacer a mano, lo aviso... jajajaj
Primero “damos la vuelta” al estar en little endian al valor y obtenemos: 9B 43
Lo pasamos a binario:
| Código: |
9 B 4 3 1001 1011 0100 0011 |
5 BITS PARA LAS HORAS -> 10011 --> 19 horas
6 BITS PARA LOS MINUTOS --> 011010 -> 26 minutos
5 BITS PARA LOS Segundos----> 00011 -> 3 segundos
Fecha de Creación
De nuevo en Little endian y también la última vez que se calcula “a mano” jejeje, eso digo siempre...
Nuestro ejemplo dice 8F 38, le damos la vuelta y queda 38 8F
En binario:
| Código: |
3 8 8 F 0011 1000 1000 1111 |
7 bits para los años + 1980 => 0011100 -> 28 +1980 = 2008 (año)
4 bits para los meses => 0100 -> 4 (mes)
5 bits para los días => 01111 -> 15 (día)
Vamos que fue creado el 15 de abril de 2008
Fecha del último acceso
Pues al igual que antes, un formato de fecha en little endian y tomando los bits 7 – 4 –5 como antes, en el ejemplo es 8F 38, luego coincide con la fecha de creación, entonces debería ser el 15 de abril de 2008 como antes...
Vamos a comprobar las horas y fechas calculadas:
- Veamos, la hora de creación es 19:26:07 y según nuestros cálculos debería ser 19:26:03, hay una diferencia de 4 segundos, bueno puede ser debido al desfase en milisegundos o a cualquier otro factor, no importa, parece que lo calculamos bien.
Aportación del compañero ramandi en cuanto a la explicación del cálculo de las horas y los milisegundos:
http://www.wadalbertia.org/phpBB2/viewtopic.php?t=4631&start=14
Los 5 bits para los segundos sólo nos permiten representar 32 valores, así que la resolución es de 2 segundos. Por tanto, habría que mutiplicar ese valor por 2.
Para completar la resolución, se usa el campo de milisegundos, que tiene una resolución de 10ms, es decir, el valor del campo se multiplicaría por 10ms y se sumaría al de los segundos que hemos visto antes. De ahí los límites de dicho campo (0-199), para cubrir justo los 2 segundos de margen que nos dejaba el campo anterior, con resolución temporal hasta las centésimas de segundo
La fecha de creación está perfecta, la hemos clavado.
La fecha/hora del la última modificación no la hemos calculado, así que como si no estuviese...
Lo que SI ES IMPORTANTE es que la fecha del último acceso es muy diferente... según nuestros cálculos debería ser 15 de abril de 2008 y la pantalla anterior nos muestra 16 de abril de 2008.
Esto nos lleva a un tema SERIO e IMPORTANTE en lo que atañe al análisis forense...Si ese pendrive fuese una prueba objeto de investigación ACABAMOS DE ALTERAR su contenido y podría ser desestimado en un caso judicial por ello.
Hombre, pensarás que por una fecha de nada... que tiene su explicación... “Vera Sr. Juez, resulta que el sistema operativo aun sin abrir un archivo y por supuesto sin modificarlo, con tan solo resaltarlo nos cambia la fecha del último acceso, pero no he cambiado nada, lo juro....”
Y el Sr. Juez dice que cómo puede estar seguro de eso... como tener la certeza que no se modificó nada, si automticamente se ha modificado eso... no sería posible que se hayan alterado otra información?
Nosotros contestaríamos que NO, porque la fecha de última modificación es la que es y como puede comprobarse no ha sido modificada...
Y el Sr. Juez dice... ¿Y cómo podemos estar seguro de eso si ya se ha modificado una de las fecha? ¿Quién me asegura que la fecha de ultima creación no le pasó lo mismo?
Vamos, que la duda existe y puede desestimar esa prueba....
Por ello es FUNDAMENTAL y ya lo veremos, hacer una imagen fiel del dispositivo y trabajar con la imagen no con la unidad original. Por otro lado, EnCase NO MODIFICA NADA!!! Vamos que hagamos lo que hagamos con esta herramienta no altera contenido alguno.
Para estas circunstancias existen “bloqueadores” hardware que impiden cualquier modificación, intencionada o fortuita, del dispositivo original.
También podemos usar un pequeño “truco” para las memorias USB como es este caso, existe una clave en el registro de Windows que “bloquea” por software la manipulación de cualquier dato en un dispositivo, jejeje, siendo pérfidos y alejándonos del ámbito del Taller forense, podemos fastidiar a cualquiera impidiendo la escritura en un USB y a menos que sepa deshacer el cambio en el registro, no podrá escribir nada en esa memoria.
Esto lo veremos cunado “ataquemos” el registro de Windows, hay muchas otras claves del registro interesantes para un análisis forense, pero valga este ejemplo como ilustración... y para que no esperéis hasta que lleguemos a esa parte, aquí va:
Accedemos al registro de Windows con la herramienta regedit (Inicio-ejecutar-regedit)
Buscamos la clave HK_Local_Machine\System\CurrentControlSet\Control
Creamos una nueva clave llamada StorageDevicePolicies
En esa nueva clave creamos un valor DWORD llamado WriteProtect y le damos el valor de 1.
Eso sí... sólo para Windows XP + ServicePack2
Bueno, sigamos y terminemos con el lo que estamos....
Valor mas significativo de cluster de inicio.
En nuestro caso es 00 00 porque estamos ante un sistema de FAT16, si fuese FAT32 existiría otro valor que junto con el campo Valor menos significativo del cluster nos daría (en formato little endian) el cluster de inicio del archivo
Hora de última escritura
Son los siguientes 2 bytes en formato Little Endian y los podemos calcular tal y como aprendimos anteriormente con los formatos de fecha y hora, en nuestro ejemplo es: E9 84.
Fecha de última Escritura
Lo ya explicado... en el ejemplo: BF 34
Valor menos significativo del cluster de inicio
En nuestro ejemplo es 02 00
Como hemos hablado, se utiliza junto con el campo “Valor mas significativo del cluster de inicio”, si unimos los dos campos tendremos:
02 00 00 00 en little endian lo tomaremos como 00 00 00 02, o sea el cluster dos.
Tamaño del Archivo
En nuestro ejemplo, 3B 00 00 00 que en little endian es 00 00 00 3B
Luego el tamaño del archivo es: 3B hexadecimal o 59 bytes en decimal
Que podemos comprobarlo con la pantalla de antes cuando observamos las propiedades del archivo.
Un link de descarga:
http://www.megaupload.com/es/?d=8QSAF4T5
Eso es una imagen de “parte” de mi pendrive con el que estoy elaborando este Taller, una vez bajado de megaupload y guardado en vuestro disco sólo tenéis que hacer doble clic en la imagen y se abrirá EnCase con el ejemplo de estas prácticas... claro... que habéis de tener EnCase instalado en vuestro equipo, aunque eso ya debería de ser... verdad?
El área de datos sin secretos.
Antes de empezar con esta parte, vamos a descargar una nueva imagen de ejemplo en el formato Evidence File (EnCase) de este link:
http://www.megaupload.com/es/?d=74WPFTZ2
Así todos podemos usar el mismo ejemplo... Una vez descargado, hacéis doble clic en el archivo y se abrirá EnCase (se recuerda “al personal” que hay que tenerlo instalado)
En esta práctica que nos servirá para recordar parte de lo ya explicado y también para descubrir “los secretos” del área de datos, es importante que observes con atención:
En el directorio raíz del pen-drive tenemos dos carpetas
- Prueba1
Prueba2
- CUMPLE.GIF
Asterix.jpg
- Prueba1
- Víctor.doc
- Prueba2
- Piratas.jpg
Es importante porque como veremos a continuación en el área de Root Directory que estudiamos antes, no nos aparecerá la información relativa a los contenidos de las carpetas!!!
RECUERDA que esa zona solo guarda información directa con el contenido del directorio raíz, los archivos Víctor.jpg y Piratas.jpg NO están en el directorio raíz, “cuelgan” de sus respectivas carpetas.
Vamos a dar un vistazo al área de Root Directory como aprendimos anteriormente, antes prepararemos a EnCase para que nos facilite algo mas el trabajo y nos sea mas fácil examinar los contenidos:
Herramienta de Análisis Forense EnCase. Introdución 2.
Tenéis que intentar poner la pantalla de Encase como aparece a continuación:
Expliquemos alguna cosa...
En la zona superior izquierda podemos tener varias fichas... De momento solo aparecen Cases y Bookmarks
La ficha Cases es la que nos mostrará “El caso” abierto para analizar, las unidades, volúmenes, carpetas, etc... ES IMPORTANTE para este ejemplo que pinches en ella.
De los Bookmarks ya hablaremos, en un ratito, por el momento es bueno saber que en esa barra de herramientas en las que solo nos muestra Cases y Bookmarks pueden aparecer mas...
Todas aquellas que “saquemos” mediante el menú View, por ejemplo, desplegamos el menú View y seleccionamos Text Styles
Ahora en la barra de herramientas que estamos estudiando aparecerán las tres, Cases, Bookmarks y TextStyles, y como esta última es la que hemos seleccionado, también cambiará el contenido de la zona superior izquierda y derecha:
Obviamente, podemos pinchar de nuevo en Cases o Bookmarks para realizar las acciones oportunas....
Si queremos cerrar una de las herramientas, bastará que pulsemos sobre ella con el botón derecho y elegir Close...
Vamos a quitar la herramienta Bookmarks...
Y cuando elijamos Close, se cerrará esa pestaña de Bookmarks... quedando sólo Cases y TextStyles que sacamos anteriormente.
Lo importante de todo esto (por el momento) es que recuerdes el manejo de esa zona... para que cuando en prácticas posteriores hablemos de “Vamos a TextStyles” o “Abrimos SearchHits”, “Keywords”, “Scripts” etc... sepas como se hace y como llegar hasta ello.
Ahora vamos a fijarnos en TextStyles, pinchamos en esa ficha de la herramienta y veamos que aparece en la zona superior derecha:
En esa zona también tenemos barra de herramientas, por el momento sólo existen las fichas Table y Report... importante que tengamos seleccionada la ficha Table de esa zona superior derecha.
Vamos a crear “un nuevo estilo de texto” para que nos presente “mejor” la información.
Si recuerdas el área de Root Directory son entradas de 32 bytes, por ello crearemos un estilo de texto al que llamaremos Estilo_FAT con un tamaño de 32, para ello pinchamos una zona en blanco del área derecha y elegimos New:
Tras ello modificamos la casilla de Name con el nombre de nuestro nuevo estilo, Seleccionamos la opción Max Size y en la Casilla Wrap Length ponemos el valor de 32, así:
Ahora, antes de Aceptar, Pinchamos en la Ficha Code Page de la pantalla anterior y activamos la opción de Other y mas a la derecha buscamos entre los distintos tipos de codificación aquella que diga ISO Latin I (que en mi caso es el número 64) tal y como se muestra mas abajo. Por último Aceptar.
En la zona derecha aparecerá nuestro nuevo estilo, hay que asegurarse que lo tenemos verificado (y sólo ese), asi:
A partir de este momento, siempre que vitalicemos texto, lo “formateará “ con 32 bytes de longitud y como ese es el tamaño de las entradas en Root Directory resultará que por cada línea representada tendremos una entrada de Root Directory,
Ejemplo:
- Accedemos a la Ficha de Cases
Pinchamos en Disk en la barra de herramientas del centro
Pinchamos en el primer cuadradito verde del área de Disco (Root Directory)
Si ahora (en la barra de herramientas del centro de la pantalla, en lugar de Disk, elegimos Text) aparecerá:
Como ves se ajusta a 32 y tendremos una línea por cada una de las supuestas entradas a Root Directory.
Aparecen 7 entradas en lugar de las cuatro que esperábamos...
No le des muchas vueltas, puede que sean asignaciones inválidas o reservadas, también ha podido ocurrir que se trate de una entrada cuyos datos han sido sobrescritos o sencillamente un espacio reservado por si usamos nombres largos, en cualquiera de los casos, las entradas dos, cuatro y seis no son válidas en este ejemplo..
También nos dan una pista, si observas el nombre del archivo “casi es el mismo” que el “bueno”, eso nos indica que el archivo no se ha renombrado (esto es una pura conjetura, pero no deja de ser cierto), por ejemplo, esta entrada:
Es “idéntica” excepto por el nombre... “parece” que el nombre original era Nueva~1 (seguramente Nueva Carpeta) y se renombró a JAJAJ, no es que sea muy significativo, pero algo es algo...
A lo que vamos, que ahora en el estilo de texto que tenemos nos visualiza las entradas de 32 en 32 y esto se corresponde con cada uno de los archivos y/o carpetas que tenemos almacenados.
De este modo podemos analizar más cómodamente las entradas de Root Directory, las marcas de tiempo (fechas de creación, horas, ultimo acceso, cluster, etc.. ) todo eso que ya vimos.
Pero como dije en su momento, ya no calcularemos mas veces “a mano” esos valores... para eso tenemos a EnCase.
Vamos ha realizar una consulta de, por ejemplo, la entrada número cinco, que es la de la carpeta Prueba2... para ello resaltamos los 32 bytes de la misma (toda esa línea), pulsamos el botón derecho del ratón y elegimos BookmarkData, así:
Aparece otra pantalla y en ella buscamos en el estructura en árbol de la izquierda, donde pone Data Type, la clave Windows y dentro de la misma, DOS Directory Entry
En la [i]zona inferior[/i] nos muestra toda la información disponible para esa entrada de Root Directory, sin tener que calcular las fechas, horas, tamaño, etc.. “manualmente”
Bueno, lamentablemente EnCase se “enrolla poco” y nos desajusta un poco la salida... debería ser así:
En fin, que nada es perfecto.... Prueba con las otras entradas, incluso con las inválidas a ver si te sale como se muestra a continuación:
El archivo Asterix.jpg
El Archivo... (invalido??)
He retocado las imágenes para que las columnas se ajusten... tú las verás algo mas desordenadas, ya sabes....
Bueno, todo esto era necesario... míralo como un breve repaso al área de Root Directory y para saber algo mas de cómo funciona Encase, pero realmente es necesario por lo que hablábamos al principio de esta sección...
No aparecen por ninguna parte los archivos Víctor.doc y Piratas.jpg... por si te has perdido, te recuerdo que esos archivos “cuelgan” de las Carpetas Prueba1 y Prueba2 (estas sí que aparecen)
Y esto nos lleva a saber cómo está organizada el área de datos...
Mientras todo “cuelgue” del directorio raíz, todos los archivos y carpetas aparecerán como entradas en el área de Root Directory, pero si existen “subcarpetas” o “subdirectorios”, el contenido de éstos no se muestra “a simple vista”
Tomemos como ejemplo de esta explicación del área de datos, la carpeta Prueba2 y su contenido el archivo Piratas.jpg
Antes de nada tenemos que localizar la carpeta Prueba2, para ello o usamos Root Directory y la “técnica” vista antes del BookmarkData o Directamente pinchamos en el nombre de la carpeta
Con BookmarkData vemos que ese archivo/carpeta está en el cluster 6
Si lo hacemos del otro modo:
Y tenemos que comentar varias cosas de aquí...
- Primero en la zona superior izquierda se selecciono la ficha de Case
Segundo, en la zona superior derecha se resalta la carpeta Prueba2.
Tercero, En la barra de herramientas “central” se elige la vista “Disk”
Cuarto, en esa misma barra observamos claramente que pone CL 6 (cluster 6)
Quinto, En el área azul (datos) se auto selecciona todos los clusters que pertenecen a Prueba2 (en la pantalla se ve como azul mas intenso)
Sexto, en la zona inferior derecha hemos elegido la Ficha “Hex” y nos muestra el contenido en hexadecimal y mas a su derecha su contenido en texto, además he ajustado el tamaño de esa ventana para que se muestren de 32 en 32 (arrastrando la columna hacia la izquierda tanto como sea necesario para obtener el resultado deseado) esta es otra manera de ajustar la visualización sin recurrir a los TexStyle de antes...
Si analizamos uno a uno cada uno de ellos obtendremos resultados muy similares a los que ya hemos hecho en repetidas ocasiones, pero hay algo “especial”... MUY ESPECIAL.
Si observas en el área de texto que hay a la derecha del área hexadecimal, en este “Root Directory” del área de datos tenemos CUATRO entradas para esta carpeta!!!! Ciertamente la tercera y la cuarta son la misma o mejor dicho, la tercera es como si fuese inválida por lo explicado antes acerca de la posibilidad que sea una entrada con datos sobrescritos, nombres largos o entrada inválida, olvidémonos de ella y pensemos que son tres.
Tres???? Pero no decías que sólo contiene el archivo Piratas.jpg??? Por qué tres???
Pues si observaste bien, LAS DOS PRIMERAS son:
- Punto (.) que ya sabemos que simboliza el directorio actual
Punto, punto (..) que es el directorio “padre” o anterior
La tercera entrada de esta carpeta es precisamente el archivo Piratas.jpg, bueno, realmente es la cuarta porque la tercera es inválida por lo de la posibilidad de ser asignaciones inválidas y/o espacio reservado para albergar los nombres largos.
Por tanto, si tenemos carpetas que cuelgan de Root Directory, tendremos tantas entradas como archivo y/o subcarpetas cuelguen de la misma, mas otras dos, las relativas al punto y al punto-punto.
Y si hay subcarpetas de la subcarpeta??? Pues igual, al menos las entradas punto y punto-punto mas todos los archivos y/o carpetas que cuelguen de ella.
Por lo demás, se comporta exactamente como el área Root Directory pero sin serlo propiamente.
Una vez mas (esta vez sin explicaciones) analizamos uno a uno los 32 bytes de la primera entrada correspondiente a la carpeta Prueba2 (la que corresponde al punto)
| Código: |
| 2E 20 20 20 20 20 20 20 20 20 20 -> nombre del archivo, 2E que es el punto. 10 -> Tipo de archivo, 10 que indica que se trata de un directorio 00 -> Valor reservado para Windows NT 5D -> valor en milisegundos de la hora de creación F3 98 -> Hora de creación del directorio 93 38 -> Fecha de creación del directorio 93 38 -> Fecha de último acceso 00 00 -> Número más significativo del cluster que ocupa el archivo (0) F4 98 -> Hora de última escritura 93 38 -> Fecha de última escritura 06 00 -> Número menos significativo del cluster que ocupa el archivo, el 6 00 00 00 00-> Tamaño en bytes (cero, claro es un directorio) |
Te recuerdo lo de los números mas significativos y menos significativos del cluster que ocupa el archivo, en FAT12 y FAT16 el número mas significativo siempre es cero, lo tendríamos que “leer en little endian”: 00 00 00 06 para nuestro ejemplo, vamos el cluster 6.
Esto nos lleva a otra característica de FAT16, como los bytes mas significativos son siempre cero, el número máximo de clusters serían siempre FF FF, es decir, 65536 clusters, si cada cluster tiene un tamaño de 32k pues,
| Código: |
| 65536 x 32768 = 2GB aprox. |
En nuestro caso, son clusteres de: 16Kb,
| Código: |
| 16384 x 65536 = 1 GB aprox. |
Digo aproximadamente porque FAT1, FAT2, Root Directory y Boot Record ocupan espacio en disco, ocupan 14 clusters en total en los que no se almacena información de usuario.
Esta es una tabla orientativa de la capacidad de FAT16 comparada con FAT32
Siguiendo con lo nuestro, lo del área de datos, si analizamos la entrada correspondiente a Piratas.jpg (esta vez no habrá hexadecimales, recurrimos al BookmarkData de Encase) y por última vez te podré las pantallas de cómo se efectúa esta operación... sin comentarios, eso, sí...
Vemos los valores de Piratas.jpg que cuelga de Prueba2, horas, fechas, tamaño, cluster....
Resumiendo, el área de datos efectivamente almacena los datos de los archivos y/o carpetas del disco pero para los directorios y subdirectorios se comporta como si de el área Root directory se tratase, con la excepción que por cada carpeta, además de las entradas a los archivos que la componen, incluye entradas para los directorios especiales punto (.) y punto-punto (..)
Además hemos aprendido bastantes cosas de Encase, Los BookmarkData, los visores de estilos de texto y un uso mas adecuado del mismo para tratar los datos con que nos vamos encontrando, yo creo que con toda esta información que ya ha sido explicada y requete-explicada estamos en condiciones para empezar “en serio” con la parte de acceso a la información, a entender cómo las herramientas de recuperación de datos funcionan, a recuperarlos manualmente, a restaurar un sistema de archivos “perdido”, etc..
Todo esto y mas.. como el File Carving, como Búsquedas “inteligentes”, utilización de Scripts, etc es lo que en la parte de prácticas y ejemplos tendremos que realizar, unas veces manualmente (porque las herramientas automáticas fallan o no logran acceder a toda la información) y otras con la ayuda de herramientas forenses como es el caso de Encase.
Queda todavía otro “escollo”, como tratar eso de los nombres largos... aquellos que no cumplen eso de 8:3.
También hay algo importante que comentar, el MBR (Master Boot Record), hasta ahora estamos dando por hecho que el Sistema de Archivos FATxx de nuestros ejemplos no es de arranque, es mas... estamos dando por hecho que todo está en una única partición de disco, vamos que aun queda camino... sin embargo el asunto de particiones y MBR lo veremos mas afondo cuando nos toque NTFS, hasta tendremos ejemplos de volúmenes FAT y NTFS en acción... todo llega.
Nos conformaremos con FATxx, de hecho, FAT32 opera de un modo similar a FAT16 y como ahora entenderás, no usa área de Root Directory (no existe), en su lugar, el propio área de datos es usada para ello como hace FAT16 con los subdirectorios, solo que FAT32 lo hace para TODO.
Algún ejemplo caerá... hasta entonces te voy a adelantar lo que haremos con FATxx en el apartado de ejercicios:
- * Acceso a datos y recomposición manual de archivos.
* File Carving, esto es, búsqueda de información mediante firmas de archivos
* Recuperación de datos borrados total y parcial (a mano y a máquina.)
* Restauración y recuperación de datos en particiones formateadas (manualmente)
* Búsqueda de evidencias y firmas de archivos sospechosos mediante patrones.
* Algo más que ya se me ocurrirá
De momento paramos aqui....
Os recuerdo que este hilo está cerrado para mantener una mejor claridad en los contenidos, cualquier duda, comentario y demás lo haremos en este otro post:
http://www.wadalbertia.org/phpBB2/viewtopic.php?p=48010#48010
EJERCICIOS Y PRÁCTICAS CON FATxx
Ejercicio/Práctica 1. El acceso a los Datos
Para esta práctica vamos a tomar como ejemplo una de las imágenes Evidence File de Encase que ya hemos utilizado anteriormente:
http://www.megaupload.com/es/?d=74WPFTZ2
Se corresponde con la imagen número 2 de los ejemplos descritos en apartados anteriores, aquella que tiene dos carpetas y dos archivos en el directorio raíz junto con un archivo de datos por cada una de las carpetas.
Más que una recuperación de datos, esta práctica va dirigida mas a comprender cómo funciona Encase en este aspecto, como extrae la información y la forma básica de su uso.
Realmente no vamos a recuperar nada porque está todo lo que hay, sin fragmentos, sin file slack, sin elementos borrados, vamos que es un ejercicio lejos del análisis forense pero que nos acercará a como realizar actividades mas complejas en un futuro.
Se trata de extraer el contenido del archivo Piratas.jpg que cuelga de la carpeta Prueba2 suponiendo que no es visible “sin mas” (que lo es) y en un hipotético supuesto de no tener acceso al mismo por estar borrado, perdido o inaccesible.
Lo vamos a hacer “a ciegas” siguiendo la pista desde Root Directory, pasando por la carpeta Prueba 2 hasta llegar al cluster de ese archivo y volcando su contenido para “ver” lo que tiene.
Lo primero que haremos es poner a Encase en el modo que nos presenta la información en “franjas” de 32 bytes como aprendimos antes. Para ello usaremos el estilo_FAT que ya tenemos y ajustamos la visualización al efecto, ha de quedar como vimos.... así:
Ahora usaremos la funcionalidad de BookmarkData para averiguar el cluster de inicio del archivo que indica la entrada...
Resaltamos los 32 bytes de la última entrada, la que dice Piratas.jpg y pulsando con el botón derecho del ratón seleccionamos BookMarkData, después accedemos a la sección DOS Directory Entry y así conocer los datos que necesitamos, que para este caso, nos basta con saber el cluster de inicio y el tamaño, veámoslo por pantallas:
Acabamos de averiguar que el tamaño del archivo es de 24.791 bytes y que comienza en el cluster 7.
Como cada cluster de nuestro sistema de archivos es de 16KB (16384 bytes) también conocemos que necesitará de DOS clusters completos (32768 bytes son 2 cluster), si no está fragmentado serán el 7 y el 8, pero si está fragmentado... ¿Cómo saberlo?
Pues vamos a la entrada de Primary FAT (FAT1) o FAT2, daría igual puesto que una es copia de la otra, y observamos lo que dicen los valores que apuntan al cluster 7.
Por si no se ve bien en la captura de pantalla, el resalte en azul y que he recuadrado en rojo de los valores hexadecimales son: 08 00 FF FF
¿Recuerdas como era el funcionamiento de los punteros de la FAT1?
08 00 en Little endian, es decir, el cluster 00 08 es el que continua con el contenido del archivo.
FF FF indica que termina el archivo en ese cluster.
En la práctica, nuestro archivo Piratas.jpg:
- * Comienza en el cluster 7 y tiene un tamaño de 24.791 bytes como nos dijo BookmarkData
* El cluster 7 de la FAT1 apunta al cluster 8 y en este mismo termina el archivo.
Bien, pues vamos al cluter 7... la forma mas simple es... pulsamos con el botón derecho del ratón sobre cualquier área de la superficie del Disk (la de los cuadraditos de colores) y seleccionamos View Cluster....
Y se nos “encogerán” los cuadraditos... ahora sólo veremos clusters y no sectores...
Los cuadraditos ahora son clusters, no sectores... para ir al 7 es fácil, contamos desde el primero azul oscuro que representa al área de datos y ya está... pero claro, si fuese el 279 en lugar del 7 es mas “rollo” así que como en Sistemas de Archivos mas grandes nos vamos a encontrar en estas tesituras, lo diremos a Encase que se vaya al 7....
De nuevo pulsamos con el botón derecho sobre la zona de clusters, la de los cuadraditos.. y seleccionamos GoTo....
y nos aparecerá un cuadro de diálogo en el que seleccionaremos Other y ponemos el número de cluster al que queremos acceder... el 7 en nuestro caso, por último OK.
Nos lleva al cluster 7 como vemos...
No sólo eso... fíjate que en la zona superior derecha ya nos aparece el nombre de ese archivo (piratas.jpg) sólo que nosotros como si no estuviese... y en la zona inferior, a la izquierda nos pone que es el 7 y a la derecha el contenido... vamos a ampliar la visualización del contenido...
Aunque no viene al caso de esta práctica, ya te voy adelantando... todos los archivos tienen o disponen de lo que se llama un File Signature (Firma del Fichero), para el caso de los archivos jpg, la firma no sólo es su extensión, sino los primeros bytes del mismo... incluso (como es este caso también) tienen de “un pié” o final característico del archivo.
Esta es una de las bases del File Carving que veremos mas adelante, consiste en encontrar esas “marcas” y hacer “suposiciones” para recuperar un tipo determinado de dato.
Bien, sirva como ejemplo, un jpg “clásico” comienza por: FF D8 FF E0 y habitualmente le siguen los valores 00 10 4A 46, como es nuestro caso.
Pero bueno, esto ya llegará mas adelante... lo que nos interesa ahora es copiar todo ese contenido para poder verlo...
Para ello, pulsamos el botón derecho del ratón sobre el área de hexadecimales y seleccionamos Export...
Aparecerá esta pantalla y seleccionamos en ella lo que se muestra:
Physical View es TODO el cluster (recuerda que tenemos la vista de cluster y no de sectores) físico, es decir desde el primer byte hasta el 16.384
También podríamos haber elegido “una parte” mediante Custom Range, ya veremos en otras prácticas como le sacamos utilidad a ello, en esta oportunidad nos interesa todo.
La opción “Logical View” no está disponible por que el contenido de este archivo ocupa TODO el cluter, dicho de otra forma, no hay Slack... cuando lo haya, podremos usar esa opción y entonces en lugar de copiar el contenido de todo el cluster, copiaría sólo hasta el fin de archivo.
La opción Exact Binary Image, copiará el contenido “exacto” de otra forma lo haría en modo texto y es muy probable que al tratarse de un archivo binario luego no se recupere correctamente...
Como es de suponer le tenemos que decir en qué carpeta y con qué nombre queremos recuperarlo... en el ejemplo, unidad C:\recupera y con nombre img1
La casilla Append to exiting File no nos interesa, es útil cuando queremos “pegar” parte de una exportación a otra, no es el caso, sin embargo lo será cuando recuperemos el resto...
¿Recuperar el resto? ¿El resto de qué? Hombre, recuerda que este archivo le hemos calculado un tamaño de 24 mil y pico de bytes y que lo que estamos “sacando” ahora son sólo los primeros 16.384 byes, el resto habrá que añadirlo... claro ahora, no?
Bueno, que le damos a OK y ya está...
Si observamos la carpeta c:\recupera, veremos que tenemos un archivo que se llama img1 con un tamaño de 16KB... y si lo abrimos???
Pues venga, como no tiene extensión (no la pusimos) elegimos cualquier visor de imágenes que tengas, yo usaré el que trae el propio Windows...
y aleeeee!!! Ya tenemos una parte... la otra la conseguimos igual, sólo que:
- * Nos situamos en el sector 8 (eso es lo que decía FAT1), no hace falta que hagas lo del Goto porque es el cuadradito inmediatamente posterior al que estamos....
* Y cuando exportemos, activaremos la casilla de Append to exiting File que antes no quisimos utilizar.
y cuando vayamos a verlo con el visor de imágenes de Windows... estará completito...
Como ves es una práctica sencilla y “poco espectacular” pero esto será la ase de muchas otras cosas, “sin querer” has aprendido:
- * Otros usos que podemos dar a Encase
* Cómo copiar fragmentos de un archivo
* Identificar una cadena de inicio de un archivo jpg.
* “Seguir el rastro” del contenido de un fichero por el sistema de archivos
* Conocer dónde comienza y la importancia que tiene el consultar la FAT1 para saber si el siguiente fragmento es contiguo o está en otro sector/cluster alejado...
* “sin querer” acabas de aprender el funcionamiento de las herramientas de recuperación de datos borrados, no era nuestro caso, el archivo estaba “vivo” en el sistema de archivos, pero podría perfectamente pertenecer a los elementos eliminados... el proceso es el mismo (casi, casi...)
* Y también “sin querer” a que podemos recuperar un parte de “algo”
También podemos “imponer” esa firma de cabecera y “pegar” un contenido probable, a veces es posible recuperar una parte si “jugamos bien nuestras cartas”..
Como ejercicio “extra” te propongo que intentes obtener este resultado (o parecido) jugando con la cabecera y trozos sueltos componemos parte de la imagen como se muestra en esta pantalla:
Y una cosa mas de los archivos JPG, este tipo de archivos terminan con una secuencia hexadecimal específica: FF D9
Si accedes al cluster numero 8 y buscas en las ultimas posiciones del archivo, lo verás...
Otra forma fácil de encontrarlo es poner “la vista hexadecimal” y en el cluster 8 recorremos el contenido hasta encontrar la parte de File Slack (en rojo tras el final del archivo)
Te comento que en estas prácticas (y en casi todas de esta parte) no encontrarás slack (restos de archivos anteriores) puesto que antes de realizar las pruebas hice u “wipeo” a ceros de toda la unidad... por eso el slack file de éste cluster está a ceros....
EJERCICIOS Y PRÁCTICAS CON FATxx
2.- Recuperación de Datos tras Formatear la unidad. File Carving I
Esta práctica las vamos a desarrollar con esta imagen Evidence File de Encase.
http://www.megaupload.com/?d=1QTFZ9JA
Supongamos que tenemos un pendrive en el que (entre otras cosas) almacenábamos un documento de Word y una imagen JPG que contenían las instrucciones de cómo llegar a la Isla del Tesoro y un mapa del mismo respectivamente.
Como lees, hablo en pasado porque desgraciadamente nos equivocamos y formateamos la memoria usb por equivocación... no nos acordamos de cómo se llamaban los archivos, sólo que en un documento de Word teníamos las instrucciones y en una imagen, el mapa.
Además de lamentar el error, lo primero que recurrimos es a una de estas herramientas que recuperan información perdida, formateada o incluso eliminada las particiones... hay muchas por el mercado, unas mejores que otras, a mi especialmente me gusta GetDataBack.
Es muy, muy potente, la llevo usando hace años y en circunstancias favorables recupera prácticamente todo, como anécdota os contaré la de un cliente mio y su portátil.
- Resulta que no le funcionaba bien del todo y lo llevo al servicio técnico de HP puesto que pensaba que era un problema de hardware...
El servicio técnico, ni corto ni perezoso, le restauró la copia del sistema operativo y zas!!! A tomar por saco todos sus datos, es un galerista de arte y en ese portátil tenía información valiosa para él, miles de fotos y fichas de trabajo de exposiciones y viajes por todo el mundo....
Bien, pues con este programita se le recuperó más de un 98% de los archivos tras la restauración del sistema que le hicieron... vamos que es una joya de programita... y con muchas posibilidades, restauración por red local, bloqueo de unidades, etc...
Tras pasarle el programa nos arroja estos resultados:
Sólo nos recupera dos carpetas... y dentro de ellas encontramos estos archivos:
Resulta que esta buena herramienta sólo nos recupera los archivos victor.doc y piratas.jpg, en un alarde de intuición y con ese nerviosismo de saber si estará ahí lo que buscamos, los recuperamos y examinamos su contenido...
El archivo Piratas.jpg contiene la fotito de los piratas del caribe... no el mapa que buscamos..
Y el archivo Victor.doc tiene un “santoral” de los días de S.Victor... eso es para que cuando lleguen me vayáis felicitando, jajajaa... pero no tiene esas instrucciones “tan buscadas”
Entonces??? No están??? Los hemos perdido???
Pues aparentemente sí... pero ¿por qué? Por qué recupera unos sí y otros no...???
Explicaciones puede haber muchas, datos sobrescritos, errores en el sector, mal funcionamiento del programa de recuperación... etc... pero este no es nuestro caso, os puedo asegurar que los datos están ahí y que los vamos a recuperar.
Lo primero que nos llama la atención es que sólo nos recupera dos carpetas y los contenidos de las mismas... si lo piensas esto es normal, ¿lo sabes ya?
Claro, al formatear se han sobrescrito/borrado las áreas de:
- * Boot Record (esta no nos interesa hoy para la recuperación),
* FAT1 y FAT2, con la consiguiente pérdida de asignaciones y punteros, vamos que los datos están pero no sabemos en qué clusters y los punteros que nos llevan de unos a otros...
* Root Directory: Por lo que todo aquello que estuviese en el directorio ráiz se ha borrado y ya no tenemos información de ello.
* El área de datos NO se ha tocado, el formateo no alteró nada de esta área!!!
¿Si dos carpetas cuelgan del directorio raíz, cómo es posible que recupere esas carpetas junto con sus contenidos (archivos victor.doc y piratas.jpg) y no recupere otra información?
Pues lo explicamos de nuevo: Si te fijas, GetDataBack recuperó dos carpetas... pero NO sus nombres, la explicación es que esos nombres de carpetas formaban parte de Root Directory.
Y por qué recupera los contenidos?
Porque ya explicamos que una carpeta es un contenedor y las entradas de sus contenidos se almacenan en el área de datos no en Root Directory, por eso es capaz de recuperar con nombres incluidos los archivos e incapaz de hacerlo con todo aquello que colgase del directorio raiz y que no fuese carpeta.
La “trampa” de este ejercicio, es precisamente esa... los archivos que nos interesan estaban en el directorio raíz y por eso utilidades de recuperación NO PODRÁN extraer la información perdida tras el formateo porque no encuentran entradas al Root Directory.
Esto para FAT16, con FAT32 y/o NTFS la cosa cambia y puede ser mas sencillo, de hecho es mas sencillo, probablemente podamos recuperar todo, pero estamos con FAT16 amigos...
No confundáis el área de Root Directory con lo que “se vé” con el explorador de Windows en el directorio raíz...
Hay mucha relación, pero no es exactamente los mismo, el directorio raíz que muestra el explorador de Windows lo realiza consultando a Root Directory, pero no es todo el contenido de Root directory..., por ejemplo un archivo borrado no se muestra, pero puede estar perfectamente y puede ser recuperado...
Vamos a la tarea... Antes de nada, tenemos que “saber” cuales son las Firmas de los archivos que buscamos... ya hemos hablado del File Carving... es un método por el cual podemos “buscar” información y /o archivos mediante patrones de búsquedas que caracterizan a un tipo concreto de fichero.
Conocer todos es como imposible pero siempre tendremos ayuda, por ejemplo esta web puede sernos bastante útil para saber mas acerca de la estructura de los archivos “bien conocidos”:
http://www.wotsit.org/
Como lo que buscamos son concretamente archivos creados con MS-Word y una imagen jpg (suponemos que es jpg, también podríamos hacer un File Carving de varios archivos de imágenes a la vez).
EnCase Dispone de muchas firmas (Signatures) de ficheros comunes, también podemos “alimentar” manualmente con nuevas firmas y hasta hay actualizaciones para ello.
Al comienzo de cada archivo:
- Los .doc de Office cuya firma típica es: D0 CF 11 E0 A1 B1 1A E1 00 00
Los .jpg de imagen cuya firma típica es: FF D8 FF E0 00
- Los .doc de Office suelen terminar en: 00 57 6F 72 64 2E 44 6F 63 75 6D 65 6E 74 2E 38 00 F4 39 B2 71
Los .jpg de imagen terminan con: FF D9
Si analizásemos un File Slack, es muy interesante saber cómo terminan puesto que podríamos determinar el tipo de archivo y aplicación con que se escribió en su momento de ese espacio “sobrante” que no pertenece al archivo actual.
En este ejercicio nos bastará con la firma de cabecera pero como vamos a echar el resto en nuestra recuperación lo haremos hasta encontrar esa marca específica de fin de archivo (manualmente o con búsqueda específica... ya veremos.)
Pues a por ello... vamos a preguntar y configurar Encase para que nos informe de los File Signature que necesitamos.
Una vez que tengamos la imagen que ya os habréis descargado y con Encase en marcha, empecemos por averiguar las firmas de estos dos tipos de ficheros.
Ahora iremos al menú View y seleccionaremos File Signatures y en la zona superior aparecerá algo como esto:
En la parte izquierda, resaltamos la penúltima firma, la que dice Picture y veremos que a la derecha nos despliega una zona con determinado tipo de archivos, extensiones, firmas, etc... si miras en la pantalla que sigue a continuación te recuadré en rojo las dos que nos interesan... si... encase recoge los archivos .doc dentro del grupo de Picture...
Ahora vamos a ver “el File Signature” para los archivos jpg, para ello hacemos doble clic sobre el JPEG Image (la número 13) nos aparecerá un cuadro de diálogo para editar esta entrada, lo que haremos es simplemente resaltar aquello que pone en Search Expressions y copiarlo (botón derecho y copiar), asi:
Los que ya estamos mas habituados a Linux no encontraremos muchos problemas en entender eso que pone GREP, los que no, no os preocupéis de momento, ya hablaremos en otra ocasión de búsquedas mediante GREP, ahora sólo recordar que esa casilla estaba marcada para que mas adelante lo dejemos tal cual.
Una vez copiado el contenido de la casilla Search expressions, Cancelamos .
De nuevo iremos al menú View y seleccionamos Keywords, una vez mostrada la ventana de keywords, pulsamos con el botón derecho del ratón y elegimos New... así:
Aparecerá un cuadro de diálogo similar al visto cuando editamos las firmas JPEG, en él que pegaremos la copia hecha anteriormente del SignatureFile, activamos la casilla de GREP y le damos un nombre descriptivo (el que se nos antoje, yo utilicé Firmas JPG)
Una vez realizada esta operación, ya tendremos un nuevo Keyword que se llama Firmas JPG en la ventana de Keywords con las firmas que necesitamos para ficheros JPG.
Ahora te toca a ti... has de hacer lo mismo para los archivos .doc, es decir, vas a File Signatures, editas la entrada de los .doc, copias la firma y te creas otro nuevo keyword con el nombre Firma DOC por ejemplo, si lo hiciste correctamente debería quedarte esto:
No se te olvide, como ya hice yo, verificar las casillas de estos dos nuevos leywords que acabamos de crear (3 y 4) porque de otro modo no se aplicarán cuando busquemos...
Vale... seguimos, ahora en la barra de herramientas superior, pulsaremos en el icono de la lupa que es la Search...
Y un nuevo cuadro de diálogo aparece:
Seleccionamos las casillas de verificación como muestra la pantalla de arriba (observa que al activar Selected keywords only) sólo buscará 2... los nuestros, los que creamos y verificamos antes..
También es importante verificar la casilla Search file Slack dado que como no tenemos area de datos (está formateado) para encase toda esa área es un slack
Las otras dos indican si se buscará también dentro de cada fichero (daría igual porque teóricamente no hay ficheros...) y si queremos verificar las firmas de archivos, ambas están verificadas..
Una vez hecho esto pinchamos en Start y dependiendo de lo grande que sea nuestro disco tardará varios minutos, horas, días... este tipo de localizaciones es muy lenta puesto que va inspeccionando sector por sector toda la unidad...
Si te fijas, en la zona inferior de la pantalla y parpadeando aparecerá algo como esto:
De momento dice que encontró 6 Hits (coincidencias) y que le faltan aproximadamente 1 minuto 13 segundos...
Cuando termine dará un informe que si lo deseamos podemos copiar:
Para ver los resultados de la búsqueda por keywords realizada tenemos que ir de nuevo al menú de View y seleccionar Search Hits.... saldrá esta pantalla que nos muestra dos localizaciones para el keyword DOC_Word
Si pinchamos en el de abajo, donde pone JPG que es el otro keyword que generamos... aparecerán 4 entradas:
Ufff!!!, ya queda menos...
Yo voy a recuperar el archivo del mapa del tesoro... espero que tú seas capáz de hacer lo mismo para las “instrucciones” este es un ejercicio propuesto para que postees en el foro tus resultados.... vamos, el examen de esta práctica
Tenemos varios problemas... 4 archivos, se supone que son imágenes jpg, pero no sabemos su tamaño... ni tan siquiera sabemos cual de las cuatro puede ser, así que, lo primero que vamos a realizar es una exportación de cada uno de ellos (como cuando recuperamos el archivo de piratas del caribe en la práctica 1 de este post)
Explicaré “con detalle” como hacerlo con uno de ellos... el segundo, por ejemplo, y tu lo deberás hacer por tu cuenta con los otros tres:
Seleccionamos la segunda entrada de la pantalla y sobre el área hexadecimal usamos el botón derecho del ratón y elegimos Export
Aparece un cuadro de diálogo que ya conocemos de la vez anterior... seleccionamos las opciones correspondientes como siguen y le damos un nombre y ruta de recuperación (en mi caso elegí: c:\recupera\img2) y por último pulsamos en el botón OK
Si ahora vamos a la carpeta c:\recupera y abrimos el archivo img2 veremos su contenido....
Vaya, hombre... es Asterix, no el mapa del tesoro....
Al realizar la misma operación con las entradas 1-3 y 4, obtendremos “una parte” de esas imágenes:
Estas:
Imagen 1 recuperada:
Imagen 3 recuperada (no hay vista disponible)
Imagen 4 recuperada
Parece ser que la imagen número 1 es parte de nuestro mapa... es el que buscábamos, que habíamos perdido tras el formateo de la unidad y que magníficas herramientas como GetDataBack no son capaces de recuperar...
Si recomponemos todos los clusters de este archivo, tendremos la imagen final:
Dejo de tu cuenta como ejercicios lo siguiente:
- * Recomposición total del archivo imagen 2 (que es el preciado mapa del tesoro)
* Recuperación del archivo .doc que incluye las “instrucciones” de cómo llegar, ya te adelanto que en éste hay algo de “truco” pero si has estado atento a toda la explicación no has de tener mayor problema
Este es el link:
http://www.megaupload.com/?d=UOXJHKUK
En fin, esta práctica ha sido posible gracias a que ninguno de los archivos que nos interesaban estaban fragmentados, de haber sido así, hubiese sido mucho mas laboriosa su recreación (no imposible, pero obviamente mas difícil)
Esto te dará una idea de lo tedioso y laaaargoooo que puede ser la reconstrucción de una evidencia, muchas horas de trabajo, pero un GRAN trabajo.
Aun quedan mas prácticas de FATxx, un par de ellas o tres antes de pasar a NTFS
Bueno, ahora sí... hasta la próxima práctica... que ya solo quedan dos o tres de FAT y pasaremos a otro sistema de archivos....
De momento paramos aqui....
Os recuerdo que este hilo está cerrado para mantener una mejor claridad en los contenidos, cualquier duda, comentario y demás lo haremos en este otro post:
http://www.wadalbertia.org/phpBB2/viewtopic.php?p=48010#48010
EJERCICIOS Y PRÁCTICAS CON FATxx
3- Nombres Largos (Long Names)
Supongamos un sistema de archivos con sólo dos ficheros en el directorio raíz:
| Código: |
| uno.txt nombrelargo.txt |
Para “matar dos pájaros de un tiro” usaremos en esta ocasión el sistema de archivos FAT32 en lugar de FAT16, así conoceremos un poco mejor esta versión de FAT.
Los que queráis seguir esta misma práctica, podéis descargar el archivo Evidence File en:
http://www.megaupload.com/?d=5I3JCBGX
Veamos como está representada FAT32 cuando abrimos EnCase:
Lo primero que llama la atención es que ya no aparecen los “cuadraditos verdes” que representaban al área de Root Directory de Fat16... Recuerda que ya se ha dicho en multitud de ocasiones que físicamente no existe esa área diferenciada en FAT32.
Lo segundo es que es existen muchos mas sectores/clusters para Boot record y FAT1/FAT2 (la vista de la pantalla anterior es la vista de clusters...) en vista de sectores:
Recuerda que FAT32 es 32 bits y que FAT16 son 16 bits, por tanto la forma de referenciar sus entradas eran:
| Código: |
| FAT16: 2 bytes, por ejemplo FF FF FAT32: 4 bytes, por ejemplo FF FF FF FF |
Es por ello que FAT32 necesitará mas espacio físico destinado a los punteros de FAT1/FAT2 y al boot record
Como diferencias significativas, dentro del Boot record, observaremos que el sector 6 es UNA COPIA del MBR (Master Boot Record) que como recordarás es el primer sector del disco (sector 0) de tal forma que se podrá “recuperar” si algo falla.
Las tablas de punteros FAT1 y FAT2 usarán 4 bytes para cada entrada referenciada en el área de datos y ocho para el inicio de FAT1/FAT2
Es decir, en nuestro ejemplo, tenemos ocupados los clusters 1, 2 y 3, libres todos los demás...
La primera pregunta que te estarás haciendo es
¿Si sólo tenemos 2 archivos, por qué se marcan como usados 3 clusters en lugar de los dos?
La respuesta deberías de “adivinarla...” como no hay área de Root Directory, la propia área de datos dispone de la información que almacenaba Root Directory en FAT16.
En nuestro ejemplo, el cluster 1, no es otra cosa que las asignaciones de nombres, fechas, tamaños, atributos, etc. de los archivos que forman parte de esta práctica...
Veámoslo:
No importa que no “veas” bien el contenido de esta imagen, sólo fíjate que marcando el primer cuadradito azul oscuro del área de datos nos muestra una “especie” de Root Directory...
Ahora, con más detalle:
Si tomamos como ejemplo la primera entrada y repasamos sus contenidos, tenemos
55 4E 4F 20 20 20 20 20 54 58 54: Nombre del fichero (uno.txt)
20 -> Atributo, fichero normal
18 -> Valor reservado para Windows NT
A7 -> Tiempo en milisegundos de la hora de creación
8C 85 -> Hora de creación
99 38 -> Fecha de creación
99 38 -> Fecha del último acceso
00 00 -> Valor mas significativo del cluster de inicio en el area de datos
5A 85 -> Hora de última escritura
99 38 -> Fecha de última escritura
03 00 -> Valor menos significativo del cluster de inicio
25 00 00 00 -> Tamaño en bytes del archivo.
Hay que recalcar que como estamos en un sistema de archivos FAT32 el valor más significativo del cluster de inicio SI SE HA DE TOMAR EN CUENTA (este campo siempre es 00 00 en FAT16 y FAT12) pero no tiene por qué serlo en FAT32.
En nuestro ejemplo, el cluster de inicio sería: 00 00 03 00
Y como ya estamos acostumbrados, en littlen endian:00 00 00 03
OBSERVA: que no se “dan la vuelta” como estamos acostumbrados... sólo se dan la vuelta por cada pareja.... a ver, otro ejemplo, supongamos que tenemos esto:
| Código: |
| Valor mas significativo: 02 00 Valor menos significativo: AB 01 El cluster de inicio sería: 00 02 01 AB |
Es decir, el valor mas significativo son siempre los primeros 2 bytes y el menos significativo los segundos, aplicando la forma little endian por cada pareja y no a los cuatro a la vez.
Siguiendo con nuestro ejemplo, si accedemos al cluster número tres que es el que hemos calculado, tendríamos el contenido de ese fichero, recuerda también que el área de datos comienza en el cluster DOS!!!! Vamos que aunque sea el segundo cuadradito azul oscuro se corresponde realmente con el cluster 3, míralo bien (segundo cuadradito -> cluster 3)
Pero vamos con nuestro archivo de “nombre largo”...
Si retomamos de nuevo la entrada del cluster 1 que es quien guarda en este caso los datos de nuestros archivos...
Para no “enrollarme” mas de la cuenta, los valores que diferencian a un nombre largo de uno corto, son:
La primera columna resaltada se corresponde con el “atributo” (si es solo lectura, oculto, sistema, etc...) en los nombres largos es 0F
La segunda columna resaltada debería ser el tiempo en milisegundos si se tratase de un nombre corto, en los nombres largos es un checksum, una comprobación.
La tercera columna remarcada se corresponde con el valor menos significativo del cluster de inicio para los nombres cortos, en los largos siempre será 00 00 (observa que esto en sí mismo no es un síntoma de que sea un nombre largo)
Hay más “indicios”, realmente es bastante mas complejo de lo que a “simple vista” se pueda observar, de hecho, todo debería comenzar con el byte número uno que realiza una máscara con el valor 0x40... pero como se trata de averiguar si estamos ante una entrada de nombre largo o corto, con las tres indicaciones dadas anteriormente nos sirven.
Observa también que sólo tenemos dos archivos y lo que parecen cuatro entradas... una para el archivo uno.txt y tres entradas para nombrelargo.txt de las cuales las dos primeras son los valores del nombre largo y la última lo que sería la representación de ese nombre como si fuese corto....
Otro ejemplo:
En este caso verás que el archivo que recuadré en amarillo dispone de cuatro entradas para él solito.... las trs primeras hacen referencia a su nombre “largo” y la última a su nombre “corto”, todo dependerá de la cantidad de caracteres que incluyamos en el nombre o en la extensión.
Bueno, creo que es suficiente para este asunto, añadir una cosa... a veces las herramientas de recuperación de datos borrados no consiguen recuperar el nombre largo de un archivo y sí el corto, vamos que igual tenemos un archivo que se llama:
Nominas_de_la_empresa.xls
Y si lo recuperamos tras un borrado accidental, etc... resulta que nos lo recupera con el nombre:
Nomina~1.xls, seguro que te ha pasado mas de una vez...
Para finalizar este asunto, te dejo una tabla con el formato de los nombres largos para que la estudies y comprendas como se realiza el formato de los mismos:
EJERCICIOS Y PRÁCTICAS CON FATxx
4- Archivos Borrados y áreas SLACK
Esta si que es simple… el primer carácter de un fichero se marca con el valor 0xE5 que simboliza la eliminación del mismo y esto es válido tanto para los sistemas de archivos FATxx como para NTFS.
Que hayamos eliminado el fichero no significa que lo podamos recuperar “sin mas”, es posible que el cluster que ocupaba ya haya sido asignado a otro fichero y por tanto no por cambiar ese valor recuperaremos el/los archivos borrados.
Encase puede recuperar los archivos borrados incluso si han sido sobrescritos por otros nuevos, claro que en ese caso, el contenido de la recuperación no será el que esperábamos... pero bueno, es lo que hay.
Para seguir este ejercicio descarga esta imagen de encase:
http://www.megaupload.com/?d=A5HUOEV6
Cuando lo lances encontrarás algo asi:
Tenemos 4 archivos, los dos primeros (marcados con un aspa roja) se corresponden con ficheros que han sido borrados y que tras el uso del dispositivo otros archivos ocuparon su espacio y el contenido de los mismos ha sido sobre-escrito:
El tercer archivo parece normal... el que se llama UNO.TXT
El cuarto (que aparece con un signo rojo de prohibido) es un archivo eliminado que se puede recuperar junto con su contenido.
Observa que en los archivos dos y cuatro el primer carácter no se muestra, en su lugar aparece el signo de subrayado (es una representación puesto que como veremos inmediatamente el valor de ese primer byte es E5)
Para recuperar el archivo _OS.TXT basta con realizar unas simples acciones:
Nos situamos en el archivo en cuestión:
Pulsamos el botón derecho del ratón y seleccionamos Copy/UnErase
Aparece un cuadro de diálogo y le indicamos el primer carácter (el que queramos... yo puse una D ) , activamos la opción Highlighted File (para recuperar solo el que tenemos marcado) y pinchamos en Siguiente:
De nuevo seleccionamos lo que viene a continuación:
Alguna aclaración de estas opciones vendrá bien:
- Logical File Only: Recupera sólo el contenido del archivo
Entire Physical File: Recupera todo el/los cluster del archivo
RAM and Disk Slack: Recupera el RAM Slack (desde donde termina el contenido hasta el final del cluster)
RAM Slack only: Recupera el RAM SLACK unicamente…
El RAM slack es la zona donde termina el archivo y el final del sector
RAM Slack and disk slack es todo el area slack, la ram slack y el resto del cluster.
Ejemplo:
Cuando veamos el ejemplo de slack en esta misma práctica entenderás mejor lo valioso que puede llegar a ser.... sigamos con la recuperación:
Incluimos la unidad y ruta del archivo a recuperar... y ya está... en la carpeta recupera tendremos el archivo DOS.TXT con sólo su contenido... observa que dice 93 bytes.
Para que veas la información “interesante” que se puede conseguir en el slack... vamos a realizar este ejercicio sobre el archivo UNO.TXT que es “normal”, vamos que no está borrado y cuyo contenido no es otra cosa que:
| Código: |
| “Este es un archivo de prueba” |
Te lo pongo por pantallas todo seguido para que lo veas:
(observa que se copiaron 4.096 bytes no sólo el “contenido”)
Si hora vemos el contenido recuperado del archivo UNO.TXT, entre otra información “inútil” o de difícil comprensión nos encontramos con sorpresas como esta:
Como ves el area slack es golosa... se pueden buscar evidencias, palabras “clave” a investigar, direcciones de correo o todo aquello que se nos ocurra o pensemos que pueda existir.
Windows sólo borra (wipea) el RAM slack de cada archivo, esto es, desde el final lógico hasta el final del sector que ocupa, el resto del cluster o deja tal cual..
Uno de los sistemas más difíciles de recuperar información son los Macintosh, puesto que el sistema que usa es borrar todo el slack, desde donde termina el contenido lógico hasta el ultimo sector del último cluster que físicamente pertenece al fichero.
Cuando veamos NTFS (que ya está “casi terminado”) os reservo una sorpresita... ¿qué os parecería ocupar los espacios slack con.... un netcat “oculto”? un virus? Imágenes secretas??
Pues sí... se puede, y el sistema de archivos no lo detectará porque es un espacio “sobrante” que para él no tiene sentido alguno
bueno, esto último son más técnicas anti-forensic que otra cosa... pero también lo veremos!!!!EJERCICIOS Y PRÁCTICAS CON FATxx
5- Particiones y MBR
Ya conocemos que un disco puede ser dividido en “trocitos” lógicos a los que comúnmente llamamos particiones. Habitualmente se hacen para una mejor distribución de los datos, una partición para el sistema, otra para datos, otra para un nuevo sistema operativo, etc...
En esta ocasión vamos a estudiar cómo analizar esas particiones, cómo localizarlas y cómo pueden ser restablecidas si las “perdemos” o se dañan...
Empezar diciendo que existen lo que llamamos particiones primarias y extendidas... el límite se establece en cuatro sin embargo gracias a las particiones extendidas podemos aumentar ese número.
Una partición extendida se puede desglosar en unidades lógicas, es por ello que ese límite de cuatro particiones por disco hoy en día no es del todo cierto.
Cada unidad lógica se comporta a su vez como si de una nueva partición se tratase, por ejemplo:
Vemos en esa pantalla que tenemos 6 particiones con distintos sistemas de archivos (las hice pequeñitas para que al pasaros el ejemplo no sea muy pesada la imagen) y no contienen datos alguno (bueno, puede que encontremos algo en el slack ...)
Además, hay un poco de todo... tenemos particiones FAT, FAT32 y NTFS hasta una no asignada...
Podéis descargarlo aquí: http://www.megaupload.com/?d=CHBVAL1N
Cuando lo tengáis en Encase como ya es habitual, vamos a ver algunas cosas “nuevas”...
Durante unos instantes, en la zona inferior derecha de la pantalla de Encase, aparecerá una barra de progreso y Verificando....
Esto es porque la imagen de las particiones las hice con verificación de Hash... realmente todas las anteriores las hice así, solo que esta al ser mas grande, se aprecia algo mas...
En el análisis forense es importante constatar que “la prueba” o “la copia” es un fiel reflejo de la realidad... y eso se consigue mediante las firmas MD5 u otras...
Si observas el contenido de la Ficha Report en Encase:
El hash de la imagen adquirida y la verificación es el mismo es idéntica, eso nos garantiza que no hubo errores, manipulación, alteración de datos, etc...
Bueno, tras este pequeño inciso, vayamos a lo que nos ocupa...
La primera diferencia con las prácticas anteriores es que ahora hemos obtenido una imagen “total” de la unidad de disco... es por ello que aparecerán varias unidades C, D, E, F y G una por cada partición que creamos en el “original”.
La tabla de Particiones y el MBR
El MBR es el Master Boot Record, se corresponde con el sector 0 de toda unidad de disco y en ese primer sector el Sistema Operativo encontrará y/o buscará la información que necesite para acceder a las particiones entre otras cosas.
Pongámos a EnCase en marcha para esta práctica...
Ponemos la vista de “Disk” y en la parte derecha la ficha “Hex” y Seleccionamos el sector cero como muestra la imagen.
Observa que al tratarse de un “volcado” de la unidad de disco completa, aparece un cuadradito rojo que en ejercicios anteriores no estaba, no es otra cosa que el MBR.
De los 512 bytes que componen el MBR sólo nos interesan unos pocos por el momento... concretamente todos los que existan desde el offset 446 hasta el final o si lo prefieres las últimos 66 bytes, te cuento como verlos con unas pantallas:
Primero resaltamos los primeros 446 bytes y luego desde el siguiente byte hasta el final...
Bien, pues en toda esa zona que hay sombreada en azul se encuentra la información sobre las particiones (si es que las hay, que sí que las hay) de nuestro disco.
Cada partición utiliza 16 bytes y el final del MBR termina con 55 AA
La primera “duda” que te asaltará es la siguiente... si tenemos 5 particiones como es el caso que nos ocupa (la sexta no está asignada), entonces...
6 particiones x 16 bytes = 96 bytes y si te fijas en la pantalla anterior después del recuadro rojo, pone LE 66
Lo dicho anteriormente... como máximo podemos tener en cada disco 4 particiones (4 x 16 = 64) + 2 bytes del “fin de MBR” (el 55 AA) son los 66 que nos marca Encase.
Entonces?? Pues la partición Extendida “contiene” dos unidades lógicas y ya veremos que esa partición extendida tiene también su propio MBR para referenciar a todas sus unidades lógicas.
Vamos a pedirle a Encase que nos muestre datos de este sistema de particiones...
Sobre los últimos 66 bytes que ya teníamos resaltados, pulsamos el botón derecho del ratón y seleccionamos Bookmark Data
Y aparecerá un cuadro de diálogo en el que buscaremos en la estructura de árbol la parte Data Type, buscamos Windows y luego seleccionamos Partition Entry
En la zona inferior veremos la tabla de particiones, algo desordenada como ya ocurrió otra vez, voy a retocar la parte inferior de la imagen para que se vea mejor:
bueno, la información que nos devuelve está bien pero no es del todo correcta, parece que se hace un poco de lío con FAT16 y lo llama BIGDOS, pero sobre todo, nos da la información de la extendida pero no de sus unidades lógicas.
Esta misma información la podemos sacar “a mano” nosotros, es mas, hasta vamos a identificar con más claridad las unidades lógicas de la partición extendida.
Además, esto que vamos a aprender, nos puede ser útil para una recuperación manual del la tabla de particiones.
Por cada partición... 16 bytes, veamos, tomemos como ejemplo los primeros 16 bytes que se han de corresponder con la primera entrada, la que dice Encase BIGDOS.
Estos son: 00 01 01 00 06 FE 3F 19 3F 00 00 00 5B 5F 06 00
Y sus significados:
Byte 1 Indicador de Arranque (00)
- Se usa por algunos gestores de arranque para indicar cual de las particiones debería ser inicio (0 la primera, 1 la segunda...etc.)
- Cilindro, Cabeza y sector en los que comienza la partición, nuestro ejemplo:
Cilindro 01, Cabeza 01, Sector 00
- Indica al Sistema Operativo el sistema de archivos que usa esa partición, para una lista completa de los códigos de particiones puedes visitar esta página:
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
Si la partición es extendida podremos encontrar códigos 05, 0F y 85. depende del sistema operativo, Windows suele marcarlo con un 05, Windows 95 con un 0F, Linux con 85... nuestro caso es un 06 que si consultas en el enlace que puse, se corresponde con: DOS 3.31 o superior, 16-bit FAT (mayor de 32MB)
Encase la reconoce como BIGDOS tal y como vimos.
- Cilindro, Cabeza y Sector del final de la partición
En nuestro ejemplo, Cilindro FE (254) , Cabeza 3F (63), Sector 19 (25)
- Pues el sector de inicio expresado en Little Endian, 00 00 00 3F que es el sector 63.
- El tamaño en Little Endian, 00 06 5F 5B que es 417627
Nuestro ejemplo es:
| Código: |
Indicador de arranque: ............... 00 CHS de inicio: ....................... Cyl. 01 Cabeza 01 Sector 00 Tipo de partición:.................... 06 FAT 16 CHS Final:............................ Cyl. 254 Cabeza 63 Sector 19 Sector de inicio:..................... 63 Tamaño en sectores: .................. 417627 |
Si lo comparamos con lo que nos muestra Encase concuerda perfectamente...
Bien, pues si queremos llegar hasta “la siguiente” partición no tendremos mas que desplazarnos al sector de inicio + tamaño en sectores, es decir,
- Sector de inicio 63 + 417327 del tamaño = 417690 sector de la siguiente partición...
Sobre cualquier sector de la vista de disco, botón derecho del ratón y Go To
En el cuadro de diálogo de Go To, escribimos el valor calculado y pulsamos en OK
y nos lanzará a la entrada de la siguiente partición:
Vamos a ver ahora las extendidas... para ello volvemos al sector 0 del MBR y consultamos la tabla de particiones como hicimos antes mediante Bookmarkdata solo que ahora nos fijaremos en la tercera entrada que es la de las extendidas...
Si lo hacemos “a mano” como antes, tendremos que coger los bytes de la tercera entrada:
Que sería:
| Código: |
Indicador de arranque:................ 00 CHS de inicio:........................ Cyl. 00 Cabeza 01 Sector 2E Tipo de partición:.................... 05 EXTENDIDA CHS Final:............................ Cyl. FE Cabeza 3F Sector 3A Sector de inicio:..................... 00 0B 46 AE Tamaño en sectores.................... 00 03 2F CD |
En decimal:
| Código: |
Indicador de arranque:................ 00 CHS de inicio:........................ Cyl. 00 Cabeza 01 Sector 46 Tipo de partición:.................... 05 EXTENDIDA CHS Final:............................ Cyl. 254 Cabeza 63 Sector 58 Sector de inicio:..................... 738990 Tamaño en sectores.................... 208845 |
Si accedemos al sector 738990 que hemos calculado mediante la opción de Go TO que usamos anteriormente en Encase (Recuerda, botón derecho sobre el área de disco, selecciona Go To y le das el valor calculado) llegaremos hasta el MBR de las particiones extendidas!!!!
Y podremos calcular de nuevo dentro de ese MBR el inicio de las unidades lógicas como si se tratasen de particiones primarias
Así:
Eso te lo dejo como práctica personal...
Se trata de que calcules manualmente y vayas visualizando TODAS las particiones (primarias, extendidas y unidades lógicas) de este ejemplo... anotas los datos obtenidos y los vas posteando en el foro para ver si todos tenemos los mismos valores...
Bien, chicos... hasta aquí de momento con FATxx... hemos avanzado mucho, conocemos bien el sistema de archivos FAT16 y FAT32, a partir de ahora comenzaremos con NTFS.
Hasta NTFS!!!, digo hasta pronto...
Finalizamos el sistema de archivos Fatxx con este post.
Os recuerdo que este hilo está cerrado para mantener una mejor claridad en los contenidos, cualquier duda, comentario y demás lo haremos en este otro post:
http://www.wadalbertia.org/phpBB2/viewtopic.php?p=48010#48010
Entradas
1 comentario:
Muy interesante material...pronto estare enviando algunos materiales sobre la misma herramienta. Omar
Publicar un comentario