In NTFS, these records reside primarily in the $LogFile metadata file. Despite its recognized forensic significance as a potential "time machine" for metadata transactions, the internal architecture of the $LogFile—comprising restart areas, log pages (typically 4 KB with "RCRD" signatures), Logical Sequence Numbers (LSNs), redo/undo operations, and client data structures—lacks comprehensive official documentation from Microsoft. Consequently, the preponderance of extant knowledge derives from community-driven reverse engineering efforts, kernel-level analysis, and empirical observation. Even with these contributions, many references suffer from incomplete or insufficiently validated documentation, rendering verification challenging. A subset of fields, record types, and behavioral nuances within the $LogFile (including aspects of its circular logging and interaction with non-resident attributes) continues to elude full elucidation. This persistent opacity impedes the development of robust, fully automated parsing and interpretive capabilities, rendering comprehensive exploitation of the journal more technically demanding than is optimal for routine forensic workflows.
Configuration of Journal File: $LogFile
Upon system interruption or crash, NTFS automatically invokes its recovery procedure via the Log File Service (LFS) to restore metadata consistency. As a transactional journaling file system, NTFS employs write-ahead logging: all metadata modifications are first recorded in the $LogFile as atomic transactions before being applied to the volume cache and disk. Each log record encapsulates redo information (to reapply committed sub-operations) and undo information (to roll back incomplete ones), thereby guaranteeing that the file system returns to a structurally consistent state upon remount.
The $LogFile is architecturally divided into two primary regions:
- The restart area, located at the beginning of the file and consisting of two redundant 4 KB pages (both bearing the "RSTR" signature for reliability). This area stores critical context, including the most recent Logical Sequence Number (LSN), checkpoint references, and pointers indicating the starting location within the logging area for recovery processing.
- The logging area (the remainder of the file), which operates as a circular buffer of variable-sized LFS record pages (typically 4 KB with "RCRD" signatures). It contains the actual transaction records, including client-specific redo/undo data for metadata operations on structures such as the Master File Table (MFT), indexes, and bitmaps.
Because every client data buffer persisted in the journal is unambiguously identified by its associated Logical Sequence Number (LSN), it is fundamental to understand how the Log File Service (LFS) allocates and generates LSNs. Each Logical Sequence Number (LSN) is a 64-bit integer composed of a sequence number (stored in the higher bits) and an offset (stored in the lower bits). The offset portion represents the position in the log file as a count of 8-byte increments from the start of the logging area. This offset helps locate the corresponding LFS record — the structure that holds the client data buffer along with its associated metadata (such as redo/undo information). The sequence number, residing in the upper bits, is drawn from a counter that increments each time the circular logging area wraps around (i.e., when writing resumes at the beginning of the log after reaching the end). The precise number of bits allocated to the sequence number versus the offset is variable and defined in the restart area (SeqNumberBits field), depending on the configured size of the $LogFile.
Logical Sequence Numbers (LSNs) in the NTFS journal exhibit a critical monotonic property: they are strictly increasing. Consequently, the LSN assigned to any new log record is invariably greater than that of any prior record. Although these 64-bit values could theoretically overflow, such an event is practically unattainable given the astronomical volume of log records required to exhaust the address space. This property makes LSNs highly reliable for establishing temporal order among metadata transactions, which is invaluable in both crash recovery and digital forensic analysis.
During recovery, NTFS uses the restart area to locate the appropriate checkpoint and then performs sequential passes over the logging area: an analysis pass to identify active transactions, a redo pass to replay committed changes, and an undo pass to revert any partial transactions. This mechanism ensures atomicity and durability for file system metadata while leaving the bulk of user data writes outside the journal (metadata-only journaling).
Two principal categories of log records written by NTFS to the $LogFile are update records and checkpoint records. Update records constitute the most prevalent type; each encapsulates a sub-operation within a transaction and contains both redo and undo information. The redo portion specifies how to reapply the sub-operation if a crash occurs after the transaction has been committed but before its effects are flushed from the cache to disk. The undo portion defines how to reverse the sub-operation for any transaction that remains incomplete at the moment of failure. These actions are engineered to be idempotent, permitting safe reapplication or reversal.
The checkpoint records are periodically written to the $LogFile. They delineate the boundaries of active transactions and indicate the oldest Log Sequence Number (LSN) from which recovery processing must commence, thereby limiting the scope of analysis, redo, and undo passes. Following each checkpoint, the LSN of that record is recorded in the restart area (the first two 4 KB pages of the $LogFile, bearing the “RSTR” signature and maintained redundantly) to enable rapid resumption of recovery upon remount after a system interruption.
The logging area itself comprises a circular sequence of 4 KB LFS record pages (typically signed “RCRD”). When a log record does not fully occupy a page, the final (most recent) partial page receives special handling during flushing. On a clean shutdown, the last record is persisted even if its enclosing page is incomplete, with any remaining space typically zero-padded on the subsequent write. The authoritative pointer to the end of the log (Current LSN / Last LSN) resides in the restart area rather than within individual client records.
Restart Area
The restart region of the NTFS $LogFile consists of two redundant 4 KB pages (both bearing the "RSTR" magic signature and protected by update sequence arrays) to ensure reliability against partial writes. Each restart page begins with a RESTART_PAGE_HEADER structure, which includes critical fields such as the chkdsk_lsn (Check Disk LSN), system and log page sizes, restart_offset (typically 0x30 on XP and later), and version information.
At the offset specified by restart_offset, follow the RESTART_AREA structure. This contains the Current LSN (the Logical Sequence Number of the most recently written log record at the time the structure was flushed), the number of log clients, client list management fields (free/in-use lists), sequence number bit width, and other context for forward compatibility and sanity checking. Immediately afterward (at a client_array_offset defined within the restart area, often resulting in an effective start near 0x70 or aligned thereafter on Windows XP+) is an array of LFS_CLIENT_RECORD structures, each typically 0xA0 bytes in length. For a standard volume, this array contains a single entry for the NTFS client.
 |
