Figure 1. (Screenshot of unregistered free demo version 19.5 SR-5 of WinHex.)
An Introduction to NTFS
(New Technology File System)
Copyright©2018, 2021 by Daniel B. Sedory
(NOT to be reproduced in any form without Permission of the Author !)
We would caution anyone who needs accurate data concerning exactly what happens under a specific OS
or how data is in fact stored, to
not only compare multiple sources, but also consult data from someone
who's actually debugged running code, using that data, since it will either
work correctly or not! You should,
of course, also perform your own verification of the information before considering it truly reliable; everyone
makes mistakes. If you wish to discuss NTFS, or any other topic, you can email us here.
Note: This page is still under construction . . . .
We are
working on EXAMPLES to
show how this data can actually be used!
Our main reason for publishing these notes on NTFS, and indeed much of the information here at The Starman's Realm, is an attempt to alleviate some of the confusion in the forensic community (and others) caused by typo errors, inaccurate statements[1] and even blunders regarding what is available online and in print concerning NT file systems[2] and other relevant data. Furthermore, we believe in using real-world data examples in order to explain a topic. Simply learning 'terminology' or listening to or reading someone's words as they attempt to teach a complex subject can keep many from truly understanding.
First, a few definitions (some words being necessary; others not so much) to help in understanding NTFS:
A file on a computer drive is essentially an artificial container for holding some kind of information. A file's boundaries (within a
larger container often called a volume) are kept track of by its file system.
A file system (NTFS being one of a few
well-known types; including FAT32 and ext4) must, of course, also store that boundary information (and any other associated data;
such as a file's name and when it was created) somewhere on the same disk drive.
Metadata refers to data that provides information about other data. In the physical world, the old 'index cards' of a library that could be used to find a book on its shelves (according to the Dewey Decimal, LC or some other classification) also contained a great deal of metadata about each book: The book's author, when it was published, by what printing house(s), how many pages that edition had, etc. etc. A 'list of lists' is another example of metatdata. Metadata is most often found in a structured format which allows one to more easily retrieve some sought after data or to manage data resources.
NTFS stores this metadata within the same volume its files are found; primarily as entries in index files and the MFT (Master File Table; see below).
One of the interesting things about NTFS is that even the instructions and system data used to manage the contents of its file system are also stored as files within its volumes; everything is a file in NTFS. So, NTFS volumes have meta files within them:
In fact, even the 16 sectors of an NTFS partition's Volume Boot Record (or VBR); which always begins at Logical Sector zero (0), is a meta file under NTFS (its file name is: $Boot).
The files in which the structured metadata of a Windows™ NTFS volume are stored each have a dollar-sign ($) as their first character (MFT Record # 5 is not a metafile). Most users are unaware of this, because these files are kept hidden from them in a very special way: Even if the Microsoft® Windows™ OS's "Folder Options" -> "View" tab settings are set to show both hidden and system files, users will never see any of these meta files! And the '$-sign' character has nothing to do with how the OS hides these files. Users can easily create a file with a $-sign as the first character; even files with the metafile names, provided they do not attempt to do so in the root directory, since they would conflict with the files that already exist there. Some examples:
Examples 1. We Can Create '$'-Character Files | Examples 2. Commands Showing NTFS | |
C:\Documents and Settings\[user]>cd\
C:\>echo "Not an official metafile!" > $MyDfile
C:\>del $MyDfile
C:\>mkdir $test
C:\>cd $test
C:\$test>echo "you can easily do this!" > $MFT
C:\$test>echo "With any metafile name!" > $LogFile
C:\$test>echo "Such as Mft2 too!" > $MFTMirr
C:\$test>dir
Directory of C:\$test
03/20/2018 06:10 PM 28 $LogFile
03/20/2018 06:09 PM 28 $MFT
03/20/2018 06:11 PM 22 $MFTMirr
3 File(s) 78 bytes
C:\$test>cd ..
C:\>rmdir /s $test
$test, Are you sure (Y/N)? yThe commands above assume you do not have a $MyDfile file or a $test folder in your C: drive's Root Directory. |
Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Windows\system32>cd\ C:\>dir /a:h $MFT [/a:h shows Hidden files.] Directory of C:\ Always -> File Not Found C:\>echo "But unable to do this!" > $MFT Access is denied. C:\>echo "In the Root Directory!" > $LogFile Access is denied. C:\>echo "Which shows they exist!" > $MFTMirr Access is denied. ( We used "Run as administrator" Command Prompt. Try dir /a:s ['system'] or even dir /a:hs ['hidden and system'], it makes no difference: Always -> File Not Found .) | |
| The Examples 2 box above shows a Windows 2000 or later OS will always return File Not Found for these NTFS metafiles.[3] | ||
The fact that a user cannot create these particular files in the Root Directory shows they do exist there; even if you cannot see them. So what exactly
keeps the average user from ever seeing these files? The answer is the code in NTFS.SYS[4]. Only a disk editor such as
WinHex[5] or some other forensic tool[6]
designed to do so, will allow you to easily view these files. One
could of course search for and view the 'raw' bytes of these metafiles using the free hex and disk editor HxD,
but that would require both the necessary experience and more time to find them.
This screenshot of an NTFS partition 'opened' in WinHex shows some
of the metafile names in the Volume's root directory:
In the window above, we've highlighted a few useful items inside the WinHex display for our study of meatafiles:
1) We point out again that the $Boot file always begins at Logical Sector 0 of the volume /
partition.
2) The first 4 bytes of every MFT record entry should always be the ASCII characters: "FILE"[7].
Note: If the 5th byte (offset 0x04) is 0x30; an ASCII "0" character, then the file
records are for NTFS version 3.1 (Windows XP or later), but a 0x2A here (an asterisk * character) would indicate the records are
for a Windows 2000 or earlier NT OS.
3) When viewing the $MFT file, WinHex shows the record/entry number in focus; note the "(#0)" next to the $MFT file name (in the dark gray area of the display). This indicates the user is viewing the very first record entry
of the $MFT file.
4) For every file (or directory) entry in the MFT, its Microsoft Unicode name technically begins 2 bytes preceding or
ahead of its printable characters: For example, in the display above, where the $MFT name begins at offset 0xF2, the byte at
offset 0xF0 (a 04 in this case) indicates the length of the name; and since it uses only a single byte for its length, that means no
Windows NTFS file name can be longer than 255 characters (0xFF = 255). The second byte (a "03") indicates the type of name[8]. It should also be noted that the location of a file name within each MFT record is not always the same! For example,
both the $AttrDef and the Root Directory file names in our sample MFT records (see below), begin at offset
0xD8 in MFT record numbers 4 and 5 (see Table 2 below for the file names of the first 16 MFT records): "08 03 24 00 41 00 74 00 74 00 72 00 44 00 65 00 66 00 ..$.A.t.t.r.D.e.f." and "01 03 2E 00 ...." (the actual name within the MFT for the Root Directory being a single 'dot' or period; hex: 0x2E with no $-sign in front of
it, though other works sometimes list it that way). Nor will it always be the same location in different volumes for the same record: For example,
in the $MFT file on a different drive, we found its Root folder name ('.'; 0x2E) at offset 0x138. In fact, when the contents of an MFT
record changes (which happen every time a file is modified or simply read), any number of its attributes may have their locations shifted
within that record.
Since 7-Zip is a compression and archival tool[9], it may surprise many
that it can also be used to view the metafile names in an NT volume's Root Directory provided it's not the volume the Windows OS is currently
running on.
Steps for looking at NTFS metafile names under 7-Zip:
1) Open the 7-Zip File Manager.
2) Click on the \\.
item. (If you do not see it, then use the Green Up Arrow button 
until you get to the highest level possible.)
3) Click on an NTFS Volume's Drive Letter. Note: If you try to open a PC's active Windows OS volume (normally the C: drive) this way; or
any volume that has a file/folder opened by some other process, 7-Zip will display an error message similar to these:
HOWEVER, there is a way to view even the metafiles
of an active Windows OS drive, or some other drive with running processes:
First, rather than attempting to open a mounted drive letter with normal user rights,
start 7-Zip with Administrator privileges (required), then choose the new item: "PhysicalDrive0" as seen here:
Then you can open the Active Windows OS partition ("1.ntfs" in this case) and proceed with steps 4 and following below.
4) It will take some time for 7-Zip to "Open" all the files in the volume.
5) Locate and click on the folder
item titled: [SYSTEM]. 7-zip's display should appear similar to this one:
However, it must be pointed out that unlike WinHex, 7-Zip can not provide any data about the metafiles which exist only inside the MFT (the ones shown with '0' bytes for their file size in the display above). But it's still quite useful for quickly viewing what metafiles do exist in a volume and inside of a metafile folder; such as "$Extend".
6) To view the contents of any of these typical NTFS Metafiles, such as "$Volume" (which contains only "resident" data; there will be more on this and the term "non-resident" below), you'll need to use an application (we'd recommend HxD) capable of doing so.
As others have noted, apart from the version numbers listed in the table below, if we consider all the Windows service packs and
updates which have affected the NTFS.SYS and other critical NT file system files over the course of its history, only then might
it be accurate to conclude as one reference states: "numerous versions of NTFS exist."[10]
[In the future, we hope to list different versions of NTFS.SYS or other
files which have affected the details of the NT File System.]
NTFS | When | Operating System | Comments |
|---|---|---|---|
1.0 | July 1993 | Windows NT 3.1 |
|
1.1 | May 1995 | Windows NT 3.51 |
|
1.2 | July 1996 | Windows NT 4.0 | Due to the OS version being NT
4.0, |
3.0 | DEC 1999 | Windows 2000 | Since Win2k was thought of as NT 5, |
3.1 | AUG 2001 | Windows XP | Per logic above, this NT version has |
|
*Somewhat understandable, since the same system file on an NT 4, Win 2000 and Win XP install has file version numbers: 4.0.13x1.x, 5.00.2195.xxxx and 5.1.2600.x, respectively. But these numbers are indicative of the OS version, not the NT File System version. | |||
And it has officially remained at version 3.1 ever since Windows XP was released, even though many new features were added in 2008, and at other times. The fsutil file system management command-line utility, first included with Windows XP, can be used to display a volume's NTFS version by entering: fsutil fsinfo ntfsinfo X: ; where X is a drive letter. The last screen shown here is from a Windows™ 10 machine (which shows fsutil itself has new features):
 Figure 2a. fsutil is a complex utility which will be described in |  Figure 2b. |
