Teste da MFT de arquivos excluídos no NTFS: o que muda após a exclusão?
Um Teste da MFT de arquivos excluídos no NTFS precisa comparar mais do que apenas um nome de arquivo. Assim que a exclusão definitiva for concluída, o NTFS pode liberar o registro do arquivo, remover sua entrada ativa no diretório e liberar seus clusters de dados não residentes. No entanto, essas alterações não apagam necessariamente o conteúdo antigo. Este experimento compara um pequeno arquivo TXT residente com um JPG não residente por meio da exclusão e reutilização do registro e, em seguida, examina uma sobrescrita definida dos dados externos do JPG. A comparação distingue três questões: o nome permanece, o mapeamento permanece e os bytes originais ainda correspondem?
Índice
O que este exame-teste sobre a MFT de arquivos excluídos no NTFS avalia
A questão central é se um registro MFT excluído ainda pode descrever um arquivo completo. A resposta depende tanto dos metadados quanto do conteúdo. Um nome que tenha sobrevivido pode identificar um arquivo antigo, enquanto uma lista de execução que tenha sobrevivido pode localizar os antigos clusters de um fluxo não residente. Nenhum dos dois fatos comprova que esses clusters ainda contenham os dados originais.
Para contextualizar, o Tabela do arquivo mestre Este guia explica como os registros relacionam nomes, atributos e locais de armazenamento. Aqui, o foco está na transição entre estados definidos.
Este experimento utiliza amostras geradas da estrutura NTFS, comparações de bytes calculadas e transições de estado de alocação explicitamente definidas. As capturas de tela mostram os registros gerados abertos no wxHexEditor, com seleções correspondentes antes e depois: os sinalizadores do registro JPG e os bytes de conteúdo residente do TXT. O modelo simula a exclusão completa de um arquivo com link único, com todos os identificadores fechados, em vez de uma movimentação para a Lixeira.
Configuração e premissas do teste da MFT do NTFS
Este teste de MFT para arquivos excluídos do NTFS utiliza um volume lógico NTFS 3.1 não criptografado. Ele utiliza setores lógicos de 512 bytes, clusters de 4.096 bytes e registros MFT de 1.024 bytes. Sua partição começa no LBA 2.048 do disco. Esses valores são parâmetros selecionados, e não especificações do dispositivo.
O alvo, mft-lab-file.jpg, ocupa o 42º lugar, um recorde. Seu anônimo, não residente $DATA O fluxo contém exatamente 10.240 bytes. Uma sequência contígua abrange três clusters, começando no cluster lógico número 8192. Consequentemente, a alocação é de 12.288 bytes, com 2.048 bytes além do fim lógico do arquivo. O tamanho da unidade de alocação O guia explica essa distinção entre tamanho e alocação.
Ambos os alvos têm um link físico e sem compressão NTFS, alocação esparsa, fluxos de dados alternativos ou registros de extensão. O arquivo JPG é um JPEG válido, gerado com dimensões de 160 × 120, com um padrão determinístico de pixels e um segmento de comentário JPEG que define seu comprimento como 10.240 bytes. Ele foi decodificado para verificar o formato da amostra. O registro 42 começa com o número de sequência 42.
O segundo alvo, resident-note.txt, contém exatamente 64 bytes de texto ASCII no registro 43, inicialmente na sequência 7. Seu $DATA O valor não requer conjuntos de dados separados. Em ambos os exemplos, o cabeçalho de atributo determina a forma de armazenamento: a .txt A extensão, por si só, não garante a presença de dados residentes, e o .jpg A extensão, por si só, não determina os dados de não residentes.
Para cada comparação de exclusão imediata, o modelo preserva a carga útil e os atributos antigos. Os cenários subsequentes alteram o slot do registro ou, no caso do JPG, um cluster de dados externo. Isso isola seus efeitos sem pressupor uma sequência específica de leitura do SSD ou de gravação do Windows.
Procedimento de teste da MFT para arquivos excluídos no NTFS
Os cenários 1 a 4 seguem o JPG para não residentes. S3 e S4 se ramificam independentemente de S2. S5 a S7 formam um controle TXT residente separado; esses estados utilizam o registro 43 em vez do registro 42.
JPG não residente: Estados de teste do MFT do NTFS
S1 — Linha de base do JPG.
Crie o registro 42 com seu nome, o mapeamento de dados de não residentes e o sinalizador de uso ativado. Defina os bits correspondentes de alocação de registro e cluster. Gere o conteúdo completo e calcule seu resumo SHA-256.
S2 — Exclusão do arquivo JPG concluída.
A partir do S1, remova o nome original da associação ao Active Directory, desmarque o bit de uso do registro, reduza sua contagem de links a zero e incremente seu número de sequência. Limpe os bits relevantes do registro e do bitmap do cluster. Preserve o nome de arquivo antigo, o atributo de dados e a carga útil, conforme definido no caso de metadados retidos.
S3 — Espaço de gravação de JPG reutilizado.
A partir do S2, substitua o registro 42 pelos atributos de novo-proprietário.txt, um pequeno arquivo residente. Defina novamente o bit de alocação do registro. Deixe os três clusters de dados anteriores inalterados e livres. Verifique se o registro atual ainda mantém o mapeamento original.
S4 — Agrupamento intermediário de JPG sobrescrito.
Retorne separadamente ao S2. Atribua o LCN 8193 a outro arquivo e substitua cada byte nesse cluster por seu inverso bit a bit (FF XOR original). Essa substituição definida altera todos os bytes nesse intervalo. Mantenha inalterado o registro de destino antigo, que já foi liberado. Compare o fluxo resultante de 10.240 bytes com o original.
TXT residente: Estados de teste da MFT do NTFS
S5 — Linha de base do TXT residente.
Criar registro 43 para resident-note.txt com 64 bytes em sua memória residente $DATA atributo. Defina o bit de alocação do registro e registre a localização e o resumo do valor. Seu fluxo de dados não possui alocação de cluster externo.
S6 — Exclusão do arquivo TXT residente concluída.
A partir de S5, remova o nome do arquivo ativo, zere os bits de uso e alocação do registro, defina os links como zero e incremente a sequência de 7 para 8. Preserve os bytes de conteúdo residente. Não há bits separados do cluster de carga útil a serem zerados para este fluxo.
S7 — Registro TXT residente reutilizado.
A partir de S6, reutilize o registro 43 para replacement1.txt. Coloque 64 caracteres de til no mesmo intervalo de valores residentes. Compare esse intervalo com o texto original para determinar se a carga útil original sobrevive a essa substituição.
Comparar conteúdos após a exclusão e reutilização
Avalie o conteúdo separadamente. Para o arquivo JPG, decodifique o mapeamento retido, leia os intervalos externos na ordem do arquivo e pare aos 10.240 bytes. Para o arquivo TXT, leia o valor de 64 bytes contido em seu registro. Compare os bytes completos e o resumo; exclua o espaço livre do cluster e não utilize o nome do arquivo como verificação de integridade.
Essas transformações se aplicam a estruturas geradas descartáveis. Para um acompanhamento baseado em dispositivo, utilize meios de teste descartáveis e verifique a identidade do alvo antes de excluir qualquer coisa. Preserve a fonte afetada ao investigar a perda efetiva de dados.
Comparação hexadecimal de exclusão de arquivos NTFS
Na seção de capturas de tela emparelhadas abaixo, compare cada arquivo com sua própria versão anterior. O campo de cabeçalho em +0x16 é a palavra de sinalizadores de dois bytes. Seu bit mais baixo muda de “alocado” para “livre”. Os campos “sequência” e “link” adjacentes fornecem o contexto de apoio. O h O sufixo identifica deslocamentos hexadecimais de linha; as capturas de tela em JPG selecionam +0x16–+0x17; já as capturas de tela do TXT selecionam o conteúdo residente para comparação.
Campos da MFT de arquivos excluídos: o que mudou?
A alteração do sinalizador libera o registro; ela não instrui um analisador a substituir os dados do arquivo por zeros. A alteração da sequência também é importante: uma referência antiga que identifica o registro 42 com a sequência 42 agora está desatualizada. Documentação da Microsoft o incremento da sequência quando um segmento de registro de arquivo é liberado.
As duas alterações no bitmap descrevem alocação de registros e clusters. $MFT::$BITMAP as faixas registram a alocação. Neste exemplo, o registro 42 corresponde ao bit 2 do byte +0x05. O volume do $Bitmap::$DATA monitora a alocação de clusters. Os clusters 8192–8194 correspondem aos bits 0–2 do byte +0x0400.
A limpeza desses bits torna os recursos disponíveis para reutilização. Isso não garante que uma leitura posterior retorne o conteúdo original. Além disso, a remoção do nome original do índice do Active Directory é um processo distinto da retenção $FILE_NAME atributo dentro do registro liberado. As atualizações na árvore de diretórios podem deslocar ou sobrescrever entradas do índice, portanto, os resquícios do índice precisam de uma interpretação própria.
Como o MFT localiza um arquivo excluído?
Em S1 e S2, o atributo de dados de não residentes começa no registro +0x118. Seu deslocamento dos pares de mapeamento é 0x40, colocando a lista de execução no registro +0x158. Os bytes descrevem uma sequência de três clusters que começa no LCN 8192. A comparação interativa abaixo mantém os valores hexadecimais reais e permite que os leitores examinem esses campos.
Os LCNs são relativos ao volume. Portanto, o primeiro bloco de dados começa no deslocamento de bytes do volume 0x02000000. Somando o deslocamento da partição escolhida, obtém-se o deslocamento em bytes do disco 0x02100000, ou LBA 67584 do disco. Confundir essas bases faria com que um leitor de recuperação inspecionasse o local errado.
TXT residente x JPG não residente: a mesma exclusão, armazenamento diferente
Compare os dois arquivos na mesma etapa: S5 versus S1 antes da exclusão, S6 versus S2 após a exclusão e S7 versus S3 após a reutilização do registro. O TXT ocupa o registro 43; o JPG ocupa o registro 42. Nomes de arquivo, números de registro e valores de sequência iniciais diferentes identificam objetos distintos, em vez de indicar alterações decorrentes da exclusão.
Palco | TXT residente: 64 bytes | JPG não residente: 10.240 bytes |
Antes da exclusão | O conteúdo está no registro 43 em | O registro 42 contém a lista de execuções; o conteúdo está nos clusters externos 8192–8194. |
Após a exclusão | O registro está livre; todos os 64 bytes de conteúdo residente permanecem no estado definido. | O registro e três clusters estão livres; o mapeamento antigo e todos os 10.240 bytes de conteúdo permanecem no estado definido. |
Após a reutilização do registro | O valor de substituição sobrescreve o mesmo intervalo: 0 / 64 bytes originais correspondem. | O novo proprietário remove o mapeamento antigo; o intervalo externo conhecido como linha de base ainda corresponde a 10.240 / 10.240 bytes. |
Inspecionar os campos de teste da MFT de arquivos excluídos
A comparação interativa é exibida com os dois estados excluídos lado a lado. Seu resumo abrange todas as três etapas correspondentes, e sua visualização de armazenamento distingue o conteúdo residente dos pares de mapeamento não residentes.
Alocação, verificações de conteúdo e endereços
Antes da exclusão: onde está o conteúdo do arquivo?
O arquivo TXT de 64 bytes contém o FormCode 00 em nível recorde +0x120. Seu conteúdo completo ocupa +0x130–+0x16F dentro do registro MFT. O arquivo JPG de 10.240 bytes possui o FormCode 01; seu registro contém pares de mapeamento em +0x158, enquanto os bytes da imagem ocupam os clusters externos 8192–8194.
TXT residente
S5: O texto selecionado é o próprio conteúdo do arquivo, armazenado no registro 43.
JPG de não residente
S1: O registro 42 armazena o atributo “não residente” e a lista de execução; o conteúdo JPEG está no local externo descrito por esse mapeamento.
Após a exclusão: o que é liberado e o que permanece?
Ambos os registros perdem o bit de “em uso”. Para o TXT, o estado de exclusão definido mantém todos os 64 bytes dentro do registro liberado; esse fluxo residente não possui clusters de carga útil separados a serem liberados. Para o JPG, a exclusão também libera seus três clusters de dados externos. O estado S2 definido mantém tanto a lista de execução antiga quanto todos os 10.240 bytes de conteúdo externo.
TXT residente
S6: Os sinalizadores passam a ser 00 00, mas o conteúdo residente selecionado permanece o mesmo do S5.
JPG de não residente
S2: As bandeiras se tornam 00 00, enquanto o registro mantém seu mapeamento. A verificação de conteúdo externo no HTML indica 10.240 bytes correspondentes.
Após a reutilização do registro: o que a operação “same” destrói?
No controle TXT, o proprietário substituto grava 64 caracteres de til sobre o mesmo intervalo de valores residentes. Todos os 64 bytes originais nesse intervalo são diferentes. No controle JPG, o proprietário substituto remove o mapeamento do registro original, mas a operação definida mantém os dados externos da imagem inalterados. Assim, o JPG perde seu mapeamento antigo, enquanto seus dados sobrevivem em outro lugar; o TXT perde seu conteúdo original dentro do registro reutilizado.
TXT residente
S7: O mesmo intervalo selecionado agora contém o texto de substituição. Conteúdo original residente que corresponde a esse intervalo: 0 / 64 bytes.
JPG de não residente
S3: O registro 42 agora descreve new-owner.txt; o mapeamento original do JPG não existe mais. O intervalo externo original, verificado separadamente, ainda corresponde a todos os 10.240 bytes do JPG.
Essas são duas formas diferentes de falha decorrentes do mesmo tipo de reutilização de registro. Uma avaliação de recuperação deve verificar o valor residente no registro do TXT, mas também deve verificar tanto o mapeamento histórico quanto o conteúdo externo do JPG. O próprio registro ainda ocupa espaço dentro de $MFT; “sem clusters externos” refere-se apenas ao fluxo de dados TXT residente.
Resultados do experimento sobre metadados de exclusão no NTFS
No caso do JPG, o S2 mantém, por definição, tanto o mapa antigo quanto todo o conteúdo original. A leitura dos clusters mapeados e o recorte para 10.240 bytes resultam em uma correspondência completa, byte a byte, e no mesmo resumo SHA-256. Isso comprova a identidade do conteúdo dessa amostra gerada. No entanto, este teste de MFT de arquivos excluídos do NTFS não avalia o desempenho de recuperação de nenhum aplicativo.
O S3 separa a permanência do conteúdo da permanência dos metadados. Os bytes de dados originais ainda coincidem, mas o registro atual pertence a um arquivo diferente e não contém mais a lista de execução original. A linha de base salva identifica onde esses bytes costumavam estar; esse conhecimento serve como referência de comparação, não como metadados disponíveis no registro reutilizado. Seriam necessárias outras estruturas remanescentes ou análises de conteúdo para localizar e identificar o fluxo antigo de forma independente.
O S4 demonstra o problema oposto. O nome do arquivo original e o mapa permanecem no registro liberado, mas seu cluster do meio contém bytes substituídos. Apenas 6.144 bytes originais coincidem; 4.096 diferem. A leitura do intervalo antigo completo ainda produz um resultado de 10.240 bytes, mas seu resumo não passa na verificação do conteúdo original. Um nome de arquivo e um comprimento de arquivo corretos podem, portanto, acompanhar um conteúdo danificado. O comportamento de visualização do JPEG é uma verificação separada da identidade byte a byte.
Para o TXT, o S6 mantém todos os 64 bytes de conteúdo residentes. No S7, nenhum desses bytes corresponde ao valor de substituição. Trata-se de uma perda de conteúdo dentro da substituição de registro definida, sem sobrescrever um cluster de dados externo.
O teste de MFT de arquivos excluídos do NTFS acima compara os arquivos TXT e JPG na mesma etapa. Suas outras visualizações mantêm as verificações “antes e depois” por arquivo, enquanto os detalhes fornecem os resumos de conteúdo calculados.
Por que os indicadores da MFT de arquivos excluídos não podem comprovar a possibilidade de recuperação
Uma avaliação útil requer três verificações distintas. Primeiro, é preciso determinar a identidade do arquivo a partir de metadados coerentes. Em seguida, interpretar seus atributos de armazenamento, incluindo limites de valores residentes, mapeamentos externos e quaisquer registros ou fluxos adicionais. Por fim, verificar o conteúdo disponível nesses intervalos. Os cenários gerados permitem deliberadamente que essas verificações produzam respostas diferentes.
Os dois alvos exigem verificações de conteúdo diferentes. O arquivo TXT residente mantém sua carga útil dentro do próprio registro; o arquivo JPG não residente depende de informações de mapeamento para acessar clusters externos. No S3, o novo proprietário é residente para isolar a reutilização do registro da reutilização dos antigos clusters de dados do JPG. S5–S7 demonstram separadamente o que acontece quando o próprio destino excluído possui dados residentes. Fluxos fragmentados, compactados, criptografados e esparsos introduzem requisitos adicionais de interpretação.
Uma ferramenta também não deve equiparar automaticamente um registro não utilizado a um arquivo excluído, mas intacto. A validade estrutural, o estado de alocação, a propriedade, a consistência do mapeamento e o conteúdo legível respondem a questões diferentes. Mesmo um fragmento de texto válido não comprova que um documento, uma fotografia ou um vídeo esteja completo.
O que o Explorador de Arquivos e o Gerenciamento de Discos podem mostrar
Após a exclusão definitiva, o nome original deve desaparecer da listagem normal do diretório. O espaço livre pode aumentar assim que o sistema de arquivos liberar a alocação, embora atividades não relacionadas possam alterar o total exibido.
A exclusão normal de um arquivo não transforma um volume NTFS, que de outra forma estaria em bom estado, em espaço RAW ou não alocado. O Gerenciamento de Discos descreve volumes e partições; ele não exibe os sinalizadores de registros individuais da MFT. Uma marcação como RAW ou a ausência de uma partição exige, portanto, um diagnóstico específico do sistema de arquivos ou da partição, em vez de ser tratada como confirmação desse mecanismo de exclusão.
When File Recovery Comes Before File-System Repair
If the volume still works and only files are missing, repair is not the first explanation or action. Continued writes can reuse both freed records and freed clusters. Avoid installing tools, saving recovered files, or running unnecessary repair operations on the affected volume. Examine a suitable preserved copy when possible and save recovered content elsewhere.
For a practical check, Magic Data Recovery can scan the affected drive and preview supported files before recovery. Install it on another drive and save recovered files elsewhere; the software cannot recover content that later writes have overwritten.
SSD behavior adds another condition. The Comando TRIM can notify storage that released logical ranges are no longer needed. Microsoft’s read-only query Consulta de comportamento fsutil DisableDeleteNotify reports the notification setting; it does not prove that a specific range retains its bytes.
If the original logical ranges return zeros or replacement content, a surviving MFT name cannot supply the missing nonresident payload. Conversely, readable old bytes still require correct mapping and content validation. Disabling notifications later does not reverse notifications already issued.
NTFS Deleted File MFT Test: Conclusion
Isso Teste da MFT de arquivos excluídos no NTFS separates record allocation, data mapping, and content integrity. In the JPG’s retained-metadata scenario, deletion frees the record and clusters while the original content still matches. However, record reuse removes the old map without changing those data bytes, and a cluster overwrite damages content while leaving the old name and map available.
The resident TXT control adds a different failure path: deleting its record leaves the defined 64-byte value intact, but reusing that record replaces the value itself. The JPG instead requires separate checks of its record and external data.
The practical conclusion is to verify each layer independently. A filename identifies a candidate; a resident-value offset or nonresident runlist identifies its content location; a complete content check determines whether that location still reproduces the original stream. That distinction explains why a deleted file can appear in a scan yet fail to open correctly after extraction.
PERGUNTAS FREQUENTES
Os sinalizadores MFT com valor 0x0002 identificam um arquivo excluído?
A assinatura do FILE valida um registro MFT do NTFS?
O número de sequência revela quantas vezes um arquivo foi excluído?
É possível atribuir um bloco livre a um arquivo excluído apenas com base no bit do seu bitmap?
A exclusão de um link físico sempre libera os dados do arquivo?
Uma extensão correta comprova que o conteúdo extraído é válido?
