TIM released - first test

Tableau have released their Tableau high performance software imaging product today.

To install it you first must have installed the latest Tableau firmware updater. Once installed the interface is fairly simple to use. I found some of the terminology in the GUI a bit odd. For example the types of compression selectable for Encase e.01 files are No Compression, Fast Compression or Good Compression whilst Encase provides the options none, good or best. It seems that fast maps to good and good maps to best. There also does not seem to be the ability to actually name the created e.01 files- just their containing folders, again a little strange.

Now as far as performance is concerned in our environment it is slightly faster. We image to a mapped network drive on a san across a gigabit ethernet network. I imaged a Hitachi 80GB sata laptop hard disk via a Tableau T35i write blocker using FTK Imager 2.5.5 using the Encase e.01 format - imaging completed in 51 minutes. Using TIM to image the same drive took 44 minutes. In both cases maximum compression was selected. Obviously at this stage this testing is far from scientific but TIM seems to be between 10 to 15% faster. I will report how it goes on with larger 3.5 inch sata hard drives later.

C4P, MySQL and Windows 7

I can just about remember the thrill of upgrading to a new OS. When I was the new kid on the block I couldn't wait to upgrade from Windows 98SE to XP Pro (somehow we missed out Windows ME). Anyhow the newer kids on the block have migrated to Windows 7 (it is prettier, more stable, blah blah). Now I am a dinosaur with XP Pro 64 bit!

Anyway I had a call today about getting various aspects of C4P to play nicely with MySQL on a Vista 64 bit box. In our office we don't actually use Vista on any of our forensic boxes so I thought I'd check out the issues on one of Windows 7 64 bit boxes. As you know (because if you are still reading this you probably use C4P along with a MySQL DB) C4P interacts with the MySQL database in two areas:

1. within Encase at Enscript level if the pre categorization option is selected
   
2. or via Data Migration/ Special/ Update Case Direct from C4P Hash Database within the Categorizer for Pictures program itself.
   

Both of these connections require an MySQL ODBC connector driver to communicate with the running MYSQL C4P hash database using a suitable database connection string. Essentially in this scenario we have a choice of four MySQL ODBC drivers:

1. MySQL ODBC 5.1 64 bit
2. MySQL ODBC 5.1 32bit
3. MySQL ODBC 3.51 64 bit
4. My SQL ODBC 3.51 32 bit
   

All bar the 3.51 64 bit driver are installed via a Windows installer. The 3.51 64 bit driver is slightly trickier to install - you need to unpack the zip, run a command prompt as administrator, navigate the command prompt to your unpacked zip folder and then run the command

Install 0

Enscript level communication

At Enscript level it is possible to modify the database connection string which allows you to specify which ODBC connector driver to use. In testing on a Windows 7 64 bit box I have found that both the 3.51 and 5.1 64 bit drivers work (if the drivers fail you generally get a long unintelligible error message). The C4P 4.02 enscript allows the user to configure their own database connection string. The string that works for me is:

Provider=MSDASQL;DRIVER={MySQL ODBC 3.51 Driver};SERVER=Your_server_name_or_IP_address;DATABASE=c4p_hash;UID=c4p_user;PASSWORD=password;OPTION=3

Simply change 3.51 to 5.1 if you are using the later driver.

Categorizer for Pictures communication

The database connection string used by this program is hard coded and not user configurable. The program requires the 3.51 driver. However I could not get the Data Migration/ Special/ Update Case Direct from C4P Hash Database option to work on the Windows 7 64 bit box using the 3.51 64 bit driver. I suspect this is due to a permissions issue and tried to run C4P as administrator but I still failed to connect to the MySQL C4P hash db. However I was able to get the Data Migration/ Special/ Update Case Direct from C4P Hash Database option to work using the MySQL ODBC 3.51 32 bit driver.

Conclusion

Other combinations may work but on a Windows 7 64 bit box I recommend installing the MySQL ODBC 5.1 64 bit driver and the MySQL ODBC 3.51 32 bit driver to get C4P and the C4P graphics extractor enscript to play nicely with the MySQL C4P hash database.

Web Browser Session Restore Forensics

As this is the first post of the year I would like to wish you a happy new year.

The posting title is the title of an excellent paper written by Harry Parsonage relating to Session Restore files created by the latest Mozilla (Firefox) and Internet Explorer 8 browsers. These files may contain enough information to allow the browser to display a users workspace exactly as it was prior to a forced restart. Obviously these files may contain significant evidence. I am not going to steal Harry's thunder so download his paper from http://computerforensics.parsonage.co.uk/other/other.htm

