Download PDF Version

EXPERIMENTAL TESTING
OF A FORENSIC ANALYSIS METHOD
ON THE TOMTOM GPS NAVIGATION DEVICE

by Clara Maria Colombini

INTRODUCTION

The earliest Satellite Navigation Systems were designed for the U.S. military, to locate the position of Polaris submarines. Over the years, satellite detection technology has become extremely widespread, and today most automotive vehicles are fitted with such systems.
TomTom, the in-car satellite navigation device, is connected with the U.S. NAVSTAR Global Positioning System (GPS), which utilises 32 satellites in Mid-Earth Orbit (MEO) positioned in six different orbital planes.

The TomTom device itself contains an ARM processor made by Samsung, using Linux to manage the software which – depending on the device – can read either an SD card or the internal memory. A bootloader in the computer searches the hard disk or SD card for the software and map data.  It then transfers the software to the 64MB internal RAM memory and starts the software.

The hardware itself starts the GPS and the navigation application. The navigation application then reads whatever settings have been installed, such as the preferred voice and last chosen route.

1
TomTom internal architecture


The integrated GPS module ensures that the satellite signal translates into coordinates pinpointing the user’s exact position on the map.  After start-up, the GPS module calculates the user’s position from the nearest satellite signals it receives; the module works out its position by calculating its distance from at least four different satellites, which send out information such as identity, altitude, position in relation to other satellites, etc.

The latest models feature RDS-TMC technology. The "Radio Data System-Traffic Message Channel" is a service providing real-time traffic information integrated in the device via a special receiver. The service provider encodes the message and sends it to FM radio transmitters which transmit it as a Radio Data System (RDS) signal alongside regular FM radio broadcasts. The TMC decoder inside the TomTom decodes the RDS signal into visual and/or spoken message on the device.

Bluetooth enabled models allow TomTom to communicate with other electronic devices like mobile phones, operate as a hands-free speakerphone, or receive information sent to a mobile phone via a wireless connection such as GPRS (General Packet Radio Service) or UMTS (Universal Mobile Telecommunications System).

This work presents research into a forensic analysis procedure on TomTom satellite navigation devices, which are able to detect extremely useful information for investigative purposes. Information such as stored addresses, itineraries, home, points of interest, etc. enable the device user’s travels, favourite itineraries and most frequent destinations to be reconstructed.

The main focus of the experiment was to develop a procedure for creating a “repeatable” forensic image of the internal memory, so that an identical forensic image can be produced at any time and can be used for analysis or as exhibits.

 

DEVICES ANALYSED

The following models were analysed:

  1. TomTom One with 1GB internal memory only – 2006 model;
  2. TomTom One with 2GB internal memory only – 2008 model;
  3. TomTom One with external SD memory card only – 2006 model;
  4. TomTom One XL Italy with 512MB internal memory + SD Card – 2008 model;
  5. TomTom Go 730 with 1GB internal memory + SD Card – 2008 model.

 

CREATION OF THE FORENSIC IMAGE

It should be noted that regarding the PC connection, the experiment did not consider the procedure for generating a forensic image of the SD memory card which can be removed from the device and can be treated like any other mass storage unit as per Computer Forensics rules.

The term “forensic image” as used herein refers to the result of a special copying procedure known as “bit by bit”, i.e. a system that scans the entire surface of the master hard drive one bit at a time, producing a clone, i.e. an identical copy, on a destination drive whose contents will be analysed.
Whenever possible, forensic analysis is not conducted on the original device but rather on its “clone”, or bitstream image, so as to preserve the integrity of the original evidence for any future analyses. Three forensic images were produced for each of the four models examined (one for each PC), for the following aims:

  1. since there was no “original” image available, i.e. one that was “definitely unaltered” against which to compare the images produced using this experimental method, which would have required an invasive procedure physically parallel to the memory chip, the first image generated was used as the starting point, and any changes observed during the tests were checked against the other two;
  2. three different PCs were used to simulate different scenarios (e.g. counter-reports, analyses at a later time, etc.).

In order to provide a sufficiently broad overview, forensic images were created using:

 

PROCEDURE IN WINDOWS ENVIRONMENT

