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/

Vista Volume Shadow Copy issues

Volume shadow copies in Vista are often the elephant sat in the corner in many cases. We know they exist and we know they can contain lots of data, but we often choose to ignore them.

A recent case required some keyword searches and an examination of picture files. A the completion of the keyword search most of the hits were within files with names similar to

{bab9c293-d150-12dc-a44f-021d253da909}{3708876a-d176-4f38-b7bb-05036c6bb821}

The view pane within Encase 6.14 displayed the contents in a nice light blue colour which I now know is a new feature in 6.14 to indicate the contents of uninitialised files. The files were all located within the System Volume Information folder on the root of the volume and are the Vista Volume Shadow Copies. By default 15% of the capacity of the volume is allocated by Vista to store these copies. The C4P graphics extractor enscript carved most of the notable pictures out shadow copies also.

At this stage I have known examiners report their findings alluding to the fact that that the notable artefacts are within the file {bab9c293-d150-12dc-a44f-021d253da909}{3708876a-d176-4f38-b7bb-05036c6bb821}. In most cases I think you need to drill down further. In order to do this I mounted my Vista image with Encase PDE and used Liveview 0.7b to create a working VM using VMWare Workstation 6. Having logged into my suspects account I ran a command prompt as administrator and entered the command

vssadmin list shadows /for=c:\

This provided a nice list of available shadow copies. Having selected one I entered the command (updated 13th Jan 2010)

mklink /d c:\shadow_copy7 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7\

This created a symbolic link in the root of C which in Windows Explorer at any rate appears exactly like a shortcut to a folder. Clicking on it produced the error message shown below

I believed this error is probably generated by a permissions issue (SEE UPDATE BELOW), however I was not able to overcome it and Rob Lee over at Sans Computer Forensics suggests this methodology does not work. I think Jimmy Weg however has had some success with a program written by Dan Mares - VSS.exe. I therefore turned to ShadowExplorer version 0.4.382.0. This program allows the user to view the contents of Volume Shadow Copies that exist on any volumes within the installed system. The contents are displayed in an Explorer like view allowing the user to export out any file or folder to an export directory. I exported the User profile I was interested in to an export directory. Unfortunately it seems that only the Last Written date is preserved in this process and all other time stamps are tripped. I then tried to copy this export directory out of the VM to my workstation and encountered errors (probably due to files within the profile with illegal windows file names). To overcome this I zipped up the export directory and copied the zip out of the VM. Once unpacked I then added the exported folders into Encase as single files and created logical evidence files from them.

Having done this I was able to resolve most of my keyword search hits and pictures to actual files as opposed to being simply within a volume shadow copy.

UPDATE 13th January 2010

The issue I had with the mklink command was due to a missing \  but not the trailing slash referred to in some comments below.  The correct command is 

mklink /d c:\shadow_copy7 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7\

References
http://blogs.msdn.com/adioltean/archive/2008/02/28/a-simple-way-to-access-shadow-copies-in-vista.aspx
http://blogs.sans.org/computer-forensics/2008/10/10/shadow-forensics/

You wait all day for a bus then two come along at once...

Probably not an entirely accurate title but I came across two enscripts the other day both of which are aimed at quickly triaging the results of a comprehensive Internet History search. Users of this functionality within Encase version 6 will know that often you can be faced with reviewing hundreds of thousands of entries on the records tab. Many times all you need is evidence of user inputted search terms. There are conditions available to start sorting the wheat from the chaff however it is difficult for these conditions to be totally focussed due to the variation in url formation. This is where both enscripts come in as they are both designed to parse the actual search term used from a variety of search engine urls.

Searchterms V 1.1 parses out the search term used and where possible the time and date it was carried out into note bookmarks. The enscript has been written to support a claimed 145 separate search engines.

Internet Search Term Finder parses out unique search terms to Log Record bookmarks and stores the term along with its associated url. The script is in fact an Enpack so it is difficult to determine exactly how it works, however it seems to base its search on elements from the query url. A neat feature is that it is configurable, allowing the addition of a new prefix (to the query string) to cater for a different or new search engine.

Within an XP Pro SP3 VM I carried out a series of searches utilising the Firefox v3.0.11, Internet Explorer v8, Opera v9.64 and Safari v4.0.2 browsers. I ran the Search for internet history Comprehensive search option within Encase 6.14 and established that all my searches had been parsed into the records tab, with the exception of those carried out with Safari v4.0.2. It turns out that Encase 6.14 does not support parsing internet history from this version of Safari.

I then ran both Enscripts and can report that both parsed out my test search terms from the records tab. The results can be viewed within bookmarks. For me the output of the Internet Search Term Finder is preferable and it usefully creates a Log Records bookmark which allows the easy export of results into a spreadsheet. Both successfully hit the spot in respect to users quickly reviewing search terms within internet history.

