Thursday 31 July 2008

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

Monday 21 July 2008

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!

Friday 4 July 2008

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