Skip to content

Carve and review with IndxCarver

Start with a question, not a broad scan

Repeatable command line workflow

Suppose a verified filesystem examination suggests that a Finance document was renamed, but the healthy directory index no longer contains the old entry. Your question is narrow: does the authorised unallocated data export contain a structurally plausible INDX record that can be decoded into a relevant filename lead?

IndxCarver is the recovery stage. It does not answer the whole case question. Preserve its outputs, parse the strongest candidate set, and compare meaningful file references, parent references and timestamps with independent NTFS evidence.

1. Prepare the working boundary

Source

Record the evidence identifier, volume, acquisition method, byte range if exported, original hash and working copy hash.

Tool

Record IndxCarver64.exe, displayed version, repository revision or acquisition date, SHA-256 and analysis host details.

Destination

Create an empty output directory on separate controlled storage. Record its full path and available space.

Use paths without spaces for the first run so the command and any parser limitations are easy to distinguish. The example below assumes the verified working input already exists:

mkdir X:\DFIR-218\indxcarver
certutil -hashfile D:\DFIR-218\working\Finance-unallocated.bin SHA256

Do not point output at the source

The tool creates several files. Keep them away from the original evidence and the verified working input so the scan cannot change the material being examined or mix generated files with source data.

2. Run a recorded command

cd /d C:\Tools\JoakimSchichtTools\IndxCarver
IndxCarver64.exe /InputFile:D:\DFIR-218\working\Finance-unallocated.bin /OutputPath:X:\DFIR-218\indxcarver

Record the command, start and finish times, console messages and exit behaviour. A window closing or a returned prompt is not enough to prove success; verify the expected files and read the log.

Part Meaning Check before running
IndxCarver64.exe 64-bit executable Filename and SHA-256 match the recorded tool copy
/InputFile: File to scan Correct case, verified working copy and intended data boundary
/OutputPath: Folder for generated files Empty, separate, writable and case linked

3. Verify the output set

IndxCarver uses a timestamped prefix. A normal run can produce files similar to:

Carver_Indx_2026-09-25_10-14-32.log
Carver_Indx_2026-09-25_10-14-32.wfixups.INDX
Carver_Indx_2026-09-25_10-14-32.wofixups.INDX
Carver_Indx_2026-09-25_10-14-32.false.positives.INDX

Hash all four files, even if one is empty. Record the file sizes and keep the common timestamped prefix so reviewers can see that the outputs belong to the same run.

1Read the logCheck scan completion, counts, errors and candidate offsets.
2Parse `wfixups`Begin with candidates that passed fixup validation.
3Assess `wofixups`Use a separate parser run and document the weaker structural basis.
4Retain false positivesUse the log and source offsets for review; do not promote rejected hits.

4. Hand candidates to a parser

IndxCarver writes raw INDX record groups. Use Indx2Csv or another validated parser to decode them. Keep each group in a separate output directory so rows from different confidence groups cannot be confused.

Start with the .wfixups.INDX file and the parser's normal, documented settings. If the case requires review of .wofixups.INDX, label that run clearly and carry the failed fixup limitation into every exported row and conclusion.

When a relevant name appears, record:

  • the IndxCarver output group and its hash;
  • the candidate offset from the log where available;
  • the filename, namespace and allocation or slack state reported by the parser;
  • the complete file reference, including its sequence value;
  • the parent file reference and decoded time fields;
  • the parser name, version, settings, output path and output hash.

5. Corroborate before reporting

  • Compare identity, not only text
    Similar filenames can belong to different records. Compare the complete file reference and parent reference where the source retains them.
  • Separate carving from decoding
    IndxCarver identifies candidate record containers; the parser interprets fields. Preserve the versions and logs for both stages.
  • State the recovery context
    Make clear whether the entry came from unallocated data, a damaged record, the fixup skipped group or parser reported slack.
  • Use independent evidence
    Test important leads against $MFT, $UsnJrnl, allocated directory indexes, acquisition offsets or known ground truth.

Use bounded language:

IndxCarver recovered a fixup valid INDX candidate from the verified unallocated data export. Indx2Csv decoded a directory entry containing the relevant name and file reference. The carved metadata supports a historical filename lead, but does not by itself prove current file presence, content, execution, user intent or authorship.

Troubleshooting

Symptom First check
A file picker opens /InputFile: was omitted or not recognised; use the documented switch and a valid file path
Output appears beside the executable /OutputPath: was omitted; move to a clean run with an explicit separate destination
No candidate records are reported Confirm the intended input file and boundary, then retain the negative result instead of widening scope without justification
Many false positives appear Read their offsets in the log, confirm the source type and prioritise structurally validated candidates
Parser rejects wofixups output Preserve the failure and report the weaker or damaged source condition; do not relabel it as fixup valid
A filename appears without useful path context Treat it as a lead and seek parent references or independent NTFS artefacts
Interpretation checkA matching filename appears only in `.wofixups.INDX`, and its file reference differs from the known current file. What should you report?
PreviousIndxCarver overviewNextHands on labs