jeudi 5 janvier 2017

Étude de NTFS: $Extend et $TXF_data

Par: Thomas Prud'Homme, Nabil Tahri et Youssef Bouzidi

Sommaire

Le présent rapport explore le dossier caché du système d’exploitation Windows, $Windows.~bt et les dossiers cachés du NTFS, $Extend et $TXF_data. Nous expliquons d’abord, dans une brève revue de littérature, ce que nous avons pu constater après une recherche sur les sujets, puis nous suivons avec une description du protocole expérimental que nous avons suivi lors des différents tests, les informations trouvées sur le système de fichier et finalement, un résultat des effets subis par les fichiers lorsque des opérations de base sont effectuées dans le volume est présenté.

Introduction

Dans le cadre du cours d’investigation numérique en informatique nous avions à réaliser un travail de session. Étant des étudiants au baccalauréat, on nous a chargés  d’investiguer différents type de dossiers et de fichiers faisant partie des artéfacts orphelins carrier en NTFS. Nous avions tout d’abord à investiguer sur le dossier nommé $Windows.~bt. En plus de celui-ci, on nous a assignés les dossiers $Extend et $TXF_data. Dans ce rapport, nous allons expliquer ce que nous avons découvert grâce à nos recherches sur ces dossiers. Nous procéderons avec une brève description du protocole expérimental, suivi des découvertes sur le système de fichiers. Avant d’offrir en conclusion une ouverture sur notre travail, nous présenterons quels sont les effets de simples opérations de base sur les fichiers.

Revue de littérature

À la suite de nos recherches initiales sur les différents dossiers, nous avons observé que notre premier sujet, soit $Windows.~bt, n’était pas un artéfact du système de fichier NTFS. La plus récente version du dossier serait en fait créée par Microsoft pour stocker les fichiers nécessaires à la mise-a-jour vers le système d’exploitation Windows 10. Bien que Microsoft ait utilisé ce dossier sur des versions antérieures, très peu, sinon aucune documentation n’est fournie sur le sujet. Après la mise-à-jour, Windows 10 y met les dossiers nécessaires pour retourner à l’ancien système d’exploitation si l’utilisateur en décide ainsi. Comme Microsoft n’a pas officiellement documenté ce dossier, quelques théories ont été proposées pour l’apparition de ce dossier. En effet, nous avons trouvé dans un article de Fatima Wahab sur ce dossier la proposition suivante : « It may have been created before the release date so as to relieve Microsoft’s servers of the stress of too many downloads the day of release. » (Wahab, 2015). Microsoft, ayant décidé d’implanter Windows 10 gratuitement sur toutes les machines qui utilisaient un de leurs systèmes d’exploitation, devait fournir via leurs serveurs plusieurs gigaoctets de fichiers nécessaires à la mise-à-jour et pour éviter un engorgement de leurs services, une pré-distribution de ces fichiers aurait été faite. Le dossier est aujourd’hui beaucoup plus difficile à retrouver, puisque Microsoft n’est plus dans une phase de déploiement. C’est pourquoi nous n’arrivons pas à reproduire le fichier comme objet d’expérience dans ce travail. Aussi, ne faisant pas partie du système de fichier, il est très improbable qu’une de nos actions auraient eu un impact sur son contenu.
Par la suite, nous nous sommes tournés vers le dossier $Extend et le fichier $TXF_data, qui proviennent tous deux du NTFS. Selon nos sources, le premier, $Extend, est utilisé pour contenir différentes extensions, notamment des quotas disques (« disk quotas »), des points d’aiguillages (« reparse points »), des identifiants objets (« object identifiers ») et un journal (« log »). C’est quatre extensions sont séparés respectivement dans les sous-fichiers $Quota, $Reparse, $ObjId et $UsnJrnl. Les quotas servent principalement à surveiller et contrôler l’espace disque utilisé pour un volume. Les points d’aiguillages quant à eux sont des collections de données définies par l’utilisateur et stocké dans le système de fichier. $ObjId contient un index de chaque fichier ayant un attribut $OBJECT_ID, soit un attribut 0x40 dans une entrée $MFTI. Finalement le $UsnJrnl est un journal qui surveille les changements apportés au volume dans les fichiers et les dossiers, et peut-être activé ou désactivé, dépendamment des versions de Windows. En effet, introduit dans Windows 2000, il ne fut pas utilisé sous le très populaire Windows XP, mais les plus récents systèmes Windows Vista et 7 auraient réintroduit son usage. Après plusieurs heures de recherche, nous avons découvert qu’il existait quelques autres sous-dossiers à $Extend, mais la documentation est plutôt vague, et leur utilisation est souvent questionné, mais sans réponse. Le tout sera revu plus en détail dans la section « Système de fichier ». Ainsi, lors de nos recherches, nous avons réussi à trouver beaucoup de documentations, autant de Microsoft que de sources externes, mais très peu avait des explications concrètes quant au fonctionnement de ce dossier. Comme Microsoft utilise un jargon très technique et que le dossier interagissait avec beaucoup d’éléments du NTFS, il a fallu lire sur le système de fichier pour réussir à comprendre leur utilité. Ce processus à quelque peu ralenti la recherche, nous obligeant souvent à aller voir quels étaient les fichiers ou éléments mentionnés dans l’article.
Le dernier élément, $TXF_data, est un peu plus obscure que le précédent. En effet, la documentation était peu claire, imprécise et difficile à trouver. Ayant trouvé quelques liens pointant celui-ci vers le NTFS transactionnel, un outil de Microsoft, nous avons orienté nos recherches dans ce sens. Le TxF (« Transactional NTFS ») permet des opérations augmentant l’assurance d’intégrité des données en protégeant contre les cas d’erreur des programmes. Mais, la documentation était peu présente puisque Microsoft incite les développeurs à utiliser d’autres méthodes sur leur site officiel : « Microsoft strongly recommends developers utilize alternative means to achieve your application’s needs. » (Microsoft Corporation, s.d.). Ainsi, le fruit de nos recherches s’est d’abord avéré maigre, puisqu’il n’existe que très peu de documentation et aussi, bien que tous liens mentionnent le fichier $TXF_data avec le NTFS transactionnel, la documentation officielle de Microsoft ne mentionne nulle part ce fichier. Pour avoir des résultats, nous nous sommes dirigés vers d’autres sources, sans trop de succès. Les sources externes à Microsoft semblent indiquer que $TXF_data serait un attribut indiquant qu’un fichier devrait être traité en NTFS transactionnel. Nous reviendrons plus en détail dans la section « Système de fichier ».

