What is the $MFT? The $MFT, Master File Table, is the most important file in a NTFS file system. It keeps track of all files on the volume, their logical location in folders, their physical location on the hard, and metadata about the files, including:
- Created Date, Entry Modified Date, Accessed Date and Last Written Date, in the Standard Information Attribute.
- The Physical and Logical Size of the file
- Permissions (security access) for the file
All of this information is stored in an entry within the MFT, called (somewhat unsurprisingly) “MFT Entries“.
The MFT Entries are 1024 bytes, as standard. Every file and folder, has to have an MFT entry, to be recognized by the computer, including the MFT itself.
The first 16 entries of the MFT are reserved for NTFS system files, these include:
$MFT, $MFT Mirror, and $BitMap.
The MFT can expand but it never contracts, under normal use. This is very important for computer forensics investigators, as it effects the recovery of data and identification of deleted files.
When a file is deleted the MFT entry is marked as ready to be re-used. This entry will continue to exist until it is overwritten by a new file. When a new file is to created on the hard drive it overwrites the next available MFT entry, if they are no spare entries ready to be overwritten then the MFT will start to expand.
Example1:
If there are 100 entries in the MFT and one file, File X, is deleted and then 1,000 more files are immediately created then the MFT entry for File X would be overwritten. Though the contents of the file may exist on the hard drive, the MFT entry which includes the name, metadata, etc, would be overwritten.
Example2:
There are 10,000 entries in the MFT. 1,000 are deleted and 2 new files are immediately added to the drive. Therefore 998 entries should be recoverable. Though if the data for the files is recoverable or not will depend on if they have been over written.
These numbers may sound unlikely, but with website data being cached and then cleaned out, temorpary files created from software installs, and then deleted, these sudden changes in file counts are not unlikely at all.
Note:
The data for the file is seperate from the MFT Entry. This leads to several possibilities during deletion and subsequent use of a hard drive.
1) The file is deleted but the MFT entry and the file data are 100% recoverable. The deleted file can be 100% recovered.
2) The file is deleted and the MFT entry is recoverable but a portion of the file data is overwritten. This means that the file can only be partialy recovered.
3) The file is deleted and the MFT entry is recoverable but the file data is 100% over written. The file is not recoverable, but informaiton about the file, name, dates, sizes, etc is.
4) The file is deleted and the MFT entry and file data is 100% recoverable. The file is 100% lost. However forensic investigation could reveal a lot of information about the file, but not through the MFT, rather other forensic artefacts.
5) The file is deleted and the MFT 100% overwritten but the file data has not been 100% overwritten. The remaining file can be carved out from the unallocated space on the hard drive. The ability to carve the data would depend on fragmentation, amount of recoverable data (it could be 100%) and nature of the file
There are other permutations, where the MFT entry is not 100% over written, leaving MFT file slack.
More information on the MFT is available here.
A good resource on the MFT, and NTFS in general is the book – File System Forensic Analysis
Where is Your Data? 
June 5, 2009 at 11:42 pm
[…] MFT Mirror, seen as $MFTMirror in computer forensics tools, is a partial backup of the MFT. It is not, as is sometimes reported a complete backup of the […]
November 27, 2014 at 8:08 am
On a freshly formatted volume, inodes 0x0B to 0x0F are marked as in use, but empty. Inodes 0x10 to 0x17 are marked as free and not used. This doesn’t change until the volume is under a lot of stress.
When the $MFT becomes very fragmented it won’t fit into one FILE Record and an extension record is needed. If a new record was simply allocated at the end of the $MFT then we encounter a problem. The $DATA Attribute describing the location of the new record is in the new record.
The new records are therefore allocated from inode 0x0F, onwards. The $MFT is always a minimum of 16 FILE Records long, therefore always exists. After inodes 0x0F to 0x17 are used up, higher, unreserved, inodes are used.
This effect may not be limited to the $MFT, but more evidence is needed