The NTFS Master File Table (MFT)

 

The NTFS (New Technology File System) is managed by an ensemble of specialized metadata files (commonly referred to as metafiles) that, in aggregate, constitute a highly structured and sophisticated relational database for managing the volume. In essence, a metadata file serves as a repository of descriptive and structural information about other data entities within the file system. These metafiles operate outside the conventional user-visible namespace of the file system hierarchy. Consequently, even when an advanced user configures Windows Explorer to display hidden files, protected operating system files, and similar elements, the NTFS metadata files remain concealed from the standard directory enumeration interface. However, forensic or low-level disk analysis utilities capable of operating at the cluster or sector level can readily locate, inspect, and—in certain cases—modify these structures. Foremost among these metafiles is the Master File Table ($MFT), which functions as the central index and primary database table for the entire volume. 

The Master File Table (MFT)

The Master File Table (MFT) constitutes the foundational metadata repository within an NTFS volume. It encompasses a dedicated record for every file and directory object, encapsulating comprehensive attributes such as filenames, temporal metadata (including creation, modification, access, and MFT modification timestamps), allocated sizes, security descriptors, extended attributes, and the precise cluster runlists delineating physical storage locations on the volume. Consequently, it serves as the paramount artifact in digital forensic examinations for ascertaining file existence, chronology, content associations, and remnants of deleted or unallocated entities (until record reuse occurs).

To mitigate fragmentation of the MFT as the volume populates with innumerable objects, NTFS implements a protective reservation contiguous to the MFT's allocated space, commonly termed the MFT Zone. This buffer precludes allocation of user data within the reserved region until all non-reserved volume space has been exhausted, thereby promoting contiguous extension of the MFT and preserving performance integrity. By default, this zone approximates 12.5% of the total volume capacity on legacy configurations. The reservation ratio is configurable prior to volume formatting via the NtfsMftZoneReservation registry parameter (values 1–4), yielding approximate proportions of 12.5%, 25%, 37.5%, or 50%. On volumes formatted under modern Windows iterations (Vista and subsequent), the mechanism has evolved toward fixed-size increments—typically commencing at 200 MB and scaling in commensurate multiples—to optimize efficiency on high-capacity storage while still safeguarding MFT contiguity. As the volume approaches saturation, NTFS may progressively release portions of the unused MFT Zone tail for general allocation (with some forensic and technical sources noting staged halving of the effective tail in certain scenarios), though the core objective remains prioritization of MFT growth.

Microsoft documentation formally reserves the initial 16 MFT records (entries 0–15) for critical filesystem metadata files. In observed practice across operational volumes, user-created files and directories commonly commence allocation at entry 24 or thereafter. Entries 17–23 frequently function as extensions or overflow for system metadata when the primary reserved slots prove insufficient, with minor variations attributable to Windows version and volume initialization state. The following delineates the principal metadata files as defined by Microsoft (included here for referential completeness).

Entry	File Name	Description
0	$MFT	Actual file table. Contains at least one base file record for each file and folder on the volume that identifies which clusters host file data. A fragmented file will have a record for each fragment.
1	$MFTMirr	A duplicate image of the first four records of the MFT. This file guarantees access to the MFT in case of a single-sector failure.
2	$LogFile	Contains a list of transaction steps used for NTFS recoverability. Log file size depends on the volume size and can be as large as 4 MB. It is used by Windows NT/2000 to restore consistency to NTFS after a system failure. It provides information for file system journaling. It retains records of changes to the file system.
3	$Volume	Contains information about the volume, such as the volume label and the volume version.
4	$AttrDef	A table of attribute names, numbers, and descriptions. Defines attributes of files and folders on volume. These include hidden, read-only, and other file system attributes.
5	$.	Index of files in system root. Too many files in the root directory can impact system performance
6	$Bitmap	A representation of the volume showing which clusters are in use.
7	$Boot	Code used to mount the volume that defines the file system along with bootstrap loader code and a pointer to the OS boot files used if the volume is bootable.
8	$BadClus	Maps bad clusters for the volume.
9	$Secure	Contains security descriptors for files contained within the volume. Services running in the OS that maintain file-level security are dependent on this metafile.
10	$UpCase	Conversion table for translating lowercase characters into matching Unicode uppercase characters.
11	$Extend	Defines optional extensions,   including quota definitions, reparse point data, and others.
12 - 15		Not currently used.

