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.

Medion MDPNA150 sat nav device

A Medion MDPNA150 sat nav came my way in an IIC case the other day. It didn't have any IIC stored upon it but whilst I had it I thought I would look at the recovery of navigation data should one come my way requiring this.

The sat nav had a 256mb mmc card and it also had internal memory. Like the Navman's I looked at earlier the Median runs a Windows CE OS and the internal memory could only be accessed via Mobile Device Centre in Vista (probably Active Sync will suffice but I did not test with this). The navigation software is Destinator. As it turned out I found only one file of note on this particular device - Previous.dat. This file contains the history of locations previously navigated to and was stored on the memory card. Destinator does create other files of potential interest but they seemed to be missing on this sat nav.

The format of Previous.dat is of particular interest and differs from many other sat navs in the form it stores latitude and longitude co-ordinates. Most others I have seen before store these values as signed 32 bit integers. Within this file they are stored as a Double.

The structure of file seems to be as follows. There does not appear to be a header. The file starts with the first record and all records appear to be variable in length.

Each record begins with a type which I believe relates to the various navigation options. The type is stored in unicode and in my limited sample I saw:

City->Street
Zip->Street
(name of a Favourite)

The type is terminated with hex 0000.

A number of other zero terminated unicode strings may follow relating to House Number, Street, City and postcode.

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.



20th November 2008 Update
Subsequent to writing this up I examined a Goodmans device also running destinator software. I have written about it here . There is more information in that post. I can supply an Enscript (written by my friend Oliver Smith over at Cy4or) to parse out these records on request.


References
http://www.mozoft.com/d3log.html
http://www.ece.uwaterloo.ca/~ece204/TheBook/02Numerics/double/complete.html
http://www.gpsbabel.org/htmldoc-development/fmt_destinator_trl.html

