Comment réparer un SRUDB.dat corrompu (récupération de base ESE)

Presque chaque SRUDB.dat que vous copiez depuis un hôte en direct est sale. Le Diagnostic Policy Service écrit constamment ; vous imagez le volume en plein vidage ; le moteur n'a jamais eu l'occasion d'écrire son enregistrement d'arrêt propre. La solution est la récupération douce, rejouer les journaux dans la base, ce que Windows ferait lui-même au prochain démarrage si vous le laissiez tourner.

Pourquoi votre copie est sale

ESE est un moteur à journal en écriture anticipée. Les écritures atterrissent d'abord dans SRU*.log et sont ensuite reportées dans SRUDB.dat. Quand vous copiez le fichier :

• Depuis une machine en direct, même via VSS, le moteur était au milieu d'un cycle d'écriture.
• Depuis une image forensique, le système tournait au démarrage de l'imagerie.

esentutl /mh SRUDB.dat indique l'état :

State: Dirty Shutdown
Log Required: 1-2 (0xN-0xM)

Un analyseur en lecture seule ouvert contre ce fichier refusera soit l'en-tête, soit sautera silencieusement les pages nécessitant un rejeu. Dans les deux cas, les lignes les plus fraîches (et souvent les plus intéressantes) manquent.

Récupération douce avec esentutl

esentutl.exe est livré avec chaque installation Windows. Travaillez toujours sur une copie de la preuve, jamais l'original :

mkdir C:\work\sru
copy "E:\image\Windows\System32\sru\*" C:\work\sru\
cd C:\work\sru
esentutl /r sru /l C:\work\sru /s C:\work\sru

Les drapeaux :

• /r sru : nom de base des journaux sru (SRU.log, SRU00001.log, …).
• /l : répertoire contenant les fichiers journaux.
• /s : répertoire contenant le checkpoint (SRU.chk).

Gardez le SRUDB.dat copié, les fichiers SRU*.log et SRU.chk ensemble dans un même dossier, et lancez la commande depuis ce dossier comme ci-dessus (le cd compte) : vous rejouez une copie qui n'est plus dans C:\Windows\System32\sru\, où les journaux ont été écrits.

Après exécution :

esentutl /mh SRUDB.dat

…doit rapporter State: Clean Shutdown. Tout analyseur, SrumECmd, srum-dump, le moteur ESE directement, ou l'analyseur en navigateur, lit désormais chaque ligne y compris celles fraîchement rejouées.

Ce que la récupération douce ne fait pas

La récupération douce n'est pas une réparation. Elle applique les transactions que le moteur a déjà écrites dans le journal. Elle ne peut pas :

• Récupérer des lignes antérieures au plus ancien fichier journal. ESE élague les vieux journaux ; si vous n'avez que la base et le journal le plus récent, tout ce qui est plus ancien que la couverture de ce journal est définitivement hors de portée de SRUM.
• Réparer une corruption structurelle dans le fichier de la base. Pour cela, il faut la réparation dure, qui est destructive.

Quand les journaux manquent

Si vous n'avez que SRUDB.dat et aucun journal, la récupération douce est impossible. La réparation dure est le dernier recours :

esentutl /p SRUDB.dat

/p reconstruit la base et peut écarter des lignes irrécupérables. Ne l'utilisez que sans alternative, et notez-le explicitement dans votre rapport. La sortie n'est plus une copie fidèle de la preuve originale.

La leçon pour l'acquisition

Presque chaque plainte "SRUM manque la dernière semaine" est en réalité une histoire de base sale. Prévenez à la collecte :

• Récupérez l'intégralité du répertoire C:\Windows\System32\sru\, pas seulement SRUDB.dat.
• Utilisez la cible SRUM de KAPE ou, dans Velociraptor, Windows.Triage.Targets avec la cible SRUM (Windows.KapeFiles.Targets sur les anciennes versions) : tous deux extraient les journaux et le checkpoint automatiquement. Windows.Forensics.SRUM ne les remplace pas : il analyse sur le poste et renvoie des lignes, pas la base.
• Récupérez la ruche registre SOFTWARE en même temps pour résoudre les GUID de profils réseau.

Voir où se trouve SRUDB.dat pour les conseils complets d'acquisition.

Documenter la récupération

Pour la chaîne de possession, consignez :

• Chemin du fichier d'origine sur l'image source, SHA-256 de la copie sale.
• Sortie esentutl /mh avant et après récupération (collez les deux).
• La ligne de commande exacte utilisée.
• SHA-256 de la base récupérée.

Une défense contestera la récupération si elle n'est pas documentée. Un /r documenté est une opération ESE standard, acceptée par tout tribunal ayant entendu un témoignage SRUM.

Pour aller plus loin

• Le format de base ESE qui propulse SRUDB.dat
• Où se trouve SRUDB.dat sous Windows ?
• Comment analyser SRUDB.dat sans rien installer