Microsoft designates each entry within the Master File Table (MFT) as a file record (also known as a File Record Segment or FRS). The default—and overwhelmingly predominant—size of an MFT file record is 1024 bytes (0x400). The initial 42 bytes (offsets 0x00–0x29) constitute the fixed file record header, encompassing well-defined fields such as the signature "FILE", update sequence number and array (fixup), link count, flags, real and allocated sizes, base file record reference, next attribute identifier, and related metadata.

Note: However, sources vary slightly: some describe a 48-byte header (including the update sequence array/fixup area at offset 0x30 in newer NTFS 3.1+ volumes) or note that the exact boundary is flexible because the offset to the first attribute is stored in the header (at offset 0x14, usually 0x38/56 decimal). The "42 bytes" is a reasonable approximation, but not rigidly fixed in all documentation.

Subsequent content within the record comprises a sequential series of attributes, each prefixed by its own attribute header (containing type, length, and other descriptors) followed by the attribute data or resident/non-resident payload. Every file, directory, and NTFS system metadata structure on the volume is allocated an MFT file record, including critical system files such as $MFT (record 0), $MFTMirr, $LogFile, $Boot, and others. The sole notable exception is the Partition Boot Record (volume boot sector located at the first sector of the partition, which includes the BIOS Parameter Block). This structure resides outside the MFT and is not manifested as a standard file record.

The size of each MFT file record is established at volume creation (format) time and is typically 1024 bytes. While the NTFS specification permits alternative sizes (such as 4096 bytes), 1024 bytes remains the de facto standard observed across virtually all contemporary Windows deployments and digital forensics examinations. Two primary mechanisms exist for determining the MFT record size:

• The designated size is encoded in the volume boot sector at byte offset 0x40 as a signed 8-bit integer.
  • If the value is positive (0x00–0x7F), it specifies the number of clusters per MFT record.
  • If negative (0x80–0xFF), it indicates a byte-based size, computed as 2 raised to the power of the absolute value of the number (e.g., 0xF6 = −10 yields 2¹⁰ = 1024 bytes).
• Independently, the allocated size of any individual file record can be read directly from bytes 0x1C–0x1F (a 4-byte little-endian DWORD) within its own file record header.

Every $MFT file record commences with a fixed header. The first attribute invariably begins at byte offset 0x38 (56 decimal) relative to the start of the record (this offset is explicitly stored at header offset 0x14 and is consistently 0x38 in standard implementations). The bytes between the core header fields and the first attribute (roughly 0x2A–0x37) accommodate the update sequence array (fixup values for sector-level integrity) along with reserved/alignment padding.

This header is succeeded by a variable sequence of attributes. Each attribute is introduced by its dedicated header, which includes a 4-byte field that denotes the total length of the attribute (including the header and data). Immediately following the conclusion of one attribute lies either the header of the subsequent attribute or the 4-byte end-of-record sentinel value 0xFFFFFFFF, which marks the termination of the attribute list within the file record.

Offset	Length	Description
0x00	DWORD	Signature (Magic Number): "FILE" (0x46494C45) or "BAAD" if corrupted
0x04	WORD	Offset to MFT Record update sequence array (also known as the fixup array)
0x06	WORD	Number of entries in the fixup array (usually 3 for 1024-byte records).
0x08	LONGLONG	$LogFile Sequence Number (LSN)
0x10	WORD	FILE Record Sequence Number
0x12	WORD	Hard link count
0x14	WORD	Offset where the first attribute starts (almost always 0x0038 / 56).
0x16	WORD	Allocation status flags (0x0000: Deleted file; 0x0001: Allocated file; 0x0002: Deleted directory; 0x0003: Allocated directory)
0x18	DWORD	Logical Size of MFT record: Actual bytes used by header + attributes + end marker
0x1C	DWORD	Physical Size of MFT record; Total allocated size of the record (usually 0x00000400 = 1024 bytes)
0x20	6 BYTES	Base Record number
0x26	WORD	Base Record Sequence Number
0x28	WORD	Next available attribute ID
0x2A	WORD	(Reserved / MFT Record Number in NTFS 3.1+): In newer NTFS versions: This record's MFT number (4 bytes total in some layouts)
0x2C	DWORD	(Reserved / MFT Record Number continuation): Padding or part of record number in NTFS 3.1+
0x30	Variable	Update Sequence Array (Fixup Array): Update Sequence Number + original end-of-sector values
0x38	WORD	Start of First Attribute: Attributes begin here (e.g., $STANDARD_INFORMATION)

