Récupérer les fichiers supprimés sur NTFS en utilisant la MFT

Récupérer les fichiers supprimés sur NTFS se résume à deux horloges et une courte règle. Les horloges : combien de temps avant que le slot de l'enregistrement MFT soit réutilisé, et combien de temps avant que les clusters de données soient écrasés. La règle : n'écrivez pas sur le volume tant que l'une des deux horloges vous est encore utile.

Voici le flux de récupération que je lance réellement quand on me tend un volume NTFS et qu'on me dit « ils ont supprimé X, peut-on le récupérer ? ». Il tire de la même boîte à outils, que X soit un seul fichier, une arborescence ou le contenu d'un répertoire passé par SDelete.

Pourquoi la suppression n'efface pas

Quand Windows supprime un fichier d'un volume NTFS :

1. Le drapeau IN_USE (bit 0 dans les drapeaux d'en-tête à l'offset 0x16) est effacé.
2. Les clusters qui contenaient les données sont marqués libres dans $Bitmap.
3. L'entrée $INDEX_ROOT du répertoire parent est retirée.

Ce qui ne se produit pas : rien n'écrase l'enregistrement ni les clusters. Ils sont marqués disponibles pour la prochaine allocation. Jusqu'à ce que quelque chose d'autre les réclame, le fichier est récupérable. Voir ce qui survit à une suppression pour le détail champ par champ.

L'horloge de récupération du slot MFT et l'horloge de récupération des clusters de données sont indépendantes. Vous pouvez avoir un enregistrement qui a été réutilisé (le slot est maintenant un autre fichier) mais dont les clusters de données contiennent encore les anciens octets. Vous pouvez avoir un enregistrement supprimé intact dont les clusters ont été alloués à un nouveau fichier. Les deux situations requièrent des stratégies de récupération différentes.

Étape 1 : arrêtez d'écrire sur le volume

Chaque écriture que vous faites sur le volume risque de réutiliser le slot ou les clusters d'un enregistrement supprimé. Si le fichier compte :

• Arrêtez l'application qui le touchait. Si c'était une base de données, arrêtez le moteur. Si c'était un document, fermez l'éditeur.
• Si le fichier vivait sur le lecteur système et que le système tourne encore, l'OS lui-même écrit constamment (paging, prefetch, registre, journaux d'événements). Éteignez ou bootez depuis des médias externes. Un système vivant perd de l'espace récupérable à la seconde.
• Pour un lecteur externe, démontez immédiatement. Sous Windows, éjectez ; sous Linux, umount.

C'est l'étape que les gens sautent quand ils pensent que la récupération va être « facile ». La moitié des cas de récupération ratés que j'ai vus ont échoué à cette étape.

Étape 2 : imagez le disque

Travaillez sur une copie, jamais sur l'original. Les options standards :

• FTK Imager : gratuit, GUI, produit des images .dd ou .E01. Hashe la source pendant la lecture.
• dd sous Linux : dd if=/dev/sdX of=disk.img bs=4M conv=noerror,sync status=progress. Rapide sur disques sains.
• ddrescue : plus lent, mais tolère les erreurs de lecture sur disques défaillants. Le bon choix quand le disque est le problème (cliquetis, lectures lentes, avertissements SMART).

Hashez l'image (SHA-256) immédiatement après l'acquisition. Toutes les étapes suivantes travaillent contre l'image, jamais contre l'original.

Étape 3 : choisissez la bonne approche de récupération

L'approche dépend de ce qui est encore intact.

Replay MFT quand l'enregistrement du fichier supprimé est encore dans la table. Parsez $MFT avec un outil qui liste les enregistrements supprimés. Le nom, les horodatages, le répertoire parent et (pour les petits fichiers) les données du fichier sont récupérables depuis l'enregistrement. Pour les fichiers non résidents, la runlist pointe toujours vers les clusters originaux ; si ces clusters n'ont pas encore été écrasés, icat ou équivalent extrait les données.

• MFTECmd liste les enregistrements supprimés et marque les données résidentes.
• Le parser navigateur filtre vers les entrées supprimées en un clic et affiche les données résidentes en ligne.
• fls -d -m du Sleuth Kit liste les entrées supprimées ; icat -r récupère leurs données quand c'est possible.

Outils de récupération conscients du système de fichiers quand vous voulez une restauration sélective pilotée par GUI depuis un volume ou une image :

• R-Studio : commercial, le choix de l'analyste pour NTFS. Gère les dégâts complexes, récupère depuis des volumes formatés, comprend EFS et BitLocker (avec clé).
• TestDisk + PhotoRec : gratuit, mûr, bon pour les dégâts de partition. PhotoRec est du carving de signature plutôt que conscient du système de fichiers, il perd donc les noms de fichiers.
• Recuva : grand public. Convenable pour les récupérations un fichier sur un lecteur dans des volumes sans complication. Pas ce que j'utiliserais pour une enquête.

Carving de signature quand la MFT est partie ou que l'enregistrement a été réutilisé. scalpel, foremost et PhotoRec scannent l'image brute pour des signatures de fichiers connues (JPEG FF D8 FF, PNG 89 50 4E 47, ZIP 50 4B 03 04, PDF 25 50 44 46) et réassemblent ce qu'ils trouvent. Les fichiers taillés perdent leurs noms et horodatages ; ceux-ci vivaient dans la MFT. Les octets eux-mêmes reviennent, modulo fragmentation.