The procedure for creating the three forensic images was carried out on three different PCs:

  1. PC workstation running Microsoft Windows XP PRO SP3;
  2. PC notebook running Microsoft Windows Vista Home Edition;
  3. Eee PC running Microsoft Windows XP Home Edition.

Software:
Accessdata FTK Imager 2.55 (free download).

Please note that it was not possible to use the  hardware write blocker  provided (Tableau T8) since when connected the PC does not recognise the device ( TomTom - T8 - PC).

 

PREPARING THE PC

The first step was to ensure that TomTomHOME software was not installed on the PC (for automatically updating TomTom data), or that the registry file did not contain keys or voice files from previous TomTom installations:

It is essential to carry out these checks because as soon as TomTom is connected to the PC it will try to update its data, searching for the software and registry keys signalled on the PC, and this will alter its files.  Since no hardware write blockers can be used, the USB ports have been configured as read-only, creating a special registry entry to disable the write option command on the peripherals connected to the PC via the USB ports.  The PC was disconnected from the Internet so as to prevent accidental attempts to update the device.

Regarding storage of the forensic images obtained, a new 50GB firewall was created on each of the three PCs, then wiped and formatted in Fat32.

 

CONNECTING THE DEVICE TO THE PC

Material used: mini USB cable for TomTom
Environment: the analysis was conducted in a closed room to prevent the TomTom device from locating the satellite.

The most sensitive part of the whole experiment was connecting the device to the PC so that the operating system “recognises” the TomTom’s internal memory without modifying the data stored within the memory, including the relevant “metadata”, i.e. other data describing this information, such as  dates of creation, modification and access, as well as size, etc..

The connection procedure varies from model to model: each model behaves differently depending on whether or not there is an SD Card slot.
The direct analysis of the model with the SD Card only was performed according to Computer Forensics rules.

The TomTom device has to be connected to the PC’s USB port and turned on, so in order to detect any changes to the data present when the drivers are installed, communication flows via USB between the TomTom and the PC were monitored throughout the connection procedure. The analysis was carried out using a specific tool, SysNucleus USB Trace v. 2.0.

 

MODELS WITHOUT SD CARD SLOT

MODELS TESTED:
Tomtom One with 1GB internal memory only – 2006 model;
Tomtom One with 2GB internal memory only – 2008 model.

 

CONNECTION

The PC is turned on and the operating system started up.

Monitoring is started on the data flow via USB on the port chosen for the connection.

Before turning the device on it is connected to the PC using the relevant cable. The TomTom is turned on. The screen illustrated below appears on the device:


2

Click on “YES”. The image below will now appear on the screen, indicating that the connection has started.


3

Once the connection has started, the screen below appears.


4


The computer signals that it has found a new USB device, installs the drivers and assigns a disk drive letter to the new peripheral device.

The same procedure was used for the three different PCs used.

The analysis of the data produced by monitoring the communication flows via USB between the TomTom and PC during the connection and installation of the drivers of the devices evidenced that no changes were made to the data contained in the device.

 

CREATION OF THE IMAGE

The forensic image was made on the three different test PCs using FTK Imager Accessdata v. 2.55, which calculates the Hash MD5 and SHA1 both of the original and the new image created, and verifies that it is an exact copy.

The new UBS peripheral is selected as the source and the DD image format (not processed) is chosen.

Destination unit: the ad hoc partition created on the PC.

The procedure is the same on all three PCs utilised.

 

RESULTS

An examination of the Hash MD5 and SHA1 files, which are identical, confirms that the three images created for each of the 4 devices are exactly the same and there has been no change to the data in the flow that the TomTom generates when connected to a Windows system.

The comparison was made using MD5summer v. 1.2.0.11.

In any case, as noted above, it is always essential to turn on the device since our intention was to conduct a “non-invasive” analysis, without having to open the device and/or remove the internal memory.

 

MODELS WITH INTERNAL MEMORY + SD CARD PORT

MODELS TESTED:
TomTom One XL Italy with 512MB internal memory + SD Card – 2008 model;
TomTom Go 730 with 1GB internal memory + SD Card – 2008 model.

Additional material used: pre-wiped SD memory card.

 

CONNECTION

If the TomTom device has an SD memory card slot, a preliminary operation is needed before connecting to create the forensic image, since there are two ways to connect this type of device to a PC.