In NTFS, the Master File Table (MFT) file record employs an Update Sequence Array (USA)—also known as a fixup array—to safeguard the integrity of multi-sector structures against partial writes. This mechanism replaces the final two bytes (one word) of each logical sector spanned by the record with a monotonically incrementing Update Sequence Number (USN) during disk commits. The original end-of-sector words are preserved within the USA, which resides in the file record header. The 16-bit field at offset 0x06 in the header encodes the total size of the Update Sequence in words. This value equals 1 (for the USN itself) plus the number of logical sectors occupied by the record. Consequently, the USA proper stores (size − 1) original 2-byte values.

• For the canonical 1024-byte MFT record on a volume with 512-byte sectors, the structure spans two sectors. The Update Sequence field, therefore contains 3 entries (one USN followed by two original end-of-sector words).
• In a hypothetical 4096-byte MFT record with 512-byte sectors, the record would encompass eight sectors, yielding a sequence of 9 entries (one USN plus eight original values).
• On modern storage with 4096-byte physical (and often logical) sectors, MFT records are typically sized at 4096 bytes as well. In such configurations, the record occupies a single sector, resulting in a minimal Update Sequence of only 2 entries (one USN and one original word).

Although the boot sector parameter can specify other MFT record sizes (via a signed “clusters per MFT record” value, commonly −10 for 1024 bytes), non-default sizes remain exceedingly uncommon in production environments. The file record header maintains a fixed layout irrespective of record size. Its immutable prefix generally occupies 42–48 bytes, with the precise length and placement of the USA varying slightly by NTFS version (commonly starting at offset 0x2A in earlier implementations or 0x30 in Windows XP and later). The first attribute (typically $STANDARD_INFORMATION) ordinarily commences immediately thereafter, most frequently at offset 0x38 or 0x30, depending on the exact USA positioning and parsing conventions. This consistent architecture ensures reliable traversal of attributes following header interpretation and fixup application.

Consider the hex dump of MFT entry 35 for our test bitstream image as shown in the figure below. The MFT entry header has been highlighted in red. This example uses a little-endian bit-ordering scheme.

NTFS MFT File Record Header: A Detailed Breakdown

Signature (Offsets 0x00–0x03)

Every valid MFT file record begins with the 4-byte signature FILE (hex: 0x46494C45), which identifies the entry as an active file record. If a record is unusable or corrupt, this signature is replaced with BAAD.

Update Sequence Offset (Offsets 0x04–0x05)

The two bytes at offsets 0x04–0x05 store a pointer to the Update Sequence Number and Array, measured from the beginning of the record header. The raw value 0x3000 reads as 0x0030 in big-endian, equating to decimal 48. This offset value can vary across different operating systems. Examining the bytes at offset 0x30 (decimal 48) confirms the Update Sequence Number resides there, containing the value 0x0300.

Update Sequence Size (Offsets 0x06–0x07)

This 2-byte field specifies the size of the Update Sequence Number and Array, counted in words (not bytes). The little-endian value 0x0300 reverses to 0x0003, indicating three words are used — one for the Update Sequence Number and two for the Update Sequence Array entries (one per 512-byte sector in the record). Inspection of multiple MFT records confirms that 0x03 00 is consistently present at this location.

Logfile Sequence Number / LSN (Offsets 0x08–0x0F)

These 8 bytes store the Logfile Sequence Number (LSN), which is associated with the NTFS journal ($LogFile). The LSN tracks when metadata changes are made to the file system, enabling faster recovery from corruption by replaying or rolling back logged operations.

Record Reuse Sequence Number (Offsets 0x10–0x11)

This 2-byte field, sometimes called the sequence number, is set to 1 when an MFT record is first allocated. It increments each time the record is reused — notably, the increment occurs when the record is marked as deleted and made available for reuse, not when it is reallocated. In the sample image, the little-endian value 0x0200 equates to decimal 2, indicating one prior reuse cycle.

Hard Link Count (Offsets 0x12–0x13)

This 2-byte integer records how many directory entries reference this MFT record — in other words, the number of hard links pointing to the file. Microsoft defines hard links as NTFS-based references that allow a single file to appear in multiple folders under different names without duplicating the underlying data. Each additional hard link increments this counter by one.

Offset to First Attribute (Offsets 0x14–0x15)

