NTFS

A walk through one of the most known file system.

Introduction

NTFS is the filesystem used by default on Windows systems. Like almost all NT stuffs under Windows, NTFS means New Technology File System. It's a pretty advanced journalized FS that integrates components against corruptions. Lucky FAs, it means there are some of these information that can be used in investigations.

The most important part of NTFS is called Master File Table - MFT.

MFT

The Master File Table is the table that contains information on all the files present on the disk. Parsing the MFT unveils a bunch of useful information during investigations.

Location

The MFT can be located thanks to the boot sector, the first 512 bytes of the volume. Below is partial view of the NTFS Boot Sector structure.

typedef struct _NTFS_BOOT_SECTOR {
		BYTE 				jmpInstruction[3];
		BYTE 				oemID[8];
		UINT16 		  bytesPerSector;
		BYTE 				sectorsPerCluster;
		[..]
		LONGLONG 		StartMFTCluster;
		LONGLONG 		startMFTMirrorCluster;
		signed char clusterPerFileRecord;
		[..]
	}

The location of the MFT can be calculated with the following

$$mftOffset = bytesPerSector \times sectorsPerCluster \times startMFTCluster$$

This location indicates the very first entry of the MFT, $MFT, which is the entry for itself - yes the MFT is referencing the MFT.

Each NTFS system file will start with $. For instance $MFT, $Logfile, etc.

The MFT is built from a sequence of MFT records, each representing a file or a directory on the system.

MFT Record segments

The size of an MFT entry, or record segment, is defined in the NTFS Boot Sector, in the clusterPerFileRecordfield. While the size can virtually be changed, it's mostly been 024 bytes since NTFS exists. Some tests need to be done here to assess what are the implications of a change.

Since an MFT entry always have the same size on a system, knowing the size of $MFT allows to know the number of entries in the MFT.

The structure of an MFT Entry is the following.

typedef struct MFT_RECORD {
	CHAR xMagic[4];
	WORD updateSequenceOffset;
	WORD fixupEntriesNumber;
	BYTE logFileSequenceNumber[8];
	BYTE sequenceNumber[2];
	WORD hardLinkCount;
	WORD firstAttributeOffset;
	BYTE recordFlag[2];
	BYTE mftEntryUsedSize[4];
	BYTE mftEntryAllocatedSize[4];
	UINT64 fileReference;
	BYTE nextAttributeID[2];
	BYTE xPadding[2];
	BYTE mftRecordNumber[4];
} 

A MFT record always begins with a magic that indicates whether the entry is valid or not.

FILE      // Valid entry 
BAAD      // Invalid entry 

An attentive reader will notice two things about the MFT record structure.

1. The structure size is not 1024 bytes as said earlier

2. The structure doesn't hold any information about the name of the file, the timestamps, the content, etc

And that's true. It was not a lie, an entry is 1024 bytes - but the above structure is incomplete. That's because the rest of the entry varies - a lot.

The rest of information of the file is stored in Attributes under the form of an attribute list.

Attributes

An attribute holds a specific type of information about an entry. It begins with a structure, known as Attribute Record Header. This header specifies the type, the optional name and the value of the attribute.

If the attribute content can fit in the MFT record segment (- remember, it's 1024 bytes only), then the attribute is called Resident. If it can't fit, then it's moved outside the MFT and stored on other clusters on the disk. It is then called Non-Resident.

Resident Attribute

The header structure contains an offset to the content of the attribute as well as its length.

Non-Resident Attribute

The header structure contains an offset to mapping pairs or data runs. These runs are a set of clusters where the attribute reside. They are constituted of an offset and a length, each offset referring to the previous data run.

Well-known attributes

Below are the most common and useful attributes with the information they contain.

$SYSTEM_INFORMATION

• MACB data as timestamp (the ones display in Explorer - easily modifiable)

• USN

• SecurityID reference

$FILENAME_INFORMATION

Others - to come

Now one may ask - great, but where is the content of the files ? Well it depends.

File Content

If the content of the file is small enough (around ~700bytes), then it might reside in the MFT record itself, under the $DATA attribute. If the content is bigger, then the $DATA attribute contains data runs that point to the locations of the file parts on the disk.

But what if the file keeps growing and there are so many attributes to a point they can't even be stored on the MFT entry ?

In that particular case, the attributes themselves are stored outside the MFT entry in a Child Record. This child record is then referenced by the parent record in a $ATTRIBUTE_LIST attribute as a mapping pair.

$i30 / INDX

Windows NTFS Index Attributes - It's a B-tree index that exists in each MFT directory entry, which keeps tracks of each files that exists in the directory.

When the B-tree rebalanced itself, following creation, move or deletion of files it can results in slack-space which might holds indication of previous files in the target directory.

Directories with a small amount of files are stored in $INDEX_ROOT (always residents). Directories with a big amount of files are stored in $INDEX_ALLOCATION (always non-resident). Another attributes called $BITMAPkeeps tracks of which indexes are used. These 3 attributes are called $i30.

For each files contained in the directory, the `$I30` retains :

• Filename

• Parent directory

• File size

• $FN timestamps

$DELETED

Present in \$Extend\$Deleted starting from Windows 10, it retains all the files that are open in FILE_SHARE_DELETE mode and are deleted, until the last handle on the file is closed. The file names are not retained and are built from the file reference number of the file and a random hex bytes string.

$RECYCLEBIN

Starting from Windows Vista, the files deleted by a user are placed in $RECYCLEBIN\<sid> where SID is the SID of the user.

Two files are created :

• $I<random>- which contains information on the file itself such as fielname, original path, fiel size, deletion date.

• $R<random> - which contains the data of the file

$UsnJrnl

Present in $Extend\$UsnJrnl. It contains an ADS named $j which is the Usn (Update Sequence Number) journal itself. It records changes made to te volume and contains very little information about the files themselves.

NTFS uses spare data run on the $j to preserve data without consuming more disk space than actually needed. The file often appears to be multiple Gbs but in reality Windows keeps it around ~40MBs.

It contains the following information for each record :

• USN ID - corresponding to the offset within the file

• The file modification timestamp

• The reason of modification (FILE_DELETED, FILE _CREATE, etc)

• Filename of the file

• Parent MFT ID (direct directory)

Parser

• https://f001.backblazeb2.com/file/EricZimmermanTools/MFTECmd.zip