| Structure of the Restart area |
 |
| RESTART_PAGE_HEADER |
 |
| RESTART_AREA |
 |
| LFS_CLIENT_RECORD |
Forensically, the restart region is of paramount importance, as it supplies the necessary context for crash recovery. Key LSN fields include:
- chkdsk_lsn (Check Disk LSN): Primarily used to flag abnormal shutdowns or chkdsk intervention; it influences recovery behavior when set.
- Current LSN: Identifies the endpoint of logged activity.
- Client Restart LSN (within the client record): Indicates the LSN from which the NTFS client should resume recovery. While often closely related to the CurrentLSN (especially after a checkpoint), it is not invariably identical and reflects client-specific restart requirements.
During recovery, NTFS uses these values (along with the most recent checkpoint record) to determine the starting point in the circular logging area for the analysis, redo, and undo passes, thereby restoring metadata consistency efficiently.
Log Record
Each 4 KB (0x1000-byte) page in the NTFS $LogFile logging area begins with an LFS_RECORD_PAGE_HEADER (signature "RCRD") followed by one or more LFS log records. A single logical log record may span multiple physical pages when its client data exceeds the remaining space in a page. The page header includes the following key fields (offsets are absolute within the 4 KB page):
- At 0x0008 (8 bytes): LastLsn/FileOffset— a union field. On regular pages, it holds the highest Last LSN of any record that starts on this page, including records that continue onto subsequent pages. On special tail pages, it stores a file offset instead.
- At 0x0018 (2 bytes): NextRecordOffset (also called free-space offset) — the byte offset within the page where the next record would begin or the end of the last complete record. If the final record on the page is incomplete, this offset points to its starting position and is not advanced until the record is fully written.
- At 0x0020 (8 bytes): LastEndLsn — the highest LSN whose record fully ends on this page (excluding any spanning record that continues to the next page).
 |
