Every entry in the Master File Table is 1,024 bytes laid out the same way: a fixed header, a small repair structure, then a stream of typed attributes. This post is a close look at that layout — the kind of detail you need when you are reading raw $MFT bytes in a hex editor or writing your own parser.
The FILE signature
The first four bytes of every record are the ASCII string FILE (46 49 4C 45). Parsers use this as the anchor when scanning a raw volume for orphaned records: every 1,024-byte boundary that begins with FILE is an MFT record, even if the table's own header is unreadable.
A record whose contents chkdsk could not repair carries the signature BAAD (42 41 41 44) instead. NTFS keeps these records in place rather than erasing them — they preserve the slot's sequence number — but the rest of the bytes should not be trusted.
The record header
The 56 bytes after the signature describe what kind of record this is and how to read it safely:
- Offset of the update sequence array (2 bytes) and size of the array in 16-bit words (2 bytes). Together they describe the fixup data; see below.
$LogFilesequence number (8 bytes). Points back into the transaction log for crash recovery.- Sequence number (2 bytes). Incremented every time the record slot is reused.
- Hard link count (2 bytes). One per
$FILE_NAMEattribute. - Offset to the first attribute (2 bytes).
- Flags (2 bytes). Bit 0 is
IN_USE; bit 1 marks a directory. - Used size (4 bytes) and allocated size (4 bytes) of the record. Allocated is always 1,024 on standard volumes.
- Base file record reference (8 bytes). Non-zero on extension records — extra slots used when one file's attributes overflow a single record.
- Next attribute ID (2 bytes). Used to assign unique IDs to new attributes.
- Record number (4 bytes, NTFS 3.1+). Self-reference, handy for sanity-checking the parse.
The sequence number is what makes deleted-file analysis trustworthy. The record number alone is reused; the 64-bit file reference (record number plus sequence number) is not. A reference that disagrees with the current sequence at that record number is a pointer to a previous tenant — usually a deleted file.
The fixup array
NTFS detects torn writes with a small trick called the update sequence array (USA), or fixup array. Each 1,024-byte record is also divided into two 512-byte sectors. NTFS:
- Picks a 16-bit update sequence number (USN — unrelated to the
$UsnJrnlUSN despite the shared acronym). - Replaces the last two bytes of every 512-byte sector with that USN before writing.
- Stores the original last-two-bytes of each sector in the fixup array, in order, right after the USN itself.
On read, NTFS checks that the last two bytes of each sector match the USN. If they do, the sectors were written together; the original bytes are pulled from the fixup array and put back in place. If any sector's tail does not match, the write was torn and the record is suspect.
This means a parser that reads $MFT byte-for-byte without applying fixups will get garbage at offsets 510 and 1022 of every record. Every serious MFT parser performs fixup as the first step after locating a record.
The attribute stream
After the header (and the fixup array) come the file's attributes. Each attribute starts with its own short header — type code, length, resident or non-resident flag, optional name — followed by the attribute's data. Attributes are 8-byte aligned, written back-to-back, and terminated by an 0xFFFFFFFF sentinel.
A minimal record carries three:
$STANDARD_INFORMATION(0x10) — timestamps and DOS flags.$FILE_NAME(0x30) — name, parent directory reference, and a second set of timestamps.$DATA(0x80) — the file's contents, resident inline for small files or a list of cluster runs otherwise.
Records can carry many more, including $ATTRIBUTE_LIST when the file's attributes outgrow a single 1,024-byte slot. The full list is in the Master File Table reference.
Why this matters for forensics
The combination of a stable 1,024-byte layout and the FILE signature is what makes carving deleted NTFS files possible. Even if $MFT itself is gone, a scan of the raw volume for FILE headers recovers most of the records — including the names, timestamps, and (for small files) the data of deleted entries. The fixup mechanism means those carved records can be trusted as long as the USA verifies.