Friday, 13 November 2009

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
Forensic Analysis of the Sony Playstation Portable - Scott Conrad, Carlos Rodriguez, Chris Marberry and Philip Craiger

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

Sunday, 1 November 2009

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)

  • 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


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.