Prueba de la MFT de archivos eliminados en NTFS: ¿qué cambia tras la eliminación?
En Prueba de la MFT de un archivo eliminado en NTFS necesita comparar algo más que el nombre de un archivo. Una vez completada la eliminación definitiva, NTFS puede liberar el registro del archivo, eliminar su entrada activa del directorio y liberar sus clústeres de datos no residentes. Sin embargo, esos cambios no borran necesariamente el contenido anterior. Este experimento compara un pequeño archivo TXT residente con un JPG no residente mediante la eliminación y la reutilización del registro, y a continuación examina una sobrescritura definida de los datos externos del JPG. La comparación aborda tres cuestiones: ¿se conserva el nombre?, ¿se conserva su asignación? y ¿siguen coincidiendo los bytes originales?
Índice
Qué evalúa este examen de prueba sobre la MFT de archivos eliminados en NTFS
La cuestión fundamental es si un registro MFT eliminado puede seguir describiendo un archivo completo. La respuesta depende tanto de los metadatos como del contenido. Un nombre que se haya conservado puede identificar un archivo antiguo, mientras que una lista de ejecución que se haya conservado puede localizar los antiguos clústeres de un flujo no residente. Ninguno de los dos elementos garantiza que esos clústeres sigan conteniendo los datos originales.
A modo de contexto, el Tabla de archivos maestros En esta guía se explica cómo los registros relacionan nombres, atributos y ubicaciones de almacenamiento. En este caso, nos centramos en el cambio entre los estados definidos.
Este experimento utiliza muestras generadas de la estructura NTFS, comparaciones de bytes calculadas y transiciones del estado de asignación definidas explícitamente. Las capturas de pantalla muestran los registros generados abiertos en wxHexEditor, con selecciones coincidentes de antes y después: los indicadores del registro JPG y los bytes de contenido residente del TXT. El modelo simula la eliminación completa de un archivo de enlace único, con todos los identificadores cerrados, en lugar de un traslado a la Papelera de reciclaje.
Configuración y supuestos de la prueba de la MFT de NTFS
Esta prueba de la MFT de archivos eliminados en NTFS utiliza un volumen lógico NTFS 3.1 sin cifrar. Utiliza sectores lógicos de 512 bytes, clústeres de 4.096 bytes y registros MFT de 1.024 bytes. Su partición comienza en la dirección LBA 2.048 del disco. Se trata de valores seleccionados, y no de las especificaciones del dispositivo.
El objetivo, mft-lab-file.jpg, ocupa el puesto número 42, un récord. Su anónimo y no residente $DATA El flujo contiene exactamente 10 240 bytes. Una secuencia contigua abarca tres clústeres, comenzando en el clúster lógico número 8192. Por consiguiente, la asignación es de 12 288 bytes, con 2 048 bytes más allá del final lógico del archivo. El tamaño de la unidad de asignación En esta guía se explica la diferencia entre «tamaño» y «asignación».
Ambos objetivos tienen un enlace físico y sin compresión NTFS, asignación dispersa, flujos de datos alternativos ni registros de extensión. El archivo JPG es un archivo JPEG válido generado de 160 × 120 con un patrón de píxeles determinista y un segmento de comentarios JPEG que establece su longitud en 10 240 bytes. Se decodificó para comprobar el formato de la muestra. El registro 42 comienza con el número de secuencia 42.
El segundo objetivo, resident-note.txt, contiene exactamente 64 bytes de texto ASCII en el registro 43, inicialmente en la secuencia 7. Su $DATA El valor no necesita grupos de datos independientes. En ambos ejemplos, el encabezado de atributo determina la forma de almacenamiento: a .txt La extensión por sí sola no garantiza los datos de los residentes, y el .jpg La prórroga por sí sola no determina la condición de no residente.
En cada comparación de eliminación inmediata, el modelo conserva la carga útil y los atributos anteriores. Los escenarios posteriores modifican la ranura del registro o, en el caso del archivo JPG, un clúster de datos externo. De este modo se aíslan sus efectos sin suponer una secuencia concreta de lectura del SSD ni de escritura de Windows.
Procedimiento de prueba de la MFT para archivos eliminados en NTFS
Los escenarios 1 a 4 siguen el formato JPG para no residentes. Los escenarios S3 y S4 se ramifican de forma independiente del S2. Los escenarios S5 a S7 forman un control TXT para residentes independiente; en esos estados se utiliza el registro 43 en lugar del 42.
JPG no residente: Estados de prueba de la MFT de NTFS
S1 — Referencia JPG.
Crea el registro 42 con su nombre, la asignación de datos de no residentes y el indicador de uso activado. Establece los bits correspondientes de asignación de registros y clústeres. Genera el contenido completo y calcula su resumen SHA-256.
S2 — Eliminación de archivos JPG completada.
A partir de S1, elimina el nombre original de la pertenencia a Active Directory, borra el bit de «en uso» del registro, reduce su recuento de enlaces a cero e incrementa su número de secuencia. Borra los bits correspondientes del registro y del mapa de bits del clúster. Conserva el nombre de archivo antiguo, el atributo de datos y la carga útil según el caso definido de «metadatos retenidos».
S3 — Se ha reutilizado la ranura de registro JPG.
A partir de S2, sustituye el registro 42 por los atributos de nuevo-propietario.txt, un pequeño archivo residente. Vuelve a establecer el bit de asignación de registros. Deja los tres clústeres de datos anteriores sin modificar y libres. Comprueba si el registro actual sigue proporcionando la asignación original.
S4 — Se ha sobrescrito el clúster central de JPG.
Vuelve por separado a S2. Asigna el LCN 8193 a otro archivo y sustituye cada byte de ese clúster por su inverso bit a bit (FF XOR original). Esta sustitución definida cambia cada byte del rango. Mantén sin cambios el antiguo registro de destino liberado. Compara el flujo resultante de 10 240 bytes con el original.
TXT residente: Estados de prueba de la MFT de NTFS
S5 — Referencia de TXT de residentes.
Crear el registro 43 para resident-note.txt con 64 bytes en su memoria residente $DATA atributo. Establece el bit de asignación de registros y registra la ubicación y el resumen del valor. Su flujo de datos no tiene asignación de clústeres externos.
S6 — Eliminación completa del TXT residente.
A partir de S5, elimina el nombre de archivo activo, borra los bits de «en uso» y de «asignación» del registro, establece los enlaces a cero e incrementa la secuencia de 7 a 8. Conserva los bytes de contenido residente. No hay bits de clúster de carga útil independientes que deban borrarse para esta secuencia.
S7 — Se ha reutilizado el registro TXT residente.
A partir de S6, reutiliza el registro 43 para replacement1.txt. Coloca 64 caracteres de tilde en el mismo rango de valores residentes. Compara ese rango con el texto original para determinar si la carga útil original se mantiene tras esta sustitución.
Comparar contenidos tras su eliminación y reutilización
Evalúa el contenido por separado. En el caso del archivo JPG, descodifica la asignación conservada, lee los rangos externos en el orden del archivo y detente en los 10.240 bytes. En el caso del archivo TXT, lee el valor de 64 bytes que contiene su registro. Compara los bytes completos y el resumen; excluye el espacio libre del clúster y no utilices el nombre del archivo como comprobación de integridad.
Estas transformaciones se aplican a las estructuras generadas de un solo uso. Para un seguimiento basado en dispositivos, utiliza soportes de prueba desechables y verifica la identidad del objetivo antes de borrar nada. Conserva la fuente afectada cuando investigues una pérdida real de datos.
Comparación hexadecimal de la eliminación de archivos NTFS
En la sección de capturas de pantalla emparejadas que aparece a continuación, compara cada archivo con su propio estado anterior. El campo de encabezado en +0x16 es la palabra de indicadores de dos bytes. Su bit menos significativo cambia de «asignado» a «libre». Los campos «secuencia» y «enlace» adyacentes proporcionan contexto adicional. El h El sufijo identifica los desplazamientos de fila en hexadecimal; las capturas de pantalla en formato JPG seleccionan +0x16–+0x17; en cambio, las capturas de pantalla de TXT seleccionan el contenido residente para compararlo.
Campos de la MFT de los archivos eliminados: ¿qué ha cambiado?
El cambio de indicador libera el registro; no indica al analizador que sustituya los datos del archivo por ceros. El cambio de secuencia también es importante: una referencia antigua que identifica el registro 42 con la secuencia 42 queda ahora obsoleta. Documentación de Microsoft el incremento de la secuencia cuando se libera un segmento de registro de archivo.
Los dos cambios en el mapa de bits describen asignación de registros y clústeres. $MFT::$BITMAP registra la asignación de registros. En este ejemplo, el registro 42 corresponde al bit 2 del byte +0x05. El volumen… $Bitmap::$DATA realiza un seguimiento de la asignación de clústeres. Los clústeres 8192–8194 corresponden a los bits 0–2 del byte +0x0400.
Al borrar esos bits, se liberan recursos para su reutilización. Esto no garantiza que una lectura posterior devuelva el contenido original. Además, la eliminación del nombre original del índice de Active Directory es independiente de la retención de $FILE_NAME atributo dentro del registro liberado. Las actualizaciones del árbol de directorios pueden desplazar o sobrescribir entradas del índice, por lo que los restos de índices requieren una interpretación propia.
¿Cómo localiza el MFT un archivo eliminado?
En S1 y S2, el atributo de datos «no residente» comienza en el registro +0x118. Su desplazamiento de los pares de correspondencias es 0x40, colocando la lista de ejecución en el registro +0x158. Los bytes describen una secuencia de tres clústeres que comienza en el LCN 8192. La comparación interactiva que aparece a continuación conserva los valores hexadecimales reales y permite a los lectores examinar estos campos.
Los LCN son relativos al volumen. Por lo tanto, el primer grupo de datos comienza en el desplazamiento de bytes del volumen 0x02000000. Al sumar el desplazamiento de la partición elegida, se obtiene el desplazamiento en bytes del disco 0x02100000, o el LBA 67584 del disco. Si se confunden estas bases, el lector de recuperación inspeccionaría una ubicación errónea.
TXT para residentes frente a JPG para no residentes: la misma eliminación, un almacenamiento diferente
Compara los dos archivos en la misma fase: S5 frente a S1 antes de la eliminación, S6 frente a S2 después de la eliminación y S7 frente a S3 tras la reutilización del registro. El archivo TXT ocupa el registro 43; el JPG, el registro 42. Los diferentes nombres de archivo, números de registro y valores de secuencia iniciales identifican objetos distintos, en lugar de indicar cambios debidos a la eliminación.
Escenario | TXT residente: 64 bytes | JPG no residente: 10 240 bytes |
Antes de la eliminación | El contenido se encuentra en el registro 43, en | El registro 42 contiene la lista de ejecuciones; el contenido se encuentra en los clústeres externos 8192-8194. |
Tras la eliminación | El registro está libre; los 64 bytes de contenido residente permanecen en el estado definido. | El registro y tres clústeres están libres; la asignación anterior y los 10 240 bytes de contenido permanecen en el estado definido. |
Tras la reutilización del registro | El valor de sustitución sobrescribe el mismo rango: coinciden 0 de los 64 bytes originales. | El nuevo propietario elimina la asignación anterior; el rango externo de referencia conocido sigue siendo de 10 240 / 10 240 bytes. |
Inspeccionar los campos de prueba de la MFT de los archivos eliminados
La comparación interactiva se abre con los dos estados eliminados uno al lado del otro. Su resumen recorre las tres etapas coincidentes, y su vista de almacenamiento distingue el contenido residente de los pares de asignación no residentes.
Allocation, content checks and addresses
Before Deletion: Where Are the File Contents?
The 64-byte TXT has FormCode 00 at record +0x120. Its complete contents occupy +0x130–+0x16F inside the MFT record. The 10,240-byte JPG has FormCode 01; its record holds mapping pairs at +0x158, while the image bytes occupy external clusters 8192–8194.
Resident TXT
S5: The selected text is the file content itself, stored inside record 43.
Nonresident JPG
S1: Record 42 stores the nonresident attribute and runlist; the JPEG content is at the external location described by that mapping.
After Deletion: What Is Freed, and What Remains?
Both records lose their in-use bit. For the TXT, the defined deletion state retains all 64 bytes inside the freed record; this resident stream has no separate payload clusters to release. For the JPG, deletion also releases its three external data clusters. The defined S2 state retains both the old runlist and all 10,240 external content bytes.
Resident TXT
S6: Flags become 00 00, but the selected resident content is unchanged from S5.
Nonresident JPG
S2: Flags become 00 00, while the record retains its mapping. The external content check in the HTML reports 10,240 matching bytes.
After Record Reuse: What Does the Same Operation Destroy?
In the TXT control, the replacement owner writes 64 tilde characters over the same resident-value range. All 64 original bytes in that range differ. In the JPG control, the replacement owner removes the original record’s mapping, but the defined operation leaves the external image data unchanged. Thus the JPG loses its old map while its data survives elsewhere; the TXT loses its original content within the reused record.
Resident TXT
S7: The same selected range now contains replacement text. Original resident content matching that range: 0 / 64 bytes.
Nonresident JPG
S3: Record 42 now describes new-owner.txt; the original JPG mapping is gone. The separately checked original external range still matches all 10,240 JPG bytes.
These are two different failure paths after the same kind of record reuse. A recovery assessment must check the resident value inside the TXT’s record, but it must check both historical mapping and external contents for the JPG. The record itself still occupies space within $MFT; “no external clusters” describes the resident TXT data stream only.
NTFS Deletion Metadata Experiment Results
For the JPG, S2 retains both the old map and all original content by construction. Reading the mapped clusters and trimming to 10,240 bytes produces a full byte-for-byte match and the same SHA-256 digest. That establishes content identity for this generated sample. However, this NTFS deleted file MFT test does not measure any application’s recovery performance.
S3 separates content survival from metadata survival. The original data bytes still match, but the current record belongs to a different file and no longer holds the original runlist. The saved baseline identifies where those bytes used to be; that knowledge is a comparison reference, not metadata available from the reused record. Other surviving structures or content analysis would be needed to locate and identify the old stream independently.
S4 demonstrates the opposite problem. The original filename and map remain in the freed record, but its middle cluster contains replacement bytes. Only 6,144 original bytes match; 4,096 differ. Reading the complete old range still produces a 10,240-byte result, yet its digest fails the original-content check. A correct filename and file length can therefore accompany damaged content. JPEG viewing behavior is a separate check from byte-for-byte identity.
For the TXT, S6 retains all 64 resident content bytes. In S7, none of those bytes match the replacement value. This is a content loss within the defined record replacement, without overwriting an external data cluster.
The NTFS deleted file MFT test above pairs the TXT and JPG at the same stage. Its other views retain the per-file before-and-after checks, while the details provide the calculated content digests.
Why Deleted File MFT Flags Cannot Prove Recoverability
A useful assessment needs three separate checks. First, establish the file’s identity from coherent metadata. Next, interpret its storage attributes, including resident-value boundaries, external mappings, and any additional records or streams. Finally, verify the contents available from those ranges. The generated scenarios deliberately let those checks produce different answers.
The two targets require different content checks. The resident TXT keeps its payload inside its record; the nonresident JPG relies on mapping information to reach external clusters. In S3, the new owner is resident to isolate record reuse from reuse of the JPG’s old data clusters. S5–S7 separately demonstrate what happens when the deleted target itself has resident data. Fragmented, compressed, encrypted, and sparse streams introduce additional interpretation requirements.
Nor should a tool equate an unused record with an intact deleted file automatically. Structural validity, allocation state, ownership, mapping consistency, and readable content answer different questions. Even a valid text fragment does not establish that a document, photograph, or video is complete.
What File Explorer and Disk Management Can Show
After final deletion, the original name should disappear from normal directory enumeration. Free space can increase once the file system releases its allocation, although unrelated activity can change the displayed total.
Ordinary deletion of one file does not turn an otherwise healthy NTFS volume into RAW or unallocated space. Disk Management describes volumes and partitions; it does not expose individual MFT record flags. A RAW label or missing partition therefore calls for a separate file-system or partition diagnosis, rather than being treated as confirmation of this deletion mechanism.
When File Recovery Comes Before File-System Repair
If the volume still works and only files are missing, repair is not the first explanation or action. Continued writes can reuse both freed records and freed clusters. Avoid installing tools, saving recovered files, or running unnecessary repair operations on the affected volume. Examine a suitable preserved copy when possible and save recovered content elsewhere.
For a practical check, Magic Data Recovery can scan the affected drive and preview supported files before recovery. Install it on another drive and save recovered files elsewhere; the software cannot recover content that later writes have overwritten.
SSD behavior adds another condition. The Comando TRIM can notify storage that released logical ranges are no longer needed. Microsoft’s read-only query fsutil behavior query DisableDeleteNotify reports the notification setting; it does not prove that a specific range retains its bytes.
If the original logical ranges return zeros or replacement content, a surviving MFT name cannot supply the missing nonresident payload. Conversely, readable old bytes still require correct mapping and content validation. Disabling notifications later does not reverse notifications already issued.
NTFS Deleted File MFT Test: Conclusion
Este Prueba de la MFT de un archivo eliminado en NTFS separates record allocation, data mapping, and content integrity. In the JPG’s retained-metadata scenario, deletion frees the record and clusters while the original content still matches. However, record reuse removes the old map without changing those data bytes, and a cluster overwrite damages content while leaving the old name and map available.
The resident TXT control adds a different failure path: deleting its record leaves the defined 64-byte value intact, but reusing that record replaces the value itself. The JPG instead requires separate checks of its record and external data.
The practical conclusion is to verify each layer independently. A filename identifies a candidate; a resident-value offset or nonresident runlist identifies its content location; a complete content check determines whether that location still reproduces the original stream. That distinction explains why a deleted file can appear in a scan yet fail to open correctly after extraction.
PREGUNTAS FRECUENTES
¿Los indicadores MFT de 0x0002 identifican un archivo eliminado?
¿Valida la firma FILE un registro MFT de NTFS?
¿Revela el número de secuencia cuántas veces se ha eliminado un archivo?
¿Se puede asignar un bloque libre a un archivo eliminado basándose únicamente en su bit de mapa de bits?
¿La eliminación de un enlace físico siempre libera los datos del archivo?
¿Una extensión correcta demuestra que el contenido extraído es válido?
