TEMA 2.

FICHEROS

¿Cómo estudiar este tema?

En este tema de la asignatura vamos a introducir los conceptos necesarios para
entender todo el tratamiento de los ficheros que realiza un sistema operativo:
cómo funcionan los sistemas a la hora de estructurar la jerarquía de ficheros, la
manera en la que los ficheros son tratados cuando se borran y los metadatos que
un fichero puede albergar.

Los objetivos de este tema son:

 Conocer el funcionamiento general de un sistema de ficheros.

 Entender el mecanismo que utilizan los sistemas de ficheros para eliminar un
archivo.
 Saber por qué es posible recuperar un archivo y qué tipos de recuperaciones
existen.
 Por último, conocer la importancia de los metadatos a la hora de realizar el análisis
de un archivo.

Dispositivos de almacenamiento

Esta definición abarca un enorme conjunto de dispositivos, desde las históricas

tarjetas perforadas de cartulina, hasta los modernos discos SSD o Blu-ray.

Para facilitar la comprensión del temario, cuando nos refiramos a los dispositivos
de almacenamientos vamos a limitar tal definición a los dispositivos de
almacenamiento modernos como son los discos duros (magnéticos), sistemas de
almacenamiento basados en memorias tipo flash como los discos SSD,
las tarjetas de memoria o los pendrives y sistemas de almacenamientos
ópticos como los CD, DVD o Blu-ray.

Los dispositivos de almacenamiento tienen un tipo de estructura interna, desde el

punto de vista lógico, que es necesario conocer para comprender en profundidad
cómo se almacena la información en los mismos y cómo podemos recuperarla o
acceder a ella cuando parezca imposible.

Las particiones

Particionar un dispositivo de almacenamiento significa dividir lógicamente el

espacio disponible en secciones a las que se puede acceder de manera
independiente una de otra. El espacio disponible en un dispositivo de
almacenamiento se puede asignar a una única partición, o bien, se puede dividir el
mismo en varias particiones.

No hay ningún tipo de regla que indique cómo debe ser particionado un dispositivo
de almacenamiento, por lo que el esquema de particionado de un dispositivo suele
estar determinado por diversos motivos tales como la flexibilidad deseada,
velocidad, seguridad o las limitaciones propias del espacio disponible. Por norma
general, es una elección propia del usuario, salvo las particiones creadas por
defecto durante la instalación de un sistema operativo.

El esquema de particionado es almacenado en la tabla de particiones del

dispositivo de almacenamiento, para la cual, existen dos formatos hoy en
día: Master Boot Record (MBR) y GUID Partition Table (GPT).

El Master Boot Record comprende los primeros 512 bytes de un dispositivo de

almacenamiento y está reservado para el cargador del sistema operativo y la tabla
de particiones del mismo nombre.

El concepto de MBR nace en 1983 con el Sistema Operativo PC DOS 2.0 y sigue
vigente hasta nuestros días, aunque dada su antigüedad, las limitaciones de este
tipo de tabla de particiones se hacen cada vez más evidentes. Entre ellas, quizá la
más notoria sea la limitación del espacio de almacenamiento máximo
direccionable a 2TB.

El código del gestor de arranque típico, en el Master Boot Record de

Windows/DOS, comprueba la tabla de particiones para buscar la partición activa
que será a la que trasfiera el control para que inicie el sistema operativo.
El gestor de arranque de Windows/DOS no puede arrancar una partición Linux, ya
que no está diseñado para cargar un kernel de Linux, y solo puede atender a una
partición activa y primaria, limitaciones que no afectan a GRUB (Grand Unified
Bootloader), que es el código del gestor de arranque de facto para GNU/Linux.

Originalmente, MBR solo admitía hasta cuatro particiones. Más tarde, se

ampliaron al introducir particiones lógicas para superar esta limitación. Existen tres
tipos de particiones: primaria, extendida y lógica.

Las particiones primarias pueden ser todas configuradas como particiones de

arranque y están limitadas a cuatro por dispositivo de almacenamiento o volumen
RAID. Si un esquema de particionado necesita más de cuatro particiones, se crea
una partición extendida que sirve para contener particiones lógicas. Las
particiones extendidas están pensadas para contener particiones lógicas. Un disco
duro no puede contener más de una partición extendida. La partición extendida
también se cuenta como una partición primaria, por lo que, si el disco tiene una
partición extendida, solo son posibles tres particiones primarias adicionales. El
número de particiones lógicas que pueden residir en una partición extendida es
ilimitado.

