NTFS
Depuis que j’ai RE le totokit AK922, j’ai eu envie de m’intéresser au format de fichier NTFS. Je n’aurais pas du, c’est vraiment un sacré bordel la dessous. Anyway, j’ai commencé a coder un petit tool me permettant de dump les fichiers directe depuis le disque. En fait j’ai 3 idées en tête :
1) Me faire un anti-rootkit, « solide » qui ne dépend pas du driver ntfs.sys. Avec j’ai un bon moyen de lutte contre toutes les rk utilisant des techniques de stealth NTFS.
2) Me servir de ces connaissances pour faire des totokits + puissants 
On verra ca plus tard …
3) Mais surtoutj’aimerais mettre en place une « pagefile attack ». Cette technique consiste à écrire en raw sur le disque au niveau de fichier du pagination (pagefile.sys), il est possible ainsi, en choisissant bien oû l’on écrit de faire éxécuter du code par le kernel. Joanna dans sa conf « Subverting Vista Kernel For Fun And Profit » a utilisé ce trick, pour loader des driver non-signés sur Vista … Evidemment comme tout le monde s’en fou de Vista je ne cherche pas à faire la même chose sur mon XP :] Je voudrais juste exécuter un petit code de la manière la plus fiable possible juste pour tripper :} Joanna, pour réussir son attaque, a modifié la DispatchRoutine (qui est dans une section possédant l’attribut PAGED_CODE) du driver null.sys (le truc qui est jamais appelé …) dans le fichier de pagination après avoir demandé à un process de bourré la ram à coups de VirtualAlloc. Evidemment avant d’écrire en raw sur le disque il faut pouvoir trouver où est le pagefile.sys et là, c’est une autre histoire
Au départ j’étais partis sur une autre manière pour écrire dans le pagefile.sys. Sachant qu’il est impossible d’ouvrir le fichier avec un NtCreateFile car il à été crée avec aucun FILE_SHARE_* il n’existe qu’il moyen pour avoir un handle sur pagefile.sys. On sait que comme pagefile.sys est manipulé par le kernel, il existe dans le process « system » un handle référencant le FILE_OBJECT associé. Je me suis dit « hop straff bunny ezlolffs, t’a plus qu’a dupliquer le handle depuis le proces system et puis tu pourra faire ce que tu veux après avec » .. mwais .. Après avoir réussit sans trop soucis à dupliquer le handle, j’ai tenté un ReadFile dessus, et ce fut le drame, BSOD in my face ! J’avoue que je n’ai toujours pas comprit pourquoi, mais bon si le fichier a été crée sans FILE_SHARE_* c’est peut-être normal 
La seule solution donc, est d’écrire directement sur le disque en retrouvant le pagefile à travers le format NTFS. Voilà ou j’en suis après avoir regardé quelques docs sur le format du système de fichiers. Première étape, comme nous voulons lire en raw sur le disque on a besoin d’envoyer des IRP sur un des devices du driver de disque. Il nous faut donc un handle dessus, hop on réalise cela avec ce petit bout de code :
hDevice=CreateFile("\\\\\\.\\\\C:",
GENERIC_READ,
FILE_SHARE_READ|FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
if(hDevice==INVALID_HANDLE_VALUE)
{
printf("Error with CreateFile : %dn", GetLastError());
goto end;
}
Après on peut enfin faire du ReadFile et ReadFileEx sur le disque. Tout d’abord quelques notions :
Un disque dur est découpe en sectors, la taille de chaque sectors est dépendante du constructeur mais en général ils font 512 octets (0×200). Windows, pour s’affranchir de la spécification constructeur manipule le disque qu’a travers des clusters, un cluster fait n sectors, chez moi j’ai 8 sectors par cluster, ce qui me donc 4096 bytes par clusters (0×1000).
Premier essai, je tenter de dumper les 400 premiers bytes du disque, bim dans mon cul ! On je peut que lire par multiple de taille de sector, soit pour moi 512. Ce n’est pas grave on recommence. La première structure qu’on découvre sur le disque est de type NTFS5_BOOT_RECORD :
#pragma pack(push,1)
typedef struct _NTFS5_BOOT_RECORD {
BYTE _jmpcode[3];
CHAR cOEMID[8];
WORD wBytesPerSector;
BYTE bSectorsPerCluster;
WORD wSectorsReservedAtBegin;
BYTE Mbz1;
WORD Mbz2;
WORD Reserved1;
BYTE bMediaDescriptor;
WORD Mbz3;
WORD wSectorsPerTrack;
WORD wSides;
DWORD dwSpecialHiddenSectors;
DWORD Reserved2;
DWORD Reserved3;
UINT64 TotalSectors;
LARGE_INTEGER MftStartLcn;
UINT64 Mft2StartLcn;
DWORD ClustersPerFileRecord;
DWORD ClustersPerIndexBlock;
UINT64 VolumeSerialNumber;
BYTE _loadercode[430];
WORD wSignature;
} NTFS5_BOOT_RECORD, *PNTFS5_BOOT_RECORD;
#pragma pack(pop)
Ce qui donne en version humainement lisible, cela :
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 000000000 EB 52 90 4E 54 46 53 20 20 20 20 00 02 08 00 00 ëRNTFS ..... 000000010 00 00 00 00 00 F8 00 00 3F 00 FF 00 3F 00 00 00 .....ø..?.ÿ.?... 000000020 00 00 00 00 80 00 80 00 21 97 FF 07 00 00 00 00 ....€.€.!—ÿ..... 000000030 00 00 0C 00 00 00 00 00 72 F9 7F 00 00 00 00 00 ........rù..... 000000040 F6 00 00 00 01 00 00 00 99 07 33 F8 3E 33 F8 2A ö.......™.3ø>3ø* 000000050 00 00 00 00 FA 33 C0 8E D0 BC 00 7C FB B8 C0 07 ....ú3ÀŽÐ¼.|û¸À. 000000060 8E D8 E8 16 00 B8 00 0D 8E C0 33 DB C6 06 0E 00 ŽØè..¸..ŽÀ3ÛÆ... 000000070 10 E8 53 00 68 00 0D 68 6A 02 CB 8A 16 24 00 B4 .èS.h..hj.ËŠ.$.´ 000000080 08 CD 13 73 05 B9 FF FF 8A F1 66 0F B6 C6 40 66 .Í.s.¹ÿÿŠñf.¶Æ@f 000000090 0F B6 D1 80 E2 3F F7 E2 86 CD C0 ED 06 41 66 0F .¶Ñ€â?÷â†ÍÀí.Af. 0000000A0 B7 C9 66 F7 E1 66 A3 20 00 C3 B4 41 BB AA 55 8A •Éf÷áf£ .ôA»ªUŠ 0000000B0 16 24 00 CD 13 72 0F 81 FB 55 AA 75 09 F6 C1 01 .$.Í.r.ûUªu.öÁ. 0000000C0 74 04 FE 06 14 00 C3 66 60 1E 06 66 A1 10 00 66 t.þ...Ãf`..f¡..f 0000000D0 03 06 1C 00 66 3B 06 20 00 0F 82 3A 00 1E 66 6A ....f;. ..‚:..fj 0000000E0 00 66 50 06 53 66 68 10 00 01 00 80 3E 14 00 00 .fP.Sfh....€>... 0000000F0 0F 85 0C 00 E8 B3 FF 80 3E 14 00 00 0F 84 61 00 .…..è³ÿ€>....„a. 000000100 B4 42 8A 16 24 00 16 1F 8B F4 CD 13 66 58 5B 07 ´BŠ.$...‹ôÍ.fX[. 000000110 66 58 66 58 1F EB 2D 66 33 D2 66 0F B7 0E 18 00 fXfX.ë-f3Òf.•... 000000120 66 F7 F1 FE C2 8A CA 66 8B D0 66 C1 EA 10 F7 36 f÷ñþŠÊf‹ÐfÁê.÷6 000000130 1A 00 86 D6 8A 16 24 00 8A E8 C0 E4 06 0A CC B8 ..†ÖŠ.$.ŠèÀä..̸ 000000140 01 02 CD 13 0F 82 19 00 8C C0 05 20 00 8E C0 66 ..Í..‚..ŒÀ. .ŽÀf 000000150 FF 06 10 00 FF 0E 0E 00 0F 85 6F FF 07 1F 66 61 ÿ...ÿ....…oÿ..fa 000000160 C3 A0 F8 01 E8 09 00 A0 FB 01 E8 03 00 FB EB FE à ø.è.. û.è..ûëþ 000000170 B4 01 8B F0 AC 3C 00 74 09 B4 0E BB 07 00 CD 10 ´.‹ð¬<.t.´.»..Í. 000000180 EB F2 C3 0D 0A 45 72 72 2E 20 6C 65 63 74 75 72 ëòÃ..Err. lectur 000000190 65 20 64 69 73 71 75 65 00 0D 0A 4E 54 4C 44 52 e disque...NTLDR 0000001A0 20 6D 61 6E 71 75 65 00 0D 0A 4E 54 4C 44 52 20 manque...NTLDR 0000001B0 65 73 74 20 63 6F 6D 70 72 65 73 73 82 00 0D 0A est compress‚... 0000001C0 45 6E 74 72 65 7A 20 43 74 72 6C 2B 41 6C 74 2B Entrez Ctrl+Alt+ 0000001D0 53 75 70 70 72 20 70 6F 75 72 20 72 65 64 82 6D Suppr pour red‚m 0000001E0 61 72 72 65 72 0D 0A 00 0D 0A 00 00 00 00 00 00 arrer........... 0000001F0 00 00 00 00 00 00 00 00 83 99 A8 BE 00 00 55 AA ........ƒ™¨¾..Uª
On retrouve dans cette structure le nombre de bytes par sector (wBytesPerSector), le nombre de sectors par cluster (bSectorsPerCluster) mais surtout le champ MftStartLcn qui nous indique l’adresse de la MFT (Master File Table) avec un LCN. Un LCN (Logical Cluster Number) est le nombre de clusters qui se trouvent entre le début du disque et la localisation du fichier, ainsi, si l’on veut retrouver ce fichier sur le disque il faut multiplier le LCN par le nombre de bytes par cluster. Dans l’exemple au dessus le champ MftStartLcn vaut 0xC0000 (offset 0×30, taille 64 bits), la MFT se trouve donc sur le disque à l’adresse physique 0xC0000000.
La MFT est une table contenant une série de fichiers dont les 16 premiers sont réservés par le système de fichiers. Ces fichiers sont des metadata dont le nom commence par ‘$’. Voici les 12 primiers (les autres sont réservés pour un usage futur) :
$MFT : Itself MFT
$MFTmirr : copy of the first 16 MFT records placed in the middle of the disk
$LogFile : journaling support file (see below)
$Volume : housekeeping information – volume label, file system version, etc.
$AttrDef : list of standard files attributes on the volume
$. :root directory
$Bitmap : volume free space bitmap
$Boot : boot sector (bootable partition)
$BadClus : records any bad spots on the disk volume
$Secure : contains unique security descriptors for all files within a volume
$Quota : file where the users rights on disk space usage are recorded (began to work only in NT5)
$Upcase : File – the table of accordance between capital and small letters in files names on current volume. It is necessary because in NTFS file names are stored in Unicode that makes 65 thousand various characters and it is not easy to search for their large and small equivalents.
$Extend : used for various optional extensions such as quotas, reparse point data, and object identifiers.
Chaque fichier est décrit sous la forme d’une série d’attributs, qui sont en général :
Standard Information
Information such as access mode (read-only, read/write, and so forth) timestamp, and link count.
Attribute List
Locations of all attribute records that do not fit in the MFT record.
File Name
A repeatable attribute for both long and short file names. The long name of the file can be up to 255 Unicode characters. The short name is the 8.3, case-insensitive name for the file. Additional names, or hard links, required by POSIX can be included as additional file name attributes.
Data
File data. NTFS supports multiple data attributes per file. Each file typically has one unnamed data attribute. A file can also have one or more named data attributes.
Object ID
A volume-unique file identifier. Used by the distributed link tracking service. Not all files have object identifiers.
Logged Tool Stream
Similar to a data stream, but operations are logged to the NTFS log file just like NTFS metadata changes. This attribute is used by EFS.
Reparse Point
Used for mounted drives. This is also used by Installable File System (IFS) filter drivers to mark certain files as special to that driver.
Index Root
Used to implement folders and other indexes.
Index Allocation
Used to implement the B-tree structure for large folders and other large indexes.
Bitmap
Used to implement the B-tree structure for large folders and other large indexes.
Volume Information
Used only in the $Volume system file. Co
Tout ces attributs ne sont par forcément présent, cela dépend du type de fichier, de sa taille et de plein d’autres params.
Sur le disque chaque fichier commence par un header de type FILE_RECORD_HEADER :
typedef struct _FILE_RECORD_HEADER {
NTFS_RECORD_HEADER Ntfs;
USHORT SequenceNumber;
USHORT LinkCount;
USHORT AttributesOffset;
USHORT Flags; // 0x0001 = InUse, 0x0002 = Directory
ULONG BytesInUse;
ULONG BytesAllocated;
ULONGLONG BaseFileRecord;
USHORT NextAttributeNumber;
USHORT Pading; /* Align to 4 UCHAR boundary (XP) */
ULONG MFTRecordNumber; /* Number of this MFT Record (XP) */
} FILE_RECORD_HEADER, *PFILE_RECORD_HEADER;
Le FILE_RECORD_HEADER nous indique l’offet de la première structure décrivant un attribut (AttributesOffset). C’est en fait une sorte de header qui décrit le type d’attribut qui suit (comme par exemple : Standard Information, FileName, Data etc …) Ce header est une structure de type ATTRIBUTE :
typedef struct _ATTRIBUTE {
ATTRIBUTE_TYPE AttributeType;
ULONG Length;
BOOLEAN Nonresident;
UCHAR NameLength;
USHORT NameOffset;
USHORT Flags; // 0x0001 = Compressed
USHORT AttributeNumber;
} ATTRIBUTE, *PATTRIBUTE;
A partir du AttributeType on retrouve un numéro définissant de quel attribut il s’agit :
typedef enum _ATTRIBUTE_TYPE {
AttributeStandardInformation = 0x10,
AttributeAttributeList = 0x20,
AttributeFileName = 0x30,
AttributeObjectId = 0x40,
AttributeSecurityDescriptor = 0x50,
AttributeVolumeName = 0x60,
AttributeVolumeInformation = 0x70,
AttributeData = 0x80,
AttributeIndexRoot = 0x90,
AttributeIndexAllocation = 0xA0,
AttributeBitmap = 0xB0,
AttributeReparsePoint = 0xC0,
AttributeEAInformation = 0xD0,
AttributeEA = 0xE0,
AttributePropertySet = 0xF0,
AttributeLoggedUtilityStream = 0x100
} ATTRIBUTE_TYPE, *PATTRIBUTE_TYPE; //sizeof(ATTRIBUTE_TYPE)=4
Le champ Nonresident nous indique si l’attribut est résident ou non, ce qui signifie si oui on les données indiqué dans le type de l’attribut soit à suivre de l’attribut ou bien se trouvent plus loin sur le disque. Par exemple si un fichier fait plus de 4ko ses données ne suivent pas l’attribut ‘Data’. Dans le cas ou l’attribut est résident on retrouve une structure RESIDENT_ATTRIBUTE :
typedef struct _RESIDENT_ATTRIBUTE {
ATTRIBUTE Attribute;
ULONG ValueLength;
USHORT ValueOffset;
USHORT Flags; // 0x0001 = Indexed
} RESIDENT_ATTRIBUTE, *PRESIDENT_ATTRIBUTE;
Comme vous le voyez la structure RESIDENT_ATTRIBUTE se compose de la structure ATTRIBUTE, en fait c’est juste une extension, la structure NONRESIDENT_ATTRIBUTE commence aussi avec la structure ATTRIBUTE mais la suite change.
Voici une descriptions des champs de la structure RESIDENT_ATTRIBUTE sortie des header de ntfs-3G :
typedef struct {
/*Ofs*/
/* 0*/ ATTR_TYPES type; /* The (32-bit) type of the attribute. */
/* 4*/ u32 length; /* Byte size of the resident part of the
attribute (aligned to 8-byte boundary).
Used to get to the next attribute. *//* 8*/ u8 non_resident; /* If 0, attribute is resident.
If 1, attribute is non-resident. */
/* 9*/ u8 name_length; /* Unicode character size of name of attribute.
0 if unnamed. */
/* 10*/ u16 name_offset; /* If name_length != 0, the byte offset to the
beginning of the name from the attribute
record. Note that the name is stored as a
Unicode string. When creating, place offset
just at the end of the record header. Then,
follow with attribute value or mapping pairs
array, resident and non-resident attributes
respectively, aligning to an 8-byte
boundary. */
/* 12*/ ATTR_FLAGS flags; /* Flags describing the attribute. */
/* 14*/ u16 instance; /* The instance of this attribute record. This
number is unique within this mft record (see
MFT_RECORD/next_attribute_instance notes
above for more details). */
/* 16*/ union {
/* Resident attributes. */
struct {
/* 16 */ u32 value_length; /* Byte size of attribute value. */
/* 20 */ u16 value_offset; /* Byte offset of the attribute
value from the start of the
attribute record. When creating,
align to 8-byte boundary if we
have a name present as this might
not have a length of a multiple
of 8-bytes. */
/* 22 */ RESIDENT_ATTR_FLAGS resident_flags; /* See above. */
/* 23 */ s8 reservedR; /* Reserved/alignment to 8-byte
boundary. */
/* 24 */ void *resident_end[0]; /* Use offsetof(ATTR_RECORD,
resident_end) to get size of
a resident attribute. */
} __attribute__((__packed__));
/* Non-resident attributes. */
[...]
Je crois qu’un exemple serait le bienvenu. J’ai prit comme démonstration un fichier de petite taille, le boot.ini :
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E FFILE_RECORD_HEADER
0C0352000 46 49 4C 45 30 00 03 00 C2 0C 77 1B 00 00 00 00 FILE0...Â.w.....
0C0352010 01 00 01 00 38 00 01 00 40 02 00 00 00 04 00 00 ....8...@.......
0C0352020 00 00 00 00 00 00 00 00 05 00 00 00 48 0D 00 00 ............H...
FILE_RECORD_HEADER.AttributesOffset=0x38;
0C0352030 CA 0A 20 2F 00 00 00 00 Ê. /....
RESIDENT_ATTRIBUTE.AttributeType=0x10
->AttributeStandardInformation
10 00 00 00 60 00 00 00 ....`...
0C0352040 00 00 00 00 00 00 00 00 48 00 00 00 18 00 00 00 ........H.......
STANDARD_INFORMATION
0C0352050 00 8D 3A 56 4E 67 C7 01 40 36 74 D4 68 FC C7 01 .:VNgÇ.@6tÔhüÇ.
0C0352060 40 36 74 D4 68 FC C7 01 40 1F 27 89 C0 FD C7 01 @6tÔhüÇ.@.'‰ÀýÇ.
0C0352070 26 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 &...............
0C0352080 00 00 00 00 15 01 00 00 00 00 00 00 00 00 00 00 ................
0C0352090 00 00 00 00 00 00 00 00 ........
RESIDENT_ATTRIBUTE.AttributeType=0x30
->AttributeFileName
30 00 00 00 70 00 00 00 0...p...
0C03520A0 00 00 00 00 00 00 02 00 52 00 00 00 18 00 01 00 ........R.......
FILENAME_ATTRIBUTE
0C03520B0 05 00 00 00 00 00 05 00 00 8D 3A 56 4E 67 C7 01 .........:VNgÇ.
0C03520C0 00 8D 3A 56 4E 67 C7 01 00 8D 3A 56 4E 67 C7 01 .:VNgÇ..:VNgÇ.
0C03520D0 00 8D 3A 56 4E 67 C7 01 00 00 00 00 00 00 00 00 .:VNgÇ.........
0C03520E0 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ .......
0C03520F0 08 03 62 00 6F 00 6F 00 74 00 2E 00 69 00 6E 00 ..b.o.o.t...i.n.
0C0352100 69 00 00 00 00 00 00 00 i.......
RESIDENT_ATTRIBUTE.AttributeType=0x40
->AttributeFileName=AttributeObjectId
40 00 00 00 28 00 00 00 @...(...
0C0352110 00 00 00 00 00 00 04 00 10 00 00 00 18 00 00 00 ................
OBJECTID_ATTRIBUTE
0C0352120 44 4E EB C3 7D 67 DC 11 83 8D 00 03 FF 02 63 0E DNëÃ}gÜ.ƒ..ÿ.c.
RESIDENT_ATTRIBUTE.AttributeType=0x80
->AttributeFileName=AttributeData
0C0352130 80 00 00 00 08 01 00 00 00 00 18 00 00 00 03 00 €...............
0C0352140 ED 00 00 00 18 00 00 00 í.......
5B 62 6F 6F 74 20 6C 6F [boot lo
0C0352150 61 64 65 72 5D 0D 0A 74 69 6D 65 6F 75 74 3D 33 ader]..timeout=3
0C0352160 30 0D 0A 64 65 66 61 75 6C 74 3D 6D 75 6C 74 69 0..default=multi
0C0352170 28 30 29 64 69 73 6B 28 30 29 72 64 69 73 6B 28 (0)disk(0)rdisk(
0C0352180 30 29 70 61 72 74 69 74 69 6F 6E 28 31 29 5C 57 0)partition(1)W
0C0352190 49 4E 44 4F 57 53 0D 0A 5B 6F 70 65 72 61 74 69 INDOWS..[operati
0C03521A0 6E 67 20 73 79 73 74 65 6D 73 5D 0D 0A 6D 75 6C ng systems]..mul
0C03521B0 74 69 28 30 29 64 69 73 6B 28 30 29 72 64 69 73 ti(0)disk(0)rdis
0C03521C0 6B 28 30 29 70 61 72 74 69 74 69 6F 6E 28 31 29 k(0)partition(1)
0C03521D0 5C 57 49 4E 44 4F 57 53 3D 22 4D 69 63 72 6F 73 WINDOWS="Micros
0C03521E0 6F 66 74 20 57 69 6E 64 6F 77 73 20 58 50 20 50 oft Windows XP P
0C03521F0 72 6F 66 65 73 73 69 6F 6E 6E 65 6C 22 20 CA 0A rofessionnel" Ê.
0C0352200 6E 6F 65 78 65 63 75 74 65 3D 6F 70 74 69 6E 20 noexecute=optin
0C0352210 2F 66 61 73 74 64 65 74 65 63 74 20 2F 64 65 62 /fastdetect /deb
0C0352220 75 67 20 2F 64 65 62 75 67 70 6F 72 74 3D 43 4F ug /debugport=CO
0C0352230 4D 31 3A 0D 0A 00 00 00 FF FF FF FF 82 79 47 11 M1:.....ÿÿÿÿ‚yG.
0C0352240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[...]
0C03523F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CA 0A ..............Ê.
Bon c’est toujours la même chose, on regarde si l’attribut qu’on a est resident ou non, on détermine ensuite quel type de données suivent puis on les lit. On trouve l’attribut suivant à partir de l’actuel en faisant :
NextAttri = CurrentAttri + CurrentAttri->ValueLength;
Concernant les NonResidentAttribut, on verra ca plus tard :p
Bon j’avoue, c’est vraiment un peu chaud à comprendre au début, je suis loin d’avoir tout capté, faut que je lise encore pas mal et que j’améliore mon code. J’essayerai de vous le sortir un jour …
En attendant, on imagine comment fonctionnent les tools de récupération de fichier, pour parser le format NTFS. Pareil, si on regarde le post de Azy sur rootkit.com, on peut voir qu’il utilise une structure de type INDEX_ENTRY qui sont celle qui servent à décrire le contenu d’un dossier. Je n’ai pas encore étudier cela mais je le ferais prochainement.
En fait il faudrait que j’arrive à retrouver le FILE_RECORD du fichier pagefile.sys en parcourant la liste des fichiers du C:, pour l’instant je ne sais pas encore le faire.
Bref, la suite au prochain épisode.
ref :
http://www.ntfs.com/
http://technet2.microsoft.com/windowsserver/en/library/8cc5891d-bf8e-4164-862d-dac5418c59481033.mspx?mfr=true
http://www.digit-life.com/articles/ntfs/
http://www.pcguide.com/ref/hdd/file/ntfs/archFiles-c.html
http://www.alex-ionescu.com/NTFS.pdf
http://dbserver.kaist.ac.kr/~yjlee/Courses/CS230/ntfs/NTFS-3.html
http://www.geocities.com/beiyu2005/beiyu_NTFSResearch.htm
2 comments septembre 26th, 2007