With the information thus acquired, a connection is made as described below, which turns out to be ideal for enabling the PC to detect the content of the internal memory.

After deleting all traces of the previously installed TomTom drivers from the PC, the device, still off, is connected to the PC via the mini-USB cable.

The new “forensic” SD Card is inserted (see above: additional material used). 

5          6

The device is then turned on. The image below shows the TomTom screen during connection.

7          8

The TomTom screen shows that the device is connecting: the device is in USB mode and the PC views the content only of the SD Card, to which the operating system assigns an external hard drive letter. Once the USB connection drivers are installed, the device is switched off, the SD Card removed and the device is switched on again. The TomTom screen again shows that the device is connecting.

The computer does not need to recognise the peripheral device again, as it already has the drivers, and views the data contained in the internal memory of the external hard drive previously assigned to the SD Card.

 

IMAGE CREATION

At this point, the forensic image is created on the three different PCS, using  FTK Imager by Accessdata v. 2.55 software.

The physical unit of the new UBS peripheral is selected as the source and the image is chosen in DD format (not processed). The destination drive is the partition created ad hoc on the PC.

The same procedure is run on the three different PCs.

 

RESULTS

The Hash MD5 and SHA1 files are identical, confirming that the three images generated for each of the 4 devices are exactly the same; the data flow generated by the TomTom when connected to one of the Windows systems has remained unchanged.

The comparison was made using MD5summer v. 1.2.0.11.

In any case, as observed, the device always has to be switched on, since the analysis in question is “non invasive”, and as such does not require the device to be opened and or/ the internal memory removed.

 

RUNNING THE PROCEDURE UNDER LINUX

Again, the procedure was carried out on three different computers.

  1. PC workstation with Linux Fedora v. 10 operating system;
  2. PC notebook with Linux Helix v. 1.9 operating system, running live from CD;
  3. Eee PC with Linux NBCaine v. 0.5. operating system running live from USB device.

 

CONNECTION

Under Linux, there was no need to adopt different connection procedures for the various models of the device.

Before switching the device on it is connected to the PC using the mini-USB cable. The device is then switched on.

The Linux operating system recognises the device as a USB memory peripheral.

It is not necessary to “mount” the  TomTom, which stays on read-only.

Instead, the image destination device is mounted and set to read-write.

 

IMAGE CREATION

The forensic images are then created in “DD” format, using the software packages listed below:

  1. Linux Fedora v. 10:  command line procedure via console;
  2. CD Helix Live 3: ADEPTO 2.0;
  3. USB NBCaine: AIR 1.2.8.

 

COMMAND LINE PROCEDURE

The mount command is used to check that neither of the two drives (the source disk drive, i.e. the TomTom internal memory, or the partition chosen by us to store the image) has been automatically mounted, and then the partition destined to store the forensic image is mounted in read-write; the original disk is NOT mounted because the data is read directly from the device with the copy command.

# mount -o rw /dev/hdb4 /media/hdb4

Before copying, the destination device is wiped to delete any previously stored data. The following command can be used to complete the operation:

# wipe /media/hdb4

The original is hashed using the DD command, specifying only the input file and sending the output of this command in pipe to an md5sum (execution of MD5 hash).

# dd if=/dev/hda1 | md5sum

The image is then created: the simplest form of the DD tool is used for the copy. The command syntax requires an input file and an output file to be specified.

# dd if=/dev/sdb1 of=/media/hdb4/tomtom01.img

At the end of the operation, the command returns the number of read and written records, with a few statistics on bytes copied, total operation time and average transfer rate of the process.

The image created using the DD command is hashed, specifying only the input file and sending the output of this command in pipe to an md5sum.

# dd if=/media/hdb4/tomtom01.img | md5sum

 

PROCEDURE VIA AIR (Automated Image & Restore) TOOL

There are obviously pros and cons with using a command line tool; the main advantage is that there is total control over each individual instruction imparted, including the ability to directly specify which options and parameters to use for each device; conversely, the complexity of the commands and the different number of options may easily generate mistakes.

However, the Helix and Caine distributions overcome these difficulties with a series of graphical interface tools allowing the operator to exploit the usability of the window interfaces.

Below is the procedure made for creating forensic images using the AIR (Automated Image & Restore) tool, included in the Caine distribution.