En la tabla de particiones solo puede haber una partición extendida, la cual, en la

tabla de particiones se identifica porque en el campo donde se indica el ID del
Sistema de Ficheros de la partición tiene el valor 0x05 o 0x0F que la identifica
como partición extendida. El inicio de una partición extendida es exactamente una
tabla de particiones exactamente igual a la tabla de particiones del propio MBR.

De la lectura de la tabla de particiones de un MBR podemos obtener, por ejemplo,

particiones cuyo ID del Sistema de Ficheros no coincide con el Sistema de
Ficheros real de la partición, o cuyo ID sea incorrecto, provocando así que el
sistema operativo no pueda acceder a ellas, aunque contengan información.

En cuanto a GUID Partition Table (GPT), es un nuevo formato de particionado que

forma parte de la especificación Unified Extensible Firmware Interface (UEFI), que
hace uso de un identificador único global para los dispositivos y cuyo objetivo es
sustituir al sistema MBR.

Al contrario que MBR, en GPT no se hace uso de un código de arranque en

ensamblador, sino que el proceso de arranque se basa en las capacidades
proporcionadas por la UEFI para estos procesos. Aun así, suele ubicarse una
tabla de particiones MBR en el primer sector del dispositivo de almacenamiento
con propósitos de protectividad y compatibilidad con el viejo esquema BIOS PC, la
GPT propiamente dicha comienza con la cabecera de la tabla de particiones.
Aunque lo típico va a ser encontrar particiones en discos duros, también es posible
encontrar particiones creadas en tarjetas de memoria, pendrives o dispositivos de
almacenamiento similares.

Sistemas de ficheros

El sistema de ficheros permite que los programas que pretenden acceder a los

datos contenidos en un dispositivo no tengan que conocer la ubicación física de
dichos datos, siendo necesario únicamente conocer la ruta de los archivos a los
que se pretende acceder, dejando al sistema de ficheros la labor de traducción.

Cuando se formatea un dispositivo, lo que se hace, entre otras cosas, es implantar

un nuevo sistema de ficheros en dicho dispositivo; siendo los más comunes:
FAT32, NTFS, Ext3/4 y HFS+, aunque hay muchos más.

De manera muy simplificada, un sistema de ficheros lo podríamos interpretar como

el índice de un libro. En él aparecen todos los ficheros del dispositivo, su ubicación
y algunos datos más referentes al mismo (los cuales dependen del sistema de
ficheros utilizado). Este índice, nos proporciona un enlace a las páginas (los
archivos) del libro.

Cuando pretendemos acceder a un fichero concreto, lo que hace el sistema

operativo es ir al índice, buscar el archivo concreto al que se pretende acceder y
seguir el enlace que apunta al comienzo del mismo.

Un esquema simplificado del funcionamiento de un sistema de ficheros sería:

 Este esquema representa la parte que interesa de cara a la
asignatura de un sistema de ficheros. Para completar la información
sobre los mismos tenéis más artículos en el apartado «A fondo» del
tema.

En el esquema anterior vemos como en la tabla índice (que en función del sistema

de ficheros empleado contendrá más o menos información y se encontrará
estructurada de una forma u otra) mantiene la lista de archivos del dispositivo
(normalmente, los sistemas de ficheros tratan las carpetas como un archivo
«especial»). En esta tabla índice, el sistema de ficheros mantiene un enlace a
la primera parte de cada uno de los archivos, la cual a su vez enlaza con la
siguiente parte del archivo, hasta llegar al final del mismo.

Hay que tener en cuenta, que lo que denominamos como «índice», es

en realidad un conjunto de archivos especiales en los cuales el
sistema de ficheros mantiene dicha información.

Por ejemplo, para un sistema de ficheros FAT32, el conjunto de archivos que lo

componen es:

 Boot Sector.
 FAT1 y FAT 2 (copia de la FAT1).
 Root folder y entradas de directorio.

Para explicar cómo los sistemas de ficheros «borran» los archivos y cómo
posteriormente podemos recuperarlos, vamos a basarnos en un ejemplo.