| Log record page header |
The header is protected by an Update Sequence Array (or FixUp array) and is followed immediately by the variable-length LFS records. During recovery and parsing, these fields help determine record boundaries, handle spanning records, and locate the most recent valid entries in the circular log.
An individual LFS record in the NTFS $LogFile consists of a fixed-size header followed by variable-length client data. The header contains the following key fields (among others):
- ThisLsn: The Log Sequence Number assigned to the current record.
- ClientPreviousLsn (Previous LSN): The LSN of the preceding record belonging to the same client.
- ClientUndoNextLsn (Client Undo LSN): The LSN used during crash recovery to identify the next record requiring an undo operation for incomplete transactions.
- ClientDataLength: The size of the client data portion that follows the fixed header.
- RecordType: 0x01 for standard client records (transaction/update records) or 0x02 for client restart area records.
- Flags: 0x01 indicates that the record spans multiple 4 KB log pages (MultiPage); 0x00 means it resides entirely within the current page.
- RedoOperation (Redo Op): The operation code specifying how to reapply the change.
- UndoOperation (Undo Op): The operation code specifying how to reverse the change.
- RedoOffset / RedoLength: The offset and length of the redo data payload relative to the client data.
- UndoOffset / UndoLength: The offset and length of the undo data payload.
Within the client data section, the following fields define the logged operation:
- LCNsToFollow (typically at offset 0x0E, 2 bytes): Specifies the number of Logical Cluster Number (LCN) entries that follow in the client data portion of the current log record. A value of 0x00 indicates no additional LCNs; a non-zero value (commonly 0x01) signals that LCN run information is appended for non-resident attribute operations.
- RecordOffset: For operations targeting an MFT record, this field contains the byte offset of the attribute (or data) within the MFT record to which the redo/undo payload is applied. For most other operation types, the value is 0x00.
- AttributeOffset (AttrOffset): When the operation affects an MFT record, this denotes the byte offset within the target attribute where the redo or undo data should be applied. For cluster-level operations on non-resident attributes, it indicates the offset within the affected cluster.
- MFT Cluster Index (or ClusterBlockOffset): Used exclusively for MFT record operations; it identifies the specific MFT record within its containing cluster (typically values 0–3, since four 1 KB MFT records fit in a standard 4 KB cluster).
- TargetVCN: The Virtual Cluster Number (VCN) within the target file (frequently the $MFT or a non-resident attribute stream) to which the operation applies.
- TargetLCN: The Logical Cluster Number (LCN) on the volume corresponding to the target location on disk.
 |