Protocole expérimental

Dans le cadre de notre recherche sur les éléments demandés, nous nous sommes tournés vers l’expérimentation sur le système de fichiers NTFS et les effets qu’auraient différentes opérations sur nos sujets. Nous avons décidé de mettre en œuvre un protocole strict nous permettant de bien observer et documenter les changements apportés à nos fichiers spécifiques selon les actions effectuées par l’utilisateur.
Nous avons tout d’abord aseptisé une clé USB afin de travailler sur une base décontaminée et ainsi obtenir des résultats plus clairs et plus précis. Ensuite, nous avons procédé avec le formatage de cette clé avec le système de fichier NTFS pour nous permettre de retrouver les dossiers et les fichiers qui font l’objet de cette étude. À l’aide de l’outil « FTK Imager », nous avons créé une image forensique de cette clé. Cette image vierge nous servira comme base pour comparer les futures images que nous prendrons après les différentes manipulations. La clé USB sera aseptisée et reformatée entre chaque test pour garder la validité de nos données. Les étapes d’aseptisation et de formatage seront donc les mêmes avant chaque opération, ainsi nous produiront, en plus de l’image vierge, neuf autres images ayant les propriétés suivantes : 
a)        Image vierge : Image de la clé USB aseptisée et formatée en NTFS produite grâce à « FTK imager » dans un format E01;
b)       Image contenant un fichier copié vide : Nous copierons un fichier vide sur la clé USB pour ensuite produire une image;
c)        Image contenant un fichier copié non vide : Nous copierons un fichier avec du contenu arbitraire ne dépassant pas la taille d’une grappe (« cluster »);
d)       Image contenant un fichier copié non vide : Cette fois, le fichier à copier sera de taille supérieure à une grappe, donc plus de 1024 octets;
e)        Image contenant un fichier créé vide : Nous créerons un nouveau fichier sans y ajouter de contenu directement sur la clé USB pour produire une nouvelle image;
f)        Image contenant un fichier créé non vide : on crée directement sur la clé USB un fichier ayant un contenu identique à l’image « c », de telle sorte que l’on ne dépasse pas la taille d’une grappe;
g)       Image contenant un fichier créé non vide : Pour cette image, nous utilisons un fichier avec le même contenu que dans l’image « d » et donc qui dépasse la taille d’une grappe, mais nous le créerons sur la clé USB.
h)       Image après la suppression d’un fichier vide : Nous avons supprimé un fichier vide avant de prendre l’image pour observer l’effet;
i)         Image après la suppression d’un fichier non vide : Avec un fichier comme celui utilisé pour « c » et « f », nous supprimons ce fichier de la clé USB;
j)         Image après la suppression d’un fichier non vide : Nous supprimerons un fichier avec une taille dépassant celle d’une grappe pour y observer les résultats.
Avec ces dix images où nous auront effectué des opérations de bases sur la clé USB aseptisée et formatée en NTFS, nous sommes d’avis que nous arriverons à tirer des conclusions sur les fonctions des différents fichiers à observer. Il faut aussi prendre en compte qu’il se peut que les opérations n’aient pas ou peu d’impacts sur les fichiers observés, dans quel cas il faudrait, lors d’une recherche future, appliquer différentes opérations plus complexes sur  la clé et en observer les effets. Suite à une recherche documentaire qui nous a permis permis d’entrevoir des pistes de solutions, notre protocole expérimental devait approfondir notre compréhension du système de ficher.

