Test MFT sui file cancellati in NTFS: cosa cambia dopo la cancellazione?
Un Test MFT su file cancellati in NTFS deve confrontare più di un semplice nome di file. Una volta completata la cancellazione definitiva, NTFS può rilasciare il record del file, rimuovere la relativa voce dalla directory attiva e liberare i cluster di dati non residenti. Tuttavia, tali modifiche non cancellano necessariamente i vecchi contenuti. Questo esperimento mette a confronto un piccolo file TXT residente con un file JPG non residente attraverso la cancellazione e il riutilizzo del record, per poi esaminare una sovrascrittura definita dei dati esterni del file JPG. Il confronto distingue tre aspetti: il nome rimane, la sua mappatura rimane e i byte originali corrispondono ancora?
Indice dei contenuti
Cosa verifica questo test sull'MFT dei file cancellati in NTFS
La questione fondamentale è se un record MFT cancellato possa ancora descrivere un file completo. La risposta dipende sia dai metadati che dal contenuto. Un nome rimasto può identificare un vecchio file, mentre una runlist rimasta può individuare i cluster precedenti di uno stream non residente. Nessuno dei due elementi dimostra che tali cluster contengano ancora i dati originali.
Per contestualizzare, il Tabella file master La guida spiega come i record mettano in relazione nomi, attributi e posizioni di archiviazione. In questo contesto, l'attenzione è rivolta al passaggio da uno stato definito a un altro.
Questo esperimento utilizza campioni generati della struttura NTFS, confronti di byte calcolati e transizioni dello stato di allocazione definite in modo esplicito. Le schermate mostrano i record generati aperti in wxHexEditor, con selezioni corrispondenti prima e dopo: i flag del record JPG e i byte di contenuto residente del file TXT. Il modello riproduce la cancellazione definitiva di un file a collegamento singolo, con tutti gli handle chiusi, anziché lo spostamento nel Cestino.
Configurazione e ipotesi del test MFT NTFS
Questo test MFT sui file cancellati in NTFS utilizza un volume logico NTFS 3.1 non crittografato. Utilizza settori logici da 512 byte, cluster da 4.096 byte e record MFT da 1.024 byte. La sua partizione inizia all'LBA 2048 del disco. Si tratta di parametri scelti, piuttosto che di specifiche del dispositivo.
L'obiettivo, mft-lab-file.jpg, occupa il 42° posto, un record. Il suo anonimo, non residente $DATA Il flusso contiene esattamente 10.240 byte. Una sequenza contigua copre tre cluster, a partire dal cluster logico numero 8192. Di conseguenza, l'allocazione è di 12.288 byte, con 2.048 byte oltre la fine logica del file. Il dimensione dell'unità di allocazione La guida spiega questa distinzione tra dimensione e allocazione.
Entrambi gli obiettivi hanno un collegamento fisico e senza compressione NTFS, allocazione sparsa, flussi di dati alternativi o record di estensione. Il file JPG è un JPEG valido generato con dimensioni 160 × 120, con uno schema di pixel deterministico e un segmento di commento JPEG che ne imposta la lunghezza a 10.240 byte. È stato decodificato per verificare il formato del campione. Il record 42 inizia con il numero di sequenza 42.
Il secondo obiettivo, resident-note.txt, contiene esattamente 64 byte di testo ASCII all’interno del record 43, inizialmente alla sequenza 7. Il suo $DATA il valore non richiede cluster di dati separati. In entrambi gli esempi, il intestazione dell'attributo determina la forma di archiviazione: a .txt L'estensione di per sé non garantisce la presenza di dati residenti, e il .jpg L'estensione di per sé non costituisce un dato relativo ai non residenti.
Per ogni confronto con cancellazione immediata, il modello conserva il payload e gli attributi precedenti. Gli scenari successivi modificano lo slot del record o, nel caso dei file JPG, un cluster di dati esterni. Ciò consente di isolare i loro effetti senza presupporre una particolare sequenza di lettura dell’SSD o di scrittura di Windows.
Procedura di test MFT per i file cancellati in NTFS
Gli scenari da 1 a 4 seguono il formato JPG per i non residenti. Gli scenari S3 e S4 si diramano in modo indipendente dallo scenario S2. Gli scenari da S5 a S7 costituiscono un controllo TXT separato per i residenti; tali stati utilizzano il record 43 anziché il record 42.
JPG non residente: Stati di test MFT NTFS
S1 — Linea di base JPG.
Creare il record 42 specificandone il nome, la mappatura dei dati dei non residenti e il flag di utilizzo. Impostare i bit corrispondenti relativi all'allocazione del record e del cluster. Generare il contenuto completo e calcolarne il digest SHA-256.
S2 — Cancellazione dei file JPG completata.
A partire da S1, rimuovere il nome originale dall'appartenenza ad Active Directory, azzerare il bit "in uso" del record, ridurre a zero il numero di collegamenti e incrementare il numero di sequenza. Azzerare i bit pertinenti del record e della bitmap del cluster. Conservare il vecchio nome del file, l'attributo dei dati e il payload come previsto dal caso definito per i metadati conservati.
S3 — Slot di registrazione JPG riutilizzato.
A partire da S2, sostituire il record 42 con gli attributi di new-owner.txt, un piccolo file residente. Impostare nuovamente il bit di allocazione del record. Lasciare invariati e liberi i tre cluster di dati precedenti. Verificare se il record corrente rispecchi ancora la mappatura originale.
S4 — Cluster centrale JPG sovrascritto.
Torna separatamente a S2. Assegna l'LCN 8193 a un altro file e sostituisci ogni byte di quel cluster con il suo inverso bit per bit (FF XOR originale). Questa sostituzione definita modifica ogni byte dell'intervallo. Lasciare invariato il vecchio record di destinazione liberato. Confrontare il flusso risultante di 10.240 byte con quello originale.
TXT residente: Stati di test dell'MFT NTFS
S5 — Linea di base TXT dei residenti.
Crea il record n. 43 per resident-note.txt con 64 byte nella sua memoria residente $DATA attributo. Impostare il bit di allocazione del record e registrare la posizione e il digest del valore. Il suo flusso di dati non presenta alcuna allocazione di cluster esterna.
S6 — Cancellazione del file TXT residente completata.
A partire da S5, rimuovere il nome del file attivo, azzerare i bit di utilizzo e di allocazione del record, impostare i collegamenti a zero e incrementare la sequenza da 7 a 8. Conservare i byte di contenuto residente. Per questo flusso non ci sono bit separati relativi ai cluster di payload da azzerare.
S7 — Record TXT residente riutilizzato.
A partire dall'S6, riutilizzare il record 43 per replacement1.txt. Inserire 64 caratteri tilde nello stesso intervallo di valori residenti. Confrontare tale intervallo con il testo originale per determinare se il payload originale sopravviva a questa sostituzione.
Confronta i contenuti dopo l'eliminazione e il riutilizzo
Valutare i contenuti separatamente. Per il file JPG, decodificare la mappatura conservata, leggere gli intervalli esterni nell'ordine in cui compaiono nel file e fermarsi a 10.240 byte. Per il file TXT, leggere il valore di 64 byte contenuto nel relativo record. Confrontare i byte completi e il digest; escludere lo spazio libero del cluster e non utilizzare il nome del file come controllo di integrità.
Queste trasformazioni si applicano alle strutture generate in modo temporaneo. Per un controllo basato sul dispositivo, utilizzare supporti di prova usa e getta e verificare l’identità del bersaglio prima di eliminare qualsiasi cosa. Conservare la fonte interessata quando si indaga su una perdita effettiva di dati.
Confronto esadecimale della cancellazione di file NTFS
Nella sezione sottostante con le schermate affiancate, confronta ciascun file con la sua versione precedente. Il campo dell'intestazione in +0x16 è la parola di flag a due byte. Il suo bit meno significativo passa da “allocato” a “libero”. I campi “sequenza” e “collegamento” adiacenti forniscono il contesto di riferimento. Il h il suffisso identifica gli offset esadecimali delle righe; gli screenshot in formato JPG selezionano +0x16–+0x17; gli screenshot in formato TXT, invece, selezionano il contenuto residente ai fini del confronto.
Campi MFT dei file cancellati: cosa è cambiato?
La modifica del flag libera il record; non indica al parser di sostituire i dati del file con degli zeri. Anche la modifica della sequenza è importante: un vecchio riferimento che identifica il record 42 con la sequenza 42 è ora obsoleto. Documentazione Microsoft l'incremento della sequenza quando viene liberato un segmento di record di file.
Le due modifiche alla mappa bit descrivono allocazione di record e cluster. $MFT::$BITMAP tiene traccia dell'allocazione dei record. In questo esempio, il record 42 corrisponde al bit 2 del byte +0x05. Il volume $Bitmap::$DATA tiene traccia dell'allocazione dei cluster. I cluster 8192–8194 corrispondono ai bit 0–2 del byte +0x0400.
L'azzeramento di quei bit rende le risorse disponibili per il riutilizzo. Ciò non garantisce che una lettura successiva restituisca il contenuto originale. Inoltre, la rimozione del nome originale dall'indice di Active Directory è un'operazione distinta dalla conservazione $ NOME_FILE attributo all'interno del record liberato. Gli aggiornamenti dell'albero delle directory possono spostare o sovrascrivere le voci dell'indice, pertanto i residui dell'indice richiedono una propria interpretazione.
In che modo l’MFT individua un file cancellato?
Nelle tabelle S1 e S2, l'attributo "non residente" inizia al record +0x118. Il suo offset delle coppie di mappatura è 0x40, inserendo la lista di esecuzione nel record +0x158. I byte descrivono una sequenza di tre cluster che inizia all'LCN 8192. Il confronto interattivo riportato di seguito mantiene i valori esadecimali effettivi e consente ai lettori di esaminare questi campi.
Gli LCN sono relativi al volume. Pertanto, il primo cluster di dati inizia all'offset in byte del volume 0x02000000. Sommando l'offset della partizione selezionata si ottiene l'offset in byte sul disco 0x02100000, ovvero l'LBA 67584 del disco. Confondere queste basi porterebbe un lettore di recupero a esaminare la posizione sbagliata.
TXT per residenti vs JPG per non residenti: stessa cancellazione, modalità di archiviazione diverse
Confronta i due file nella stessa fase: S5 rispetto a S1 prima della cancellazione, S6 rispetto a S2 dopo la cancellazione e S7 rispetto a S3 dopo il riutilizzo del record. Il file TXT occupa il record 43; il file JPG occupa il record 42. I nomi dei file, i numeri di record e i valori iniziali della sequenza diversi identificano oggetti diversi, anziché indicare modifiche dovute alla cancellazione.
Palcoscenico | TXT residente: 64 byte | JPG non residente: 10.240 byte |
Prima della cancellazione | Il contenuto si trova nel record 43 all'indirizzo | Il record 42 contiene la lista delle esecuzioni; il contenuto si trova nei cluster esterni 8192–8194. |
Dopo la cancellazione | La scrittura è libera; tutti i 64 byte di contenuto residenti rimangono nello stato definito. | Il record e tre cluster sono liberi; la vecchia mappatura e tutti i 10.240 byte di contenuto rimangono nello stato definito. |
Dopo il riutilizzo record | Il valore di sostituzione sovrascrive lo stesso intervallo: corrispondono 0 / 64 byte originali. | Il nuovo proprietario rimuove la vecchia mappatura; l'intervallo esterno di riferimento noto corrisponde ancora a 10.240 / 10.240 byte. |
Verifica dei campi di prova MFT dei file eliminati
Il confronto interattivo si apre con i due stati eliminati affiancati. Il riepilogo illustra tutte e tre le fasi corrispondenti, mentre la vista di archiviazione distingue i contenuti residenti dalle coppie di mappature non residenti.
Assegnazione, controlli dei contenuti e indirizzi
Prima della cancellazione: dove si trova il contenuto del file?
Il file TXT da 64 byte contiene il FormCode 00 a livelli record +0x120. Il suo contenuto completo occupa +0x130–+0x16F all'interno del record MFT. Il file JPG da 10.240 byte ha il FormCode 01; il suo record contiene coppie di mappature a +0x158, mentre i byte dell'immagine occupano i cluster esterni 8192–8194.
TXT residente
S5: Il testo selezionato è il contenuto stesso del file, memorizzato nel record 43.
JPG per non residenti
S1: Il record 42 memorizza l'attributo "non residente" e la runlist; il contenuto JPEG si trova nella posizione esterna indicata da tale mappatura.
Dopo la cancellazione: cosa viene liberato e cosa rimane?
Entrambi i record perdono il bit "in uso". Per il TXT, lo stato di cancellazione definito conserva tutti i 64 byte all'interno del record liberato; questo flusso residente non ha cluster di payload separati da rilasciare. Per il JPG, la cancellazione libera anche i suoi tre cluster di dati esterni. Lo stato S2 definito conserva sia la vecchia runlist che tutti i 10.240 byte di contenuto esterno.
TXT residente
S6: I flag assumono il valore 00 00, ma il contenuto residente selezionato rimane invariato rispetto a S5.
JPG per non residenti
S2: Le bandiere diventano 00 00, mentre il record mantiene la propria mappatura. Il controllo dei contenuti esterni nel codice HTML rileva 10.240 byte corrispondenti.
Dopo il riutilizzo di un record: cosa viene eliminato dalla stessa operazione?
Nel controllo TXT, il proprietario sostitutivo scrive 64 caratteri tilde nello stesso intervallo di valori residenti. Tutti i 64 byte originali in quell'intervallo risultano diversi. Nel controllo JPG, il proprietario sostitutivo rimuove la mappatura del record originale, ma l'operazione definita lascia invariati i dati esterni dell'immagine. Pertanto, il JPG perde la sua vecchia mappatura mentre i suoi dati sopravvivono altrove; il TXT perde il suo contenuto originale all'interno del record riutilizzato.
TXT residente
S7: Lo stesso intervallo selezionato ora contiene il testo sostitutivo. Contenuto originale presente che corrisponde a tale intervallo: 0 / 64 byte.
JPG per non residenti
S3: Il record 42 ora descrive new-owner.txt; la mappatura JPG originale è andata persa. L'intervallo esterno originale, verificato separatamente, corrisponde ancora a tutti i 10.240 byte del file JPG.
Si tratta di due diversi percorsi di errore a seguito dello stesso tipo di riutilizzo di un record. Una valutazione del ripristino deve verificare il valore residente all’interno del record TXT, ma deve controllare sia la mappatura storica che i contenuti esterni del file JPG. Il record stesso occupa ancora spazio all’interno di $MFT; l'espressione “nessun cluster esterno” si riferisce esclusivamente al flusso di dati TXT residente.
Risultati dell'esperimento sui metadati di cancellazione NTFS
Per il file JPG, S2 conserva per impostazione predefinita sia la vecchia mappa che tutti i contenuti originali. La lettura dei cluster mappati e il ridimensionamento a 10.240 byte producono una corrispondenza completa byte per byte e lo stesso digest SHA-256. Ciò conferma l’identità del contenuto per questo campione generato. Tuttavia, questo test sull’MFT dei file cancellati in NTFS non misura le prestazioni di recupero di alcuna applicazione.
S3 distingue la sopravvivenza dei contenuti da quella dei metadati. I byte dei dati originali corrispondono ancora, ma il record attuale appartiene a un file diverso e non contiene più la runlist originale. La baseline salvata identifica dove si trovavano in precedenza quei byte; tale informazione costituisce un riferimento di confronto, non un metadato disponibile dal record riutilizzato. Per individuare e identificare in modo indipendente il vecchio flusso sarebbero necessarie altre strutture sopravvissute o un'analisi dei contenuti.
S4 evidenzia il problema opposto. Il nome del file originale e la mappa rimangono nel record liberato, ma il suo cluster centrale contiene byte sostitutivi. Solo 6.144 byte originali corrispondono; 4.096 sono diversi. La lettura dell’intero intervallo precedente produce comunque un risultato di 10.240 byte, ma il suo digest non supera il controllo di corrispondenza con il contenuto originale. Un nome file e una lunghezza file corretti possono quindi accompagnare un contenuto danneggiato. Il comportamento di visualizzazione dei file JPEG costituisce un controllo distinto dall’identità byte per byte.
Per il TXT, S6 conserva tutti i 64 byte di contenuto residenti. In S7, nessuno di questi byte corrisponde al valore di sostituzione. Si tratta di una perdita di contenuto nell'ambito della sostituzione del record definita, senza sovrascrivere un cluster di dati esterno.
Il test MFT sui file cancellati in NTFS sopra riportato abbina i file TXT e JPG nella stessa fase. Le altre visualizzazioni mantengono i controlli “prima e dopo” per singolo file, mentre la sezione dei dettagli fornisce i digest dei contenuti calcolati.
Perché i flag MFT dei file cancellati non possono dimostrare la possibilità di recupero
Una valutazione efficace richiede tre controlli distinti. Innanzitutto, occorre stabilire l’identità del file sulla base di metadati coerenti. Successivamente, occorre interpretare le sue caratteristiche di archiviazione, inclusi i limiti dei valori residenti, le mappature esterne ed eventuali record o flussi aggiuntivi. Infine, occorre verificare i contenuti disponibili in tali intervalli. Gli scenari generati consentono deliberatamente che tali controlli producano risposte diverse.
I due target richiedono controlli diversi sui contenuti. Il TXT residente conserva il proprio payload all’interno del proprio record; il JPG non residente si affida alle informazioni di mappatura per raggiungere i cluster esterni. In S3, il nuovo proprietario è residente per isolare il riutilizzo del record dal riutilizzo dei vecchi cluster di dati del JPG. S5–S7 illustrano separatamente cosa accade quando la destinazione eliminata stessa contiene dati residenti. I flussi frammentati, compressi, crittografati e sparsi introducono ulteriori requisiti di interpretazione.
Né uno strumento dovrebbe equiparare automaticamente un record inutilizzato a un file cancellato ma intatto. La validità strutturale, lo stato di allocazione, la proprietà, la coerenza della mappatura e la leggibilità del contenuto rispondono a domande diverse. Anche un frammento di testo valido non dimostra che un documento, una fotografia o un video sia completo.
Cosa possono mostrare Esplora file e Gestione disco
Dopo la cancellazione definitiva, il nome originale dovrebbe scomparire dall'elenco normale delle directory. Lo spazio libero può aumentare una volta che il file system libera l'allocazione, anche se attività non correlate possono modificare il totale visualizzato.
La semplice eliminazione di un file non trasforma un volume NTFS, altrimenti integro, in spazio RAW o non allocato. Gestione disco descrive i volumi e le partizioni, ma non mostra i singoli flag dei record MFT. L’etichetta RAW o la mancanza di una partizione richiedono quindi una diagnosi separata del file system o della partizione, piuttosto che essere considerate una conferma di questo meccanismo di eliminazione.
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 comportamento 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
Questo Test MFT su file cancellati in 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.
FAQ
I flag MFT con valore 0x0002 indicano un file eliminato?
La firma FILE verifica la validità di un record MFT NTFS?
Il numero di sequenza rivela quante volte un file è stato cancellato?
È possibile assegnare un cluster libero a un file cancellato basandosi esclusivamente sul suo bitmap?
L'eliminazione di un collegamento fisico comporta sempre la liberazione dei dati del file?
Un’estensione corretta dimostra che il contenuto estratto è valido?
