srum-dump: Turning the Windows SRUM Database Into a Spreadsheet

What the SRUM database records, and why it matters

SRUM-DUMP extracts data from the System Resource Utilization Management database and generates an Excel spreadsheet. The tool is described as invaluable for forensic investigations, because SRUM maintains records of applications that have run on a system within the last 30 days. That last clause is the whole reason the artefact is useful in an investigation. On a running Windows machine, the system already keeps a rolling record of what ran, with resource usage figures, and that record is not something a user can easily switch off or inspect. A tool that turns it into a table of application names, with timestamps, converts a binary file that an examiner would otherwise have to parse by hand into something that can be read, filtered and put in a report.

The feature set, and the configuration step that defines the search

The features list is compact. It extracts and analyses data from SRUDB.DAT, generates an Excel report for easy analysis, supports additional enrichment using the SOFTWARE registry hive, generates a configuration file after the initial analysis is done, lets you edit that config file to indicate dirty words and other elements of investigation, and provides the configuration file for fine-tuned extraction. The config step is the part that turns the tool from a dumper into an investigation instrument. The first pass tells you what is in the database, and the config file then narrows the output to what matters for the case, with the dirty words acting as search terms. The `configuration_file.md` file in the repository documents that file, and the workflow is designed so the examiner reads the results once before deciding what to extract.

Running the prebuilt GUI, step by step

A prebuilt version is available for download in the releases section, and the GUI path is a numbered list. You launch the executable, select an empty output directory where the working files and results will be stored, and select the SRUDB.DAT file, which is required. If you are selecting it from the live path C:\Windows\System32\sru\srudb.dat on a running system, administrative privileges are required. Optionally you select the SOFTWARE registry hive, which provides useful additional context and can be left blank if unavailable. You then confirm the configuration, editing the config file to fine-tune the analysis, and click CONFIRM to proceed. A progress dialog appears during the run, with the Close button disabled until the process completes, and the resulting files are in the output directory you chose.

The command line, and the two parsing engines

The CLI takes the same arguments as the GUI and is what you want for automated processing, and the help output lists the options. The input file is given with --SRUM_INFILE, the working directory with --OUT_DIR, the registry hive with --REG_HIVE, and the output format with --OUTPUT_FORMAT, which takes xls or csv and defaults to xls.

.\srum_dump.exe -h
usage: srum_dump.exe [-h] [--SRUM_INFILE SRUM_INFILE] [--OUT_DIR OUT_DIR] [--REG_HIVE REG_HIVE] [--ESE_ENGINE {pyesedb,dissect}]
                     [--OUTPUT_FORMAT {xls,csv}] [--DEBUG] [--NO_CONFIRM]

The --ESE_ENGINE option is the interesting one, because it names two independent parsers for the same ESE database, pyesedb and dissect, and the help text explains the reason plainly: corrupt file, try a different engine to see if it does better. A database that has been damaged by a crash or by tampering is common in the cases this tool is used for, and having a second parser is what stops one bad file from ending the investigation. The --NO_CONFIRM flag skips the dialog, and --DEBUG turns on verbose logging to srum_dump.log.

The registry hive and what enrichment adds

The --REG_HIVE option takes the SOFTWARE registry hive, and the help text says that if it is provided then the names of the network profiles will be resolved. That is a more specific claim than the general wording elsewhere in the readme, which says the file provides useful additional context, and it points at what the hive is actually for. The SOFTWARE hive holds the applications that have been installed, so matching an executable recorded in the SRUM tables against the install records turns an opaque path into something a reader can interpret, and it lets the tool attribute activity to a specific network profile. The readme also states plainly that if the hive is unavailable you leave the field blank, so the tool has to work without it, which is a reasonable requirement since acquiring the hive means the same administrative access as the database itself.

Building from source, and the Windows-only dependency

The project requires Python 3.12, and the source route is a clone of the version3 branch plus a requirements install.

git clone --branch version3 https://github.com/markbaggett/srum-dump.git
cd srum-dump
pip install -r requirements.txt

The requirements list shows the platform constraint more clearly than the prose does. Besides openpyxl, dissect.esedb, python-registry, pywin32 and PyYAML, there is a wheel for the libesedb binary, srum-dump/libesedb_python-20240420-cp312-cp312-win_amd64.whl, and the filename says it plainly: a CPython 3.12 Windows x86-64 binary. That is the precompiled libesedb from the log2timeline project, and it makes the tool Windows only in practice, since the alternative engine, dissect, is pure Python but the packaged path is not. The two ESE engines therefore serve two different purposes, one being a faster native parser and the other the portable fallback.

The dependency set, and what each library contributes

The dependencies divide cleanly by function. ESE database access comes from Dissect, used for structured parsing, and from pylibesedb, which supplies the precompiled binaries from the log2timeline project. XLS output comes from XLSXWriter in the prose and openpyxl in the requirements file, and registry access comes from python-registry to extract registry data. The pairing of two ESE parsers with a registry reader and a spreadsheet writer is a compact dependency list for a tool that touches a proprietary binary format, a proprietary registry format and a proprietary output format, and the fact that each is an established project rather than something written here is what makes the tool auditable. The project metadata gives the version as 3.2.0 with setuptools and wheel as the build backend, and the package name is SRUM-DUMP.

Licence, releases and how to use it in a case

The project is released under the GNU GPL, and the author welcomes contributions, asking that features and fixes follow best practices and be tested before submission. The release record shows v3.0 in April 2025 followed by v3.1 and v3.2 in June 2025, and the last push was on 2026-07-28, so the code is being maintained even though the tagged releases are not recent. The repository is small and flat, with the srum-dump/ package, tests inside it, a configuration_file.md, a pyproject.toml, a requirements.txt and a demo gif. The practical sequence in a case is the one the documentation describes: acquire SRUDB.DAT and, if possible, the SOFTWARE hive, run the first pass into a working directory, read the generated configuration file and set the dirty words for the case, then run again and work through the spreadsheet. Running the tool against a copy rather than the original is the habit that keeps the evidence intact.

Editorial conclusion

srum-dump fits an incident responder or digital forensics analyst who needs to know which applications ran on a Windows machine in the last month, and who wants the result in a spreadsheet rather than in raw tables. It is the wrong tool if you need a live response, since the database is read from a file and the tool is not designed for triage while the system is running, and the wrong tool off Windows, since the bundled binary is Windows only. Before you run it, copy the sru database and the SOFTWARE hive to a working directory and review the generated configuration file before confirming the run.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. MarkBaggett/srum-dump on GitHub
4. README
5. Releases