TL;DR. Le ShimCache se trouve à HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. Windows le reconstruit en mémoire à chaque session et ne le flushe dans la ruche SYSTEM qu'à l'arrêt propre — un reboot dur peut perdre entièrement les entrées récentes. N'oubliez pas de rejouer SYSTEM.LOG1 / SYSTEM.LOG2.
Beaucoup de mésaventures avec le ShimCache remontent à un seul malentendu : les enquêteurs supposent que le cache est mis à jour comme un fichier journal, avec des entrées écrites sur le disque au fil de l'eau. Ce n'est pas le cas. Voici exactement où vit le ShimCache et quand Windows y écrit.
Le chemin dans le registre
Le ShimCache se trouve dans la ruche SYSTEM, à :
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache
Ce dernier AppCompatCache est une valeur, pas une sous-clé. Sa donnée est un blob binaire unique dont le schéma varie selon la version de Windows — XP, 7, 8, 8.1, 10 et 11 utilisent chacune une mise en page légèrement différente. La présentation du format binaire détaille le schéma moderne Windows 10/11.
Vous pouvez lire la même valeur hors ligne en extrayant la ruche SYSTEM — c'est l'un des fichiers sous C:\Windows\System32\config\ — et en y dirigeant un parser. Le Shimcache Parser fait exactement cela, dans votre navigateur, sans uploader le fichier où que ce soit.
L'astuce du ControlSet « courant »
Windows maintient en réalité plusieurs ControlSets (ControlSet001, ControlSet002, parfois davantage). À chaque instant, un seul est l'ensemble actif, indiqué par la valeur HKLM\SYSTEM\Select\Current. CurrentControlSet est un alias d'exécution vers celui qui est actif.
Lors d'une analyse hors ligne, il faut :
- lire
HKLM\SYSTEM\Select\Current(un DWORD, typiquement 1 ou 2), - parcourir la valeur
ControlSetXXX\Control\Session Manager\AppCompatCache\AppCompatCachecorrespondante, - tomber en repli sur
ControlSet001puisControlSet002siSelect\Currentn'est pas lisible.
La plupart des parsers — y compris cet outil — gèrent cela automatiquement.
Quand le cache est écrit
Voici la partie qui surprend : pendant que le système tourne, le ShimCache vit en mémoire. Windows ne le déverse dans la ruche SYSTEM qu'à l'arrêt propre. Donc :
- Un redémarrage à froid, une coupure de courant, un BSOD ou un kill de VM au niveau hyperviseur perdra toutes les entrées récentes non encore persistées.
- Une triage à chaud d'un système en marche via
reg.exeou RegRipper voit le ShimCache précédemment persisté, pas celui en cours de construction en mémoire. - L'analyse mémoire (p. ex. le plugin Volatility
shimcachemem) peut récupérer le cache courant en mémoire avant sa perte.
C'est cette temporisation qui fait que l'analyse dead-box d'une ruche manque souvent l'activité la plus récente, et pourquoi les enquêteurs se tournent vers AmCache (qui écrit en continu — voir ShimCache vs AmCache) pour combler le vide.
Qu'en est-il du journal de transactions du registre ?
La ruche SYSTEM est accompagnée de fichiers de journal de transactions (SYSTEM.LOG1, SYSTEM.LOG2). Ils peuvent contenir des écritures non flushées qui n'ont jamais atteint la ruche principale. Les parsers hors ligne robustes rejouent ces journaux avant de lire le ShimCache ; si vous codez votre propre analyse, prenez-les en compte ou utilisez un parser qui le fait.
Check-list express
- Valeur ShimCache :
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache - ControlSet actif sélectionné par
HKLM\SYSTEM\Select\Current - Stocké en mémoire, flushé uniquement à l'arrêt propre — corroborer avec AmCache pour l'activité récente
- Rejouer les journaux
SYSTEM.LOG*avant l'analyse pour un état à jour
Pour aller plus loin
- Microsoft Learn — Registry hives — la référence canonique sur les fichiers de ruche et les ControlSets.
- ShimCacheParser de Mandiant — le parser Python original, utile comme référence de format.
- Velociraptor
Windows.Registry.AppCompatCache— logique de collecte sur système vivant.