Listen to the full reference63 min / AI narration
Code, tables and images may need the written guide.
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.
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.
$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.
$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 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 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
$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
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
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
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
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.
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.
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.
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.
$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
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
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
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
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.
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
# 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.
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.
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.
In the context of Minecraft and FiveM PC checks, these journals 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
Check USN Journal Status (Built-In)
# 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
# ── 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
# 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
# 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.
$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.