I know that Harry is not keen on blogs simply regurgitating information found elsewhere so I will try and add a little value.

Safari v4
Session Restore functionality is now a must have in modern browsers. Another browser to have similar functionality is Safari v4. The last session information is contained in a file entitled LastSession.plist

In Mac OSX 10.6 this file is stored at /Users/<user name>/Library/Safari

In XP this file is stored at C:\Documents and Settings\<User name>\Application Data\Apple Computer\Safari

I use the mac application - property list editor to review plists, there are windows applications to do this as well.

Firefox v3.5.6 running in Mac OSX 10.6
Harry's paper applies here in the main.

The sessionstore.js file is stored at /Users/<User Name>/Library/Application Support/Firefox/Profiles/XXXXXXX.default

Navman S30 Satnav device

I have seen a number of different Navman models now. All of them have subtle variations on how to process them. Although the underlying OS is Microsoft WinCE.NET 5.0 Core Version I did not have to access this device via Mobile Device Centre. After applying some write blocking to my USB port this device was accessible as a mass storage device allowing me to image it with Encase. I ended up with 114,759 sectors being imaged.

The next step I took was to track down and consult a manual for the device in order to establish its capabilities. I expect all devices to have saved Home, Favourites and Recent destinations and this device was no exception.

In addition however this device can save trip logs, pre-planned itineraries, pictures and be paired with a mobile phone.

Almost all the relevant data is stored within xml formatted files. Microsoft Excel 2007 is an excellent tool for examining these files and subsequently reporting on them. I use the Get External Data / From Other Sources / From XML Data Import option via the data tab and allow Excel to sort out the formatting.

A good place to start is the file paths.xml stored at the root of the partition. This file details the location of some of the relevant files.

This is a more definitive list:

• MyFavouriteLocations.xml - used to store the home location and favourites
• MyRecentLocations.xml - used to store Recents and also Journey Starts
  
• MyMultiStopLocations.xml - used to store saved multi stop journeys
• MyRoute.xml - used to store the current journey which is in effect the last journey -on the device I examined this file was deleted but recoverable
  
• UserSettings.xml – used to store device settings including where the unit was turned off
  

When a user enters a new address the menu shows previously entered towns or cities, road names and postcodes. This data is stored in the following files:

• DWRecentPocode.xml – Previously entered postcodes, most recent first
  
• DWRecentRoad.xml – Previously entered road names, most recent first
  
• DWRecentPlace.xml – Previously entered towns or cities, most recent first
  

There are a number of presumably back up files also containing the same (as far as I could see) xml formatted data:

• MyFavouriteLocations_bak.xml
• MyRecentLocations_bak.xml
  
• MyMultiStopLocations_bak.xml
  

There are also two files that appear to be temporary files which were deleted but recoverable, containing xml formatted data:

• MyRecentLocations_New.xml
  
• MyMultiStopLocations_New.xml
  

All of the above mentioned xml files are parsed very tidily using Microsoft Excel 2007. I use the same program to create an html version of the worksheet after a little tidying up. The longitude and latitude values need to be divided by 100,000. I populate a new column using the formula:

=HYPERLINK("http://maps.google.co.uk/maps?q="&(K3/100000)&"+"&(L3/100000)&"","Click here to view in Google Maps")
The cell K3 contains the Latitude and L3 the Longitude. The formula creates a clickable hyperlink to the Lat/Long in google maps.

There are one or two other files of interest:

• destdata.dat - which contains the address used for the last navigated journey
  
• gpslog.ini - detailing the location of trip log data
  
• default_settings.xml -which in the FAVOURITES/ RECENTS/ MULTI-STOP section appears to detail the maximum number of favourites and recents
  
• .pcd - on the unit I examined I could not locate a .pcd file however I understand from Andy Sayers that this file if it exists contains the phonebook from a paired mobile phone
  
• Log001.log - again I did not see this file but if it exists it contains GPS track logs
  

Because we have physical access there is also a possibility of recovering relevant data from unallocated clusters. I located records in unallocated using the keyword <lat> .

References
Sat Nav Examination Guidance Notes (Andy Sayers)
Navman S-Series (S30, S50, S70 & S90i) User Manual

Binatone X350 UK&ROI 2nd edition GPS