Imaginad que tenemos un archivo de vídeo en alta definición que ocupa 2GB de
espacio en nuestro disco duro. Este archivo se encontrará dividido en distintas
partes a lo largo del dispositivo tal que así:
Cuando eliminamos dicho archivo, lo que estamos haciendo no es
eliminarlo físicamente del dispositivo, si no marcar dicho archivo como eliminado,
indicar que el espacio ocupado por el mismo está libre, borrar el enlace a la primera
parte del mismo, eliminar la definición del archivo del índice o varias de estas
opciones, todo ello en función del sistema de ficheros utilizado.
El índice quedaría de manera similar a esta:

Por ejemplo, en un sistema de ficheros FAT32, cuando se elimina un archivo lo que se

hace es indicar en la tabla FAT1, que los clústeres ocupados por dicho archivo se
encuentran ahora disponibles, pero si leemos los datos de la carpeta donde dicho
archivo se encontraba (o accedemos al root folder si se encontraba en el directorio
raíz), vemos que dicho archivo sigue existiendo.

Vamos a verlo mejor con un ejemplo (en el ejemplo vamos a trabajar sobre un
FAT16). Contenido de la tabla FAT1 antes de borrar el único archivo contenido en
el directorio raíz del dispositivo:
Las dos primeras entradas de la FAT (coloreadas en rojo) son utilizadas por el
propio sistema de archivos. La tercera entrada (correspondiente con el clúster 2 y
coloreada en verde) está marcada como utilizada y la cuarta entrada
(correspondiente con el clúster 3 y coloreada en naranja) también está marcada
como utilizada, siendo además el último clúster del archivo.

Contenido de la tabla FAT1 tras la eliminación del único archivo contenido en el

dispositivo:

Como vemos, la tercera y cuarta entrada (coloreadas en azul), que antes se

correspondían con los clúster utilizados por el archivo, se encuentran marcadas ahora
como disponibles.

Ahora vamos a ver el contenido del root folder antes de borrar el archivo.

Como vemos, indica que hay un archivo denominado «BALLOON», con extensión
«JPG» que ocupa 971bytes (en azul claro está coloreado CB03, que leyendo al
revés es 03CB = 971 en decimal) y que comienza en el clúster 2 (lo indica el valor
02 del offset 00040010A).

Ahora vamos a ver el contenido del root folder tras la eliminación del archivo.

Como vemos, el contenido es el mismo salvo por el primer registro (coloreado en

rojo) que ahora tiene el valor E5, eliminado. Es por ello, que si recuperáramos el
archivo lo recuperaríamos con el nombre «_ALLOON.JPG», ya que hemos
perdido el primer carácter del nombre.

El motivo por el cual no se elimina físicamente el archivo, es que este proceso

implicaría llenar de ceros (o cualquier otro valor irrelevante) la zona del dispositivo
donde se encontraba dicho archivo, lo que conllevaría mucho tiempo y
desgaste del propio dispositivo.

Ahora bien, tras el «borrado» de un archivo, el espacio que dicho archivo ocupaba pasa a
encontrarse como disponible. Por lo tanto, es posible que parte de dicho espacio
sea sobrescrito en operaciones de escritura posteriores quedando el fichero
inicial irrecuperable parcial o completamente.
En el dibujo anterior, la primera parte del archivo «video2.avi» ha sobrescrito la
segunda parte del archivo «video.avi», lo que ha provocado que se pierda el
enlace al resto de partes de dicho archivo. Por lo tanto, en este caso particular
solo se podría recuperar parcialmente el archivo «video.avi».

Ejemplo de una imagen en formato JPG recuperada parcialmente:

Imagen Original Recuperacion Parcial

Veamos con una tabla los posibles escenarios existentes tras la eliminación de un
archivo y la información que se podría recuperar en cada uno de ellos.

Información que se
Acción Resultado
puede recuperar

El archivo se mueve a Toda (el archivo

Eliminación la papelera de reciclaje eliminado y los datos
(o similares) asociados al mismo)

Eliminación y El archivo se marca Si se marca como

 eliminado, toda.
como borrado en la
Si se elimina el enlace
vaciado de la tabla de índice, se
o su definición en el
papelera (o elimina el enlace al
índice, solo el archivo,
similares) mismo o se elimina su
sin los datos
definición de la tabla
asociados al mismo

Eliminación, vaciado
Similar a borrar el
de la papelera (o Solo el archivo, sin los
enlace al archivo o
similares) y datos asociados al
eliminar su definición
sobrescritura del mismo
de la tabla
enlace del índice

