How to Acquire the NTFS $LogFile (Live and Dead Box)

Q: Can I copy $LogFile with Explorer or the copy command?

No. $LogFile is an NTFS metadata file that the file system keeps open while the volume is mounted, and it is hidden from normal file APIs. Read it through raw NTFS access (KAPE, Velociraptor, FTK Imager, RawCopy) or from an image with icat or ntfscat.

TL;DR. $LogFile is MFT entry 2 at the root of each NTFS volume, locked while mounted. On a live host, use KAPE ($LogFile + $MFT targets), Velociraptor (Windows.Triage.Targets with its LogFile + MFT targets; Windows.KapeFiles.Targets on older releases), FTK Imager or RawCopy (/FileNamePath:C:2). From an image, use icat image.dd 2 or ntfscat -i 2. Collect it first — it is circular and your own activity overwrites it — and collect the $MFT of the same volume at the same time. Then check the copy starts with RSTR, has the size the restart area declares, and is not all zeros.

The $LogFile is the most perishable artifact on an NTFS volume. On a busy system drive it can roll over in well under an hour. Every command you run on the host writes metadata, and every metadata write goes through the log. Acquisition order and destination matter more here than for almost any other file.

What you are collecting

File	Where	MFT entry	Why
`$LogFile`	Root of each NTFS volume (`C:\$LogFile`)	2	The transaction log itself
`$MFT`	Root of the same volume	0	Names and parents for every MFT entry referenced by the log
`$UsnJrnl:$J`	`$Extend\$UsnJrnl`, `$J` stream	varies	Dated change history for correlation (optional but recommended)

The log is usually about 64 MiB on current Windows volumes (the size is configurable with chkdsk /L, so check it rather than assume it). Take all volumes that matter, not only C:. Removable and data volumes keep history much longer than the system drive.

Before you start: protect the log from yourself

Collect it first, before memory-heavy or file-heavy triage. dfir.ru measured old records being overwritten after 16 minutes in one Windows 10 test (How the $LogFile works?).
Write the output to another volume (USB drive, network share). Writing a collection to C: generates log records on C: for every file you create.
Do not run chkdsk on the evidence volume. It can reset or resize the log. If a restart page carries the CHKD signature, the log was touched by chkdsk.
Take $LogFile and $MFT in the same run, from the same volume, and keep the folder structure (C/, D/) so each log can be paired with its own $MFT.

Live Windows host

KAPE

The KapeFiles project ships $LogFile.tkape and $MFT.tkape targets (plus $J.tkape for the USN journal):

kape.exe --tsource C: --target $LogFile,$MFT,$J --tdest E:\case42\kape

KAPE reads locked files through raw access and preserves the source path in the output tree. Repeat --tsource for each volume. If you use a compound target, open it and confirm it references $LogFile rather than trusting the name.

Velociraptor

Windows.Triage.Targets, from the Velociraptor Triage project, collects the same files at scale. Tick its LogFile and MFT targets in a server collection or an offline collector (Server Artifacts → Build offline collector), and check MaxFileSize so a large $MFT is not skipped.

Older Velociraptor releases ship the former Windows.KapeFiles.Targets instead, with $LogFile and $MFT targets. It can use the ntfs, lazy_ntfs and mft accessors; lazy_ntfs is faster but relies on $I30 index data, which is not always complete for metadata files, so the artifact exposes a DontBeLazy option to fall back to the full NTFS parser (Velociraptor bulk file acquisition). For NTFS metadata files, prefer the full accessor.

FTK Imager

File → Add Evidence Item → Logical Drive, select the volume, expand [root], right-click $LogFile and $MFT → Export Files. Export to an external drive. FTK Imager reads the volume directly, so the lock does not apply.

RawCopy

Joakim Schicht's RawCopy accepts a volume plus MFT record number instead of a path. Its readme shows C:0 for the $MFT; $LogFile is record 2:

RawCopy.exe /FileNamePath:C:2 /OutputPath:E:\case42 /OutputName:LogFile_C.bin
RawCopy.exe /FileNamePath:C:0 /OutputPath:E:\case42 /OutputName:MFT_C.bin

Run it as administrator. Rename outputs back to $LogFile / $MFT or keep a clear naming scheme; parsers that pair files by name (including the in-browser $LogFile parser) look for the $LogFile and $MFT in the same folder.

Dead box or disk image

The Sleuth Kit

icat extracts a file by metadata address; on NTFS, the address is the MFT entry. -o is the sector offset of the partition inside the image (icat man page):

mmls image.dd                         # find the NTFS partition start sector
icat -o 2048 image.dd 2 > '$LogFile'
icat -o 2048 image.dd 0 > '$MFT'

ntfs-3g on Linux

ntfscat from ntfs-3g accepts an inode number with -i (ntfscat man page). Attach the image read-only (for example with a loop device and --read-only), then:

ntfscat -i 2 /dev/loop0p2 > '$LogFile'
ntfscat -i 0 /dev/loop0p2 > '$MFT'

Never mount the evidence volume read-write "just to copy a file". Mounting writes to the log.

Volume Shadow Copies

Shadow copies contain older copies of NTFS metadata files, which means older windows of $LogFile. Extract them from each snapshot with the same raw tools (or collect the snapshots with your imaging workflow) and parse each copy separately. Label each copy with the snapshot creation time.

Check the copy before you leave

A failed raw copy often looks like success: the file exists and has the right size. Four quick checks:

Check	How	Bad sign
Signature	First 4 bytes	Not `RSTR` (or `CHKD`)
Not zero-filled	Look at the first 4 KiB	All zeros: lock or sparse read failed
Size	Compare with the log size in the restart area	Shorter: truncated copy
Pairing	`$MFT` from the same volume and time	Different collection times

xxd -l 16 '$LogFile'      # expect 52 53 54 52  -> "RSTR"
sha256sum '$LogFile' '$MFT' > hashes.txt

The $LogFile parser runs the same checks on intake: a file that starts with zeros is reported as "probably locked or still being written when copied", a copy shorter than its declared size is flagged as truncated, a CHKD restart page is reported, and a $MFT without a $LogFile from the same folder is explained rather than silently ignored.

Chain of custody notes

Record tool name and version, the command line, source volume, destination and time for every copy.
Hash on the collection host and again on the analysis host.
If you collected from a live system, say so in the report: a live $LogFile is a moving target, and the newest page may only exist in the tail or fast-page area (see $LogFile format 1.1 vs 2.0).

Next step

Open the files in the browser-based $LogFile parser — nothing is uploaded — and follow how to analyze an NTFS $LogFile. For the other artifacts from the same collection, the sibling USN journal parser, Prefetch parser and disk image tools cover the next steps.

Frequently asked questions

Can I copy $LogFile with Explorer or the copy command?

No. $LogFile is an NTFS metadata file that the file system keeps open while the volume is mounted, and it is hidden from normal file APIs. Read it through raw NTFS access (KAPE, Velociraptor, FTK Imager, RawCopy) or from an image with icat or ntfscat.

Why collect the $MFT with the $LogFile?

Log records refer to files by MFT entry number. Names only appear in the log when a file is created, renamed or deleted, so without the $MFT of the same volume many paths stay incomplete.