FIELD REFERENCE 03 / FILESYSTEM RECORDS

$LogFile & $UsnJrnl:$J

NTFS transaction journals, file activity reconstruction, deleted file detection, and anti-forensics identification for PC check and screenshare investigations

Listen to this guide63 min / AI narration

SpeedDownload audio ↓

Code, tables and images may need the written guide.

Platform FocusWindows NTFS (XP — 11)

Use CaseMinecraft / FiveM Screenshares

Sections16

2Journal Artifacts

28+Reason Flag Types

4MB$LogFile Default Size

~32MB$J Default Max Size

∞Files Tracked Per Volume

§ 01

Introduction

This document provides a comprehensive forensic reference for two of the most powerful — and most overlooked — NTFS artifacts available during a PC check or screenshare: $LogFile and $UsnJrnl:$J. Together, these two system files form a near-complete journal of every file operation that has occurred on a Windows volume, often going back days or weeks even after files have been deleted and the Recycle Bin has been emptied.

In the context of Minecraft and FiveM screenshares, these artifacts are invaluable. A player can delete a cheat client, wipe their AppData folder, clear their recycle bin, and run a cleaner — and $J will still contain a precise timestamp and filename for every one of those operations. Neither artifact requires any special configuration: they are active on every Windows NTFS volume by default, and they cannot be selectively cleared without either formatting the drive or running privileged tools that leave their own traces.

These two artifacts complement each other and should always be examined together. $LogFile operates at the transaction level and is primarily useful for confirming integrity and detecting deliberate wiping. $UsnJrnl:$J operates at the file operation level and is the primary source for file activity timelines. Neither replaces the other.

Core Principle

Both journals are NTFS metadata files located in the Master File Table. They are not accessible through normal Windows Explorer navigation — they require either raw volume access or dedicated forensic tools. A suspect cannot delete them through standard means, and their absence or truncation is itself a strong indicator of deliberate tampering.

§ 02

NTFS Metadata Files — Context

NTFS (New Technology File System) is the filesystem used by all modern Windows installations. Unlike FAT32, NTFS maintains an extensive internal database called the Master File Table (MFT) — a structured record of every file and directory on the volume, including metadata, timestamps, and permissions. In addition to regular files, NTFS reserves a set of special metadata files, each identified by a dollar-sign prefix, that manage the filesystem itself. Two of these are forensically critical.

The Key NTFS Metadata Files

$MFTMaster File Table — the central index of every file and directory. Each MFT record is 1 KB and stores timestamps, file sizes, attribute headers, and data run locations. The starting point for nearly all NTFS forensics.

$LogFileNTFS transaction log — records all metadata changes as atomic transactions to ensure volume consistency after crashes. Typically 4–64 MB. Stored at MFT record 2. Wraps cyclically when full.

$UsnJrnlUpdate Sequence Number Journal — a change journal tracking every file and directory modification on the volume. Contains the $J data stream (record log) and $Max (configuration). Stored as a sparse file, typically up to 32 MB of active data.

$BitmapTracks which clusters on the volume are in use. Used in carving to identify unallocated regions where deleted data may still exist.

$BootContains the volume boot record and filesystem parameters. Useful for volume identification and timestamp of initial format.

$I30Directory index — stores directory entries. Slack space in $I30 indexes often retains records for deleted files long after deletion.

Why These Files Cannot Be Deleted Normally

NTFS metadata files are locked by the kernel at all times while the volume is mounted. Windows will refuse any userspace attempt to open, rename, delete, or modify them directly. Bypassing this requires either raw volume I/O (requiring administrator privileges and leaving traces), a live forensic tool, or booting an alternate OS. Any tool capable of clearing these files is itself a significant red flag by its presence alone.

§ 03

What Is $LogFile?

$LogFile is the NTFS transaction log — sometimes called the NTFS redo log. Its primary engineering purpose is to ensure that the filesystem can recover to a consistent state after an unexpected shutdown or crash. Before NTFS commits any metadata change (creating a file, renaming it, deleting it, modifying its attributes), it first writes a record of that change to $LogFile. If the system crashes mid-write, NTFS replays or rolls back these logged transactions on the next mount to restore consistency.

From a forensic perspective, this means $LogFile contains a detailed, low-level record of every metadata operation that has taken place since it was last wrapped. The log captures not just what happened, but the before and after state of the metadata involved — meaning you can reconstruct exactly what an MFT record looked like before a change, and what it looked like after.

Key Characteristics

Location (MFT record)MFT record number 2. Present on every NTFS volume. Cannot be disabled without reformatting.

Default sizeApproximately 4 MB on typical system volumes, but can grow up to 64 MB on larger volumes. The size is set at format time and does not change dynamically.

Wrapping behavior$LogFile wraps cyclically — when full, the oldest records are overwritten by new ones. On an active system, older entries may be overwritten within minutes to hours.

Log Sequence Number (LSN)Every record carries a monotonically increasing 64-bit LSN. The current LSN is stamped in every MFT record, allowing cross-referencing between $LogFile and the MFT.

Transaction scopeRecords both redo (what to reapply on recovery) and undo (what to roll back) operations. Covers MFT record changes, index operations, attribute modifications, and allocation bitmap changes.

No userspace accessRequires raw volume access. Tools: MFTECmd (Eric Zimmermann), NTFSLogTracker, LogFileParser. Cannot be opened in Explorer or standard file tools.

