Metadati NTFS dopo una formattazione rapida: un’analisi con WinHex
I metadati NTFS dopo una formattazione rapida descrivono un file system appena inizializzato, mentre alcuni record e contenuti dei file del file system precedente potrebbero rimanere leggibili al di sotto di esso. Windows crea una nuova Master File Table e una nuova struttura di directory; non si limita semplicemente a nascondere tutti i vecchi nomi di file. Il recupero ha esito positivo quando una quantità sufficiente di metadati originali e dei dati da essi descritti sopravvive e rimane accessibile.
WinHex aiuta a distinguere queste condizioni mostrando i campi del settore di avvio, i record MFT e le mappature dei blocchi di dati. Questo articolo esamina un caso di formattazione rapida da NTFS a NTFS e un esempio separato di ricostruzione di frammenti MFT. I calcoli si applicano alle strutture registrate, piuttosto che a ogni volume Windows. Il comportamento di scarto degli SSD e le successive operazioni di scrittura possono produrre risultati molto diversi.
Indice dei contenuti
1. Quali modifiche apporta la formattazione rapida nel file system NTFS
Il Sistema di file NTFS organizza i file tramite file di metadati, indici delle directory e mappature dei cluster. Una formattazione rapida crea una nuova istanza di queste strutture.
Struttura | Ruolo dopo la formattazione rapida | Conseguenze per il recupero |
Settore di avvio del volume e relativo backup | Descrivi il volume appena formattato | I puntatori MFT attuali potrebbero non riuscire più a individuare la vecchia tabella |
$MFT e directory principale | Descrivi il nuovo file system e i suoi oggetti iniziali | I vecchi nomi dei file e le relazioni tra le directory scompaiono durante la normale navigazione |
| Tiene traccia dei record allocati nella nuova MFT | Non tiene conto dei record sopravvissuti al di fuori di quella tabella |
$Bitmap | Tiene traccia dei cluster allocati nel nuovo volume | I cluster già occupati possono diventare disponibili per essere riutilizzati |
$MFTMirr e altri metadati di sistema | Supportare il file system appena inizializzato | I loro scritti possono sovrascrivere metadati o contenuti di file precedenti |
Posizioni precedenti dei dati dei file | Potrebbe conservare contenuti leggibili al di fuori degli intervalli sovrascritti o eliminati | La sopravvivenza va verificata, non data per scontata |
Il Tabella file master è esso stesso un file. Il suo flusso $DATA, privo di nome, contiene record di file; la sua bitmap descrive l'allocazione dei record. Il file separato $Bitmap descrive l'allocazione dei cluster all'interno del volume. Confondere queste due bitmap porta a conclusioni errate su ciò che è stato salvato.
Anche la formattazione di una partizione esistente è diversa dall'eliminazione della relativa voce nella tabella delle partizioni. Una formattazione di routine del volume ricostruisce il file system all'interno del volume selezionato; l'eliminazione della partizione riguarda invece la struttura del disco al di fuori di esso.
2. Leggere il settore di avvio originale in WinHex
Per un confronto esadecimale "prima e dopo" della formattazione NTFS, conservare un'immagine del settore prima della formattazione e confrontarla con un'immagine acquisita successivamente. Su un supporto già formattato, utilizzare un'immagine e eventuali acquisizioni precedenti disponibili. Non ripetere la formattazione per riprodurre l'evento.
Il record di avvio del volume fornisce i parametri necessari per interpretare gli indirizzi dei cluster.
Estratto esadecimale originale del settore di avvio tratto dal fascicolo di WinHex. I riquadri rossi indicano i campi relativi alla dimensione del settore, alla dimensione del cluster e alla posizione nella MFT.
Offset del settore di avvio | Byte registrati | Interpretazione |
|
| 512 byte per settore logico |
|
| Otto settori per cluster |
|
| $MFT inizia a LCN 175.724.968 |
|
| $MFTMirr inizia a LCN 167.336.228 |
|
| Valore con segno −10: la dimensione del record è 2¹⁰ = 1.024 byte |
I numeri interi multibyte utilizzano l'ordine dei byte little-endian. Il dimensione dell'unità di allocazione è quindi:
- 512 × 8 = 4.096 byte per cluster
LCN indica un numero di cluster relativo al volume. Di conseguenza:
- Settore relativo al volume MFT originale = 175.724.968 × 8
- = 1,405,799,744
- Offset in byte relativo al volume MFT originale = 175.724.968 × 4.096
- = 719,769,468,928
Quando si esamina un'immagine dell'intero disco, aggiungere l'offset in byte iniziale del volume. Quando si esamina un'immagine relativa solo al volume, non aggiungerlo nuovamente. Il contesto di indirizzamento visualizzato da WinHex deve corrispondere al calcolo.
Il settore di avvio identifica il primo extent dell'MFT. Non descrive ogni singolo frammento della tabella.
3. Decodificare i dati relativi ai non residenti contenuti nell’MFT originale
Nella posizione originale dell'MFT, verificare il record 0 e individuare il suo attributo senza nome $DATA, digitare 0x80. Un attributo non residente memorizza le informazioni di mappatura anziché l'intero contenuto all'interno del record.
Le note del caso indicano che questo attributo si trova all'offset del record 0x100. Questo fa sì che il suo byte di forma compaia a 0x108; il valore 01 indica "non residente". Questi offset assoluti appartengono a questo record. Altri record possono collocare l'attributo in un'altra posizione.
Quando si interpreta un altro record, utilizzare gli offset relativi all'inizio dell'attributo:
Offset relativo | Campo |
| Modulo per residenti/non residenti |
| Numero di cluster virtuale più basso, o VCN |
| VCN più alto, compreso |
| Offset rispetto all'array delle coppie di mappature |
| Lunghezza assegnata |
| Dimensione logica del file |
| Lunghezza dei dati validi |
Leggere i tre campi relativi alle dimensioni separatamente. La lunghezza allocata indica lo spazio di archiviazione riservato, la dimensione logica definisce la lunghezza del flusso e la lunghezza dei dati validi descrive i dati inizializzati. Non è necessario che siano uguali.
Per un intervallo che copre i VCN da 0 a 98.431, il numero di cluster è 98.432, non 98.431. La struttura a due passaggi registrata fornisce:
Correre | Numero di cluster | Firmato LCN delta | Avvio di LCN | Slot di record logici da 1.024 byte ciascuno |
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 |
Il secondo indirizzo è relativo alla corsa precedente inizio LCN:
- 175,724,968 + 83,118,309 = 258,843,277
- (75.096 + 23.336) × 4.096 = 403.177.472 byte
- 403.177.472 ÷ 1.024 = 393.728 slot per record
Si tratta di slot indirizzabili, non di un conteggio dei file attivi. Alcuni record potrebbero non essere utilizzati e un singolo file può richiedere più record.
Le intestazioni delle esecuzioni registrate 43 e 42 descrivere le larghezze dei campi. Per 43, la lunghezza occupa tre byte e il delta LCN quattro; per 42, la lunghezza occupa due byte e il delta quattro. Il delta LCN va interpretato come un valore con segno, poiché i frammenti successivi possono trovarsi in posizioni precedenti sul volume.
La lunghezza dell'estensione risultante è di 384,5 MiB. La visualizzazione arrotondata a “385 MB” non può di per sé stabilire una dimensione di allocazione diversa né dimostrare che siano stati riservati cluster aggiuntivi.
4. Confronta il nuovo MFT con il vecchio layout
Le note del caso riportano un MFT post-formattazione che inizia a LCN 786.432, con un’estensione di 180 cluster. Ipotizzando una dimensione del cluster pari a 4.096 byte, come riportato:
- Offset del byte iniziale del nuovo MFT = 786.432 × 4.096
- = 3,221,225,472
- Nuova dimensione dell'estensione = 180 × 4.096 = 737.280 byte
Il nuovo punto di inizio si trova a 3 GiB all'interno del volume. Tale indirizzo è un'osservazione relativa a questo caso specifico, non una posizione obbligatoria nel file system NTFS.
Proprietà | Layout originale | Layout del formato del post registrato nelle note |
Avvio di MFT LCN | 175,724,968 | 786,432 |
Estensioni MFT registrate | Due | Uno |
Copertura dell'estensione | 98.432 cluster | 180 cluster |
Capacità alla dimensione del record registrata | 393.728 slot | 720 slot |
Le note menzionano inoltre i record da 0 a 717. Si tratta di 718 record, ovvero 735.232 byte. Ciò è compatibile con un’allocazione sufficientemente ampia per 720 slot, ma non chiarisce se il numero 718 si riferisca alla lunghezza logica, alla lunghezza inizializzata o ai record esaminati. Tali campi richiedono i byte di attributo sottostanti.
Il cambiamento significativo è che Windows ora segue la nuova tabella. Le dimensioni ridotte della nuova MFT consentono non significa che la vecchia tabella è stata fisicamente troncata sul posto. Le sue precedenti posizioni devono essere ispezionate separatamente.
Per stabilire se l’MFT NTFS sia stato sovrascritto durante la formattazione, occorre confrontare gli estenti originali dell’MFT con tutte le nuove scritture di metadati e le successive allocazioni. Un puntatore modificato dimostra che il riferimento è stato alterato; un confronto a livello di byte conferma la sovrascrittura in una posizione specifica. Il solo spostamento non dimostra né la completa sopravvivenza né la completa perdita dei dati.
5. Ricostruire una tabella MFT frammentata a partire dai record sopravvissuti
La frammentazione dell'MFT si sviluppa man mano che la tabella cresce e lo spazio contiguo non è più disponibile. NTFS riserva una zona MFT per ridurre la frammentazione, ma ciò non garantisce un unico extent. La crescita può allocare frammenti prima o dopo l'extent corrente.
Un esempio di ricostruzione a sé stante, contenuto nel materiale del caso, illustra questa disposizione a tre righe. Non deve essere associato al caso precedente a due righe, come se entrambi descrivessero la stessa tabella.
Correre | Slot per record logici | Avvio di LCN | Differenza rispetto all'inizio dell'esecuzione precedente | Cluster |
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 |
In ogni cluster da 4.096 byte trovano posto quattro slot da 1.024 byte. Questo spiega entrambi i limiti:
- 51.232 × 4 = 204.928 slot
- 204.928 + (10.915 × 4) = 248.588
- 9.274.281 − 416.173 = 8.858.108
Complessivamente, le esecuzioni coprono 94.098 cluster, pari a 385.425.408 byte. Il VCN finale è 94.097.
Individuazione e verifica dei dati dei candidati
Le note di ricostruzione descrivono la ricerca del record 204.928, lo scartamento di un candidato in quanto non valido e l'individuazione di un altro candidato ritenuto valido. Un numero corrispondente o il FILE La firma da sola non è sufficiente.
Su un'immagine di sola lettura:
- Ricerca di
FILEfirme, comprese quelle relative a posizioni al di fuori dell'attuale MFT. Una scansione limitata alla nuova tabella non rileverà i record distaccati. - Verificare i limiti dei record, la lunghezza dei record, gli offset degli attributi e la lunghezza degli attributi.
- Verificare l'array della sequenza di aggiornamento prima di interpretare i byte dei record protetti. Nei record registrati da 1.024 byte, i controlli coprono le estremità dei due intervalli da 512 byte.
- Ripristinare i termini del trailer salvati nella memoria del parser prima di analizzare gli attributi oltre tali confini; non modificare l'immagine delle prove.
- Confrontare i record adiacenti, la numerazione dei record (ove presente), i nomi, i riferimenti ai record principali e i numeri di sequenza. Scartare le relazioni non plausibili o obsolete.
Se un vecchio record 0 ancora presente fornisce una runlist valida, utilizzare quella mappatura. Se manca, la ricostruzione degli extent a partire dalle sequenze di record rimane un’ipotesi che richiede ulteriori verifiche. La presenza di record vuoti in una regione non dimostra di per sé che non esistano frammenti successivi.
Rimontare separatamente la tavola logica
Copiare gli estenti convalidati in un file di analisi separato, in ordine VCN. Non ordinarli in base all’LCN crescente: la terza esecuzione sopra indicata si trova prima della seconda sul disco, ma la segue dal punto di vista logico.
Per il numero di registrazione n, dimensione del record R, e la dimensione del cluster C:
- VCN = floor(n × R ÷ C)
- Offset all'interno del cluster = (n × R) mod C
- LCN = LCN iniziale della corsa + (VCN − VCN iniziale della corsa)
Per il record 204.929 nell'esempio a tre run, il VCN è 51.232 e il suo offset all'interno del cluster è di 1.024 byte. Il suo indirizzo relativo al volume è quindi:
- 9.274.281 × 4.096 + 1.024 = 37.987.456.000 byte
Questa mappatura recupera un indirizzo, non un file. Il record e i dati a cui fa riferimento devono comunque essere sottoposti a verifica.
6. Recuperare il contenuto dei file tramite i vecchi attributi
Una volta compreso un record di file sopravvissuto, il suo attributo $DATA determina il metodo di estrazione.
Dati dei residenti: leggere l'offset e la lunghezza del valore dell'attributo, quindi esportare tale valore dal record convalidato e ripristinato tramite correzione. I file di piccole dimensioni possono perdere il proprio contenuto quando i relativi record MFT vengono sovrascritti, poiché il contenuto risiede proprio lì.
Dati relativi ai non residenti ordinari: decodificare la runlist del file stesso, leggere ogni estensione dall'immagine originale del volume, assemblare i byte nell'ordine VCN e ritagliare l'output in base alla dimensione logica del file. La runlist della MFT individua i record dei file; non sostituisce la mappatura tra file e dati di ciascun utente.
Seguire i riferimenti $ATTRIBUTE_LIST quando gli attributi si estendono ad altri record. I flussi sparsi e compressi richiedono le rispettive regole di decodifica. I contenuti crittografati richiedono comunque il materiale di decrittografia applicabile. In questi casi, la semplice concatenazione non è sufficiente.
Il recupero delle directory richiede particolare attenzione. Un nome di file può sopravvivere anche se la directory padre non esiste più. Ricostruire i percorsi solo quando i riferimenti e i numeri di sequenza coincidono; in caso contrario, mantenere il file orfano piuttosto che inventare una relazione con una cartella.
Salvare i file estratti su un altro dispositivo fisico. Modificare il nuovo settore di avvio in modo che punti a un vecchio MFT non equivale a recuperare i file: le mappe di allocazione, gli indici, i record di sistema e altri metadati potrebbero appartenere a istanze diverse del file system.
7. Perché il recupero può funzionare — e perché può fallire
Il recupero basato sui metadati può avere esito positivo perché un vecchio record conserva l'identità di un file, la sua dimensione logica e le mappature dei dati, mentre i contenuti mappati rimangono leggibili. Uno strumento di recupero può seguire tali relazioni anche se Windows non le include più nel proprio spazio dei nomi attivo.
Se mancano dei record, il “carving” basato sulle firme può talvolta identificare direttamente il contenuto dei file. Di solito questa tecnica comporta la perdita dei nomi dei file originali e della struttura delle directory ed è meno affidabile nel caso di file frammentati. X-Ways documenta la ricerca dei record NTFS al di fuori dell’attuale MFT separatamente dalla ricerca delle intestazioni dei file, riflettendo così questi diversi metodi di recupero.
Il recupero diventa più difficile quando nuovi metadati si sovrappongono ai record originali, i file successivi riutilizzano i vecchi cluster o mancano le mappature di frammentazione. Un nome file valido non garantisce l’integrità del contenuto; una prima pagina o un’intestazione video riconoscibile non garantiscono che i frammenti successivi siano sopravvissuti.
Gli SSD introducono un’ulteriore condizione. La formattazione di Windows può inviare notifiche TRIM/cancellazione; Microsoft’s formato la documentazione comprende /NoTrim per eliminarli. Si tratta di un'opzione di formattazione, non di una soluzione in caso di perdita di dati. A seconda del dispositivo e del percorso di archiviazione, gli intervalli eliminati potrebbero smettere di restituire i byte originali anche senza una sovrascrittura convenzionale visibile in WinHex. La formattazione rapida non garantisce quindi in modo universale la possibilità di recupero dei dati.
8. Verificare i dati estratti prima di riutilizzare il disco
Conservare l'immagine originale e la mappa di estensione fino al completamento della convalida. Per un flusso di lavoro pratico di scansione ed esportazione, consultare recuperare i file da un disco rigido formattato.
Confronta i file recuperati con un inventario precedente alla formattazione, se disponibile. Confronta nomi, dimensioni, relazioni tra cartelle e hash con gli originali noti. In assenza di hash di riferimento, apri i documenti e controlla le loro pagine, verifica gli archivi, visualizza le immagini a piena risoluzione e riproduci i file video per intero.
Registrare i file danneggiati o mancanti separatamente dai file verificati. Una tabella MFT ricostruita senza errori di analisi sintattica garantisce metadati leggibili; i contenuti esportati utilizzabili garantiscono il recupero dei file. Per un recupero completo è necessario tenere conto del set di dati previsto.
Domande frequenti
La formattazione rapida sovrascrive l'intera MFT del file system NTFS?
I file possono sopravvivere anche se i relativi record MFT sono andati persi?
Il mirror MFT è in grado di ripristinare tutti i record dei file?
Un bit pari a zero nella bitmap del nuovo volume significa che i vecchi dati sono stati cancellati?
È possibile che un vecchio record MFT abbia ancora il flag "in uso" attivato?
Il ripristino del vecchio settore di avvio annullerà la formattazione?