First, note that (except for NTFS v.1.0 and 1.1 volumes[11]) the last sector of an NTFS partition is always reserved for a copy of the volume's Boot Sector (often referred to as the Backup Boot Sector). Everything is a file in an NTFS volume, but there is no entry in the MFT for the BBS (Backup Boot Sector)[11], because it is outside of the NTFS volume. So, an NTFS Volume is always 1 sector less than its partition: SizeOf_NTFS_Partition - (1 sector) = SizeOf_NTFS_Volume. This is also true for NTFS volumes on GUID Partition Table (GPT) disks.
Why is a volume's Boot Sector critical enough to warrant having its own backup copy? Because it stores the locations of both the $MFT and $MFTMirr files, and without access to the Master File Table, the operating system cannot boot! The following table refers only to where these two locations are stored in the Boot Sector; see our page on the NTFS Boot Sector for all the other data which is contained in its BIOS Parameter Block (or BPB):
Hex Offset | Length |
Hex | Decimal Equiv. | Description |
|---|---|---|---|---|
| 30h | 8 Bytes |
00000000 000C0000 |
786,432 * | Starting Cluster Number of the $MFT file in this partition. |
| *All Windows XP and later Windows OSs place the $MFT file at LCN 0x0C0000 (786,432). See Layouts, Era 2. (Note: If the partition is not large enough, this value would be changed by the OS; it could also be altered by 3rd party software.) | ||||
| 38h | 8 Bytes |
00000000 00000002 |
2 * | Starting Cluster Number of the $MFTMirr file in this partition. |
| *All Windows 7 and later Windows OSs place the $MFTMirr file immediately after the Volume Boot Record; at LCN 0x02, that's Logical Sector 16 for 4 KiB clusters. See Layouts, Era 3. (Note: This value could be changed by 3rd party software.) | ||||
This table shows the hex bytes and some ASCII characters for the NTFS Boot Sector of the C: volume of a Windows 10 PC with a 1 TB disk drive. It is comprised of 512 bytes, most of them being the boot code (with a light green background). The bytes with a light red background are all part of the BPB; except here we've highlighted the starting locations of the $MFT and $MFTMirr files by giving them a sky blue and gray background respectively:
The bytes with a violet background are error messages used by the boot code. The last two bytes of any Boot Sector are always 55 AA (also written as the hex number: 0xAA55). |
|
As an illustration of what will happen if the location of the $MFT file is in error, rather than completely zeroing-out the data, we simply changed the starting location of only the $MFT file in a Windows 7 PC's C: Volume Boot Sector (at offsets 0x30 - 0x37) from 0x0C0000 to 0x0BFFFF (just 1 cluster less!). When we tried to boot the OS again, the PC displayed:
So, even with the bloated size of a Windows 10™ OS, though our test PCs never lost the location of the $MFTMirr file, none of them were able to repair the issues; even after re-booting and selecting various repair options using the install DVD! For all of their touted advancements over the years, you would think Microsoft could have attempted to use the Backup Boot Sector's data; especially if the $MFT file's starting location was completely zeroed-out (making it the same location as the Boot Sector; which it obviously could never be in that location!), but it appears the Microsoft policy makers decided very long ago to not become involved in actual data recovery. They likely determined: It would be better for user's to have a technician examine their data issues and decide what to do, rather than us spending more money and wasting time on writing software that needs to make so many critical decisions about customer's data.[12]
How Large is an NTFS Cluster? Few today will ever encounter an NTFS Cluster that is not 4 KiB (4096 bytes), since the exceptions are: 1) When working with an NT 3.1 through NT 4.0 install volume, because those partitions always began as FAT16 and were converted to NTFS after using the FAT16 default cluster sizes, 2) Because NTFS volumes under 2 GiB; even for Windows 2000 and Windows XP, did in fact have smaller cluster sizes [We will be adding detailed notes on this in the near future!] and 3) The next change in the default cluster size is for volumes over 16 TiB (it defaults to 8 KiB). |
Next, we need to ask: For what Windows OS version? Yes, what OS version, not what NTFS version! We have identified basically three different layouts, so the question could be stated as: "From what NT OS layout era is the volume?" Though technically the 'layout' depends on what format code was used under an OS to create the volume, in this regard the NT systems generally fall into these three groups (or eras):
NTFS Layout Eras | |
|---|---|
Era | Includes these Windows Operating Systems[13] |
1 | The beginning of NTFS (Betas and Windows NT 3.1), Windows NT 3.51, Windows NT 4.0 (and its Service Packs 1 - 6), all of their Server and Advanced Server versions and the NT 5.0 Betas which became Windows 2000 (and its SP1 - SP4). |
2 | Windows XP (and SP1 - SP3), Windows Server 2003 (and SP1, SP2 and R2; R='Release', there was no R1) and Windows Vista (both the 32-bit and 64-bit versions). |
3 | Windows 7 (including its 32-bit version), Windows 8 and 8.1 and Windows 10; as well as the various Server 2008, Server 2012 and Server 2016 versions. |
NOTE: The three diagrams below (Figures 3 through 5) are not to scale; which means the size of the boxes used for the VBR, $MFT, Mft2, BBS and the whole partition are not in true proportion to each other. The VBR and BBS are, respectively, only 8192 and 512 bytes, and Mft2 is only 4096 bytes long. The size of the $MFT file will vary. If we attempted to show these areas to scale, some of the boxes couldn't be a single pixel wide even for a rather small partition. |
1) Under Windows operating systems of the first era, the beginning of the $MFT file is found either immediately after or near to (relatively speaking) the Volume Boot Record (VBR). When an unformatted drive area had a new NTFS volume created under the early systems (NT 3.1, 3.5, 3.51 and their Servers), the $MFT file was placed in clusters immediately following the VBR. This is why much of the literature concerning the NT File System shows the MFT at the beginning of a volume. For Windows NT 4.0 and 2000, it's normal to find a gap of 16 sectors between the VBR and $MFT. On the OS install volumes from this era, we have seen the $MFT begin at Logical Sectors ranging from only 32 to 202,915 (this is the largest 'gap' from the VBR we found; it's possible a larger one exists). It should also be noted that no matter where the $MFT file began, the $MFTMirr file was created in the center of the volume.
A typical layout for a Windows NT 4.0 or Windows 2000 partition from this era would look like this:
Unfortunately, Microsoft did not update their own diagrams used in various documents after they made changes to NTFS, so authors continued copying what became incorrect data[14] for the next layout era of Windows operating systems:
2) With the release of Windows XP, although the $MFTMirr file was still being created in the center of its volumes, the $MFT file began to appear in a specific location: At LCN (Logical Cluster Number) 786,432 (or 0x0C0000 in hex)[15]. So, what happens if I create a volume that is very close to or even smaller than LCN 786,432?
NOTE: For any volume which has simply been 'expanded,' such as the Windows XP C: volume shown in Figure 2a above (we manually altered its partition table entry and the data in its VBR to expand its volume), the "Mft2" ($MFTMirr file) will no longer be at the center of the volume.
3) The Era 3 layout (as we're calling it), began with the release of Windows 7. The $MFT file still begins at LCN 0x0C0000, but the
"Mft2" ($MFTMirr file) is now placed immediately after the VBR ($Boot); at Logical Sector 16. That is LCN 0x02.
The fsutil display from a new Windows 10 laptop (see Figure 2b. above) shows precisely these locations:
Mft Start Lcn : 0x00000000000c0000 and
Mft2 Start Lcn: 0x0000000000000002.
NOTE: The locations for the $MFT and $MFTMirr (or "Mft2") files as described in all three of the NTFS Era Layouts above are for partitions and volumes that have not been altered by 3rd-party partition or defragmenting tools (a worthwhile third-party tool can in fact move the location of both these files), nor by the Windows OS itself (Vista or later); which has limited Shrink and Expand capabilities: Windows can "Shrink" NTFS volumes to the point where Mft2 ($MFTMirr file), or in the case of an Era 3 volume, the $MFT file, end up being at the end of a volume, since the Microsoft Shrink feature cannot move either one of these files from their original location. It may be true that Windows Shrink will not move some or all of the other NTFS metafiles as well. Thus, the reason Era 2 partitions, with the $MFTMirr file located in the middle of the volume, cannot be shrunk by Windows Disk Management more than about half (1/2) of their original size! |
The most important file within an NTFS partition (apart from any code which helps an operating system manage it) is the $MFT (Master File Table). Why? Because it's basically the master index to the location and size of every file within the whole volume; including the MFT itself. In fact, it's so important, there's a backup copy of the MFT's most important records called the $MFTMirr file. (Note that $MFTMirr is not a complete backup copy of the $MFT file! In fact, it contains only the $MFT, $MFTMirr, $LogFile and $Volume entries; which are the first 4 records of the MFT.)
Note: If a file's size is small enough, NTFS will store its entire contents only within its MFT entry! This would be true, for example, for many small text files. For 1 KiB NTFS record lengths (the norm), files of about 700 bytes or less are normally found only within the $MFT file. Under NTFS, these are known as resident data attribute records. Many directories ('folders') which have only a few entries may also be stored as resident records within the MFT. (The various attributes of MFT record entries will be explained further below.)
Note: Each normal file record inside an MFT file, including an entry for the $MFT file itself; which is always the first record (ID # 0), begins with the header: FILE at offsets 0x00 - 0x03. (And for any NTFS created by Windows XP or later, the ID # of the entry is found at offsets 0x2C through 0x2F.)
The first 16 records of every NTFS Volume's MFT (Master File Table) are always reserved for the same metafiles and the Root Directory, and are always found in this order:
$MFT | Metafile | Common |
Description |
|---|---|---|---|
0 | $MFT | Master File Table | The file
which contains all the records of every file on the volume; including itself! |
1 | $MFTMirr | MFT Mirror File | Backup copy of the $MFT file's most
important entries: The $MFT, $MFTMirr, $LogFile and $Volume records. |
2 | $LogFile | Log File | The Log File might be useful in recovering
files after power losses or OS lock-ups. |
3 | $Volume | Volume Data | Among other data, contains the volume's name. |
4 | $AttrDef | Attribute Definitions | The Attribute Definition Table. See Attributes. |
5 | . | Root Directory | Contains an index of
all the files and folders in the Root Directory. Note: It's Filename is a single dot (0x2E) character. Technically, not a '$-character' metafile, but as an index, it is meta data, so it (as are all other folders) is treated by the MFT as if it were a file; after all, everything in the NT File System is a file. |
6 | $Bitmap | NTFS Bitmap | Allocation status of every cluster on the Volume. |
7 | $Boot | Boot Record | 16 sectors always reserved; but only about 8 sectors of code. |
8 | $BadClus | Bad Cluster File | Listing of all 'bad clusters' on the volume. |
9 | $Secure | Security | [Still under construction.] |
10 | $UpCase | UpperCase Table | [Still under construction.] |
11 | $Extend | Extend Table | [Still under construction.] |
12-15 | Reserved | Unnamed | These 4 records are reserved for Metafiles when the file
system is created. Their official function(s) are unknown at this time. ( But malicious and White Hat programmers have been able to insert files, such as AUTORUN.INF, into these locations.[4]) |
The first 42 or 48 bytes of each MFT record, comprise its "header" which contains:
Offset | Size | Description |
|---|---|---|
0x00 | 4 | Always: FILE (or Magic Number = 0x454C4946; |
0x04 | 2 | Offset to 'Update Sequence...Array' (from start of FILE header); |
0x06 | 2 | Size in WORDs of the 'Update Sequence Number and Array' (USA) |
0x08 | 8 | $LogFile Sequence Number (or LSN) |
0x10 | 2 | Sequence Number |
0x12 | 2 | Hard Link Count |
0x14 | 2 | Offset to first Attribute |
0x16 | 2 | Flags |
0x18 | 4 | Actual Size of this FILE Record. |
0x1C | 4 | Allocated Size of this FILE Record; normally 0x400 (1 KiB; 2 sectors). |
0x20 | 8 | File Reference to Base FILE Record |
0x28 | 2 | Next Attribute ID |
0x2A | 2 | Used to align to 4-byte boundary (only since NTFS version 3.1) |
0x2C | 4 | MFT Record Number (only since NTFS version 3.1) |
There are some sample $MFT files here for the first 17 records; in both binary and text format as well as an HTML color-highlighted disk editor view! These are from a Windows XP Professional OS and a Windows 2000 Professional OS installation on real physical disk drives; the XP install includes a BAAD record.
Within the $MFT file, everything, including all data, is an attribute. The $AttrDef file contains a list of all the attributes available for use in that volume. Each attribute has a type number associated with it which we've highlighted in this $AttrDef Sample File. The attributes found in this file are as follows:
Attribute | ATTRIBUTE |
|---|---|
0x10 ( 16) | $STANDARD_INFORMATION |
0x20 ( 32) | $ATTRIBUTE_LIST |
0x30 ( 48) | $FILE_NAME |
0x40 ( 64) | $OBJECT_ID |
0x50 ( 80) | $SECURITY_DESCRIPTOR |
0x60 ( 96) | $VOLUME_NAME |
0x70 (112) | $VOLUME_INFORMATION |
0x80 (128) | $DATA |
0x90 (144) | $INDEX_ROOT |
0xA0 (160) | $INDEX_ALLOCATION |
0xB0 (176) | $BITMAP |
0xC0 (192) | $REPARSE_POINT |
0xD0 (208) | $EA_INFORMATION |
0xE0 (224) | $EA |
0x100 (256) | $LOGGED_UTILITY_STREAM |
Note: ID # 0xF0 is not defined at this time.
1[Return to
Text] For example, The Complete Guide to Windows Server 2008, John Savill (Pearson Education, 2008), which was invaluable to many admins working
with this server, still had this error (on the 2nd page of Chapter 5): "The MFT2 is a mirror of the first 16 records of the MFT, which describe
the metadata files themselves and are, therefore, most vital." Well, that number (16) is incorrect. $MFTMirr is a copy
of only the first 4 records of the MFT. Whoever wrote '16' was probably thinking about the fact the first 16 records of the
MFT are always the same metafile records; and (expected?) that all 16 should be copied. But no one has seen a Microsoft $MFTMirr that does; not even on
a Windows 2008 Server.
Microsoft® documentation has had its share of errors which, unfortunately, continued to be perpetuated by students
copying the errors into their projects! One example, which also influenced Trojan and malware authors, could be found (until about 2019) by searching for the
terms: "how ntfs works" "server 2003" "ntldr.dll" site:microsoft.com and looking for ntldr.dll. Well,
there was no such Windows OS file as ntldr.dll! The Windows XP and 2003 Server 0S file's name was only: ntldr (no
.dll extension). Some malware authors saw this and used the name for malicious code (variations on other real system file names have also been used many
times for Trojans and other malware). So, just because you see something in IBM®, Microsoft® or some other large software and/or hardware company's
documentation that does not mean it must be correct; verify it first. [Note: The "ntldr.dll" error referenced above can still be found on this Microsoft
page.]
2[Return to Text] "Systems" plural, because both the linux community and Apple® developers along with a number of commercial software houses like Paragon Technologie GmbH and Tuxera, each have their own versions of NTFS drivers for many different OSs; all of which may be helpful in understanding and/or implementing successful NTFS drivers, but not necessarily true of Microsoft® drivers. For example, one can read about NTFS-3G here and various versions of Apple's NTFS drivers here. But, the main focus of this page will be on verifiable data concerning the NTFS versions of Microsoft® Windows™.
3[Return to Text] Prior to Windows 2000 (sometimes referred to as 'NT 5.0'), it was possible to see the size of an individual NTFS metafile by performing the "dir /a:h <metafile name>" command. It functioned as shown below under Windows NT 3.1 through Windows NT 4.0 (SP-6) and its Servers. For example:
 | Until Microsoft added the fsutil |
If the NFI utility is copied to the WINDOWS folder of an XP install, entering "nfi" at a command prompt will display its help info, but this does not explain or provide an example on how to enter an "NT-device-path" so here's an example where the first hard disk must be entered as "\device\harddisk0\dr0" (including the \backslashes\):
C:\>nfi \device\harddisk0\dr0 63
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.
***Physical sector 63 (0x3f) is in file number 7 on drive C.
Boot Sectors ($Boot)
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$SECURITY_DESCRIPTOR (resident)
$DATA (nonresident)
physical sectors 63-78 (0x3f-0x4e)
C:\>nfi C:\$MFT
Master File Table ($Mft)
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 6291456-7032255 (0x600000-0x6b4dbf)
logical sectors 106529872-106541135 (0x6598450-0x659b04f)
$BITMAP (nonresident)
logical sectors 267688-267783 (0x415a8-0x41607)
4[Return to
Text] The NTFS.SYS File System Driver contains the names of all the "$-character" system files and treats them as specially
Protected files, returning ACCESS DENIED to any system code (such as Windows File Explorer) acting on behalf of users or even
Administrators which simply attempts to view their names. So these hidden, system NT metafiles can never be listed in the Windows Root
Directory, even at a Command Prompt; let alone be accessed for reading. This means any tool (possibly apart from Microsoft's own utilities; like fsutil) that can view these special files, must be accessing these files and their content outside of the usual OS code which would
normally call NTFS.SYS to access an NTFS file. However, the special protections which these files have is not simply a matter of whether their names
exist in NTFS.SYS: We can actually create our own metafile-type file which will be completely invisible under File Explorer; even with its
"Hide protected operating system files (Recommended)" checkbox UN-checked, if we create it in one of the Reserved MFT entries! This is
in fact how malicious code is able to be embedded in USB drives by creating an invisible AUTORUN.INF metafile. As proof that this can also be
done in a disk drive volume, we created a VHD file for you to examine: SEDORY.vhd.zip (152 KB) which contains
a fully functional 19 MB NTFS file system with the new metafile "SEDORY_is_here!" as revealed in the 7-Zip display
below. One of the intermediate steps in creating this file was running CHKDSK on the modified Volume; which happily fixed/indexed the metafile for us:
" Recovering orphaned file SEDORY_is_here! (D) [that's MFT record
0x0D (or #12 of 0 through 15); for a total of 16 System Metafile records.] into
directory file 5. " and " 1 unindexed files recovered to
original directory. "
[Return to Text]
5[Return to
Text] Note: You can download and make use of WinHex from here with limited
functionality. You may evaluate WinHex free of charge for 45 days without licensing it. However, in this mode WinHex will not save files larger than
200 KB, nor write to disk sectors or edit virtual memory: So you could, for example, save a copy of your MBR and VBR sectors, but not be able to
write them back to the disk drive. Licensed copies of WinHex include automatic color highlighting of various bytes inside $MFT records, but this
feature is disabled in the free demo which will also sometimes show this reminder:
6[Return to
Text] Another tool would be FTK Imager (a free tool from AccessData which can be downloaded from
here). Here's a pic of FTK Imager running on a UEFI/EFI
laptop under Windows™ 10 installed on a GPT disk drive:
7[Return to
Text] The exception would be if one or more of the records had an unreadable sector(s), in which case, the Windows OS (or more specifically, running
an error scan with a utility such as chkdsk) will replace the "FILE" header with a "BAAD" header, and all of its remaining bytes will be zero-filled ('00' bytes only); with the exception of the last two bytes in each
sector called the 'Update Sequence Number'. (Note: We've included a BAAD record from a physical drive running Windows XP Professional in our $MFT Sample Metafile Records; it's the last record, MFT # 16, in Sample 1.)
It should be NOTED that the "BAAD" indicator can also (though rarely) be found at the beginning of some MFT record which has become 'corrupt' due to some strange
behavior of the PC, its OS or by someone purposely altering system bytes within that MFT record. We're searching for sites that provide examples of what
a Windows OS will do with such MFT entries.
For an additional reference, see the "BAAD" entry in the "Glossary" of the
work NTFS Documentation by Richard Russon and Yuval Fledel, which states that
during a chkdsk run, "if [it] finds a multi-sector item (MFT, INDEX BLOCK, etc) where the multi-sector header doesn't match the
values at the end of the sector, it marks the item with the magic number 'BAAD', and fill [sic] it with zeroes (except for a short at the end of each
sector...)" In this quote, we take "short" to mean a USN (Update Sequence Number); which is indeed found at the end of each MFT redord's
sectors as well as at the beginning of the Update Sequence Array (see MFT Header Layout for more information on USNs and the USA). It
is unfortunate that few, if any, other works, contain these details concerning "BAAD" records due to 'bad sectors' on a disk drive.
8[Return to Text] The name types are: 01 - Indicates a LONG filename, 02 - Indicates a SHORT filename, 03 - Indicates a LONG filename that also meets the requirements for a SHORT filename.
9[Return to Text] 7-Zip happens to be one of the best free 'Windows' programs available on the Net (in our opinion). We have not only used it to extract files and compress them into the standard archives (BZ, GZ, TAR, ZIP and of course 7z), but also extract both files and data from proprietary archives, emails and whole file systems! (Examples: Not only archives such as: ARJ, RAR, Microsoft CAB files, but also file systems and system related data: Apple™ DMG, Linux EXT and SquashFS, ISOs, UDFs, FAT, HFS, NTFS, GPT and UEFI drives and image files, Microsoft CHM, MSI, VHD and WIM files, and more.). 7-zip is one of our go to tools when trying to view whatever is inside some obscured data, quickly! You can download the free (GNU licensed) 7-zip from here.
10[Return to Text] John Savill, The Complete Guide to Windows Server 2008 (Pearson Education, 2008), Chapter 5, 2nd page. Did this author perhaps also have in in mind all the other versions of NTFS from other vendors; as mentioned in our note 2 above?
11[Return to Text] For the Windows NT 3.1 (NTFS v. 1.0) through Windows NT 3.51 (v. 1.1) OS versions, we do find copies of their NTFS "Boot Sector" in the middle of the volume, immediately preceding the $MFTMirr file. Furthermore, the $Boot (MFT #7) entries actually reference this cluster in a "2nd run" of the "Run List" in the MFT record's $DATA (0x80) attribute! The "1st run" is a link to the full 16-sector Boot Record at the beginning of each volume.
12[Return to Text] Our opinion here is based on the fact that both IBM and MS-DOS had backup copies of the FAT table for their FAT16 and FAT32 file systems, but none of their DOS versions ever made use of those, and now many decades later, neither do any of the Windows operating systems make use of their backup boot sectors. In all fairness, Microsoft did publish some 'knowledge base' pages on how such data could be used; though it was mostly useful for data recovery technicians rather than the average user. See: How to Recover From a Corrupt NTFS Boot Sector (KB-121517) and Recovering NTFS boot sector on NTFS partitions (KB-153973).
13[Return to Text] These lists do not include 'Embedded Devices', cancelled versions, such as, Nashville, NepTune or Odyssey, nor any Appliances or Mobile devices. See: List of Microsoft Windows Versions and its links for a complete list of all Windows versions and editions.
14[Return to Text] For example, on Microsoft's Technet page: How NTFS Works which states that it applies to the Windows 2003 Servers, the diagram "Organization of an NTFS Volume" not only implies the MFT starts immediately after the 'Boot Sector' which it no longer did, but also that the $MFTMirr file (called "Master File Table Copy" in the diagram) was at the end of the volume, instead of its center. And there's an example (from 2007) where a university computer science teacher in 'Silicon Valley' had copied that diagram word-for-word, elongated it (stretched it out) and titled it "NTFS partition structure" (which probably confused some of his students); see COEN252/152NTFS. In reality, these diagrams should look more like this one:
15[Return to Text] Curiously, for volumes having 4 KiB clusters, an LCN of 0x0C0000 (4 zeros) is also a logical byte-offset of 0xC0000000 (7 zeros) bytes, so don't confuse, or be confused by, the two values; this is only a coincidence. (Well, sort of... A 4 KiB; i.e., a 4096-byte, cluster is 0x1000 bytes in hex, so it's easy to see why multiplying LCN 0xC0,000 by 0x1000 bytes/cluster = 0xC0,000,000 bytes).
Updated: 30 JAN 2018 (30.01.2018); 3 FEB 2018 (03.02.2018); 5 FEB 2018 (05.02.2018); 6 FEB 2018 (06.02.2018);
7 FEB 2018 (07.02.2018); 11 FEB 2018 (11.02.2018); 12 FEB 2018 (12.02.2018); 17 FEB 2018 (17.02.2018); 19 FEB 2018 (19.02.2018); 23 FEB 2018 (23.02.2018);
5 MAR 2018 (05.03.2018); 6 MAR 2018 (06.03.2018); 9 MAR 2018 (09.03.2018); 11 MAR 2018 (11.03.2018); 21 MAR 2018 (21.03.2018); 5 APR 2018 (05.04.2018);
19 APR 2018 (19.04.2018); 26 APR 2018 (26.04.2018); 3 JUN 2018 (03.06.2018); 27 NOV 2018 (27.11.2018); 30 NOV 2018; 3 DEC 2018 (03.12.2018); 26 May 2019
(26.05.2019); 7 JUN 2021 (07.06.2021). Replaced corrupted "SEDORY.vhd" file.
Last Update: June 9, 2021 (09.06.2021).
You can email me here: online reply form.
(It opens in a new window.)
MBR and Boot Records
Index
The Starman's Realm Index Page