Investigator Note

$LogFile's wrapping behavior makes it more time-sensitive than $J. On a heavily used system, the useful forensic window in $LogFile may be only an hour or two. Always extract $LogFile early in an investigation. On a system where the suspect has done little since committing the suspected action, $LogFile may still contain the exact transaction.

§ 04

$LogFile — Structure & Record Types

$LogFile is organized as a circular buffer divided into 4 KB pages. Each page begins with a standard NTFS update sequence record header (signature RSTR for restart pages, RCRD for log record pages). The restart pages appear at the very beginning of the file and store checkpoint information used during volume recovery.

File Layout

Region	Signature	Description	Forensic Use
Pages 0–1	`RSTR`	Restart areas — store the most recent checkpoint LSN, the current client (NTFS), and the log file's current state flags	Confirms the log is valid; provides the last checkpoint LSN as a reference point; log state flags reveal if the volume was cleanly unmounted
Pages 2+	`RCRD`	Log record pages — circular buffer of individual log records, each describing a single metadata operation	Primary forensic content — contains redo/undo data for every recent metadata change

Log Record Types (Operation Codes)

Operation Code	Name	What It Records	Forensic Signal
`0x00`	Noop	No operation — padding or transaction boundary marker	Low
`0x01`	CompensationLogRecord	Undo record written during rollback	Indicates a partial or aborted operation — may indicate crash or tool failure during anti-forensics
`0x02`	InitializeFileRecordSegment	A new MFT record was initialized (file or directory created)	HIGH — direct proof of file/directory creation
`0x03`	DeallocateFileRecordSegment	An MFT record was deallocated (file deleted)	VERY HIGH — direct proof of deletion
`0x04`	WriteEndOfFileRecordSegment	Tail of a multi-segment MFT record was written	Medium — context-dependent
`0x05`	CreateAttribute	A new attribute was added to an MFT record (e.g., adding a $DATA stream or $FILE_NAME)	HIGH — can reveal Alternate Data Stream creation
`0x06`	DeleteAttribute	An attribute was removed from an MFT record	HIGH — can indicate attribute wiping
`0x07`	UpdateResidentValue	The value of a resident attribute was modified (e.g., timestamps changed in $STANDARD_INFORMATION)	VERY HIGH — timestomping leaves this record; before/after timestamps recoverable
`0x08`	UpdateNonResidentValue	Non-resident attribute data was modified	Medium — useful for tracking file content changes
`0x0B`	UpdateFileNameRoot / IndexEntryAllocationInsert	A directory index entry was inserted (file appeared in a directory listing)	HIGH — proves a file was placed in a specific directory
`0x0C`	IndexEntryAllocationDelete	A directory index entry was removed (file removed from directory listing)	VERY HIGH — proves a file was removed from a specific directory; file name preserved in the log record

Timestomping Detection via $LogFile

One of the most powerful uses of $LogFile in screenshare forensics is detecting timestamp manipulation (timestomping). When a tool modifies a file's $STANDARD_INFORMATION timestamps to hide recent activity, the modification itself is an MFT attribute update — which generates an UpdateResidentValue log record in $LogFile. This record contains both the original timestamps (undo data) and the modified timestamps (redo data), allowing the analyst to prove exactly what the timestamps were before tampering.

Timestomping Indicators in $LogFile

$STANDARD_INFORMATION timestamps pre-date $FILE_NAME timestamps — $FILE_NAME timestamps are harder to forge and often retain accurate values
UpdateResidentValue records showing SI timestamp changes — the undo data contains original timestamps; a gap between before/after values of years is a near-certain indicator
$STANDARD_INFORMATION nanosecond components all zeroed — real Windows timestamps always have non-zero sub-second precision; perfectly rounded timestamps indicate tool-written values
$FILE_NAME timestamps newer than $STANDARD_INFORMATION — under normal operation, $SI timestamps are updated more frequently than $FN; if $FN is newer, the $SI timestamps were set back artificially

§ 05

$LogFile — Forensic Value

$LogFile's primary forensic strength is operating at the transaction level rather than the file level. It records not just that something changed, but the exact before-and-after state of the NTFS metadata. This gives investigators capabilities unavailable from any other artifact on the system.

What $LogFile Can Prove

File Creation & Deletion

InitializeFileRecordSegment and DeallocateFileRecordSegment operations are direct, low-level evidence of file creation and deletion. The log records include the MFT record content at the time of the operation — including the file name stored in the $FILE_NAME attribute.

creation proofdeletion prooffilename preserved

Timestamp Manipulation

UpdateResidentValue records targeting $STANDARD_INFORMATION attributes preserve the original timestamps in undo data. This makes $LogFile one of the only artifacts capable of recovering pre-tampering timestamp values and directly proving they were changed.

timestompingbefore/after recovery

MFT Record History

By replaying log records against an MFT record from oldest to newest, analysts can reconstruct the full history of changes to that record over the log's retention window — seeing every attribute that was created, modified, or deleted and when.

attribute historystate reconstruction

Alternate Data Stream Detection

CreateAttribute records for $DATA attributes that include a non-empty attribute name indicate the creation of an Alternate Data Stream — a classic persistence and hiding technique. The stream name is preserved in the log record even after the stream is deleted.

ADS detectionhidden data

Limitations

