Skip to content

Parse and review with LogFileParser

Turn an extracted $LogFile into a reviewable record of filesystem activity. Keep a case note open alongside the tool and record each decision that affects interpretation.

Select the sourceRecord settingsInspect the exportCorrelate and report

1. Select the right input

Click Select $LogFile and choose the verified working copy. The file may have been renamed during extraction; its provenance matters more than its filename. Record the original NTFS path, source image or volume, extraction method, file size and hashes of the preserved and working copies.

Get MFT csv is optional. It accepts CSV output from Joakim Schicht's Mft2Csv, not the raw $MFT and not arbitrary CSV from another parser. Use an export from the same volume with compatible schema and encoding. Check the author's compatibility notes and test the join rather than assuming every name resolved correctly. For the first run, it is reasonable to leave this blank and review the unjoined output.

Select fragment is for a broken transaction fragment. It is a separate recovery path, not another mandatory evidence input. There is no $UsnJrnl input button in the supplied interface: LogFileParser can decode journal records embedded within $LogFile; separately collected journal output can be used for corroboration.

2. Configure and record the run

Control in the screenshot First run approach Why it matters
Timestamp format / Precision Record the selected format; use format 6 and NanoSec for this lesson Preserves displayed fractional detail; precision does not prove clock accuracy
Set decoded timestamps to specific region Use UTC 0.00 for this lesson Keeps comparison explicit; a display conversion is not another event
Set separator Keep pipe (\|) and match it when importing A .csv suffix does not guarantee comma separated fields
Unicode Record the setting and check a known filename in the export Encoding and optional MFT import/reconstruction compatibility need verification
Sectors per cluster / MFT record size Use values established from the source volume Incorrect geometry can undermine decoding; screenshot defaults are not universal
Source is from 32-bit OS Follow the source system context This refers to the system that handled the volume, not the analyst workstation's executable architecture
Split csv Leave off for the small beginner run Keep an inventory if a larger run is split
When should I touch the recovery options?

Broken $LogFile, Skip Fixups and Rebuild headers (in slack) belong to damaged or recovered input investigations. Preserve a baseline run and compare any recovery run separately. Reconstruct data runs attempts to derive allocation information; it is not a guarantee of complete file recovery. The LSN error level affects recovery heuristics. Leave it at the documented baseline unless you can explain and validate a change.

Extract non + resident updates and the verbose LSN list support deeper review. Retain any binary extracts and their relation to the originating transaction. Do not interpret recovered bytes without their attribute, offset and redo/undo context.

3. Start and locate the output

  1. Check the selected input, geometry, time basis, separator and encoding once more. Capture the settings in your notes or a screenshot.
  2. Click Start. Read messages and retain any errors rather than treating the end of processing as proof of success.
  3. Open the newly created LogFile_… directory beneath the program directory. The supplied GUI has no output folder button. Use a writable analysis location and preserve this run as a case linked output set.
  4. Review debug.log, the file inventory and row counts. Output availability depends on the input and enabled options. Keep empty or warning bearing output in context.
  5. Rehash the working input and compare it with the pre run value. Hash and preserve the output set before making filtered working copies.

4. Know which file to open

LogFile.csv

Main transaction export. Start with LSN, operations, reference fields and decoding context.

LogFile_FileNames.csv

Resolved names associated with MFT reference, sequence and LSN. Useful for finding a candidate record instance.

LogFileJoined.csv

Transaction output enriched with name information. Check the origin of the association against the unjoined records.

Other outputs may include LogFile_INDX_I30.csv, embedded journal records in LogFile_lfUsnJrnl.csv, SQLite output ntfs.db, and specialised attribute exports. Use your run's headers and schema; do not assume all exports share the same field names.

Import delimited files using the configured separator and encoding. Keep identifiers such as LSNs as text or exact integers: spreadsheet numeric conversion can round large values. Preserve the original exports and conduct searches or sorting in a separate working view.

Follow one candidate

  1. Search the filename export for your target, but retain every matching reference and sequence number. The same name can belong to different files.
  2. Identify a candidate reference + sequence pair. A reused MFT record number with a different sequence is not automatically the same file instance.
  3. Follow related LSNs and operations in LogFile.csv. Keep lf_Offset, lf_LSN, lf_LSNPrevious, operation fields and relevant attribute data. Reference resolution can be incomplete; retain uncertainty.
  4. Check FromRcrdSlack, IncompleteTransaction and lf_TextInformation. Isolate slack/reconstructed/partial material rather than silently mixing it with stronger records.
  5. Correlate the candidate with separately collected $UsnJrnl:$J or $MFT output from the same volume. Seek matching references, sequences, parent context and relevant change reasons. Separate journal timestamps from attribute timestamps.

A rename lead, not attribution

Two names associated with reference 51200 and sequence 4 are a rename lead. A matching journal old and new name pair strengthens that explanation. The name pair alone does not identify who made the change, prove why it happened, or prove a file was copied off the system.

5. Record a finding another analyst can review

Question and authorised scope:
Source volume/image, acquisition and extraction context:
Input path, size, SHA-256 before and after:
Parser version, executable hash, settings and run directory:
Output filename, row/offset, LSN, reference and sequence:
Direct observation:
Corroborating source and matching identifiers:
Interpretation and alternative explanations:
Coverage, decoding limitations and next check:

If the result does not make sense

Symptom Check next
Startup/path warning or output not created Use a writable, simple program path without spaces; keep package dependencies together
Everything appears in one column Match the viewer delimiter to Set separator; inspect the raw header
Names appear garbled Verify encoding with a known name; check MFT CSV compatibility before joining
No relevant filename Inspect unjoined records, log coverage and warnings; absence is not proof the change never happened
Unexpected time shift Compare the recorded region and the meaning of each timestamp field
Many partial/slack records Preserve flags and logs; validate recovery settings in a separate run
MFT name seems unrelated Check volume provenance, reference reuse and sequence numbers

Continue with the interactive investigation or Full Lab. Technical reference: author's source and output schema, README, and 2.0.0.53 changes.