Metadatos NTFS tras un formateo rápido: un análisis con WinHex
Los metadatos NTFS tras un formateo rápido describen un sistema de archivos recién inicializado, aunque algunos registros y contenidos de archivos del sistema de archivos anterior pueden seguir siendo legibles en el fondo. Windows crea una nueva tabla maestra de archivos y una nueva estructura de directorios; no se limita simplemente a ocultar todos los nombres de archivo antiguos. La recuperación se lleva a cabo con éxito cuando se conservan y siguen siendo accesibles suficientes metadatos originales y los datos que estos describen.
WinHex ayuda a distinguir estas situaciones al mostrar los campos del sector de arranque, los registros de la MFT y las asignaciones de bloques de datos. Este artículo analiza un caso de formateo rápido de NTFS a NTFS y un ejemplo independiente de reconstrucción de fragmentos de la MFT. Los cálculos se aplican a las estructuras registradas, y no a todos los volúmenes de Windows. El comportamiento de descarte de los SSD y las escrituras posteriores pueden dar lugar a resultados muy diferentes.
Índice
1. ¿Qué cambia con el formateo rápido en NTFS?
En Sistema de archivos NTFS Organiza los archivos mediante metadatos, índices de directorios y asignaciones de clústeres. Un formateo rápido crea una nueva instancia de estas estructuras.
Estructura | Función tras un formateo rápido | Consecuencias para la recuperación |
El sector de arranque del volumen y su copia de seguridad | Describe el volumen recién formateado | Es posible que los punteros MFT actuales ya no puedan localizar la tabla antigua |
$MFT y el directorio raíz | Describe el nuevo sistema de archivos y sus objetos iniciales. | Los antiguos nombres de archivos y las relaciones entre directorios desaparecen durante la navegación habitual |
| Realiza un seguimiento de los registros asignados en la nueva MFT | No recoge los registros conservados que no figuran en esa tabla |
$Bitmap | Realiza un seguimiento de los clústeres asignados en el nuevo volumen | Los grupos que estaban ocupados anteriormente pueden quedar disponibles para su reutilización |
$MFTMirr y otros metadatos del sistema | Admite el sistema de archivos recién inicializado | Sus operaciones de escritura pueden sobrescribir metadatos o contenidos de archivos anteriores |
Ubicaciones anteriores de los datos de los archivos | Puede conservar contenido legible fuera de los rangos sobrescritos o descartados | No hay que dar por sentada la supervivencia, sino que hay que comprobarla. |
En Tabla de archivos maestros es en sí mismo un archivo. Su flujo $DATA, sin nombre, contiene registros de archivos; su mapa de bits describe la asignación de registros. El archivo independiente $Bitmap describe la asignación de clústeres en todo el volumen. Confundir estos dos mapas de bits lleva a conclusiones erróneas sobre lo que se ha conservado.
El formateo de una partición existente también difiere de la eliminación de su entrada en la tabla de particiones. Un formateo de volumen reconstruye el sistema de archivos dentro del volumen seleccionado; la eliminación de la partición afecta a la estructura del disco fuera de él.
2. Leer el sector de arranque original en WinHex
Para realizar una comparación hexadecimal «antes y después» de un formateo NTFS, guarda una imagen del sector antes del formateo y compárala con una imagen capturada después. En un soporte ya formateado, trabaja a partir de una imagen y de cualquier captura anterior de la que dispongas. No repitas el formateo para reproducir el suceso.
En registro de arranque del volumen proporciona los parámetros necesarios para interpretar las direcciones de los clústeres.
Fragmento hexadecimal original del sector de arranque extraído del expediente de WinHex. Los recuadros rojos identifican los campos de tamaño del sector, tamaño del clúster y ubicación de la MFT.
Desplazamiento del sector de arranque | Bytes registrados | Interpretación |
|
| 512 bytes por sector lógico |
|
| Ocho sectores por grupo |
|
| $MFT comienza en el LCN 175.724.968 |
|
| $MFTMirr comienza en el LCN 167.336.228 |
|
| Valor con signo −10: el tamaño del registro es 2¹⁰ = 1.024 bytes |
Los enteros multibyte utilizan el orden de bytes «little-endian». El tamaño de la unidad de asignación por lo tanto, es:
- 512 × 8 = 4.096 bytes por clúster
LCN hace referencia a un número de clúster relativo al volumen. Por lo tanto:
- Sector relativo al volumen MFT original = 175 724 968 × 8
- = 1,405,799,744
- Desplazamiento en bytes relativo al volumen del MFT original = 175 724 968 × 4 096
- = 719,769,468,928
Al examinar una imagen de disco completo, añade el desplazamiento en bytes inicial del volumen. Al examinar una imagen que solo contiene un volumen, no lo añadas de nuevo. El contexto de direccionamiento que muestra WinHex debe coincidir con el cálculo.
El sector de arranque identifica la primera extensión de la MFT. No describe todos y cada uno de los fragmentos de la tabla.
3. Descifrar los datos de no residentes de la MFT original
En la ubicación original del MFT, valida el registro 0 y localiza su atributo sin nombre $DATA; escribe 0x80. Un atributo no residente almacena información de asignación en lugar de todo su contenido dentro del registro.
Las notas del caso sitúan este atributo en el desplazamiento del registro 0x100. Eso hace que su byte de forma aparezca en 0x108; el valor 01 significa «no residente». Estas compensaciones absolutas pertenecen a este registro. Otros registros pueden ubicar el atributo en otro lugar.
Al interpretar otro registro, utiliza desplazamientos relativos al inicio del atributo:
Desplazamiento relativo | Campo |
| Formulario para residentes y no residentes |
| Número de clúster virtual más bajo, o VCN |
| VCN más alto, incluido |
| Desplazamiento respecto a la matriz de pares de correspondencias |
| Longitud asignada |
| Tamaño lógico del archivo |
| Longitud válida de los datos |
Lee los tres campos de tamaño por separado. La longitud asignada reserva espacio de almacenamiento, el tamaño lógico define la longitud del flujo y la longitud de datos válidos describe los datos inicializados. No es necesario que sean iguales.
Para un intervalo que abarca los VCN del 0 al 98.431, el número de clústeres es 98.432, y no 98.431. La disposición de dos pasadas registrada da como resultado:
Ejecutar | Recuento de clústeres | Firmado: LCN delta | Inicio de LCN | Espacios para registros lógicos de 1.024 bytes cada uno |
1 | 75,096 | +175,724,968 | 175,724,968 | 0–300,383 |
2 | 23,336 | +83,118,309 | 258,843,277 | 300,384–393,727 |
La segunda dirección es relativa a la ejecución anterior: comenzando LCN:
- 175,724,968 + 83,118,309 = 258,843,277
- (75 096 + 23 336) × 4 096 = 403 177 472 bytes
- 403 177 472 ÷ 1 024 = 393 728 espacios para registros
Se trata de ranuras direccionables, no de un recuento de archivos activos. Es posible que algunos registros no se utilicen, y un archivo puede requerir varios registros.
Los encabezados de las ejecuciones registradas 43 y 42 describir las anchuras de los campos. Para 43, la longitud ocupa tres bytes y el delta del LCN, cuatro; para 42, la longitud ocupa dos bytes y el delta, cuatro. El delta del LCN debe interpretarse como un valor con signo, ya que los fragmentos posteriores pueden encontrarse en una posición anterior dentro del volumen.
La longitud resultante de la extensión es de 384,5 MiB. El valor redondeado que se muestra, “385 MB”, no permite determinar por sí solo un tamaño de asignación diferente ni demostrar que se reservaran clústeres adicionales.
4. Comparar el nuevo MFT con el diseño anterior
Las notas del caso registran una tabla MFT posterior al formateo que comienza en LCN 786.432, con una extensión de 180 clústeres. Suponiendo que el tamaño de clúster registrado sea de 4.096 bytes:
- Nuevo desplazamiento del byte inicial del MFT = 786.432 × 4.096
- = 3,221,225,472
- Nuevo tamaño del extenso = 180 × 4.096 = 737.280 bytes
El nuevo punto de inicio se encuentra a 3 GiB dentro del volumen. Esa dirección es una observación derivada de este caso concreto, no una ubicación obligatoria en el sistema de archivos NTFS.
Propiedad | Diseño original | Diseño del formato de la publicación registrado en las notas |
Inicio de MFT LCN | 175,724,968 | 786,432 |
Extensiones MFT registradas | Dos | Uno |
Ámbito de cobertura | 98 432 grupos | 180 grupos |
Capacidad con el tamaño de registro registrado | 393 728 tragaperras | 720 tragaperras |
Las notas también mencionan los registros 0-717. Eso supone 718 registros, es decir, 735 232 bytes. Es compatible con una asignación lo suficientemente grande como para 720 ranuras, pero no aclara si el número 718 se refiere a la longitud lógica, a la longitud inicializada o al número de registros inspeccionados. Esos campos requieren los bytes de atributos subyacentes.
El cambio importante es que Windows ahora sigue la nueva tabla. El menor tamaño de la nueva MFT hace que no significa que la antigua tabla se truncó físicamente in situ. Es necesario inspeccionar por separado sus antiguas ubicaciones.
Para determinar si la MFT de NTFS se ha sobrescrito al formatear, compara los extents originales de la MFT con todas las nuevas escrituras de metadatos y las asignaciones posteriores. Un puntero modificado demuestra que la referencia ha cambiado; una comparación de bytes confirma la sobrescritura en una ubicación concreta. La reubicación por sí sola no demuestra ni la conservación completa ni la pérdida total.
5. Reconstruir una tabla MFT fragmentada a partir de los registros conservados
La fragmentación de la MFT se produce a medida que la tabla crece y deja de haber espacio contiguo disponible. NTFS reserva una zona de la MFT para reducir la fragmentación, pero esto no garantiza que se forme un único extenso. El crecimiento puede asignar fragmentos antes o después del extenso actual.
Un ejemplo de reconstrucción independiente en el material del caso ilustra esta disposición de tres series. No debe combinarse con el caso anterior de dos series como si ambos describieran la misma tabla.
Ejecutar | Espacios para registros lógicos | Inicio de LCN | Diferencia respecto al inicio de la ejecución anterior | Clústeres |
1 | 0–204,927 | 786,432 | +786,432 | 51,232 |
2 | 204,928–248,587 | 9,274,281 | +8,487,849 | 10,915 |
3 | 248,588–376,391 | 8,858,108 | −416 173 | 31,951 |
En cada clúster de 4.096 bytes caben cuatro ranuras de 1.024 bytes. Esto explica ambos límites:
- 51 232 × 4 = 204 928 ranuras
- 204 928 + (10 915 × 4) = 248 588
- 9 274 281 − 416 173 = 8 858 108
En conjunto, las ejecuciones abarcan 94 098 clústeres, lo que equivale a 385 425 408 bytes. El VCN final es 94 097.
Localizar y validar los registros de los candidatos
Las notas de reconstrucción describen la búsqueda del registro 204.928, el rechazo de un candidato por no ser válido y la localización de otro candidato que se aceptó como válido. Un número coincidente o el ARCHIVO La firma por sí sola no es suficiente.
En una imagen de solo lectura:
- Buscar
ARCHIVOfirmas, incluidas las ubicadas fuera de la MFT actual. Un escaneo limitado a la nueva tabla no detectará los registros desprendidos. - Comprueba los límites de los registros, la longitud de los registros, los desplazamientos de los atributos y la longitud de los atributos.
- Comprueba la matriz de secuencia de actualización antes de interpretar los bytes del registro protegido. En los registros grabados de 1.024 bytes, sus comprobaciones abarcan los extremos de los dos tramos de 512 bytes.
- Recupera las palabras del tráiler guardadas en la memoria del analizador antes de analizar los atributos que traspasan esos límites; no modifiques la imagen de prueba.
- Compara los registros adyacentes, la numeración de los registros (si la hay), los nombres, las referencias a los registros principales y los números de secuencia. Descarta las relaciones poco plausibles o obsoletas.
Cuando un registro antiguo conservado 0 proporcione una lista de ejecución válida, utilícese esa correspondencia. Si falta, la reconstrucción de los extensos a partir de secuencias de registros sigue siendo una hipótesis que requiere comprobaciones adicionales. Los registros en blanco de una región no demuestran por sí solos que no exista ningún fragmento posterior.
Vuelve a montar la mesa lógica por separado
Copia los extents validados en un archivo de análisis independiente, siguiendo el orden VCN. No los ordenes por LCN ascendente: la tercera ejecución mencionada anteriormente se encuentra antes que la segunda en el disco, pero la sigue lógicamente.
Para el número de registro n, tamaño del registro R, y el tamaño del clúster C:
- VCN = floor(n × R ÷ C)
- Desplazamiento dentro del clúster = (n × R) mod C
- LCN = LCN inicial de la serie + (VCN − VCN inicial de la serie)
Para el registro 204.929 del ejemplo de tres ejecuciones, el VCN es 51.232 y su desplazamiento dentro del clúster es de 1.024 bytes. Por lo tanto, su dirección relativa al volumen es:
- 9 274 281 × 4 096 + 1 024 = 37 987 456 000 bytes
Esta asignación recupera una dirección, no un archivo. El registro y los datos a los que hace referencia aún deben validarse.
6. Recuperar el contenido de los archivos mediante los atributos antiguos
Una vez que se ha identificado un registro de archivo conservado, su atributo $DATA determina el método de extracción.
Datos de los residentes: Lee el desplazamiento y la longitud del valor del atributo y, a continuación, exporta ese valor desde el registro validado y restaurado tras la corrección. Los archivos pequeños pueden perder su contenido cuando se sobrescriben sus registros MFT, ya que dicho contenido se encuentra almacenado allí.
Datos generales sobre los no residentes: decodificar la lista de secuencias del propio archivo, leer cada extensión de la imagen del volumen original, ordenar los bytes según el orden VCN y recortar el resultado al tamaño del archivo lógico. La lista de secuencias de la MFT localiza los registros de los archivos; no sustituye a la asignación de datos de los archivos de cada usuario.
Sigue las referencias de $ATTRIBUTE_LIST cuando los atributos se extiendan a otros registros. Los flujos dispersos y comprimidos requieren sus respectivas reglas de decodificación. El contenido cifrado sigue requiriendo el material de descifrado correspondiente. La simple concatenación no es suficiente en estos casos.
La recuperación de directorios requiere un cuidado especial. Un nombre de archivo puede conservarse aunque su directorio principal ya no exista. Reconstruye las rutas únicamente cuando las referencias y los números de secuencia coincidan; en caso contrario, mantén el archivo huérfano en lugar de inventar una relación con una carpeta.
Guarda los archivos extraídos en otro dispositivo físico. Editar el nuevo sector de arranque para que apunte a una MFT antigua no equivale a recuperar los archivos: los mapas de asignación, los índices, los registros del sistema y otros metadatos pueden pertenecer a diferentes instancias del sistema de archivos.
7. Por qué la recuperación puede funcionar… y por qué puede fracasar
La recuperación basada en metadatos puede tener éxito porque un registro antiguo conserva la identidad del archivo, su tamaño lógico y las asignaciones de datos, mientras que el contenido asignado sigue siendo legible. Una herramienta de recuperación puede seguir esas relaciones aunque Windows ya no las incluya en su espacio de nombres activo.
Si faltan registros, el «carving» basado en firmas puede, en ocasiones, identificar directamente el contenido de los archivos. Por lo general, se pierden los nombres de archivo originales y la estructura de directorios, y resulta menos fiable en el caso de archivos fragmentados. X-Ways documenta la búsqueda de registros NTFS fuera de la MFT actual de forma independiente de las búsquedas en las cabeceras de los archivos, lo que refleja estos diferentes métodos de recuperación.
La recuperación se complica cuando los nuevos metadatos se superponen a los registros originales, los archivos posteriores reutilizan clústeres antiguos o faltan las asignaciones de fragmentación. Un nombre de archivo válido no garantiza que el contenido esté intacto; una primera página reconocible o un encabezado de vídeo reconocible no garantizan que los fragmentos posteriores se hayan conservado.
Los SSD añaden otra condición. El formateo de Windows puede enviar notificaciones TRIM o de eliminación; Microsoft… formato La documentación incluye /NoTrim para eliminarlos. Se trata de una opción de formateo, no de una solución tras la pérdida de datos. Dependiendo del dispositivo y de la ruta de almacenamiento, los rangos descartados pueden dejar de devolver los bytes originales incluso sin que se observe una sobrescritura convencional en WinHex. Por lo tanto, el formateo rápido no garantiza de forma universal la posibilidad de recuperación.
8. Comprueba los datos extraídos antes de volver a utilizar el disco
Conserva la imagen original y el mapa de extensión hasta que finalice la validación. Para conocer un flujo de trabajo práctico de digitalización y exportación, consulta Recuperación de archivos de un disco duro formateado.
Compara los archivos recuperados con un inventario previo al formateo, siempre que esté disponible. Compara los nombres, los tamaños, las relaciones entre carpetas y los hash con los originales conocidos. Si no se dispone de hash de referencia, abre los documentos e inspecciona sus páginas, comprueba los archivos comprimidos, visualiza las imágenes a resolución completa y reproduce los archivos de vídeo íntegros.
Registra los archivos dañados o perdidos por separado de los archivos verificados. Una MFT reconstruida sin errores de análisis establece metadatos legibles; los contenidos exportados que se pueden utilizar permiten la recuperación de los archivos. Para una recuperación completa es necesario tener en cuenta el conjunto de datos esperado.
Preguntas frecuentes
¿El formateo rápido sobrescribe toda la tabla MFT de NTFS?
¿Pueden los archivos seguir existiendo cuando sus registros de la MFT han desaparecido?
¿Puede la copia de seguridad de MFT recuperar todos los registros de archivos?
¿Un bit a cero en el mapa de bits del nuevo volumen significa que los datos antiguos se han borrado?
¿Puede un registro MFT antiguo seguir teniendo activado el indicador de uso?
¿Al restaurar el antiguo sector de arranque se anulará el formateo?