C\Documents and Settings\All Users\Application Data\Microsoft\WIA\{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0000

My current case had a number of lets say incriminating photographs stored at this location. I was not sure what the WIA folder was. I have found that WIA  is an abbreviation of Windows Image Acquisition and is used to allow graphics software to communicate with imaging hardware.

The {6BDD1FC6-810F-11D0-BEC7-08002BE2092F} part of the path is a class GUID which features in the registry key HKLM\SYSTEM\CurrentControlSet\Control\Class\{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}. Microsoft use this key to store information about installed still image devices. I searched the System registry hive for this class GUID and found that this key contained details of Trust 360 USB 2.0 SpaceCam. It appears that this webcam has a snapshot button which causes the bundled Photoimpression software to cache pictures into the WIA folders.  The 0000 in the path appears to be used to distinguish the device.  If another still image device is used it would use folder 0001 and so on.

Having checked the registry of a few other boxes I have found references to digital cameras and scanners. Possibly a good source of evidence.

The moral of the story - search your suspects registry for any strange GUIDs you come across!

Windows FE

Windows FE is a forensic edition of Windows PE boot CD. It is forensic because it is not supposed to mount anything automatically. This post will not detail how to create a Windows FE disc because this can be found at the MS LE Portal (and also here) however I want to discuss some elements of why one would use it and also help to get over one or two gremlins.

I have been asked Is it another Helix disc? The answer is - it is similar but it offers some advantages in certain situations. The main advantage is being able to inject drivers into the ISO prior to burning. This allows you to add drivers for the latest SAS raid controller or Dell SATA drive controller for example which is not always possible in Linux (working on the principle that there are generally more Windows drivers than Linux ones).

You can also add your own forensic tools. I have been able to successfully add a full working copy of Encase 6.11 (including Dongle drivers). Strangely I have not been able to get FTK Imager to work (subsequently I have - see newer post). I imaged a 149GB hard disk in an Apple MacBook Pro to a 500gb external usb hdd in 2 hours 6 minutes.

Gremlin 1
If you have seen the paper dealing with the discs creation and use you will see that it states you should use the Diskpart utility to add and mount hard disks. You will probably need to mount a disk as your harvest or collection drive (i.e the disk you will save your image to). This aspect of the disks use proved to be slightly tricky. In order to save an image to an external drive I had to put it online, assign a drive letter and remove it's read only attribute. A number of Diskpart commands are required to achieve this as discussed below.

Windows FE boots up to a shell. You will have a command prompt on the X drive which is a RAM disk. To launch the Diskpart utility type:

X:\windows\system32\Diskpart

To establish which disks can be seen type:

DISKPART >List Disk

If you have not yet attached your collection disk you will have to type:

DISKPART > Rescan

and then List Disk after connecting it. You need to establish a drive number (e.g. disk 1 or disk 2 and so on) for your collection disk. Once you have done this you will need to select this disk:

DISKPART >Select Disk 1

and you may need to put it online:

DISKPART >online

and then clear any readonly attributes:

DISKPART >Attributes disk clear readonly

Then identify the volume upon your collection disk you wish to image to:

DISKPART >List Volume

and then select the volume:
DISKPART >Select Volume 1

and then clear any readonly attributes:

DISKPART >Attributes volume clear readonly

Next - assign a drive letter:

DISKPART >assign letter=k

You should now be able to write an image to your collection disk. If you are getting the error "your disk is write protected" or similar the problem most likely lies with the read only attribute.

Gremlin 2
The disk during the boot process prompts press any key to boot from the CD. This behavior is not very desirable in a forensic boot CD. To prevent this from happening delete the bootfix.bin file from the \ISO\boot folder before creating your WinFE CD.

Gremlin 3
Encase will run happily from the disk but simply copying your Encase folder from Program files will cause some problems with respect to the encase config files and the indexing and parsecache folders. The way round this is to create an X: drive on your local machine and create an WinFE folder within it. Then install a new copy of Encase into this folder. If you then copy the Encase folder from here into the the WinFE tools folder all the paths will be fine.

Links
http://www.svrops.com/svrops/articles/winvistape2.htm
http://www.digital-detective.co.uk/cgi-bin/digitalboard/YaBB.pl?num=1213944253

Navman iCN 510

I blogged a short time ago about the Navman iCN 310 satellite navigation device.

A iCN 510 (versionID 3.00.1008 BuildTime 2004-11-22, 12:38:48) has now been submitted and it is a bit more complicated to deal with. It still had a 128mb MMC card but it only had maps on. The .dat files I needed to find were stored within internal memory. The problem to overcome was how to access it. This navman is running a Windows CE NET 4.2 OS and in Windows XP Microsoft Active Sync is required to access it. The plan was to use Paraben's Device Seizure software to image the device. The plan went pear shaped when Active Sync wouldn't connect to the Navman - I am not sure why but I suspect a driver was missing somewhere. In desperation I connected the device to a Vista box and suprisingly detected the Navman immediately as a mobile device and allowed me to copy off the aformentioned .dat files. In Vista Active Sync has been replaced with a free download - Windows Mobile Device Center. I instaled this software and it then identified the Navman as a Windows CE device. Within the device there appeared to be two volumes: \ and My Flash Disk.

Within My Flash Disk there are four notable files:

• Recent.dat
• FavVer3.dat
  
• route.dat
• tripPlan.dat
  

RECENT.DAT stores up to thirty of the recently navigated to destinations. These destinations 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. 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).

FAVVER3.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.

ROUTE.DAT I speculate is used to store the origin of the last navigated journey. Coordinates can be found at record offset 507.

TRIPPLAN.DAT contains destinations set by a user when planning a trip with multiple destinations (via Trip Planner in the main menu or via pop up menus in the Map Screen). These destinations are stored in records of 532 bytes in length. Each destination has its Lat/Long coordinates stored in 8 bytes starting at Record Offset 504. These are also decoded by bookmarking in Encase as a 32 bit integer.

Where I can I try and download manuals for these devices because it helps in mapping the features to the files containing user generated data. I found that the manual for the iCN 510 did not reflect the menu screen I found. The manual for the iCN 600 however did mirror what I saw on this device. I guess the software was upgraded.

GREP search expression for Encase to find coordinates ......[\x4f-\x55]\x00

