Windows Prefetch File (old blog entry from 42 LLC)

The Windows prefetch file (.pf) has long been recognized as a useful artifact in the forensic community. It has been commented upon by several experts like Harlan Carvey, and there are a few utilities available to parse out pf files. However, all of the utilities and blogs I have seen only reference two artifacts from the PF files:

1. Program last execution date

2. Number of executions.

But there is more to it, a lot more! It keeps track of files opened by the program in the first 10 seconds of running, which I have found to be immensely useful in Incident Response cases. If you look at the pf file for MSWord or Notepad under a hex editor, you are most likely going to find the path of the last .doc or .txt file that was double-clicked to open it.

I decided to take a closer look at the file format and see if there was yet more forensically useful information that could be gained from it.

The PF file also records volume information, the volume serial number, DOS Fullpath and timestamp of volume creation. This is stored for all the volumes that are referenced by the application (during the time monitored). I have already used this to find serial numbers of external thumb drives used to launch applications or native applications that opened files on external media, whose remnants were left behind in .pf files.

Before we get to that, here are some basic facts about prefetch files.

Pf files are created by the “Task Scheduler” service (which runs under svchost) and are stored under “\\Prefetch” folder. It is used to record frequently used memory pages by applications. The first 10 seconds of an application”s run are monitored (by windows cache manager) and this information is written out to a pf file. Inside the pf file for a particular app, which will be named “application.extension-HASH.pf”, you will see several paths to files that were read by the application in its first 10 seconds. The HASH is a 32 bit number, represented in hex and looks like “19B4A02D”. This hash is calculated from the fullpath of the application which will be of the form:

\\DEVICE\\HARDDISKVOLUME1\\WINDOWS\\SYSTEM32\\NOTEPAD.EXE

The hash computation does not include the command line to the application as part of the path, however there is an exception to this. If “/prefetch:%i” is used in the command line, then this special flag is included for hash computation. Here %i can be any number 1, 2, 3 ,… The only purpose of this switch in the command line is to ensure a different hash generation, so now a single application can have multiple pf files. As of now, we do not know the hash algorithm, but its on my list of things to do.

I will comment more on the PF file and its format in a later blog. For now, here are the most relevant parts for forensic examiners, skipping out the known and obvious :

Windows XP Prefetch header offsets

0×64 – Offset to Block containing Filepaths (DWORD)

0×68 – Length of Block containing Filepaths (DWORD)

0x6C – Offset to Volume Information Block (DWORD)

0×78 – Program Last Execution Time (FILETIME)

0×90 – Number of Executions (DWORD)

Windows Vista (and Windows 7) Prefetch header offsets

0×64 – Offset to Block containing Filepaths (DWORD)

0×68 – Length of Block containing Filepaths (DWORD)

0x6C – Offset to Volume Information Blocks (DWORD)

0×80 – Program Last Execution Time (FILETIME)

0×98 – Number of Executions (DWORD)

The “Block of Filepaths” contains Unicode strings and can easily be read and parsed out.

The Volume Information Blocks have the following format.

0×00 – Volume Path Offset (DWORD)

0×04 – Volume Path Length (DWORD)

0×08 – Volume Creation Date (FILETIME)

0×10 – Volume Serial Number (DWORD)

0×14 – Offset To Blob1 (DWORD)

0×18 – Length of Blob1 (DWORD)

0x1C – Offset To Folder-paths (DWORD)

0×20 – Number of Folder-paths (DWORD)

0×24 – Unknown (DWORD)

There can be more than one Volume Information Blocks present. The volume path offset is the offset to full physical path (DOS path) of the volume. Volume created date is populated for NTFS volumes and is blank for FAT volumes. The serial number is always recorded.

The volume path (DOS path) will look something like this:

“\\DEVICE\\HARDDISK1\\DP(1)0-0+9″

“\\DEVICE\\HARDDISKVOLUME3\\”

I have created an encase enscript that parses out this information to console and text file. The prefetch parser enscript (code) can be downloaded here

Usage: Load up any evidence containing pf files and run the script. Output is in the console and exported file.

UPDATE (April 2009) :

I have figured out the prefetch hashing algorithm (out of ntkrnlpa.exe) for XP and Vista. Its a simple one, that uses pi (3.14159) as a seed for randomization along with the prime number 37. The enscript code available in the link above contains the full algorithm implemented.

A key feature skipped in the earlier blog was the hash algorithm used by windows in the pf files, which I promised to return to. And here it is, ripped out of ntkrnlpa.exe for XP and Vista. Its a simple one, that uses pi (3.14159) as a seed for randomization along with the prime number 37.

It is essentially adding all characters into an integer overflowing it.

hash = (37 * hash) + path[i];

In Vista hash begins with value of pi = 314159;

In XP, it begins with zero, then performs an additional operation of :

hash = (314159269×hash) mod 1000000007

UPDATE (October 2013):

Read the updated changes for Windows 8 prefetch files in a new post here.