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!