O FAT e o NTFS resolvem o mesmo problema: seguir que clusters pertencem a que ficheiros. Os dois sistemas de ficheiros respondem-no de formas muito diferentes, e a diferença é a razão inteira de a forense moderna do Windows ter o toolkit que tem. Em FAT, muitas vezes consegue provar que um ficheiro existiu. Em NTFS, geralmente consegue provar o que estava lá dentro, quando foi tocado, quem lhe fez links, e o que lhe aconteceu depois.
Como funciona o FAT, num parágrafo
O FAT mantém uma única tabela onde cada entrada mapeia um cluster para o próximo cluster do ficheiro, um marcador de fim de cadeia, ou o valor 0 que significa livre. Uma entrada de directório separada associa um nome de ficheiro ao primeiro cluster do ficheiro. Para ler um ficheiro, percorre a cadeia. Para eliminar um, o FAT limpa todas as entradas de cluster da cadeia para 0 e substitui o primeiro carácter do nome do ficheiro na entrada de directório por 0xE5. Os dados ficam para trás, mas a cadeia em si é destruída: pode recuperar o primeiro cluster e um nome de ficheiro parcial, mas a ligação aos clusters subsequentes desapareceu.
Essa última frase é o problema inteiro da recuperação em FAT. As ferramentas de recuperação em FAT conseguem encontrar fragmentos de ficheiro. Não conseguem reagrupá-los de forma fiável quando o ficheiro estava fragmentado pelo disco. Ficheiros sequenciais (câmaras, gravadores áudio a escrever um WAV grande) voltam; ficheiros fragmentados (qualquer Office, qualquer coisa escrita ao longo do tempo, qualquer coisa num volume meio-cheio) voltam parcialmente ou nem isso.
Como funciona o NTFS
O NTFS substitui a tabela de alocação pela Master File Table, um ficheiro onde todos os outros ficheiros têm pelo menos um registo de 1.024 bytes a descrevê-los. Cada registo é um pequeno contentor com atributos tipados: $STANDARD_INFORMATION, $FILE_NAME, $DATA, $INDEX_ROOT, e outros detalhados na referência de atributos.
Crucialmente, o $DATA não aponta para "o primeiro cluster" e depende de uma tabela separada para encadear. Carrega uma runlist completa: uma sequência de pares (LCN inicial, comprimento) que cobre cada fragmento do ficheiro. Eliminar um ficheiro não parte essa lista. A lista vive dentro do registo, e o registo persiste até que outra coisa reivindique o seu slot.
Esta é a única decisão de desenho que mudou tudo para a forense.
O que muda para a forense
Os ficheiros eliminados mantêm a runlist. Até que o slot do MFT seja reutilizado, pode ler a runlist de um ficheiro eliminado, andar até aos seus clusters (que o alocador pode ainda não ter atribuído), e reconstruir os dados mesmo quando o ficheiro estava muito fragmentado. O FAT não consegue fazer isto.
Oito carimbos temporais por registo, dois deles resistentes a adulteração. O $STANDARD_INFORMATION e o $FILE_NAME carregam quatro carimbos temporais cada. O SI move-se em cada operação; o FN é estável depois da criação. Os dois conjuntos fazem cross-check um do outro. Veja os quatro carimbos temporais do MFT para o sinal de timestomping que isto faz emergir. O FAT carrega um carimbo de criação, um de modificação (em formato DOS time, com granularidade de dois segundos), e uma data de acesso opcional. Sem cross-check, sem granularidade, sem defesa contra timestomping trivial.
Dados residentes para ficheiros pequenos. Ficheiros abaixo de aproximadamente 700 bytes de dados vivem inteiramente dentro do seu registo MFT. Recupere o registo, recupere o ficheiro, sem tocar na área de dados. É assim que um pequeno ficheiro de texto eliminado há um mês e sobrescrito nos clusters de dados pode ainda voltar intacto. Veja resident data.
Hard links e ADS. Um único registo MFT pode ter múltiplos atributos $FILE_NAME (hard links) e múltiplos atributos $DATA (o fluxo primário mais alternate data streams). A evidência forense que estes fornecem é rica e o FAT não tem nada equivalente. Os ADS são um sítio onde os atacantes escondem payloads. Os hard links são uma forma de fazer o mesmo ficheiro aparecer em múltiplos directórios com referências de pai diferentes; úteis para rastrear mecanismos de persistência.
Journals. O change journal $UsnJrnl regista cada operação de metadados: criar, eliminar, renomear, sobrescrever dados, com carimbos temporais e motivos. O $LogFile regista detalhe ao nível das transacções. O FAT não regista nem um nem outro.
Descritores de segurança. O $Secure guarda a loja de ACLs; cada ficheiro referencia a sua ACL por ID. Relevância forense: pode provar quem tinha acesso e quando as ACLs mudaram (SetSecurityInfo escreve um motivo USN de SECURITY_CHANGE). O FAT não tem conceito de permissões por ficheiro.
Reparse points. Symlinks, junctions, mount points, placeholders do OneDrive, stubs de dedup e metadados POSIX do WSL vivem todos em atributos $REPARSE_POINT. O FAT não consegue representar nada disto; funcionalidades modernas do Windows que dependem de reparse points simplesmente não funcionam em volumes FAT.
O efeito agregado: se tem escolha entre uma imagem FAT e uma imagem NTFS do mesmo incidente, a imagem NTFS quase sempre responderá a mais perguntas. Frequentemente por uma ordem de grandeza.
Onde ainda se encontra FAT
O FAT não está morto. Vai encontrá-lo em:
- Pen drives USB formatadas de fábrica (exFAT nas maiores, FAT32 nas mais pequenas).
- A partição EFI System em todas as instalações Windows UEFI (FAT32, cerca de 100-300 MB, contém o Windows Boot Manager).
- Cartões SD de câmaras, drones, dispositivos embebidos.
- Controladores industriais mais antigos e uma longa cauda de Linux embebido que ainda usa FAT por omissão em armazenamento removível.
- Alguns volumes formatados no Mac partilhados com Windows (exFAT).
Para volumes de SO em qualquer máquina Windows moderna, está a olhar para NTFS. O ReFS aparece em algumas instalações Server e em Storage Spaces, mas não no disco de arranque. O artefacto que quer é o $MFT.
exFAT, brevemente
O exFAT é o caso intermédio. É o que a Microsoft usou para substituir o FAT32 em volumes demasiado grandes para o limite prático de 32 GB do FAT32. Tabela de alocação moderna com cadeias de cluster, mas sem journal, sem MFT, sem ADS, sem hard links, sem descritores de segurança. Do ponto de vista forense, está mais perto do FAT do que do NTFS. Tem carimbos temporais (mais granulares do que FAT), tem a cadeia de clusters, e tem as entradas de directório. Não tem nenhuma das coisas que tornam a forense em NTFS valiosa.
Quando vê exFAT num dispositivo removível que era relevante, a sua tooling muda: PhotoRec e scalpel para carving por assinatura, fsstat e fls do Sleuth Kit para a pouca estrutura que existe, e um reconhecimento honesto no seu relatório de que o conjunto de artefactos é limitado.
Uma consequência prática
Por vezes as pessoas perguntam porque é que a pen USB formatada em FAT delas rendeu tão pouco comparado com o volume NTFS do mesmo incidente. A resposta honesta é estrutural: o sistema de ficheiros decidiu que evidência deixar para trás anos antes de o incidente acontecer. A escolha de formato é em si uma variável forense, e alguém habituado a tirar artefactos de desktops Windows ficará seriamente desapontado com um cartão de câmara em exFAT.
Se controla a escolha (baseline corporativo, suportes de imaging de laboratório), escolha NTFS. Se não controla (resposta a incidente num alvo que não especificou), aceite as restrições e mude a sua tooling.
Leituras adicionais
- Microsoft, Comparação FAT vs NTFS. Matriz oficial de funcionalidades.
- Brian Carrier, File System Forensic Analysis. Os capítulos que comparam FAT e NTFS continuam a ser a referência definitiva.
- A especificação exFAT (Microsoft). Vale a pena ler uma vez se lidar regularmente com suportes removíveis.