Pour les fichiers fragmentés, le carving de signature peine. Les carvers concatènent des clusters consécutifs qui paraissent bons, mais si le fichier était éparpillé sur le disque, ils ne peuvent pas le réassembler. Le replay MFT conscient de NTFS gère la fragmentation correctement parce que la runlist décrit explicitement chaque fragment.

Étape 4 : quand la récupération MFT est la seule voie

Les petits fichiers (sous ~700 octets de $DATA) vivent entièrement dans l'enregistrement MFT. Même si $Bitmap a été écrasé des dizaines de fois, les octets résidents sont toujours dans l'enregistrement jusqu'à ce que le slot soit réutilisé. Voir données résidentes.

Pour un petit fichier texte, une petite config JSON, un script PowerShell, un export registre, un petit certificat ou un fichier .lnk, le parser navigateur est souvent la voie la plus rapide : déposez la $MFT extraite, filtrez vers les entrées supprimées, cherchez les enregistrements avec $DATA résident et copiez les octets dehors. Ça marche quand rien d'autre ne marche parce que les données ne sont jamais sorties de la MFT.

Ce qui est vraiment irrécupérable

Clusters écrasés. Les HDD et SSD modernes n'offrent aucun chemin réaliste pour récupérer des données écrasées une fois. La récupération par « magnétisation rémanente » fantaisiste de la vieille littérature forensique ne s'applique pas aux disques fabriqués cette décennie. La densité est trop élevée, le positionnement de tête trop précis.

Blocs SSD récupérés par TRIM. Une fois que le contrôleur SSD a TRIM un bloc, le flash sous-jacent est mis à zéro pendant le garbage collection. Les données partent, vite. La fenêtre entre la suppression et la fin du TRIM sous Windows moderne est de quelques secondes au plus.

Volumes chiffrés sans la clé. Les volumes NTFS chiffrés BitLocker, VeraCrypt ou LUKS sont irrécupérables sans la clé. Le texte en clair n'a jamais touché le disque en premier lieu.

Fichiers effacés par un wiper compétent. sdelete -p 3 -z -s -q C:\target\* écrase les clusters du fichier trois fois, met à zéro l'espace libre et récurse. La récupération est impossible pour les clusters de données ; l'enregistrement MFT peut encore contenir des métadonnées et des données résidentes, mais le contenu substantiel du fichier est parti.

Données résidentes : le cas où la physique est de votre côté

Le cas des données résidentes continue de surprendre les analystes débutants. Les fichiers sous le seuil sont en ligne dans l'enregistrement MFT. L'enregistrement persiste jusqu'à ce que le slot soit réutilisé. La zone de données est sans importance ; si $Bitmap a été écrasé mille fois, les octets résidents sont toujours là.

J'ai un jour récupéré un fichier .config de 400 octets d'un disque dur qui avait été utilisé deux semaines de plus après la suppression et avait été en grande partie écrasé. Le slot MFT au-dessus de l'enregistrement 230 000 n'avait pas été réutilisé. Le fichier complet était là, résident, dans l'enregistrement. Cinq minutes de travail.

C'est pour cela que j'essaie toujours la récupération MFT d'abord pour les petits fichiers avant de toucher à la zone de données.

Questions fréquentes

Combien de temps les fichiers supprimés restent-ils récupérables sur NTFS ?

Jusqu'à ce que le slot MFT soit réutilisé et que les clusters de données soient écrasés. Sur un système chargé, c'est des heures. Sur un système oisif, ça peut être des mois. Il n'y a pas de minuterie fixe ; cela dépend de la pression d'allocation du volume.

Vider la corbeille rend-il la récupération plus difficile ?

Non. La corbeille est un répertoire caché ($Recycle.Bin) sur chaque volume. Vider supprime les fichiers au sens NTFS normal ; les mêmes techniques de récupération s'appliquent. Avant le vidage, le fichier est un fichier NTFS normal sous \$Recycle.Bin\<SID>\ avec un nom $R<ID> ; le compagnon $I<ID> consigne le chemin original.

Puis-je récupérer des fichiers supprimés avec del /F ou Shift+Delete ?

Oui. Ceux-ci sautent la corbeille mais suppriment de la même façon (IN_USE effacé, clusters libérés). L'enregistrement MFT est toujours là jusqu'à réutilisation.

Puis-je récupérer des fichiers d'un disque NTFS formaté ?

Un formatage rapide ne réécrit que le secteur de boot et une $MFT fraîche. La plupart des anciens clusters de données sont intacts et beaucoup des enregistrements MFT précédents (NTFS réutilise le même offset de départ) sont récupérables via du carving de signature des en-têtes FILE sur le volume brut. Un formatage complet met à zéro le volume ; ces données sont parties.

Et un fichier qui a été renommé avant la suppression ?

L'enregistrement MFT après suppression montre le nom final (celui d'après renommage). Le journal USN préserve la paire RENAME_OLD_NAME / RENAME_NEW_NAME, vous pouvez donc retrouver le nom original par là.

Lectures complémentaires

• Brian Carrier, File System Forensic Analysis. Chapitres sur la sémantique de suppression et la récupération sous NTFS.
• Documentation de fls -d et icat -r du Sleuth Kit. Flux de ligne de commande canonique pour l'énumération de fichiers supprimés et la récupération de données.
• Documentation PhotoRec. La référence pour le carving de signature quand la MFT n'est plus le bon outil.