How pagefile.sys forensics actually works

There is no documented binary format for pagefile.sys. Microsoft does not publish a layout because there is no layout to publish. The file is whatever the Memory Manager wrote into the free slots at the time. Every tool that analyses it, page_brute, bulk_extractor, photorec, scalpel, X-Ways, Magnet Axiom, this one, falls back to the same family of techniques. This post is the practitioner's view of what those techniques are and what they are good for.

1. Per-page signature carving

The file is split into 4 KB pages and each page is matched against a catalog of file-format signatures. The magic bytes that consistently pay back the time:

Signature	What it tells you
`MZ ... PE\0\0`	An executable image was paged out
`regf`	Registry hive base block (SECURITY, SAM, NTUSER.DAT)
`hbin`	Hive bin, a 4 KB chunk of a hive
`FILE` / `BAAD`	NTFS MFT record, active or damaged
`SQLite format 3`	SQLite database header (browser history, mail clients)
`<?xml`	XML, often EVTX templates, manifests, configs
`ElfFile` / `ElfChnk`	EVTX event log file / chunk
`SCCA`	Prefetch file
`%PDF`	PDF
`PK\x03\x04`	ZIP / DOCX / XLSX
`\x89PNG` / `\xFF\xD8\xFF`	PNG / JPEG

A page that matches a signature usually represents the start of a larger artifact. The rest of that artifact lives elsewhere in RAM, paged to non-adjacent slots, or never paged out at all. A single hit is a lead, not a recoverable file. bulk_extractor will reliably surface every PE header it finds. It will not reassemble the binary.

2. String extraction

Most of the value in a pagefile is in strings. Software was working with text when it got swapped out. The extraction is conceptually GNU strings:

ASCII: contiguous runs of printable bytes (0x20 to 0x7E plus tab) of length 6 or more.
UTF-16LE: contiguous runs of (printable, 0x00) pairs. Windows is Unicode-first internally so most useful text is here. Skipping UTF-16LE is the most common rookie mistake in roll-your-own pagefile tooling.

Each emitted string gets paired with its absolute file offset so you can correlate it back to the page it came from. If you keep that offset, you can pivot from a string hit to its neighbours, which often surfaces the rest of the same allocation.

3. Regex artifact sweeps

The strings feed a fixed catalog of regexes:

URLs: https?://....
Email addresses, IPv4, IPv6.
Windows paths (C:\...) and UNC paths (\\server\share\...).
Registry keys (HKLM\..., HKCU\...).
GUIDs (a strong indicator near MSI installers, COM, event tracing).
Command-line indicators: cmd.exe, powershell.exe, mshta.exe, rundll32.exe, certutil.exe. See malware command lines.
Credentials: password=, Authorization: Bearer ..., JWT-shaped tokens. See finding credentials.

These are the patterns that have historically yielded most of the actionable signal in pagefile triage. They will not catch novel tradecraft. They will catch the 90% case fast.

4. Statistical fallback

For pages that match no signature and have low string density, basic statistics help you decide what kind of content it was:

Shannon entropy above ~7.5: likely encrypted, compressed, or encoded. On Windows 10+ this usually means a page that CompressionStoreManager wrote with Xpress-Huffman before flushing. See the limitations post.
High proportion of null bytes: unused or scrubbed slot.
High proportion of printable bytes: text-heavy content that did not trip a signature.

The histogram alone tells you where to spend your manual time. A pagefile that is 80% high-entropy after Windows 10's compression rollout looks different from one that is 60% printable ASCII because the host had plenty of RAM.

What you cannot do

Standalone pagefile analysis cannot tell you which process owned a given page, which virtual address it was at, or what kind of allocation (heap, stack, mapped file) it was. That needs a corresponding RAM dump and PTE parsing, which is what Volatility and MemProcFS do. See the Volatility + pagefile workflow. The pagefile alone gives you content, not context.