La Master File Table, scritta $MFT sul disco, è l'indice che NTFS usa per tenere traccia di ogni file e cartella di un volume. È il primo file utente visibile di ogni partizione NTFS, e tutti gli altri file del volume — compresa la tabella stessa — vi possiedono almeno un'entrata. Leggere $MFT è il modo in cui gli strumenti forensi rispondono a domande su file di cui Windows non riconosce più l'esistenza: quando sono stati creati, con quale nome, quale contenuto avevano e chi li ha toccati per ultimo.
Questa guida è un riferimento completo. Copre cos'è la tabella, come è disposto un record, quali attributi può portare, il piccolo insieme di file di sistema riservati all'inizio della tabella, cosa significa davvero «Windows non riesce a recuperare la master file table», e come leggere $MFT da soli con il parser di questo sito.
Cos'è la Master File Table?
La Master File Table è un singolo file chiamato $MFT situato in una posizione fissa vicino all'inizio di ogni volume NTFS. NTFS — New Technology File System — è stato introdotto con Windows NT 3.1 nel 1993 e ha sostituito FAT come file system predefinito di Windows. A differenza di FAT, che mantiene una piccola tabella di allocazione e memorizza i nomi dei file nelle voci di directory, NTFS raccoglie quasi tutti i metadati di ogni file in un'unica tabella strutturata: $MFT.
Ogni riga di quella tabella è un record di esattamente 1.024 byte. Ogni record descrive un file o una cartella. Il record contiene il nome del file, i suoi timestamp, i flag in stile DOS, l'elenco dei cluster del disco dove vivono i suoi dati, i descrittori di sicurezza e una manciata di altri attributi — il tutto codificato come un piccolo insieme di campi tipizzati.
Questo design ha due grandi conseguenze:
- Tutti i metadati sono in un unico posto. Una sola ricerca in
$MFTbasta a enumerare ogni file del volume. Strumenti forensi e di recupero ne dipendono; lo stesso vale per gli antivirus e i servizi di indicizzazione. - I file eliminati lasciano dietro metadati intatti. Quando NTFS elimina un file, azzera un bit nell'header del record e marca i cluster del file come liberi. Il resto del record — il nome, i timestamp, spesso i data run — rimane in posizione finché quella slot non viene riutilizzata.
L'acronimo MFT significa Master File Table. Lo vedrete scritto MFT, $MFT, o la MFT. Tutti rinviano alla stessa struttura su disco.
Come $MFT è disposta sul disco
Quando NTFS formatta un volume riserva una regione chiamata MFT zone vicino all'inizio della partizione. Il boot sector all'offset 0 del volume contiene un puntatore (il campo MftStartLcn) al primo cluster di $MFT. I primi 16 record della tabella sono riservati ai file di sistema NTFS (descritti più avanti); il record 0 è l'entrata della tabella stessa, che punta ai propri cluster.
$MFT cresce estendendosi nella sua zona riservata ogni volta che ha bisogno di più record. Se il volume si riempie prima che la zona sia esaurita, Windows riduce la zona per fare spazio ai dati utente, ed è per questo che una $MFT molto frammentata è un sintomo comune sui file system invecchiati.
Una copia di backup dei primi record vive in un secondo file, $MFTMirr, generalmente posizionato al centro del volume. Se $MFT stessa è corrotta, NTFS usa $MFTMirr per avviare il recupero — è il meccanismo dietro l'errore «Windows non riesce a recuperare la master file table» descritto più avanti.
Anatomia di un record FILE
Ogni record MFT inizia con la signature ASCII FILE su quattro byte. (I record corrotti usano BAAD al loro posto — una lapide deliberatamente scritta da chkdsk.) Dopo la signature viene un header fisso, seguito da un flusso di attributi a lunghezza variabile.
L'header del record contiene:
- Signature —
FILEper un record valido,BAADper un record chechkdsknon ha potuto riparare. - Update sequence number (USN) e fixup array — un piccolo trucco di checksum che permette a NTFS di rilevare scritture interrotte. Gli ultimi due byte di ogni blocco da 512 byte del record sono sostituiti con l'USN; gli originali sono riposti nel fixup array. In lettura, NTFS verifica l'USN e ripristina i byte originali.
- Log sequence number — puntatore in
$LogFileper il recupero dopo un crash. - Sequence number — incrementato ogni volta che il record viene riutilizzato. Combinato con il numero di record, forma una file reference a 64 bit che identifica univocamente una specifica incarnazione di un file.
- Contatore hard link — numero di attributi
$FILE_NAMEche puntano al record. - Flag — il più importante è il bit 0,
IN_USE. A zero significa eliminato. - Base file record reference — non nullo sui record di estensione che appartengono a un record di base situato altrove nella tabella.
Dopo l'header vengono gli attributi. Ogni attributo ha il proprio piccolo header (tipo, lunghezza, flag resident/non-resident, nome se presente) seguito dai dati. Non c'è un ordine fisso, ma $STANDARD_INFORMATION è convenzionalmente per primo e $DATA per ultimo.
Un record che esaurisce lo spazio — troppi frammenti, troppi ADS, un nome insolitamente lungo — fa spuntare un attributo $ATTRIBUTE_LIST che punta a uno o più record di estensione altrove nella tabella. I parser devono seguire la catena per assemblare il file completo.
Attributi di file memorizzati in $MFT
Questa è la ricerca più comune dietro la parola chiave «quali attributi di file sono memorizzati nella master file table». L'elenco completo dei tipi di attributo NTFS, con i codici esadecimali:
| Tipo | Hex | Scopo |
|------|-----|-------|
| $STANDARD_INFORMATION | 0x10 | Quattro timestamp (creazione, modifica, accesso, modifica MFT), flag DOS, ID proprietario, ID di sicurezza, USN. |
| $ATTRIBUTE_LIST | 0x20 | Puntatore ai record di estensione quando gli attributi di un file traboccano da un singolo record. |
| $FILE_NAME | 0x30 | Un nome file, una reference alla directory genitore, dimensione allocata e reale, e un secondo set di quattro timestamp. Un file può averne diversi — uno per hard link, uno per il nome corto 8.3. |
| $OBJECT_ID | 0x40 | Identificatore di oggetto a 128 bit usato dal servizio Distributed Link Tracking. |
| $SECURITY_DESCRIPTOR | 0x50 | ACL per file (legacy). NTFS moderno memorizza le ACL centralmente in $Secure e le referenzia per ID da $STANDARD_INFORMATION. |
| $VOLUME_NAME | 0x60 | Solo sul record 3 ($Volume). Contiene l'etichetta del volume. |
| $VOLUME_INFORMATION | 0x70 | Versione NTFS, flag dirty. |
| $DATA | 0x80 | Il contenuto del file. Resident per file molto piccoli; non-resident (una lista di cluster runs) altrimenti. Un file può portare diversi $DATA — quello senza nome è il flusso principale, quelli con nome sono flussi di dati alternativi. |
| $INDEX_ROOT | 0x90 | Radice di un albero B+. Usato dalle directory ($I30), dagli indici dei reparse point e da altre strutture indicizzate. |
| $INDEX_ALLOCATION | 0xA0 | Continuazione non-resident di un grande indice. |
| $BITMAP | 0xB0 | Bitmap di allocazione per $MFT stessa o per grandi directory. |
| $REPARSE_POINT | 0xC0 | Symlink, junction, mount point, placeholder OneDrive. |
| $EA_INFORMATION / $EA | 0xD0 / 0xE0 | Attributi estesi dell'era OS/2. Rari su Windows moderno. |
| $LOGGED_UTILITY_STREAM | 0x100 | Metadati di cifratura EFS ($EFS), dati transazionali TxF. |
Un record porta sempre almeno $STANDARD_INFORMATION, un $FILE_NAME e un $DATA. Tutto il resto è opzionale e legato a funzionalità specifiche.
Dati resident vs non-resident
La maggior parte degli attributi $DATA su un volume reale sono non-resident: l'header dell'attributo contiene un elenco compatto di cluster runs (un LCN di partenza e una lunghezza, ripetuti), e i byte del file vivono altrove sul disco. L'header dell'attributo è di per sé piccolo.
Se il file è abbastanza piccolo — tipicamente sotto i ~700 byte dopo aver contabilizzato gli altri attributi — NTFS memorizza i byte inline dentro il record. Sono dati resident, ed è uno degli artefatti più utili nel lavoro forense: il contenuto di un piccolo file di testo eliminato settimane fa può ancora trovarsi, byte per byte, dentro un record $MFT non allocato. Vedi resident-data per un approfondimento.
File di metadati NTFS nei primi sedici record
I primi 16 record di $MFT sono riservati ai file di gestione interna di NTFS. Iniziano con un $ per non entrare in conflitto con i nomi di file utente. Quelli da conoscere:
| Rec n. | File | Cos'è |
|--------|------|-------|
| 0 | $MFT | La tabella stessa. |
| 1 | $MFTMirr | Backup dei primi record di $MFT. |
| 2 | $LogFile | Log di transazioni usato per annullare o rieseguire operazioni incomplete dopo un crash. |
| 3 | $Volume | Etichetta del volume e flag dirty. |
| 4 | $AttrDef | Schema dei tipi di attributo validi. |
| 5 | . | La directory radice. |
| 6 | $Bitmap | Un bit per cluster del volume; traccia l'allocazione. |
| 7 | $Boot | Copia del boot sector. |
| 8 | $BadClus | File sparse i cui run puntano a ogni cluster che il file system ha marcato come difettoso. |
| 9 | $Secure | Magazzino centrale dei descrittori di sicurezza. |
| 10 | $UpCase | Tabella di mapping Unicode in maiuscolo usata per il confronto di nomi case-insensitive. |
| 11 | $Extend | Directory contenente i file di sistema più recenti: $ObjId, $Quota, $Reparse, $UsnJrnl, $RmMetadata. |
Il change journal $UsnJrnl (sotto $Extend) è particolarmente utile in forensica — registra ogni modifica di metadati sul volume e complementa $MFT per la ricostruzione delle timeline. Vedi usn-journal.
Quando $MFT va male: corruzione e «Windows non riesce a recuperare la master file table»
Il messaggio di errore «Windows non riesce a recuperare la master file table. CHKDSK interrotto» appare quando chkdsk non riesce a leggere $MFT e non può nemmeno ripiegare su $MFTMirr. Quando vedete questo messaggio, NTFS ha già provato e fallito nella propria autoriparazione.
Cause comuni:
- Supporto fisico in avaria. Settori difettosi nella MFT zone fanno restituire dati spazzatura alla lettura. I dati SMART di solito corroborano.
- Interruzione improvvisa di alimentazione durante un'operazione pesante sui metadati. Il log delle transazioni normalmente effettua il rollback, ma un
$LogFilecorrotto manderà in fallimento il meccanismo. - Corruzione a livello driver o filtro. Stack di cifratura disco mal scritti, minifiltri del file system o driver di archiviazione buggati possono scrivere record incoerenti.
- Sovrascritture malevole. Wiper e alcune famiglie di ransomware scarabocchiano deliberatamente su
$MFTper rendere il volume più difficile da recuperare.
La risposta corretta dal punto di vista forense è:
- Smettere immediatamente di scrivere sul volume. Ogni ulteriore scrittura riduce le possibilità di recupero.
- Imager il disco con FTK Imager,
ddoddrescueverso una destinazione integra. Verificare l'hash. - Lavorare sull'immagine, non sull'originale. Provare
testdisk,R-Studio, o un'analisi manuale che trovi i recordFILEscansionando il volume per signature — anche se il puntatore su disco verso$MFTè scomparso, i record in sé sono di solito ancora riconoscibili. - Se l'obiettivo è rimettere online il volume invece di recuperare dati, solo allora eseguire
chkdsk /fsull'immagine.
chkdsk /b su un volume scrivibile può cancellare i marker di cluster difettosi, ma può anche scartare record che non comprende. Eseguitelo sull'originale solo dopo aver ottenuto un'immagine e dopo aver deciso che la disponibilità prevale sulla fedeltà forense.
Come leggere $MFT
Avete tre opzioni realistiche:
- MFTECmd (Eric Zimmerman) — un CLI Windows che produce CSV nel layout body-file atteso dalla maggior parte degli strumenti di timeline. Lo standard di fatto per chi risponde a incidenti.
omerbenamram/mft— un crate Rust e un CLI. Lo stesso parser usato da questo sito, utile quando volete scriptare un'analisi o integrarla in un pipeline più ampio.- Il parser nel browser di questo sito — trascinate
$MFTsulla homepage e lo stesso parser Rust, compilato in WebAssembly, gira interamente nel vostro browser. Niente viene caricato. Utile quando volete una lettura rapida senza installare nulla, o quando le policy vietano di inviare prove a un servizio cloud.
Per un confronto concreto dei tre, vedi mft-parser-tools. Per flussi di lavoro pratici basati su una $MFT analizzata, vedi build-mft-timeline, deleted-files ed extracting-mft.
Domande frequenti
Cosa significa MFT?
MFT significa Master File Table. La si scrive anche $MFT su disco perché, in NTFS, il segno dollaro prefissa i nomi dei file di metadati.
A cosa serve la master file table?
È l'indice che NTFS usa per trovare ogni file e cartella di un volume. Ogni entrata memorizza il nome del file, i suoi timestamp, le informazioni di sicurezza, gli attributi e la posizione dei suoi dati sul disco.
Quali attributi di file sono memorizzati nella master file table?
Come minimo ogni record contiene $STANDARD_INFORMATION (timestamp, flag DOS), $FILE_NAME (nome e un secondo set di timestamp) e $DATA (il contenuto del file o un puntatore a esso). I record possono anche contenere $ATTRIBUTE_LIST, $OBJECT_ID, $SECURITY_DESCRIPTOR, $INDEX_ROOT, $INDEX_ALLOCATION, $BITMAP, $REPARSE_POINT, $EA e $LOGGED_UTILITY_STREAM a seconda del file. Il riferimento completo è nella tabella degli attributi sopra.
Quanto è grande la master file table?
Ogni record è di 1.024 byte. La tabella riserva circa il 12,5% del volume per impostazione predefinita (la MFT zone) ma consuma solo lo spazio effettivamente necessario. Un volume con un milione di file ha una $MFT di circa 1 GB.
$MFT è uguale a $MFTMirr?
No. $MFTMirr è un backup parziale dei primi record di $MFT, posizionato altrove sul disco in modo che NTFS possa avviare il recupero se l'header della tabella principale è corrotto.
Come riparo una master file table corrotta?
Imager prima il disco. Poi eseguire chkdsk /f sull'immagine (veloce, può scartare record), oppure usare uno strumento di recupero capace di scansionare le signature FILE e ricostruire la tabella dai cluster grezzi (lento, preserva più prove). Non eseguire mai chkdsk sul volume originale prima dell'imaging.
Posso leggere $MFT su Linux o macOS?
Sì. $MFT è solo un file. Qualsiasi parser che accetti un dump grezzo di $MFT funziona su qualsiasi OS — omerbenamram/mft, analyzeMFT, lo strumento browser di questo sito. Avete bisogno di Windows solo per estrarre il file da un volume montato in modo attivo.