TL;DR. 案件作業には Eric Zimmerman の AppCompatCacheParser（最も広い OS カバレッジ、CSV 出力、十分にテスト済）。大規模なライブ・トリアージには Velociraptor。Python の素直なリファレンスが欲しいときは Mandiant の ShimCacheParser。インストール不要・アップロード不要が要件なら 本ツール（ブラウザ内での迅速なトリアージ）。意見が割れたらクロスチェック：フォーマットは細かく、2 つのパーサーが時折異なる結果を返すことがあります。
注目すべき 4 つのパーサー
| ツール | 言語 | 配布 | 最適な用途 |
|---|---|---|---|
| Mandiant ShimCacheParser | Python | GitHub のソース | フォーマット理解、カスタム解析のスクリプト化 |
| Eric Zimmerman AppCompatCacheParser | C# / .NET | 単一バイナリ | 案件作業 — レポートで最も信頼できる |
Velociraptor Windows.Registry.AppCompatCache | VQL | Velociraptor サーバー | フリート規模のライブ収集 |
| Shimcache Parser（本ツール） | Rust → WebAssembly | ブラウザのみ、インストール不要 | セットアップ不要のトリアージ、データは端末から出ない |
どれをいつ使うか
Eric Zimmerman の AppCompatCacheParser（案件作業の既定）
EZ の C# パーサーはオフライン解析の事実上の標準です。XP から Windows 11 まで全バージョンをカバーし、SYSTEM トランザクションログを自動再生し、Timeline Explorer にそのまま流せる CSV を出力します。最終レポートに出力を載せるなら、レビュアーが期待するのはこれです。
AppCompatCacheParser.exe -f SYSTEM --csv .
制約：Windows 専用バイナリ、.NET Framework / Core が必要、ブラウザ内アドホック・トリアージには不向き。
Velociraptor Windows.Registry.AppCompatCache（大規模収集）
数十〜数千台のホストから ShimCache を引きたいなら、Velociraptor が最適。アーティファクトは稼働中エンドポイントから直接メモリ内キャッシュを読み出します — OS がシャットダウン時に書き出していたであろう同じビューを、シャットダウンを待たずに取得します。メモリダンプからの ShimCache 抽出を参照。
制約：Velociraptor インフラが必要、単発分析には過剰。
Mandiant の ShimCacheParser（フォーマットの参照実装）
オリジナルの Python proof-of-concept。EZ のツールほど洗練されていませんが、フォーマットがどう復号されるかを コードで読む ためや、カスタム解析を Python で組むときに有用です。出力はテキスト主体で、Python パイプラインへ統合する用途向き。
python ShimCacheParser.py -t -h /path/to/SYSTEM
制約：Python 2.x（または互換フォーク）が必要、CSV / JSON は EZ ほど洗練されていない。
この Shimcache Parser（インストール不要、アップロード不要）
このツールは他が苦手な 2 つのケースを埋めるために存在します。
- インストール不要のトリアージ：ページを開き、ハイブをドロップし、エントリを見る。DFIR ツールが入っていないホストや、ラップトップ／貸与機での解析に便利。
- 機密性の高い解析：ハイブは WebAssembly でブラウザ内のみで解析されます。ファイルはページから出ず、サーバーに到達せず、ログに残りません。クライアント／案件のハイブで「アップロード不可」が要件のときに重要です。
トレードオフ：CLI なし、CSV エクスポートなし（今のところ）、自動化フックなし。人手主導のトリアージ向きで、パイプラインには EZ のツールが正解です。
クロスバリデーション：2 つのパーサーが食い違うとき
ShimCache のバイナリ・フォーマットは厳格で、Windows 10/11 フォーマット参照が示すように、たった 1 つのオフセットずれで残りが連鎖的に崩れます。実務的にはパーサーは概ね一致しますが、実機ハイブが微妙に仕様外なことがあり、次の点で食い違います。
- Win7 ハイブのビット幅検出 — ヘッダーには「x86 / x64」が明示されておらず、各パーサーがヒューリスティックで判定します。同じハイブで 2 つのツールがパスを違えるのが手掛かり。
- パスの正規化 — バックスラッシュのエスケープ、ドライブレターの大文字小文字、
\??\プレフィックス。各パーサーで正規化方針が異なる。 - 空エントリ／プレースホルダー — 空行として出すツールと、スキップするツールに分かれる。
肝心な場面では 2 つのパーサーを走らせて diff を取ってください。推奨組合せ：
- EZ + 本ツール（高速クロスチェック）
- EZ + Mandiant（Python と C# のサニティチェック）
- EZ + Velociraptor（メモリ内 vs ディスク上）
よくある落とし穴
- トランザクションログを忘れない。
SYSTEM.LOG1/SYSTEM.LOG2には保留中の書き込みが入っています。なしで読むと古いハイブを見ていることに。EZ は自動で再生しますが、他のツールは必ずしもそうではありません。SYSTEM ハイブの取得を参照。 - ディスクとメモリの ShimCache を直接比較しない。 異なる真実の源です — ディスクは前回の正常シャットダウン時の状態、メモリは現セッション。補完関係であり、冗長ではありません。
- 実行と決めつけない。 どのパーサーもこれは直しません — キャッシュは「検査」を記録するもので、実行を記録するものではない。
さらに読む
- Eric Zimmerman の AppCompatCacheParser — リファレンス・パーサー。
- Mandiant の ShimCacheParser — オリジナル Python 実装。
- Velociraptor
Windows.Registry.AppCompatCache— VQL アーティファクト。 - Windows 10/11 AppCompatCache deep dive (Ø Security) — パーサーが食い違う理由の解説。