Système de fichier

Le système de fichier, comme mentionné précédemment dans le rapport, est le NTFS. Pour accomplir le travail demandé, nous allons nous concentrer sur les parties du système impliquant les éléments $Extend et $TXF_data et non sur $Windows.~bt, puisque seulement les deux premiers ont un rôle à jouer dans le NTFS. En ouvrant la clé USB sur le logiciel « FTK Imager », nous avons pu observer les différents dossiers installés par le formatage en NTFS. Bien qu’il y ait plusieurs fichiers avec plusieurs rôles distincts, il existe souvent plusieurs liens entre ces fichiers, rendant le tout une technologie complexe à analyser, en plus que ce système ne fut pas conçu pour être analyser directement par un utilisateur humain.
Nous allons commencer par présenter les captures d’écran de la clé USB aseptisée et formatée, sans qu’il y ait de modifications apportées par l’usager. Ainsi, comme nous n’avons aucune donnée sur le disque, certaines figures contiennent peu ou pas d’informations pertinentes. Les figures se retrouvent à l’annexe A:
a)        $Extend (figure 1, 2) : C’est un répertoire contenant des sous-répertoires et des fichiers de métadonnées. Ce dossier est appelé un dossier d’extensions par les différentes sources et les sous-fichiers servent à différents rôles. Puisque le dossier $Extend contient un nombre connue d’objets, il ne contient pas d’attribut dans ses métadonnées indiquant sa taille;
 
b)       $ObjId (figure 3) : Ce fichier est un index de tous les attributs d’identifiants d’objets en utilisation dans le volume;
1.        Un identifiant unique est assigné à ce fichier (« GUID Object Id »);
2.        Un identifiant de volume où le fichier a été créé (« GUID Birth Volume Id ») qui ne change jamais;
3.        L’identifiant original du fichier (« GUID Birth Object Id »), si jamais le fichier est modifié pour une raison quelconque, cette valeur reflète la valeur originale;
c)        $Quota (figure 4): Il assure la gestion des quotas des fichiers et des volumes. Ces quotas sont conservés par personne et par volume;
d)       $Reparse (figure 5): Contient une racine d'index et de l’allocation nommé $R;
e)        $TxF_data (figure 6, 7) : Attribut du NTFS pour le transactionnel. Comme il se retrouve à deux endroits sur la clé, nous avons tenté d’observer les deux. Bien que mentionné dans la revue de littérature, nos expériences n’ont pas su faire apparaître le journal $UsnJrnl. Ceci peut être dû à notre version de Windows, ou un attribut que nous n’arrivons pas à trouver.
 

Opérations et effets

