The need for speed

We are lucky in our lab that our workstations are upgraded on a regular basis so once in use we don't often make many changes.

The most important bits of my current spec are as follows:

1. Supermicro X7-DWA-N fitted into a Supermicro CSE-733TQ-645 chassis
   
2. Two Intel Xeon X5482 processors
   
3. 16GB DDR2 800 Ram
   
4. Western Digital 300GB VelociRaptor10,000 rpm hard drive for the OS
   
5. 3 x 1TB Samsung HE103UJ Spinpoint F1 hard drives in a RAID 0 array
   
6. Microsoft XP 64 bit
   
7. 256MB ATI FirePro V3700 GPU
   
   

At one time our primary forensic software Encase would max out the processor when carrying pretty much any process. With the advent of multi-core dual processors we aim to max out one core (which on my box is 13% cpu utilisation in task manager). As processors get faster and faster I have noticed that often the CPU core is not maxing out. Something else is slowing us down! We store our Encase evidence files on the Raid 0 array (and just before someone posts a comment about the lack of data resilience etc., the way our lab is set up all the data on my Raid 0 array is mirrored elsewhere). We do this for speed and capacity. When Encase (and most other forensic utilities for that matter) is processing it has a voracious appetite for data. Just look at the Read bytes value in Task Manager. The multi-core processors allow us to run other forensic programs (FTK, Netanalysis hstex etc etc) along with Encase, we can even run other instances of Encase, and because we can - we do. The net result of all these programs running is that they compete to read data from the Raid 0 array in my case (and from wherever you store yours in yours) - the net result once your data storage is maxed out is things slow down. It follows then that performance can be increased by having faster data storage.

One way to achieve this would be faster hard drives. We use sata hard drives for capacity reasons and to an extent cost. SAS hard drives are faster but don't provide the capacity. So as things stand three hard drives in a Raid 0 array was the best that could be done. I decided to see how I could make some improvement.

Currently the three hard drives (and the OS drive) connect to the Intel ESB2 raid controller integrated on the motherboard. Conventional wisdom would have it that by adding a fourth hard drive to the raid 0 array would speed things up.

HD Tach details an average sequential read speed of around 200 MB/s for a three drive array utilising the default stripe size (128kb) with NTFS formatted with the default cluster size.

Adding a fourth drive slowed the sequential read speed to around 180 MB/s.

I tested a variety of different stripe sizes and aligned the partitions but came to the conclusion that the Intel ESB2 controller just did not scale up to four drives very well. The arrays were created via the utility accessed via the controller bios during boot up. This utility is very basic and does not allow much configuration. Intel also provides a Windows utility called Intel Matrix Storage Console. When running this utility I found that by default Volume Write-back cache was disabled. Enabling it made a significant improvement.

Conventional wisdom has it that a hardware Raid controller would improve performance over the Intel ESB2 and in my testing this seems to be the case. I have used an Areca 1212 PCI-E raid card and achieved a sequential read speed of over 600 MB/s.

This array has four 1TB sata hard drives with a 64kb stripe, is partition aligned at 3072 sectors and has one NTFS volume with the default cluster size. Using Syncback to write to the array from our file server across a copper gigabit ethernet network produces some pretty impressive network utilization stats.

Yahoo mailbox

An MLAT request brought CD-R to my door recently. The OIC informed me that the CD contained a Yahoo mailbox but wanted my help because he could not read them. I found that the CD contained a tar.gz file.

Once this archive was unpacked I saw it contained two very large text files. These files were generic Mbox files. The next problem was how to view the contents. I found that Apple Mail would happily import Mbox files (File/Import Mailboxes) however I live in a mainly windows world so needed a Windows method for the OIC to preview the emails.

Thunderbird came to mind, however although this program uses the mbox format for its mailboxes it does not offer an easy way to import them. I did track down an extension to Thunderbird that provided this functionality but it only worked on one of my two mbox files. I also found that Opera 9 would also import my mbox files.

The problem with both Thunderbird and Opera is that the boxes available to the OIC in this case, and our customers in general, mostly do not have these programs installed. Ideally a way of getting the email messages into Outlook Express would be the best bet. The solution to this is provided by using the Mid Michigan Computer Forensics Group's M2CFG Yahoo! Email/Text Parser. This program parses out the email messages into .eml files which can be dragged into Outlook Express (and a number of other Email clients).