These two bytes contain a pointer — measured from the start of the record header — to the first attribute within the file record. The little-endian value 0x3800 reads as 0x0038, equating to decimal 56. Examining the bytes at that offset reveals the value 0x1000, which corresponds to the $STANDARD_INFORMATION attribute.

Flags (Offsets 0x16–0x17)

This 2-byte field describes the current state of the MFT record. The significant values are:

• 0x0000 - Deleted FILE record
• 0x0100 - FILE record in use
• 0x0200 - Deleted DIRECTORY record
• 0x0300 - DIRECTORY record in use

In the sample record, the value 0x0100 confirms this is an active, in-use FILE record.

Logical (Used) Size of Record (Offsets 0x18–0x1B)

This 4-byte little-endian integer stores the logical size of the file record — the actual number of bytes currently occupied by data within the record. The value 0x000001B0 translates to decimal 432, indicating 432 bytes of the record are actively used.

Physical (Allocated) Size of Record (Offsets 0x1C–0x1F)

These 4 bytes store the physical (allocated) size of the file record — the fixed storage space reserved for it on disk, as preset in the BIOS Parameter Block (BPB). The little-endian value 0x00000400 translates to decimal 1024, confirming the standard 1024-byte record allocation.

Base File Reference (Offsets 0x20–0x27)

This 8-byte field is used when a file's attributes exceed the space available in a single MFT record. In such cases, additional (extension) records are allocated elsewhere in the MFT, and each extension record stores a Base File Reference here, pointing back to the primary (parent) record. The extended records are not necessarily contiguous with the base record — they may be located anywhere within the MFT.

The 8 bytes are internally structured: the first 6 bytes appear to encode the MFT record number of the parent record, while the final 2 bytes likely represent a sequence number or identifier. The parent record, in turn, contains forward pointers to its extension records, listed in the order they should be read. When no extension records exist, this field contains 0x0000000000000000.

Next Attribute ID (Offsets 0x28–0x29)

This 2-byte field stores the ID that will be assigned to the next attribute added to this record. A value of 4 implies that attributes with IDs 0 through 3 have already been assigned. However, this field is unreliable as a count of currently present attributes: it increments when an attribute is added but does not decrement when one is removed, and may reset to zero upon record reuse.

High Part of MFT Record Number (Offsets 0x2A–0x2B)

Because MFT record numbers are 48-bit values, a standard 4-byte field is insufficient to store the full number. These 2 bytes store the upper 16 bits of the record number, while the lower 32 bits are stored at offsets 0x2C–0x2F. In practice, this high-part value is almost always zero, as reaching the 32-bit record number limit would require an astronomically large volume. Notably, the high part is stored before the low part in the header layout.

Low Part of MFT Record Number (Offsets 0x2C–0x2F)

This 4-byte (DWORD) field, present in Windows XP and later versions of NTFS, stores the lower 32 bits of the MFT record number — the primary numerical identifier of this entry within the $MFT file. This field did not exist in older implementations (e.g., Windows NT 4.0), where the file record header was smaller (42 bytes rather than the modern 48 or 56 bytes).

Update Sequence Number (Offsets 0x30–0x31)

The Update Sequence Number (USN) is a 2-byte integrity check value. NTFS writes this value into the last 2 bytes of each 512-byte sector within the MFT record before writing it to disk, replacing the original bytes at those positions. This allows NTFS to detect partial or torn writes. In the sample record, the USN value is 0x0300.

Update Sequence Array (Offsets 0x32–0x35)

These 4 bytes form the Update Sequence Array, which stores the original bytes that were displaced by the USN fix-up process. Since a standard 1024-byte MFT record spans two 512-byte sectors, four bytes are preserved here — two from the end of the first sector (0x2300) and two from the end of the second sector (0x0000). During read operations, NTFS restores these original bytes back into their correct positions after verifying the USN fix-up codes.

MFT Record Numbers and File References

Each MFT entry is assigned a 48-bit record number, assigned sequentially starting from 0. Combined with the 16-bit sequence number (at offset 0x10), NTFS constructs a 64-bit file reference: the sequence number occupies the upper 16 bits, and the record number occupies the lower 48 bits. This file reference uniquely and reliably identifies any MFT entry.

The sequence number serves as a staleness detector: if a stored file reference contains a sequence number that no longer matches the current sequence number in the referenced MFT entry, the reference is treated as invalid. This mechanism supports both file system consistency and data recovery operations.

