TL;DR. Utilisez AppCompatCacheParser d'Eric Zimmerman pour les dossiers — la plus large couverture OS, sortie CSV, éprouvé. Utilisez Velociraptor pour le triage en direct à l'échelle. Utilisez ShimCacheParser de Mandiant quand une référence Python simple aide. Utilisez cet outil quand vous voulez zéro installation et zéro upload — triage rapide dans le navigateur. Croisez les résultats en cas de désaccord ; le format est suffisamment finicky pour que deux parsers voient parfois les choses différemment.
Les quatre parsers qui comptent
| Outil | Langage | Distribution | Idéal pour |
|---|---|---|---|
| Mandiant ShimCacheParser | Python | Source sur GitHub | Lire le format, scripter des analyses sur mesure |
| Eric Zimmerman AppCompatCacheParser | C# / .NET | Binaire unique | Travail de dossier — le plus fiable pour les rapports |
Velociraptor Windows.Registry.AppCompatCache | VQL | Serveur Velociraptor | Collecte en direct à l'échelle d'un parc |
| Shimcache Parser (cet outil) | Rust → WebAssembly | Navigateur uniquement, sans installation | Triage rapide sans setup, aucune donnée ne quitte la machine |
Quand utiliser lequel
AppCompatCacheParser d'Eric Zimmerman (le défaut pour les dossiers)
Le parser C# d'EZ est le standard de fait pour l'analyse hors ligne. Il couvre toutes les versions Windows de XP à 11, rejoue automatiquement les journaux de transaction SYSTEM, et sort du CSV qui s'intègre proprement à Timeline Explorer. Si votre sortie va dans un rapport final, c'est ce que les relecteurs attendront.
AppCompatCacheParser.exe -f SYSTEM --csv .
Limites : binaire Windows uniquement ; nécessite .NET Framework / Core ; peu adapté au triage ad-hoc dans le navigateur.
Velociraptor Windows.Registry.AppCompatCache (collecte à l'échelle)
Quand il faut extraire le ShimCache de dizaines ou de milliers d'hôtes, Velociraptor gagne. L'artefact lit le cache en mémoire directement depuis les endpoints en marche — la même vue que l'OS aurait flushée à l'arrêt, mais sans attendre l'arrêt. Voir Extraire le ShimCache depuis un dump mémoire pour la rationale.
Limites : nécessite l'infrastructure Velociraptor. Surdimensionné pour de l'analyse one-shot.
ShimCacheParser de Mandiant (la référence du format)
Le proof-of-concept Python original. Moins poli que l'outil d'EZ mais utile quand on veut lire le code pour comprendre exactement comment le format est décodé, ou pour scripter une analyse personnalisée autour. Sortie texte simple ; à intégrer dans d'autres pipelines Python.
python ShimCacheParser.py -t -h /chemin/vers/SYSTEM
Limites : nécessite Python 2.x (ou un fork de compatibilité) ; sortie CSV / JSON moins polie que celle d'EZ.
Ce Shimcache Parser (sans installation, sans upload)
Cet outil existe pour deux cas que les autres ne couvrent pas bien :
- Triage sans installation : ouvrir la page, déposer une ruche, voir les entrées. Pratique sur un hôte sans outillage DFIR installé, ou pour analyser sur un laptop / prêt.
- Analyse sensible à la confidentialité : la ruche est analysée entièrement dans votre navigateur via WebAssembly. Le fichier ne quitte jamais la page, n'atteint aucun serveur, n'apparaît dans aucun log. C'est important quand la ruche appartient à un client / un dossier où l'upload n'est pas acceptable.
Compromis : pas d'interface en ligne de commande, pas d'export CSV (pas encore), pas de crochets d'automatisation. À utiliser pour du triage piloté par un humain, pas pour des pipelines. Pour les pipelines, l'outil d'EZ est la bonne réponse.
Croisement : quand deux parsers ne sont pas d'accord
Le format binaire du ShimCache est intransigeant — la référence du format Windows 10/11 montre pourquoi un seul décalage d'offset peut casser toute la suite. En pratique, les parsers sont généralement d'accord, mais les ruches réelles peuvent être légèrement hors spec, et les parsers divergent sur :
- Détection de bitness sur les ruches Win7 — l'en-tête ne dit pas explicitement « x86 vs x64 », les parsers choisissent heuristiquement. Deux outils produisant des chemins différents sur la même ruche sont votre signal.
- Normalisation des chemins — échappement des backslashes, casse des lettres de lecteur, préfixes
\??\. Les parsers normalisent différemment. - Entrées vides / placeholders — certains émettent des lignes vides pour les slots inutilisés, d'autres les ignorent.
Quand ça compte, lancez deux parsers et diff. Les combinaisons que je privilégie :
- EZ + cet outil pour un contrôle rapide
- EZ + Mandiant pour une vérification « Python vs C# »
- EZ + Velociraptor pour comparer « mémoire vive vs ruche sur disque »
Pièges fréquents
- N'oubliez pas les journaux de transaction.
SYSTEM.LOG1/SYSTEM.LOG2portent les écritures en attente ; sans eux, vous lisez une ruche périmée. L'outil d'EZ les rejoue automatiquement, d'autres non. Voir Acquérir une ruche SYSTEM. - Ne comparez pas directement ShimCache sur disque et en mémoire. Ce sont des sources de vérité différentes — sur disque, seule la dernière vue propre ; en mémoire, la session courante. Complémentaires, pas redondants.
- N'assumez pas l'exécution. Aucun parser ne corrige cela — le cache enregistre l'examen, pas l'exécution.
Pour aller plus loin
- AppCompatCacheParser d'Eric Zimmerman — parser de référence.
- ShimCacheParser de Mandiant — implémentation Python originale.
- Velociraptor
Windows.Registry.AppCompatCache— artefact VQL. - Windows 10/11 AppCompatCache deep dive (Ø Security) — explique pourquoi les parsers divergent parfois.