First  select the source device on the left hand side of the template, and the destination device on the right.

Next, select no image compression.

Then  select the type of hash to use for verifying the identity of the original and the copy.

Here DCFLDD is been selected instead of DD.

This option does not branch the image into different files and does not encrypt the file with a key.

Then check the noerror option on the conv parameter, which continues the image creation operation even in the event of read errors.

Before pressing the start button and beginning the copy process, click on the show status windows button to see how the operation is progressing.

9

 

RESULTS

An inspection of the Hash files, which are identical, confirms that the three images generated for each of the four devices are exactly the same and that there has been no change to the data they contain.

In any case, as observed, the device always has to be switched on, since the analysis in question is “non invasive”, and as such does not require the device to be opened and or/ the internal memory removed.

 

ANALYSIS

The memories on TomTom devices (both the internal memory and the SD Card) behave just like any other digital memory insofar as they can store, conceal and delete files of any kind.

The TomTom memory creates forensic images “bit by bit” so that all the data stored can be analysed; even deleted or fragmented data can be carved out with the use of special forensic software.

The tool used to perform the analysis was AccessData FTK 2.2 running Windows; it can view the contents of all files present, including the relative meta-data, and recover deleted or fragmented files. However, for the purposes of an investigation seeking satellite navigation data using the device, only the relevant files are listed below.

TTGO.BIF

Contains information concerning the device, including:
model, serial number, language, current map, current base map, voice.

CURRENTLOCATION.DAT

Contains the latest position of the device

CURRENTMAP.DAT

Contains the current map

GPRSETTINGS.DAT

Contains the GPRS configuration (if present)

SETTINGS.DAT

Contains the name and MAC Address of any telephone connected, wireless settings, provider data, and user telephone data, if entered (GO models only)

GPRS.CONF

Contains the GPRS PIN number (if entered) (GO models only)

MAPSETTINGS.CFG

Files with a “CFG” extension, such as “mapsettings.cfg” or “name_map.cfg” are all contained in the folders of the relevant maps and contain all the information on “Favourites”, itineraries, addresses , and points of interest stored.

\CONTACTS\ CALLED.TXT

Contains telephone numbers called from the telephone connected to the TomTom (GO models only)

\CONTACTS\ CALLERS.TXT

Contains the telephone numbers that have called the telephone connected to the TomTom (GO models only)

\CONTACTS\ CONTACTS.TXT

Contains the contact list of the telephone connected to the TomTom (GO models only)

\CONTACTS\ INBOX.TXT

Contains text messages received from the telephone connected to the TomTom (GO models only)

\CONTACTS\ OUTBOX.TXT

Contains text messages sent from the telephone connected to the TomTom (GO models only)

NOMEFILE.ITI

Contains stored itineraries

TEMPORARY.ITI

Contains itineraries not stored with a filename

 

Depending on the model, certain files may be missing from the device.

This table reports some differences among different models.

 

RECENT DESTINATION

BIF FILE

SETTING FILE

CALLED FILE

CALLS FILE

INBOX FILE

OUTBOX FILE

TOMTOM ONE REGIONAL

YES

YES

NO

NO

NO

NO

NO

TOMTOM ONE EUROPE

YES

YES

NO

NO

NO

NO

NO

TOMTOM GO 510

YES

YES

YES

YES

YES

YES

YES

TOMTOM GO 710/720/730/750/790

YES

YES

YES

YES

YES

YES

YES

TOMTOM GO 910//920/930

YES

YES

YES

YES

YES

YES

YES

TOMTOM NAVIGATOR 6

YES

YES

NO

NO

NO

NO

NO

 

SPECIFIC TOMTOM ANALYSIS SOFTWARE

There are various software packages on the market for analysing TomTom navigation files. POIedit is a shareware programme that runs under Windows,  for reading DAT files.

It is interesting because it can identify and view the exact locations of addresses stored in the “mapsettings.cfg” file on GoogleMaps (an Internet connection is required).

The figure below pinpoints the geographic location of addresses contained in the “mapsettings.cfg” file.


10

 

The site contributors make every effort to stay on top of technology and document the “best practices” for seizing devices, acquiring the data, and analyzing the information.  If you come across additional information, errors on this site or contradicting information please use the contact form to let us know.