The physical byte offset of any MFT record within the $MFT file can be calculated simply by multiplying its record number by the fixed record size (typically 1024 bytes).

An interesting feature of the first 15 MFT records after the record for the $MFT itself (record 0), is that their MFT Record number and their MFT Record Sequence number are the same, and these records are not reused as other records.

File Name	MFT Record Number	MFT Sequence Number
$MFTMirr	1	1
$LogFile	2	2
$Volume	3	3
$AttrDef	4	4
$.	5	5
$Bitmap	6	6
$Boot	7	7
$BadClus	8	8
$Secure	9	9
$UpCase	10	10
$Extend	11	11
*Reserved*	12	12
*Reserved*	13	13
*Reserved*	14	14
*Reserved*	15	15

The figure below shows the file reference number for the $AttrDef MFT record on a live system.

Each entry in the Master File Table (MFT) consists of a header and a collection of attributes that describe a file or directory. NTFS represents files as sets of attributes—some store metadata such as timestamps, names, and security information, while one (the $DATA attribute) contains the file’s actual content. As a result, every file or directory on an NTFS volume has at least one associated MFT entry, and large files may use multiple MFT records. In essence, files in NTFS are collections of attributes that hold both their descriptive information and their data.

MFT Entry Attributes Concepts

Every MFT entry begins with a small header that describes the structure and content of the entry. One of the key fields in this header is the offset (located at byte 0x14) to the first attribute. Attributes then follow sequentially, one after another, until an attribute type 0xFFFFFFFF marks the end of the list.

Each attribute consists of two main components: an attribute header, which defines the attribute’s type and metadata, and the attribute content, also referred to as the attribute’s stream. The supported Attributes on an $MFT file record can be seen by examining the $AttrDef metadata file in the same Volume, which also provides their general properties. The order in which Attributes appear in a file record is the same as the order they appear in the $AttrDef file. NTFS supports two forms of attribute storage:

• Resident attributes store their content directly inside the MFT entry.

• Non-resident attributes store their content outside the MFT entry on disk, requiring the file system to track the external cluster locations.

Therefore, the data structure for the non-resident attribute is slightly different from the resident attribute, particularly because the content of the attribute is stored outside the MFT entry,  so the addresses of these clusters allocated to store the content must be specified. The contents of non-resident attributes are stored in intervals of clusters called data runs.  Each run is represented by its starting cluster and its length in clusters. The lengths of data runs vary, and are determined by the first byte of a run, where the lower 4 bits represent the number of bytes for the length of the run and the upper 4 bits represent the number of bytes containing the starting cluster address for the run. Each run uses contiguous disk allocation.

Because each data run describes a contiguous block of clusters, the attribute’s content may span multiple runs scattered across the volume, depending on the level of fragmentation. This flexible, variable-length encoding allows NTFS to efficiently map non-resident data, even when stored in fragmented segments.

The table below shows the layout of an attribute, including resident attributes and non-resident attributes.

Byte Offset	Length	Description
0x00	DWORD	Attribute type identifier is classified according to the type of information stored in the file (16 = $STANDARD_INFORMATION for general information, 48 = $FILE_NAME for file name & MAC, 64 = $OBJECT_ID for file & directory, 128 = $DATA for file content, etc.)
0x04	DWORD	Length of Attribute
0x08	BYTE	Non-resident flag (0x00: Resident; 0x01: Non-resident)
0x09	BYTE	Length of stream name (Number of Unicode characters).  Unicode characters are 2-byte values, so the length in bytes is 2x this number.
0x0A	WORD	Offset to stream name (from the start of the Attribute)
0x0C	WORD	Attribute Flags. The ‘Attribute Flags’ bytes have 3 currently observed: 0x0001 = Attribute content is compressed; 0x8000 = Attribute content is sparse; 0x4000 = Attribute content is encrypted.
0x0E	WORD	Attribute identifier
Resident Attribute		Non-Resident Attribute
Bytes Offset	Description	Bytes Offset	Description
0x10 - 0x13	Size of file content	0x10 - 0x17	Starting virtual cluster number (VCN) of the run list
0x14 - 0x15	Offset of file content  (from the start of the Attribute)	0x18 - 0x1F	Last VCN of the run list
		0x20 - 0x21	Offset to the data runs
		0x22 - 0x23	Compression unit size
		0x24 - 0x27	Unused
		0x28 - 0x2F	Allocated size of the attribute content
		0x30 - 0x37	Actual size of the attribute content
		0x38 - 0x3F	Initialized size of the attribute content
		0x40	Attribute Total Allocated Size*

