Forensic acquisition and analysis of the Random Access Memory of TomTom GPS navigation systems

https://doi.org/10.1016/j.diin.2010.02.005Get rights and content

Abstract

TomTom navigation systems are widely used, but unfortunately these devices do not store any information that can be used to link time and position on any non-volatile media. However, this kind of information can be found in the volatile Random Access Memory (RAM) of these devices. There are two methods to extract the content stored in RAM. The first method uses the available JTAG signals on the device. For the second method, a small Linux distribution is loaded into the device. Analysis of the extracted content shows some information linking time and position of the device. Although the quantity of information found at this point is limited, the possibility to link the position and time of the device can be invaluable in some cases.

Introduction

Driving on the motorway at night, you can observe the faint glow from a navigation system from almost every car; as if nobody knows their way home without one. The combination of the wide acceptance of these devices and the information stored on them, makes them valuable in a forensic context. The possibility of linking a device to a specific place at a specific time or determining the speed of the device at a certain point can provide critical information to forensic teams. Depending on the brand and model of the navigation system, the information required to make these links is or is not stored on any non-volatile media (van der Knijff, 2009).

In Europe, TomTom was the market leader with a market share of almost 50% in 2008 (Luttikhedde, 2008). Unfortunately, their present models do not store any information which can be used to link time and position in a readable format on any non-volatile media (Nutter, 2008). As this information is presented on the screen of the devices during normal use, the information should be available in its volatile Random Access Memory (RAM) while operating. This paper describes two methods for making forensic copies of this memory and some results on its analysis.

After noting the work of others which was used during the research in Section 2 an overview of the TomTom devices and their differences is shown in Section 3. Also, the anatomy of a TomTom navigation device is explained and the circumstances in which system power is retained are given.

In Section 4 the first method for copying the data retained by the RAM is presented; the JTAG method. This method uses the JTAG connector found on the mainboard of most TomTom devices to copy the content of the RAM.

Section 5 introduces the second method for reading the RAMs content. This method, called ‘TomCopy’, is based on a small Linux distribution on an SD card.

After copying the content of the RAM, the acquired image should be analysed and decoded. In Section 6 two methods of decoding the RAM image with scripts and tools are presented.

The results of both methods for copying the data retained by the RAM on TomTom navigation systems are discussed in Section 7. Both methods can be improved upon. The ideas for improving these methods are discussed in Section 8.

Section snippets

Previous work

As acquisition of the non-volatile media of TomTom navigation systems could be done using common available tools, the analysis of data stored on these was the primary focus of the forensic community and information on this topic was already available from various sources. Siezenga (2008) described the structure of the configuration file stored on the non-volatile media in dept. His description of this file was used during analysis to decode items like favourites and the home location. Nutter

TomTom hardware overview

There are a lot of different TomTom devices. The TomTom devices are normally placed on the market in series; for example the Go 300, 500, 700 serie, the Go 510, 710, 910 serie and the Go 740, 940 serie. Between the devices in one serie the differences are for example the size of the memory, the availability of bluetooth or whether there is a hard drive or a memory card. For the Go 740 and 940 there even is a possibility for a SIM-card to be inserted in the device for receiving traffic data.

JTAG method

One method for making a copy of the content of the RAM is using JTAG (Breeuwsma, 2006). JTAG stands for Joint Test Action Group and is also referred to as boundary scan. With JTAG it is possible to test and debug an embedded system at various levels of the design and production. Using JTAG it is possible to stop the processor and gain access to the memory space of the device, thus allowing the data retained in RAM to be read without changing the content.

The main processor of a TomTom Go 500 is

TomCopy, custom kernel method

Of the whole range of TomTom navigation systems, quite a few are equipped with an SD card interface as their primary or secondary storage facility. Tests had shown that when an SD card containing a bootable system image was inserted, the navigation system would boot this image regardless the presence of an other image on an internal storage device. Any software which had been loaded into memory from the system image and executed, had full access to and control over all available hardware of the

RAM memory analysis

For the memory copies made using the JTAG or TomCopy method to be useful, they had to be analysed and searched for relevant data. The first data to look for was date–time information related to GPS-positions, as this type of data could not be found on any non-volatile media.

An image taken from the RAM of a TomTom Go 910 that had been in normal use for a few days was first analysed by running it through the program “strings”. In the output, NMEA protocol strings4

Results

Using the JTAG method as described in Section 4 and the Linux distribution TomCopy as described in Section 5, copies of the Random Access Memory of TomTom navigation systems were made. The JTAG method was tested on the TomTom Go 300, Go 910, Rider 2nd Edition and One XL. The method was unsuccessful on the One XL due to the different processor used in this model. The method was not tested on the Go 940 Live, due to the absence of the JTAG connector as described in Section 4.1 (Table 5).

