Prefetch and User Assist

It seems to me that more and more cases I see only have evidence within unallocated clusters. It is also a frustration that the CPS seem less and less interested in any artefact found there. They seem to have the view that any thing currently living in unallocated clusters somehow magically arrived there and has nothing whatever to do with the computer's user.

Obviously we try and address this misconception, by trying to investigate how the evidence in question came to be on the computer, and to a lesser extent how it came to be deleted. Which brings me on to another frustration - file wiping software. This is another thing I see more and more. Properly configured file wiping software eliminates the little fragments of evidence we use to piece our cases together.

Recently I was faced with this scenario - evidence could only be found in unallocated and there was file wiping software sat there in program files. Sentencing Advisory Panel guidelines allude to the presence of file wiping software being an aggravating factor to consider when sentencing. But in this case it occurred to me that it would be evidentially useful to know just how often my suspect used the file wiping software concerned. File time stamps may indicate when the program was last executed and installation dates can be discerned from a variety of locations (registry entries, folder creation dates and so on) but where do you establish how often the program was used? You never know -it may write to a log file or create event log entries but many don't. In my case the answer lay in two areas - Prefetch and User Assist.

Prefetch
My suspect was using Microsoft Windows XP. This OS (as the later Vista and Windows 7) performs application and boot prefetching. This process is designed to speed up the loading of applications (with regards to application prefetching) by storing data required by the program during the first ten seconds of use in a file - a prefetch file. These files are stored in the Windows/Prefetch folder and have a .pf file extension. The file names are a combination of the applications name and a hash of its file path. The hash may be useful in some cases because it could indicate that an application lives in more than one location (which is often suspicious). Some work on analysing the hash algorithm has been carried out by Yogesh Khatri at 42llc. The files themselves contain some useful information including last time of execution, the number of times the program was run and references to files and the file system utilised by the program in its first ten seconds of use. Unfortunately prefetch files are not differentiated by user. In my case the file wiping software had a prefetch file. There are a number of options open to us to analyse the prefetch file.

If all you need is the time of last execution and number of time the application was run for just one file you may as well do it manually. For Windows XP at file offset 120 an 8 byte Windows Filetime is stored which is the Last Execution Time. At file offset 144 the number of executions is stored as a four byte Dword. For Vista and Windows 7 the offsets are different - 128 and 152 respectively.

Bookmarking Last Execution Time and Date

Bookmarking number of times the application was run

If you have a number of prefetch files to analyse or you wish to corroborate your findings you could try the Mitec Windows File Analyzer program or run an enscript. Guidance Software's download center has two enscripts that fit the bill. PfDump.Enpack and Prefetch File Analysis. Pfdump outputs to the console and the Prefetch File Analysis enscript outputs to bookmarks.

UserAssist
UserAssist is a method used to populate a user's start menu with frequently used applications. This is achieved by maintaining a count of application use in each users NTUSER.DAT registry file. I use Access Data's Registry Viewer application to parse and decode this information. Simon Key has written a cool enscript which is bang up to date with Windows 7 support. Detailed information, including the changes introduced with Windows 7, and the script can be found within GSI's download center.

In my case I encountered a possible anomaly in that the Prefetch and UserAssist run counts were different. With multiple users you would expect this as the Prefetch run count is not user specific. I had only one user in my case and the UserAssist count was significantly greater albeit that both were four figure numbers. A possible explanation is that if the application's prefetch file is deleted when the application is next used the prefetch run count starts again from 1.

References
https://42llc.net/index.php?option=com_myblog&show=Prefetch-Files-Revisited.html&Itemid=39
http://en.wikipedia.org/wiki/Prefetcher
http://members.rushmore.com/~jsky/id14.html
http://members.rushmore.com/~jsky/id37.html
http://jessekornblum.com/presentations/dodcc08-2.pdf

C4P Import to Encase enscript and Lost Files

Many C4P users experience problems when importing bookmarks back into Encase from C4P. A common problem is that files bookmarked in Unallocated Clusters don't match up to actual picture data. Almost always the cause of this problem is that the user has run the Recovered Folders process in Encase after running the C4P Graphics Extractor enscript thus altering the amount of unallocated clusters (as calculated by Encase). Trevor has a two page pdf on the C4P website addressing all the potential issues.

I have noticed another problem. A large number of my notable files are in Lost Files. Lost Files in Encase on an NTFS volume are files that have an MFT entry but their parent folder has been deleted. It is possible to have a number of files in the virtual Lost Files folder that have the same file name (and path). In my current case where I have duplicate file names in Lost Files the C4P Import enscript has not always bookmarked the correct file, bookmarking another file with the same name and path instead. This is sometimes further complicated by the incorrect file being deleted and overwritten.

The symptoms of this problem are easy to detect. Viewing your C4P import within the Encase bookmarks tab in gallery view results in a number of pictures not being displayed. When checking the bottom pane in text view you see that the bookmarked data for the non displaying pictures does not relate to a picture. Alternatively the picture you see does not relate to the C4P category it should be. To review this I am currently selecting (blue ticking) all non displaying pictures or wrongly bookmarked pictures and then tagging these selected files. Having done this in Entries view I am sorting by selection (blue tick) then highlighting a blue ticked file, then sorting by name. This brings all the other files with the same name together in Entries view. I am then checking the others to find the file that was meant to be bookmarked.

The underlying problem is a small bug in the C4P Import v2 enscript. Trevor has now kindly fixed it for me and will no doubt circulate the revised script. However in the meantime to fix the script

Find the following file in the import script folder: ..\include\ProcessReportClass.EnScript

In there, find the following function:

EntryClass FindByFullPath(ImportRecordClass irc, CaseClass c)

It’s a short function, only eight lines – highlight them, and replace with the following:

EntryClass FindByFullPath(ImportRecordClass irc, CaseClass c){

EntryClass e = c.EntryRoot();

e = e.Find(irc.DeviceName + "\\" + irc.Path);

if(e){

if(e.PhysicalLocation() == irc.PhysicalLocation)

return e;

else

return null;

}

else

return null;

}

Save and update.

HTH someone :)