Metadados do NTFS após a formatação rápida: uma análise com o WinHex
Os metadados NTFS após uma formatação rápida descrevem um sistema de arquivos recém-inicializado, embora alguns registros e conteúdos de arquivos do sistema de arquivos anterior possam permanecer legíveis por baixo dele. O Windows cria uma nova Tabela Mestre de Arquivos e uma nova estrutura de diretórios; ele não se limita a ocultar todos os nomes de arquivos antigos. A recuperação é bem-sucedida quando metadados originais suficientes e os dados que eles descrevem sobrevivem e permanecem acessíveis.
O WinHex ajuda a distinguir essas condições ao exibir os campos do setor de inicialização, os registros da MFT e os mapeamentos de sequências de dados. Este artigo analisa um caso de formatação rápida de NTFS para NTFS e um exemplo separado de reconstrução de fragmentos da MFT. Os cálculos se aplicam aos layouts registrados, e não a todos os volumes do Windows. O comportamento de descarte do SSD e as gravações subsequentes podem produzir resultados muito diferentes.
Índice
1. Quais são as mudanças na formatação rápida no NTFS
O Sistema de arquivos NTFS organiza os arquivos por meio de arquivos de metadados, índices de diretórios e mapeamentos de clusters. Uma formatação rápida cria uma nova instância dessas estruturas.
Estrutura | Função após a formatação rápida | Consequência para a recuperação |
Setor de inicialização do volume e seu backup | Descreva o volume recém-formatado | Os ponteiros MFT atuais podem não conseguir mais localizar a tabela antiga |
$MFT e diretório raiz | Descreva o novo sistema de arquivos e seus objetos iniciais | Os nomes antigos dos arquivos e as relações entre diretórios desaparecem durante a navegação normal |
| Rastreia os registros alocados na nova MFT | Não inclui registros remanescentes fora dessa tabela |
$Bitmap | Rastreia os clusters alocados no novo volume | Agrupamentos anteriormente ocupados podem ficar disponíveis para reutilização |
$MFTMirr e outros metadados do sistema | Oferecer suporte ao sistema de arquivos recém-inicializado | As gravações podem sobrescrever metadados ou conteúdos de arquivos mais antigos |
Locais anteriores dos arquivos | Pode conter conteúdo legível fora dos intervalos sobrescritos ou descartados | É preciso verificar a sobrevivência, em vez de simplesmente presumir que ela exista |
O Tabela do arquivo mestre é, por si só, um arquivo. Seu fluxo $DATA, sem nome, contém registros de arquivos; seu bitmap descreve a alocação desses registros. O arquivo $Bitmap, separado, descreve a alocação de clusters em todo o volume. Confundir esses dois bitmaps leva a conclusões incorretas sobre o que foi preservado.
A formatação de uma partição existente também difere da exclusão de sua entrada na tabela de partições. Uma formatação de volume reconstrói o sistema de arquivos dentro do volume selecionado; a exclusão da partição diz respeito ao layout do disco fora dele.
2. Ler o setor de inicialização original no WinHex
Para realizar uma comparação hexadecimal “antes e depois” de uma formatação NTFS, salve uma imagem do setor antes da formatação e compare-a com uma imagem capturada posteriormente. Em uma fonte já formatada, trabalhe a partir de uma imagem e de quaisquer capturas anteriores disponíveis. Não repita a formatação para reproduzir o evento.
O registro de inicialização do volume fornece os parâmetros necessários para interpretar os endereços dos clusters.
Trecho hexadecimal original do setor de inicialização, extraído do registro do caso no WinHex. As caixas vermelhas identificam os campos de tamanho do setor, tamanho do cluster e localização na MFT.
Deslocamento do setor de inicialização | Bytes registrados | Interpretação |
|
| 512 bytes por setor lógico |
|
| Oito setores por grupo |
|
| $MFT começa no LCN 175.724.968 |
|
| $MFTMirr começa no LCN 167.336.228 |
|
| Valor assinado −10: o tamanho do registro é 2¹⁰ = 1.024 bytes |
Os inteiros multibyte utilizam a ordem de bytes little-endian. O tamanho da unidade de alocação é, portanto:
- 512 × 8 = 4.096 bytes por cluster
LCN significa um número de cluster relativo ao volume. Consequentemente:
- Setor relativo ao volume original do MFT = 175.724.968 × 8
- = 1,405,799,744
- Deslocamento em bytes relativo ao volume do MFT original = 175.724.968 × 4.096
- = 719,769,468,928
Ao examinar uma imagem do disco inteiro, some o deslocamento inicial em bytes do volume. Ao examinar uma imagem apenas do volume, não some esse valor novamente. O contexto de endereçamento exibido pelo WinHex deve corresponder ao cálculo.
O setor de inicialização identifica a primeira extensão da MFT. Ele não descreve todos os fragmentos da tabela.
3. Decodificar os dados de não residentes da MFT original
No local original do MFT, valide o registro 0 e localize seu atributo $DATA sem nome; digite 0x80. Um atributo não residente armazena informações de mapeamento, em vez de todo o seu conteúdo, dentro do registro.
As notas do caso indicam que esse atributo está localizado no deslocamento do registro 0x100. Isso faz com que seu byte de forma apareça em 0x108; o valor 01 significa “não residente”. Esses deslocamentos absolutos pertencem a este registro. Outros registros podem posicionar o atributo em outro local.
Ao interpretar outro registro, utilize deslocamentos relativos ao início do atributo:
Deslocamento relativo | Campo |
| Formulário para residentes/não residentes |
| Número do cluster virtual mais baixo, ou VCN |
| VCN mais alto, inclusive |
| Deslocamento na matriz de pares de mapeamento |
| Comprimento alocado |
| Tamanho lógico do arquivo |
| Comprimento válido dos dados |
Leia os três campos de tamanho separadamente. O comprimento alocado reserva espaço de armazenamento, o tamanho lógico define o comprimento do fluxo e o comprimento dos dados válidos descreve os dados inicializados. Eles não precisam ser iguais.
Para um intervalo que abrange os VCNs de 0 a 98.431, o número de clusters é 98.432, e não 98.431. O layout de duas execuções registrado resulta em:
Executar | Contagem de agrupamentos | Assinado: LCN delta | Iniciando o LCN | Espaços para registros lógicos de 1.024 bytes cada |
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 |
O segundo endereço é relativo à execução anterior começando LCN:
- 175,724,968 + 83,118,309 = 258,843,277
- (75.096 + 23.336) × 4.096 = 403.177.472 bytes
- 403.177.472 ÷ 1.024 = 393.728 espaços para registros
Esses são slots endereçáveis, e não uma contagem de arquivos ativos. Alguns registros podem estar ociosos, e um arquivo pode exigir vários registros.
Os cabeçalhos das execuções registradas 43 e 42 descrever as larguras dos campos. Para 43, o comprimento ocupa três bytes e o delta do LCN, quatro; para 42, o comprimento ocupa dois bytes e o delta, quatro. Interprete o delta do LCN como um valor com sinal, pois fragmentos posteriores podem estar localizados em posições anteriores no volume.
O comprimento da extensão resultante é de 384,5 MiB. A exibição arredondada de “385 MB” não permite, por si só, determinar um tamanho de alocação diferente nem comprovar que foram reservados clusters adicionais.
4. Compare o novo MFT com o layout antigo
As anotações do caso registram um MFT pós-formatação que começa no LCN 786.432, com uma extensão de 180 clusters. Supondo o tamanho de cluster registrado de 4.096 bytes:
- Novo deslocamento do byte inicial do MFT = 786.432 × 4.096
- = 3,221,225,472
- Novo tamanho da extensão = 180 × 4.096 = 737.280 bytes
O novo ponto inicial fica a 3 GiB do início do volume. Esse endereço é uma observação feita neste caso específico, não uma localização obrigatória no sistema de arquivos NTFS.
Imóvel | Layout original | Layout pós-formatação registrado nas notas |
Iniciando o MFT LCN | 175,724,968 | 786,432 |
Extensões MFT registradas | Dois | Um |
Cobertura de extensão | 98.432 agrupamentos | 180 agrupamentos |
Capacidade com o tamanho de registro registrado | 393.728 vagas | 720 vagas |
As notas também mencionam os registros 0–717. Isso equivale a 718 registros, ou 735.232 bytes. É compatível com uma alocação grande o suficiente para 720 slots, mas não esclarece se o número 718 se refere ao comprimento lógico, ao comprimento inicializado ou ao número de registros inspecionados. Esses campos exigem os bytes de atributos subjacentes.
A mudança importante é que o Windows agora segue a nova tabela. O tamanho menor da nova MFT faz com que não significa que a tabela antiga foi fisicamente truncada no próprio local. Seus locais anteriores devem ser inspecionados separadamente.
Para determinar se a MFT do NTFS foi sobrescrita durante a formatação, compare as extensões originais da MFT com todas as novas gravações de metadados e alocações posteriores. Um ponteiro alterado comprova uma referência alterada; uma comparação de bytes confirma a sobrescrita em um local específico. A simples realocação, por si só, não comprova nem a sobrevivência completa nem a perda total.
5. Reconstruir uma MFT fragmentada a partir dos registros remanescentes
A fragmentação da MFT ocorre à medida que a tabela cresce e o espaço contíguo se esgota. O NTFS reserva uma zona da MFT para reduzir a fragmentação, mas isso não garante uma única extensão. O crescimento pode alocar fragmentos antes ou depois da extensão atual.
Um exemplo de reconstrução separado, no material do caso, ilustra esse layout de três etapas. Ele não deve ser combinado com o caso anterior de duas etapas, como se ambos descrevessem a mesma tabela.
Executar | Espaços para registros lógicos | Iniciando o LCN | Diferença em relação ao início da execução anterior | Clusters |
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 |
Cada cluster de 4.096 bytes comporta quatro slots de 1.024 bytes. Isso explica ambos os limites:
- 51.232 × 4 = 204.928 vagas
- 204.928 + (10.915 × 4) = 248.588
- 9.274.281 − 416.173 = 8.858.108
No total, as execuções abrangem 94.098 clusters, ou 385.425.408 bytes. O VCN final é 94.097.
Localizar e validar registros de candidatos
As notas de reconstrução descrevem a busca pelo registro 204.928, a rejeição de um candidato por ser inválido e a localização de outro candidato aceito como válido. Um número correspondente ou o ARQUIVO A assinatura por si só não é suficiente.
Em uma imagem somente leitura:
- Procurar por
ARQUIVOassinaturas, incluindo localizações fora do MFT atual. Uma varredura restrita à nova tabela não detectará registros separados. - Verifique os limites dos registros, o comprimento dos registros, os deslocamentos dos atributos e os comprimentos dos atributos.
- Valide a matriz da sequência de atualização antes de interpretar os bytes do registro protegido. Nos registros gravados de 1.024 bytes, essas verificações abrangem os finais dos dois intervalos de 512 bytes.
- Recupere os termos do trailer salvos na memória do analisador antes de analisar os atributos que ultrapassam esses limites; não altere a imagem de evidência.
- Compare os registros vizinhos, a numeração dos registros (quando houver), os nomes, as referências aos registros pais e os números de sequência. Rejeite relações improváveis ou desatualizadas.
Caso um registro antigo remanescente 0 forneça uma lista de execução válida, utilize esse mapeamento. Se ele estiver ausente, a reconstrução de extensões a partir de sequências de registros continua sendo uma hipótese que requer verificações adicionais. Registros em branco em uma região, por si só, não comprovam que não exista nenhum fragmento posterior.
Remonte a tabela lógica separadamente
Copie os extensos validados para um arquivo de análise separado, na ordem do VCN. Não os classifique por LCN crescente: a terceira execução acima vem antes da segunda no disco, mas vem depois dela logicamente.
Para o número do registro n, tamanho do registro R, e tamanho do cluster C:
- VCN = floor(n × R ÷ C)
- Deslocamento dentro do cluster = (n × R) mod C
- LCN = LCN inicial da série + (VCN − VCN inicial da série)
Para o registro 204.929 no exemplo de três execuções, o VCN é 51.232 e seu deslocamento dentro do cluster é de 1.024 bytes. Seu endereço relativo ao volume é, portanto:
- 9.274.281 × 4.096 + 1.024 = 37.987.456.000 bytes
Esse mapeamento recupera um endereço, não um arquivo. O registro e os dados a que ele se refere ainda precisam ser validados.
6. Recuperar o conteúdo do arquivo por meio dos atributos antigos
Uma vez compreendido um registro de arquivo remanescente, seu atributo $DATA determina o método de extração.
Dados dos residentes: leia o deslocamento e o comprimento do valor do atributo e, em seguida, exporte esse valor do registro validado e restaurado pela correção. Arquivos pequenos podem perder seu conteúdo quando seus registros da MFT são sobrescritos, pois o conteúdo está armazenado ali.
Dados comuns de não residentes: decodificar a lista de execução do próprio arquivo, ler cada extensão da imagem do volume original, organizar os bytes na ordem VCN e ajustar a saída ao tamanho do arquivo lógico. A lista de execução da MFT localiza os registros dos arquivos; ela não substitui o mapeamento entre arquivos e dados de cada usuário.
Siga as referências $ATTRIBUTE_LIST quando os atributos se estenderem a outros registros. Fluxos esparsos e compactados exigem suas respectivas regras de decodificação. O conteúdo criptografado ainda requer o material de descriptografia aplicável. A simples concatenação é insuficiente para esses casos.
A recuperação de diretórios requer um cuidado especial. Um nome de arquivo pode permanecer intacto mesmo que seu diretório pai não exista mais. Reconstrua os caminhos apenas quando as referências e os números de sequência coincidirem; caso contrário, mantenha o arquivo órfão em vez de inventar uma relação com uma pasta.
Salve os arquivos extraídos em outro dispositivo físico. Editar o novo setor de inicialização para que aponte para uma MFT antiga não equivale a recuperar arquivos: mapas de alocação, índices, registros do sistema e outros metadados podem pertencer a instâncias diferentes do sistema de arquivos.
7. Por que a recuperação pode dar certo — e por que pode fracassar
A recuperação baseada em metadados pode ser bem-sucedida porque um registro antigo mantém a identidade do arquivo, seu tamanho lógico e os mapeamentos de dados, enquanto o conteúdo mapeado permanece legível. Uma ferramenta de recuperação pode seguir essas relações, mesmo que o Windows não as inclua mais em seu espaço de nomes ativo.
Se houver registros ausentes, a recuperação baseada em assinaturas pode, às vezes, identificar diretamente o conteúdo do arquivo. Geralmente, esse método perde os nomes originais dos arquivos e a estrutura de diretórios, sendo menos confiável para arquivos fragmentados. A X-Ways documenta a busca por registros NTFS fora da MFT atual separadamente das buscas nos cabeçalhos dos arquivos, refletindo esses diferentes métodos de recuperação.
A recuperação se torna mais difícil quando novos metadados se sobrepõem aos registros originais, arquivos posteriores reutilizam clusters antigos ou faltam mapeamentos de fragmentação. Um nome de arquivo válido não garante que o conteúdo esteja intacto; uma primeira página ou cabeçalho de vídeo reconhecível não garante que os fragmentos posteriores tenham sobrevivido.
Os SSDs acrescentam mais uma condição. A formatação do Windows pode enviar notificações TRIM/exclusão; a Microsoft’s formato a documentação inclui /NoTrim para suprimí-los. Trata-se de uma opção de formatação, não de uma solução após a perda de dados. Dependendo do dispositivo e do caminho de armazenamento, os intervalos descartados podem deixar de retornar os bytes originais, mesmo sem que haja uma sobrescrita convencional visível no WinHex. A formatação rápida, portanto, não é uma garantia universal de recuperabilidade.
8. Verifique os dados extraídos antes de reutilizar o disco
Guarde a imagem original e o mapa de extensão até que a validação seja concluída. Para conhecer um fluxo de trabalho prático de digitalização e exportação, consulte recuperação de arquivos de um disco rígido formatado.
Verifique os arquivos recuperados em relação a um inventário pré-formatação, quando disponível. Compare nomes, tamanhos, relações entre pastas e hashes com os originais conhecidos. Na ausência de hashes de referência, abra os documentos e inspecione suas páginas, teste os arquivos compactados, visualize as imagens em resolução total e reproduza os arquivos de vídeo na íntegra.
Registre os arquivos danificados ou ausentes separadamente dos arquivos verificados. Uma MFT reconstruída sem erros de análise fornece metadados legíveis; conteúdos exportados utilizáveis confirmam a recuperação dos arquivos. A recuperação completa requer a consideração do conjunto de dados esperado.
Perguntas frequentes
A formatação rápida sobrescreve toda a MFT do NTFS?
Os arquivos podem sobreviver quando seus registros na MFT são apagados?
O espelho MFT consegue restaurar todos os registros de arquivos?
Um bit zero no mapa de bits do novo volume significa que os dados antigos foram apagados?
Um registro MFT antigo ainda pode ter o sinalizador de uso ativado?
A restauração do antigo setor de inicialização anulará a formatação?
