← All posts

Memory dump file formats explained (.mem, .raw, .vmem, LiME)

4 min read

Memory forensics starts with acquisition, and the format of the resulting file determines what a tool can do with it. The short version: anything where physical address equals file offset is easy, and ramparser also reads a few structured containers natively (LiME, compressed AVML, 64-bit Windows crash dumps). Anything else (hibernation file, 32-bit crash dump, AFF4) needs a conversion pass first.

Raw / physical images — best supported

A raw physical memory image is a flat, byte-for-byte copy of RAM: physical address N is at file offset N. Every modern memory analyzer is built around this layout.

  • .mem / .raw / .bin — generic raw dumps from DumpIt, FTK Imager, Magnet RAM Capture (default mode), winpmem (--format=raw).
  • .vmem — a VMware guest's physical memory. Effectively raw. Pause the VM and grab the .vmem from the VM directory.
  • LiME (.lime) — Linux Memory Extractor format. Raw payload with small section headers; most analyzers read it directly. This is also what AVML writes by default.
  • Compressed AVML — avml --compress stores each block of up to 16 MiB as a Snappy stream behind an AVML header. ramparser decompresses the blocks on demand while it reads, so no avml convert pass is needed.

64-bit Windows crash dumps — supported natively

A Windows crash dump (MEMORY.DMP, or a .dmp written by DumpIt, WinDbg .dump /f, livekd or FTK Imager's crash-dump option) starts with a PAGEDU64 header. ramparser reads two of its layouts directly, no conversion needed:

  • Full dumps (DumpType 1) — physical memory stored as a table of runs; ramparser maps each run back to its physical address.
  • Bitmap dumps (DumpType 5, and 6 for live kernel dumps from Task Manager) — a summary header (FDMP or SDMP) at offset 0x2000 holds a per-page bitmap marking which physical pages are present; the pages follow densely packed. This is what Windows 8 and later write for BSOD complete, kernel and automatic memory dumps.

The header also hands over the kernel DTB, PsActiveProcessHead, PsLoadedModuleList and the bugcheck code. Keep in mind that kernel and automatic memory dumps only contain kernel pages, so user-mode data will be missing.

Not supported: 32-bit crash dumps (PAGEDUMP header), small memory dumps (minidumps), and the newer DumpTypes 0x8–0xA that recent WinDbg releases write for .dump /k, /ka and /f. These fall back to being read as raw, which gives wrong results — convert them first.

For pure analyzer compatibility, prefer raw. It is the lowest-common- denominator format and survives the longest in archive storage without needing tool-version pinning.

Formats that need conversion

  • 32-bit Windows crash dumps (.dmp with a PAGEDUMP header). Flatten to raw with Volatility 2's imagecopy. (64-bit crash dumps load directly, see above.)
  • Hibernation files (hiberfil.sys). Compressed, with a structured header that maps decompressed pages back to physical addresses. Comae's Hibr2Bin decompresses to raw.
  • VMware snapshots with separate descriptors. A .vmsn / .vmss references the .vmem. Point your tool at the .vmem; the descriptor is metadata.
  • Hyper-V .bin + .vsv. Similar split: .bin is the guest RAM. Some Hyper-V configurations compress; vol3 handles modern layouts directly.
  • AFF4 (.aff4). Container format used by winpmem. Few analyzers read it natively. Use aff4imager or winpmem's own export to convert to raw.

How ramparser detects the OS

Regardless of extension, ramparser fingerprints from content:

  • Windows — the kernel's CodeView/RSDS record (also the symbol key used to fetch the matching ntoskrnl PDB).
  • Linux — the Linux version banner string emitted by the kernel at boot.

If detection says unknown, the image is likely a compressed container, an encrypted dump, or an unsupported format (32-bit crash dump, hibernation file). Convert it to raw and retry.

Pagefile is not a memory dump

A common false start: trying to load pagefile.sys into a memory analyzer. The pagefile is on-disk swap, not a flat physical layout. It is useful — see the pagefile parser for what you can extract — but a memory analyzer will reject it. Same goes for swapfile.sys.

Rule of thumb

If you can dd it and physical offset equals file offset, ramparser can parse it — and so it can with LiME, AVML (compressed or not) and 64-bit Windows crash dumps. Anything else structured (32-bit crash dump, hibernation, AFF4) should be converted to raw first.

Further reading