Another issue I am encountering with sat navs is flat batteries and no chargers. Not all of them can be charged via USB however I have found that mobile phone chargers are a good stand in. Motorola have a charger that happily charged this Navman.

Finding Event Logs in unallocated

I blogged here about a case where the suspect had repeatedly re-installed his OS. The suspect is accused of creating a CD at a particular time prior to the installation of the current OS. Putting aspects relating directly to the CD (link files, volume serial number etc.) aside we needed to find evidence that the computer was or was not being used at the material time.

After reading Harlan Carvey's blog I liked the idea of recovering event logs from unallocated. After hunting around Harlan's and a few other blogs together with Steve Bunting's site I found and had a read of Rich Murphey's paper Automated Windows event log forensics. Following his advice we created a GREP

\x30\x00\x00\x00\x4c\x66\x4c\x65\x01\x00\x00\x00\x01\x00\x00\x00

and utilising the custom file finder in Encase carved out 512kb files from unallocated. The issue of corrupt event logs was considered as discussed on Steve Bunting's site and Rich Murphey's fixevt tool was run across all the carved evt files in the export folder to deal with this issue.

I had to decide which tool I could use to parse out the contents of these evt files. I would have liked to use one of Harlan's perl scripts or utilities but despite seeing references to them everywhere I could not lay my hands on them (guess I'll have to buy the book). I did try out Event Log Explorer and this program was very successful in parsing out many of the carved out evt files and displaying them in a functional GUI. I was impressed with the programs filtering tools and it's ability to save a project into a workspace.  When I first wrote this up I missed the obvious - you can also drag the carved out evt files back into Encase as single files and use the Windows Event Log Parser module part of the Case Processor Enscript to parse them.  It seems to create a separate worksheet for each evt.

pagefile.sys - not always what it seems!

From time to time I hear colleagues discussing the merits of an artefact reported by Encase as being in pagefile.sys. It may be a picture or even an e-mail attachment as referred to in this Forensic Focus post. I have seen reports detailing these artefacts along with explanations of what virtual memory is.

I have always thought that pagefile.sys was pre-allocated an area of the hard disk and did not necessarily have to write to it all. As this was raised again recently I decided to carry out some tests.

I configured a XP VM not to use a Paging File



and then ran Eraser v5.86.1 with a Task to wipe Unused Space with



which in ASCII is UN. As expected I ended up with most of Unallocated Cluster being overwritten with UNUNUN etc. (\x55 \x4E).

I then turned the pagefile back on and rebooted



I found that a considerable proportion of my (quite large) pagefile.sys was UNUN etc. sampled in this sweeping bookmark-


Full Path Pagefiletest\0\C\pagefile.sys
File Created 05/06/08 09:41:25
Last Written 05/06/08 09:43:35
Physical Size 1,794,691,072
Logical Size 1,794,691,072
Initialized Size 1,794,691,072
Starting Extent 0C-C3307487
File Offset 32763080
Length 3104

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN

UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUN


and shown in this screen print



The moral of the story is that the pagefile.sys is not always what it seems - perhaps more specifically what is reported as being within it may have resided within unallocated clusters prior to pagefile.sys being created or resized.

References

http://www.aumha.org/win5/a/xpvm.php
http://www.petri.co.il/pagefile_optimization.htm

Install dates and shutdown times found in the registry

My friend Chris over at Cy4or told me about a case recently where a suspect had stated that he repeatedly had problems with his OS (XP) that he resolved by formatting and re-installing.

Chris was tasked with looking for evidence of this and came up with searching for the Install Date registry key in live (Software hive and restore points) registry files and within unallocated clusters. This proved to be a neat idea because a number of different Install Dates were located.

In encase the GREP \x04\x00\x00\x00\x01\x00\x00\x00\x49\x6E\x73\x74\x61\x6C\x6C\x44\x61\x74\x65 finds the Install Date string and just prior to this can be seen a Unix 32 bit date which when decoded is the Install Date. On all our test boxes this was consistent- your mileage may vary.



