$MFTMirr es la póliza de seguros más pequeña de NTFS. Replica los primeros registros de $MFT para que, cuando los bytes al inicio de la tabla principal sean ilegibles, el driver del sistema de archivos siga teniendo una forma de encontrar cada archivo del volumen. También es el artefacto que la gente olvida adquirir y necesita tres semanas más tarde.
Esto es lo que realmente contiene, dónde se sitúa en el disco, cuándo lo usa NTFS y los (limitados) casos en los que se gana su lugar en forense.
Por qué existe un espejo en absoluto
Los primeros registros de $MFT son portantes. El registro 0 es la propia $MFT, con una runlist $DATA que dice dónde vive el resto de la tabla en el disco. El registro 2 es $LogFile. El registro 3 es $Volume. Si los bytes al inicio de $MFT están dañados, NTFS no puede encontrar ninguno de los demás archivos del volumen, incluido el log de transacciones que normalmente usaría para recuperar inconsistencias del sistema de archivos.
Esa es una dependencia circular: necesitas $MFT para encontrar $LogFile, pero necesitas $LogFile para arreglar $MFT. El espejo rompe el ciclo. $MFTMirr es un archivo separado en una ubicación física distinta que contiene un duplicado de esos primeros registros. Cuando el driver monta un volumen, lee el registro 0 de $MFT; si esa lectura falla o el array de fixup no verifica, recurre al registro 0 de $MFTMirr y usa el duplicado para reubicar el resto.
Dónde vive
$MFTMirr es el registro 1 de la MFT. Su atributo $DATA es no residente, y su runlist tradicionalmente apunta al medio del volumen para que un único fallo localizado (un sector defectuoso, una escritura desgarrada en una región) no pueda eliminar ambas copias. El NTFS moderno lo coloca en LCN clusterCount / 2. En un volumen de 500 GB eso pone el espejo alrededor de la marca de 250 GB.
Puedes encontrarlo desde un sistema vivo:
fsutil file queryextents C:\$MFTMirr
Eso devuelve los cluster runs que ocupa $MFTMirr, que una lectura cruda puede reensamblar. El target MFT de KAPE lo recolecta junto a $MFT por defecto. Si usas FTK Imager, se sienta junto a $MFT en la raíz del volumen NTFS.
Qué contiene
Copias byte por byte de los primeros registros MFT. La garantía histórica era los primeros cuatro registros (0 a 3, los metadatos verdaderamente esenciales). Las versiones actuales de Windows replican los primeros dieciséis, que es el conjunto completo de metadatos NTFS descrito en la referencia de la master file table.
Cada copia es un registro MFT normal. Misma firma FILE, misma cabecera, mismo array de fixup, mismo flujo de atributos. Un parser apuntado a $MFTMirr lo recorre exactamente igual que recorre $MFT. MFTECmd, mft_dump, analyzeMFT y fls del Sleuth Kit lo aceptan como entrada.
Cómo lo usa NTFS al montar
En un montaje sano, el driver no toca $MFTMirr. En un montaje dañado:
- Leer el registro 0 de
$MFT. - Si la lectura devuelve un error de I/O, o la verificación de fixup falla, leer el registro 0 de
$MFTMirren su lugar. - Si la copia del espejo del registro 0 es válida, usar su runlist
$DATApara localizar$MFTen el disco y continuar.
El espejo no tiene que reemplazar a $MFT. Solo tiene que proporcionar suficiente información para encontrar la real. Una vez que el driver ha localizado $MFT desde el puntero del espejo, procede con la tabla viva.
Cómo lo usa chkdsk
chkdsk es más agresivo. Cuando detecta corrupción en los primeros registros de $MFT, cruza cada registro contra el espejo. Si ambas copias son válidas pero difieren, chkdsk trata al espejo como autoritativo para los primeros pocos registros críticos (asumiendo que los registros vivos se actualizaron más recientemente y se corrompieron en el proceso).
Si $MFT es ilegible y el espejo es ilegible, chkdsk informa Windows no puede recuperar la master file table. CHKDSK abortado. En ese punto la recuperación requiere herramientas offline: carving de firma por registros FILE a través del volumen crudo con Sleuth Kit, R-Studio o testdisk. La autorreparación integrada de NTFS está agotada.
Por qué $MFTMirr no es una copia completa
Solo replica los archivos de metadatos. Los registros 16 y posteriores, que son todo archivo y directorio de usuario, existen solo en $MFT. Si $MFT está dañada más allá del registro 16, el espejo no puede ayudarte. El espejo es suficiente para montar el volumen; recuperar archivos arbitrarios desde el daño requiere las mismas técnicas que usarías sin él.
Esta es la idea equivocada que cuesta tiempo a la gente en compromisos de IR. Acuden a $MFTMirr pensando que es una instantánea histórica completa. No lo es. Para eso quieres las Volume Shadow Copies, cada una de las cuales contiene una copia real a un instante dado de la $MFT completa.
Interés forense
$MFTMirr rara vez es el artefacto primario en un caso, pero tiene dos usos reales:
- Cotejo. Los registros 0 a 15 en el espejo deben coincidir con los registros vivos bit a bit. Una divergencia sugiere que un lado fue modificado fuera de banda: un bug de driver, manipulación deliberada, recuperación parcial tras un crash, o un wiper mal escrito que garabateó en la MFT viva y se saltó el espejo. He visto exactamente un caso en el que el espejo pilló a un wiper que sobrescribió los primeros 16 registros de
$MFTy no se dio cuenta de que vivía una copia en otra parte del volumen. La reconstrucción funcionó porque el espejo estaba intacto. - Instantánea pre-corrupción. Si los registros vivos de
$MFTse han modificado pero el espejo aún no se ha vaciado a disco (NTFS los mantiene en sincronía pero hay una pequeña ventana), el espejo conserva el estado anterior. Esta ventana es corta, milisegundos en operación normal, pero en un caso de fallo súbito puede ser la única copia limpia.
Más allá de esos casos, trata $MFTMirr como algo que recolectas rutinariamente (KAPE lo hace por ti) y rara vez necesitas mirar.
Preguntas frecuentes
¿Es $MFTMirr lo mismo que una copia de la MFT completa?
No. Contiene solo los primeros pocos registros (los archivos de metadatos del sistema). Los archivos de usuario no se replican.
¿Puedo parsear $MFTMirr con las mismas herramientas que $MFT?
Sí. Es estructuralmente idéntico: mismo formato de registro, mismo array de fixup, mismos atributos. Suéltalo en el parser en navegador o aliméntalo a MFTECmd.
¿Puedo borrar o mover $MFTMirr?
No. Como $MFT, está bloqueado mientras Windows está en funcionamiento. Desactivar el espejo por completo no es una operación soportada; chkdsk rechazaría el volumen.
¿Qué pasa si mi disco no tiene $MFTMirr?
Lo tiene. Todo volumen NTFS tiene uno, creado en el momento del formateo. Si $MFTMirr falta o es ilegible, el volumen está gravemente dañado y chkdsk fallará.
Lecturas adicionales
- Microsoft, NTFS Reserved Files. Catálogo oficial de los archivos de metadatos de los primeros 16 registros.
- Notas sobre $MFTMirr del proyecto linux-ntfs. Escrito práctico del papel del espejo desde la perspectiva de un implementador de parsers.
- Brian Carrier, File System Forensic Analysis. El capítulo sobre archivos de metadatos NTFS explica la ruta de recuperación al montar.