En función de la
Eliminación, vaciado cantidad de
Las zonas físicas
de la papelera (o información
donde se encontraba el
similares) y sobrescrita, es posible
archivo han sido
sobrescritura de los recuperar una parte
sobrescritas
datos del archivo o no
recuperar nada

Salvo para los archivos enviados a la papelera de reciclaje (o similares), cuya

recuperación consiste en extraer dichos archivos de la papelera, que comúnmente
es un directorio («$Recycle.Bin\[SID del usuario]\», en el caso de Windows 7),
para el resto de escenarios es necesario el uso de programas de recuperación de
archivos.

Las firmas de los archivos

Hemos comentado que cuando eliminamos un archivo no se elimina físicamente,

si no que alteramos el índice para indicar que ese archivo ya no existe. Ahora
bien, ¿cómo recuperan estos archivos los programas de recuperación? La
respuesta está en las firmas de los archivos.

Prácticamente todos los archivos tienen una cabecera o firma que los identifica.

Esta firma se encuentra al principio del archivo y es independiente de

la extensión que dicho archivo tenga asignada. Una imagen con extensión .JPG
puede tener una cabecera de una imagen PNG, por lo que en realidad estaríamos
ante una imagen PNG.
Algunas de las firmas de los tipos de archivos más comunes son:

Firma Firma
Tipo de archivo
(Hexadecimal) (ASCII)

Ejecutable
4D 5A MZ
(*.EXE)

Comprimido
50 4B 03 04 PK...
(*.ZIP)

52 61 72 21 1A Comprimido
Rar!...
00 00 (*.RAR)

89 50 4E 47 0D Imagen
.PNG....
0A 1A 0A (*.PNG)

FF D8 FF Imagen
ÿØÿà/á/è
E0/E1/E8 (*.JPG)

D0 CF 11 E0 Documentos
ÐÏ.ࡱ.á
A1 B1 1A E1 MS Office
Para ver la firma de un archivo, solo tenemos que abrir dicho archivo con un editor
hexadecimal. La firma se encuentra (por norma general) al principio del mismo,
aunque la longitud de la misma suele variar.

Aquí vemos la firma de un archivo de imagen en formato JPG abierto con un editor
hexadecimal:

Los programas de recuperación de archivos trabajan de dos formas diferentes:

 La primera de ellas se utiliza cuando en el índice todavía existen referencias a

archivos que han sido borrados, aunque indique que dicho espacio está libre (es el
caso del ejemplo explicado anteriormente para FAT16). El programa de
recuperación de archivos, lee el índice, va a la posición donde este indica que se
encuentra el archivo y lo recupera.

 La otra manera, denominada recuperación en bruto, consiste en leer

los espacios del disco duro marcados como libres en el índice del sistema de
 ficheros y buscar en dichos espacios firmas de archivos conocidas, de manera que
cuando encuentre una de estas firmas, sabemos que lo que viene a continuación
es un archivo.

El problema que tiene este tipo de recuperación, es que no sabemos dónde

termina el archivo, a no ser que dicho tipo de archivo tenga también una firma de
fin de archivo (FF E9 en el caso de un archivo JPG).

Los metadatos de los archivos

Algunos ejemplos de metadatos que nos podemos encontrar son:

Como vemos, cada tipo de archivo tiene unos metadatos asociados distintos,

aunque algunos de ellos se compartan como pueden ser las fechas de creación y
modificación, el autor o una descripción del archivo.

Aunque prácticamente todos los tipos de archivos pueden contener metadatos, los

archivos en los que más fácilmente se encuentran son: los documentos ofimáticos
(hojas de cálculo, documentos de texto…), las fotografías, los archivos de vídeo y
audio y los mensajes de correo electrónico (las cabeceras del mensaje).

El análisis de los metadatos puede realizarse desde el propio sistema

operativo (en Windows basta con ver las propiedades del archivo), utilizando
programas de terceros (como Metadata Analyzer) o webs (como FOCA on-line,
que también tiene su versión off-line) que realizan el análisis de manera
automática.
Un ejemplo de la información que se puede obtener de los metadatos de un
documento y las implicaciones que dichos metadatos pueden acarrear lo
encontramos en un dossier sobre la seguridad en Iraq y organizaciones de
inteligencia publicado por el gobierno del Reino Unido.