We also looked at whether the same method would locate multiple shutdown times but found that the shutdown time at HKLM\System\Current Control set\Control\Windows\ShutdownTime stored as a 64 bit Windows File Time is often not co-located with the ShutdownTime string.

Whilst looking at this we did find that the registry key HKLM\System\Current Control set\Control\Watchdog\Display\ShutdownCount was exactly what it says on the tin - it maintains a count of the number of times the OS has been shutdown.

Navman iCN320 Sat Nav device

I have previously written elsewhere a guide to investigating TomToms and of course there is TomTology and the paper by Beverley Nutter of the MPS out there as well.

Today I had a Navman iCN320 sat nav come my way.

After a brief look it seems that the crucial three files are within the SYSTEM directory:

• RECENT.DAT
• FAVVER4.DAT
  
• ROUTE.DAT

They are stored on a 256mb MMC card formatted FAT16.

RECENT.DAT stores up to thirty of the recently navigated to destinations. These destinations 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. 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.

ROUTE.DAT I speculate is used to store the origin of the last navigated journey. Coordinates can be found at record offset 507.

GREP search expression for Encase ......[\x4f-\x55]\x00

Looks like a bit of testing is in order!

The net widens!

Saw this on the BBC news today. The gist of the article is possession of drawings and computer-generated images of child sex abuse would be made illegal in the UK.

Although I agree with the sentiment has anyone given any thought to the practicalities? I can see another category being specified within SGC Guidelines with no thought being given to our tools of the trade (C4P etc.)

How do you tell if an account password is set in Mac OSX ?

A colleague asked me "How do you tell if an account password is set in Mac OSX ?". A bit like buses two mac problems have turned up at once.

A simple question? - well after looking at this for a while I thought -give me one on sport!

When you google this problem you find tons of stuff on cracking/ hacking/ replacing/ passwords and a few relevant sites that I will reference at the end of this post.

I am going to focus on Mac OSX 10.4 and 10.5. Password hashes for each user are contained in files at the path private\var\db\shadow\hash. The file names comprise of the generated user Id for each user and these can be reconciled (on Tiger boxes) to the user name by looking at the store.xxxx files in var\db\netinfo\local.nidb.

When you look at the hash files in the text pane within Encase it will look something like

NTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLM000000000000
000000000000000000000000000000000000SHA1SHA1SHA1SHA1SHA1SHA1SHA1SHA1SHA1SHA1
0000000000000000SaSHA1SaSHA1SaSHA1SaSHA1SaSHA1SaSHA1SaSHA1SaSHA1000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000

NTLM represents a 64 character NTLM hash.
SHA1 represents a 40 character SHA1 Panther compatibility hash.
SaSHA1 represents a 48 character salted SHA1 hash used by Tiger and Leopard.

The NTLM hash comprises a 32 character NT hash and a 32 character LM hash and will only exist if Windows File Sharing is enabled for this user (or in Tiger boxes has been in the past). I have seen only a 32 character NT hash on Leopard boxes (i.e. the first 32 characters). The SHA1 hash will only exist if the box has been upgraded from Panther and may also be salted with four zeroes preceding the 40 characters. The SaSHA1 hash comprising of 48 characters will exist in all cases from FO169.

If an account is enabled for Windows File Sharing it is easy to establish whether a password is set. This is because the NTLM hash for a blank password is known and is in all cases:

31D6CFE0D16AE931B73C59D7E0C089C0AAD3B435B51404EEAAD3B435B51404EE

therefore any other NTLM hash must represent a password of some kind. In Leopard it appears that only an NT password hash is stored and therefore only the first 32 characters of the blank password hash will be stored.

I have created a few test accounts and the hash files are as follows:

1) apple pw test\0\1 Customer\Macintosh_HD\private\var\db\shadow\hash\49BE7F58-7656-4FF3-A77B-21CC32E774CB

This is a hash file from a Leopard box - note the 32 character NT hash which represents a blank password.

31D6CFE0D16AE931B73C59D7E0C089C0000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000000003894ED462BFB59E9E750F719DD326D62685D51BE63F0823E000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000