This device can be purchased very cheaply now from places like Asda and ebuyer. It runs Astrob Turbodog4 satellite navigation software within a Microsoft WinCE.NET 5.0 Core Version OS. Although I have not examined one I believe a number of Navigo devices run similar software. It has an SD card slot which was unpopulated in the one I looked at. The internal memory can be accessed like many similar devices via Mobile Device Centre in Vista which makes available a volume entitled ResidentFlash. I disable writing to USB devices by modifying the registry (there are many utilities about to do this). Simply paste the text below into a text file, give it a .reg file extension and then execute it and then reboot.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies]
"WriteProtect"=dword:00000001

After copying and creating a logical evidence file of ResidentFlash I found three notable files within the MobileNavigator folder:

• RecentDest.dat
  
• FAV.DAT
  
• SystemSet.dat
  

RecentDest.dat stores up to fifty of the recently navigated to locations. These locations are stored in records of 104 bytes in length. The first record starts at the first byte of RecentDest.dat, so by viewing the file in Encase with the view pane set to hex and dragging the view to show 104 bytes per line (assuming you have twin monitors), it is possible to see all the relevant data. Each location record stores Longitude and Latitude as 8 byte doubles which unfortunately Encase does not natively decode. The data interpreter in Winhex can do this. The hex editor 0xED on a mac can also do this but rounds up to fewer decimal places than Winhex. So given a fully populated RecentDest.dat file you have one hundred doubles to decode. I turned to my friend Oliver Smith over at Cy4or who wrote me an enscript which parses out the records to a csv file. Email me with a brief note about who you are for a copy

Recent Destinations also log the time entered, so very unusually some meaningful time and date information may be extracted. Providing these times have been recorded whilst the device can see satellites they are accurate and stored at the configured time zone. If a destination is entered when the unit can not see the sky and if the battery had been previously discharged it appears that the recorded time and date would be soon after 00:00 hours 1st January 2007.

I have decoded each 104 byte record as shown in figure 1

Figure 1 (click on image for larger version)

FAV.DAT contains user configured Favourites stored in 536 byte records. Once again the Longitude/Latitude are stored as eight byte doubles in the first sixteen bytes of each record.

SystemSet.dat appears to store the users Home location and again the Longitude/Latitude are stored as eight byte doubles.

Within the MobileNavigator folder there is a folder entitled Trace. This was empty in the one I looked out however the manual states:

The unit is capable of logging all positioning information received from the GPS satellites during navigation. It then uses this information to draw a track of the route on the map. This enables you to review the route information at a later time.

I imagine that should this feature be enabled a file of some sort will be stored in this folder.

References

http://binatonegps.com/gps/download/manual/X350II%20User%20Guide%20(Turbo%20Dog)%20-%2020080910.pdf
http://en.wikipedia.org/wiki/Double_precision_floating-point_format

Sony PSP internet history

A recent case resulted from an entry in a compromised web server log. The GET request included the string "Mozilla/4.0 (PSP (PlaySation Portable); 2.00)". Our suspect had used a PSP to do dodgy stuff and the PSP eventually came my way. I looked around for some information but did not find a large amount of information, essentially the most useful items were an Encase Message Board post and Chapter 9 of a book entitled Advances in Digital Forensics V which I read via Google Books.

Sony PlayStation Portable hand held consoles have an inbuilt wi-fi adaptor and can therefore connect to the internet. The device utilises the Netfront browser. There are a number of different versions and firmware versions. The one I looked at had a label indicating that it was a PSP1001. This site details the many different types available. A PSP1001 is known as a PSP Fat (as opposed to a PSP Slim). The one I looked had version 4.05 firmware. These type of PSPs have a small amount of internal NAND flash memory and a Memory Stick ProDuo flash media card.

As far as I can ascertain it is not possible to examine the internal NAND memory of devices beyond 1.5 firmware because you would require hacked firmware and modified hardware to do it. The browser does store its cache in this area but I believe as a default only 512KB is used for this purpose. Some information can be derived from the internal memory via a manual exam. Essentially then, we are left with the Memory Stick ProDuo flash media card. Our Tableau USB write blocker would not recognise the card I had however I was able to image it using our Helix imaging box and Guymager. The card had a FAT16 file system and was examinable with Encase.

Files of interest
On the card I looked at only two files were of interest both in the folder \PSP\SYSTEM\BROWSER.

