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

Sony NV-U50 G Sat Nav device

Some of you may be thinking that this blog has stopped being a computer forensics blog and is now only covering sat navs. It seems that way lately, but it is just that my computer cases are all run of the mill whilst sat navs are nearly always new and exiting!

The Sony NV-U50 G sat nav I looked at is running Sony Personal Navigation System version 1.06 software within Windows CE. It has 512mb of internal memory and no external flash media. I accessed it via Mobile Device Centre in Vista (probably Active Sync will suffice but I did not test with this) and discovered a My Flash Disk volume as normal. A folder named Sony will be accessible and within the NAV-U sub folder the following notable files can be found:

• recent.txt
• favourites.txt
  
• prefs.ini

All three files are plain text.

prefs.ini is used to store user preferences but also contains three useful values:

• hometarget
• lasttarget
• LastVisibleArea

hometarget contains the postcode and latitude and longtitude coordinates of the user set home location. lasttarget was not populated on the device I examined but I understand from colleagues that it can contain the last navigated to location. Both these values comprise of seventeen fields separated by the pipe symbol (|).

LastVisibleArea contains the lat/long coordinates of the bottom left and top right corners of the last map displayed on the device prior to being switched off. I had seen that the manual for the device contained the note:
The Sony Personal Navigation System always opens with the screen that was active at the time you switched off the device.

recent.txt and favourite.txt contained recently navigated to locations and user stored favourite destinations respectively. Each location record comprised of seventeen fields separated by the pipe symbol (|) in both files allowing them to be imported into an excel spreadsheet using the text data import wizard.


Example of a single favourite record.

GFRIEND|-|48|12366|-|-|SW1 1AA|-|-|-|-|-0.142076|51.50107|-|-|-|-|

Field 3 in most cases contained the value 48 which I understand to be the Country Code used by Sony/Navteq for the UK, Field 4 had in some cases a five digit number beginning with the digits 12. I speculate that these fields have something to do with the RDS/TMC facility available with this device. Fields 12 and 13 contained the Longtitude and Latitude coordinates of the location record (stored in decimal notation). Fields 16 and 17 if populated contained a second set of Longtitude and Latitude coordinates which I can only speculate may be journey origins.

The device can also store pre-planned itineraries and these are stored within files with a .rte file extension in the Sony/NAV-U/Routes folder. These files are plain text formatted the same way as recent.txt and favourite.txt .

By carrying out a live examination of the device most the data above can be ascertained, however where a user has allocated a name to a favourite or itinerary only the allocated name will be displayed - not the underlying address and lat/long coordinates.

UPDATED 17th December 2008

I have been asked whether the order of the entries in Recent.txt had any significance. I have carried out some further testing and established:

i) Recent.txt will contain a maximum of thirty entries.

ii) If the entry is generated by a user choosing to navigate to a Favourite via the Favourites menu button the display name will be stored along with other location information within Recent.txt.

iii) The most recently entered location is recorded last.

iv) Once there are thirty entries within Recent.txt when a new location is added the oldest record at the top of the list is deleted. An exception to this is if a new location duplicates an entry already stored in Recent.txt the older entry is deleted (wherever it was stored in the list) and a new location appended to the end of the list.

I also had another look at the secondary lat/long values and I am now of the view that they DO NOT contain journey origins. During testing all the values I was able to populate in these fields were fairly near to the location chosen to navigate to. I could not however discern their relevance.