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é