Métadonnées NTFS après un formatage rapide : une analyse réalisée avec WinHex
Les métadonnées NTFS après un formatage rapide décrivent un système de fichiers nouvellement initialisé, tandis que certains enregistrements et contenus de fichiers provenant du système de fichiers précédent peuvent rester lisibles en arrière-plan. Windows crée une nouvelle table de fichiers maître (MFT) et une nouvelle structure de répertoires ; il ne se contente pas de masquer tous les anciens noms de fichiers. La récupération est réussie lorsque suffisamment de métadonnées d'origine et les données qu'elles décrivent ont été préservées et restent accessibles.
WinHex permet de distinguer ces cas en affichant les champs du secteur d'amorçage, les enregistrements MFT et les correspondances entre les blocs de données. Cet article examine un cas de formatage rapide NTFS vers NTFS ainsi qu'un exemple distinct de reconstruction de fragments de la table MFT. Ces calculs s'appliquent aux structures enregistrées, et non à tous les volumes Windows. Le comportement de « discard » des SSD et les écritures ultérieures peuvent produire des résultats très différents.
Table des matières
1. Quels sont les changements apportés par le formatage rapide sous NTFS ?
Les Système de fichiers NTFS organise les fichiers à l'aide de fichiers de métadonnées, d'index de répertoires et de mappages de clusters. Un formatage rapide crée une nouvelle instance de ces structures.
Structure | Rôle après un formatage rapide | Conséquences pour le redressement |
Secteur d'amorçage du volume et sa sauvegarde | Décrivez le volume récemment formaté | Les pointeurs MFT actuels risquent de ne plus pouvoir localiser l'ancienne table |
$MFT et répertoire racine | Décrivez le nouveau système de fichiers et ses objets initiaux | Les anciens noms de fichiers et les relations entre répertoires disparaissent lors de la navigation normale |
| Suivi des enregistrements alloués dans la nouvelle table de fichiers maîtres (MFT) | Ne répertorie pas les documents conservés en dehors de ce tableau |
1 TP 14 T Bitmap | Suivi des groupes de pistes alloués dans le nouveau volume | Les groupes précédemment occupés peuvent redevenir disponibles pour être réutilisés |
$MFTMirr et autres métadonnées système | Prise en charge du système de fichiers nouvellement initialisé | Leurs écritures peuvent écraser des métadonnées ou le contenu de fichiers plus anciens |
Anciens emplacements des fichiers de données | Peut conserver du contenu lisible en dehors des plages écrasées ou supprimées | Il faut vérifier la viabilité plutôt que de la tenir pour acquise |
Les Tableau du fichier principal est lui-même un fichier. Son flux $DATA, qui ne porte pas de nom, contient des enregistrements de fichiers ; sa carte de bits décrit l'allocation des enregistrements. Le fichier $Bitmap, distinct, décrit l'allocation des clusters sur l'ensemble du volume. Confondre ces deux cartes de bits conduit à des conclusions erronées quant aux données qui ont été conservées.
Le formatage d'une partition existante diffère également de la suppression de son entrée dans la table de partition. Une opération de formatage de volume reconstruit le système de fichiers à l'intérieur du volume sélectionné ; la suppression d'une partition concerne quant à elle la structure du disque en dehors de celui-ci.
2. Lire le secteur d'amorçage d'origine dans WinHex
Pour effectuer une comparaison hexadécimale « avant-après » d'un formatage NTFS, conservez une image du secteur avant le formatage et comparez-la avec une image capturée après celui-ci. Sur une source déjà formatée, travaillez à partir d'une image et de toutes les captures antérieures disponibles. Ne répétez pas le formatage pour reproduire l'événement.
Les enregistreur de démarrage du volume fournit les paramètres nécessaires à l'interprétation des adresses de cluster.
Extrait hexadécimal original du secteur d'amorçage issu du dossier WinHex. Les encadrés rouges indiquent les champs relatifs à la taille du secteur, à la taille du cluster et à l'emplacement de la MFT.
Décalage du secteur d'amorçage | Octets enregistrés | Interprétation |
|
| 512 octets par secteur logique |
|
| Huit secteurs par groupe |
|
| $MFT commence à la LCN 175 724 968 |
|
| $MFTMirr commence à la LCN 167 336 228 |
|
| Valeur signée −10 : la taille de l'enregistrement est de 2¹⁰ = 1 024 octets |
Les entiers multi-octets utilisent l'ordre des octets « little-endian ». Le taille de l'unité d'allocation est donc :
- 512 × 8 = 4 096 octets par cluster
LCN désigne un numéro de cluster lié au volume. Par conséquent :
- Secteur relatif au volume MFT d'origine = 175 724 968 × 8
- = 1,405,799,744
- Décalage en octets relatif au volume MFT d'origine = 175 724 968 × 4 096
- = 719,769,468,928
Lorsque vous examinez une image de disque entier, ajoutez le décalage en octets du début du volume. Lorsque vous examinez une image ne contenant qu’un seul volume, ne l’ajoutez pas à nouveau. Le contexte d’adressage affiché par WinHex doit correspondre au calcul effectué.
Le secteur d'amorçage identifie la première extension de la table MFT. Il ne décrit pas chaque fragment de la table.
3. Décoder les données relatives aux non-résidents du fichier MFT d'origine
Sur le site MFT d'origine, validez l'enregistrement 0 et localisez son attribut $DATA sans nom, puis saisissez 0x80. Un attribut « non-résident » stocke des informations de mappage plutôt que l'intégralité de son contenu au sein de l'enregistrement.
Les notes de dossier situent cet attribut à l'offset de l'enregistrement 0x100. Son octet de forme apparaît donc à l'adresse 0x108; la valeur 01 signifie « non-résident ». Ces décalages absolus sont propres à cet enregistrement. D'autres enregistrements peuvent placer cet attribut à un autre emplacement.
Utilisez des décalages par rapport au début de l'attribut lors de l'interprétation d'un autre enregistrement :
Décalage relatif | Champ d'application |
| Formulaire pour les résidents et les non-résidents |
| Numéro de cluster virtuel le plus bas, ou VCN |
| VCN le plus élevé, inclus |
| Décalage par rapport au tableau des paires de correspondance |
| Longueur allouée |
| Taille logique du fichier |
| Longueur valide des données |
Lisez les trois champs de taille séparément. La longueur allouée correspond à l'espace de stockage réservé, la taille logique définit la longueur du flux, et la longueur des données valides décrit les données initialisées. Ces valeurs ne sont pas nécessairement égales.
Pour une plage couvrant les VCN de 0 à 98 431, le nombre de clusters est de 98 432, et non de 98 431. La configuration à deux passages enregistrée donne :
Exécuter | Nombre de grappes | Signé LCN delta | Démarrage de LCN | Emplacements d'enregistrements logiques de 1 024 octets chacun |
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 |
La deuxième adresse est relative à celle de l'exécution précédente : début LCN :
- 175,724,968 + 83,118,309 = 258,843,277
- (75 096 + 23 336) × 4 096 = 403 177 472 octets
- 403 177 472 ÷ 1 024 = 393 728 emplacements d'enregistrements
Il s'agit d'emplacements adressables, et non d'un décompte de fichiers actifs. Certains enregistrements peuvent être inutilisés, et un fichier peut nécessiter plusieurs enregistrements.
Les en-têtes de série enregistrés 43 et 42 décrire les largeurs des champs. Pour 43, la longueur occupe trois octets et le delta LCN quatre ; pour 42, la longueur occupe deux octets et le delta quatre. Considérez le delta LCN comme un nombre signé, car des fragments ultérieurs peuvent se trouver plus tôt sur le volume.
La taille de l'espace ainsi obtenu est de 384,5 MiB. L'affichage arrondi à “ 385 Mo ” ne permet pas à lui seul de déterminer une taille d'allocation différente ni de prouver que des clusters supplémentaires ont été réservés.
4. Comparer le nouveau MFT à l'ancienne mise en page
Les notes du dossier indiquent un MFT de type « post-format » commençant à l'adresse LCN 786 432, d'une étendue de 180 clusters. En supposant une taille de cluster de 4 096 octets, comme indiqué :
- Nouvel offset d'octet de départ du MFT = 786 432 × 4 096
- = 3,221,225,472
- Nouvelle taille de l'étendue = 180 × 4 096 = 737 280 octets
Le nouveau point de départ se trouve à 3 GiB dans le volume. Cette adresse est une observation tirée de ce cas particulier ; il ne s'agit pas d'un emplacement NTFS obligatoire.
Biens immobiliers | Mise en page d'origine | Mise en page du format de publication consignée dans les notes |
Démarrage de MFT LCN | 175,724,968 | 786,432 |
Extensions MFT enregistrées | Deux | Un |
Étendue de la couverture | 98 432 grappes | 180 grappes |
Capacité pour la taille d'enregistrement indiquée | 393 728 emplacements | 720 emplacements |
Les notes mentionnent également les enregistrements 0 à 717. Cela représente 718 enregistrements, soit 735 232 octets. Ce chiffre est compatible avec une allocation suffisamment grande pour 720 emplacements, mais ne permet pas de déterminer si le nombre 718 correspond à la longueur logique, à la longueur initialisée ou au nombre d’enregistrements inspectés. Ces champs nécessitent les octets d'attribut sous-jacents.
Le changement important réside dans le fait que Windows utilise désormais la nouvelle table. La taille réduite de la nouvelle MFT permet pas Cela signifie que l'ancienne table a été physiquement tronquée sur place. Ses anciens emplacements doivent faire l'objet d'une inspection distincte.
Pour déterminer si la table MFT du système de fichiers NTFS a été écrasée lors du formatage, comparez les segments d'origine de la MFT avec toutes les nouvelles écritures de métadonnées et les allocations ultérieures. Un pointeur modifié prouve qu'une référence a été modifiée ; une comparaison d'octets permet de constater un écrasement à un emplacement précis. La relocalisation à elle seule ne prouve ni la préservation intégrale ni la perte totale.
5. Reconstituer une table MFT fragmentée à partir des enregistrements conservés
La fragmentation de la table MFT s'accentue à mesure que la table s'agrandit et que l'espace contigu vient à manquer. Le système de fichiers NTFS réserve une zone MFT afin de réduire la fragmentation, mais cela ne garantit pas l'existence d'une seule extension. L'agrandissement de la table peut entraîner l'allocation de fragments avant ou après l'extension actuelle.
Un autre exemple de reconstitution, présenté dans la documentation relative au dossier, illustre cette disposition à trois lignes. Il ne faut pas le confondre avec le cas précédent à deux lignes, comme si les deux décrivaient le même tableau.
Exécuter | Emplacements d'enregistrements logiques | Démarrage de LCN | Différence par rapport au début de la série précédente | Grappes |
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 |
Chaque cluster de 4 096 octets contient quatre emplacements de 1 024 octets. Cela explique ces deux limites :
- 51 232 × 4 = 204 928 emplacements
- 204 928 + (10 915 × 4) = 248 588
- 9 274 281 − 416 173 = 8 858 108
Au total, ces exécutions couvrent 94 098 clusters, soit 385 425 408 octets. La valeur finale du VCN est de 94 097.
Rechercher et valider les dossiers des candidats
Les notes de reconstitution décrivent la recherche de l'enregistrement n° 204 928, le rejet d'un candidat jugé non valide et l'identification d'un autre candidat considéré comme valide. Un numéro correspondant ou le FICHIER La signature seule ne suffit pas.
Sur une image en lecture seule :
- Rechercher
FICHIERles signatures, y compris celles situées en dehors de la table MFT actuelle. Une analyse limitée à la nouvelle table ne permettra pas de détecter les enregistrements détachés. - Vérifiez les limites des enregistrements, leur longueur, les décalages des attributs et la longueur de ces derniers.
- Vérifiez la validité du tableau de séquences de mise à jour avant d'interpréter les octets des enregistrements protégés. Dans les enregistrements de 1 024 octets, ces vérifications portent sur les extrémités des deux segments de 512 octets.
- Restaurez les mots de fin d'annonce enregistrés dans la mémoire de l'analyseur avant d'analyser les attributs au-delà de ces limites ; ne modifiez pas l'image de preuve.
- Comparez les enregistrements voisins, leur numérotation (le cas échéant), leurs noms, leurs références parentales et leurs numéros de séquence. Écartez les relations peu plausibles ou obsolètes.
Lorsqu'un ancien enregistrement 0 encore présent fournit une liste d'exécution valide, utilisez ce mappage. S'il est manquant, la reconstruction des extensions à partir des séquences d'enregistrements reste une hypothèse nécessitant des vérifications supplémentaires. La présence d'enregistrements vides dans une région ne prouve pas à elle seule qu'il n'existe aucun fragment ultérieur.
Remontez la table logique séparément
Copiez les extensions validées dans un fichier d'analyse distinct, en respectant l'ordre VCN. Ne les triez pas par ordre croissant de LCN : la troisième exécution mentionnée ci-dessus précède la deuxième sur le disque, mais la suit d'un point de vue logique.
Pour le numéro d'enregistrement n, taille de l'enregistrement R, et la taille du cluster C:
- VCN = floor(n × R ÷ C)
- Décalage au sein d'un cluster = (n × R) mod C
- LCN = LCN de départ de la série + (VCN − VCN de départ de la série)
Pour l'enregistrement 204 929 de l'exemple à trois exécutions, le VCN est égal à 51 232 et son décalage au sein du cluster est de 1 024 octets. Son adresse relative au volume est donc :
- 9 274 281 × 4 096 + 1 024 = 37 987 456 000 octets
Cette mise en correspondance permet de récupérer une adresse, et non un fichier. L'enregistrement et les données auxquelles il fait référence doivent encore être validés.
6. Récupérer le contenu d'un fichier grâce aux anciens attributs
Une fois qu'un enregistrement de fichier existant a été identifié, son attribut $DATA détermine la méthode d'extraction.
Données relatives aux résidents : lire l'offset et la longueur de la valeur de l'attribut, puis exporter cette valeur à partir de l'enregistrement validé et restauré par la fonction de correction. Les petits fichiers peuvent perdre leur contenu lorsque leurs enregistrements MFT sont écrasés, car c'est là que ce contenu est stocké.
Données relatives aux non-résidents ordinaires : décoder la liste d'exécution propre au fichier, lire chaque extension à partir de l'image du volume d'origine, assembler les octets dans l'ordre VCN et ajuster la taille du fichier de sortie à celle du fichier logique. La liste d'exécution de la MFT permet de localiser les enregistrements de fichiers ; elle ne remplace pas le mappage entre les fichiers et les données propre à chaque utilisateur.
Suivez les références $ATTRIBUTE_LIST lorsque les attributs s'étendent à d'autres enregistrements. Les flux clairsemés et compressés nécessitent leurs règles de décodage respectives. Le contenu chiffré nécessite toujours le matériel de déchiffrement approprié. Une simple concaténation ne suffit pas dans ces cas-là.
La restauration des répertoires nécessite une attention particulière. Un nom de fichier peut subsister alors que son répertoire parent a disparu. Ne reconstituez les chemins d'accès que lorsque les références et les numéros de séquence concordent ; dans le cas contraire, conservez le fichier orphelin plutôt que d'inventer une relation avec un dossier.
Enregistrez les fichiers extraits sur un autre périphérique physique. Modifier le nouveau secteur d'amorçage pour qu'il pointe vers une ancienne table MFT ne revient pas à récupérer les fichiers : les tables d'allocation, les index, les enregistrements système et autres métadonnées peuvent appartenir à différentes instances du système de fichiers.
7. Pourquoi le rétablissement peut réussir… et pourquoi il peut échouer
La récupération basée sur les métadonnées peut aboutir car une ancienne entrée conserve l'identité d'un fichier, sa taille logique et ses mappages de données, tandis que les contenus mappés restent lisibles. Un outil de récupération peut suivre ces relations même si Windows ne les inclut plus dans son espace de noms actif.
En cas d'enregistrements manquants, l'extraction basée sur les signatures permet parfois d'identifier directement le contenu des fichiers. Cette méthode entraîne généralement la perte des noms de fichiers d'origine et de la structure des répertoires, et s'avère moins fiable pour les fichiers fragmentés. X-Ways distingue la recherche d'enregistrements NTFS en dehors de la MFT actuelle de la recherche d'en-têtes de fichiers, reflétant ainsi ces différentes méthodes de récupération.
La récupération s'avère plus difficile lorsque de nouvelles métadonnées recouvrent les enregistrements d'origine, que des fichiers ultérieurs réutilisent d'anciens clusters ou que les correspondances de fragmentation font défaut. Un nom de fichier valide ne garantit pas l'intégrité du contenu ; une première page ou un en-tête vidéo reconnaissable ne prouve pas que les fragments suivants ont été préservés.
Les SSD ajoutent une condition supplémentaire. Le formatage sous Windows peut envoyer des notifications TRIM/suppression ; Microsoft’s format La documentation comprend /NoTrim pour les supprimer. Il s'agit d'une option de formatage, et non d'une solution après une perte de données. Selon le périphérique et le chemin de stockage, les plages supprimées peuvent cesser de renvoyer les octets d'origine, même en l'absence d'un écrasement classique visible dans WinHex. Le formatage rapide ne garantit donc pas systématiquement la récupérabilité des données.
8. Vérifier les données extraites avant de réutiliser le disque
Conservez l'image source et la carte d'étendue jusqu'à ce que la validation soit terminée. Pour un processus pratique de numérisation et d'exportation, consultez récupération de fichiers à partir d'un disque dur formaté.
Vérifiez les fichiers récupérés en les comparant à un inventaire pré-formatage, le cas échéant. Comparez les noms, les tailles, les relations entre les dossiers et les hachages avec ceux des originaux connus. En l'absence de hachages de référence, ouvrez les documents et examinez leurs pages, testez les archives, affichez les images en pleine résolution et lisez les fichiers vidéo dans leur intégralité.
Enregistrez les fichiers endommagés ou manquants séparément des fichiers validés. Une table MFT reconstituée sans erreur d'analyse permet d'établir des métadonnées lisibles ; l'exportation de contenus exploitables permet de confirmer la récupération des fichiers. Une récupération complète nécessite de prendre en compte l'ensemble de données attendu.
FAQ
Le formatage rapide écrase-t-il l'intégralité de la table MFT du système de fichiers NTFS ?
Les fichiers peuvent-ils subsister lorsque leurs enregistrements MFT ont disparu ?
Le miroir MFT permet-il de restaurer tous les enregistrements de fichiers ?
Un bit à zéro dans le bitmap du nouveau volume signifie-t-il que les anciennes données ont été effacées ?
Un ancien enregistrement MFT peut-il encore avoir son indicateur « en cours d'utilisation » activé ?
La restauration de l'ancien secteur d'amorçage annulera-t-elle le formatage ?
