Où se trouve SRUDB.dat sous Windows ?

SRUDB.dat vit au même chemin sur chaque version Windows prise en charge depuis 8. C'est l'acquisition qui piège : le Diagnostic Policy Service détient un handle exclusif tant que le système tourne, et la moitié de l'activité récente se trouve dans les journaux de transactions plutôt que dans le fichier principal.

Le chemin

C:\Windows\System32\sru\SRUDB.dat

Plus tout le reste de ce répertoire :

C:\Windows\System32\sru\
  SRUDB.dat        # la base ESE
  SRU.log          # journal courant
  SRU0000xxxx.log  # journaux roulés
  SRU.chk          # fichier de checkpoint

Même chemin sur Windows 8, 8.1, 10, 11, et Server 2012 R2 et ultérieur.

Pourquoi vous avez besoin de tout le répertoire

ESE est un moteur à journal en écriture anticipée. Les transactions récentes vivent dans les fichiers SRU*.log jusqu'à ce que le moteur les flushe dans la base. Si vous prenez seulement SRUDB.dat, vous manquez :

• Les lignes validées dans la dernière heure ou deux d'activité.
• Le marqueur "clean shutdown" qui permet à un analyseur en lecture seule d'ouvrir le fichier sans avertissements.

Récupérez toute l'arborescence sru\. Prenez en même temps la ruche registre SOFTWARE : elle porte le mappage GUID-vers-SSID NetworkList\Profiles dont vous avez besoin pour afficher les noms de réseau dans Network Data Usage.

Acquérir le fichier

Le fichier est verrouillé pendant que DPS tourne. Options qui fonctionnent :

1. Image forensique (E01, raw, AFF4). La voie la plus propre. Montez en lecture seule, copiez le répertoire.

2. Volume Shadow Copy. Sous Windows 10 / 11 et Server 2016+, laissez esentutl créer l'instantané et en extraire le fichier, depuis une invite administrateur :

   esentutl /y C:\Windows\System32\sru\SRUDB.dat /vss /d C:\triage\SRUDB.dat
   

   Lancée depuis C:\Windows\System32\sru, esentutl /y SRUDB.dat /vssrec sru . /d C:\triage\clean\SRUDB.dat rejoue en plus les journaux dans l'instantané : la copie sort propre. N'utilisez pas vssadmin create shadow : cette commande n'existe que sur Windows Server. Sur un Windows client, l'autre moyen d'obtenir un instantané est WMI (méthode Create de Win32_ShadowCopy, par exemple depuis PowerShell), puis de copier depuis le périphérique \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\ créé. Dans les deux cas, l'instantané n'est pas bloqué par le verrou.

3. KAPE. La cible SRUM collecte le répertoire sru\ plus la ruche SOFTWARE en une seule commande.

4. Velociraptor. Collectez Windows.Triage.Targets avec la cible SRUM (anciennes versions : Windows.KapeFiles.Targets, cochez SRUM) pour extraire le même ensemble sur une flotte, via un hunt ou un collecteur hors ligne. Windows.Forensics.SRUM est un autre artefact : il analyse sur le poste et renvoie des lignes, pas le fichier de base.

5. FTK Imager / X-Ways / Magnet AXIOM Process. Les lectures disque direct contournent le verrou.

Copier SRUDB.dat depuis un hôte en direct sans VSS ne marche pas : le handle du fichier est en FILE_SHARE_READ | FILE_SHARE_WRITE refusé. Copy-Item PowerShell échouera. robocopy /B n'aide pas non plus : le mode sauvegarde (SeBackupPrivilege) contourne les ACL du fichier, pas le mode de partage d'un handle ouvert par un autre processus, et se heurte donc à la même violation de partage. Une copie issue d'un instantané, elle, est en général en Dirty Shutdown (la base était ouverte au moment de l'instantané) : prenez les journaux avec et rejouez-les, ou utilisez /vssrec.

Quand vous avez ouvert une base sale

esentutl /mh SRUDB.dat rapporte l'état. Tout autre que Clean Shutdown signifie que les journaux du même répertoire portent des transactions non validées :

esentutl /r sru /l <rep_log> /s <rep_checkpoint>

Lancez-la sur une copie, depuis le dossier qui contient le SRUDB.dat copié avec ses fichiers SRU*.log et SRU.chk (faites d'abord un cd vers ce dossier et pointez /l et /s dessus). Vérifiez ensuite avec esentutl /mh SRUDB.dat que la copie indique Clean Shutdown.

Voir comment réparer un SRUDB.dat corrompu pour la séquence complète.

Quand le fichier n'existe pas

• Windows 7 et antérieur. Pas de SRUM. Le service a été introduit dans Windows 8 / Server 2012.
• Images Windows allégées. Certains builds kiosque et d'entreprise verrouillés désactivent DPS. Le répertoire existe mais la base peut être vide ou rance.
• Builds serveur sur mesure avec télémétrie minimisée. Même histoire : SRUDB.dat vide. Vérifiez en regardant l'étendue de TimeStamp dans Application Resource Use ; une fenêtre d'une heure signifie que le service a été récemment réactivé.

Pour aller plus loin

• Qu'est-ce que SRUM et pourquoi cela intéresse les analystes forensiques
• Tables SRUM expliquées : AppResource, Network, Energy, Push
• Comment analyser SRUDB.dat sans rien installer
• Comment réparer un SRUDB.dat corrompu