← Back to all posts

Inside MAM compression

A Windows XP .pf file opens at offset zero with the SCCA header. You read down from there and the format makes sense. Drop the same parser on a Windows 10 .pf and you get garbage. The reason is three ASCII bytes: MAM.

Anyone who has watched a Python script confidently report "version 7761" on a modern Prefetch file has met this problem. The script read MAM\x04 as the start of an SCCA header and treated M (0x4D) as the low byte of a u32.

The MAM framing

Starting with Windows 8, the OS compresses every Prefetch file before SysMain writes it to disk. The on-disk file begins with an eight-byte framing header:

offset  size  field
0       3     ASCII signature "MAM"
3       1     compression algorithm (0x04 = Xpress Huffman)
4       4     uncompressed payload size (u32 little-endian)
8       ..    compressed payload

The byte after MAM identifies which COMPRESSION_FORMAT_* algorithm was used. Microsoft defines five across the family. Prefetch only ever uses Xpress Huffman (0x04). The size field tells the decompressor exactly how large the output buffer needs to be — handy because the SCCA payload has no length field of its own at the same offset.

The frame is the same on Windows 8, 8.1, 10, and 11. Everything that has changed across versions lives inside the decompressed SCCA bytes, not in the MAM envelope.

Xpress Huffman in one paragraph

Xpress Huffman is a block-oriented LZ77 variant, specified as [MS-XCA] in Microsoft's open spec corpus. Each block opens with a 256-entry Huffman alphabet — one nibble per symbol — defining literal byte codes for 0..255 plus match-length codes. The encoded bitstream is decoded as Huffman codes; each symbol either emits a literal or signals a back-reference into the already-decompressed output. Not the fastest LZ variant ever shipped, but compact, deterministic, and good enough for files that are typically 30–100 KB.

The parser this site runs (frnsc-prefetch) carries a pure-Rust Xpress Huffman decoder so the whole pipeline can run inside a WebAssembly module without a native shell-out or the Windows-only RtlDecompressBufferEx API. The libscca C library does the same on the desktop side; PECmd uses the .NET implementation that ships with the framework.

Why it matters operationally

Anything that tries to read modern Prefetch without an Xpress Huffman decompressor in the pipeline will either crash, error politely, or — worst case — silently produce wrong output. The number of forensic write-ups still pinned to "tested on Windows 7" is not zero. I have read PDFs that confidently report a v0 SCCA payload because the author's Python script never made it past offset 4.

If your toolchain stops working when you collect Prefetch from a Win10/11 endpoint, the first thing to check is whether it actually handles MAM. Both PECmd and libscca (and its pyscca binding) do. The prefetchparser.py lineage of older Python parsers mostly does not, depending on which fork you grabbed.

The compression is the easy part

Once you have decompressed the payload, the SCCA-level differences between v17, v23, v26, v30, and v31 are what your parser actually needs to handle correctly. Eight execution timestamps appearing at v26, file-metric layout changes between v23 and v26, padding tweaks in v31 — those are where parsers diverge. The outer MAM frame has been a settled problem for a decade.

Further reading

  • Microsoft, [MS-XCA] Xpress Compression Algorithm specification — the canonical reference for the decoder.
  • Joachim Metz, libscca documentation — readable description of both the MAM frame and the SCCA payload underneath.
  • Maxim Suhanov, posts on Windows compression internals — useful when you need to debug a malformed block.