Comparing ShimCache parsers: Mandiant, Zimmerman, Velociraptor, and this tool

4 min read

TL;DR. Use Eric Zimmerman's AppCompatCacheParser for casework — broadest OS coverage, CSV output, well-tested. Use Velociraptor for live triage at scale. Use Mandiant's ShimCacheParser when a simple Python reference helps. Use this tool when you want zero install and zero upload — fast triage in the browser. Cross-validate disagreements; the format is finicky enough that two parsers occasionally see things differently.

The four parsers that matter

ToolLanguageDistributionBest for
Mandiant ShimCacheParserPythonSource on GitHubReading the format, scripting custom analysis
Eric Zimmerman AppCompatCacheParserC# / .NETSingle binaryCase work — most reliable for production reports
Velociraptor Windows.Registry.AppCompatCacheVQLVelociraptor serverLive collection at fleet scale
Shimcache Parser (this tool)Rust → WebAssemblyBrowser only, no installQuick triage without setup, no data leaves the machine

When to reach for which

Eric Zimmerman's AppCompatCacheParser (the default for case work)

EZ's C# parser is the de-facto standard for offline analysis. It covers every Windows variant from XP through Windows 11, replays SYSTEM transaction logs automatically, and outputs CSV that drops cleanly into Timeline Explorer. If your output is going into a final report, this is what reviewers will expect you used.

AppCompatCacheParser.exe -f SYSTEM --csv .

Caveats: Windows-only binary; you need .NET Framework / Core installed; not great for ad-hoc browser-based triage.

Velociraptor Windows.Registry.AppCompatCache (collection at scale)

When you need to pull ShimCache from dozens or thousands of hosts, Velociraptor wins. The artifact reads the in-memory cache directly from running endpoints — the same view the OS would have flushed at shutdown, but without waiting for shutdown. See Extracting the ShimCache from a memory dump for the rationale.

Caveats: requires Velociraptor infrastructure. Overkill for one-off analysis.

Mandiant ShimCacheParser (the format reference)

The original Python proof-of-concept. Less polished than EZ's tool but useful when you want to read the code to understand exactly how the format is decoded, or to script custom analysis around it. The output is plain text; integrate it with other Python pipelines.

python ShimCacheParser.py -t -h /path/to/SYSTEM

Caveats: requires Python 2.x (or a compatibility fork); CSV / JSON output is less polished than EZ's.

This Shimcache Parser (no install, no upload)

This tool exists for two cases the others don't cover well:

  1. Zero-install triage: open the page, drop a hive, see entries. Useful when you're on a host without DFIR tooling installed, or analyzing on a laptop / loaner.
  2. Trust-sensitive analysis: the hive is parsed entirely in your browser via WebAssembly. The file never leaves the page, never hits a server, never appears in any log. That matters when the hive belongs to a client / case where upload isn't acceptable.

Trade-offs: no command-line interface, no CSV export (yet), no automation hooks. Use it for human-driven triage, not for pipelines. For pipelines, EZ's tool is the right answer.

Cross-validation: when two parsers disagree

The ShimCache binary format is unforgiving — the Windows 10/11 layout reference shows why a single offset miscount can cascade through the rest of the blob. In practice, parsers usually agree, but real-world hives sometimes ship slightly off-spec data, and parsers disagree on:

  • Bitness detection on Win7 hives — the header doesn't unambiguously say "x86 vs x64", so parsers heuristically pick. A pair of tools producing different paths on the same hive is your tell.
  • Path normalization — backslash escaping, drive letter case, leading \??\ markers. Different parsers normalize differently.
  • Empty / placeholder entries — some tools emit blank rows for unused slots; others skip them.

When it matters, run two parsers and diff. The combinations I'd reach for:

  • EZ + this tool for fast cross-check
  • EZ + Mandiant for a "Python vs C#" sanity check
  • EZ + Velociraptor for "live in-memory vs on-disk hive" comparison

Common pitfalls

  • Don't forget transaction logs. SYSTEM.LOG1 / SYSTEM.LOG2 carry pending writes; without them you're reading a stale hive. EZ's tool replays them automatically; some others don't. See Acquiring a SYSTEM hive.
  • Don't compare on-disk and in-memory ShimCache directly. They're different sources of truth — on-disk has only the last clean-shutdown state, in-memory has the current session. Treat them as complementary, not redundant.
  • Don't assume execution. No parser can fix this — the cache records examination, not execution.

Further reading

Related articles