Update 15 Sept 2009
Dan Fenwick has kindly updated his Internet Search Term Finder (to v1.1.1). The script now can remove duplicates and separates the results by device. Even more useful - thanks Dan.

Link Files within System Restore Points

A recent case involved the download of a contraband file and I was asked to establish what happened just before the download in order to try and establish who was responsible. This scenario is fairly commonplace and I usually start with a timeline analysis of the file system activity around the event in question. An invaluable enscript for this is Geoff Black's Timeline Report which can also be found within the Guidance Software Enscript Resource center. The html report produced by this script is particularly cool.

In my case my analysis showed there were a number of link files in a number of system restore points all created at a time and date just before the download. They were all named in the form A000XXXX.lnk (xxxx being a variable number) and I could see from a rough and ready examination of the data that they all pointed to one particular file saved on the users desktop. As these link files were stored within restore points the first hurdle to overcome was to establish the link files original name and path. This information is stored within the changelog files of each respective restore point. Manually searching through this file for the restore point file name (e.g. A000XXXX.lnk) will reveal the files original path. There used to be an enscript for parsing the changelog files but it was written for version 5, however I was able to track down a version that worked in version 6 at Paul Bobby's excellent blog/web site (this enscript can also be found within the Guidance Software Enscript Resource Center). The changelog files contain a lot of information and all I really needed was the original filename and path - the scripts output may be a little bit of an overkill*. Another utility out there is the Mandiant Restore Point Analyzer. I used this utility to determine the original paths and file names.

All of the link files related to one link file stored within a users Recent folder. In my case the file the link file linked to was created and stored upon the desktop, thus causing the initial link file to be created. Over a period the target file was opened and additional information written into it, thus causing the link file to be updated. Harry Parsonage's paper on link files illuminates this further.

I copied the link files out of my image and loaded them into Sanderson Forensics Linkalyzer. This program decodes and displays the contents of link files into a grid much like a spreadsheet ( I was going to post a screenshot but sanitising the contents became too much of a pain) and very quickly allowed me to see that the target file was being regularly accessed and modified. Because the target file size is also stored within the link file I could also see that the file size was growing over time. The program produces good reports and has many other abilities beyond the scope of this blog post, but in short I thoroughly recommend it.

Now as far as my case was concerned the target file was clearly linked to the suspect and it proved worthwhile delving into those restore point link files.

References
http://computerforensics.parsonage.co.uk/downloads/TheMeaningofLIFE.pdf
Forensic Analysis of System Restore Points in Microsoft Windows XP

*Now what would be really useful is an enscript that simply parsed out the original path and filename of only all user selected (blue checked) files sitting in restore points. I would envisage the output to be a three column csv file - Current Filename, Original Path and Filename, Restore Point Creation Date.

Video Triage

Paul Sanderson's VidReport has been referred to here and there lately. C4M also is regularly brought up in conversations I have with people (such an interesting life I lead). Triage is certainly the flavour of the month right now. So I thought it worth writing a few lines about my recent experiences of triaging videos.

I have often voiced the opinion that reviewing a couple of hundred video files in a case is not that bigger a deal and on that basis I have not been too keen on using C4M. Anyhow I've just had a case with about 170 video clips to review and thought it would be a good case to try out the video triage approach. My normal approach is to use VLC as a file viewer in Encase to preview each video. This took about an hour and a half (some of the videos were quite good ;-) ).

I then used John Douglas's video triage program (which I think he supplies free to LE) to review the same video clips. To use this program you copy out the clips you wish to review and point the program at the folder containing them. It processes each clip by taking a screen capture at a configurable interval and putting each screen capture into a subfolder named after the videos file name. Once the program has processed all the clips you will have a sub folder for each one, containing the screen captures. I then simply dragged the folders into Encase as single files and previewed the contents of each folder in gallery view. I previewed all the clips in fifteen minutes. My scepticism of video triage was clearly unfounded.

Bing in-line video previews

The new Microsoft search engine Bing has been in the news lately.

One of the facilities it provides is a video search which in itself is old hat, however the results page features in-line video previews. A user can turn safe search off and perform a search which results in a screen of thumbnails of the located videos. Hovering the mouse over a thumbnail results in a short preview of the video being played within the thumbnail.

The thumbnail videos are cached as FLV (flash video) files however the interesting feature is that the URL host of the flv files in my early tests was ts3.images.live.com. The ts3 part was variable. Microsoft are processing the video using Smart Motion Preview technology producing effectively a trailer of the most relevant parts. Microsoft on or about 12th June 2009 began to serve all explicit video smart motion previews from ts4.explicit.bing.net. The ts4 part is variable.

These in-line video previews allow the viewing of contraband material without leaving a significant footprint. At least for Bing the search query is saved within the browsers internet history and the smart motion preview is cached as a FLV file with the word explicit helpfully added into the cached items url.

The video search at ask.com also provides in-line video previews however these previews seem to be streamed - another kettle of fish altogether!