The ‘Attribute Total Allocated Size’ field is only found in attributes where the Attribute Flag 0x0001 (Attribute Content is Compressed) or 0x8000 (Attribute Content is Sparse) is set. The ‘DataRun offset’ in those Attributes is changed from the typical 0x40 (64) to 0x48 (72) to accommondate the 8 extra bytes.

The offset of the first Attribute in a FILE record is determined by the ‘Offset to 1st attribute’ in the Record Header. To get to the 2nd Attribute, one must add the ‘Attribute Length’ of the 1st Attribute to the ‘Offset to 1st attribute’, etc. For example:

• ‘Offset to 1st attribute’+ ‘1st Attribute Length’ → Start of 2nd Attribute.
• ‘Offset to 1st attribute’+ ‘1st Attribute Length’ + ‘2nd Attribute length’ → Start of 3rd Attribute. 

The minimum Attribute Header length is 24 bytes long, whether it has a Stream Name or not. According to their purposes, there are many types of attributes used by an NTFS volume. This is defined by a hidden system file named $AttrDef. $AttrDef is made up of multiple 160-byte records, one for each attribute. Each record contains the attribute’s name, numeric type identifier, flags (e.g., Non-resident or Non-resident, indexed or not), minimum size, and a maximum size. If an attribute has no size limitations, the minimum size will be set to 0, and the maximum will have all bits set to 1. The table below lists the default MFT entry attribute types, although it is unlikely that all will be used in an MFT record.

Attribute Type Identifier	Attribute Name	Description
0x10	$STANDARD_INFORMATION	General information, such as flags; file system timestamps, including the last accessed, written, and, created times; and the owner and security ID.
0x20	$ATTRIBUTE_LIST	List where other attributes for a file can be found.
0x30	$FILE_NAME	Filename, in Unicode, and file system timestamps, including the last accessed, written, and created times.
0x40	$VOLUME_VERSION	Volume information. Exists only in version 1.2 (Windows NT).
0x40	$OBJECT_ID	A 16-byte unique identifier for the file or directory. Exists only in versions 3.0+ and after (Windows 2000+).
0x50	$SECURITY_DESCRIPTOR	The access control and security properties of the file.
0x60	$VOLUME_NAME	Volume name.
0x70	$VOLUME_INFORMATION	File system version and other flags.
0x80	$DATA	File contents.
0x90	$INDEX_ROOT	Root node of an index tree.
0xA0	$INDEX_ALLOCATION	Nodes of an index tree rooted in the $INDEX_ROOT attribute.
0xB0	$BITMAP	A bitmap for the $MFT file and for indexes.
0xC0	$SYMBOLIC_LINK	Soft link information. Exists only in version 1.2 (Windows NT).
0xD0	$REPARSE_POINT	Contains data about a reparse point, which is used as a soft link in version 3.0+ (Windows 2000+).
0xE0	$EA_INFORMATION	Used for backward compatibility with OS/2 applications (HPFS).
0xF0	$EA	Used for backward compatibility with OS/2 applications (HPFS).
0x100	$LOGGED_UTILITY_STREAM	Contains keys and information about encrypted attributes in version 3.0+ (Windows 2000+).

Recall that every file on the file system will have at least one MFT entry, and the size of each MFT entry is only 1024 bytes. In case a file has too many attributes that won’t fit into a single MFT entry, an additional MFT entry would be used, linked from the base MFT through the use of the $ATTRIBUTE_LIST attribute. In other words, the $ATTRIBUTE_LIST attribute is used to indicate where other attributes can be found for the given MFT entry.

Update Sequence Number and Update Sequence Array

In digital forensics, it is standard practice to use MD5 (or similar cryptographic hash functions) to verify that two files contain identical binary content. This technique is frequently applied when investigators need to confirm that multiple copies of a file found on a storage volume are exact duplicates, particularly when file locations, timestamps, or other metadata are relevant to the case. It is also essential when processing large collections of files—such as tens of thousands of images—where automated hash comparison against a database of known files can identify items of interest without requiring manual review of every file.

For any hash-based comparison to be reliable, the recovered file must be an accurate and complete representation of its original content. NTFS employs a built-in integrity mechanism known as the Update Sequence Array (USA), also referred to as the fixup array, within structures such as Master File Table (MFT) records. This feature was not widely discussed in the forensic community until it was highlighted through detailed experimental analysis.

