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.