Wraps quickly on active systems — at 4 MB, $LogFile may only retain the last 1–4 hours of activity on a system under normal use. Extraction should happen as early as possible.
No absolute timestamps in log records — $LogFile records do not contain wall-clock timestamps. Time is inferred from LSN ordering and correlated with $J or MFT timestamps.
Complex parsing required — the format is not documented by Microsoft and requires specialized tools. Raw analysis requires significant NTFS internals knowledge.
Does not track file content — $LogFile tracks metadata changes only. File data (the actual bytes in a document or binary) is not journaled here.

§ 06

What Is $UsnJrnl:$J?

The Update Sequence Number Journal ($UsnJrnl) is an NTFS change journal that maintains a high-level, human-readable log of every file and directory operation on the volume. Unlike $LogFile which operates at the raw transaction level, $J records discrete, labeled events such as "this file was created," "this file was renamed to X," "this file was deleted." Each record carries an absolute 64-bit timestamp, the file name at the time of the event, and a set of reason flags describing exactly what happened.

$UsnJrnl is stored as an NTFS metadata file (\$Extend\$UsnJrnl) with two named data streams: $J (the journal records themselves, stored as a sparse file) and $Max (configuration — maximum size and allocation delta). The $J stream is the forensically relevant component.

Because $J is a sparse file that grows forward and has older data zeroed out as new data is appended (rather than overwriting in-place like $LogFile), it retains a much longer history — often several days to weeks, even on active systems. This makes it the primary artifact for file activity timelines in screenshare investigations.

Key Characteristics

LocationC:\$Extend\$UsnJrnl:$J (not browsable via Explorer). MFT record in the $Extend directory. Requires raw volume access or forensic tools.

Maximum journal sizeControlled by the $Max stream. Default is typically 32 MB of active records on Windows 10/11. Configurable via fsutil usn createjournal.

Allocation deltaWhen the journal approaches maximum size, NTFS deallocates the oldest 8 MB (by default) of records by zeroing the sparse file's leading blocks. The USN values of purged records are still present in each MFT record's $STANDARD_INFORMATION — this gap can be detected.

TimestampsEvery $J record contains an absolute FILETIME timestamp (100-nanosecond intervals since January 1, 1601 UTC). This is a direct, high-precision wall-clock time for the recorded event.

CoverageTracks every file and directory on the entire volume — not just a specific folder. A cheat client installed anywhere on the C: drive, even in a temp subdirectory, will generate $J records.

Enabled by defaultActive on all modern Windows installations. Disabling it requires administrator privileges and fsutil usn deletejournal, which itself leaves evidence in $LogFile.

§ 07

$J — USN Record Structure

Each record in the $J stream is a variable-length structure. Records are always aligned to 8-byte boundaries. There are multiple versions of the USN_RECORD structure; version 2 is the most common (Windows XP — 11), with version 3 introduced in Windows 8 adding integrity checking.

USN_RECORD_V2 Field Layout

Offset	Size	Field	Description & Forensic Value
0x00	4	RecordLength	Total length of this record in bytes (variable; includes filename at end). Needed to advance to the next record.
0x04	2	MajorVersion	Record format version. Should be 2 for standard records (3 for integrity-checked variants).
0x06	2	MinorVersion	Always 0 in practice.
0x08	8	FileReferenceNumber	The MFT record number + sequence number for the file. Can be used to link a $J record to the file's current or historical MFT entry.
0x10	8	ParentFileReferenceNumber	MFT reference to the parent directory at the time of the event. Reveals which folder the file was in — even if both have since been deleted.
0x18	8	Usn	The Update Sequence Number — a monotonically increasing 64-bit value that uniquely identifies this record's position in the journal. Used for correlation and ordering.
0x20	8	TimeStamp	Wall-clock time of the event in FILETIME format. This is the primary timestamp used in timeline analysis. 100ns precision.
0x28	4	Reason	Bitmask of reason flags — describes what type of operation occurred. Multiple flags may be set simultaneously. See §08 for full reference.
0x2C	4	SourceInfo	Source information flags. `0x01` (USN_SOURCE_DATA_MANAGEMENT) indicates the change was made by a backup or replication tool, not a user action. `0x04` (USN_SOURCE_REPLICATION_MANAGEMENT) indicates VSS/DFS replication.
0x30	4	SecurityId	The security descriptor ID applied to the file. Can be used to link events to a specific security context.
0x34	4	FileAttributes	File attribute flags at the time of the event (Hidden, System, Archive, Temporary, etc.). Useful for identifying files deliberately marked hidden or system.
0x38	2	FileNameLength	Length of the filename in bytes (Unicode, so divide by 2 for character count).
0x3A	2	FileNameOffset	Offset from start of record to the filename data. Always 0x3C for V2 records.
0x3C	var	FileName	The file name at the time of the event in UTF-16LE. This is the name as it existed when the event occurred — renames preserve both the old and new name in separate records. No full path — only the filename component.

Analyst Note — Path Reconstruction

