Registry Parser
← All articles

How this Registry Parser actually parses your hives (and why nothing gets uploaded)

3 min read

Most online forensic tools want you to upload your evidence. For Windows registry hives that is a non-starter. SAM and SECURITY carry credential material; NTUSER.DAT carries user activity that is, depending on the case, attorney-client privileged. Handing those files to a third-party SaaS for "parsing" trades chain of custody for convenience.

This site does not do that. Every hive you drop is read in your browser, parsed in your browser, and discarded when you close the tab. Open the Network panel and watch: no requests leave the page after the worker boots. If you do not trust that claim, the source is shipped with the page.

The parsing engine, in two layers

The primary engine is hivex, the libguestfs registry library, compiled to WebAssembly. hivex has been the reference open-source REGF parser for over a decade; it is what virt-win-reg uses and what RegRipper uses under the hood on Linux. Compiling it to WASM means the registry hive is parsed by exactly the same code path as the canonical CLI, just instantiated in a Web Worker instead of a process.

If the WASM artifact is unreachable (for example, a strict CSP that blocks WebAssembly compilation, or a transient CDN failure), the tool falls back to a pure-JavaScript REGF parser. Both implement the same internal HiveSession interface, so the explorer and the artifact plugins behave identically regardless of which engine is loaded. You can verify which one is running from the diagnostics panel.

Hives supported

NTUSER.DAT, USRCLASS.DAT, SOFTWARE, SYSTEM, SAM, SECURITY, and Amcache.hve. The tool infers the hive type from the file name and routes the matching set of artifact plugins. If you load Amcache.hve, you get the Amcache-specific plugins; if you load SYSTEM, you get Shimcache, services, and the rest.

Transaction logs (.LOG1/.LOG2) get replayed when present. Drop them alongside the main hive. The first thing the worker does is reconcile any in-flight writes — same behavior as hivex on a CLI.

Chain of custody, written down

Because the parser is local and read-only, the original evidence file is never modified, never moved, and never leaves the analyst's workstation. The browser sandbox is the boundary. There is no temporary file written to disk; the hive lives in memory for the duration of the session.

For reports, the tool exports JSON, CSV, or Markdown with the artifact extractions, original file hash (SHA-256 computed at load), and the timestamp of the analysis. That hash is what goes into case notes. If you want a second pair of eyes, the same hash should reproduce the same output on any analyst's machine.

If you need to demonstrate to a court or to an internal reviewer that no upload occurred, the easiest evidence is a recorded screen capture of the Network panel during the analysis. No outbound requests, no exfil channel. The hive stays on your laptop.

Where this fits with the rest of the stack

This parser is one tool. For a complete Windows DFIR picture you usually also want the MFT, the USN journal, Prefetch, the AmCache, the Shimcache (which lives in SYSTEM and this parser already handles), and the Security event log. The sister sites use the same client-side approach. Drop, parse, never upload.

Further reading