← All posts

How to analyze a RAM dump in your browser

2 min read

You have a MemoryDump.mem and you want a process list now, without installing Python, Volatility, or symbol packs. The workflow below takes about a minute end-to-end on a typical desktop dump.

The workflow

  1. Open the analyzer. Static web page; nothing is installed.
  2. Select your dump. Click Select a RAM dump and choose the image (.mem, .raw, .vmem, .lime, .bin). It stays on the device.
  3. Wait for detection. ramparser streams through the image, fingerprints the OS from content (kernel CodeView for Windows, Linux version banner for Linux), and on Windows fetches the matching public ntoskrnl PDB.
  4. Read the results. Every applicable plugin renders its own table: pslist, psscan, psxview, pstree, cmdline, dlllist, modules, netscan. On Linux, taskscan runs as well.

What is happening under the hood

  • The dump is read in 4 KiB pages via FileReaderSync inside a Web Worker. A 32 GB image is processed without ever holding all of it in memory.
  • The OS is detected from content, not the extension. Crash dumps (.dmp) and hibernation files are not flat physical layouts and will fail detection — convert them first; see memory dump file formats.
  • For Windows, _EPROCESS offsets come from the official ntoskrnl PDB, so the process list is symbol-accurate per build.

Tips for real cases

  • Large dumps are fine. Scanning is linear; a 64 GB host takes longer but completes. Keep the tab focused for best throughput.
  • Raw / physical images work best. A VMware .vmem is already raw and parses directly. Compressed AVML output needs decompression first.
  • Symbols, not bytes, are fetched. Only the kernel PDB GUID + age (a public identifier shared by every machine on that Windows build) is sent. No dump contents leave the device. See is it safe to analyze memory dumps online.

When triage flags something

ramparser is the front-end. When triage points at a real lead — a DKOM-hidden process, an outbound connection to known C2, a shell spawned from winword.exe — move to Volatility 3 for the deep dive (malfind, yarascan, timeliner, kernel callbacks). The memory analysis workflow covers the handoff.

Further reading