Nous arrivons ici à l’un des objectifs principal de ce travail, soit d’appliquer plusieurs manipulations sur un volume formaté en NTFS pour ainsi constater les modifications répercutées et observables dans les fichiers ciblés par notre recherche. C’est pour cette raison que nous avons produit dix images avec différentes configurations. Les figures se retrouveront à l’annexe B où les carrés verts correspondent à la signature des entrées qui suivent.
1.        Opération de copie de fichier
a.        Fichier vide : la copie d’un fichier vide sur le disque ne modifie aucun des documents que nous observions.
b.       Fichier avec un contenu inférieur à 1024 octets (figure 1) : Seul le fichier $ObjId est modifié, on peut voir que des données sont ajoutés au fichier, notamment des identifiants du fichier. Tous les autres fichiers n’ont subis aucune modification.
c.        Fichier avec contenu de plus de 1024 octets (figure 1) : Comme précédemment, seul le fichier $ObjId est modifié, et de la même façon qu’avec un fichier inférieur à 1024 octets.
Nous pouvons ainsi déterminer que la copie d’un fichier sur la clé USB n’affecte que très peu les fichiers que nous surveillons. En effet, seul $ObjId est touché par ceci, mais le type de fichier ajouté importe peu. Il est intéressant de constater qu’un fichier vide n’apporte aucune modification; Nous pouvons avancer qu’il s’agit d’un fichier résident et donc qu’il n’a pas besoin d’être répertorié comme les autres. Il est logique que cette opération n’affecte que le fichier $ObjId, puisque selon nos recherches, il est le seul lié à la gestion des fichiers sur le volume.
2.        Opération de création de fichier
a.        Fichier vide (figure 2) : Seul l’objet $ObjId est affecté. Contrairement à la copie d’un fichier vide, la création ajoute une entrée dans ce fichier.
b.       Fichier avec un contenu de moins de 1024 octets (figure 2) : Encore une fois, seul le fichier $ObjId est affecté par la création d’un fichier. De plus, comme précédemment, la valeur du fichier $ObjId reste la même après la création à l’offset 0x14 (oxD000) du début du fichier.
c.        Fichier avec contenu de plus de 1024 octets (figure 2) : Pour notre dernière opération d’ajout, nous avons exactement le même résultat, c’est-à-dire que seul le fichier $ObjId est modifié et il prend la même valeur à l’offset 0x14 (oxD000) du début du fichier comme le montre la figure.
Bien que la création de fichiers directement sur le média change le fait que le fichier vide ajoute une entré dans $ObjId, les effets sont pratiquement les même que pour la copie. Il est intéressant de constater que de créer le fichier plutôt que de le copier apporte une si petite différence. Ainsi, nous pouvons donc déterminer que la copie ou la création sont gérée d’une manière très similaire au niveau du Système de fichier NTFS. Les propriétés que nous observons dans les images correspondent à celles notés dans la partie « Système de fichier ».
3.        Opération de suppression de fichier
a.        Fichier vide (figure 3) : Bien que le fichier ne soit plus sur la clé, nous observons qu’il existe toujours une entré dans $ObjId. Il est important de noter qu’il y avait une entré avant la suppression, puisque le fichier avait été créé directement sur la clé et comme nous l’avons vu précédemment, ceci ajoutait une entré.
b.       Fichier avec un contenu inférieur à 1024 octets (figure 3) : La même valeur se retrouve dans le fichier $ObjId à l’offset 0x14 (oxD000) du début du fichier.
c.        Fichier avec un contenue supérieur à 1024 octets (figure 3) : Même comportement que les deux opérations de suppression.
La suppression apporte une modification au document, lié au changement d’état du fichier. En effet, nous pouvons observer que le fichier laisse des traces dans le système de fichier, et ce malgré sa suppression. Il faudrait explorer plus en détail d’autres fichiers pour réussir à reconstruire ce fichier ou du moins son historique, puisque le fichier $ObjId ne contient que peu d’informations à ce sujet.
Les opérations, menées selon notre protocole expérimental, nous ont peu aidées à comprendre le comportement des fichiers à observer. Effectivement, avec très peu de modifications suite aux opérations, il faudrait trouver des opérations plus complexes à effectuer sur des fichiers, ou observer ces fichiers selon différents volumes, utilisateurs ou toutes autres configurations susceptibles de les modifier. Puisque le fichier $ObjId contient des identifiants (GUID), il est difficile de bien discerner l’information des attributs et donc d’analyser en profondeur l’objet. Le $TxF_data quant à lui semblait beaucoup plus difficile à modifier, puisque, comme mentionné plus haut, il utilise une technologie de Microsoft qu’eux-mêmes désapprouve. Ainsi dans le cadre du projet, nous n’avons pas tenté de manipulations aussi complexes, puisque ceci dépassait les limites de notre mandat.
Ainsi, nous sommes déçus des résultats, puisque ceux-ci nous ont apportés peu de réponses. Malgré tout, il est important de noter que le but de la recherche se limitait à des opérations simples et donc qu’il était difficile de prévoir des résultats complexes.

Conclusion