2) apple pw test\1\1 Apple_HFS_Untitled_1\Bootable Backup\private\var\db\shadow\hash\322CD0AA-AE6D-4100-A94C-E27A7D64EA5B

This is a hash file from a Tiger box - note the 64 character NTLM hash which represents a blank password.

31D6CFE0D16AE931B73C59D7E0C089C0AAD3B435B51404EEAAD3B435B51404EE0000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000AE9FF34A30316C6A3ED60E16E01DACE0CB2EC125F4535523000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000

3) apple pw test\1\1 Apple_HFS_Untitled_1\Bootable Backup\private\var\db\shadow\hash\F796D172-5974-4BD6-AF20-A389C45137AC

This is also hash file from a Tiger box for another account- note the 64 character NTLM hash which represents a blank password and also that the salted SHA1 hash is different to the previous entry.

31D6CFE0D16AE931B73C59D7E0C089C0AAD3B435B51404EEAAD3B435B51404EE0000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000030A5A46EEC7D0CA83AB340F593DC98B9DC9C3A7984807428000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000

The last two files illuminate the problem - because of the salt in the absence of a NTLM hash how do you determine if a null/blank password has been set. I understand that the salt that prefixes the hashed password in tiger/leopard has 2^32 potential values which is a big number. I have tried to use a password cracking program MacKrack but it does not seem to like blank passwords however the pre-patched version of John The Ripper which includes support for OSX salted SHA1 hashes does cope with them.

To use JTR download a pre-compiled version from here and unzip. Then create a text file containing an entry in the form user:saltedSHA1hash (i.e. for the hash in the example above user:30A5A46EEC7D0CA83AB340F593DC98B9DC9C3A7984807428). Next launch Terminal and drag into it the file John from the unzipped JTR download and then drag in your text file and press return.

Last login: Mon May 26 00:03:32 on console
test-machine-imac:~ test$ /Users/test/Downloads/john-1.7.2-macosx-universal/run/john /Users/test/Desktop/jtr.txt
Loaded 1 password hash (Salt SHA1 [salt-sha1])
           (test)
guesses: 1  time: 0:00:00:00 100% (2)  c/s: 12950  trying:
test-machine-imac:~ test$

The process is complete once you see the command prompt. The output of the password is in the form
Password (user name)
In this example the user name I used was test and because the password is blank nothing precedes (test).
The result will also be recorded in John.pot. If the password is not blank JTR will keep trying to guess what the password is -blank passwords will be identified almost instantly. The example I have shown above utilises a Mac OSX version of JTR - there is also a Windows version which is equally as good and runs from the command line - just a pity you can't drag files to the windows command prompt.

Another issue to consider if the ability to configure a Mac to login automatically to a nominated account without inputting a password. Luckily the com.apple.loginwindow.plist clearly indicates whether the autologin facility has been used and additionally the log at private\var\log\secure.log also contains reference to this facility when it has been used.

References
http://www.dribin.org/dave/blog/archives/2006/04/07/os_x_passwords/
http://www.machacking.net/kb/files/crackingosxhashes.txt
http://www.macshadows.com/forums/index.php?s=&showtopic=8516&view=findpost&p=62916
http://www.macos.utah.edu/documentation/system_deployment/radmind/faqs/manage_local_users.html
http://www.macshadows.com/kb/index.php?title=Mac_OS_X_password_hashes#Mac_OS_10.4_.27Tiger.27
http://freaky.staticusers.net/ugboard/viewtopic.php?t=17175

wtmp

A while back over at forensic wiki I posted a few Mac OSX artefacts which may be evidentially useful.  

The wtmp file was one of them.  This file contains login and shutdown information for Mac OSX 10.4 and earlier, sadly I found out today that wtmp is now deprecated in Leopard and has been super-ceded with asl.db.

To view wtmp you could copy the suspect file to your mac and within terminal use the command Last -f and pipe out the parsed file to a text file in the form:

testac_ console macintoshtestcom Tue Feb 19 21:37 still logged in
reboot ~ Tue Feb 19 21:36
shutdown ~ Tue Feb 19 15:51
testac_ console macintoshtestcom Tue Feb 19 15:26 - 15:51 (00:24)
reboot ~ Tue Feb 19 15:26
shutdown ~ Tue Feb 19 10:37
testac_ console macintoshtestcom Tue Feb 19 10:28 - 10:37 (00:09)
reboot ~ Tue Feb 19 10:26
shutdown ~ Tue Feb 19 00:52
testac_ console macintoshtestcom Mon Feb 18 18:44 - 00:52 (06:07)
reboot ~ Mon Feb 18 18:42
shutdown ~ Mon Feb 18 18:39
testac_ console macintoshtestcom Sun Feb 17 17:55 - 18:39 (1+00:44)
reboot ~ Sun Feb 17 17:51
shutdown ~ Sun Feb 17 17:47
testac_ console macintoshtestcom Mon Feb 11 11:21 - 17:47 (6+06:25)
reboot ~ Mon Feb 11 11:21
shutdown ~ Mon Feb 11 03:31
testac_ console macintoshtestcom Sun Feb 10 14:28 - 03:31 (13:03)
reboot ~ Sun Feb 10 14:27
shutdown ~ Fri Feb 8 15:35
testac_ console macintoshtestcom Fri Feb 8 14:24 - 15:35 (01:10)
reboot ~ Fri Feb 8 14:24
shutdown ~ Fri Feb 8 14:21
 

and so on....

This works fine using Terminal in Tiger but for some reason using the Last command in Leopard does not work.  

I have asked about this elsewhere and someone suggested the wtmp parser within the Encase Case Processor.  The results I got were unintelligible.   

Whilst revisiting this subject I discovered that older  wtmp files are archived into gzip files which may become useful to someone!

Tableau writeblockers and sata laptop hard drives

We use a variety of Tableau writeblockers and found that the T35i was regularly not recognising newish sata laptop hard drives.

It seems Tableau have encountered this and released a firmware update (v5.20) back in February 2008.

Bearflix

Bearflix is a peer to peer file sharing program from the Bearshare stable working on the Gnuttela network. I have examined Limewire in detail in the past and posted a lot of stuff at Forensicwiki.com.

A recent box I looked at had Bearflix installed and I found that it saves what amounts to the holy grail in these type of investigations - the user inputted search terms. The program has in built banner advertising and I found that these banner adverts cause entries to be made within Internet Explorers History index.dats. The URLs contain the search terms (presumably so that the adverts can be tailored to the search term). How cool is that! I have documented this in a couple of slides following

Google Searches

Google search terms can be great evidence and I doubt that many machines exist where they can't be found. NetAnalysis identifies them within URLs and cached webpages may hold some results pages.

On a Vista box I am looking at there is a helpfully named folder entitled Local Search History at the path

C\Users\{account name}\AppData\Roaming\Google\Local Search History

The equivalent location on XP is C:|Documents and Settings\{account name}\Application Data\Google\Local Search History.

Within this folder are five files on the box I am looking at

1. google%2Emaps.w
2. google%2Eweb.w
3. google%2Egroups.w
4. google%2Eimages.w
5. google%2Enews.w

Each one contains search terms in unicode. I have tested and found as it appears the type of google search is contained in the filename (e.g. google map searches are in google%2Emaps.w and so on).

Notably testing using IE7 with a separate Google Toolbar installed running in Vista revealed that searches made using

1. Instant search box (set to Google)
2. Google Toolbar
3. Google webpage

all populated google%2Eweb.w .

I have found traces of these files in unallocated clusters also.

The google toolbar has a Clear History option and as far as I can tell this modifies the MFT for the file resulting in Encase reporting an Empty File. In testing I carried out searches that caused google%2Eweb.w to extend over three clusters as follows

I cleared search history and via disk view in Encase viewed each cluster. In cluster 1447520 I found remnants of google%2Eweb.w but after a few minutes this cluster was zeroed out (during this test I had pointed Encase at my local drive). So at this point I am not sure why I have found traces in unallocated.