In a typical 1024-byte MFT record (spanning two 512-byte sectors), the final two bytes of each sector (offsets 510-511, 1022-1023) are overwritten with a two-byte Update Sequence Number (USN) during normal system operation. The original bytes that occupied those positions are saved in the Update Sequence Array (USA), located in the MFT record header (usually starting around byte offsets 42-48, depending on the NTFS version). When the operating system reads the record:

• It checks that the end-of-sector bytes match the current USN (integrity check).
• It replaces those USN bytes with the saved original values from the USA, ensuring the data appears intact to applications.

If an analyst extracts raw data directly from an MFT record (e.g., for a small resident file whose content lives inside the $DATA attribute of the MFT entry) without manually applying the fixup/USA restoration, the extracted file will contain the USN values in the last 2 bytes of each sector instead of the original data. The issue becomes significant when the resident file content crosses a sector boundary within the MFT record, a situation that occurs frequently with small files. In such cases, the extracted data will differ from the true file content, causing the computed MD5 hash to mismatch when compared against a reference database or another copy of the file. The same problem can affect any data recovered from record slack space or other structures that span sector boundaries.

This discrepancy can have serious consequences in legal proceedings. For example, if a document, such as a blackmail note, is created on one computer and later transferred to another, investigators may need to prove the files are identical. If the files are recovered in raw form from an NTFS volume, their hashes may not match either because the sector boundaries differ or because the Update Sequence Numbers vary between the two systems. A defense team could exploit such a mismatch to question the overall reliability of the forensic process. The same hashing failure can occur when comparing a raw recovery from NTFS against a logically copied version of the file from a non-NTFS file system (such as FAT), which does not use this update mechanism.

Many common forensic tools automatically apply the fixup correction when displaying file content in a parsed “File View,” but may not clearly document when/where they did so (or show the on-disk USN in hex view). In hexadecimal view, the software may misleadingly suggest that the Update Sequence Numbers reside at the physical end of the sectors, when in reality those positions hold the USN values, and the true data bytes are stored in the Update Sequence Array. Analysts must understand the low-level disk structures to verify tool behavior. This mechanism (fixups/USA) applies not only to MFT records but also to other NTFS structures like INDX records, $LogFile records, etc.

Modern forensic suites (e.g., EnCase, FTK, Autopsy/Sleuth Kit with proper NTFS parsers) generally handle fixups correctly when carving or exporting resident files. However, custom scripts, manual hex carving, or certain open-source tools can still trip over it if the parser skips the fixup step. The problem does not affect non-resident files (data stored in allocated clusters outside the MFT) or normal logical file copies made via the OS.

These subtleties reinforce the importance of forensic examiners possessing a solid understanding of low-level disk structures and storage principles. Analysts should always verify tool behavior independently rather than relying solely on automated output, especially when hash matching is critical to the investigation.

Practical Advice for Analysts

• Always use tools that properly parse NTFS MFT records and apply fixups when recovering resident content.
• When in doubt, manually verify: parse the MFT header → locate the USA offset and size → restore the original end-of-sector bytes → recompute the hash.
• For hash-based identification (e.g., NSRL, known-bad image databases), ensure the recovered file represents the logical content, not the raw on-disk MFT bytes.

While the USN/USA fix-up ensures data integrity for individual MFT records, the USN Journal provides a historical timeline of system activity, including actions on deleted files.

The Update Sequence Number (USN) is a 16-bit unsigned integer (uint16) that serves as an integrity marker in NTFS. It is stored both in the header of multi-sector NTFS structures (such as MFT records) and written into the final two bytes of every sector occupied by that structure. When NTFS writes the USN to the end of each sector, it overwrites the original data bytes that previously occupied those positions. These overwritten bytes may contain critical information, including portions of filenames, timestamps, attribute data, or any other content, depending on the sector boundary. To preserve this original data, NTFS maintains an Update Sequence Array (USA), also known as the fixup array. The USA stores copies of the bytes that were displaced by the Update Sequence Numbers. When the operating system reads the structure, it verifies the USN values for consistency and then restores the original bytes from the USA, ensuring the data is presented correctly to applications and processes. The types of data structures that we typically find USN and USA for are:

• $MFT FILE Records
• INDX Records for directories and other indexes
• $LogFiles RCRD Records
• $LogFile RSTR Records.