As it turned out the two mboxes I had extracted for the OIC were so full of emails with attachments that it was too complicated for him to process efficiently. So they came back to me to investigate. I added the mbox text files into Encase v6.12.1 and searched for email with the mbox option selected which resulted in Encase parsing out the emails and attachments very well. Reporting them was another matter!

Corel Paint Shop Pro Photo X2

Paint Shop Pro has a slightly longer title nowadays. From a forensic perspective the older version had a thumbnail cache stored within .jbf files. Tim Coakley wrote a tool for parsing the contents out. I stumbled across this new version when I saw some subfolders in my suspect's My Pictures folder entitled 2008.01.02 and a subfolder entitled Thumbs at the path C:\Documents and Settings\username\Local Settings\Application Data\Corel\Thumbs. This folder had a number of jpgs within it with filenames in the format yyyy.mm.dd.jpg.

The software can be installed as a trial. It has two components that leave good evidence - an Organizer that creates a thumbnail database of selected folders (by default the current users C:\Documents and Settings\Username\My Pictures, C:\Documents and Settings\All Users\My Pictures and My Corel Shows) and the Corel Photo Downloader.

Organizer
When the program is first run it will catalogue all supported picture types in the default folders. This allows the user to view a thumbnail gallery of the catalogued folders within the program. The thumnails are created and stored at the path:

C:\Documents and Settings\Username\Local Settings\Application Data\Corel\Thumbs

These catologued thumbnails retain the filename of the original picture. Metadata is stored in a database imagedb.db.

Corel Photo Downloader
This utility was responsible for creating some good evidence in my recent case. It is installed as part of Corel Paint Shop Pro Photo X2 and is intended to automate the download of photographs from cameras, flash media cards and CDs. The following dialogue box shows the relevant configuration settings:

Photos downloaded with this utility form the folders and files I had found.



Thumbnails of them are catalogued as part of the Organizer function - a function your suspect may be unaware of.

Thumbnail issues

When Coral Paint Shop Pro Photo X2 is running thumbnails are pruned if the underlying source folders/files are deleted. However if the program is not run after the underlying source folders/files are deleted the thumbnails remain. In my case it appears that the trial expired which allowed a considerable number of thumbnails to remain at the path C:\Documents and Settings\username\Local Settings\Application Data\Corel\Thumbs.

Imagedb.db

Both the organizer and the photo downloader utilise a SQLite3 database to store metadata in relation to the catalogued pictures. The database can be viewed using the SQLite database browser. It is possible to walk through the database to establish the original filenames of any thumbnails and the source folder. Other useful information is stored in the database including program configuration. In my case the date of download was useful.

Figure 1
Details pictures downloaded (in this case from a casio camera). The highlighted picture has been given an image ID number - 5210 and has a Download ID number 1.

Figure 2
Image ID 5210 has been allocated the filename 20090129_3.jpg and is stored in Folder 851.

Figure 3
Folder 851's entry detailing the folder name and path

Figure 4
Showing Download ID number 1's download date.

Encase v6 Comprehensive Internet History Search and Firefox Mork Databases

Encase version 6 now includes considerable functionality in recovering Internet History records for a number of browsers.

In a recent case using v6.12.1 I ran a search for internet history with the Comprehensive search option selected. My results included relevant hits in unallocated clusters which Encase attributed to Mozilla History/Forms. The results are recorded within the Encase Records tab and when highlighting a record some data was highlighted in the view pane which made me scratch my head - and luckily loosen some cobwebs in a long ago abandoned area of my brain. What was Encase showing me - I wasn't sure but my brain was telling me it was something to do with Mork.

Click on screenshot 1 to see a larger image



My suspect was using Firefox version 1.8. Firefox can save (subject to user configuration) information entered into web forms and the search bar to make form filling and searching faster. This information is saved in a file known as formhistory.dat. Encase had found data within unallocated that was a fragment of a deleted formhistory.dat file. In this version of Firefox formhistory.dat contained a Mork database. Encase had highlighted in the view pane what I will loosely refer to as the address of the data that it had parsed out.

[8(^83^83)(^82^8A)]

To understand this better we need to look more closely at all the data in the database. Because the hit was in unallocated I needed to find the start of the deleted formhistory.dat file. The file signature of the file is highlighted in the screenshot below

Click on screenshot 2 to see a larger image

so I scrolled up in the view pane, found this header and swept down to the footer (which is the } after the last address) and exported out the data as a file

Click on screenshot 3 to see a larger image


























