← Back to all posts

How the Windows Prefetch hash is calculated

Every prefetch file in C:\Windows\Prefetch\ is named like NOTEPAD.EXE-1B4A5887.pf. The eight hex characters at the end are not a checksum of the file contents — they are a hash of the full path to the executable, encoded as UTF-16. Two copies of notepad.exe launched from C:\Windows\System32\ and C:\Users\analyst\notepad.exe produce two different .pf files because their paths differ, even though the binary is byte-identical.

Three algorithms, three eras

The hash function changed alongside Windows itself:

  • Windows XP / Server 2003 — the original SuperFetch hash, a simple rolling computation over the UTF-16 path string.
  • Windows Vista / 2008 — same family but with a different constant multiplier and a different starting seed. Vista-era prefetch files cannot be re-derived with the XP function and vice versa.
  • Windows 7 onwards — "Hash function 5" in Microsoft parlance, still used by Windows 10 and 11. It folds groups of bytes from the UTF-16 path through a multiply-and-XOR loop and masks the result to 32 bits, then truncates to the lower 32 bits of the prefetch filename suffix.

The path string fed into all three algorithms includes a \DEVICE\HARDDISK prefix and the file path encoded in upper-case UTF-16 (LE), with a few quirks around volume formats and command-line arguments on later versions of Windows.

Why this matters for an investigator

A planted prefetch file is one of the easier anti-forensic tricks. If you suspect manipulation, recompute the expected hash for the executable path and compare it to the filename. A mismatch is a strong signal that the .pf file did not originate on this system — either it was copied in from another machine or hand-crafted by a sloppy attacker.

The corollary: when an executable lives in an unusual path (a profile directory, a temp folder, a USB volume letter), the hash is the most direct evidence of where it ran from. The path itself is no longer present inside the prefetch payload — only the volume serial — so the hash is often the only surviving trace of the precise launch location.

Implementation notes

Open-source implementations of all three hash functions live in libyal's libscca documentation and in the frnsc-prefetch Rust crate that powers this tool. If you are scripting a forensic pipeline, the Vista and Win 7+ functions are short enough to inline — about a dozen lines each — without pulling in a dependency.

This parser does not verify the hash by default; it surfaces the value parsed from the filename so you can cross-check it manually. A future update will optionally flag mismatches against the parsed executable path.