Extract and verify¶

Follow a file from its source to a checked copy. If a colleague has already confirmed its MFT record, go straight to extracting the document. Otherwise, collect the file catalogue first.

1. Prepare the source and destination¶

INPUT / READ

Source identity¶

Record the image hash or live host, NTFS volume and time zone. Work from a verified image or authorised training volume.

OUTPUT / WRITE

Output identity¶

Create a new case folder on separate storage. Check free space and choose that folder in the tool.

The Full Lab uses a live training VM, where files can change during collection. Record that limitation.

START HERE / CASE IMAGE

Open the image, then choose its volume¶

Click Choose Image and open your verified working copy.
In the lower list, select the NTFS volume that holds the file.
Check the volume size and partition against your case notes. An image can contain more than one volume.

Click Choose Output and select your new case folder before you start extracting.

Working from a mounted volume, physical disk or shadow copy?

Mounted volume: click Rescan Mounted Drives, then select the intended volume in the lower list. Check its identity and size.
Physical disk: click Scan Physical, select the disk in the upper list, then Test it. Choose the intended partition in the lower list.
Shadow copy: click Scan Shadows, select a snapshot in the upper list, then Test it. Choose its NTFS volume and record the snapshot time.

The official README describes these source routes.

2. Choose a useful scope¶

FOCUSED COLLECTION / USER SELECT

Know the record? Extract just what you need.¶

Select User Select, keep Logfile enabled and leave Partial Init off. Click Start Extraction to enter decimal record numbers.

Need the file catalogue first? Enter 0,2 to collect $MFT and $LogFile. Use the next section to preserve them.
Already have the document's record? Enter that confirmed number. In the browser lab it is 7421; your real case will have its own number.

Two different logs: record 2 is NTFS's $LogFile. The Logfile control saves the tool's own run log, beside its executable. Keep the tool on separate storage too. See the implementation.

When would I use Active, Deleted or All?

Active collects files still allocated on the volume. Useful for a wider collection, but expect more output.
Deleted attempts to recover deleted files. Some bytes may already be overwritten; check each result.
All includes both. Use it when the case calls for a broad collection and your destination has enough space.

For a known document, User Select keeps the collection focused.

3. Run, inspect and preserve¶

Choose Output; confirm the path and selected source. Record the settings and start time.
Extract records 0,2. Keep the tool's log and any errors; its .log file is written beside the executable.
Find both outputs, check they are nonempty and hash them. Use a copy of $MFT for parsing.

# Set this to your actual output folder, on separate evidence storage.
$nfeOutput = 'E:\Cases\NFE-1042\metadata'
Get-ChildItem -LiteralPath $nfeOutput -Recurse -File |
    Select-Object FullName, Length
Get-ChildItem -LiteralPath $nfeOutput -Recurse -File |
    Get-FileHash -Algorithm SHA256 |
    Export-Csv -LiteralPath 'E:\Cases\NFE-1042\metadata-sha256.csv' -NoTypeInformation

Keep the manifest outside the folder being hashed. A hash identifies retained bytes; it does not prove a complete acquisition.

4. Identify and extract one document¶

Open a working copy of the extracted $MFT in MFT Explorer or parse it with Mft2Csv. Search for the known training filename, confirm its parent path and allocation status, and record its MFT entry/index number. Do not paste a full file reference value containing a sequence number into the GUI.

Reopen NtfsFileExtractor, select the same source volume, choose a fresh output folder, then User Select › Start Extraction › the confirmed decimal entry number. Compare the extracted file with its known content and baseline SHA-256.

What do unusual output names mean?

Deleted output may be prefixed with [DEL+IndexNumber]; alternate streams use [ADS_streamname] in the output name. Keep those distinctions in your evidence inventory. A recovered filename or extension alone is insufficient to validate its content. The naming conventions are documented in the README.

Before you call it a match¶

01 / TRACE

Right file?¶

Check the source volume, record number and expected path. A matching filename alone is not enough.

02 / INSPECT

Readable content?¶

Inspect the file safely, check its size and review the extraction log for read errors. Never run a recovered program to test it.

03 / COMPARE

Same bytes?¶

Compare the full SHA-256 with a known copy when available. Without a baseline, save the hash and explain what you could verify.

Pause and decide: the log says “complete”. Is the file verified?

Not yet. The log says the run finished. You still need to locate the right output, check its content and size, review errors and compare it with the known copy. A matching hash supports identical bytes; it does not tell you who used the file.

Something doesn't look right?¶

Open the symptom that matches your run. Keep the original output and logs while you investigate.

No NTFS volume appears

Check the source type, access rights and whether the volume is readable NTFS. Encrypted or unsupported containers need preparation with an appropriate, validated workflow.

The wrong file was extracted

Recheck the source volume and decimal entry number against your parser result. Records can be reused, so also confirm the path and file status.

The output is missing, or a deep path fails

Check the selected output folder, its subfolders, free space and the run log. For a path length failure, retry in a shorter, fresh destination and keep both runs' logs.

The hash differs from the known copy

Preserve both results. Check for a changed live file, the wrong record or incomplete reads. Report the mismatch until you can explain it.

A deleted file is empty or damaged

Its data may no longer be available. Record the recovery limit; an unsuccessful recovery does not prove the file never existed.