FAT et NTFS résolvent le même problème : suivre quels clusters appartiennent à quel fichier. Les deux systèmes de fichiers y répondent très différemment, et la différence est la raison entière pour laquelle la forensique Windows moderne dispose de l'outillage qu'elle a. Sous FAT, vous pouvez souvent prouver qu'un fichier a existé. Sous NTFS, vous pouvez généralement prouver ce qu'il contenait, quand il a été touché, qui s'y est lié, et ce qui lui est arrivé ensuite.
Comment FAT fonctionne, en un paragraphe
FAT maintient une seule table où chaque entrée mappe un cluster soit vers le cluster suivant du fichier, soit vers un marqueur de fin de chaîne, soit vers la valeur 0 signifiant libre. Une entrée de répertoire distincte associe un nom de fichier au premier cluster du fichier. Pour lire un fichier, on parcourt la chaîne. Pour en supprimer un, FAT met chaque entrée de cluster de la chaîne à 0 et remplace le premier caractère du nom dans l'entrée de répertoire par 0xE5. Les données restent, mais la chaîne elle-même est détruite : vous pouvez récupérer le premier cluster et un nom partiel, mais le lien vers les clusters suivants a disparu.
Cette dernière phrase est tout le problème de la récupération FAT. Les outils de récupération FAT peuvent trouver des fragments de fichiers. Ils ne peuvent pas les réassembler de manière fiable quand le fichier était fragmenté à travers le disque. Les fichiers séquentiels (caméras, enregistreurs audio écrivant un gros WAV) reviennent ; les fichiers fragmentés (tout Office, tout ce qui est écrit dans le temps, tout sur un volume à moitié plein) reviennent partiellement, si tant est qu'ils reviennent.
Comment NTFS fonctionne
NTFS remplace la table d'allocation par la Master File Table, un fichier où chaque autre fichier a au moins un enregistrement de 1 024 octets le décrivant. Chaque enregistrement est un petit conteneur avec des attributs typés : $STANDARD_INFORMATION, $FILE_NAME, $DATA, $INDEX_ROOT et les autres détaillés dans la référence d'attributs.
Surtout, $DATA ne pointe pas vers « le premier cluster » et ne dépend pas d'une table séparée pour chaîner. Il transporte une runlist complète : une séquence de paires (LCN de départ, longueur) qui couvre chaque fragment du fichier. Supprimer un fichier ne casse pas cette liste. La liste vit à l'intérieur de l'enregistrement, et l'enregistrement persiste jusqu'à ce que quelque chose d'autre réclame son emplacement.
C'est l'unique décision de conception qui a tout changé pour la forensique.
Ce qui change pour la forensique
Les fichiers supprimés conservent leur runlist. Jusqu'à ce que l'emplacement MFT soit réutilisé, vous pouvez lire la runlist d'un fichier supprimé, suivre vers ses clusters (que l'allocateur n'a peut-être pas encore redistribués) et reconstruire les données même quand le fichier était fortement fragmenté. FAT ne peut pas faire ça.
Huit horodatages par enregistrement, deux résistants à la falsification. $STANDARD_INFORMATION et $FILE_NAME portent chacun quatre horodatages. SI bouge à chaque opération ; FN est stable après création. Les deux jeux se contrôlent mutuellement. Voir les quatre horodatages MFT pour le signal de timestomping que cela fait remonter. FAT porte un horodatage de création, un horodatage de modification (en format DOS, à granularité de deux secondes) et une date d'accès optionnelle. Pas de contrôle croisé, pas de granularité, pas de défense contre le timestomping trivial.
Données résidentes pour les petits fichiers. Les fichiers en dessous d'environ 700 octets de données vivent entièrement à l'intérieur de leur enregistrement MFT. Récupérez l'enregistrement, récupérez le fichier, sans jamais toucher la zone de données. C'est ainsi qu'un petit fichier texte supprimé il y a un mois et écrasé sur les clusters de données peut encore revenir intact. Voir données résidentes.
Hard links et ADS. Un seul enregistrement MFT peut avoir plusieurs attributs $FILE_NAME (hard links) et plusieurs attributs $DATA (le flux primaire plus les alternate data streams). La preuve forensique tirée de ceux-ci est riche et FAT n'a aucun équivalent. ADS est un endroit où les attaquants planquent des charges. Les hard links sont un moyen de faire apparaître le même fichier dans plusieurs répertoires avec des références parent différentes ; utile pour suivre les mécanismes de persistance.
Journaux. Le journal des changements $UsnJrnl enregistre chaque opération de métadonnées : création, suppression, renommage, écrasement de données, avec horodatages et raisons. $LogFile enregistre le détail au niveau transactionnel. FAT n'enregistre ni l'un ni l'autre.
Descripteurs de sécurité. $Secure héberge le magasin d'ACL ; chaque fichier référence son ACL par ID. Pertinence forensique : vous pouvez prouver qui a eu accès, et quand les ACL ont changé (SetSecurityInfo écrit une raison USN SECURITY_CHANGE). FAT n'a aucun concept de permissions par fichier.
Reparse points. Symlinks, junctions, points de montage, placeholders OneDrive, stubs de déduplication et métadonnées POSIX WSL vivent tous dans des attributs $REPARSE_POINT. FAT ne peut rien représenter de tout cela ; les fonctionnalités Windows modernes qui dépendent des reparse points ne fonctionnent simplement pas sur les volumes FAT.
L'effet agrégé : si vous avez le choix entre une image FAT et une image NTFS du même incident, l'image NTFS répondra presque toujours à davantage de questions. Souvent d'un ordre de grandeur.
Où vous rencontrez encore FAT
FAT n'est pas mort. Vous le rencontrerez encore sur :
- Les clés USB formatées en usine (exFAT sur les plus grandes, FAT32 sur les plus petites).
- La partition système EFI sur chaque installation Windows UEFI (FAT32, autour de 100-300 Mo, contient le Windows Boot Manager).
- Les cartes SD de caméras, drones, appareils embarqués.
- Les anciens contrôleurs industriels et une longue queue de Linux embarqué qui utilise toujours par défaut FAT pour le stockage amovible.
- Certains volumes formatés Mac partagés avec Windows (exFAT).
Pour les volumes système sur n'importe quelle machine Windows moderne, vous regardez du NTFS. ReFS apparaît sur certaines installations Server et Storage Spaces mais pas sur le disque de boot. L'artefact que vous voulez est $MFT.
exFAT, en bref
exFAT est le cas intermédiaire. C'est ce que Microsoft a utilisé pour remplacer FAT32 sur les volumes trop grands pour la limite pratique de 32 Go de FAT32. Table d'allocation moderne avec chaînes de clusters, mais pas de journal, pas de MFT, pas d'ADS, pas de hard links, pas de descripteurs de sécurité. Du point de vue forensique, c'est plus proche de FAT que de NTFS. Vous avez des horodatages (plus granulaires que FAT), vous avez la chaîne de clusters, et vous avez les entrées de répertoire. Vous n'avez aucune des choses qui rendent la forensique NTFS intéressante.
Quand vous voyez exFAT sur un périphérique amovible qui comptait, votre outillage change : PhotoRec et scalpel pour le carving de signature, fsstat et fls du Sleuth Kit pour le peu de structure qui existe, et une reconnaissance honnête dans votre rapport que le jeu d'artefacts est limité.
Une conséquence pratique
Les gens demandent parfois pourquoi leur clé USB formatée FAT a donné si peu comparée au volume NTFS du même incident. La réponse honnête est structurelle : le système de fichiers a décidé quelles preuves laisser derrière des années avant que l'incident n'arrive. Le choix de format est lui-même une variable forensique, et quelqu'un habitué à attraper des artefacts sur des bureaux Windows sera nettement déçu par une carte de caméra exFAT.
Si vous contrôlez le choix (baseline d'entreprise, médias d'imagerie de labo), choisissez NTFS. Si vous ne le contrôlez pas (réponse à incident sur une cible que vous n'avez pas spécifiée), acceptez les contraintes et changez votre outillage.
Lectures complémentaires
- Microsoft, comparaison FAT vs NTFS. Matrice de fonctionnalités officielle.
- Brian Carrier, File System Forensic Analysis. Les chapitres comparant FAT et NTFS restent la référence définitive.
- La spécification exFAT (Microsoft). Vaut la lecture une fois si vous traitez régulièrement de médias amovibles.