TL;DR. Utilise l'AppCompatCacheParser d'Eric Zimmerman pour le casework. Plus large couverture OS, sortie CSV, bien éprouvé. Utilise Velociraptor pour le triage live à grande échelle. Utilise le Mandiant Shim Cache Parser quand une référence Python simple aide. Utilise cet outil quand tu veux zéro installation et zéro téléversement. Cross-valide les divergences. Le format est suffisamment pointilleux pour que deux parsers voient parfois les choses différemment.
Il y a quatre outils ouverts qui comptent pour le parsing ShimCache. Chacun a sa niche. L'erreur que je vois faire aux analystes juniors, c'est d'en choisir un et de le traiter comme la réponse pour chaque cas. La bonne réponse dépend de si tu mets à l'échelle, tu scriptes, ou tu fixes un seul hive à 2h du matin.
Les quatre parsers qui comptent
| Outil | Langage | Distribution | Idéal pour |
|---|---|---|---|
| Mandiant Shim Cache Parser | Python | Source sur GitHub | Lire le format, scripter de l'analyse sur mesure |
| Eric Zimmerman AppCompatCacheParser | C# / .NET | Binaire unique | Casework. Le plus fiable pour les rapports en production. |
Velociraptor Windows.Registry.AppCompatCache | VQL | Serveur Velociraptor | Collecte live à grande échelle |
| Shimcache Parser (cet outil) | Rust → WebAssembly | Navigateur uniquement, pas d'installation | Triage rapide sans setup, aucune donnée ne quitte la machine |
Lequel choisir quand
AppCompatCacheParser d'Eric Zimmerman
Le standard de facto pour l'analyse hors ligne. Couvre toutes les variantes Windows de XP à Windows 11, rejoue automatiquement les journaux de transactions SYSTEM, et produit un CSV qui rentre proprement dans Timeline Explorer. Si ta sortie part dans un rapport final, c'est ce que les relecteurs attendent que tu aies utilisé.
AppCompatCacheParser.exe -f SYSTEM --csv .
Bémols : binaire Windows-only, nécessite .NET Framework ou Core, pas conçu pour du triage ad-hoc dans le navigateur.
Velociraptor
Quand tu dois récupérer le ShimCache sur des dizaines ou des milliers d'hôtes, Velociraptor gagne. L'artefact lit le cache en mémoire directement depuis des endpoints en exécution, soit la même vue que l'OS aurait vidée à l'arrêt mais sans attendre l'arrêt. Voir extraire le ShimCache d'un dump mémoire pour la justification.
Bémols : nécessite une infrastructure Velociraptor. Surdimensionné pour de l'analyse ponctuelle.
Mandiant Shim Cache Parser
Le proof-of-concept Python d'origine. Moins fini que l'outil d'EZ mais utile quand tu veux lire le code pour comprendre exactement comment le format est décodé, ou pour scripter de l'analyse sur mesure autour. La sortie est en texte brut ; intègre-la à d'autres pipelines Python.
python ShimCacheParser.py -t -h /path/to/SYSTEM
Bémols : nécessite Python 2.x ou un fork de compatibilité. La sortie CSV / JSON est moins finie que celle d'EZ.
Ce Shimcache Parser
Existe pour deux cas que les autres ne couvrent pas bien :
- Triage sans installation. Ouvre la page, dépose un hive, vois les entrées. Utile quand tu es sur un hôte sans tooling DFIR installé, ou que tu analyses sur un portable ou une machine de prêt.
- Analyse sensible en confiance. Le hive est parsé entièrement dans ton navigateur via WebAssembly. Le fichier ne quitte jamais la page, n'arrive jamais sur un serveur, n'apparaît dans aucun log. Ça compte quand le hive appartient à un client ou à un dossier où le téléversement n'est pas acceptable.
Compromis : pas d'interface ligne de commande, pas de hooks d'automatisation. Utilise-le pour du triage piloté par un humain, pas pour des pipelines. Pour les pipelines, l'outil d'EZ est la bonne réponse.
Cross-validation quand les parsers divergent
Le format binaire est sans pitié. La référence de la disposition Windows 10/11 montre pourquoi un seul mauvais comptage d'offset peut casser tout le reste du blob. En pratique les parsers s'accordent généralement, mais des hives réels embarquent parfois des données légèrement hors spec, et les parsers divergent sur :
- Détection de bitness sur les hives Win7. L'en-tête ne dit pas sans ambiguïté x86 vs x64, alors les parsers choisissent heuristiquement. Deux outils qui produisent des chemins différents sur le même hive, c'est ton indice.
- Normalisation des chemins. Échappement des backslashes, casse des lettres de lecteur, marqueurs
\??\initiaux. Différents parsers normalisent différemment. - Entrées vides ou placeholder. Certains outils émettent des lignes vides pour les slots inutilisés ; d'autres les sautent.
Quand ça compte, lance deux parsers et fais un diff. Les combinaisons vers lesquelles je me tourne :
- EZ + cet outil pour un cross-check rapide.
- EZ + Mandiant pour un sanity check "Python vs C#".
- EZ + Velociraptor pour la comparaison "live en mémoire vs hive sur disque".
Pièges courants
- N'oublie pas les journaux de transactions.
SYSTEM.LOG1etSYSTEM.LOG2portent des écritures en attente ; sans eux tu lis un hive périmé. L'outil d'EZ les rejoue automatiquement. D'autres non. Voir acquérir un hive SYSTEM. - Ne compare pas directement le ShimCache sur disque et en mémoire. Ce sont deux sources de vérité différentes. Sur disque, seul l'état du dernier arrêt propre. En mémoire, la session courante. Traite-les comme complémentaires.
- N'assume pas une exécution. Aucun parser ne peut corriger cela. Le cache enregistre un examen, pas une exécution.
Lectures complémentaires
- AppCompatCacheParser d'Eric Zimmerman. parser de référence.
- Shim Cache Parser de Mandiant. implémentation Python d'origine.
- Velociraptor
Windows.Registry.AppCompatCache. artefact VQL. - Windows 10/11 AppCompatCache deep dive sur Ø Security. explique pourquoi les parsers divergent parfois.