bookmarks.html contained what you would expect -user created bookmarks
historyv.dat contained internet history

Scott Conrad, Carlos Rodriguez, Chris Marberry and Philip Craiger's paper within Advances in Digital Forensics V refer to two further files of interest historyi.dat and historys.dat. I got my hands on a test PSP1001 with the same firmware as my suspects (4.05) and in testing I was not able to populate these files with any data. The files existed but I was not able to cause details of either Google Searches or user typed URLs to be stored in these files. My suspects card had an unpopulated historyi.dat file and no historys.dat file. As noted by Conrad et al I found in testing that I could only cause writes to historyv.dat by shutting the browser down gracefully. Simply turning off the PSP without shutting down the browser did not commit that sessions history to historyv.dat.

Structure of historyv.dat
The structure of historyv.dat is discussed by Conrad et al however they suggest that elements of the file were best decoded by introducing the data into a test PSP for decoding. For example the date of each history entry could be ascertained this way. I would prefer to carry out a completely static examination if possible, not least because on my suspects card I had recovered a number history records in slack space and a manual examination can be a little laborious. I have therefore decoded the records a little bit further as shown below at Figure 2 and Figure 3. Each historyv.dat file is headed with 66 bytes of data starting with the string Ver.01. Within this 66 bytes are two further bits of plain text - NFPKDDAT and BrowserVisit. Immediately following BrowserVisit is the first history record. The most recent record is listed first, the oldest last. Each record can be located using a GREP expression to search for the header - in Encase \x03\x00\x01\x00 -see Figure 1 below. Records can be found in slack space and unallocated clusters.

Click on image for larger version

Figure 1

Figure 2

Figure 3

A significant addition to the research of Conrad et al is the decoding of the date for each record. The date is recorded in the two bytes following the URL and is stored Little Endian. In Encase sweep these two bytes and right click, select Go To and check Little-endian. The value is the number of days since the Unix epoch (1st January 1970). This web site provides a good date calculator.
IMPORTANT NOTE re dates: the dates stored are in accordance with the PSPs internal clock. The clock resets when the battery is exhausted. With the firmware I looked at the reset date was 1st January 2008. This date is 13879 days from the Unix epoch. I speculate that the average user is unlikely to reset the date each time the battery exhausts, therefore I would expect to see a lot of dates in January 2008.

References and thanks
http://www.edepot.com/reviews_sony_psp.html
http://en.wikipedia.org/wiki/PlayStation_Portable#Web_browser
Forensic Analysis of the Sony Playstation Portable - Scott Conrad, Carlos Rodriguez, Chris Marberry and Philip Craiger
https://support.guidancesoftware.com/forum/showthread.php?t=33057&highlight=psp
http://www.computerforensicsworld.com/modules.php?name=Forums&file=viewtopic&t=654&highlight=psp

Thanks to Pete Lewis-Jones and Simon Maher for their help brain storming the date problem

Garmin Streetpilot C510

I blogged earlier this year about the Garmin Nüvi 200 Sat Nav device and I have now had a crack at a Garmin Streetpilot C510.

The Streetpilot like the Nüvi 200 stores waypoints in a file Current.gpx found within the Garmin folder. This folder is accessible when the device is connected to a computer due to the fact that the device is designed to act as a mass storage device. It is probably worth expanding on what a waypoint is. Garmin's FAQs define them as

Waypoints may be defined and stored in the unit manually, by taking coordinates for the waypoint from a map or other reference. This can be done before ever leaving home. Or more usually, waypoints may be entered directly by taking a reading with the unit at the location itself, giving it a name, and then saving the point.

Essentially as far as both the Garmin devices discussed here are concerned the waypoints recovered from Current.gpx are the users favourites and home location. Apologies for teaching granny to suck eggs but it is probably worth stating that waypoints are not Track Logs. Most Streetpilots and Nüvi 200s do not store any tracking information (there is an unsupported hack which allows the modification of some units firmware to store tracking information).

As commented in my previous posting and within the SatNav forensics forum over at Digital Detective these Garmin devices do store other data not contained in Current.gpx. This data is the Recently Found locations which are effectively the last fifty locations a user chose to navigate to (or at least look at on the device). Evidentially this data may be useful. Up to now a manual exam using something like Fernico ZRT has been the answer. I have tried out a slightly different methodology.

Suggested Methodology for the examination of Garmin Streetpilot C510
(May work with other models)

• Download Garmin USB drivers
  
