Auteurs
Francis St-Amour
Idir Kacha
Louis Pépin
Sommaire
Le système de fichier NTFS est un système de fichier
propriétaire utilisé par les systèmes d’exploitation Microsoft depuis plusieurs
années. Étant propriétaire, on ne connait pas tout de son fonctionnement. Dans
ce rapport, nous allons donc explorer le fonctionnement de ce système de
fichiers en expérimentant avec les artéfacts qui le composent.
Introduction
La capacité d’un investigateur numérique à dénicher des
preuves peut faire toute la différence entre une enquête fructueuse et une
enquête désastreuse. Cette capacité peut être vue comme une corrélation entre
les connaissances de l’investigateur ainsi que son expérience. Le présent écrit
relatera le parcours de réalisation de notre travail de session qui vise à
construire aussi bien nos connaissances que notre expérience à l’égard d’un
élément central de l’investigation numérique : le système de fichiers. Nous y
présenterons donc la littérature qui nous a principalement servi de point de
départ et les expérimentations qui ont poussé plus loin notre compréhension du
système NTFS, plus particulièrement des artéfacts orphelins de Carrier suivants
: $AttrDef, $BitMap, $MFTmirr, $Volume et $Boot. Nous développerons sur nos
trouvailles, conclurons et présenterons notre médiagraphie ensuite.
Revue de littérature
Pour mettre en place des expériences pertinentes afin
d’expliquer les particularités et pousser nos connaissances des artéfacts
orphelins de Carrier pour le système de fichier NTFS, il nous a été important
de procéder à une solide revue documentaire.
Pour commencer, dans le livre «
File System Forensic Analysis » de Brian Carrier (2004), on trouve des
informations pertinentes sur le fonctionnement des systèmes de fichiers en
général. Entre autre, on lit que le fichier $AttrDef regroupe la liste des attributs
supportés par le système de fichiers représentés par leur nom, identificateur numérique, taille
minimum/maximum, et aussi des fanions de 4 bytes. Ces attributs sont utilisés
par d’autres fichiers de métadonnées tels que $MFT et $Volume, $BOOT afin de
regrouper des informations sur les fichiers (permissions, nom du volume, numéro
de série, etc…) et de plus, $AttrDef est conçu de sorte qu’il permet à chaque SYSTÈME
DE FICHIERS de posséder ses propres attributs, c’est-à-dire, qu’il est
extensible. Par contre, il n’accepte que des multiples de 160 octets. (Dave
Hull, 2009)
Encore dans le livre de Carrier,
on peut comprendre que $MFTMirr permet de stocker des sauvegardes qui peuvent
être récupérées lorsque $MFT est corrompu. Il nous explique que l’attribut
$DATA alloue des grappes au milieu du système de fichiers et sauvegarde les 4
premières entrées de MFT ($MFT, $MFTMirr, $LogFile, $VOLUME), ainsi il est
possible à l’outil de récupération d’utiliser la taille du volume et de
calculer le centre des grappes et lire la sauvegardes. Il est également à noter
que chaque entrée MFT possède une signature particulière qui permet de la
valider.
En ce qui concerne $Boot, il est
situé à l’entré 7 de MFT et son attribut $Data est situé dans le premier
secteur physique du volume pour permettre de démarrer le système. Le secteur de
démarrage renferme des informations basiques à propos de la taille de chaque
grappe, le nombre de secteur, l’adresse de grappe de départ, et la taille de
chaque entrée MFT. C’est ce qui force $Data à être non-résident. Microsoft alloue les seize(16) premiers
secteurs pour $Boot, par contre, la seconde moitié contient seulement des
zéros, (Carrier, 2004) c’est ce qui le différentie du système FAT avec lequel
il partage les 40 premiers octets. (Richard Russon et Yuval Fledel).
$Volume est décrit comme étant le
seul qui contient les attributs $VOLUME_INFORMATION (contient la version du
NTFS et le statut de propreté du volume) et $VOLUME_NAME (le nom du volume en
UNICODE). $Volume peut être trouvé à l’entré 3 de $MFT. (Jeff Hughes, 2010)
Structure de base du système de fichiers
Le système de fichier NTFS est
composé de plusieurs artéfacts décrivant le contenu et les capacités du volume.
Le point d’entré est le fichier $boot, qui est toujours situé au début du
volume afin qu’il puisse être trouvé et celui-ci contient l’information qui
pointe vers le fichier le plus important du système de fichier: le $MFT. Ce
fichier constitue un index de l’ensemble des fichiers et contient les attributs
de chacun.
D’autre part, Microsoft et aussi
à l’origine du système de fichier FAT, il est donc intéressant de comparer très
brièvement ces deux systèmes de fichier: les deux regroupent les secteurs
physiques en grappes logiques, mais les limitations sont différentes. Par
exemple, la table FAT doit être proportionnelle à la taille du système de
fichier, alors que la $MFT est proportionnelle au nombre de fichier dans le
système.
Protocole expérimental suivi
Les artéfacts à l’étude
permettent de maintenir la cohérence du système de fichiers, ceci implique
qu’ils changent dynamiquement de contenu et parfois de taille pour refléter
fidèlement l’état du système.
L’état du système est ici
déterminé par les fichiers qu’il contient et cette observation a orienté notre
approche pour observer le fonctionnement des différents artéfacts. En effet, le
protocole expérimental sera très similaire pour tous les artéfacts : nous
commencerons avec un disque fraichement asceptisé et formaté en NTFS puis nous
effectuons des manipulations sur des fichiers dans le système en prenant bien
soin de noter les changements dans l’artéfact visé. Ces manipulations consisteront
aussi bien en l’ajout que la suppression ou la modification de fichiers,
principalement de simples fichiers texte.
Il aurait été pratique de
disposer de périphériques offrant un petit espace de stockage, mais la plus
petite mémoire externe dont nous disposons fait 8Go et l’aseptisation prend un
certain temps. Pour gagner du temps, nous avons créé une image du support juste
après aseptisation et formatage pour facilement pouvoir revenir au point de
départ, sans avoir à patienter trop longtemps.
Le protocole se résume ainsi en trois principales étapes :
1. Initialiser
le périphérique avec l’image de départ
2. Effectuer
des manipulations
3. Observer les
résultats
La seconde étape est celle où la
plus grande partie du travail se trouve, avec des manipulations spécifiques
pour chaque artéfact et pour chaque but recherché. Nous allons résumer aussi
succinctement que possible cette seconde étape pour chacun de nos cinq
artéfacts.
1.
$AttrDef : Contient la liste des types d’attributs supporté
par le système de fichier. Il ne change donc jamais pour un même volume, mais
peut être sujet à des changements selon les versions de NTFS. Pour confirmer,
on a procédé à ces manipulation:
a.
Ajout d’un fichier resident.
b.
Changer nom de volume
c.
Changer les permissions d’un fichier
d.
Formatage en augmentant la taille de l’unité
d’allocation
2.
$Bitmap : Peut être vu comme une cartographie de
l’espace de stockage. Nous avons donc conservé une version de l’artéfact avant
et après chaque manipulation pour fins de comparaisons et nous avons ajouté des
fichiers de différentes tailles dans le système pour observer les changements.
a.
Ajout d’un fichier résident (n’occupera pas de place dans
l’espace des données de la partition).
b.
Ajout d’un fichier non résident (plus grand, occupera
de l’espace dans l’espace des données de la partition).
c.
Ajout de nombreux fichiers non-résidents.
d.
Supprimer le/les
plus ancien(s) fichier(s) non-résident(s).
3.
$MFTmirr : Sert à réparer $MFT lorsque le fichier est
corrompu.
a.
Corrompre $MFT puis réparer avec $MFTmirr
b.
Corrompre $MFTmirr puis le réparer avec $MFT
4.
$Volume : Ce fichier indique des informations basiques
sur le volume comme son nom, sa version de système de fichiers, ses fanions et
identifiants. Les manipulations viseront donc non seulement à observer comment
son contenu réagis aux stimuli, mais aussi à observer comment son altération
affecte le volume.
a.
Formater le média avec différents noms et tailles de
secteurs
b.
Modifier le fichier et remonter le média
5.
$Boot : Ce fichier sert à lancer (boot en anglais) le système d’exploitation, il est lui-même chargé
par le bootloader sité dans le MBR.
Nous nous contenterons d’examiner l’impact de la taille du système de fichier a
sur cet artéfact, car expérimenter avec le code contenu dans ce fichier système
serait très complexe et dépasserait le cadre de ce rapport.
a.
Formater le média avec différentes taille de système de
fichiers et comparer les différents artéfacts $boot généré.
Résultats
$AttrDef
On remarque qu’aucune des modifications n’a apporte de
changement sur le fichier $AttrDef, excepte la taille d’allocation qui a fait
en sorte que la taille du fichier $AttrDef soit plus grande et avec un bourrage
de zeros a la fin de son contenu. Quant aux autres changement, ils apportent
une nouvelle entrée (changement a) au
niveau du fichier $MFT, une modification sur l’attribut ($VOLUME_NAME), et une
autre sur l’attribut ($STANDARD_VOLUME).
$Bitmap
Après le formatage, nous avons constaté qu’une partie des
bits du fichier $Bitmap étaient à 1.
Après avoir ajouté un petit
fichier résident, une comparaison du nouveau fichier $Bitmap avec l’ancien n’a
révélé aucune différence.
Nous avons ensuite ajouté un
fichier assez gros pour ne pas résider dans le fichier $MFT et cette fois, une
comparaison entre le nouveau et l’ancien $Bitmap a révélé quelques différences.
Ces différences sont illustrées dans la figure 12.
Lorsque nous avons ajouté de multiples fichiers
non-résidents, les changement se sont avérés contigus dans le fichier $Bitmap
comme le montre la figure 13.
Nous avons exécuté la dernière étape de l’expérience en
ajoutant encore plus de fichier résidents, ce qui a inversé de nombreux bits à
la suite des précédents, puis nous avons supprimé les fichiers les plus
anciens, ce qui a brisé la contiguité de notre fichier $Bitmap comme le montre
la figure 14.
$MFTmirr
Nous avons commencé par localiser $MFTmirr à l’aide de
l’outil gratuit Disk Editor 6.0. d’Active@.
Comme on s’y attendait, on voit
(Annexes X.1, X.2) que $MFTmirr semble contenir une copie des quatre premiers
fichiers de $MFT. Seul le premier fichier a été capturé.
Avant de commencer à modifier
$MFT et $MFTmirr, nous avons testé les outils de récupération pour être sûrs
qu’ils fonctionnent bien lorsque $MFT et $MFTdirr sont intacts (Annexe X.3,
X.4).
Cette vérification s’est avérée
bien fructueuse, car l’outil TestDisk indique que $MFT et $MFTdirr sont
corrompus même si le disque vient tout juste d’être formaté. Après avoir
cherché et tenté de régler le problème, il semble que celui-ci soit assez
récurrent chez les utilisateurs de TestDisk et l’utilisation de cet outil pour
cette partie a été abandonnée.
Ensuite, nous avons modifié à
la main $MFT (Annexe X.5) et tenté de le réparer à l’aide de $MFTdirr et de
l’outil ntfsfix (Annexe X.6). Ce ne fut malheureusement pas concluant. Même si
seulement $MFT a été modifié, ntfsfix n’arrive pas à utiliser $MFTmirr pour le
réparer, ce qui nous mène à penser que nos modification à $MFT étaient trop
importantes pour que soit possible sa reconstruction. Pourtant, en suivant de
nouveau les étapes décrites plus haut et en ne modifiant $MFT que très
légèrement, le même problème survient encore.
Finalement, suivant les mêmes
procédures, nous avons modifié $MFTmirr (Annexe X.7) pour ensuite tenter de le
réparer avec l’outil ntfsfix (Annexe X.8). La réparation de $MFTdirr s’est fait
avec succès (Annexe X.9).
$Volume
Premièrement, nous avons formaté le média avec les
paramètres par défaut: NTFS, unité d’allocation = 4096, aucun nom de volume. De
l’extérieur, ce sont les seuls paramètres sur lesquels nous avons un contrôle.
Nous avons ensuite formaté le média de la même façon, mais en lui donnant cette
fois un nom et les principales différences observées sont dans la figure 15.
Notons que $Volume est un fichier résident.
Nous avons ensuite reformaté le média en prenant la plus
petite unité d’allocation possible, mais sans spécifier de nom de volume pour
ne pas brouiller les pistes. Voir les résultats d’une comparaison avec le
premier fichier dans la figure 16.
Cette fois, les changements sont localisés dans le haut du
document et semblent correspondre à des blocs bien définis.
Nous sommes ensuite allés dans l’autre sens en modifiant le
fichier avec Disk Editor et en observant les résultats. Nous avons ainsi
modifié les champs qui définissent le nom du volume et les informations du
volume, car cet artefact est le seul à les utiliser.
$Boot
Un extrait de l’artéfact $boot,
suite au formatage, est inclus en annexe (figure 1). Selon FTK imager, l’artéfact
pèse 8192 octets, il n’est pas un fichier résident et il est situé au 128e
secteur (au 64k-ieme octet). De plus, il est seulement permit de
lire ce fichier et rien d’autre.
Les deux artéfacts générés (à
l’aide du même disque formaté avec deux tailles de système de fichier
différentes) sont presque identiques sauf à quelques endroits au début. Un diff est montré en annexe (figure 2).
Interprétation
$AttrDef
On peut conclure que cet artéfact
contient des informations necessaires pour identifier les types d’attributs que
peut supporter un système de fichiers. Ils sont identifiés par un identifiant
numérique et un nom qui peuvent être référencés dans d’autres métadonnées. On
aurait aimé apporter des modifications à des entrées de ce fichier tel que les
identificateurs, dans l’hypothèse que des modifications en résultent dans les
autres artefacts.
$Bitmap
Comme souligné
plus haut, $Bitmap est une cartographie du volume. En effet, chaque bit
représente un secteur et indique si celui-ci est occupé ou non. Ainsi,
lorsqu’un bit est à “1”, ceci indique que la grappe qui lui correspond est
occupé par un fichier. Sachant cela, nos résultats sont bien plus aisés à
comprendre.
Les premiers
tests ont montré que NTFS alloue l’espace de façon contigüe, mais jamais dans
les premier secteurs. Nous avons vu en cours que $MFT pouvait occuper un espace
important dans le volume et nous avons supposé que le système réservait peut
être cet espace pour ce fichier crucial. Une revue de la littérature nous a
donné raison, mais nous ne nous sommes pas contenté de ça. Nous avons ajouté de
nombreux fichier très petits (résidents), nous assurant ainsi que seul le
fichier $MFT allait grandir et que tout nouveau secteur occupé lui serait donc
associé. Les faits nous ont donné raison et nous avons vu des bits s’inverser
en début de volume, alors que les nouveaux fichiers étaient ajoutés bien plus
loin (offset 0x17F86 et au-delà).
D’allure simpliste, $Bitmap
permet de refléter les différents schémas d’allocations présentés par NTFS et
est bien plus intéressant que nous ne l’aurions cru.
$MFTmirr
Nous
avons lu qu’il est possible de réparer $MFT à l’aide de $MFTmirr et vice versa,
mais en pratique cela ne s’est montré possible que dans un sens. NTFS étant
propriétaire et son code étant caché, il est très difficile pour des
programmeurs indépendants de fabriquer des outils qui fonctionnent bien.
L’expérience
rappelle la ou les première fois où on tente d’installer Linux à côté de Windows
sur un ordinateur personnel. Il est presque inévitable de massacrer un peu sa
partition Windows dans le processus et les outils de sauvetage sont souvent
très obscurs ou ne fonctionnent tout simplement pas, ce qui résulte en une
expérience très fastidieuse et frustrante car des données importantes peuvent
être en jeu. Nous croyons sans aucun doute que Microsoft devrait ouvrir et
rendre publique son implantation de NTFS (et beaucoup d’autres implémentations
systèmes d’ailleurs) afin que de meilleurs outils de récupération puissent être
développés dont une large communauté bénéficierait grandement.
$Volume
Nous
observons que ce fichier est un simple ramassis de propriétés que le système
d’exploitation va lire pour caractériser le média. En effet, presque toutes les
propriétés du volume que l’on peut modifier à partir de Windows se retrouvent
dans ce fichier. Les plus intéressantes pour nous sont les deux attributs
uniques du fichier, à savoir $VOLUME_NAME et $VOLUME_INFORMATION. Le premier
définit le nom (« label ») du volume tel qu’il est affiché dans
l’explorateur Windows. C’est donc sans surprise que la modification du nom de
volume dans l’explorateur engendre une modification de cet attribut dans
$Volume et que, dans l’autre sens, la modification de ce contenu reflète un
nouveau nom dans Windows.
L’attribut le plus intéressant est le second car il
contient des informations plus techniques qui sont utilisées par Windows pour
reconnaitre les propriétés du volume comme la version du système de fichier par
exemple. On a spéculé que modifier ce champ à l’offset 0x70 nous permettrait
peut être de faire planter le système, mais Windows a simplement refusé de
monter le média lorsque nous entrions des versions erronnées et il s’adaptait
de façon transparente lorsque nous entrions des versions valides mais
différentes. Cette adaptation se manifeste par des comportements adaptés à la
version comme des limitations de fonctionnalités (comme le support des quotas
de disque apparus seulement à la version 3.0).
$Boot
En premier
lieu, nous avons observé ce qui semblait être une signature au début de
l’artéfact (le « NTFS » à partir du 4ième octet). Cette
signature n’est pas situé au début de l’artéfact car celui-ci est destiné à
être chargé en mémoire et être exécuté, c’est pourquoi les 3 premiers octets
sont en fait une instruction JUMP qui fait passer par-dessus l’en-tête et les
donnée constantes (comme les messages, par exemple, encodé en UTF-16).
En second
lieu, selon la table d’instruction x86, les trois premiers octets seraient en
fait deux instructions: “JMP 52h” et “NOP”, nous déduisons donc que le code
destiné à être exécuter est situé au 84ième (82 + 2) octet et que les
données du fichier donc situées entre les 4ième et 83ième
octets inclusivement. Nous croyons que les textes débutant au 396ième
sont des messages d’erreur utilisés par le code débutant au 82ième
octet. Nous déduisons donc que ce bout de code sert simplement à charger le
reste du fichier en mémoire afin de l’exécuter, mais pour en être certain il
faudrait probablement se lancer dans une grosse session de désassemblage. En
observant le diff entre les deux
artéfacts, on voit bien que les seules données qui ont changé sont citées dans cet
en-tête, ce qui correspond bien à nos hypothèses, car il ça ne ferait pas de
sens d’avoir du code différent à chaque fois pour le même système
d’exploitation.
En dernier
lieu, les octets 40 à 44 ont changé puisqu’ils correspondent, selon la NTFS documentation, au nombre de secteurs
sur le volume; ce qui est effectivement ce que nous avons changé entre les deux
artéfacts. Les octets 48 à 52 indiquent à quel endroit est situé le fichier
$MFT et on observe que ce fichier n’est pas du tout au même endroit sur les
deux images. Finalement, à l’octet 72, jusqu’à 80, se situe le volume serial label, il est donc normal
que ces octets aient complètement changé entre les artéfacts.
Conclusion
Bien que l’entièreté du travail
fut très instructif, nous avons tout particulièrement été séduit par la
complexité du fichier $BOOT. Il est vraisemblablement un pilier central dans
l'architecture de NTFS et ceci le met en première position dans la liste des
outils d’un utilisateur malveillant.
Nous aurions aimé explorer les
modifications malicieuses possible du fichier $BOOT, puisque celui-ci contrôle
le processus de démarrage de Windows. Il serait peut-être possible par exemple
de le modifier de telle sorte qu’une partie du disque soit invisible même pour
l’OS (en modifiant les vecteurs d’interruption adéquatement). Par ailleurs, il
existe très probablement certaines protection contre ce type de modification et
il serait intéressant de découvrir lesquelles sont mise en place par quelles
versions de Windows.
Du côté de $MFTmirr, il est
dommage que nous n’ayons pas pu observer la récupération de $MFT alors qu’il
s’agit de son utilité principale. Par contre, nous avons au moins pu confirmer
qu’il contient bien les quatre premiers fichiers de $MFT et qu’il est possible
de reconstruire $MFTmirr à partir de $MFT, réparant ainsi un disque corrompu.
Médiagraphie
« $AttrDef (4) - File - NTFS Documentation ».
Consulté le 7 mars 2016. http://www.inform.pucp.edu.pe/~inf232/Ntfs/ntfs_doc_v0.5/files/attrdef.html
« $Bitmap (6) - File - NTFS Documentation ».
Consulté le 7 mars 2016.
« File - $Boot (7) ». Consulté le 6 mars 2016.
Les deux liens suivant sont aussi des fichiers de
documentations du projet linux-NTFS.
Russon, Richard, et Yuval Fledel. « NTFS
Documentation ». Consulté le 6 mars 2016.
Implémentation Open-Source d’un pilote pour lire et écrire
un système de fichier NTFS.
« Tuxera | Open Source: NTFS-3G - Tuxera ».
Consulté le 7 mars 2016.
Alazab, Mamoun, Sitalakshmi Venkatraman, et Paul Watters. « EFFECTIVE DIGITAL FORENSIC
ANALYSIS OF THE NTFS DISK IMAGE », 2009.
« B-Tree ».
Wikipedia, the Free Encyclopedia, 2 mars 2016.
Hector,
Fuentes II. System and method for removing master file table ($MFT) file record
segments (FRS). US8650229 B2, filed 18 novembre 2010, et issued 11 février
2014.
Huebner,
Ewa, Derek Bem, et Cheong Kai Wee. « Data hiding in the NTFS file
system ». Digital Investigation 3, no 4 (décembre 2006):
211-26. doi:10.1016/j.diin.2006.10.005.
« Master File Table (Windows) ». Consulté le 6
mars 2016.
« NTFS ».
Wikipedia, the Free Encyclopedia, 4 mars 2016.
Medeiros,
Jason. « NTFS Forensics: A Programmers View of Raw Filesystem Data
Extraction », 2008. http://alturl.com/mik68
« NTFS System Files ». Consulté le 7 mars 2016.
Brian
carrier, File System Forensic Analysis
Richard Russon et Yuval Fledel, NTFS documentation
Dave Hull, NTFS: Attributes Part One tiré de:
“Intel x86
Assembler Instruction Set Opcode Table.” Accessed April 4, 2016.
Computer
Forensic de Darren R. Hayes
“Forensic
computing de Anthony Sammes”,Brian Jenkinson
Jeff Hughes, 2010 NTFS File Attributes,
Annexes - Aperçus d’écrans
Annexe A - Captures d’écran pour l’artéfact
$boot
Figure 1: Début du contenu de
l’artéfact $Boot après formatage
Figure 2: Différences entre les
deux artéfacts $Boot généré
Annexe B - Captures d’écrans $MFTmirr
Figure 3: $MFTDirr
Figure 4: $MFT (Identique)
Figure 5: ntfsfix
Figure 6: TestDisk
Figure 7: Corruption de $MFT
Aucun commentaire:
Publier un commentaire