$MFTMirr è la più piccola polizza assicurativa di NTFS. Replica i primi record di $MFT così che, quando i byte all'inizio della tabella principale sono illeggibili, il driver del filesystem abbia ancora un modo per trovare ogni file sul volume. È anche l'artefatto che la gente dimentica di acquisire e poi serve tre settimane dopo.
Questo è ciò che effettivamente contiene, dove sta sul disco, quando NTFS lo usa e i casi (limitati) in cui guadagna il suo posto nella forense.
Perché esiste un mirror
I primi record di $MFT sono portanti. Il record 0 è $MFT stessa, con una runlist $DATA che dice dove vive il resto della tabella sul disco. Il record 2 è $LogFile. Il record 3 è $Volume. Se i byte all'inizio di $MFT sono danneggiati, NTFS non può trovare nessuno degli altri file del volume, compreso il log delle transazioni che userebbe normalmente per recuperare le incoerenze del filesystem.
Quella è una dipendenza circolare: ti serve $MFT per trovare $LogFile, ma ti serve $LogFile per riparare $MFT. Il mirror rompe il ciclo. $MFTMirr è un file separato in una posizione fisica diversa che mantiene un duplicato di quei primi record. Quando il driver monta un volume, legge il record 0 da $MFT; se quella lettura fallisce o l'array di fixup non si verifica, ripiega sul record 0 da $MFTMirr e usa il duplicato per rilocare il resto.
Dove vive
$MFTMirr è il record MFT 1. Il suo attributo $DATA è non residente, e la sua runlist tradizionalmente punta alla metà del volume così che un singolo guasto localizzato (un settore difettoso, una scrittura lacerata su una regione) non possa eliminare entrambe le copie. NTFS moderno lo posiziona alla LCN clusterCount / 2. Su un volume da 500 GB, ciò colloca il mirror intorno alla soglia dei 250 GB.
Lo puoi trovare da un sistema vivo:
fsutil file queryextents C:\$MFTMirr
Restituisce i cluster run che $MFTMirr occupa, che una lettura grezza può riassemblare. Il target MFT di KAPE lo raccoglie accanto a $MFT di default. Se usi FTK Imager, sta accanto a $MFT nella radice del volume NTFS.
Cosa contiene
Copie byte per byte dei primi record MFT. La garanzia storica erano i primi quattro record (0 a 3, i metadati davvero essenziali). Le versioni attuali di Windows mirroreggiano i primi sedici, che è l'intero set di metadati NTFS descritto nel riferimento della master file table.
Ogni copia è un normale record MFT. Stessa firma FILE, stesso header, stesso array di fixup, stesso flusso di attributi. Un parser puntato a $MFTMirr lo percorre esattamente come percorre $MFT. MFTECmd, mft_dump, analyzeMFT e il fls del Sleuth Kit lo accettano tutti come input.
Come NTFS lo usa al mount
Su un mount sano, il driver non tocca $MFTMirr. Su un mount danneggiato:
- Leggi il record 0 di
$MFT. - Se la lettura restituisce un errore I/O, o la verifica del fixup fallisce, leggi invece il record 0 di
$MFTMirr. - Se la copia del record 0 nel mirror è valida, usa la sua runlist
$DATAper localizzare$MFTsul disco e continua.
Il mirror non deve sostituire $MFT. Deve solo fornire informazioni sufficienti per trovare quella vera. Dopo che il driver ha localizzato $MFT dal puntatore del mirror, procede con la tabella viva.
Come chkdsk lo usa
chkdsk è più aggressivo. Quando rileva corruzione nei primi record di $MFT, incrocia ogni record con il mirror. Se entrambe le copie sono valide ma differiscono, chkdsk tratta il mirror come autorevole per i primi pochi record critici (assumendo che i record vivi siano stati aggiornati più di recente e corrotti nel processo).
Se $MFT è illeggibile e il mirror è illeggibile, chkdsk segnala Windows non può ripristinare la master file table. CHKDSK abortito. A quel punto il recupero richiede strumenti offline: carving della firma per record FILE sul volume grezzo con Sleuth Kit, R-Studio o testdisk. L'autoriparazione integrata di NTFS è esaurita.
Perché $MFTMirr non è un backup completo
Replica solo i file di metadati. I record 16 in poi, che sono ogni file e directory utente, esistono solo in $MFT. Se $MFT è danneggiata oltre il record 16, il mirror non può aiutarti. Il mirror basta per montare il volume; recuperare file arbitrari dal danno richiede le stesse tecniche che useresti senza di esso.
Questo è il malinteso che costa tempo alla gente negli ingaggi IR. Ricorrono a $MFTMirr pensando che sia uno snapshot storico completo. Non lo è. Per quello vuoi le Volume Shadow Copies, ciascuna delle quali contiene una vera copia a un istante della $MFT completa.
Interesse forense
$MFTMirr è raramente l'artefatto primario in un caso, ma ha due usi reali:
- Verifica incrociata. I record da 0 a 15 nel mirror dovrebbero corrispondere ai record vivi bit per bit. Una divergenza suggerisce che un lato è stato modificato fuori banda: un bug del driver, manomissione deliberata, recupero parziale dopo un crash, o un wiper malscritto che ha scarabocchiato la MFT viva e ha mancato il mirror. Ho visto esattamente un caso in cui il mirror ha colto un wiper che ha sovrascritto i primi 16 record di
$MFTe non si è accorto che una copia viveva altrove sul volume. La ricostruzione ha funzionato perché il mirror era intatto. - Snapshot pre-corruzione. Se i record vivi di
$MFTsono stati modificati ma il mirror non è ancora stato scaricato (NTFS li tiene sincronizzati ma c'è una piccola finestra), il mirror tiene lo stato precedente. Questa finestra è breve, millisecondi in funzionamento normale, ma in un caso di guasto improvviso può essere l'unica copia pulita.
Oltre a quei casi, tratta $MFTMirr come qualcosa che raccogli di routine (KAPE lo fa per te) e che raramente hai bisogno di guardare.
Domande frequenti
$MFTMirr è lo stesso di un backup dell'intera MFT?
No. Contiene solo i primi pochi record (i file di metadati di sistema). I file utente non sono mirroreggiati.
Posso parsare $MFTMirr con gli stessi strumenti di $MFT?
Sì. È strutturalmente identico: stesso formato di record, stesso array di fixup, stessi attributi. Trascinalo sul parser nel browser o passalo a MFTECmd.
Posso eliminare o spostare $MFTMirr?
No. Come $MFT, è bloccato mentre Windows è in esecuzione. Disabilitare del tutto il mirror non è un'operazione supportata; chkdsk rifiuterebbe il volume.
Cosa succede se il mio disco non ha $MFTMirr?
Ce l'ha. Ogni volume NTFS ne ha uno, creato al momento della formattazione. Se $MFTMirr manca o è illeggibile, il volume è gravemente danneggiato e chkdsk fallirà.
Letture aggiuntive
- Microsoft, NTFS Reserved Files. Catalogo ufficiale dei file di metadati nei primi 16 record.
- Le note su $MFTMirr del progetto linux-ntfs. Resoconto pratico del ruolo del mirror dal punto di vista di un implementatore di parser.
- Brian Carrier, File System Forensic Analysis. Il capitolo sui file di metadati NTFS spiega il percorso di recupero al momento del mount.