Typical file systems encapsulate virtually all user and system data within files, including a critical ensemble of specialized system files collectively constituting the file system’s metadata infrastructure. The term “metadata” denotes self-referential structures that encapsulate descriptive attributes about the underlying data. These metadata constructs maintain comprehensive forensic artifacts for every file and directory, including Modified, Accessed, Created, and Entry Modified (MACE) timestamps; discretionary access control lists (DACLs) and system access control lists (SACLs); ownership and security identifiers (SIDs); allocated and logical file sizes; as well as extent pointers or run lists mapping to the physical clusters on the volume.
Allocation mechanics for file data clusters vary across file systems. FAT-based systems rely on a linked-list chain within the File Allocation Table (FAT), whereas NTFS employs a more efficient data run encoding for non-resident attributes—compact tuples describing runs of contiguous clusters (length and starting logical cluster number).
The Master File Table (MFT)
In NTFS, the Master File Table (MFT) serves as the paramount metadata database and core forensic repository of the file system. Implemented as a hidden system file ($MFT), it consists of a series of fixed-size MFT records (also referred to as MFT entries or file records), each typically 1 KB in size. An MFT record exists for every file, directory, and critical system metadata file (including $LogFile, $Bitmap, $Secure, $Extend, and others) on the volume. Each record contains a set of attributes that fully describe the entity. For resident attributes—typically small files or metadata streams—the complete data payload is stored directly within the MFT record itself. For larger entities, the MFT record holds non-resident attributes with data runs providing the necessary pointers to the actual data extents elsewhere on the volume. This architecture enables rapid file system traversal and constitutes a primary source of evidentiary artifacts in digital forensic examinations.
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.
The figure above illustrates a representative MFT record for a non-resident file, in which the file’s data resides in allocated clusters on the volume rather than within the MFT record itself. In NTFS, every file, directory, and system object is represented by at least one (and typically exactly one) MFT record. Collectively, these records comprise the hidden system file $MFT, which functions as the central forensic artifact repository for the entire volume.
Consistent with forensic principles across file systems, each MFT record encapsulates critical metadata attributes, including the file or directory name (via the $FILE_NAME attribute), a full complement of MACE timestamps (Modified, Accessed, Created, and MFT Entry Modified), security descriptors with permissions and ownership information, and—when non-resident—data runs that provide precise extent mappings to the file’s clusters on disk. For resident files, the complete data payload is stored directly within the unused portion of the MFT record (typically feasible only for files of approximately 600 bytes or smaller, depending on attribute overhead).
When file data is stored non-residently, NTFS tracks cluster allocation status via the hidden metadata file $Bitmap. This file maintains a bitmap in which each bit corresponds to one cluster on the volume: a set bit indicates an allocated (in-use) cluster, while a cleared bit denotes an unallocated (free) cluster. In the illustrated example, the file’s data occupies clusters 12, 13, 14, and 17. This allocation pattern exemplifies fragmentation, as the extents are non-contiguous. Although the Windows NTFS allocator strives to maintain contiguity for performance optimization, fragmentation is a common occurrence and represents a significant consideration in forensic recovery and timeline analysis.
Beyond the $MFT and $Bitmap, NTFS relies on an ensemble of additional hidden system files to manage volume operations, metadata integrity, and recovery. The file system reserves the first 24 MFT records for these special objects, with the first 12 entries allocated to core system files. Nearly all of these system files are prefixed with a dollar sign ($) and are concealed from standard directory listings, requiring specialized forensic tools for visibility (with $Volume or similar being occasional exceptions depending on viewer configuration).
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 table delineates these critical system files, their respective reserved MFT record numbers, and their primary forensic and operational roles.
Entry | File Name | Description |
0 | $MFT | (MFT Record 0): This is the Master File Table itself. The record at index 0 describes the $MFT file and contains the data runs necessary to locate all additional clusters allocated to the remainder of the MFT. The Volume Boot Record (VBR) holds the initial pointer to this record. Unlike FAT, the VBR in NTFS is the only structure permanently bound to a fixed disk location and cannot be relocated. All subsequent file system objects are located via pointers stored within MFT records. |
1 | $MFTMirr | (MFT Record 1): This file contains a mirror (backup copy) of the initial portion of the primary $MFT. It serves as a critical redundancy mechanism in the event of physical disk damage or corruption affecting the primary MFT. Because disk allocation occurs at the cluster level (default 4 KB) while MFT records are 1 KB, the mirror typically encompasses the first four MFT records—the minimum information required to bootstrap access to the full MFT. |
2 | $LogFile | (MFT Record 2): This file implements NTFS journaling by recording transactional metadata changes. It enables crash recovery and maintains file system consistency through redo/undo logging, a feature analogous to journaling in other modern file systems. The $LogFile is a primary artifact for forensic timeline reconstruction and recovery analysis. |
3 | $Volume | (MFT Record 3): This metadata file stores the volume label (friendly name), the NTFS version in use, and volume state flags, including indicators of whether the volume was cleanly unmounted during the last shutdown. |
4 | $AttrDef | (MFT Record 4): This file defines all NTFS attribute types supported on the volume. It serves as the authoritative reference for attribute identifiers and names used throughout the file system. Forensic tools rely on this definition when parsing MFT records and attribute streams. |
5 | $. | (Root Directory, MFT Record 5): The root directory of the volume. Functionally identical to any other directory record, it is permanently assigned MFT record number 5 and bears the canonical name “.”. |
6 | $Bitmap | (MFT Record 6): A compact bitmap structure in which each bit represents the allocation status of one cluster on the volume. A value of 1 indicates the cluster is allocated (in use); a value of 0 indicates it is free. This file is fundamental for forensic cluster-level analysis and unallocated space recovery. |
7 | $Boot | (MFT Record 7): This file provides a standard file-system interface to the Volume Boot Record (VBR), allowing the boot sector to be accessed via normal I/O operations for consistency. |
8 | $BadClus | (MFT Record 8): A sparse file used to mark physically damaged or unreliable clusters. It maintains a logical size equal to the entire volume but consumes no disk space for zero-filled regions. When bad clusters are identified, non-zero data is written at the corresponding offset, causing the $Bitmap to mark those clusters as allocated and thereby preventing their reuse. In practice, modern disk controllers often remap failing sectors at the hardware level, reducing reliance on this mechanism. |
9 | $Secure | (MFT Record 9): This file maintains a centralized security descriptor database (via indexed entries) for the volume. It optimizes storage and lookup of ownership, DACLs, and SACLs, avoiding redundant duplication of security information across individual MFT records. |
10 | $UpCase | (MFT Record 10): A lookup table containing Unicode case-mapping information for filename normalization and sorting. It ensures consistent alphabetical ordering (e.g., treating “A” and “a” appropriately) across different locales and code pages. |
11 | $Extend | (MFT Record 11): A directory that serves as a container for extended system metadata files introduced after the initial NTFS design. Rather than consuming additional reserved low-numbered MFT records, these objects reside in normal MFT records (typically 24–28, as they are created early during volume formatting). Key files within $Extend include:
|
12 - 15 |
| Not currently used. |
Just as clusters at the data layer exist in allocated or unallocated states, MFT records similarly maintain distinct allocation status. An allocated MFT record is actively associated with an existing file or directory on the volume. Conversely, an unallocated MFT record exists in one of two forensic states:
- It has never been used and remains zero-filled (virgin space).
- It was previously allocated to a file or directory that has since been deleted, leaving residual metadata artifacts from its last use.
In the latter case, the unallocated MFT record often retains a wealth of recoverable information, including the file or directory name ($FILE_NAME attribute), complete MACE timestamps, ownership and security descriptors, file size, and data run extents (if non-resident). This residual metadata provides critical evidentiary value even when the file itself is no longer visible through the file system namespace. Furthermore, if the clusters previously allocated to the deleted file have not been overwritten by subsequent write operations, full file recovery remains possible through carving or reconstruction using the extent information preserved in the orphaned MFT record. This interplay between unallocated MFT records and unallocated cluster space forms a cornerstone of NTFS forensic recovery and deleted file analysis.
MFT record allocation is predominantly sequential in nature. As new files and directories are created on an NTFS volume, the file system typically assigns the next available unallocated MFT record, resulting in contiguous or near-contiguous record numbering for files created in temporal proximity.
In the figure above, the initial execution of a malicious binary (“spinlock.exe”) triggered the extraction of multiple embedded resource files into the user’s temporary directory. Because these files were written in rapid succession, NTFS allocated them sequential MFT records (e.g., records 60940–60947). A parallel pattern appears in the lower part of the figure, where the execution of a masquerading binary (“svchost.exe”) and its helper (“a.exe”) resulted in the near-simultaneous creation of associated prefetch files. This produced another cluster of consecutive MFT records.
While this sequential allocation behavior is not universal—subject to factors such as fragmentation, concurrent activity, and MFT growth patterns—it occurs with sufficient frequency to be forensically significant. When present, such clustering effectively provides an alternative creation timeline encoded in the MFT record sequence itself. Files occupying nearby MFT records were likely instantiated within a narrow temporal window, even if their embedded timestamps ($STANDARD_INFORMATION or $FILE_NAME attributes) have been deliberately altered through timestomping or other anti-forensic techniques.
In NTFS, the Master File Table (MFT) constitutes the foundational core and primary metadata repository of the file system. This highly structured database maintains a dedicated MFT record for every object on the volume—including files, directories, and system metadata files. Each MFT record is a fixed-size structure, most commonly 1,024 bytes (1 KB) in length, though in rare cases the file system may utilize larger records (typically 4,096 bytes). Every record contains a sequence of variable-length attributes that comprehensively describe the associated object. This design ensures that even system entities, such as the volume label stored in the $VOLUME system file, are assigned a permanent MFT record (reserved at entry #3).
The following table enumerates the most frequently encountered NTFS attribute types and their corresponding type identifiers for both files and directories.
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+). |
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.
To better understand the internal architecture of the Master File Table, it is useful to examine the fundamental building block of the MFT: the individual FILE record (MFT entry). The diagram depicts a standard 1,024-byte MFT record, with the beginning of the subsequent record visible at the bottom. Each MFT entry follows a rigid, well-defined structure consisting of:
- A fixed-size MFT record header at the start, containing signature (“FILE”), sequence number, link count, attribute offset, and other housekeeping metadata.
- A variable-length sequence of attributes immediately following the header. These attributes provide a comprehensive description of the referenced object—whether a user file, directory, or system metadata file. 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.
On a typical NTFS volume, the $MFT contains many thousands (often hundreds of thousands) of such records, each representing a distinct entity within the file system namespace. This modular, attribute-based design makes the MFT both highly extensible and a rich source of forensic artifacts.
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 record begins with the signature “FILE” (0x46494C45). In the event the file system detects corruption within a record, this signature is replaced with “BAAD” (0x42414144). The presence of the “FILE” signature is a reliable forensic marker when carving for MFT fragments in unallocated space.
Offset to Fix-up Array (Offsets 0x04–0x05)
The two bytes at offsets 0x04–0x05 store a pointer to the Fix-up Array, relative to the start of the MFT entry. The Fixup Array (also known as the Update Sequence Array or USA) implements a robust error-detection mechanism for MFT records that span multiple sectors. During write operations, NTFS copies the last two bytes of each sector within the record into the Fixup Array and replaces them with a special Update Sequence Number (USN). Upon subsequent reads, the operating system compares the trailing two bytes of each sector against the expected USN. If they match, the original values stored in the Fixup Array are restored in memory. A mismatch indicates corruption, at which point the system marks the record with the “BAAD” signature. This fixup process protects the structural integrity of MFT records (excluding the actual file data content) and is a key consideration in low-level forensic parsing and validation of recovered MFT fragments.
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.
Fix-up Array Size (Offsets 0x06–0x07)
This 2-byte field specifies the size of the Fix-up 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)
The $LogFile Sequence Number (LSN), located at offset 0x08-0x0F within the MFT record header, is a fundamental component of NTFS’s journaling mechanism. It records the log sequence number corresponding to the most recent transaction involving this MFT record. This value serves as an offset into the $LogFile, enabling the file system to locate the precise journal entry associated with the record. During recovery operations, the LSN is used to determine whether the volume is in a consistent state or whether specific redo or undo operations must be replayed from the transaction log to restore consistency.
In our example, the LSN value 0x13DD3 is stored in little-endian byte order, as is standard for NTFS on-disk structures. This field is of considerable forensic value when correlating MFT changes with entries in the NTFS transaction journal.
Sequence Number (Offsets 0x10–0x11)
The Sequence Number, located at offset 0x10-0x11 in the MFT record header, functions as a reuse counter for that specific MFT record.
- When an MFT record is allocated for the first time, the Sequence Number is initialized to 1.
- Each subsequent deallocation (i.e., when the associated file or directory is deleted) causes the Sequence Number to be incremented.
- The counter is not incremented when a previously used record is reallocated to a new file.
Consequently, the Sequence Number effectively tracks how many times an MFT record has been freed (deleted). A higher sequence number on an unallocated record indicates a greater history of reuse. This field is particularly valuable in digital forensics for distinguishing between newly created records and those that have been recycled from previously deleted files.
Hard Link Count (Offsets 0x12–0x13)
The Hard Link Count field, located at offset 0x12 in the MFT record header, indicates the total number of $FILE_NAME attributes associated with the MFT record. This count encompasses:
- Multiple filename entries for the same file, such as the long filename and the legacy 8.3 short filename.
- True hard links, where a single file (MFT record) is referenced by multiple distinct names, potentially located in different directories.
In all cases, these $FILE_NAME attributes point to the same underlying MFT record and therefore reference the identical data streams and metadata. This field is useful in forensic analysis for identifying files with multiple names or hard links.
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)
Hex Value Binary Meaning 0x00 0000 Record not in use (unallocated) 0x01 0001 File record in use 0x02 0010 Directory record (deleted) 0x03 0011 Directory record in use
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.
The difference between these two values represents the slack space (unused bytes) at the end of the MFT record. This slack space can contain residual data from previous use of the record, making it a potentially valuable source of forensic artifacts during deleted file recovery and low-level MFT analysis.
Base File Reference (Offsets 0x20–0x27)
The File Reference to Base Record field, located at offset 0x20-0x27, is used exclusively for extended (base) MFT records. This field is populated only when a single logical file or object requires more attributes than can fit within the standard 1,024-byte MFT record. In such cases, the file system creates extension records, and this field in the extension records contains a reference back to the primary (base) MFT record. The extended records are not necessarily contiguous with the base record — they may be located anywhere within the MFT. For the overwhelming majority of MFT records on a typical volume, this field remains zeroed out, as most objects do not require attribute overflow beyond a single record.
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)
The Next Available Attribute ID field, located at offset 0x28 in the MFT record header, contains the identifier that will be assigned to the next attribute added to this MFT record. Each attribute within a given MFT record maintains a unique ID, with numbering beginning at zero. This field tracks the next sequential identifier to be used, ensuring attribute uniqueness within the record during dynamic updates (such as when new attributes are added or existing ones are modified). A value of 4 in our example 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.
In forensic analysis, this value helps reconstruct the sequence of attribute modifications within a specific MFT record.
The layout of the MFT record header varies slightly depending on the NTFS version. In pre-Windows XP versions (NTFS v3.0 and earlier), the field immediately following the Attribute Count marked the beginning of the Fixup Array. Starting with Windows XP (NTFS version 3.1 and later), a new field was introduced at offset 0x2C: the MFT Record Number (also known as the Inode Number). This field stores the record’s own index within the Master File Table and is extremely valuable during forensic recovery when carving fragmented or unallocated MFT entries.
The addition of this field increased the size of the MFT header, which is reflected in the Offset to Fixup Array (at offset 0x04). In older NTFS versions this offset was typically 0x2A; in version 3.1+, it became 0x30. In ASCII representation, this changes the byte following the “FILE” signature from “*” (0x2A) to “0” (0x30). This version-specific difference is noteworthy for tool developers and analysts: some older file carvers that rely on the signature pattern “FILE*” may fail to identify MFT records on modern NTFS volumes that use “FILE0”.
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).
Beginning at offset 0x30 (in NTFS v3.1+), the MFT record header contains the Fixup Array (Update Sequence Array). The array starts with the Update Sequence Number (USN), followed by the Update Sequence Array (USA) entries. The total number of 2-byte entries in the array is specified by the Fixup Length field at offset 0x06. For a standard 1,024-byte MFT record (spanning two 512-byte sectors), the fixup array contains three 2-byte entries:
- One USN (the signature written to the end of each sector).
- Two USA values (the original bytes that were overwritten).
When the record is written to disk, the last two bytes of each sector are copied into the USA, and the USN is written in their place. On read operations, the system verifies that the trailing two bytes of each sector match the USN in the header. If validation succeeds, the original bytes from the USA are restored in memory. If any mismatch occurs, the record is deemed corrupt: the signature is changed to “BAAD” and an error is generated.
This protective mechanism ensures the structural integrity of MFT records during I/O operations. A similar fixup process is employed in NTFS directory index buffers, though those typically contain significantly more entries due to larger structures.
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.
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.
Post a Comment