O $MFTMirr é a apólice de seguro mais pequena do NTFS. Espelha os primeiros registos do $MFT para que, quando os bytes no início da tabela principal estão ilegíveis, o driver do sistema de ficheiros ainda tenha uma forma de encontrar todos os ficheiros do volume. É também o artefacto que as pessoas se esquecem de adquirir e depois precisam três semanas mais tarde.
Aqui está o que ele realmente contém, onde está em disco, quando o NTFS o usa, e os (limitados) casos em que se prova útil em forense.
Porque existe sequer um mirror
Os primeiros registos do $MFT são estruturais. O registo 0 é o próprio $MFT, com uma runlist $DATA que diz onde vive o resto da tabela em disco. O registo 2 é o $LogFile. O registo 3 é o $Volume. Se os bytes no início do $MFT estiverem danificados, o NTFS não consegue encontrar nenhum dos outros ficheiros do volume, incluindo o log de transacções que normalmente usaria para recuperar de inconsistências.
Isto é uma dependência circular: precisa do $MFT para encontrar o $LogFile, mas precisa do $LogFile para corrigir o $MFT. O mirror quebra o ciclo. O $MFTMirr é um ficheiro separado num local físico diferente que guarda um duplicado desses primeiros registos. Quando o driver monta um volume, lê o registo 0 do $MFT; se essa leitura falhar ou o fixup array não verificar, recorre ao registo 0 do $MFTMirr e usa o duplicado para reposicionar o resto.
Onde vive
O $MFTMirr é o registo 1 do MFT. O seu atributo $DATA é não residente, e a sua runlist aponta tradicionalmente para o meio do volume de modo a que uma única falha localizada (um sector mau, uma escrita rasgada numa região) não consiga liquidar ambas as cópias. O NTFS moderno coloca-o em LCN clusterCount / 2. Num volume de 500 GB isso põe o mirror na zona dos 250 GB.
Pode encontrá-lo a partir de um sistema em vivo:
fsutil file queryextents C:\$MFTMirr
Isso devolve as cluster runs que o $MFTMirr ocupa, que uma leitura bruta consegue remontar. O target MFT do KAPE recolhe-o por omissão ao lado do $MFT. Se estiver a usar o FTK Imager, está ao lado do $MFT na raiz do volume NTFS.
O que contém
Cópias byte a byte dos primeiros registos do MFT. A garantia histórica eram os primeiros quatro registos (0 a 3, os metadados verdadeiramente essenciais). As versões actuais do Windows espelham os primeiros dezasseis, que é o conjunto completo de metadados NTFS descritos na referência da master file table.
Cada cópia é um registo MFT normal. Mesma assinatura FILE, mesmo cabeçalho, mesmo fixup array, mesmo fluxo de atributos. Um parser apontado ao $MFTMirr percorre-o exactamente como percorre o $MFT. MFTECmd, mft_dump, analyzeMFT e o fls do Sleuth Kit aceitam-no como input.
Como o NTFS o usa na montagem
Numa montagem saudável, o driver não toca no $MFTMirr. Numa montagem danificada:
- Lê o registo 0 do
$MFT. - Se a leitura devolver erro de I/O, ou a verificação de fixup falhar, lê em vez disso o registo 0 do
$MFTMirr. - Se a cópia do registo 0 no mirror for válida, usa a sua runlist
$DATApara localizar o$MFTem disco e prossegue.
O mirror não tem de substituir o $MFT. Apenas precisa de fornecer informação suficiente para encontrar o verdadeiro. Depois de o driver ter localizado o $MFT a partir do ponteiro do mirror, segue com a tabela viva.
Como o chkdsk o usa
O chkdsk é mais agressivo. Quando detecta corrupção nos primeiros registos do $MFT, cruza cada registo com o mirror. Se ambas as cópias forem válidas mas diferirem, o chkdsk trata o mirror como autoritativo para os primeiros registos críticos (a suposição é que os registos vivos foram actualizados mais recentemente e ficaram corrompidos no processo).
Se o $MFT for ilegível e o mirror também for ilegível, o chkdsk reporta Windows cannot recover master file table. CHKDSK aborted. Nesse ponto, a recuperação requer ferramentas offline: carving por assinatura para registos FILE em todo o volume bruto com Sleuth Kit, R-Studio ou testdisk. A auto-reparação interna do NTFS esgotou-se.
Porque o $MFTMirr não é uma cópia de segurança completa
Só espelha os ficheiros de metadados. Os registos 16 em diante, que são todos os ficheiros e directórios de utilizador, existem apenas no $MFT. Se o $MFT estiver danificado para além do registo 16, o mirror não o pode ajudar. O mirror é suficiente para montar o volume; recuperar ficheiros arbitrários de danos requer as mesmas técnicas que usaria sem ele.
Este é o mal-entendido que custa tempo em engagements de IR. As pessoas recorrem ao $MFTMirr pensando que é um snapshot histórico completo. Não é. Para isso, quer Volume Shadow Copies, cada uma contendo uma cópia ponto-no-tempo real do $MFT completo.
Interesse forense
O $MFTMirr raramente é o artefacto principal num caso, mas tem duas utilizações reais:
- Cruzamento. Os registos 0 a 15 no mirror devem coincidir bit a bit com os registos vivos. Uma divergência sugere que um lado foi modificado fora de banda: um bug de driver, adulteração deliberada, recuperação parcial após crash, ou um wiper mal escrito que escreveu por cima do MFT vivo e não percebeu que existia uma cópia noutro lado do volume. Vi exactamente um caso em que o mirror apanhou um wiper que sobrescreveu os primeiros 16 registos do
$MFTe não percebeu que vivia uma cópia noutro sítio do volume. A reconstrução resultou porque o mirror estava intacto. - Snapshot pré-corrupção. Se os registos vivos do
$MFTtiverem sido modificados mas o mirror ainda não tiver sido flushed (o NTFS mantém-nos sincronizados mas há uma pequena janela), o mirror guarda o estado mais antigo. Esta janela é curta, milissegundos em operação normal, mas num caso de falha súbita pode ser a única cópia limpa.
Para além desses casos, trate o $MFTMirr como algo que recolhe por rotina (o KAPE fá-lo por si) e raramente precisa de olhar para ele.
Perguntas frequentes
O $MFTMirr é o mesmo que um backup do MFT inteiro?
Não. Contém apenas os primeiros registos (os ficheiros de metadados do sistema). Os ficheiros de utilizador não são espelhados.
Posso analisar o $MFTMirr com as mesmas ferramentas que uso para o $MFT?
Sim. É estruturalmente idêntico: mesmo formato de registo, mesmo fixup array, mesmos atributos. Largue-o no parser de browser ou dê-o de comer ao MFTECmd.
Posso apagar ou mover o $MFTMirr?
Não. Tal como o $MFT, está bloqueado enquanto o Windows está a correr. Desactivar o mirror inteiramente não é uma operação suportada; o chkdsk recusaria o volume.
O que acontece se o meu disco não tiver $MFTMirr?
Tem. Cada volume NTFS tem um, criado no momento da formatação. Se o $MFTMirr estiver em falta ou ilegível, o volume está severamente danificado e o chkdsk vai falhar.
Leituras adicionais
- Microsoft, NTFS Reserved Files. Catálogo oficial dos ficheiros de metadados nos primeiros 16 registos.
- Notas sobre $MFTMirr do projecto linux-ntfs. Descrição prática do papel do mirror na perspectiva de quem implementa parsers.
- Brian Carrier, File System Forensic Analysis. O capítulo sobre ficheiros de metadados NTFS explica o caminho de recuperação no momento da montagem.