NTFS is a new file system introduced by Windows NT, which has many new features. This article is intended to explore the underlying structure of NTFS, which is only the distribution of files on the NTFS volume. In NTFS, all stored data in the volume is in a file called $ MFT, called the master file table. And $ MFT is composed of file record arrays. The size of File Record is generally fixed, usually 1KB, which is equivalent to inode in Linux. File Record is physically continuous in the $ MFT file and numbered from 0. $ MFT is for File System itself, the architecture file system is used, which is called metadata in NTFS. The metadata file of the NTFS out of Windows 2000 Release is listed below (partial output of the partial output of the sample code to give). File Record (Inode) FileName ------------------ -------- 0 $ MFT 1 $ MFTMIR 2 $ logfile 3 $ VOLUME 4 $ Attrdef 5. 6 $ BITMAP 7 $ BOOT 8 $ BADCLUS 9 $ Secure 10 $ UPCASE 11 $ Extend WINDOWS 2000 cannot be used to list these metadata files like a normal file. In fact, File System Driver (NTFS.SYS) maintains a system variable NTFSProtectSystemFiles to hide these metadata. By default, this variable is set to True, so use DIR / AH will not get any files.
Use i386kd modify the behavior after NtfsProtectSystemFiles know the metadata file can be listed:!!!! Kd> x ntfs NtfsProtect * fe213498 Ntfs NtfsProtectSystemFiles fe21349c Ntfs NtfsProtectSystemAttributes kd> dd ntfs NtfsProtectSystemFiles l 2 fe213498 00000001 00000001 kd> ed ntfs NtfsProtectSystemFiles 0! KD> DD NTFS! NTFSPROTECTSYSTEMFILES L 2 Fe213498 00000000 00000001 Kd> D: /> Ver Microsoft Windows 2000 [Version 5.00.2195] D: /> DIR / AH $ * Drive D is the serial number of the W2kNTFS volume is E831- 9D04 D: / Of catalog 2000-04-27 19:31 36,000 $ attrdef 2000-04-27 19:31 0 $ Badclus 2000-04-27 19:31 67,336 $ Bitmap 2000-04-27 19:31 8,192 $ boot 2000-04-27 19:31
In order to better continue the discussion below, I have listed here the structure File Record Header: typedef struct {ULONG Type; USHORT UsaOffset; USHORT UsaCount; USN Usn;} NTFS_RECORD_HEADER, * PNTFS_RECORD_HEADER; typedef struct {NTFS_RECORD_HEADER Ntfs; USHORT SequenceNumber; USHORT LinkCount; USHORT AttributesOffset; USHORT Flags; // 0x0001 = InUse, 0x0002 = Directory ULONG BytesInUse; ULONG BytesAllocated; ULONGLONG BaseFileRecord; USHORT NextAttributeNumber;} FILE_RECORD_HEADER, * PFILE_RECORD_HEADER; I'll discuss how to position the $ MFT. People who are slightly operated in system knowledge will know the boot sector, which is the first sector in the volume. The first sector analyzed by DSKProbe.exe (a gadget in Windows 2000 Resource Kit): File: D: /sector00.bin size: 0x00000200 (512) Address | 00 01 02 03-04 05 06 07: 08 09 0A 0B-0C 0D 0E 0F | 0123456789ABCDEF -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- - 00000000 | EB 52 90 4E-54 46 53 20: 20 20 20 00-02 08 00 00 | • R? NTFS .... 00000010 | 00 00 00 00 F8 00 00 00 00: 3F 00 f0 00-3f 00 00 00 | ..... .. e ... 00000020 | 00 00 00 00-80 00 80 00:??..?. 90 C0 41 00-00 00 00 00 | .... € €. angry A ..... 00000030 | 04 00 00 00-00 00 00 00: 09 1C 04 00-00 00 00 00 | ................ 00000040 | F6 00 00 00-01 00 00: 04 9d 31 E8-BB 31 E8 94 |? .......? 杌 1 钄....... C9-00 00 55 aa | ........ 儬成 ..u? This 512 byte is the following format: (Excerpted from the Gary Nebbett book, many of this article come from or refer to this book.
) #Pragma pack (push, 1) typedef struct {UCHAR Jump [3]; UCHAR Format [8]; USHORT BytesPerSector; UCHAR SectorsPerCluster; USHORT BootSectors; UCHAR Mbz1; USHORT Mbz2; USHORT Reserved1; UCHAR MediaType; USHORT Mbz3; USHORT SectorsPerTrack ; USHORT NumberOfHeads; ULONG PartitionOffset; ULONG Reserved2 [2]; ULONGLONG TotalSectors; ULONGLONG MftStartLcn; ULONGLONG Mft2StartLcn; ULONG ClustersPerFileRecord; ULONG ClustersPerIndexBlock; ULONGLONG VolumeSerialNumber; UCHAR Code [0x1AE]; USHORT BootSignature;} BOOT_BLOCK, * PBOOT_BLOCK; #pragma pack ( POP) Detailed meaning of each field is generally clear from the field name. There is also a detailed document in Linux-NTFS GNU project (http://sf.net/projects/linux-ntfs), which is limited to the space I don't list it. You can use the following code to read the first sector in the volume: hvolume = createfile (drive, generic_read, file_share_read | file_share_write, 0, open_existing, 0, 0); ReadFile (Hvolume, & Bootb, Sizeof (bootb), & n, 0 ); BOOT_BLOCK BootB is a structure I in the following format in volume (see the corresponding Sector00.bin analysis): Dump BootBlock at below: BytesPerSector: 200 SectorsPerCluster: 8 BootSectors: 0 SectorsPerTrack: 3F NumberOfHeads: F0 PartitionOffset: 3F TotalSectors: 41C090 MFTSTARTLCN: 41C09 ClustersperFileRecord: F6 ClustersperIndexBlock: 1 VoluMserialNumber: E8319D04 BootSignature: AA55 The above MFTStartLCN is actually a cluster (Cluster) in the volume. Clusters are the basic units of NTFs, minimum units. A file with only 1byte should also take up a cluster of space. NTFS uses the LCN (Logical Cluster Number) to represent the physical location in the NTFS volume, which is simple to numbered from the total cluster number in the 0 to the volume. For a specific file NTFS, use the VCN (Virtual Cluster Number) to map the organization of the LCN implementation file.
From the value of MFTSTARTLCN, you can know that the LCN of $ MFT is 4 and the SectorsPerCluster, the size of the Bytespector can locate the location of the $ MFT. After getting the location of the $ MFT, if all File Record in the $ MFT can get all the files in the volume (previously mentioned that File Record is just simple from 0). That is to say, so far can you have the easiest understanding of the document organization, but how to get the file information, such as file name, etc. All documents in NTFS include normal user files, metadata files, data, attributes, etc. in the same way. I am listed in the output of NFI.exe (from Windows NT / 2000 OEM Support Tools) as the beginning of my narrative: D: /> Copy Con File Testforntfs ^ z has been copied 1 file. D: /> nfi d:.. / File NTFS File Sector Information Utility Copyright (C) Microsoft Corporation 1999. All rights reserved / file $ STANDARD_INFORMATION (resident) $ FILE_NAME (resident) $ DATA (resident) D: /> echo testforattr > file: ATTR d: /> nfi d:.. / file NTFS File Sector Information Utility Copyright (C) Microsoft Corporation 1999. All rights reserved / file $ STANDARD_INFORMATION (resident) $ FILE_NAME (resident) $ DATA (resident) $ DATA Attr (Resident) NFI output result $ standard_information, $ file_name, $ data, etc., in NTFS, "Attribute). The property is divided into resident attribute and a very stationery (NonResIdent Attribute). The data of the file is also included in the properties, which seems to be a bit mixed with the name of the property. However, this has made NTFS have the form of more unified organizational documents. This also allows NTFS with Multistreams (this feature).
The implementation code of the given Attribute is as follows: Template
: Bpx FindAttribute Break due to BPX FindAttribute (ET = 6.89 seconds): locals [EBP-4] struct ATTRIBUTE * attr = 0x00344D68 <{...}> [EBP 8] struct FILE_RECORD_HEADER * file = 0x00344D38 <{. ..}> [EBP C] enum ATTRIBUTE_TYPE type = AttributeFileName (30) [EBP 10] unsigned short * name = 0x004041BC < "$ MFT">:? file struct FILE_RECORD_HEADER * = 0x00344D38 <{...}> struct NTFS_RECORD_HEADER Ntfs = {...} unsigned short SequenceNumber = 0x1, "/ 0 / x01" unsigned short LinkCount = 0x1, "/ 0 / x01" unsigned short AttributesOffset = 0x30, "/ 00" unsigned short Flags = 0x1, " / 0 / x01 "Unsigned long bytesinuse = 0x2d8," / 0 / x02 / xd8 "unsigned long bytesallocated = 0x400," / 0 / x04 / 0 "unsigned quad BaseFileRecord = 0x0," / 0/0/0 / 0/0/0/0/0 "Unsigned short nextattributenumber = 0x6," / 0 / x06 "File parameter I am incoming $ MFT, from the LCN = 4 of $ MFT, you can get the physical address in the volume, This has been described above. You can also use DSKProbe (IPAP * SectorsPerCluster = 4 * 8 sector) to get the output of SOFTICE:: DD @File // The following comments can be used in the file_record_header definitions listed in the name. 0023: 00344D38 454C4946 0003002A 6D4AC04D 00000000 file * ... m.jm .... 0023: 00344d48 00010001 00010030 000002D8 00000400 .... 0 ......... ---- | __ATtributeoffset 0023: 00344d58 00000000 00000000 04340006 0000FA0D .......... 4 ..... 0000000010 0000000060 00180000 00000000 .... ......... -------- - -------- | | _T pointed out the length of this Attribute. Defined as follows.
| _Tribute header, based on AttributeOffset, is defined as follows. 00000010 indicates that this Attribute to StandardInformation 0023: 00344D78 00000048 00000018 2C1761D0 01BFB03C H ........ a, <... Attribute head is defined as follows:. Typedef struct {ATTRIBUTE_TYPE AttributeType; ULONG Length; BOOLEAN Nonresident; UCHAR NameLength; USHORT NameOffset; USHORT Flags; // 0x0001 = Compressed USHORT AttributeNumber;} ATTRIBUTE, * PATTRIBUTE; typedef struct {ATTRIBUTE Attribute; ULONG ValueLength; USHORT ValueOffset; USHORT Flags; // 0x0001 = Indexed} RESIDENT_ATTRIBUTE, * PRESIDENT_ATTRIBUTE; typedef struct {ULONGLONG DirectoryFileReferenceNumber ; ULONGLONG CreationTime; // Saved when filename last changed ULONGLONG ChangeTime; // ditto ULONGLONG LastWriteTime; // ditto ULONGLONG LastAccessTime; // ditto ULONGLONG AllocatedSize; // ditto ULONGLONG DataSize; // ditto ULONG FileAttributes; // d ITTO ULONG Alignorreserved; Uchar Namelength; Uchar NameType; // 0x01 = long, 0x02 = short wchar name [1];} filename_attribute, * pfilename_attribute; attribute_type is an ENUM type definition. The 00000010 is StandardInformation. 30 is FileName. Because FileNameAttribute is always a standing Attribute, I will also define the resident_attribute definition.
OK, now you can continue DUMP Next Attribute: // DD @ file file-> attributeoffset length (StandardInformationAttribute): DD @ file 30 60 0023: 00344DC8 000030 00000068 00180000 00030000 0 ... h ..... ... -------- ------ | | ___ Here Namelength and NameOffset refers to the FileNameAttribute name. Don't mix with $ MFT FileName. | _ Pointed out this is a FileNameAttribute. 0023: 00344DD8 0000004a 00010018 00000005 00050000 j ............. -------- ---- -------- | | _ based on valueoffset Value, get the specific location of FileName_Attribute. | | _Valueoffset value | _valuelength 0023: 00344DE8 2C1761D0 01BFB03C 2C1761D0 01BFB03C .a., <.... a., <... 0023: 00344df8 2c1761d0 01 bfb03c 2c1761d0 01 bfb03c .a., <.... a., < ... 00004000 000000000000004000 00000000. @ ....... @ ... 00000006 00000000 00240304 0046004D ........ $. Mf - ------ | | ___ find the filename of $ MFT. | _NameLength 0023: 00344E28 00000054 00000000 00000080 00000190 T ............... 0023: 00344E38 00400001 00010000 00000000 00000000 .. @ ............. here to A concrete approach to Dump Attribute. Finally, I will give the code that traversed the File Record, which should explain the $ BITMAP attributes in the $ MFT before giveing the code. NTFS's Attribute is equivalent to the S_Inode_bitmap array of Linux Ext2 (Linux 2.0). Therefore, it is easy to understand the role of $ bitmap, that is, each bit is pointed out in the case of the corresponding File Record.
The following is the code of DumpAllFileRecord: Bool Bitmap, Ulong i) {Return (Bitmap [I >> 3] & (1 << (i & 7)))! = 0;} Void DumpAllFileRecord () {Pattribute Attr = FindAttribute (MFT, AttributeBitmap, 0); PUCHAR bitmap = new UCHAR [AttributeLengthAllocated (attr)]; ReadAttribute (attr, bitmap); ULONG n = AttributeLength (FindAttribute (MFT, AttributeData, 0)) / BytesPerFileRecord; PFILE_RECORD_HEADER file = PFILE_RECORD_HEADER ( New uchar [bytesperfileRecord]); for (ulong i = 0; i
Thank you! Reference: 1.Gary Nebbett "Windows NT / 2000 Native API Reference" 2.Linux-NTFS Project NTFS Documentation Version 0.4 3.mark Russinovich Related Document 4.David SolomoMOM "Inside Windows NT, 2nd Edition" -------- -------------------------------------------------- ------------------------ Article from: http://www.geocities.jp/webcrazyjp/NTFS.HTM (this guy actually uses the space of Japan The domain) author: WebCrazy (tsu00@263.net)