Open the file with Notepad and find/replace all the $00 strings with an empty string. The file now looks a lot more readable

Click on screenshot 4 to see a larger image

In the example we are working through the address we are interested in is

[8(^83^83)(^82^8A)]

which can be seen shown in red at the bottom of Screenshot 4 above. This address is a row within the Mork database. The row is delimited with open and close square brackets [] and is made up of a Row Object ID followed by a series of cells delimited by open and close brackets (). The cells contain a column name and a value.

The column names are defined within a dict delimited with <> shown in green at the start of Screenshot 4 above. It can be seen that two column names are relevant here name and value, given object ids of 83 and 82 respectively.

The values are defined within the next dict down. The one relevant to our address are shown in red.

[8(^83^83)(^82^8A)]

decodes to

[8(^Name^searchbar-history)(^Value^vmware fusion)]

The Name column contains the type of record - searchbar-history means what it says on the tin, other values may relate to various fields found on web page forms. The query field on the Google Firefox start page is represented by q .

Encase does not report these records particularly well. I chose to export relevant records into a spreadsheet and manually add the physical sector and sector offset of each row.

References
https://support.guidancesoftware.com/forum/showpost.php?p=115379&postcount=2
http://www.mozilla.org/mailnews/arch/mork/primer.txt
https://developer.mozilla.org/en/Mork_Structure

Goodmans GNAV12 sat nav device

This device runs destinator software within a Windows 4.2 CE OS and is similar to the Medion MDPNA150 I looked at earlier. It has an external SD card slot which was not populated on the one I looked at. It also has internal flash memory.

I accessed the device via Mobile Device Centre in Vista and copied off the contents of the ResidentFlash volume. At the path DestinatorApps\Destinator\UK_Ireland I found Previous.dat. This file contains Recent Locations which are locations that the user chose to navigate to.

I have deconstructed the records found within Previous.dat.

Key (click on table to view larger image)

Example Records (click on records to view larger image)

Each record contains two sets of longitude and latitude co-ordinates stored one after the other. I speculate that one set is actual and the other set is nearest road. In my sample they were either very similar or the same. Each longitude or latitude value is stored as a double which requires 8 bytes therefore 32 bytes are required to store both sets. The two sets are followed by a further 16 bytes of data -use unknown, which completes the record.

To locate these co-ordinates I found it easier to count back from the start of the following record. The other problem to overcome is how to convert the doubles to a decimal value. Encase does not have a easy way to do this. 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.

I can supply on request an Enscript (written by my friend Oliver Smith over at Cy4or) that will parse out these records.

HP QuickPlay version 2.3

A HP media centre laptop came through our lab recently. Its main OS was XP Media Center edition. However it appeared to have another XP OS installed on a separate 1GB partition. This was a case where the suspect was suspected of hiding stuff and regularly re-installing his OS to cover his tracks - so this second OS was of interest.

Encase listed three partitions



Mounting the drive PDE and looking at the disk in Disk Management showed





The Windows Initialise case module reported the following for the OS on the 1GB partition



The 1GB partition has a Partition Type of D7



A quick google began to throw some light on the matter. It seems that the laptop has HP Quickplay 2.3 installed. This technology allows users to access multimedia disks without booting into the main operating system. The version of XP on the partition with partition type D7 is XP embedded. This OS facilitates the quickplay function. Later versions of HP Quickplay do not use this method.

It seems that a number of other manufacturers use the D7 partition type for similar purposes.

References

http://en.wikipedia.org/wiki/QuickPlay
http://www.goodells.net/dellrestore/mediadirect.htm
http://www.asifism.com/installing-hp-quickplay-on-your-laptopnotebook-vista-xp/

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.

Transition to XP 64

We upgrade our forensic workstations every eighteen months or so have just taken delivery of four shiny new ones. This time I decided that the time had come for us to enter the brave new world of 64 bit operating systems. I have read many peoples experiences of this on Digital Detective, Forensic Focus and so on and was expecting a number of difficulties. However the driver for change is utilising 8gb ram so XP 64 bit was specified. To be on the safe side I had the machines built in a dual boot configuration with XP 64 bit on one partition and XP 32 bit on another. As an additional safeguard on the 64 bit side I installed VMWare Workstation and created an XP 32 bit VM.

