A Master File Table, escrita $MFT no disco, é o índice que o NTFS usa para acompanhar cada arquivo e diretório de um volume. É o primeiro arquivo visível ao usuário em toda partição NTFS, e todos os outros arquivos do volume — inclusive a própria tabela — possuem ao menos uma entrada dentro dela. Ler $MFT é como as ferramentas forenses respondem a perguntas sobre arquivos que o Windows não admite mais existirem: quando foram criados, com que nome, o que continham e quem os tocou por último.
Este guia é uma referência completa. Cobre o que é a tabela, como os registros são estruturados, quais atributos um registro pode carregar, o pequeno conjunto de arquivos de sistema reservados no início da tabela, o que significa de fato "Windows cannot recover the master file table" e como ler $MFT você mesmo com o parser deste site.
O que é a Master File Table?
A Master File Table é um único arquivo chamado $MFT que fica em um local fixo perto do início de cada volume NTFS. O NTFS — New Technology File System — foi introduzido com o Windows NT 3.1 em 1993 e substituiu o FAT como sistema de arquivos padrão do Windows. Diferentemente do FAT, que mantém uma pequena tabela de alocação e armazena nomes de arquivos dentro das entradas de diretório, o NTFS coloca quase todas as informações de metadados de cada arquivo em uma única tabela estruturada: $MFT.
Cada linha dessa tabela é um registro de exatamente 1.024 bytes. Cada registro descreve um arquivo ou um diretório. O registro contém o nome do arquivo, seus carimbos de tempo, suas flags estilo DOS, a lista de clusters de disco onde residem seus dados, descritores de segurança e um punhado de outros atributos — tudo codificado como um pequeno conjunto de campos tipados.
Esse design tem duas grandes consequências:
- Todos os metadados ficam em um só lugar. Uma única busca em
$MFTé suficiente para enumerar todo arquivo do volume. Ferramentas forenses e de recuperação dependem disso; assim como antivírus e serviços de indexação. - Arquivos excluídos deixam metadados intactos para trás. Quando o NTFS exclui um arquivo, ele apaga um bit no cabeçalho do registro e marca os clusters do arquivo como livres. O resto do registro — o nome, os carimbos de tempo, frequentemente os data runs — fica no lugar até que aquele slot de registro seja reutilizado.
O acrônimo MFT significa Master File Table. Você o verá escrito como MFT, $MFT ou a MFT. Todos se referem à mesma estrutura em disco.
Como a $MFT é disposta no disco
Quando o NTFS formata um volume, ele reserva uma região chamada MFT zone perto do início da partição. O boot sector no offset 0 do volume contém um ponteiro (o campo MftStartLcn) para o primeiro cluster de $MFT. Os 16 primeiros registros da tabela são reservados para arquivos de metadados do NTFS (descritos abaixo); o registro 0 é a entrada da própria tabela, apontando de volta para seus próprios clusters.
A $MFT cresce estendendo-se dentro de sua zona reservada sempre que precisa de mais registros. Se o volume enche antes que a zona se esgote, o Windows encolhe a zona para abrir espaço para dados de usuário, motivo pelo qual uma $MFT muito fragmentada é um sintoma comum em sistemas de arquivos envelhecidos.
Um backup dos primeiros registros vive em um segundo arquivo, $MFTMirr, geralmente colocado no meio do volume. Se a própria $MFT está corrompida, o NTFS usa $MFTMirr para iniciar a recuperação — esse é o mecanismo por trás do erro "Windows cannot recover the master file table" descrito mais adiante.
Anatomia de um registro FILE
Todo registro MFT começa com a assinatura ASCII de quatro bytes FILE. (Registros corrompidos usam BAAD no lugar — uma lápide deliberadamente escrita pelo chkdsk.) Após a assinatura vem um cabeçalho fixo, seguido por um fluxo de atributos de tamanho variável.
O cabeçalho do registro carrega:
- Assinatura —
FILEpara um registro válido,BAADpara um registro que ochkdsknão conseguiu reparar. - Update sequence number (USN) e fixup array — um pequeno truque de checksum que permite ao NTFS detectar gravações interrompidas. Os dois últimos bytes de cada bloco de 512 bytes do registro são substituídos pelo USN; os originais ficam guardados no fixup array. Na leitura, o NTFS verifica o USN e restaura os bytes originais.
- Log sequence number — um ponteiro para
$LogFilepara recuperação após falha. - Número de sequência — incrementado toda vez que o registro é reutilizado. Combinado com o número do registro, forma uma referência de arquivo de 64 bits que identifica unicamente uma encarnação específica de um arquivo.
- Contador de hard links — número de atributos
$FILE_NAMEapontando para o registro. - Flags — a mais importante é o bit 0,
IN_USE. Zero significa excluído. - Referência ao registro base — diferente de zero em registros de extensão que pertencem a um registro base em outro lugar da tabela.
Depois do cabeçalho vêm os atributos. Cada atributo tem seu próprio cabeçalho curto (tipo, comprimento, flag residente/não residente, nome se houver) seguido pelos dados. Não há ordem fixa, mas $STANDARD_INFORMATION é convencionalmente o primeiro e $DATA o último.
Um registro que fica sem espaço — fragmentos demais, ADS demais, um nome incomumente longo — ganha um atributo $ATTRIBUTE_LIST que aponta para um ou mais registros de extensão em outro lugar da tabela. Os parsers precisam seguir a cadeia para montar o arquivo completo.
Atributos de arquivo armazenados na $MFT
Esta é a busca mais comum por trás da palavra-chave "quais atributos de arquivo são armazenados na master file table". A lista completa dos tipos de atributos do NTFS, com códigos em hex:
| Tipo | Hex | Finalidade |
|------|-----|------------|
| $STANDARD_INFORMATION | 0x10 | Quatro carimbos de tempo (criação, modificação, acesso, modificação MFT), flags DOS, ID do proprietário, ID de segurança, USN. |
| $ATTRIBUTE_LIST | 0x20 | Ponteiro para registros de extensão quando os atributos de um arquivo transbordam de um único registro. |
| $FILE_NAME | 0x30 | Um nome de arquivo, referência ao diretório pai, tamanho alocado e real, e um segundo conjunto de quatro carimbos de tempo. Um arquivo pode ter vários — um por hard link, um para o nome curto 8.3. |
| $OBJECT_ID | 0x40 | Identificador de objeto de 128 bits usado pelo serviço Distributed Link Tracking. |
| $SECURITY_DESCRIPTOR | 0x50 | ACL por arquivo (legado). O NTFS moderno armazena as ACLs centralmente em $Secure e as referencia por ID a partir de $STANDARD_INFORMATION. |
| $VOLUME_NAME | 0x60 | Somente no registro 3 ($Volume). Contém o rótulo do volume. |
| $VOLUME_INFORMATION | 0x70 | Versão do NTFS, flag dirty. |
| $DATA | 0x80 | O conteúdo do arquivo. Residente para arquivos muito pequenos; não residente (uma lista de cluster runs) caso contrário. Um arquivo pode carregar vários $DATA — o sem nome é o fluxo principal, os nomeados são fluxos de dados alternativos. |
| $INDEX_ROOT | 0x90 | Raiz de uma árvore B+. Usado por diretórios ($I30), índices de reparse point e outras estruturas indexadas. |
| $INDEX_ALLOCATION | 0xA0 | Continuação não residente de um índice grande. |
| $BITMAP | 0xB0 | Bitmap de alocação para a própria $MFT ou para diretórios grandes. |
| $REPARSE_POINT | 0xC0 | Symlinks, junctions, pontos de montagem, placeholders do OneDrive. |
| $EA_INFORMATION / $EA | 0xD0 / 0xE0 | Atributos estendidos da era OS/2. Raros no Windows moderno. |
| $LOGGED_UTILITY_STREAM | 0x100 | Metadados de criptografia EFS ($EFS), dados transacionais TxF. |
Um registro sempre carrega no mínimo $STANDARD_INFORMATION, um $FILE_NAME e um $DATA. Todo o resto é opcional e ligado a funcionalidades específicas.
Dados residentes vs não residentes
A maioria dos atributos $DATA em um volume real é não residente: o cabeçalho do atributo carrega uma lista compacta de cluster runs (um LCN inicial mais um comprimento, repetidos), e os bytes do arquivo vivem em outro lugar do disco. O cabeçalho do atributo em si é pequeno.
Se o arquivo for pequeno o bastante — tipicamente abaixo de ~700 bytes depois de contabilizados os outros atributos — o NTFS armazena os bytes inline dentro do registro. Esses são dados residentes, e é um dos artefatos mais úteis no trabalho forense: o conteúdo de um pequeno arquivo de texto excluído há semanas pode ainda estar, byte por byte, dentro de um registro $MFT desalocado. Veja resident-data para um olhar mais profundo.
Arquivos de metadados do NTFS nos dezesseis primeiros registros
Os 16 primeiros registros de $MFT são reservados para os arquivos de controle interno do próprio NTFS. Eles começam com $ para não colidir com nomes de arquivos de usuário. Os que vale conhecer:
| Reg. # | Arquivo | O que é |
|--------|---------|---------|
| 0 | $MFT | A própria tabela. |
| 1 | $MFTMirr | Backup dos primeiros registros de $MFT. |
| 2 | $LogFile | Log de transações usado para desfazer ou refazer operações incompletas após uma falha. |
| 3 | $Volume | Rótulo do volume e flag dirty. |
| 4 | $AttrDef | Esquema dos tipos de atributo válidos. |
| 5 | . | O diretório raiz. |
| 6 | $Bitmap | Um bit por cluster do volume; rastreia a alocação. |
| 7 | $Boot | Cópia do boot sector. |
| 8 | $BadClus | Arquivo esparso cujos runs apontam para todo cluster que o sistema marcou como defeituoso. |
| 9 | $Secure | Armazenamento central de descritores de segurança. |
| 10 | $UpCase | Tabela Unicode de mapeamento para maiúsculas usada para comparação de nomes insensível a maiúsculas/minúsculas. |
| 11 | $Extend | Diretório contendo os arquivos de sistema mais recentes: $ObjId, $Quota, $Reparse, $UsnJrnl, $RmMetadata. |
O journal de mudanças $UsnJrnl (sob $Extend) é especialmente útil em forense — registra cada mudança de metadados no volume e complementa $MFT para reconstrução de linha do tempo. Veja usn-journal.
Quando a $MFT dá errado: corrupção e "Windows cannot recover the master file table"
A mensagem de erro "Windows cannot recover master file table. CHKDSK aborted" aparece quando o chkdsk não consegue ler $MFT e também não consegue recorrer a $MFTMirr. Quando você vê essa mensagem, o NTFS já tentou e falhou em seu autorreparo interno.
Causas raízes comuns:
- Mídia física falhando. Setores defeituosos na MFT zone fazem a leitura retornar dados corrompidos. Os dados SMART normalmente corroboram.
- Queda de energia súbita durante uma operação intensa em metadados. O log de transações normalmente reverte essas operações, mas um
$LogFilecorrompido derrota o rollback. - Corrupção em nível de driver ou filtro. Pilhas de criptografia de disco mal comportadas, minifilters de sistema de arquivos ou drivers de armazenamento com bugs podem escrever registros inconsistentes.
- Sobrescrições maliciosas. Wipers e algumas famílias de ransomware rabiscam deliberadamente em
$MFTpara tornar o volume mais difícil de recuperar.
A resposta forenseticamente correta é:
- Pare imediatamente de escrever no volume. Cada gravação adicional reduz a chance de recuperação.
- Faça uma imagem do disco com FTK Imager,
ddouddrescuepara um destino confiável. Verifique o hash. - Trabalhe na imagem, não no original. Tente
testdisk,R-Studioou uma análise manual que encontre registrosFILEescaneando assinaturas diretamente no volume — mesmo que o ponteiro em disco para$MFTtenha sumido, os próprios registros geralmente ainda são reconhecíveis. - Se o objetivo é colocar o volume de volta em operação em vez de recuperar dados, só então rode
chkdsk /fna imagem.
chkdsk /b em um volume gravável pode limpar marcadores de clusters defeituosos, mas também pode descartar registros que ele não entende. Rode no original somente depois de ter uma imagem e de ter decidido que a disponibilidade vence a fidelidade forense.
Como ler a $MFT
Você tem três opções realistas:
- MFTECmd (Eric Zimmerman) — uma CLI para Windows que produz CSV no layout compatível com bodyfile esperado pela maioria das ferramentas de linha do tempo. O padrão de facto para os responsáveis por resposta a incidentes.
omerbenamram/mft— um crate Rust e CLI. O mesmo parser que este site usa, útil quando você quer automatizar a análise via script ou embarcá-la em um pipeline maior.- O parser navegador deste site — solte
$MFTna página inicial e ele roda o mesmo parser Rust, compilado para WebAssembly, totalmente no seu navegador. Nada é enviado. Útil quando você quer uma leitura rápida sem instalar nada, ou quando a política proíbe enviar evidências para um serviço em nuvem.
Se você precisa de uma comparação dos três com prós e contras concretos, veja mft-parser-tools. Para fluxos práticos que se apoiam em uma $MFT analisada, veja build-mft-timeline, deleted-files e extracting-mft.
Perguntas frequentes
O que significa MFT?
MFT significa Master File Table. Também é escrita como $MFT no disco porque, no NTFS, o cifrão prefixa os nomes dos arquivos de metadados.
Para que serve a master file table?
É o índice que o NTFS usa para encontrar todo arquivo e diretório de um volume. Cada entrada armazena o nome do arquivo, seus carimbos de tempo, suas informações de segurança, seus atributos e a localização de seus dados no disco.
Quais atributos de arquivo são armazenados na master file table?
No mínimo, cada registro carrega $STANDARD_INFORMATION (carimbos de tempo, flags DOS), $FILE_NAME (nome e um segundo conjunto de carimbos de tempo) e $DATA (o conteúdo do arquivo ou um ponteiro para ele). Os registros também podem carregar $ATTRIBUTE_LIST, $OBJECT_ID, $SECURITY_DESCRIPTOR, $INDEX_ROOT, $INDEX_ALLOCATION, $BITMAP, $REPARSE_POINT, $EA e $LOGGED_UTILITY_STREAM, conforme o arquivo. A referência completa está na tabela de atributos acima.
Qual o tamanho da master file table?
Cada registro tem 1.024 bytes. A tabela reserva cerca de 12,5% do volume por padrão (a MFT zone) mas só consome o espaço realmente necessário. Um volume com um milhão de arquivos tem cerca de 1 GB de $MFT.
$MFT é o mesmo que $MFTMirr?
Não. $MFTMirr é um backup parcial dos primeiros registros de $MFT, colocado em outro lugar no disco para que o NTFS possa iniciar a recuperação se o cabeçalho da tabela principal estiver corrompido.
Como conserto uma master file table corrompida?
Faça uma imagem do disco primeiro. Depois, rode chkdsk /f contra a imagem (rápido, pode descartar registros) ou use uma ferramenta de recuperação capaz de escanear por assinaturas FILE e remontar a tabela a partir dos clusters brutos (lento, preserva mais evidências). Nunca rode chkdsk contra o volume original antes da imagem.
Posso ler $MFT no Linux ou macOS?
Sim. $MFT é só um arquivo. Qualquer parser que aceite um dump bruto de $MFT funciona em qualquer SO — omerbenamram/mft, analyzeMFT, a ferramenta navegador deste site. Você só precisa de Windows para extrair o arquivo de um volume montado ao vivo.