How to parse SRUDB.dat without installing anything

There is no shortage of SRUM parsers. The choice is about your workflow, not about capability — every tool below reads the same ESE structures and resolves the same SruDbIdMapTable joins.

SrumECmd — what most DFIR shops actually run

Eric Zimmerman's SrumECmd is the standard on Windows analysis workstations. It writes one CSV per table, ready for Timeline Explorer:

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

-r points at the SOFTWARE registry hive so that network profile GUIDs resolve to friendly SSIDs. Without it, you get raw GUIDs and have to pivot through the registry manually.

Output:

• Application Resource Use (current + LT)
• Network Data Usage
• Network Connectivity
• Energy Usage (+ LT)
• Push Notifications
• The resolved IdMap

Process a whole evidence drive in a single batch script and pull the CSVs into Timeline Explorer or your SIEM.

srum-dump — the cross-platform option

Mark Baggett's Python tool. Writes an XLSX with one sheet per table.

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

Willi Ballenthin's JSON fork is a better fit for scripted pipelines (pandas, jq). Both are slower than SrumECmd on multi-gigabyte files, faster than waiting for a Windows VM if you live in Linux/macOS.

In-browser parser

Drop SRUDB.dat onto the page. Parsing happens entirely client-side via WebAssembly; nothing is uploaded. For a typical 5 MB database the results render in about a second.

What you get:

• All ESE tables enumerated with column types.
• Tabs for the well-known SRUM tables (Application Resource Use, Network Data Usage, Network Connectivity, Energy Usage, Push Notifications).
• AppId and UserId automatically resolved against SruDbIdMapTable.
• FILETIME columns rendered as ISO-8601; OLE dates rendered correctly.

Useful when the source database came from a regulated environment and uploading it to a third-party SaaS is not an option.

Picking between them

• One file, quick triage → browser parser.
• Many files, repeatable in a script → SrumECmd.
• Custom analysis in pandas / jq → srum-dump JSON fork.
• Sensitive evidence that cannot cross a vendor boundary → browser parser.

Common pitfalls before you trust any tool's output

1. Copying a locked file. SRUDB.dat is locked on a live system. See where is SRUDB.dat located for acquisition options.
2. Dirty database. A copy from a live host is almost always dirty. The most recent rows live in the SRU*.log files. See how to fix a dirty SRUDB.dat.
3. Forgetting the SOFTWARE hive. Without it, network profile names are raw GUIDs. SrumECmd's -r flag and srum-dump's --REG_HIVE accept the hive path.
4. Reading only the short-term table. Application Resource Use captures ~30 days. The LT sibling holds weekly aggregates for up to a year. Always check both, especially for incidents older than a month.
5. Assuming every timestamp is FILETIME. Application Resource Use TimeStamp is an OLE variant date. Energy and Network Connectivity event timestamps are FILETIMEs. Mixing them slips dates by 400 years.

Further reading

• What is SRUM and why forensic analysts care
• SRUM tables explained: AppResource, Network, Energy, Push
• Using SRUM in a forensic investigation
• How to fix a dirty SRUDB.dat