| General structure of log record |
The client data area that follows is highly dependent on the specific redo and undo operation codes. Each opcode corresponds to a particular metadata operation (e.g., updating an MFT attribute, modifying an index, allocating/deallocating clusters), and its data structure is unique. These LSN links, together with the redo/undo opcodes and their associated data, form the core elements for reconstructing file system activity, determining transaction boundaries, and performing forensic timeline analysis or recovery of prior metadata states.
Log Operation Types
The NTFS $LogFile employs a well-defined set of log operation codes (opcodes) that appear in the RedoOperation and UndoOperation fields of individual LFS records. The table below enumerates the primary operation types and their corresponding hexadecimal codes. Although much of the detailed knowledge regarding these codes derives from community reverse engineering rather than official documentation, it has proven sufficiently reliable for practical forensic analysis. These opcodes are instrumental in identifying patterns of log records generated during common file system operations, including:
- File creation
- File deletion
- File extension or truncation
- Modification of file information
- File renaming
- Changes to file security descriptors
Each high-level Windows file operation typically produces a characteristic sequence (pattern) of log records. These recurring patterns enable forensic examiners to reconstruct prior file system activity with a high degree of confidence, even in cases involving deletion or timestamp manipulation. Certain records within these sequences can preserve immutable temporal evidence (e.g., original MFT initialization timestamps embedded in redo data).
For analytical convenience, individual log record types are frequently identified by composite notation of the form RedoOpcode/UndoOpcode. Commonly observed composites include 0x0E/0x0F (AddIndexEntryAllocation / DeleteIndexEntryAllocation), 0x02/0x00 (InitializeFileRecordSegment / NoOp), 0x08/0x00 (UpdateNonResidentValue / NoOp), and 0x14/0x14 (UpdateFileNameAllocation / UpdateFileNameAllocation). These composites serve as concise descriptors for specific transaction subtypes.
|
Log Operation Codes |
|
|
Log Operation Type |
Op code |
|
NoOp |
0x00 |
|
CompensationlogRecord |
0x01 |
|
InitializeFileRecordSegment |
0x02 |
|
DeallocateFileRecordSegment |
0x03 |
|
WriteEndofFileRecordSegement |
0x04 |
|
CreateAttribute |
0x05 |
|
DeleteAttribute |
0x06 |
|
UpdateResidentValue |
0x07 |
|
UpdateNonResidentValue |
0x08 |
|
UpdateMappingPairs |
0x09 |
|
DeleteDirtyClusters |
0x0A |
|
SetNewAttributeSizes |
0x0B |
|
AddindexEntryRoot |
0x0C |
|
DeleteindexEntryRoot |
0x0D |
|
AddIndexEntryAllocation |
0x0E |
|
DeleteIndexEntryAllocation |
0x0F |
|
SetIndexEntryVCNAllocation |
0x12 |
|
UpdateFileNameRoot |
0x13 |
|
UpdateFileNameAllocation |
0x14 |
|
SetBitsInNonresidentBitMap |
0x15 |
|
ClearBitsInNonresidentBitMap |
0x16 |
|
PrepareTransaction |
0x19 |
|
CommitTransaction |
0x1A |
|
ForgetTransaction |
0x1B |
|
OpenNonresidentAttribute |
0x1C |
|
DirtyPageTableDump |
0x1F |
|
TransactionTableDump |
0x20 |
|
UpdateRecordDataRoot |
0x21 |
The Event Analysis of $LogFile
File/Directory Creation
When a new file or directory is created on an NTFS volume, the file system generates a series of log records in the $LogFile to ensure metadata consistency. Typical sequences observed during file/directory creation include the following composite redo/undo operation codes:
- Series 1: 15/16 → 00/03 → 0e/0f → 0e/0f → 02/00 → 0b/0b → 08/00 → 0b/0b → 1b/01
- Series 2: 07/07 → 14/14 → 1b/01
- Series 3: 0b/0b → 08/00 → 0b/0b → 07/07 → 1b/01
These patterns arise from operations such as MFT record initialization, index entry allocation in the parent directory’s $I30 index, attribute creation/updates, and bitmap modifications. Creation via Windows Explorer may produce slightly different sequences due to additional shell-related steps (e.g., temporary naming or renaming).
A distinctive 0x1b/0x01 record frequently terminates the transaction:
- 0x1b denotes Forget Transaction,
- 0x01 denotes a Compensation Log Record.
Similar multi-record patterns exist for other high-level operations such as file deletion, copying, moving, or renaming. These recurring sequences provide forensic examiners with reliable signatures for reconstructing file system activity, even when the corresponding MFT records have been reused or overwritten.
To explain the log record series, we use the example “Series 3”. The 0x0b/0x0b log record is the first log record and has a "Current LSN" of 0x0E00FD5B, with “Previous LSN” and “Undo LSN” of 0x0E00FD42, respectively, as seen in the Figure below. A log record with numbers of the “Previous LSN” and the “Undo LSN” generally has the two LSN numbers the same.
The 0x08/0x00 log record is next to the 0x0b/0x0b log record. The “LSN” of this log record is 0x0E00FD6E. The number of the “Previous LSN” and the number of the “Undo LSN” have the same LSN number of 0x0E00FD5B. This means that the previous record of this log record is the one with the LSN number of 0x0E00FD5B.
The 0x0b/0x0b log record is next to the 0x08/0x00 log record. The “LSN” of this log record is 0x0E00FD83. The number of the “Previous LSN” and the number of the “Undo LSN” have the same LSN number of 0x0E00FD6E. This means that the previous record of this log record is the one with the LSN number of 0x0E00FD6E.
The 0x07/0x07 log record is next to the 0x0b/0x0b log record. The “LSN” of this log record is 0x0E00FD96. The number of the “Previous LSN” and the number of the “Undo LSN” have the same LSN number of 0x0E00FD83. This means that the previous record of this log record is the one with the LSN number of 0x0E00FD83.
The 0x1B/0x01 log record has two LSN numbers in the “ Current LSN” attribute of 0x0E00FDA3 and the “Previous LSN” attribute of 0x0E00FD96. In the third LSN attribute of the “Undo LSN,” there is no LSN number. This log record means the end of a series of log records.
PreviousLSN establishes a backward chain among records belonging to the same client, enabling sequential ordering and traversal of operations.
When analyzing NTFS log records for file/directory creation events, the MFT Entry Number can indeed be obtained from the Redo data of 0x15 (Set Bits In Nonresident Bit Map) and 0x16 (Clear Bits In Nonresident Bit Map) operation records. The first four bytes of the Redo data in these operation records represent the MFT Entry Number of the targeted MFT record associated with the operation.
The 0x15/0x16 log record shown above has only one LS, the “Current LSN”. The “Previous LSN” and the “Undo LSN” have numbers of zero, respectively. The two zeros mean NULL links, so it has no backward log record links. This implies that the log record stands for the first log record of one of the log record series.
Windows NTFS supports both long filenames (Win32 namespace) and short 8.3 DOS filenames for backward compatibility. The $FILE_NAME attribute (type 0x30) stores the filename along with the parent directory’s file reference number. It is always a resident attribute and appears in both the MFT record and the parent directory’s index ($I30). For files with long names, NTFS typically creates two $FILE_NAME attributes within the same MFT record:
- One for the Win32 long name (namespace 1): case-insensitive, supports Unicode and most special characters (except /\:*?"<>|).
- One for the DOS 8.3 short name (namespace 2): uppercase, restricted to 8.3 format.
The namespace field (1 byte) in the $FILE_NAME attribute identifies the naming rule:
- 0 → POSIX (case-sensitive)
- 1 → Win32
- 2 → DOS (8.3)
- 3 → Win32 & DOS (used when the name already complies with 8.3 rules, requiring only one attribute).
During file or directory creation, four common log record composites in the $LogFile contain filename-related information:
- 0x0E/0x0F (Add Index Entry Allocation / Delete Index Entry Allocation): Adds the name to the parent directory’s index.
- 0x02/0x00 (Initialize File Record Segment / NoOp): Initializes the new MFT record, including the embedded $FILE_NAME attributes.
- 0x08/0x00 (Update Non-resident Value / NoOp): Primarily updates content of non-resident attributes (not directly for $UsnJrnl).
- 0x14/0x14 (related to filename or index allocation updates): Often involved in updating filename information or parent directory metadata.
The long filename is reliably extracted from the Win32 $FILE_NAME attribute (usually the second one when two exist).
The 0x0E/0x0F log record composite (AddIndexEntryAllocation / DeleteIndexEntryAllocation) is responsible for inserting or removing an index entry in a directory’s filename index ($I30). The redo payload contains a variable-length INDEX_ENTRY structure, which embeds the $FILE_NAME attribute (type 0x30) for the file or folder being added. Consequently, the size of the redo data depends directly on the length of the filename. The data structure for “Redo” is depicted in the Figure below.
- For files/folders with short names (fitting the 8.3 DOS format), this operation typically appears once in the transaction sequence.
- For long filenames (Win32 namespace), the operation appears twice in succession: once for the generated DOS 8.3 short name and once for the actual long Win32 name. The second occurrence is specifically used to allocate the index entry for the long filename in the parent directory’s $I30 index.
The undo payload is frequently minimal or absent (NoOp) during creation operations, as the primary goal is to add the index entry. This behavior is consistent across file and directory creation and provides examiners with the user-visible long filename even when the MFT record has been reused or deleted.
 |
| The byte with value 0x0C means the length of the name string, i.e., it has a 12-byte-long name. The byte with value 0x02 means namespace, which stands for DOS(8.3) namespace. The short file name “fontc~2.dat” begins at the highlighted orange. |
During file or directory creation, the InitializeFileRecordSegment operation (0x02/0x00) writes a log record whose redo data payload contains the initialized content of the target MFT record. This embedded MFT record allows forensic extraction of the following key information:
- Creation timestamp and other standard metadata from the
$STANDARD_INFORMATIONattribute. - Original file/directory name and parent directory reference (Parent File Reference Number) from the
$FILE_NAMEattribute. By recursively resolving the Parent File Reference Address against the$MFT, the complete file path can be reconstructed. This approach provides high-fidelity creation metadata that often survives deletion or MFT record reuse. - Object type (file vs. directory): Determined by the presence of the
$INDEX_ROOTattribute. The presence of an$INDEX_ROOTattribute in the MFT record correctly indicates that the object is a directory rather than a file.
The allocation and initialization of the MFT record during file creation is fundamentally identical regardless of whether the resulting $DATA attribute is resident or non-resident. Consequently, the primary forensic artifacts obtainable from the InitializeFileRecordSegment (0x02/0x00) redo data remain the same in both cases:
- Creation timestamp and standard metadata from the $STANDARD_INFORMATION attribute.
- Original filename and parent directory reference from the $FILE_NAME attribute.
- Object type determination (file or directory) based on the presence of the $INDEX_ROOT attribute.
However, non-resident files generate additional log records for cluster allocation, runlist construction (UpdateMappingPairs), and data writes (UpdateNonResidentValue), which can provide further recoverable details such as initial data run information.
It is important to note that this record reflects only the initial MFT record content, not the final state. Subsequent operations during the same transaction (such as attribute updates, index entry additions, and size modifications) can alter certain fields, particularly attribute contents and timestamps. In the case of folder creation, the process involves multiple steps, causing LSN and USN values to advance even if the core timestamps remain largely unchanged after initialization. For file creation, an additional update to the MFT Modified Time (Entry Modified / $MFT Changed time in $STANDARD_INFORMATION) typically occurs shortly after the 0x02 record due to further modifications to the MFT entry. The behavior of other timestamps (Last Write, Last Access, etc.) can vary depending on the application that created them and the specific operations performed. This distinction is critical in forensic analysis, as the 0x02 redo data provides a valuable snapshot of the file or folder at the exact moment of its creation, while later records may reflect post-initialization changes.
NTFS implements file system tunneling, whereby if a file is deleted (or renamed) and a new file with the identical name is created in the same directory within the default 15-second window, the new file inherits the original file’s Creation Time (and short name information where applicable). In such cases, the original Creation Time is not present in the initial InitializeFileRecordSegment (0x02/0x00) record. Instead, it is written via a subsequent UpdateResidentValue (0x07) operation that modifies the $STANDARD_INFORMATION attribute of the new MFT record. Forensic examiners can locate this update using the following indicators in the redo data:
- Redo Operation: UpdateResidentValue (0x07)
- Record Offset: 0x38 (offset within the MFT record)
- Attr Offset: 0x20 (offset within the target attribute)
This method allows recovery of the tunneled (original) Creation Time even when standard MFT analysis shows only the post-tunneling value.
To identify cases where file system tunneling has occurred, locate the operation record that modifies the MFT Modified Time (Entry Modified time) of the parent directory of the newly created file:
- Obtain the Parent MFT Reference Number from the $FILE_NAME attribute in the redo data of the InitializeFileRecordSegment (0x02/0x00) record associated with the created file.
- Calculate:
Target VCN = Parent MFT Reference Number ÷ 4MFT Cluster Index = Parent MFT Reference Number mod 4
- Search for a subsequent log record (typically UpdateResidentValue) that targets the same Target VCN and MFT Cluster Index values. This record corresponds to the update of the parent directory’s MFT Modified Time.
Detection Criterion: If the Creation Time of the newly created file differs from (is earlier than) the MFT Modified Time of its parent directory, file system tunneling has likely occurred.
Note: This heuristic is not 100% reliable, as modern Windows systems frequently generate and delete numerous temporary files within very short timeframes (often dozens per second), which can produce similar timestamp patterns.
The 0x14/0x14 log record corresponds to the UpdateFileNameAllocation operation. In this composite, both the redo and undo opcodes are identical (0x14). The redo and undo data payloads are typically 0x38 bytes in length. The redo payload contains four timestamps, representing the updated values, while the undo payload contains the previous four timestamps. These timestamps correspond to the $STANDARD_INFORMATION attribute of the parent directory whose index is being modified. The 8-byte field at the beginning of the payload typically holds the MFT record number of the affected parent directory. This operation is triggered whenever a file or subdirectory is created, deleted, or renamed within the parent directory, as such actions require updating the directory’s index allocation buffer.
From a forensic perspective, the 0x14/0x14 record is significant because any modification to a directory’s contents causes NTFS to update the parent directory’s timestamps — most notably the MFT Modified Time (Entry Modified time). In such cases, three of the four timestamps are generally refreshed to the current system time, while the Creation Time of the parent directory remains unchanged. This behavior makes 0x14/0x14 records particularly useful for reconstructing directory activity and establishing temporal relationships between parent and child objects in digital forensic investigations.
File/Directory Deletion
The typical sequence of log records observed when deleting a resident file in NTFS is as follows (shown as Redo/Undo composites):
- 0x0F/0x0E — Delete Index Entry Allocation / Add Index Entry Allocation: Removes the file’s index entry from the parent directory’s filename index ($I30).
- 0x03/0x02 — Deallocate File Record Segment / Initialize File Record Segment: Marks the MFT record as unallocated (free for reuse).
- 0x16/0x15 — Clear Bits In Nonresident Bitmap / Set Bits In Nonresident Bitmap: Updates the relevant non-resident bitmap to reflect the deallocation of the MFT record.
- 0x1B/0x01 — Forget Transaction / Compensation Log Record: Concludes the transaction, indicating it no longer requires active undo tracking.
This ordered sequence ensures atomicity and consistency during deletion. It is highly valuable in digital forensics because it allows reconstruction of deletion events even when the original MFT record has been reused or overwritten.
From the undo data of the 0x0F/0x0E log record (Delete Index Entry Allocation / Add Index Entry Allocation), the following forensic information can be recovered:
- The undo payload contains a complete INDEX_ENTRY structure embedding the $FILE_NAME attribute (type 0x30) of the deleted object.
- The deleted filename is extracted from the Name field of the $FILE_NAME attribute.
- The full path of the deleted object can be reconstructed by resolving the Parent File Reference Number against the $MFT.
- The object type (file or directory) is determined from the Flags field in the $FILE_NAME attribute.
This technique is especially powerful in forensic investigations because the undo data of the deletion record often remains available in the $LogFile even after the original MFT record has been overwritten or reused.
The deletion of a non-resident file in NTFS generates a longer and more complex sequence of log records than that of a resident file, primarily due to the need to release allocated data clusters and update the data runlist.
A typical observed order (shown as Redo/Undo composites) is approximately as follows:
- 0x0F/0x0E — Delete Index Entry Allocation / Add Index Entry Allocation: Removes the filename index entry from the parent directory’s $I30 index.
- 0x09/0x00 or 0x06/0x05 — UpdateMappingPairs / NoOp or DeleteAttribute / CreateAttribute: Updates or removes the runlist (mapping pairs) of the non-resident $DATA attribute.
- 0x0A/0x00 — DeleteDirtyClusters / NoOp: Marks the data clusters previously occupied by the file as free.
- 0x03/0x02 — Deallocate File Record Segment / Initialize File Record Segment: Deallocates the MFT record itself.
- 0x16/0x15 — Clear Bits In Nonresident Bitmap / Set Bits In Nonresident Bitmap: Updates the volume bitmap to reflect the freed clusters.
- 0x1B/0x01 — Forget Transaction / Compensation Log Record: Completes the transaction.
Note: The exact sequence can vary slightly depending on the Windows version, whether the file has multiple attributes, and the state of the volume. However, the presence of 0x09 (UpdateMappingPairs) and 0x0A (DeleteDirtyClusters) steps distinguishes non-resident file deletion from resident file deletion.
Writing Data to Resident Files (Windows XP and Earlier)
When the redo operation code is UpdateResidentValue (0x07) and both the Record Offset exceeds 0xF8, and the Attribute Offset exceeds 0x18 within the MFT record, the operation corresponds to an update of the content of the resident $DATA attribute. In the case of files with very short filenames (particularly single-character names), the $DATA attribute typically begins at offset 0xF8 within the MFT record, with the actual file content starting at offset 0x18 relative to the beginning of the attribute.
- If the undo data payload is entirely zero-filled, the operation represents the initial write of a new resident file.
- If the undo data contains non-zero content, the operation indicates a modification of existing resident file data, where the undo payload holds the previous data and the redo payload holds the updated data.
To correlate the write operation with the target file, the Target LCN/VCN and MFT Cluster Index values should be compared between the UpdateResidentValue record and the preceding InitializeFileRecordSegment (0x02/0x00) record. Matching values confirm that the write operation targets the file whose MFT record was initialized in the earlier record.
Writing Data to Non-Resident Files
For non-resident files, the actual file content resides in externally allocated clusters on the volume. The location of these clusters is defined by the data runlist (mapping pairs), which can be recovered from the UpdateMappingPairs (0x09/0x09) operation record. When the Attribute Offset is 0x40 in this record, the redo data typically contains the cluster run information.
The method for associating a write operation with its target file remains consistent with the resident case: matching the Target LCN/VCN and MFT Cluster Index between relevant records. In practice, the UpdateMappingPairs operation that appears after the initial file creation sequence is a strong indicator that data is being written to a non-resident file. The following sequence of log record composites is commonly observed when a non-resident file is created, and its initial data is written:
- 0x06/0x05 — DeleteAttribute / CreateAttribute
- 0x05/0x06 — CreateAttribute / DeleteAttribute
- 0x15/0x16 — Set Bits In Nonresident Bitmap / Clear Bits In Nonresident Bitmap
- 0x0B/0x0B — SetNewAttributeSizes / SetNewAttributeSizes
- 0x09/0x09 — UpdateMappingPairs / UpdateMappingPairs
- 0x0B/0x0B — SetNewAttributeSizes / SetNewAttributeSizes
- 0x1B/0x01 — Forget Transaction / Compensation Log Record
These patterns reflect the complex coordination required to allocate the MFT record, create and size the non-resident $DATA attribute, update the volume bitmap, establish the data runlist, and commit the transaction atomically.
File/Directory Rename
A file or directory rename event in NTFS is characteristically marked by a pair of consecutive operations: DeleteAttribute (0x06) immediately followed by CreateAttribute (0x05), where both records have a Record Offset of 0x98 and an Attribute Offset of 0x00. These offsets indicate that the operations target the $FILE_NAME attribute (type 0x30), which is typically located at offset 0x98 within the affected MFT record. Both operations must share the same Target LCN/VCN value. The typical sequence of log record composites observed during a rename operation is as follows:
- 0x0F/0x0E — Delete Index Entry Allocation / Add Index Entry Allocation
- 0x06/0x05 — DeleteAttribute / CreateAttribute
- 0x05/0x06 — CreateAttribute / DeleteAttribute
- 0x0E/0x0F — Add Index Entry Allocation / Delete Index Entry Allocation
- 0x1B/0x01 — Forget Transaction / Compensation Log Record
From the redo data of these operations:
- The original filename (before renaming) can be extracted from the redo payload of the DeleteAttribute (0x06) record.
- The new filename (after renaming) can be extracted from the redo payload of the CreateAttribute (0x05) record.
- Both $FILE_NAME attributes also provide the Flags field, which indicates whether the object is a file or a directory.
The rename timestamp can be reliably approximated from the MFT Modified Time (Entry Modified time) of the parent directory, as the rename modifies the parent’s index. This pattern is highly useful in digital forensics for reconstructing rename events, even when the original MFT record has been partially overwritten.
File Move
In NTFS, a move operation can be differentiated from a simple rename by examining the $FILE_NAME attributes within the associated log records:
- If the filename remains identical before and after the operation, but the Parent File Reference Number differs, the event constitutes a move (the object has been relocated to a different directory).
- If the filename changes while the Parent File Reference remains the same, the event is a rename.
Apart from this distinction in parent directory information, the underlying log record sequence and forensic artifacts are essentially identical to those observed in a rename operation. Specifically:
- The old index entry is removed from the source directory.
- The old $FILE_NAME attribute is deleted, and a new one is created (containing the updated parent reference).
- A new index entry is added to the target directory.
- The transaction is finalized with a Forget Transaction record.
This pattern allows forensic examiners to reliably differentiate between rename and move events and to reconstruct the source and destination paths using the Parent File Reference values.
Post a Comment