So if it helps anyone here is a list of what works (and what doesn't).

XP 64 Software installations

64 bit programs

Encase 6.11.2 x64

Encase installed OK. Help About shows that the PDE, VFS, EFS and Fastbloc SE modules are installed and I have successfully tested PDE.

Tomtology

Tomtology x64 1.162, .NET 3.5 Redistributable and the keylock dongle drivers all installed and working.

http://forensicnavigation.com/#/downloads/4527959036

7Zip

http://downloads.sourceforge.net/sevenzip/7z460-x64.msi

Ultramon

http://www.realtimesoft.com/files/UltraMon_2.7.1_en_x64.msi

Firefox

http://wiki.mozilla-x86-64.com/Download

CodeMeter

CodeMeter Runtime 3.30a is needed for the FTK codemeter dongle.

Gimp 2.5.4

http://downloads.sourceforge.net/gimp-win/gimp-2.5.4-r26790-x64-setup.exe?modtime=1219882476&big_mirror=0

32 bit programs that work within the 64 bit OS

Encase 6.11.2 32 bit version

The 32 bit version installs and runs OK.

Access Data FTK

I had hoped to upgrade to FTK2 but a 64 bit version has not been released. I did however decide to transfer our licences from the green keylock dongle to the Codemeter dongle. There are detailed instructions on how to do this within the FTK2 box. I used an internet connected laptop with the latest version of Licence Manager installed to carry out the transfer. Once the licences were on the codemeter dongle I installed CodeMeter Runtime 3.30a (64 bit) onto the XP 64 bit box and then inserted the dongle. It was successfully recognized. FTK 1.81 and Registry Viewer 1.5.3 have been installed and they work OK.

http://accessdata.com/downloads.html

Microsoft Office 2007

The office programs are 32 bit but are designed to work with a 64 bit MS OS.

VFC

I have installed VFC 1.2.4.3, the green keylock dongle drivers and VMWare Diskmount Utility. All seem to work OK.

http://www.vmware.com/download/eula/diskmount_ws_v55.html

C4P

C4P v3.3.4 runs without issue. However some work is needed to get the C4P graphics extractor enscript running.

For Encase v6 64 bit running on XP 64 bit install the 64 bit MySQL 3.51 ODBC connector driver found at http://dev.mysql.com/downloads/connector/odbc/3.51.html#winx64
and also a MS hotfix found at http://www.microsoft.com/downloads/details.aspx?FamilyID=000364db-5e8b-44a8-b9be-ca44d18b059b&displaylang=en

The latest C4P v4 graphics extractor enscript contains a mySQL database connection string which needs modification (if you are using mysql). The string needs to be edited to read:

Conn.Open("PROVIDER=MSDASQL;DRIVER={MySQL ODBC 3.51 Driver};SERVER=" + Com.serverName + ";DATABASE=" + DbName + ";" + "UID=c4p_user;PASSWORD=password;OPTION=3")


NetAnalysis
NetAnalysis 1.38 beta 6 is running OK

Irfanview
Irfanview 4.20 is a running OK

Saminside
Saminside v2.5.7.1 is running OK

Isobuster 1.9 Pro
Isobuster 1.9 Pro works OK

Various other utilities such as PSPad, FileAlyzer, WRR and WFA are also working OK.

Things that did not work

Well not much really. The Microsoft powertoy picture resizer does not work but is adequately replaced with http://adionsoft.net/fastimageresize/

Navman F20 Sat Nav device

Yet another Navman sat nav has come my way - an F20 (versionID 4.10.1029 BuildTime 2007-02-12, 09:38:57) and once again a different approach is required to access the relevant data files. The last Navman I looked at was a Windows CE device that became accessible using Mobile Device Centre in Vista. I have not been able to access this device the same way and I believe the underlying OS is Linux based. This site also states that the F20 is not running Windows CE. The case markings also do not disclose the precise model within the F series range. There are hidden service menus that will provide model and firmware information that are accessible by holding down the power and menu buttons together when powering on.

There is an SD Card slot which on the device I examined was not populated. The data was stored internally. I was not able to access this device as a removable USB storage device despite tracking down a driver. The only option left to me was to identify the storage within the device - luckily I discovered that the device has a micro SD card that is accessible without resorting to a full disassembly. The following pictures show how to access the card.







The memory card was formatted FAT16 and within the Navman/System folder I identified three notable files:

• Recent.dat
• Favver4.dat
  
• Route.dat
  

RECENT.DAT stores up to thirty locations. The locations may be
-destinations that the user chose to navigate to
-they may be the location that the unit was at when it was turned on
-or the location the unit was at when the user chose to navigate to a new destination.
These locations are stored in records of 520 bytes in length. Each destination has its Lat/Long coordinates stored in 8 bytes starting at Record Offset 507. These are decoded by bookmarking in Encase as a 32 bit integer. The resulting values need to be divided by 100,000. In the UK Latitude will begin in the range 49-59 and is decimally notated. Longitude is in the range -5 to +1.6 ish. When bookmarking as a 32 bit integer Longitude is shown first and will often be a negative value (i.e. anywhere west of Greenwich).

FAVVER4.DAT possibly stores up to 200 user entered favourite destinations. These favourite destinations are stored in records of 1508 bytes in length. Each destination has its Lat/Long coordinates stored in 8 bytes starting at Record Offset 352. These are also decoded by bookmarking in Encase as a 32 bit integer and dividing each value by 100,000. I also established that the first location stored within this file was the User inputted Home location.

ROUTE.DAT I speculate is used to store the origin of the last navigated journey. Coordinates can be found at record offset 507 however in this particular device no data was found in this file.

I have an Enscript kindly coded by my friend Oliver Smith over at Cy4or to parse the recent.dat file. Please email me if you need it.

Along with the F20 I have also examined a Navman iCN 330. This unit is similar to the Navman iCN 310 I wrote about earlier. This device had it's notable files stored upon an SD card also. Notably all the flash media cards I have examined that originate from Navman devices did not contain any relevant data within unallocated clusters. This suggests that in some cases a manual examination (i.e. photograph display whilst device is turned on) may suffice.

Another issue I have encountered is how to test on these devices. On TomToms it is possible to clone the memory cards and use the cloned card for testing. This is not possible with the Navman devices I have seen. When you run the Navman with the cloned card you quickly receive an eror message No Map Data or similar. It appears that Navman has some anti copying features built in that utilise the flash card's CID number (which I believe is stored within a non host accessible area of the flash card). As each card has a unique CID number cloning is impared.

References
http://navmanunlocked.wikispaces.com/Unlock
http://www.sdcard.org/about/memory_card/pls/
http://duff.dk/navman/
http://www.gizmondoforums.com/forums/index.php?showtopic=5366

Windows FE saves the day with a Dell Inspiron 530

Dell boxes (both laptop and desktop) seem to be more difficult to image every week. We had a Dell Inspiron 530 midi tower with a Seagate 320GB sata hard disk submitted to us. Our normal method of imaging this drive with a Tableau T35i write blocker and FTK Imager failed as the drive seemed to turn off after about ten minutes. An attempt with a Tableau T3u and FTK Imager also failed. Both Tableau write blockers had the latest firmware.

Next we tried to image the drive in situ by utilising a Helix 1.9a boot disc. Despite trying a variety of cheat codes we could not get the Helix disc to work.

So I decided to try out Windows FE in anger. Step one involved trying to identify the necessary drivers to build into the WinFE iso. I plumped for the relevant Intel Matrix Storage Manager sata driver for Vista which downloads as a self extracting zip file (R154092.exe) and loaded the two inf files into my WinFE iso. I also decided to add a chipset driver and downloaded the relevant Intel Chipset software Installation Utility. This also downloads a self extracting zip (R154069.exe) however when you run it as well as extracting a large number of drivers it also (on the Vista side my Macbook Pro at least) tried to begin an installation which I canceled. The chipset utility contains drivers for a large number of chipsets. The Inspiron 530 has an Intel G33 chipset so I loaded g33q35.inf into my WinFE iso.

With the drivers loaded I added my imaging tool. In my earlier Windows FE posting I alluded to FTK Imager not working. The author of the WinFE paper Troy Larson kindly advised me that one of his colleagues - Andrew Choy had been able to get FTK Imager to work. In addition to the dlls identified by Access Data as being required in the same folder as the FTK Imager.exe, a dll oledlg.dll from C:\Windows\system32\ needs to be added.

We added another sata drive onto a spare sata port within the Inspiron 530 and booted to the Windows FE boot disc. Some Dell boxes including this one provide a boot menu by holding down F12. After following the guide to using Diskpart in my earlier posting and assigning a drive letter to the additional sata collection drive we utilised FTK Imager to image the drive in record time. We imaged to Encase evidence files with maximum compression and the whole process completed including verification in less than four hours. Windows FE worked like a dream.