What this auditor measures
An EVTX file starts with a 4,096-byte file header followed by fixed 65,536-byte chunks. Each chunk contains a 512-byte header, an allocated event-record region, and unused space. The auditor compares declared and physical chunk counts, validates offset bounds, recalculates the file-header, chunk-header, and record-data CRC32 values, then walks record envelopes using their leading and trailing sizes.
Why CRC and continuity are separate evidence
A matching CRC32 says the covered bytes agree with a stored accidental-corruption checksum; it is not a cryptographic signature. Sequential record identifiers are another clue. A gap can reflect cleared, overwritten, recovered, or otherwise absent records, while duplicates and backward movement are stronger structural anomalies. None of these facts alone proves tampering.
What a slack candidate means
After the chunk's free-space offset, the tool scans for the documented record signature, a bounded aligned size, a matching trailing size, an identifier, and a plausible FILETIME. Passing those envelope checks makes a byte range worth specialist review. It does not prove that the embedded binary XML is complete, internally valid, attributable, or admissible.
Format basis
The byte layout follows the maintained libevtx EVTX format document. The independent evtx parser implementation is a useful downstream choice when complete BinXML-to-XML/JSON event decoding is required.
Validation boundary
This is a structural triage tool, not a complete EVTX parser or forensic conclusion. It does not decode BinXML, render messages, resolve provider resources, verify acquisition provenance, detect deliberate checksum recomputation, infer deletion causes, recover files from disk images, or validate chain of custody. Exported data describes only observed byte-level evidence. Preserve the original and use established forensic tooling for material investigations.
Frequently asked questions
Can a file pass every CRC and still be untrustworthy?
Yes. CRC32 detects accidental changes but offers no authentication. A person or program can change bytes and recompute it.
Does “dirty” mean the file is corrupt?
No. It is a header flag associated with an unclean or active state and deserves review alongside the actual checksum and record findings.
Can I recover the slack candidates here?
No. The tool intentionally exports offsets and envelope metadata only. Safe recovery also requires validating the candidate's BinXML and surrounding forensic context.
Why are provider and Event ID totals absent?
Those fields live inside BinXML. ToolQuill avoids partial decoding that could silently mislabel damaged records; use a complete parser after the structural preflight.
Inspect a SQLite WAL sidecar · Browse systems and forensics tools