Pour conclure, ce travail nous a permis d’explorer plus en détail les éléments cachés à l’utilisateur et contenus dans le système de fichier NTFS, plus précisément le contenu des fichiers $Extend, $TXF_data ainsi que le dossier provenant du système d’exploitation Windows, $Windows.~bt. Nous avons eu l’occasion de constater certaines modifications dans le contenu des éléments du NTFS et avons retracé leurs réactions à certaines manipulations de bases effectuées sur le volume.
Bien que nous ayons recherché, expérimenté et décortiqué les trois éléments, beaucoup de points restent à éclaircir. Premièrement, il existe beaucoup d’opérations plus complexes que nous pourrions effectuer sur les fichiers, comme par exemple changer les permissions, ou simplement déplacer le fichier à l’intérieur du volume avec différents répertoires. Toutes ces opérations devraient avoir des effets sur les fichiers que nous avons observés, et il est de notre avis que nous pourrions trouver plusieurs attributs à l’intérieur des fichiers qui seraient modifiés. Aussi, bien que des manipulations aient été faites sur les fichiers et dossiers accessibles à l’utilisateur, nous n’avons pas exploré les effets de manipulations sur les fichiers à l’étude eux-mêmes. Découvrir et documenter les effets de modifications ou de suppressions dans les dossiers $Extend et $TXF_data pourrait faire l’objet d’une présentation future. Bien que nous soyons d’avis que la corruption de tels documents rende le système très instable au point de le rendre inutile, il serait très intéressant de voir ce que nous pouvons modifier sans causer un arrêt total du système, ou observer tout autre effet attribuable à leur contamination.





Médiagraphie

Medeiros, J. (2008). NTFS Forensics: A Programmers View of Raw Filesystem Data Extraction. http://grayscale-research.org/new/pdfs/NTFS%20forensics.pdf: Grayscale Research., Consulté le 28 Mars 2016
Microsoft Corporation. (2003, March 28). How NTFS Works. Récupéré sur Microsoft TechNet: https://technet.microsoft.com/en-ca/library/cc781134(v=ws.10).aspx, Consulté le 31 Mars 2016
Microsoft Corporation. (2003, Mars 28). What Are Disk Quotas? Retrieved from Microsoft TechNet: https://technet.microsoft.com/en-ca/library/cc781892(v=ws.10).aspx, Consulté le 31 Mars 2016
Microsoft Corporation. (n.d.). Reparse Point. Retrieved from Microsoft Developer resources: https://msdn.microsoft.com/en-ca/library/windows/desktop/aa365503(v=vs.85).aspx, Consulté le 31 Mars 2016
Microsoft Corporation. (n.d.). Transactional NTFS (TxF). Retrieved from Microsoft Developer resources: https://msdn.microsoft.com/en-us/library/windows/desktop/aa364407(v=vs.85).aspx, Consulté le 28 Mars 2016
Multiple. (2015, Novembre 5). New Technology File System (NTFS). Retrieved from ForensicsWiki: http://www.forensicswiki.org/wiki/New_Technology_File_System_(NTFS), Consulté le 28 Mars 2016
Russon, R. (2004). NTFS - Home. Retrieved from NTFS Documentation: http://0cch.com/ntfsdoc/index.html, Consulté le 28 Mars 2016
Russon, R., & Fledel, Y. (2008). NTFS Documentation. Retrieved from Dubeyko: http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf, Consulté le 31 Mars 2016
Schicht, J. (2015, Octobre 27). LogFileParser. Retrieved from Github: https://github.com/jschicht/LogFileParser, Consulté le 31 Mars 2016
Wahab, F. (2015, Septembre 07). What Is The $WINDOWS.~BT Folder On My Hard Drive? Retrieved from addictivetips: http://www.addictivetips.com/windows-tips/what-is-the-windows-bt-folder-on-my-hard-drive/, Consulté le 31 Mars 2016








Annexe A



 

Figure 1 : Dossier $Extend de la clé USB vierge dans « FTX Imager »


 

Figure 2 : Capture d’écran d’« FTK Imager » avec les métadonnées d’$Extend
Rouge : Début de la première entrée
Orangé : Date (en Windows 64 bits petit-boutiste 29-mars-2016 à 11h41)
Vert : Longueur d’entrée du répertoire $Extend
Bleu : Nom de fichier ($Quota)
Jaune : Longueur des entrées $ObjId, $Quota et $Reparse








Figure 3 : Capture d’écran d’« FTK Imager » avec les métadonnées de $ObjId

 



Figure 4 : Capture d’écran d’« FTK Imager » avec les métadonnées de $Quota



 
 Figure 5 : Capture d’écran d’« FTK Imager » avec les métadonnées de $Reparse



 

Figure 6 : Capture d’écran d’« FTK Imager » avec les métadonnées de $Txf_data sous [root]/$Extend/$RmMetadata/$Txf/
 


Figure 7 : Capture d’écran d’« FTK Imager » avec les métadonnées de $Txf_data sous [root]/
 


Annexe B

 
 

Figure 1 : $ObjId après avoir copié un fichier de moins 1024 octets et un fichier de plus de 1024 octets.
 


Figure 2 : Effet de création de fichier sur la clé USB sur le fichier $ObjId
 
 

Figure 3 : Effet de la suppression dans le fichier $ObjId
Vert : Adresse du dernier Offset
Rouge : Attribut d’un fichier supprimé