Skip to content
$LogFileparser

NTFS transaction journal · DFIR

NTFS $LogFile Parser

Recent file creations, renames, deletions and timestamp changes reconstructed from the NTFS transaction journal — with every raw log record one click away. Parsed in your browser with WebAssembly — nothing is uploaded.

  • $LogFile
  • $MFT
  • LSN
  • redo / undo
  • Rust → WASM

Drop $LogFile (and the $MFT of the same volume) here

Add the $MFT to turn MFT references into full paths. Folders and ZIP triage collections (KAPE, Velociraptor) work as-is — each $LogFile is paired with the $MFT next to it.

A synthetic $LogFile and $MFT from a fictional intrusion — no real data.

100% client-side: files are parsed by WebAssembly in your browser and never uploaded.

How to get your data

Full acquisition guide

$LogFile is a locked NTFS metafile: Explorer and copy cannot read it. One command collects it together with the $MFT that names its files.

  1. 1. Collect $LogFile + $MFT
  2. 2. Drop the folder or ZIP here
  3. 3. Everything stays in your browser

KAPE, two targetsRecommended

Administrator Command Prompt (cmd.exe; PowerShell would expand $LogFile) · KAPE on the host or a USB drive · E: = your external drive.

cmd · admin
kape.exe --tsource C: --target $LogFile,$MFT --tdest E:\triage

Produces E:\triage\C\$LogFile and E:\triage\C\$MFT. Drop the whole E:\triage folder here. For another volume, run it again with --tsource D:.

Gotchas

  • A plain copy fails or comes back zero-filled because the file is locked. Use a raw-access tool above; the tool flags zero-filled copies.
  • The log is circular: a busy system drive can roll over in under an hour. Collect it first and write to another drive, not C:.
  • Take the $MFT from the same volume in the same run, and never run chkdsk on the evidence volume (it can reset the log).

What is the NTFS $LogFile?

$LogFile is the NTFS transaction journal (MFT entry 2). Before NTFS changes its own metadata — a FILE record, a directory index, a bitmap — it writes a log record describing the change twice: a redo operation (how to apply it) and an undo operation (how to roll it back). After a crash, Windows replays or undoes these records to keep the volume consistent.

For an investigator, those redo and undo bytes are gold: they hold the file names, parent folders, MFT references and timestamps of every metadata change, before and after. File creations, deletions, renames and timestamp rewrites can be rebuilt from them, even when the USN journal was disabled or cleared.

Where it is stored

  • \$LogFile at the root of every NTFS volume (C:\$LogFile, D:\$LogFile…). It is a hidden metadata file: Explorer and copy cannot open it — use a raw NTFS reader.
  • Default size: 64 MiB on current Windows (configurable with chkdsk /L). It is circular: new records overwrite the oldest ones, so it usually covers minutes to a few hours of activity on a busy system.
  • Layout: two restart pages (RSTR), then 2 tail pages (log format 1.1, Windows XP–7, and Windows 8+ after a clean shutdown) or 32 fast pages (format 2.0, Windows 8+ while mounted), then the circular area of log record pages (RCRD), each protected by an update sequence array.

Why it matters in an investigation

  • File and folder creations (InitializeFileRecordSegment + AddIndexEntry), deletions (DeleteIndexEntry + DeallocateFileRecordSegment) and renames or moves, with the MFT entry and sequence number.
  • Timestomping: an UpdateResidentValue on $STANDARD_INFORMATION carries the old and the new timestamps — a creation time rewritten to 2019 is visible as such.
  • Content of small files, sometimes: data stored inside the FILE record (resident, up to ~700 bytes) can appear in redo/undo data — occasionally even for notes or scripts deleted a minute later. On modern Windows many edits only log that a change happened, so treat recovered content as a bonus, not a given.
  • It complements $UsnJrnl:$J (longer history, but only reasons and names) and $MFT (current state only): $LogFile gives the before / after values.

Limitations

  • Short retention: the log is circular, so only recent activity is still there. Collect it early.
  • Log records have no clock time. Times shown come from the $FILE_NAME / $STANDARD_INFORMATION values inside the data; events without one borrow the time of the nearest dated event and are marked ≈.
  • Names are only known when they appear in the log; without the $MFT, some paths start with [MFT #n] or are missing.
  • Non-resident file content is never in $LogFile (only metadata). Transaction grouping, the $UsnJrnl companion and $I30 slack are not used yet.
  • The parser is validated against synthetic logs built from the published format (Linux ntfs3, libfsntfs) — verify important findings with a second tool.

How to get the files

  • KAPE: the $LogFile and $MFT targets (or !SANS_Triage) collect them raw from each volume. Velociraptor: Windows.Triage.Targets with its LogFile and MFT targets (formerly Windows.KapeFiles.Targets), or the NTFS accessor.
  • From a disk image: FTK Imager (export from [root]) or The Sleuth Kit: icat -f ntfs image.dd 2 > '$LogFile' and icat … 0 > '$MFT'.
  • Take $LogFile and $MFT from the same volume at the same time, and keep the folder structure (C/, D/…) so each log is paired with its own $MFT.

FAQ

Is my $LogFile uploaded anywhere?

No. The parser is Rust compiled to WebAssembly and runs in a Web Worker in your browser. There is no upload endpoint; the $MFT is streamed in chunks and only file names and parents are kept.

Why add the $MFT?

Log records point to MFT entries, and a file's name is only logged when it is created, renamed or deleted. The $MFT names every other entry and every parent folder, so paths become complete (\Windows\System32\… instead of [MFT #44]).

How does it spot timestomping?

Every $STANDARD_INFORMATION update in the log carries the old and the new values. A rewritten creation time, a timestamp moving backwards, a whole-second value or a creation time earlier than $FILE_NAME's are flagged — hints to verify, not proof.

Does it support Windows 8, 10 and 11 logs?

Yes: log format 2.0 (32 fast pages, used while the volume is mounted on Windows 8 and later) and 1.1 (older Windows, or after a clean shutdown). The newest page, often still only in the tail / fast area of a live capture, is used when it is newer than its circular copy.

How is this different from LogFileParser or NTFS Log Tracker?

Same source data, no install: it runs in the browser, shows every raw log record next to the rebuilt events, resolves paths with the $MFT and exports CSV / JSON. Those tools are more mature — use them to confirm key findings.

Blog

Read the blog →