$J records store only the filename, not the full path. To reconstruct the full path of a file at the time of an event, you must follow the ParentFileReferenceNumber chain upward through the MFT (or through earlier $J records showing the parent's own creation) until you reach the root. MFTECmd's timeline output does this automatically for currently present files; for deleted parent directories, manual chain following is required.

§ 08

$J — Reason Flags Reference

The Reason field in each $J record is a bitmask — multiple flags are often set within a single record, and multiple records may be generated per logical user operation. For example, saving a file in Notepad may generate records with reasons DATA_OVERWRITE, DATA_EXTEND, DATA_TRUNCATION, and finally CLOSE as the file handle is released.

Hex Value	Constant Name	Meaning	Common Context
`0x00000001`	DATA_OVERWRITE	Existing file data was overwritten	File modified in-place; combined with CLOSE at end of write
`0x00000002`	DATA_EXTEND	File data was extended (file grew)	Data appended to file; download in progress; installer writing output
`0x00000004`	DATA_TRUNCATION	File data was truncated (file shrank)	File was zeroed or shortened; may indicate log or cache clearing
`0x00000010`	NAMED_DATA_OVERWRITE	Named data stream (ADS) was overwritten	Alternate Data Stream modified — potential hiding technique
`0x00000020`	NAMED_DATA_EXTEND	Named data stream extended	Data written into an ADS — possible payload concealment
`0x00000040`	NAMED_DATA_TRUNCATION	Named data stream truncated	ADS content removed
`0x00000100`	FILE_CREATE	A new file or directory was created	Primary creation event — present for every new file; absence of this record for an "old" file is itself suspicious
`0x00000200`	FILE_DELETE	A file or directory was deleted	Primary deletion event — proves a file was deleted even if it is now gone; timestamp is the moment of deletion
`0x00000400`	EA_CHANGE	Extended attributes were changed	Rare in normal use; may indicate specialized tools or WSL operations
`0x00000800`	SECURITY_CHANGE	Security descriptor (ACL/permissions) was changed	Permissions modified; may follow tool installation that adjusts access rights
`0x00001000`	RENAME_OLD_NAME	The file had this name before a rename	Proves a file was renamed — paired with RENAME_NEW_NAME to show before/after names; critical for detecting renaming of cheat clients or cleaners
`0x00002000`	RENAME_NEW_NAME	The file has this name after a rename	Paired with RENAME_OLD_NAME to form a complete rename event
`0x00004000`	INDEXABLE_CHANGE	File became indexable or non-indexable (Windows Search)	Usually benign; may indicate file attribute changes
`0x00008000`	BASIC_INFO_CHANGE	File timestamps or attributes changed	Direct indicator of timestomping — any timestamp modification generates this flag
`0x00010000`	HARD_LINK_CHANGE	A hard link was created or deleted	Potential technique for obscuring file references
`0x00020000`	COMPRESSION_CHANGE	File compression state changed	Uncommon; may indicate NTFS compression being toggled
`0x00040000`	ENCRYPTION_CHANGE	File encryption state changed (EFS)	May indicate EFS being used to hide file contents
`0x00080000`	OBJECT_ID_CHANGE	The file's object ID changed	Object ID assignment or deletion; uncommon in normal operation
`0x00100000`	REPARSE_POINT_CHANGE	A reparse point (symlink/junction) was created or deleted	May indicate junction or symlink creation for evasion
`0x00200000`	STREAM_CHANGE	A named data stream was created or deleted	ADS creation or deletion — high-signal flag for potential data hiding
`0x80000000`	CLOSE	The file handle was closed	Always marks the end of a logical operation; the timestamp on a CLOSE record is often the most meaningful for a completed write or delete

Reading Reason Flag Combinations

A typical file download appears as: FILE_CREATE → DATA_EXTEND (repeated) → CLOSE. A deletion appears as: FILE_DELETE + CLOSE. A rename appears as two records: one with RENAME_OLD_NAME bearing the old name, immediately followed by one with RENAME_NEW_NAME bearing the new name. A timestomping event appears as: BASIC_INFO_CHANGE + CLOSE without any preceding data modification. This last pattern — a BASIC_INFO_CHANGE in isolation with no surrounding data writes — is a strong indicator of deliberate timestamp manipulation.

§ 09

$J — Forensic Value

$UsnJrnl:$J is the single most useful file activity artifact available during a screenshare. Its combination of absolute timestamps, preserved filenames (even for deleted files), rename tracking, and long retention window makes it the primary tool for reconstructing what a player did — and when — with any file on the system.

Core Investigative Capabilities

Deleted File Proof

FILE_DELETE records persist in $J for days or weeks after a file is gone. Even if the Recycle Bin was bypassed (Shift+Delete), even if a dedicated cleaner was run, the $J record for the deletion remains — with the exact filename and timestamp.

FILE_DELETEfilename preservedpost-wipe

Rename Chain Reconstruction

Renaming a file to disguise it (e.g., renaming a cheat client JAR to something innocuous) generates RENAME_OLD_NAME and RENAME_NEW_NAME records showing both names and the exact time of the rename. These cannot be hidden without clearing the journal entirely.

RENAME_OLD_NAMERENAME_NEW_NAME

Timestomping Detection

BASIC_INFO_CHANGE records with a CLOSE and no surrounding data modification are a direct indicator of timestamp manipulation. The $J timestamp of the manipulation event is itself accurate — providing the real time the stomping occurred, even if the file's own timestamps have been altered.

BASIC_INFO_CHANGEtimestamp fraud

Installation Artifact Recovery

Installing a cheat client generates a cascade of $J records: FILE_CREATE for the installer, DATA_EXTEND during extraction, FILE_CREATE for each extracted file, SECURITY_CHANGE as permissions are set. Even after uninstall and deletion, this entire sequence is preserved in $J.

FILE_CREATEinstall detection

Long-Term Retention Advantage

Unlike $LogFile which may wrap in hours, $J's sparse-file design means it retains weeks of history under typical conditions. On a system with a 32 MB journal maximum and normal desktop activity generating roughly 1–3 MB of journal entries per day, you may have 10–30 days of file operation history available. This window can easily capture a cheat client that was installed, used, and deleted days before the screenshare.

Practical Guidance

Always check the USN value of the first (oldest) record in the $J stream against the USN stored in recent MFT records. If MFT records reference USN values that fall before the start of the journal, those records predate the current journal window — the journal was either reset or has wrapped past that point. This gap analysis tells you how far back your visibility actually extends.

§ 10

Timeline Reconstruction

The most powerful investigative technique combining $LogFile and $J is super-timeline construction: merging records from both artifacts (plus MFT timestamps and Prefetch) into a single chronological view of filesystem activity. This produces a timeline where every file creation, modification, rename, and deletion appears in order, with accurate timestamps, allowing investigators to reconstruct exactly what happened on the machine minute by minute.

Super-Timeline Source Combination

Artifact	Contributes	Retention	Timestamp Source
$UsnJrnl:$J	File create/delete/rename/modify events with filenames; timestomping indicators	Days to weeks	Embedded FILETIME (accurate, not forgeable without clearing $J)
$LogFile	MFT-level transaction detail; before/after timestamp recovery; ADS creation; deletion verification	Hours (wraps fast)	Inferred from LSN ordering; no embedded wall-clock time
$MFT	Current state of all files including deleted entries in slack; $STANDARD_INFORMATION and $FILE_NAME timestamps	Until record reused	Four SI timestamps + two FN timestamps per file
Prefetch (.pf)	Program execution events; last run times; run counts; accessed file lists	Up to 128 entries, months	Embedded FILETIME in .pf file; last 8 run times (Win8+)
$I30 slack	Ghost directory entries for deleted files; filename fragments	Until index block reused	Timestamps preserved in slack from deleted entries

Example: Cheat Client Installation + Deletion Timeline

$J Timeline OutputMFTECmd / Timeline Explorer
# Reconstructed sequence — times are illustrative
# Source: $J records, filtered for known cheat-related paths

2025-03-14 18:43:02  FILE_CREATE    liquidbounce-1.2.3.zip          \Users\user\Downloads
2025-03-14 18:43:03  DATA_EXTEND    liquidbounce-1.2.3.zip          \Users\user\Downloads
2025-03-14 18:43:09  CLOSE          liquidbounce-1.2.3.zip          \Users\user\Downloads
2025-03-14 18:44:17  FILE_CREATE    LiquidBounce                    \Users\user\AppData\Roaming\.minecraft\mods
2025-03-14 18:44:18  FILE_CREATE    liquidbounce-nightly-1234.jar   \Users\user\AppData\Roaming\.minecraft\mods
2025-03-14 18:44:18  DATA_EXTEND    liquidbounce-nightly-1234.jar   \Users\user\AppData\Roaming\.minecraft\mods
2025-03-14 18:44:18  CLOSE          liquidbounce-nightly-1234.jar   \Users\user\AppData\Roaming\.minecraft\mods

# 20 minutes of Minecraft usage ...

2025-03-14 19:06:44  FILE_DELETE    liquidbounce-nightly-1234.jar   \Users\user\AppData\Roaming\.minecraft\mods
2025-03-14 19:06:44  FILE_DELETE    LiquidBounce                    \Users\user\AppData\Roaming\.minecraft\mods
2025-03-14 19:06:49  FILE_DELETE    liquidbounce-1.2.3.zip          \Users\user\Downloads
2025-03-14 19:07:12  FILE_CREATE    CCleaner64.exe                  \Users\user\AppData\Local\Temp
2025-03-14 19:07:45  FILE_DELETE    CCleaner64.exe                  \Users\user\AppData\Local\Temp
          
This sequence would be fully present in $J even if every file is gone, the Recycle Bin is empty, and CCleaner has been run. The $J records are not affected by CCleaner. Highlighted rows represent the highest-value evidence for a ban decision.

§ 11

Deleted File Evidence

One of the most common defenses during a screenshare is that a suspicious file "was never there" or "must have been from something else." $J eliminates this defense when the deletion record is still present. The filename, parent directory reference, and exact deletion timestamp are all preserved in the journal record regardless of how the file was removed.

Deletion Pathways and $J Coverage

Deletion Method	Recycle Bin	$J Records?	What $J Shows
Delete key (to Recycle Bin)	Yes	YES	RENAME to $Recycle.Bin path, then FILE_DELETE if emptied. Both operations logged.
Shift+Delete (bypass Recycle Bin)	No	YES	Direct FILE_DELETE record with the original path and filename.
Deleted by uninstaller	No	YES	FILE_DELETE for each removed file. Installer artifacts (temp files) also present.
Deleted by cleaner (CCleaner, etc.)	No	YES	FILE_DELETE records remain. The cleaner itself also generates $J records on creation/deletion.
`fsutil usn deletejournal`	—	DETECTABLE	$J cleared — but $LogFile records the deletejournal operation itself. A new $J is created immediately on next mount. Gap in USN sequence is visible.
Volume format / reinstall	—	No (new $J)	The format event is itself suspicious context. No $J data survives a full format.

MFT Slack — Additional Deleted File Recovery

When an MFT record is deallocated (file deleted), the 1 KB MFT record is not immediately zeroed — it is simply marked as available for reuse. Until that record is reused for a new file, the old data persists in the MFT as residual / slack data. This can include the full original $FILE_NAME attribute (including the filename and parent reference) and $STANDARD_INFORMATION timestamps for the deleted file. MFTECmd with the --de flag (deduplicate entries) and tools like Autopsy can carve these residual MFT records.

§ 12

Anti-Forensics & Tampering Detection

A knowledgeable suspect may attempt to interfere with $LogFile and $J. Understanding the techniques — and the traces each leaves — is essential. Critically, almost every anti-forensic action against these journals is itself detectable, either in the remaining journal content, in $LogFile, or through structural analysis of the artifacts themselves.

Known Techniques & Their Indicators

Anti-Forensics Technique: $J Deletion via fsutil

Method: fsutil usn deletejournal /D C: clears the $UsnJrnl entirely. Requires administrator privileges.
Trace 1: $LogFile contains an MFT record update for the $Extend\$UsnJrnl file showing its deletion and subsequent re-creation.
Trace 2: The USN values stored in recent MFT records' $STANDARD_INFORMATION will be higher than the first USN in the new $J — indicating records are missing.
Trace 3: The $J creation timestamp (visible in the MFT record for $UsnJrnl) will be recent — inconsistent with a system that has been in use for months.
Trace 4: Prefetch entries for FSUTIL.EXE will show recent execution. Combined with the above, this is very strong evidence of deliberate journal clearing.

Anti-Forensics Technique: Journal Size Reduction

Method: fsutil usn createjournal m=512 a=512 C: — shrinks the maximum journal size to 512 bytes, causing it to wrap almost immediately and destroy historical data.
Trace 1: The $Max stream of $UsnJrnl will show the new reduced MaximumSize value. Default is 0x2000000 (32 MB); anything drastically smaller is highly suspicious.
Trace 2: $LogFile records the $Max attribute modification.
Trace 3: Prefetch for FSUTIL.EXE will show recent execution.

Anti-Forensics Technique: Timestomping

Method: Tools such as BulkFileChanger, Attribute Changer, NirSoft's tools, or PowerShell's [System.IO.File]::SetCreationTime() modify $STANDARD_INFORMATION timestamps to make a file appear older or to match a "clean" date.
Trace 1: $J record with reason BASIC_INFO_CHANGE + CLOSE and no accompanying data writes shows a timestamp-only modification.
Trace 2: $LogFile UpdateResidentValue record contains original timestamps in its undo data.
Trace 3: $FILE_NAME timestamps (harder to modify) remain inconsistent with the forged $STANDARD_INFORMATION timestamps.
Trace 4: Nanosecond component of modified timestamps is exactly zero — real Windows timestamps always carry non-zero sub-second precision.
Trace 5: Prefetch for the timestomping tool itself may be present (e.g., BulkFileChanger.exe).

Anti-Forensics Technique: Secure Deletion Tools

Method: Tools like Eraser, SDelete, or custom wipers overwrite file data before deletion to prevent content recovery.
Trace 1: $J will still contain FILE_DELETE and preceding DATA_OVERWRITE/DATA_EXTEND records for the targeted files. The filenames are preserved.
Trace 2: The overwrite pattern (e.g., SDelete renames files to a sequence of Z characters before deletion) produces highly distinctive RENAME_OLD_NAME + RENAME_NEW_NAME records in $J.
Trace 3: Prefetch for the secure deletion tool (sdelete.exe, eraser.exe) will be present and can confirm its use.
Trace 4: Multiple rapid DATA_OVERWRITE records for the same file before FILE_DELETE is consistent with a multi-pass wipe cycle.

Analyst Note

No common anti-forensic technique against $LogFile or $J is truly clean. Every method leaves at least one verifiable trace. When a suspect has clearly attempted to clear journal evidence, the attempt itself — demonstrable through the traces above — is significant context for interpretation.

§ 13

Gaming & Screenshare Red Flags

In the context of Minecraft and FiveM PC checks, these journals reveal patterns that are specifically meaningful in a gaming anti-cheat context. The following indicators are derived from common cheat client behaviors, cleaner usage, and anti-forensic techniques encountered in active screenshares.

High-Signal $J Indicators for Gaming Screenshares

Indicator	Confidence	Notes
FILE_CREATE / FILE_DELETE for known cheat client names in `.minecraft\mods`, `AppData`, or `Downloads`	VERY HIGH	Known clients: LiquidBounce, Wurst, Meteor, Aristois, Impact, Inertia, etc. Even partial name matches are significant.
FILE_CREATE for `.zip` or `.jar` files followed closely by FILE_DELETE — both in `Downloads`	HIGH	Classic download-install-delete-clean pattern. Gap of minutes to hours between creation and deletion is most suspicious.
RENAME events where the old name is a recognizable cheat client name	VERY HIGH	Players sometimes rename cheat JARs to something like `optifine.jar` before screenshare. $J will contain both names.
FILE_CREATE + FILE_DELETE for cleaner executables (CCleaner, BleachBit, PrivaZer, Eraser)	HIGH	Cleaners run immediately before a screenshare are a well-established evasion pattern. The cleaner's own traces in $J are ironic but inevitable.
BASIC_INFO_CHANGE on `.jar` files in the mods folder with zero-nanosecond timestamps	HIGH	Timestomping on mods — attempting to make a recently added mod appear old.
FILE_CREATE / FILE_DELETE for injection-related executable names (DLL files, injectors)	VERY HIGH	FiveM context. Relevant names: any DLL in unusual paths, executables in Temp/AppData with random-looking names adjacent to FiveM process times.
FILE_DELETE events for `\AppData\Roaming\.minecraft\logs\latest.log` or similar	HIGH	Minecraft logs are cleared by some clients on exit or by players manually. Log deletion before a screenshare is suspicious.
STREAM_CHANGE or NAMED_DATA_EXTEND on otherwise innocuous files	MEDIUM	Alternate Data Stream usage — data hidden in a named stream attached to a normal file (e.g., `image.png:payload`).
Prefetch for `FSUTIL.EXE` combined with recent $J creation timestamp	VERY HIGH	Definitive evidence of `fsutil usn deletejournal` being run to clear the journal.
All $J records have timestamps within the last few hours on a system used for months	VERY HIGH	Indicates journal was recently reset. The absence of historical data is itself the evidence.

FiveM-Specific Paths to Monitor

FiveM application data — %localappdata%\FiveM\FiveM.app\ — any unexpected DLL creation or executable addition here
FiveM cache directory — %localappdata%\FiveM\FiveM.app\data\game-storage\ — injection tools sometimes stage files here
System32 / SysWOW64 — look for FILE_CREATE events for DLL files with non-standard names proximal to FiveM launch times
Temp directories — %temp% and C:\Windows\Temp — many injectors and loaders stage in Temp and delete themselves after injection
Startup / persistence paths — %appdata%\Microsoft\Windows\Start Menu\Programs\Startup — FILE_CREATE here indicates attempted persistence

§ 14

Tools Reference

Tool	Author / Source	Function	Best For
MFTECmd	Eric Zimmermann (EZ Tools)	Parses $MFT, $LogFile, $UsnJrnl:$J, $Boot, $SDS. Exports to CSV/JSON. Free.	Primary tool for all NTFS journal parsing. Outputs timeline-ready CSVs. The standard tool for screenshare $J analysis.
Timeline Explorer	Eric Zimmermann (EZ Tools)	GUI for viewing and filtering large CSV timelines from MFTECmd output	Filtering $J output by filename pattern, timestamp range, or reason code after MFTECmd export
NTFSLogTracker	Joakim Schicht	Parses $LogFile with operation code breakdown and transaction reconstruction	Deep $LogFile analysis including timestomping before/after recovery
LogFileParser	Joakim Schicht	Alternative $LogFile parser; CSV output with LSN, operation code, redo/undo data	Supplementary $LogFile tool when NTFSLogTracker output needs verification
KAPE	Eric Zimmermann / Kroll	Forensic acquisition framework — triage tool for collecting NTFS artifacts from a live system	Collecting $MFT, $LogFile, $J, Prefetch, and event logs simultaneously during a screenshare or triage
Autopsy	Basis Technology (open source)	Full forensic suite with NTFS support, timeline analysis, keyword search, and deleted file recovery	Full case analysis, deleted file recovery, $I30 carving, correlation across multiple artifact types
Velociraptor	Velocidex (open source)	Endpoint forensics and remote acquisition; VQL queries for NTFS artifact collection	Remote collection during a live screenshare session; can collect $J and $MFT without agent pre-installation
fsutil.exe	Microsoft (built-in)	Native Windows tool for querying $UsnJrnl — can dump raw records and query journal status	Quick first-look at journal status without additional tools; checking if journal exists and its configuration
Magnet AXIOM / IEF	Magnet Forensics (commercial)	Commercial DFIR platform with NTFS journal parsing and integrated timeline	Commercial/professional investigations requiring court-ready output

§ 15

PowerShell & Command-Line Reference

Check USN Journal Status (Built-In)

CMD / PowerShelljournal_status.ps1
# Query the USN journal status — no special tools needed
# Shows if the journal exists, its size config, and the current/first USN
fsutil usn queryjournal C:

# Example output fields to check:
#   Usn Journal ID     — unique ID; changes if journal is deleted and recreated
#   First Usn          — oldest USN still present in $J
#   Next Usn           — next USN to be assigned (current journal position)
#   Maximum Size       — configured max size (default ~0x2000000 = 32 MB)
#   Allocation Delta   — how much is freed when journal wraps (default ~0x800000 = 8 MB)

# A Maximum Size of 512 bytes or similarly tiny value indicates deliberate shrinkage
# A recent First Usn close to Next Usn indicates the journal was recently cleared/reset
          
This command requires no external tools and runs in any CMD or PowerShell window. The output alone can confirm whether the journal has been tampered with.

Collect NTFS Artifacts with MFTECmd

PowerShellcollect_ntfs.ps1
# ── Requires MFTECmd.exe (EZ Tools) — run as Administrator ──────

$out = "C:\ForensicOutput"
New-Item -Path $out -ItemType Directory -Force | Out-Null

# Parse $MFT — full file listing including deleted entries
MFTECmd.exe -f "C:\`$MFT" --csv $out --csvf mft_output.csv

# Parse $UsnJrnl:$J — complete file activity journal
MFTECmd.exe -f "C:\`$Extend\`$UsnJrnl:$J" --csv $out --csvf j_output.csv

# Parse $LogFile — NTFS transaction log
MFTECmd.exe -f "C:\`$LogFile" --csv $out --csvf logfile_output.csv

# Note: Backtick-escapes required in PowerShell for $ in NTFS metadata paths
# The tool handles raw volume access internally — files do not need to be copied first

Write-Host "Output written to $out"
Write-Host "Open CSVs in Timeline Explorer for filtering"
          
MFTECmd accesses the raw NTFS volume directly. Administrator rights are required. The output CSVs can be opened directly in Timeline Explorer for filtering by filename, timestamp, and reason code.

Quick $J Search — Known Cheat Client Names

PowerShellsearch_j_output.ps1
# After running MFTECmd to produce j_output.csv:
# Filter $J CSV for known cheat client indicators

$jPath = "C:\ForensicOutput\j_output.csv"
$data = Import-Csv $jPath

# Known Minecraft cheat client name fragments
$mcPatterns = @(
  'liquidbounce', 'wurst', 'meteor', 'aristois',
  'impact', 'inertia', 'xray', 'aimbot',
  'autoclicker', 'killaura', 'scaffold',
  'baritone', 'freecam', 'antiknockback'
)

# Known cleaners / anti-forensic tools
$cleanerPatterns = @(
  'ccleaner', 'bleachbit', 'privazer', 'eraser',
  'sdelete', 'fsutil', 'bcwipe', 'fileshredder'
)

# Combine all patterns
$allPatterns = $mcPatterns + $cleanerPatterns

# Filter and display results
$hits = $data | Where-Object {
  $name = $_.Name.ToLower()
  $allPatterns | Where-Object { $name -like "*$_*" }
}

$hits | Select-Object UpdateTimestamp, Reason, Name, ParentPath |
  Sort-Object UpdateTimestamp |
  Format-Table -AutoSize

# Write hits to separate file for reporting
$hits | Export-Csv "C:\ForensicOutput\j_hits.csv" -NoTypeInformation
          
This script post-processes MFTECmd's CSV output to surface high-value hits quickly. Adjust the patterns array as needed. Export the hits CSV as evidence documentation.

Check for Journal Tampering Indicators

PowerShelljournal_tamper_check.ps1
# Quick tamper-indicator checks — run as Administrator

# 1. Check USN journal configuration
Write-Host "=== USN Journal Status ==="
fsutil usn queryjournal C:

# 2. Check $UsnJrnl file timestamps via MFT
# If the journal was deleted and recreated recently, its creation time will be suspicious
Write-Host `n"=== $UsnJrnl MFT Entry ==="
$result = MFTECmd.exe -f "C:\`$MFT" --csvf mft_tmp.csv --csv . 2>$null
Import-Csv .\mft_tmp.csv |
  Where-Object { $_.FileName -eq '$UsnJrnl' } |
  Select-Object FileName, Created0x10, LastModified0x10, LastRecordChange0x10

# 3. Check Prefetch for fsutil.exe (evidence of deletejournal command)
Write-Host `n"=== FSUTIL Prefetch Entries ==="
Get-ChildItem "C:\Windows\Prefetch" -Filter "FSUTIL*" |
  Select-Object Name, LastWriteTime, CreationTime

# 4. Show first and last $J timestamps from MFTECmd output
# A gap between system install date and first $J record is suspicious
Write-Host `n"=== $J Timestamp Range ==="
$j = Import-Csv "C:\ForensicOutput\j_output.csv" |
  Sort-Object UpdateTimestamp
Write-Host "Oldest $J record: $(($j | Select-Object -First 1).UpdateTimestamp)"
Write-Host "Newest $J record: $(($j | Select-Object -Last 1).UpdateTimestamp)"
          
This script surfaces the key tamper indicators in one pass. The combination of a recent $UsnJrnl creation timestamp, a FSUTIL Prefetch entry, and a short $J history window is strong evidence of deliberate journal clearing.

§ 16

Conclusion

$LogFile and $UsnJrnl:$J represent two layers of the same truth: a near-complete, tamper-resistant record of everything that happened to the filesystem. In screenshare contexts, they are among the most powerful artifacts available precisely because they require no special logging configuration, are invisible to most users, and survive the vast majority of cleanup attempts.

$LogFile gives you depth — the ability to see the exact before-and-after state of metadata changes, recover pre-timestomping timestamps, and detect ADS creation with surgical precision. $J gives you breadth — a long-running, timestamp-accurate record of every file operation across the entire volume, including the names and exact deletion times of files that no longer exist.

Together, they close the most common evasion loops: deleting evidence, renaming files to hide them, running a cleaner, and timestomping. In each case, the journal either contains the event directly, or the anti-forensic action itself leaves a distinct and recognizable pattern that supports rather than undermines the investigative conclusion.

Final Note

The most important habit when working with these artifacts is to extract them early and interpret them conservatively. A $J hit for a suspicious filename is evidence that the file existed and was operated upon — it is not automatically a ban. Context from Prefetch, MFT timestamps, $I30 slack, and event logs should all be cross-referenced before conclusions are stated with high confidence.