En febrero de 2003, el gobierno del Reino Unido publicó un dossier sobre la

seguridad en Iraq y organizaciones de inteligencia. El documento se publicó en
formato DOC en la propia web del gobierno Británico y del análisis de los
metadatos que contenía se obtuvo:
 Que el documento había sufrido diez revisiones.

 Que justo antes de la utilización de dicho documento por parte de Colin Powell en
un discurso ante las Naciones Unidas, uno de los autores había copiado el informe
de su ordenador a un disquete para que Powell lo utilizara en la presentación.
 Se obtuvo información sobre los autores del mismo: «P. Hamill», «J. Pratt», «A.
Blackshaw» y «M. Khan». Pudiendo averiguar, a partir de sus nombres, cuál era
su cargo y lugar de trabajo. Además, se descubrió que gran parte dicho
documento había sido plagiado de los documentos de un investigador
estadounidense.

Todo esto puede sonar a película de acción, pero es real y demuestra

la información que los metadatos pueden proporcionarnos durante nuestra labor
de investigación.
Ejemplo de recuperación de un archivo
eliminado
Para aclarar los conocimientos adquiridos a lo largo de este tema, vamos a ver un
sencillo ejemplo de cómo un programa recupera de forma automática un archivo
eliminado.

Para ello, vamos a realizar paso a paso los procesos que el programa de
recuperación realiza de forma automática, sobre una imagen preparada para tal
propósito. En este caso, estamos trabajando sobre un Sistema de Ficheros FAT.

Por lo que, aunque el procedimiento sería similar en otros Sistemas de Ficheros,

no tiene por qué coincidir.

El primer paso consiste en leer el contenido del directorio raíz del dispositivo a
analizar. Obteniendo algo similar a lo que se observa en la siguiente imagen:

Como se observa, aparecen cuatro entradas, de las cuales, las tres últimas son
las que se corresponden con los archivos contenidos en el dispositivo, mientras
que la primera sería el nombre del volumen FAT (esto es así en FAT pero, como
ya hemos comentado al inicio, no tiene por qué serlo en otros sistemas de
ficheros).

En FAT, cada una de las entradas de esta carpeta raíz ocupa 32 bytes, los cuales
se distribuyen de la siguiente manera:

Root Folder
Size Description
Entry

11
Name Name in 8.3 format
bytes
 Attribute byte 1 byte Information about the entry.

Reserved 1 byte  

Creation time 5
Time and date file was created.
and date bytes

Last access 2
Date file was last accessed.
date bytes

2
Reserved  
bytes

Last
4 Time and date file was last
modification
bytes modified.
time and date

2 Starting cluster number in the

First cluster
bytes file allocation table.

4
File size Size of the file.
bytes

Para saber qué archivos han sido eliminados solo nos tenemos que fijar en que el
primer valor (hexadecimal) de su entrada:

Valor Significado

0x00 La entrada se encuentra sin usar.

El archivo al que hacer referencia la

0xE5
entrada ha sido eliminado.

El archivo al que hace referencia la

0x05 entrada, comienza por el carácter «_»,
en hexadecimal (0xE5).

Por lo tanto, de la lista de entradas del directorio raíz podemos ver que dos de las
tres entradas se encuentran eliminadas. Estas entradas se corresponden con los
archivos «?ORMIGA» y «?EADOW».

Siendo la información disponible sobre dichos archivos, la siguiente:

Como se observa, se pueden ver las fechas de creación, último acceso y
modificación. Además del clúster en el cual comienzan y el tamaño de los
archivos.
Una vez sabemos el clúster de inicio y el tamaño del archivo, es posible calcular el
clúster final mediante una sencilla operación matemática.

Por ejemplo, para el primero de los registros indicados, el archivo “_ORMIGA.JPG”

sabemos que empieza en el clúster número 2 y que su tamaño total es de 183.857
bytes. Si el tamaño del clúster es de 8 sectores y cada sector tiene un tamaño de
512bytes (toda esta información se encuentra en el sector de arranque de la
partición FAT) el número de clúster ocupados por el archivo sería:

183.857bytes / 512bytes = 359,09 → 360 sectores

360 sectores / 8 sectores por clúster = 45 clúster
Por lo tanto, el archivo ocupa desde el sector 2 al sector 46. En total, 45 clúster.