The JTAG

Future work

Both methods have room for improvement. The method of reading the RAM by JTAG can be improved upon by halting the device before the bootloader is loaded into memory. This might be achieved by attempting to read data, like the device id, on the JTAG chain and halt the processor as soon as valid data is read. This way, no RAM will be consumed by the bootloader and up to 3 MB of data might be saved. Investigations are being made to establish this improvement using the OpenOCD software.

Another

Acknowledgements

The authors wish to express their thanks to all colleagues for reviewing early versions of this paper and providing assistance to the required experiments. Especially the comments and suggestions provided by Ronald van der Knijff and the assistance by Marcel Breeuwsma for finding the layout of the JTAG connector is very much appreciated. Furthermore, the authors wish to express their gratitude to the members of the open source community in general and the OpenTom, OpenOCD and OpenMoko project

References (20)

  • B. Nutter

    Pinpointing TomTom location records: A forensic analysis

    Digital Investigation

    (2008)
  • M. Breeuwsma

    Forensic imaging of embedded systems using jtag (boundary-scan)

    Digital Investigation

    (2006)
  • busybox

    busybox

    (2009)
  • Farnell

    Farnell

    (2009)
  • google, Kml

    (2009)
  • GoogleEarth

    Googleearth

    (2009)
  • GPSBabel

    Gpsbabel

    (2009)
  • Hallinan C. Embedded linux primer;...
  • H. Luttikhedde

    Update: Tomtom blijft mikken op 30%-marktaandeel vs

    (Jul. 2008)
  • N.F.I., rdd

    (2009)
There are more references available in the full text version of this article.

Cited by (15)

  • Challenges and opportunities for wearable IoT forensics: TomTom Spark 3 as a case study

    2021, Forensic Science International: Reports
    Citation Excerpt :

    However, there was no detailed correlation of how these forensic artifacts could be used in a forensic investigation or related scenarios. Previous forensic analyses of TomTom devices have focused solely on their satellite navigation devices as demonstrated in studies by [22–24]. None of these papers, however, covers the forensic analysis of TomTom smartwatches and identified up to date forensic artefacts on all sources of evidential data ( IoT device, mobile app, and event logs) to aid forensic investigations.

  • Identifying 3D printer residual data via open-source documentation

    2018, Computers and Security
    Citation Excerpt :

    Residual data resident on a device can be empirically determined by examining the constituent memory components. This approach has been applied to a variety of device types, including Global Positioning Systems (van Eijk and Roeloffs, 2010), smartphones (Grispos et al., 2013), and multifunction copiers (Lee et al., 2011; Rackley and Griffin, 2008). Practitioners tasked with investigating new device types, be it for forensic or security related purposes, however, do not have the luxury of relying on previous work and, with the variety present in AM device architectures, examination of only the device may be insufficient to discover the entirety of the residual data footprint left by its printing process.

  • A novel file carving algorithm for National Marine Electronics Association (NMEA) logs in GPS forensics

    2017, Digital Investigation
    Citation Excerpt :

    Since the GPS data received by GPS receivers (referred to as NMEA data) comply with the NMEA 0183 standard, those data should also exist in the Random Access Memory (RAM) of GPS devices. For example, the authors of (Van Eijk and Roeloffs, 2010) proposed an approach referred to as TomCopy to dump the RAM of TomTom devices and extracted some NMEA data from the acquired RAM image. Besides, the authors of (de Sousa and Gondim, 2016) focused on the RAM of Android devices and found these devices also utilized NMEA 0183.

  • Forensic analysis of newer TomTom devices

    2016, Digital Investigation
    Citation Excerpt :

    The first generation TomTom devices were thoroughly examined by Nutter (in press), whereby the different file types were identified and decoded. The volatile RAM memory of these devices has also been examined, as described in van Eijk and Roeloffs (2010). Although not a great deal of data was found in the volatile memory, at least there was a general method for the extraction of the contents of the RAM.

  • The Linux FAT32 allocator and file creation order reconstruction

    2014, Digital Investigation
    Citation Excerpt :

    It is an ARM embedded system running a Linux kernel (compiled for the ‘ARMv4T’ subarchitecture), with a fairly conventional user space environment consisting of the proprietary and closed source core navigation software, a BusyBox userland, the GNU libc6 C library, and some other open source libraries (TomTom International BV, 2014). Due to reverse engineering efforts by open source enthusiasts, users can quite easily run custom programs and even custom kernels on the device (OpenTom.org, 2013)—permitting development of forensic RAM acquisition software as described in Roeloffs & van Eijk, 2010. The Go 930 is not a novel model.

View all citing articles on Scopus
View full text