Is it safe to analyze memory dumps online?
3 min read
A RAM image is the most sensitive artefact in a typical case. Cleartext passwords, Kerberos tickets, TLS session keys, bearer tokens, decrypted documents, in-memory PII — all there, sitting in process address space, waiting for anyone with access to grep them out. Shipping that file to a third-party SaaS is a real risk, and one that an internal-affairs review will rightfully challenge. ramparser is built so the question does not arise.
The privacy model in concrete terms
- The dump never leaves the device. You pick a local file. The
browser reads it in ranges via
FileReaderSyncinside a Web Worker. There is no upload endpoint for memory contents — not as policy, but as missing code. - Parsing is local WebAssembly. The forensic engine is Rust compiled to WASM and runs in your tab. No server-side analysis exists. The static page itself is delivered from a CDN; everything after that is local.
- Only a public build identifier is fetched. For symbol accuracy
on Windows, ramparser sends just the kernel PDB GUID and age (the
same identifier every machine on that Windows build advertises) to
a proxy that returns Microsoft's public
ntoskrnlPDB. No bytes of your dump are part of that request.
What is sent off the device, exactly
| Data | Leaves the browser? |
|---|---|
| Memory dump contents | Never |
| Process lists / plugin output | Never (rendered locally) |
| Kernel PDB GUID + age (public) | Yes — to fetch matching symbols |
The PDB identifier reveals only the OS build (e.g. a Windows 10 patch level). It is not specific to your machine, your case, or your user.
Good practice on top of the tool
The tool keeps the dump local. The rest of chain-of-custody discipline is still on you:
- Work from a copy, never the original evidence file.
- Hash the dump (SHA-256) before and after any handling. Record the hash in your case notes.
- Run ramparser on a trusted endpoint. A compromised analysis workstation still leaks via the browser's own process memory.
- For Windows symbol fetches in restricted environments, mirror the Microsoft public symbol server inside your DFIR network and proxy ramparser's PDB requests to it.
Why this matters in practice
Memory contains secrets that survive disk encryption. BitLocker keys sit in memory on a running host. SSH session keys, browser session cookies, OAuth tokens, the contents of any private chat window — all recoverable from RAM with the right plugins. A regulated environment (healthcare, finance, defence, government) cannot accept a workflow that uploads those bytes to a third party, regardless of TLS, vendor SOC2 status, or stated retention policy.
Local parsing removes the question entirely.