• Download Garmin xImage version 2.3
  
• Download G7toWin
  
• Install Ximage on your workstation
• Turn on Garmin sat nav and press and hold your finger over the onscreen battery symbol for about 10 seconds
• This should take you into a hidden diagnostics menu

• On your Forensic Examination workstation run the Garmin USB drivers executable and work through to this screen

• Connect Garmin sat nav to your Forensic Workstation and complete the USB driver installation (the sat nav must be displaying the hidden service mode - if it isn't it will act as a mass storage device)

• Run G7toWin on your workstation (it does not need to be installed) and adjust the configuration to allow communication via USB

• Within G7toWin via the menu bar select GPS/Download from GPS/ All
  
• All available waypoints will display
  
• Via File/Save As you can save the data to your filetype of choice (e.g. .gpx, .kml, .xml)
  
• It is possible that one of the fields may contain an illegal character - in my testing the comment field did. I dealt with this in my exported kml and xml files with a decent text editor (PSPad) and the find and replace feature. Applications that support xml and Google Earth are not usually tolerant of any illegal characters/formatting.
  

Downloading of the waypoints is now taken care of. Next I want to deal with the

Recently Found

locations. I am going to suggest two approaches, which although relatively simple I have not seen documented elsewhere. The version of the device you are using may dictate which approach you try.

• Approach 1
  
• You should still be at the Diagnostics Menu - press the Exit icon
  
• Via the main navigation menu select Where to?/ Recently Found
  
• You should now see the first five Recently Found locations
  
• On your Forensics Workstation launch xImage, your device should appear in the Device field then click Next
  
• Select Get Images from the GPS then click Next
  
• Set Image Type to Screen Shot
  
• Clicking Next will allow you to save a screen shot of the currently displayed screen on the device
  
• Using this method you can quickly screenshot all the screens you would have photographed in a manual exam, after each screenshot click back to prepare for the next one
  

Approach 2 is more invasive, however I think principal 2 of ACPO guidelines applies.

• Approach 2
  
• You don't initially have to have your device connected to your workstation for this to work
  
• On the device select Settings/ Display
  
• In the Display menu enable Screen Shot
  
• This will cause a small camera icon to appear in the top right of the display
  
• Pressing this icon will cause a screen shot to be saved into the Garmin/scrn folder upon the device
  
• Screen shot all the screens you would have photographed in a manual exam
  
• Connect device to workstation as mass storage device and cut and paste screenshots from it
  

UPDATE RE GARMIN Nüvi 310

Artemus has been looking at a Garmin Nüvi 310. He tried Approach 1 above and found that to enter the diagnostics mode he had to push and hold the top right of the display (as opposed to the battery symbol). HOWEVER he then encountered a message asking if he wished to delete all user data, so I guess for Nüvi 310 Approach 1 is a no go. So he tried Approach 2. He enabled the Screen Shot feature however on this device no camera icon appears. Screen shots are created by pressing the power button. Screen shots are saved into a folder entitled Screenshot on the media card.

TIM

TIM is an acronym for Tableau Imager which unsurprisingly is new imaging software developed by Tableau. Tableau promise astounding imaging speeds. Apparently it will be available in beta form anytime soon. Given the quality of the Tableau write blockers I think this software is definitely worth watching out for. The latest info can be found here.

Video triage revisited

Back in July 2009 I blogged about the potential of video triage. I was commenting on its effectiveness and had used a program written by John Douglas to explore what was possible. Mark Woan added a very interesting comment to that post, introducing a program he had written - Forensic Video Triage. I have now tried out a series of enscripts written by Oliver Höpli which aim to provide the same functionality as both John and Mark's programs.

Essentially all three approaches utilise a third party video playing and manipulation program to create and store thumbnails of frames at set intervals throughout a video clip. The investigator can then triage the video clip by reviewing the thumbnails as opposed to playing the video. The gallery feature in Encase for example makes reviewing the thumbnails a considerably quicker experience than playing the videos.

John's program utilises VLC, Mark's uses ffmpeg and Oliver's enscript calls upon mplayer for thumbnail creation. Each of these video utilities have inbuilt codecs and their capabilities may vary - in other words a video clip may play with one and not the others.

Oliver Höpli has integrated the process much more closely with Encase with his suite of enscripts, and for me this can only be a good thing. If you are an Encase shop the pre-processing is considerably reduced and the whole process is more seamless leading to greater productivity. The main enscript runs across selected (as in blue checked) movie files within your case and parses out thumbnails into a logical evidence file. Another enscript creates a folder structure within the Encase bookmarks tab based on the contents of the logical evidence file. Each video clip has a folder within bookmarks making it an easy process to review the thumbnails.

To get it all working the main enscript needs a little configuration which I found a little fiddly. Ahead of time you need to install a version of mplayer suitable for Windows, the installer I used was MPUI.2009-07-24.Full-Package.exe. This appears to have been superseded by MPUI.2009-10-12.Full-Package.exe which is available here (at least today - download locations seem to change quite often). Oliver directs you to the standard mplayer site which I found a bit difficult to navigate. Once mplayer is installed you need to configure the main enscript by editing it to include the location of mplayer.exe and the location of a suitably large temp directory. On my box the lines of the enscript are (note the double \\)

////////////////////////////////////////// Configuration ///////////////////////////

//Path to MPClassic.exe
mpclassic = "C:\\Program Files (x86)\\MPlayer for Windows\\mplayer";

//Tempfolder which will be used to extract the movies and create the thumbnails
expDir = "C:\\Temp";

//time interlace between to frames
//films under 1 minute
OneU = 5;

//films between 1 and 5 minutes
FiveU = 10;

//films between 5 and 30 minutes
BetweenFiveAndThirty = 20;

//films over 30 minutes
ThirtyU = 30;

///////////////////////////////////////////////////////////////////////////////////

Oliver's enscript can be found in the Guidance Software Download Center and comes with a Readme which needs reading.

Windows Photo Gallery

Windows Photo Gallery is built in to all Vista editions and allows the management of photographs and other pictures together with the ability to carry out a number of basic photo editing tasks. Two forensic artefacts of this program are discussed in this post.

Original Images Folder

The program allows users to revert to the original picture with one click should they not like the results of their editing. This feature provides investigators with a very useful artefact. When a picture has been edited the original unmodified version is stored at

%LOCALAPPDATA%\Microsoft\Windows Photo Gallery\Original Images

The file name of this original unmodified version is renamed - the relevant Microsoft Knowledge Base Article details the file name construction

When the original unmodified version of the image is saved, the image file is renamed by using a combination of a unique ID and the original file name. The unique ID is determined by theSystem.Image.ImageID file property. If there is no System.Image.ImageID file property value, a GUID is created. The following is the new file name construction:
'{' + unique ID + '}' + '-' + file name
The following is an example of a renamed original file:
{198EB054-44E6-441e-87C8-9B29C5198DE6}-image1.jpg

To example this I have edited and renamed the Windows sample picture Toro-toucan.jpg (quite apt considering the forthcoming Arthur's day) using Windows Photo Gallery

The Original Images folder is created the first time a picture is edited with the application and is a hidden folder. From a forensic point of view we might need to identify the edited picture which may have been renamed. We can locate the edited picture by searching for the unique ID referred to above. Essentially take the original file name:
{1F7BA35C-33F2-499E-92A1-0FBE9477C8CA}-Toco Toucan in my example)

and strip it down to

1F7BA35C33F2499E92A10FBE9477C8CA

This value is embedded within metadata stored within the edited file known as an XMP Message block and also in one further location. Using FTK Imager we can see this value stored in the two locations within the edited file (click on screenshots to see a larger version)

In the second screenshot part of the XMP message block can be seen. The editing application is also detailed.

Pictures PD4

Windows Photo Gallery stores metadata about the pictures indexed by it in a database file Pictures.PD4 at the location

C:\Users\YourUser\AppData\Local\Microsoft\Windows Photo Gallery.

Tim Coakley's Simple Carver Suite contains a program Windows Photo Gallery Viewer to parse this file. I have found that substituting a test Pictures.PD4 file (in a Vista VM lets say) with your suspects Pictures.PD4 file can produce some meaningful results. I found that the best results can be achieved when the test Windows Photo Gallery is set to display tiles view. Although a blog discussing the transfer of Pictures.PD4 files from machine to machine suggests that the test machines Volume Serial Number needs to match that of the suspects. This can be done with the Windows Sysinternals utility Volume ID v2.0.

References
http://support.microsoft.com/default.aspx/kb/944370
http://blogs.msdn.com/pix/archive/2006/08/16/702780.aspx
http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart3.pdf
http://aaron-kelley.net/blog/2008/03/migrating-vistas-windows-photo-gallery-database/