Comment analyser SRUDB.dat sans rien installer

Les analyseurs SRUM ne manquent pas. Le choix relève du flux de travail, pas de la capacité : tous les outils ci-dessous lisent les mêmes structures ESE et résolvent les mêmes jointures SruDbIdMapTable.

SrumECmd, ce que la plupart des équipes DFIR utilisent

Le SrumECmd d'Eric Zimmerman est la norme sur les postes d'analyse Windows. Il écrit un CSV par table, prêt pour Timeline Explorer :

SrumECmd.exe -f C:\evidence\SRUDB.dat -r C:\evidence\SOFTWARE --csv C:\output

-r pointe sur la ruche registre SOFTWARE pour que les GUID de profils réseau se résolvent en SSID conviviaux. Sans cela, vous obtenez des GUID bruts et devez pivoter manuellement par le registre.

Sortie :

• Application Resource Use (current + LT)
• Network Data Usage
• Network Connectivity
• Energy Usage (+ LT)
• Push Notifications
• Le IdMap résolu

Traitez un disque de preuves entier en un seul script batch et chargez les CSV dans Timeline Explorer ou votre SIEM.

srum-dump, l'option multiplateforme

L'outil Python de Mark Baggett. Écrit un XLSX avec une feuille par table.

pip install -r requirements.txt
python srum_dump.py --SRUM_INFILE SRUDB.dat --REG_HIVE SOFTWARE --OUT_DIR ./out

Le fork JSON de Willi Ballenthin convient mieux aux pipelines scriptés (pandas, jq). Les deux sont plus lents que SrumECmd sur des fichiers de plusieurs gigaoctets, plus rapides qu'attendre une VM Windows si vous vivez sous Linux/macOS.

Analyseur en navigateur

Déposez SRUDB.dat sur la page. L'analyse se fait entièrement côté client via WebAssembly ; rien n'est envoyé. Pour une base typique de 5 Mo, les résultats s'affichent en environ une seconde.

Ce que vous obtenez :

• Toutes les tables ESE énumérées avec leurs types de colonnes.
• Des onglets pour les tables SRUM connues (Application Resource Use, Network Data Usage, Network Connectivity, Energy Usage, Push Notifications).
• AppId et UserId résolus automatiquement contre SruDbIdMapTable.
• Colonnes FILETIME affichées en ISO-8601 ; dates OLE rendues correctement.

Utile lorsque la base source vient d'un environnement réglementé et que la téléverser vers un SaaS tiers n'est pas envisageable.

Choisir entre eux

• Un fichier, triage rapide → analyseur navigateur.
• Beaucoup de fichiers, reproductible en script → SrumECmd.
• Analyse personnalisée en pandas / jq → fork JSON srum-dump.
• Preuves sensibles qui ne peuvent franchir une frontière fournisseur → analyseur navigateur.

Pièges courants avant de faire confiance à la sortie d'un outil

1. Copier un fichier verrouillé. SRUDB.dat est verrouillé sur un système en direct. Voir où se trouve SRUDB.dat pour les options d'acquisition.
2. Base sale. Une copie depuis un hôte en direct est presque toujours sale. Les lignes les plus récentes vivent dans les fichiers SRU*.log. Voir comment réparer un SRUDB.dat corrompu.
3. Oublier la ruche SOFTWARE. Sans elle, les noms de profils réseau restent des GUID bruts. Le drapeau -r de SrumECmd et le --REG_HIVE de srum-dump acceptent le chemin de la ruche.
4. Lire uniquement la table court-terme. Application Resource Use capte environ 30 jours. La jumelle LT détient des agrégats hebdomadaires jusqu'à un an. Vérifiez toujours les deux, surtout pour les incidents de plus d'un mois.
5. Supposer que chaque horodatage est un FILETIME. Le TimeStamp de Application Resource Use est une date variante OLE. Les horodatages d'événement d'Energy et Network Connectivity sont des FILETIME. Les mélanger fait glisser les dates de 400 ans.

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
• Utiliser SRUM dans une investigation forensique
• Comment réparer un SRUDB.dat corrompu