gps

Crime Scene Investigation of GPS Data in Unmanned Aerial Vehicles (UAVs)

by Chirath De Alwis

The invention of the Unmanned Aerial Vehicle (UAV), also known as the drone, has the potential to address some crucial issues in society. Commercial aerial surveillance, oil/gas/mineral exploration, and disaster relief are some of them [1]. Considering the increasingly popular use of drones, it is evident that there is potential for them to be used in crimes. This demands forensics investigation.

When it comes to analysis of drone artifacts, GPS data plays a huge role. It is vital to answer to questions like where was this drone flying? From where this drone was sent? This article describes evidence acquisition from drones and extraction of GPS information from drone artifacts.

Drone Structure

To operate a drone requires the aircraft, a mobile device, battery, camera, radio controller, and/or Wi-Fi range extender (some models do connect using Wi-Fi). The structure of a drone can be vary based on the vendor, design and purpose. But most commonly, drones consist of a main board, GPS module, gimbal image stabilization, and sensors.

A diagram of a UAV's basic components
Figure: Basic components of a drone [2]
Figure: Components of DJI Phantom 4 Pro

Evidence in Drones

A drone’s primary evidence is stored in the mobile device connected to both the drone and its remote controller. To control the drone requires a controlling application inside the mobile device connected to the controller system. DJI Phantom 4 Pro drones use the app “DJI GO 4,” available in both Android and iOS. This application primarily stores data inside its application folder and provides the capability to the user to upload the files into DJI cloud.

Once these local files are synchronized to the cloud, users can delete them from the local storage. It is important to know that users have an account to login to. To get the previous flight details, users have to login into their respective account using DJI GO 4 applications. The same drone can be used or controlled by different users by connecting each of their mobile devices to the controller, but flight information from these captures will not available in the original user account.

The DJI Phantom 4 Pro contains a 4GB SD card as its primary storage medium. In some drone models, this storage medium is glued into the board. This chip also contains some interesting files when it comes to analysis. Since this DJI Phantom 4 Pro drone does not connect to its controller via Wi-Fi, we cannot perform wireless connection to this drone.

Figure: SD card glued into the board [4]

Evidence Acquisition

Data Acquisition from Drone

Linux is the predominant OS for onboard UAV systems and it is possible to perform mobile forensic techniques to collect the data from the drone. It is possible to dump the file system directly from the drone using the “DD” Linux tool. Following is a command to perform this function: [3]

ssh 192.168.1.1 -l root “dd if=/dev/mtdblock3 ” | dd of=root.dd

Data Acquisition from SD Card

We can get the data directly from the SD card by connecting the SD card to the workstation, or we can access the SD card though the drone itself.

Data Acquisition from Mobile App

A considerable amount of data can be extracted from the DJI GO 4 mobile application. This data can be extracted using normal mobile forensic methods. If the device run iOS, then it is possible to extract data from iTunes. If the device is Android, it is possible to extract data from via the Android Debug Bridge (ADB).

Analysis of GPS Locations

Apart from recorded videos and pictures, the most interesting and important information that can have a forensic value is GPS information. When investigating GPS data from drones, there are three main places where GPS data is stored.

  1. Inside the application (flight details)
  2. Inside the drone
  3. Inside the captured files (videos and pictures)

From Flight Logs

Flight details are recorded inside the mobile application. In order to extract flight logs it is required to log into the account and synchronize data into the cloud. If the data is not stored in/synchronized to the cloud, then the data is stored inside the mobile device.

Following are the list of steps required to export flight logs from the DJI Phantom 4 Pro:

  1. Connect to the DJI GO 4 app.

2. Select the drone type.

3. Select Flight Records from the menu in the top right corner.

4. Now it is possible to see all the flight details. Select the flight you need to export.

5. You can view the flight path here as well.

6. Click Export.

Once export is successful, these flight records are available inside the application folder and normal mobile forensics techniques can be used to extract these files. These flight records are stored in “.txt” file format and the naming convention will look like “DJIFlightRecord_2017-07-11_[15-25-14].txt”. Some flight records contain pictures, and these can be carved using header- and footer-based file carving techniques.

Drone activity since the drone started to fly is recorded inside the “2019-01-18_10-43-24_FLY812.DAT”  file. This file can be opened and viewed using the “CsvView” tool. This tool converts .DAT file into .CSV format.

Figure 4: Motor Speed from .DAT file

These flight records contain lot of information. Some interesting data includes aircraft name, date, maximum altitude, maximum speed, landing battery, takeoff battery, sensor information, images, controller average response time, etc. These details can be extracted using the “app.airdata.com” website [6].  Since this tool does have a paid version, using paid version avoids publishing flight data for public use.

Figure: Flight Information from Flight Log
Figure: Ground Weather from Flight Log

Figure: Cell Deviation and Cell Voltage from Flight Log
Figure: Remaining Battery from Flight Log

Apart from these details, it is also possible to visualize the flight path. Phantom Log Viewer [7] is another online viewer that can be used to visualize this information. Forensic use of this tool is not recommended, as it can make uploaded data publicly available. Therefore, it is recommended to use “CsvView” tool to visualize the data.

Figure: Flight path from Phantom Log Viewer

From Image Metadata

Image metadata contains some useful information for forensic investigations. It is possible to get the GPS information from image metadata. The data can be found from file properties or by uploading the file to “pic2map” [8]. For forensic use it is recommended to use file properties and input the coordinates directly to Google Maps.

Figure: GPS coordinates from file metadata
Figure: GPS location from file metadata using pic2map

From Drone Captures

By default, drone captures do not contain GPS information. It is required to enable GPS from the application settings.  In order to enable this in the DJI GO 4 app, the user must enable “video capture” from the settings. The following picture depicts this step.

Figure: enable video capture using DJI GO 4

Once this video capture is enabled and starts recording, it creates two files: a main video file, and a new file with an .SRT file extension. This .SRT file contains the GPS locations and can be analyzed using https://tailorandwayne.com/dji-srt-viewer/. For forensic analysis, it is recommended to use the “CsvView” tool. Some drones, like the Phantom 2 Vision+, store the GEO information along with the video files in a new file with an .EXIF (Exchangeable Image Format) extension.

Figure: SRT file
Figure: SRT view output from tailorandwayne.com

Reference

  1. https://www.dummies.com/consumer-electronics/drones/popular-uses-for-drones/
  2. https://dronelife.com/2016/09/06/top-5-drone-component-companies/
  3. https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1492184184.pdf
  4. https://dfrws.org/sites/default/files/session-files/pres_drone_forensics_program.pdf
  5. https://commons.erau.edu/cgi/viewcontent.cgi?article=1513&context=jdfsl
  6. https://app.airdata.com/flight/last
  7. https://www.phantomhelp.com/LogViewer/Upload/
  8. https://www.pic2map.com/

 

About The Author

Chirath De Alwis is an information security professional with more than four years’ experience in Information Security domain. He holds BEng (Hons), PGdip and eight professional certifications in cyber security and is also reading for his MSc specializing in Cyber Security. Currently, Chirath is involved in vulnerability management, Threat Intelligence, incident handling and digital forensics activities in Sri Lankan cyberspace. You can contact him on chirathdealwis@gmail.com.

Mobile Device Geotags & Armed Forces

In recent years it has been noticeable that the amount of people carrying a smart phone has increased exponentially. This is down to their low price and availability; even children as young as 12 have a smart phone. However, most people who own a smart phone are not aware of the data hidden in even the simplest and most innocent things they do on their phones. This includes armed forces staff. This article will look at the issues and possible repercussions of the availability of such easily obtained data.

Let’s consider a scenario:  in this case an armed forces staff member is on patrol. they take a picture of themselves and upload it to a social media. Their personal profile on this site is not secured or has limited access that allows anyone to view their photos. A militant group happens to be doing some research on their “enemy”. They use advanced search on Google then happen use the correct collection of words or phrases, and just happens to find this picture. What could possibly happen?

First off, the basics:

What is a geotag?

The method of geotagging is the addition of geographical data into the meta data of an object, in this case a picture that has been taken by armed services personnel.

A geotag on a photograph from an Iphone, for example, captures the GPS coordinates of the location it was taken using Longitude and Latitude.

Obtaining geotag information

Using free tools that are widely available on the internet it can take seconds to reveal the geotag information. It requires very little effort and absolutely no training. Ideal for militant groups who would want to find this information relatively quickly.

Below is an example and for this example I will be using a picture of the blue ball in snooker, but imagine this photo was a team photo taken in a base on foreign soil.

Here I’m using Evigator’s TAGView software

(available @ http://www.evigator.com/)

1 – Locate the image and open it using the Open Image Icon.

1

2 – Press Open

2

3 – The Image will be analysed and you will have a screen similar to below:

3

4 – Sample data from the analysed picture.

4

As you can see from the above, highlighted is the geotag data & various information about the device the picture was taken on. Also note the mapped location of where it was taken. To get this information was less than 3 seconds once loaded into the program. 

Security Risks & Repercussions

So what are the security risks? Well, as already pointed out the information could reveal any number of things: barracks, bases, patrol points or even patrol patterns. This information not only puts the staff member who uploads the pictures in danger but their entire deployment group.

Potential death is not the only issue, with profiles being insecure it could lead to that one member being profiled by the militant group, this then leading to potential blackmail, kidnap or endangering family members.

What should the armed forces be doing?

There are many things the armed forces could be doing. The key thing to do is offer the training necessary to remind their staff of the issues of geotags and smart phones. They could put a ban on any personal phones completely. However, some service men and woman would still find a way to take them into active duty.

A one hour basic training session that shows the dangers is all that is needed. The session could cover basic security settings of their social networking profiles and turning off the location services on any of their devices.

A one hour session could be the difference between life and death in most cases during deployment.

This article has been geared towards the idea of militant groups, however its not just militant groups, it could be anyone; stalkers, thieves, even an enraged ex could use these techniques.

 

Part 2 will be released soon. 

Android Tracking – from a forensic point of view

– Introduction –

In my last article on iPhoneTracking, I tried to explain Apple’s crowd-sourced location based service. Obviously Android has to do something similar to provide a good user experience using location based services…

Also back in April 2011 some people, who wrote stuff about iPhoneTracking, also mentioned Android with a sentence or two without going to much into detail. So, what I would like to provide with this article is a more detailed discussion especially suitable for mobile forensic investigators.

Why doing caching at all

As I am an iPhone user from the very beginning in 2007, when I first held a freshly installed Samsung Galaxy i5800 in my hands, I was quite disappointed by the user experience of Google Maps! But to be successful and in order to compete with iOS, Android is in desperate need for stuff like indoor and most of quick localization. From what I know, Android offers quite the same features as iOS, but each device manufacturer has the possibility to brand his own stuff, even with different settings and last but not least Android seems to be more restrictive concerning privacy settings.

But one step after another…

– First tests / First hands on –

Sample Files (foreign data)

Because of the lack for a test device, my first sample files were kindly provided by a German security researcher from the FH Brandenburg. From what he told me, the data was collected over a total time of 2 weeks. So, once again, I was quite disappointed, that only 1 valuable cell location and 6 valuable wi-fi locations were reported (see below):

cache.cell
                 key   accuracy confidence       latitude      longitude            timestamp
     262:2:309:54101       1225         75      52,x67885      13,x90695  16.11.2011 08:21:48
   262:2:65534:65535         -1          0       0,x00000       0,x00000  16.11.2011 08:21:48

cache.wifi
                 key   accuracy confidence       latitude      longitude            timestamp
   7c:4f:b5:df:ef:cf         -1          0       0,x00000       0,x00000  16.11.2011 08:21:48
   bc:05:43:eb:90:8f         75         87      52,x66898      13,x90329  16.11.2011 08:21:48
   88:25:2c:22:06:a2         72         92      52,x66372      13,x89764  16.11.2011 08:21:48
   54:e6:fc:b6:57:88        182         82      52,x66961      13,x90662  16.11.2011 08:21:48
   00:1f:3f:d0:59:7a         75         87      52,x66441      13,x89421  16.11.2011 08:21:48
   00:09:5b:da:2c:be        176         87      52,x66774      13,x90851  16.11.2011 08:21:48
   00:23:08:82:69:87        113         87      52,x66436      13,x91162  16.11.2011 08:21:48

My first impression was, that it seems to be quite the same scenario like in iOS (multiple entries to a single timestamp) but with much less data cached. I have had a little conversation to get a better idea of how to interpret the recorded(?) data, but the most obvious problem was: the data were not mine.

Test Device (my own data)

Then, on my first day back in office in 2012 I was in luck getting a test device from my chief. It was a Samsung Galaxy i5800, that was not supported by any forensic investigation software we use.

So, to be honest: My first experiments were not forensic sound at all:

  • I installed a file browser (no files in /data/*)
  • I tried to “root” the device (no success)
  • I flashed the device to a newer firmware (Android 2.3)
  • I finally got the device “rooted”
  • I installed another file browser (yeah: files in /data/*)

But, there were no cache.cell, cache.wifi files anywhere on the device. Why not?

In “Location & Security” the option “GPS” was activated. But in order to enable caching it is also necessary to enable “Use wireless networks”!

Finally, I got the desired two files… Jippie!

The files are very small (under 5kb), so: I simply synced them with Dropbox in order to keep different versions for different investigations I wanted to carry out after different location-based operations like taking photos, navigating or using google maps.

– Some basics explained –

How does Google-Crowd-Mapping work

I found a thread in a google product forum describing the process like this:

If your location is being incorrectly detected by a Google Maps or Latitude using Google’s cell ID (cell tower) or WiFi (wireless network) location database, you can help provide updated info to correct Google’s database using Google Maps for mobile. At this time, you cannot provide individual updates to Google’s location databases, though they are being updated and improved constantly over time.
Open Google Maps on an Android 2.0+, Windows Mobile, or Symbian S60 phone and enable GPS. While Maps is simultaneously connected to a GPS satellite and a cell tower or WiFi router, you will be providing updated anonymous geographic data for the cell tower or WiFi router to which you’re connected. Please note that this data is anonymous and may require a significant amount of data from you and other users before changes are made to Google’s location database.
Android: You must enable Settings > Location & security > Use wireless networks and have previously given consent for anonymous location data collection. You can check if you’ve given consent by un-checking and re-checking the ‘Use wireless networks’ setting.

Also, the user experience is much better, when “Us(ing) wireless networks”. The time to retrieve the user-location is reduced substantially.

Decoding the byte stream

The cache-files are organized in so called java byte streams. As you can see below, within the byte stream “Input”, you can identify some UTF-Strings with additional non-printable characters.

To get a better idea of what data is stored in these files, I implemented “ByteStreamAnalyzer”. The idea behind that piece of software is to easily analyze the “Input” data with additional help features like bold-style-formatting the most obvious data type (1) with converting the retrieved value, for example into an UNIX-timestamp (2). Then clicking on the data-type (3) in the “Data” window moves the cursor further in the “Input” frame as well as adding the pattern to the “ParsingPattern” window.

The last step is then to start the parsing process by clicking (4) in the “ParsingPattern” window. Et Voila: See the result in the “Output”-Window at the bottom (5).

By now, the software is not really forensic sound, cause all text areas are editable. But it helps to get a better idea, of what is stored inside the cache-files. From what is my experience when examining different Android 2.3 files, the structure is as you can see below (and there is no additional data inside):

Structure of the byte stream

As mentioned by Magnus Eriksson (I think, he was the first one) in his python script at github, the structure is like this:

Heading Information (4 bytes sequence)

  • 2 bytes: Unsigned Short (version)
  • 2 bytes: Unsigned Short (Entry Count)

Location Entry(ies) (loop sequence)

  • x bytes: UTF-String (Cell-Information or MAC-adress)
  • 4 bytes: Integer (transmission range)
  • 4 bytes: Integer (confidence)
  • 8 bytes: Double (latitude)
  • 8 bytes: Double (longitude)
  • 8 bytes: Long (UNIX-timestamp)

What are the refresh rates / the limits?

Magnus Eriksson also presented some older Android source code fragments, that stated the limits:

// Maximum time (in millis) that a record is valid for, before it needs
// to be refreshed from the server.
   private static final long MAX_CELL_REFRESH_RECORD_AGE = 12 * 60 * 60 * 1000; // 12 hours
   private static final long MAX_WIFI_REFRESH_RECORD_AGE = 48 * 60 * 60 * 1000; // 48 hours

// Cache sizes
   private static final int MAX_CELL_RECORDS = 50;
   private static final int MAX_WIFI_RECORDS = 200;

My experiences from Android 2.3:

  • the data get refreshed as the location changes significantly and location based apps are used
  • stored for a maximum of 14 days or when the cache is filled up (cell: 50, wi-fi: 200)

– Forensic Investigations –

In order to get everything out of the Android location-cache-files, you need to inspect two files:

  1. cache.cell
  2. cache.wifi

The files can be found on the device within the folder “/data/data/com.google.android.location/files/”

With AndroidTrackerLE, you can load two files at the same time. After loading both files, it is possible to perform different tasks like:

  1. select Cell Towers as Input
  2. select WiFi Access Points as Input
  3. enable position estimation(*)
  4. enable transmission range visualization(*)
  5. choose multiple timestamps to render either cell towers or wi-fi antennas on the map
  6. retrieve more information on a specific location item by clicking on it
  7. and last but not least create a forensic report.

(*) free registration is required in order to get these features, see below for further information.

Position estimation (cell towers)

In my tests, I never saw a more than 1 cell tower at a specific timestamp, so position estimation is unnecessary for cell towers.

Position estimation (wi-fi hotspots)

For estimating the best/nearest wi-fi access point, it seems to be that the MAC address from the nearest hotspot is send to google and google sends back up to 10 MAC-adress/geolocation items that are saved all with the same timestamp. From my experience, I can tell, that the first entry is the actually connected or at least nearest wi-fi hotspot.

Position accuracy

As you can see from the above picture, cell- and wi-fi location entries are

  • often combined (cell/wi-fi) at a specific timestamp (5) and
  • the combined wi-fi hotspot lies inside the cell tower transmission range area with the
  • device normally located inside the wi-fi transmission range area.

These information seem to be very accurate in contrast to my experience with location estimations retrieved from Apple’s databases.

Sometimes, there are inconsistent combinations reported, where the wi-fi location is not reported within the  transmission area. In these cases, from what was my experience, the actual location is neither within the cell- nor the wi-fi transmission range as can be seen below. The actual position was, where the yellow star is painted.

When there are singular timestamps reported, the position has to be validated from other sources, although all timestamps I examined where accurate.

– Conclusion –

Comparison between Android and iOS

The most obvious difference between location cache data from Android to iOS is the file structure:

  • Android uses a binary byte-stream
  • iOS uses a SQLite File

Another major difference is the file size: 

  • Android from ~2kb to ~10kb
  • iOS from ~30kb to ~12mb

From what is my experience, the data is very limited, but therefore very accurate. The transmission areas are much more concentrated than on iOS.

On Android devices any kind of harvesting data is non existent . More likely it seems, that harvested data is send to google right away, when using wireless networks in addition to GPS.

I can not really confirm that an entry has to be updated after a certain time.

What else?

In the meantime I finished AndroidTrackerLE v. 1.1. I will provide AndroidTrackerLE FREE for LawEnforcement agencies through a download from a restricted website. You may contact me by mail: 4rensics@gmx.de or leave a comment.

Thanks for reading this far and feel free to shoot my an email or leave a comment!

Also see my post on iPhone Tracking – from a forensic point of view

iPhone Tracking – from a forensic point of view

– Introduction –

iPhoneTracking is sexy!!! Every mobile forensic suite, at least the ones dealing with iPhones, are providing it proudly. iPhoneTracking also has been a hot topic in the media all around the globe. People stated, that there is a way to display every step of an iPhone user ever since the device got bought. Hm… Sounds great for all kind of investigations! Let’s see…

Apples Point of View

Apple, on the other hand, stated that: “in no way Apple does tracking movements of iPhone users”. What Apple admits is to provide a well designed CoreLocation Framework.

(Apple Inc)

The goal behind CoreLocationFramework is to provide location based services being:

  • Available instantly everywhere, all the time, but
  • also resource friendly, saving battery life.

The Location sources or maybe the problems to be solved are:

  • GPS (is not available inside buildings, eats up battery-lifetime)
  • Cell towers (have no geo-coordinates available)
  • Wi-Fi hotspots (have no geo-coordinates available either).

The solution would be to provide geo-location information from the built-in GPS sensor when necessary and available and some kind of fall-back location estimation inside buildings or whenever GPS is not (yet) available. Most iPhone users do have mobile service and Wi-Fi enabled all the time. Cell towers and Wi-Fi hotspots can be concerned to be quite stable regarding their geo-location. And: there are several signal-stations availble all around the position of the user that can be used to calculate the actual position on base of triangulation. The problem for Apple is to build up a map, that has to be up-to-date and for best at no additional costs *smile*. How to achive that? I think, it is achieved by a mechanism, I call…

Swarm-Mapping

Swarm-Mapping procedure

Apple has sold milllions of GPS-trackers (they call them iPhone) with additional mobile-/WiFi-chips. They can rely on a lot of iPhone users out there to provide data, even not knowing they do.

In general Swam-Mapping consists of three steps:

    1. Collecting data from enabled (and available) signal sources when CoreLocationFramework is active
      • on the iPhone recording current GPS-position and surrounding Cell Towers and Wi-Fi-hotspots infos
    2. Submitting the collected data to Apple
      • where the data is consolidated with already collected location informations from other iDevices
    3. Providing Data back to the iDevices
      • when requested from different location-based services.

I would like to provide a simple example for the consolidation process:
Lets think of three people on their way home… They do not use the same, but nearly the same way, receiving the same cell towers and Wi-Fi hotspots. With collected GPS data from different positions it is possible for Apple to refine the position for every seen radio source.
Now imagine thousands of people (maybe also the same user on the way to work the next day) providing location data for the same radio transmitter from different GPS-locations again and again.

iPhone Tracker – Pete Warden

http://petewarden.github.com/iPhoneTracker/

One of the first persons, who brought the attention on this topic to the people in the public, was Pete Warden. He and his colleague Alasdair Allan provided a tool called “iPhone Tracker” to display the location informations saved on an iPhone.

(Screenshot: iPhoneTracker, Pete Warden)

What does the tool do?

  1. It searches for the SQLite3-database “consolidated.db” in the mobile backup of iTunes
  2. extract informations from the tables
    • CELLLOCATION and
    • WIFILOCATION
  3. displays the geo-location information on a map in correlation to the timestamp, when the coordinates were received also regarding the amount of coordinates received for one certain timestamp.

My first experiences with iPhone Tracker from Pete Warden were, that

  • the tool isn’t using real GPS-Data from the iPhone
  • so the data are not accurate (why is there a grid?)
  • and the data-sources are not distinguished
  • the tool is not very user-friendly
  • only one timestamp selectable at a time
  • no resize of the window provided

I was quite dissapointed, cause it definitely was not forensic sound in any way! I then had the idea to develop my own framework. I’ve had already a tool displaying maps using the jxMapKit-framework for OpenStreetMap and another tool reading data from sqlite3-dbs. No big step to combine these tools into what I call a forensic suitable iPhoneTracker tool.

– Forensic Investigations –

my iPhoneTracker – first beta

My very first version did provide the following:

  • no grid alignment of the data
  • distinguish different data sources (CELLLOCATION, WIFILOCATION)
  • display specific timestamps
(Screenshot: iPhoneTrackerLE)

But more than that, I got a framework to examine data from a trusted, well known data source; my own iPhone. With this tool, I examined my different consolidated.db’s in correlation to my calendar 😉

I figured out, that there are more than just the consolidated-data provided by Apple used by Pete Warden’s iPhoneTracker. As stated above in the Swarm-Mapping chapter it is obvious, that Apple has to rely on location data of either celltowers or WiFi hotspots in order to provide an assisted GPS feature on the iPhone. They could buy the information from different providers, who have built up their own location-databases, but the problem is, that the location of the antennas or devices are not published by mobile carriers (celltowers) or are not known generally (WiFi hotspots). Beside that, the location informations are not totally static. Provider add celltower antennas and private people change their WiFi-hardware without informing anyone *smile*. So why not collect the data with the help of millions of iPhones all around the world? Brilliant! Ok. I mentioned that already.

From a forensic point of view, both kind of entries (received from Apple / recorded by the iPhone itself) exist within the database and need to be examined towards their forensic relevance. I will go into detail on that just in a minute.

For now, it can be stated, that neither the iPhoneTracker provided by Pete Warden nor actual commercial forensic products are usable in court regarding the forensic reliability of tracking informations!!!! (If you disagree in this; feel free to shoot an email or a comment to me; as long as you provide your product name and a free evaluation copy *cough*)

– Location Data provided by Apple (I) –

CellLocation, WiFiLocation

I further examined the data provided from Apple:

  • CELLLOCATION
  • WIFILOCATION.

At first, I took a closer look at the table data:

Both tables provide nearly the same information:

  • an Individual Representation of the source for later location estimation
    • MCC, MNC, LAC, CI (for celltowers)
    • MAC (for WiFi hotspots)
  • a Timestampin CFAbsoluteTime format
    • when the location information of the device was retrieved,  that is, when location services were used and the location daemon needs to be updated.
  • the Location of the device
    • Latitude, Longitude,
  • the Horizontal- and Vertical- Accuracyof the device
    • to be interpreted as the transmitter range of the device (therefore celltowers do not transmit vertical, so the value is -1.0, many WiFi hotspots do have more than one antenna to provide a more all around transmitting range)
  • the Altitudeof the device
    • the Altitude of celltowers is 0, because the greater divergence resulting of a higher transmitting range
  • Speed / Course
    • not used
  • and the Confidenceof the source
    • to be interpreted as the reliability of the source
    • 50-70 for celltowers, maybe in relation to the consolidation experience from Apple
    • 50, “to be or not to be”, or 50% of reliability

Experiences and Problems

From what were my first experiences and from a forensic point of view, the location entries provided from Apple (CellLocation, WifiLocation) are not usable at court! One main problem is, that the entries in the table are derived from Apple as base information to the actual position estimation process. The data is not retrieved from the built-in GPS-sensor (the device itself).

There are several other problems, which I would like to outline:

There is no exact position of the device or user at one specific timestamp

The result data is not presenting only one location of the device at a specific time, but rather a set of cell towers or Wi-Fi hotspots around the estimated position of the device.

The center point is a rough estimation of the location, but not guaranteed. (The blue arrow describes the route I took with the car, the red cross the location I have been at that time)

The estimation of the actual position can be derived from other available sources

One of my suggestions is, that the iPhone uses the location of the actual used celltower or an estimated location of the IP-address you are using over Wi-Fi, when the GPS-signal is not available inside a building.

The red cross is the location I resided at the selected timestamp.

The result data from Apple might also include unconsolidated data

for instance, when Wi-Fi hotspots got “moved” or because cell tower antennas are not reachable from every direction.

The figure above shows the recorded Wi-Fi hotspots the day I was at the Cebit fair 2011 in Hannover, Germany. There were a lot of exhibitors from all over Europe, who used their own Wi-Fi hotspots which were formerly consolidated to their home-/ business-location. For that reason it is explainable, despite of residing in Hannover without moving to other countries, the iPhone saw MAC-Addresses from devices, all over Europe. Some Wi-Fi hotspots were even reported at locations in India and Asia!!

It would have been interesting to observe, if the hotspots would get consolidated through Apple to show the actual location in Hannover right the day after. But this is not the scope of this article. It is just another example, that it is not possible to get an exact movement profile of an iPhone user with that source of data (CellLocation, WiFiLocation). But maybe, there is more inside the database…

– Location Data collected by the iPhone itself –

Swarm-Mapping how it actually works

As I further examined different consolidated.db files, I came across a table containing 2401 timestamps from only one day with only one location-information for every timestamp. The data shows exactly the route I took, and the timestamps were recorded with an interval from seconds. I used Navigon MobileNavigator to navigate…

So: It is obvious, that Apple (or better: the LocationDaemon) records tracks of its users (*smile*)

The problem with these tracks: the waypoints do not contain any references like cell towers or WiFi hotspots to be consolidated and useful for others. But: There exist the so called “harvesting”-tables containing much less, but more interesting data. According to the timestamps and waypoints recorded in the CellLocation-table, the data in LocationHarvest and WiFiLocationHarvest save cell towers and WiFi hotspots seen from the actual GPS-position.

Harvesting Tables

As stated before, Apple needs to get data from users to build up the consolidated database. In summary, there are three different harvesting tables:

  • LOCATIONHARVEST (GPS-position recorded from GPS-Applications)
  • CELLLOCATIONHARVEST (strongest cell tower seen from the actual GPS-position)
  • WIFILOCATIONHARVEST (strongest WiFi hotspot seen from the actual GPS-position)

These tables usually do not contain any data due to the fact, their content gets deleted right after the data is successfully submitted to Apple. As for iOS 4.3.3 and later, the data gets submitted to Apple, as one of the first actions, when there is a WiFi-connection available. As far as I can say, the data is not transmitted over a mobile service network connection cause it would stress the mobile plan and would definitely mean more bad press for Apple. For safety, one of the first actions when seizuring an iDevice definitely is to put it into “flight mode”!

So: most of the time an investigator examines the harvesting tables, they might be empty. Nevertheless, I had luck to preserve a well populated consolidated.db before the transmission process towards Apple cleaned up the tables.

LocationHarvest

The table records the following information:

  • an individual Timestampfor every location with very short intervals
    • in CFAbsoluteTime format
  • Latitude, Longitude and Altitude values as expected for a location service
  • Horizontal- and Vertical- Accuracyvalues
    • maybe used for describing the exactness of the actual position information
  • navigation information like
    • Speed in m/s and a
    • Coursein degrees of direction meaning
      • 000 = north
      • 090 = east
      • 270 = west and
      • 180 = south
  • Confidence seems to be 90 all the time, which means, that information from the GPS-sensor seems highly valuable for the location service
  • TripId and Context maybe for internal use, though they are not reused in other harvesting tables as far as I can say, don’t know what they describe exactly

Within the tables I investigated, there weren’t more than the maximum of 2 routes recorded due to the fact, that after submitting the data to Apple, the data gets deleted as stated before. But this might be different, for a device seized on a journey with no possibility to transmit the information over WiFi. So put the device in “flight mode” right after seizuring the device!

CellLocationHarvest

The table records the same information as the CellLocation table:

  • an Individual Representation of the source for later location estimation
    • MCC, MNC, LAC and CI
  • a Timestampin CFAbsoluteTime format
    • describing the time, the GPS-position of the device was recorded
  • the Location of the device
    • as Latitude, Longitude and Altitude values
    • determine the location of the iPhone itself, not the celltower
  • Horizontal- and Vertical- Accuracyvalues
    • to be interpreted as the maximum derivation of the GPS-data
  • and the Confidenceof the source
    • to be interpreted as the reliability of the source
    • with 90 as the highest possible information cause of GPS

as well as additional information like:

  • the mobile Operator
    • in my case t-mobile Germany
  • the BundleId
    • naming the application, which is to be the source of the information
  • and navigation information like
    • Speed in m/s and a
  • Coursein degrees of direction meaning
    • 000 = north
    • 090 = east
    • 270 = west and
    • 180 = south

Keep in mind, that the presented geo-location is not the position of the cell tower itself but the location the device resides at the time, when the different cell towers were seen. This is exactly the same with the data recorded within the next table…

WiFiLocationHarvest

The table records the same information as the WiFiLocation table:

  • an Individual Representation of the source for later location estimation
    • the MAC-adress
  • a Timestampin CFAbsoluteTime format
    • describing the time, the GPS-position of the device was recorded
  • the Location of the device
    • as Latitude, Longitude and Altitude values
    • determine the location of the iPhone itself, not the celltower
  • Horizontal- and Vertical- Accuracyvalues
    • to be interpreted as the maximum derivation of the GPS-data
  • and the Confidenceof the source
    • to be interpreted as the reliability of the source
    • with 90 as the highest possible information cause of GPS

as well as additional information like:

  • the transmitting Channel
  • a flag describing the Visibility
    • Hidden: 0 = no, 1 = yes
  • the transmitting power
    • RSSI in decibel (?)
  • an Agevalue
    • (?)
  • the BundleId
    • naming the application, which is to be the source of the information
  • and navigation information like
    • Speed in m/s (in the case above 0) and a
    • Course of -1

CellLocationLocal

Last but not least, I discovered another table called

  • CELLLOCATIONLOCAL.

I invested quite some time to think about the data stored in this table. And I was to release this article with the words: „I don’t know what this table is all about“. The columns of the table look the same as in CellLocationHarvest.

The table contains only one entry most of the time, which is not updated to often.

But there is a major difference to CellLocationHarvest: Obviously, at least one entry preserves the WiFi-transmit of data to Apple. Because of that, I think the stored data might be also used by other applications for getting a faster GPS-fix. But only Apple knows for sure 😉

– Location Data provided by Apple (II) –

Back to the beginning… As I stated before, the main problem with the location data retrieved from Apple is, that there are always several location-entries received from Apple for one single timestamp entry. It would be nice to figure out one single geo-location at one timestamp.

I tried out different techniques:

  • the first entry,
  • the last entry,
  • the average over all points.

It was obvious to me, that it would not be an exact GPS-position, because from the idea of swarm-mapping I have, the actual position is calculated from different sources according to the different signal strength received. But one of the entries has to be at least in the range of the iPhone mobile or WiFi connection.

To figure it out, I combined different sources. As you can see below, there is a gps timestamp quite in the middle of the set of WiFi hotspots. The question is: which one fits best concerning the GPS position?

Is it the first, the average or the last entry for that timestamp… what would you guess?

Well. Long story short: for implementation aspects, it is very easy to take the first entry from every timestamp. After applying the horizontal accuracy value (range in meters) for this hotspot, you even get a better idea of where the iPhone has been.

From my further research, it has to be stated, that there is no general rule, which entry in the set of location-data retrieved from Apple fits best. In most cases the first entry, with horizontal Accuracy applied, gave the best results.

Conclusion

Position estimation helps a lot, but validating every timestamp still is necessary!!!!!!!!

My latest experiences regarding position estimation from consolidated-iPhone-data:

  • WiFi hotspots are very accurate (small transmission range), but may sometimes “move”
  • Cell towers are more stable concerning their positions but have greater transmission ranges

But if there are real GPS-informations from the harvesting-tables, you should prefer to look at them.

Thanks for reading this far and feel free to shoot my an email or leave a comment!

What else??

In the meantime I finished iPhoneTrackerLE v. 1.7 with great features like

  • using GPS-values recorded directly from the iPhone itself with course direction applied (I don’t think anyone else has included that in an iPhoneTrackingTool or Forensic Suite?!)
  • position estimation from Apple provided data (I did not see anyone else featuring this; all the other tools provide is a horrible amount of data to every timestamp)
  • providing the horizontal accuracy (the transmission range), which indicates even better, where the iPhone has been
  • internationalization (english, german) (help me to provide even more languages; all you have to do is to translate about 100 words…)
  • some minor bug-fixes

I will provide iPhoneTrackerLE FREE for LawEnforcement agencies through a download from a restricted website. You may contact me by mail: 4rensics@gmx.de or leave a comment.

See also my post on Android Tracking – from a forensic point of view

Geotags: Friend or Foe?

by David Benford
Director, Blackstage Forensics

I recently wrote a research paper, “Geotag Data: The Modification of Evidence on the Apple iPhone”, based around the possibility of modifying geotag evidence on the Apple iPhone. A test was performed as part of this project, to find out how easy it is to discover a person’s home location, social and business movements and background information.The process was begun by doing a Google Image search for the criteria “Blog iPhone self taken”. This was to trace an image taken by an iPhone for a personal blog, which would hopefully be of the user, hence “self taken”. In Google “Advanced Image Search” some changes were made, such as “Tall Image” and “JPG” file type being ticked; the theory being that most iPhone images are of portrait type and JPG format. An image appeared that seemed suitable of a woman photographing herself at the hairdresser’s. The image was saved and opened in TAGView which showed the location of the shop to be in a specific street in Oregon. As there is only one hairdresser listed in this street the process of selecting the correct business was straightforward. The image linked through to the woman’s blog and by doing a search, several more images taken on her iPhone were found complete with geotag data. The woman had taken a photograph of a magazine, mentioning that she was reading it at the dentist’s surgery. The surgery could be located within a minute and was found to be around the corner from the hairdresser’s shop. There was an image of a cake, along with its geotag pointing to Walmart. There was an image of her foot, taken in her kitchen, and the geotag gave an approximate location of where she lived. Images on the blog that were taken on her drive had no geotags. With an approximate idea of her home address, these could be used to pinpoint the exact property by viewing Google Street View. There were also non-tagged images of her family, giving further personal information. In the side margin of the blog there was a link to her Twitter page. Twitter displayed her actual name, where she was at any time and gave an even more detailed pattern of her movements, social life, family’s sports and hobbies, dining out preferences and so on. All of this information was derived from the source of just one geotag within a JPG image. This woman was potentially not only putting herself at risk, but also her family.

There appears to be many arguments on the web that the geotag feature being activated as default is not a well known fact amongst users. A very recent article published by the International Computer Science Institute in America supports this argument, along with the theories of the potentially dangerous nature of publishing data with embedded geotags. The authors, Gerald Friedland and Robin Sommer argue that websites such as Flickr having APIs which allow easy researching of specific criteria such as time, place and date can place unsuspecting users in a potentially vulnerable position, (Friedland & Sommer, 2010).

There is a strong possibility that similar search techniques could be adopted by paedophiles to discover the locations of young children. Innocent images, incorporating geotags, of children may have been taken by their family and uploaded to a blog for sharing with friends and family. There are many blogs that link through to social networking accounts that, when used together with the geotags, can assist in presenting a relatively clear picture of where a family lives, goes on holiday, works or socialises away from home, or can provide travelling times and school details. There are many cases of similar details being used by criminals for cybercasing and cyberstalking, as websites such as ICanStalkYou.com (URL no longer active) have highlighted.

There may also be an argument against the geotagging of images of endangered animals and birds. Geotagged online photographs of, for example, a rare bird sitting in its nest, could leave the bird vulnerable to poachers, egg collectors and hunters. With the availability of cameras, such as the Fujifilm Finepix XP30, that have in-built GPS, the proliferation of geotags may increase. With the XP30 being waterproof, it is particularly suitable for outdoor use and therefore for photographing wildlife.

Modification of Geodata

In my recent research I carried out processes proving that geotag data can be modified on the iPhone. These changes can be made either to JPG metadata on the device or to metadata within the iTunes backup files, which are then restored to the device. The benefit of the latter method is that it is less detectable when forensically analysing the iPhone than the method of modifying the images on the device itself. Obviously analysis of the computer where the changes were made in iTunes Backup should present artefacts, although the machine may not be available to the investigator to offer the evidence. This can be used to falsify evidence, such as creating a false alibi or in an attempt to falsely incriminate a third party.

 


Before modification
TAGView screenshot (click to enlarge)
After modification
TAGView screenshot (click to enlarge)

The same methods can be applied to other iDevices, such as the iPod and iPad, and with Apple projecting iPhone sales of 100 million handsets and 48 millions iPads for 2011, there are increasing possibilities that Apple iDevices may be misused for fraudulent or criminal activities. Of course, these modifications could just be done on a computer with no involvement of mobile phones.

Here are some hypothetical examples of modifying geotags for misuse:

· A person with a grudge could upload an image of some precious diamonds to Craigslist. They could convert the geotags to point to the target’s home address, therefore leaving the target and their family vulnerable to possible theft.

· If a victim’s phone could be accessed briefly, a pornographic image, taken by a similar device, could be transferred onto the target device. The image would have geotags pointing to the victim’s house address. The instigator could then anonymously inform the police that the victim is in possession of illegal images. The evidence is present on the device to help convict the victim. He may have often left his iPhone on his desk during the working day, but thought it OK as it was pin-locked.

· An organised crime gang member could download a JPG of a girl from the web. The location could be modified to a disused warehouse, and then, via the wi-fi connection in the local cafe, the image uploaded to the web. The image geodata could be translated to the location by someone who works in ICT, who could decide to visit the address out of curiosity and is attacked and robbed.

In a case where an outcome may rely on geographical evidence, it is crucial that it be taken into consideration that the data may have been tampered with, even if there is no forensic evidence being present.

Due to the speed of users’ uptake of accessing email and the internet, along with the multimedia and geographic capabilities of the latest smart phones, there is an argument that such smart phone devices could easily become subjected to misuse, criminal and fraudulent activities. An example of this already happening is with the introduction of apps that utilise augmented reality. A definition of augmented reality, otherwise known as AR, is “the real-time mixing of computer generated and real-world information” (TheAssurer.com, 2010). An example of AR working in conjunction with an iPhone is Layar utilising a Panoramio layer. Panoramio is a Google-owned app allowing images to be uploaded via a smart phone or internet browser. The images appear, for example, on Google maps where certain criteria are entered into an API. This can then be interlaced with Layar, which is an app allowing the smart phone user to point view media tied to their current location. This AR system can also interlace further with Flickr and Google Earth, which arguably could cause further problems in the case of misuse. Could it be only a matter of time before this technology can be used to create violations of privacy and potentially endanger individuals and property? By creating an image of a person or object that may be likely to attract undesirable attention from criminals or sex offenders and geotagging it to a user’s location could be considered malicious and a violation of the user’s right to privacy and safety.

To summarise, such modifications of evidence on digital handheld devices may not be commonplace at the moment, but could prove to be a problem for victims in the future. Modifications of digital evidence may prove a future challenge for both law enforcement agencies and forensic examiners on a global scale. There is also an inherent naivety, amongst many users, regarding the dangers involved with publishing geotagged images on the internet.

If anyone would like a copy of “Geotag Data: The Modification of Evidence on the Apple iPhone” then PM me ( RedCelica67 on ForensicFocus.com ) or email me via the Blackstage Forensics website.

David Benford is Director of Blackstage Forensics (www.blackstage-forensics.co.uk), Derbyshire, England. He specialises in the forensic analysis of handheld digital devices and possesses an MSc in Forensic Computing & Security. He is also a trustee of the Cystinosis Foundation UK charity – see http://www.cystinosis.org.uk/our-charity/trustees for further details.

Experimental Testing Of A Forensic Analysis Method On The Tomtom GPS Navigation Device

First published June 2009

by Dr. 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.

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:

Personal Computer running Windows OS;
Personal Computer running Linux OS.

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:

SOFTWARE registry file;
SYSTEM registry file: no entries relating to previous installations of TomTom USB drivers must be present in the CONTROL SET sub-key…..\ENUM\USBSTOR.

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 (procedure for permanent deletion of files from memory card by overwriting with spurious data until all traces are eliminated) 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:

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

Once the connection has started, the screen below appears.

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 (see note 2) MD5 and SHA1 both of the original (see note 3) 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( see note 4) 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.

2 “Hash” means the hash calculated on a data flow determined after two intelligent systems (with CPU) have joined on a communications protocol.

3 “Original” means not the original data stored on the device, but the original data flow leaving the device when it connects with a Windows system.

4 Hash algorithms are a kind of “footprint”, that univocally distinguishes all electronic trace of the forensic analysis so as to comply with data integrity requirements. This “digital watermark” is produced by “one-way hashing” (e.g. MD5 and SHA1) which generates unmistakable reference to the original trace but does not allow it to be reconstructed. These algorithms are utilized internationally and ensure a satisfactory level of security/safety.

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

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.

– without an SD card inserted in the slot:

the device goes into “update” mode and looks for the TomTom Home software on the PC for automatically updating user data on the Internet. When it fails to find the software the device tries to install it (the device software includes a compact self-installing version TomTom Home). The PC recognises it as a navigation device and installs the data update drivers. In this mode, certain files on the device are automatically updated and therefore changed. This is confirmed by analysing the data produced by monitoring communication flows via USB between TomTom and PC, using the SysNucleus USB Trace v. 2.0 tool, during the connection of each device as described here.

– with SD Card inserted:

the device goes into “USB peripheral” mode and as such is recognised by the PC which installs only the USB connection drivers.

No communication is attempted to update the TomTom data and the TomTom Home software is not searched for on the PC, so the files stored within the device are not changed; the machine only reads the contents of the SD Card, which is assigned an external hard drive letter. An analysis of the information generated by monitoring communication flows via a USB between the TomTom and the PC, using SysNucleus USB Trace v. 2.0 during the connection and installation of the device drivers, confirms that the data stored in the device has not been changed.

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

 

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

 

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 (see note 6) 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.

6 Hash algorithms are a kind of “footprint” univocally distinguishing the electronic trace of the forensic analysis, so as to preserve data integrity. The “digital watermark” is created via a one-way hashing operation, (e.g. MD5 and SHA1), which generates a “footprint” that refers exclusively to the original trace, but does not enable it to be reconstructed. These algorithms are used internationally and ensure a satisfactory level of security.

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 (see note 7) 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” (see note 8) 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 (see note 9);
2. CD Helix Live 3: ADEPTO 2.0;
3. USB NBCaine: AIR 1.2.8.

7 Live mode allows an operating system downloaded directly to memory from a CD or USB flash drive to be used, without the need to rely on the hard disk(s) present on the machine.

8 Mounting enables a block peripheral to be initialised to permit read/write access.

9 Console mode is an alternative to graphics mode in which commands are facilitated by a graphical interface with buttons and windows. In consoled mode, commands must be written with no intermediation needed.

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 (see note 10) 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 pipe11 to an md5sum.

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

10 In UNIX the pipe is a mechanism for controlling information flows. In other words, the pipe is a system for using outgoing information flows from one command as input for another command.

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 (see note 12) 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.

12 DCFLDD is used to perform certain operations; the advantage is that it calculates hashes concurrently with the creation of the copy, eliminating the extra step needed when using DD.

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 (see note 13) 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. Below is an example of file content from which this information can be gleaned.

[TomTomGo]
DeviceName=TomTom ONE XL
DeviceVersionHW=ONE XL
DeviceSerialNumber=L26497J00167
DeviceUniqueID=AK8AG AADSW
RamDiskVersion=20080529
BootLoaderVersion=53026
LinuxVersion=190943
ApplicationVersionVersionNumber=8010
ApplicationVersion=9369
UserLanguage=Italiano
UserName=L26497J00167
LastConnectionTime=Never
GPSFirmwareVersion=
BuiltInColorScheme0=Belgica
BuiltInColorScheme1=Brittanica
BuiltInColorScheme2=America
BuiltInColorScheme3=Germanica
BuiltInColorScheme4=Australia
BuiltInColorScheme5=Deuteranopia
BuiltInColorScheme6=Greys
BuiltInColorScheme7=Antarctica
BuiltInColorScheme8=Africa
BuiltInColorScheme9=Astra
CurrentColorSchemeBuiltIn=1
CurrentVoiceInfo=Roberto
CurrentMap=Italia
CurrentMapVersion=710.1571
CurrentHomeLocation=45.53052,9.03387,Via Francesco Daverio 11, Milano
Traffic=N
13 Data carving is a technique for recovering deleted or de-allocated files.
CurrentFuelpricesType=
CurrentFuelpricesTypeString=
CurrentFuelpricesLastFullUpdate=
ValueRatio=BpHDxKhXmBZzHUCpsA==
Features=PlusDownloadDynamic,PlusDownloadGeneral,PlusDownloadMap,PlusDo
wnloadPOI,PlusDownloadScheme,PlusDownloadUpgrade,PlusDownloadVoice,Plus
DownloadRingTone,PlusMessageNotification,PlusPushChannel,PlusTraffic,PlusWe
ather,PlusEphemeris,PlusBuddies,PlusMobileSafetyCameras,PlusRoadConditions,
PlusFixedSafetyCameras,PlusFuelPrices,HDTraffic,PlusOnlineCamera,PlusTripRep
orting,HomeBackup,PhotoJPGViewer,PhotoBMPViewer,Newyork,Newyork1Dot6,Iti
nerary,Caymann,Durham,PhoneFeatures,CarSymbol,RDSTMC,Prague,Bluetooth,S
DSlot,InternalFlash
SupportedPatchTypes=1F
NrSupportedErrorTypes=132
UserPatchDatVersion=102
CompressedPatchVersion=150
MapServerPatchDatVersion=104
DeletedPoiDatVersion=200
ServerLineIndexDatVersion=102
ServerNameIndexDatVersion=102
MapShareSupportedProviders=203
CharacterSet=Latin-1

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.

BIBLIOGRAPHY

1. C.M. Colombini, Y. Corio, La corretta gestione di un incidente informatico e alcune ipotesi di linee guida per le operazioni di forensics. La Dead Analysis. White Paper, Corso di Perfezionamento in Computer Forensics e Investigazioni Digitali, AA 2007/2008.

2. B. Nutter , Pinpointing TomTom location records: A forensic analysis. 2008 Elsevier Ltd.

3. Peter Hannay, A Methodology for the forensic acquisition of the TomTom One satellite navigation System – A research in progress, Edith Cowan University, 2007.

4. A.K. Theiss, DD.CC. Yen, C.Y. Ku, Global positioning systems: an analysis of applications, current development and future implementations. Computer Standards & Interfaces, 2005.

5. SEC.AU, Edith Cowan University

6. ACPO (2003). Good Practice Guide for Computer based Electronic Evidence 3.0. Retrieved 16 Oct, 2007.

7. P. Hannay, A Methodology for the Forensic Acquisition of the TomTom One Satellite Navigation System–A Research in Progress. Paper presented at the 5th Australian Digital Forensics Conference, 2007.

8. A. K. Theiss, D. C. Yen, & Ku, Global Positioning Systems: an analysis of applications. 2005.

9. http://www.marcomattiucci.it.

10. http://ww.tomtom.com

11. http://www.GPSforensics.org

12. http://www.forensicswiki.org/wiki/GPS

13. http://www.symbian.com

14. http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&part num=S3C2443

15. http://www.maerco.it/index.php/2007/01/03/open-tom-tomtom-opensource/

16. http://www.opentom.org/Main_Page

A special thanks to the Major Marco Mattiucci, Commander of the RTI – Reparto Tecnologie Informatiche – RACIS Roma – Arma dei Carabinieri.

—

Dr. Clara Maria Colombini
Email: clara.colombini@email.it
LinkedIn: www.linkedin.com/in/claracolombini

Mobile Phone and GPS Forensics – Some Thoughts

First published February 2009

by Greg Smith
Mobile Telephone Evidence & Forensics
trewmte.blogspot.com

Mobile telephones are the predominate wireless telecommunications device throughout the world and most certainly in the UK they predominate other technologies, where ownership has reached well over saturation level when compared to the population number and mobile phone usage is embedded in UK culture. Global Positioning Systems (GPS) falls into the category of wireless communications that provides a ‘beacon’ service from which information can be derived, such as a reference clock and location coordinates. GPS is fast becoming an integrated service in mobile telephones and forms part of the forensics and evidence examination process.I have been in talks with Professor David Last, a specialist and expert in GPS forensics and evidence, for some while on the cross-connection between wireless modules that can be integration into mobile telephones and, in particular, GPS being such a module. The discussion has been directed towards interpretation of GPS data and the importance that once data has been extracted and harvested it is vital that interpretation of the GPS data needs to be accurate.

I have similar thoughts regarding mobile telephone evidence and I have raised them, in the past at my webblog, and recently published at my webblog discussion about Cell Site Analysis:

trewmte.blogspot.com/2008/11/csa-from-ockhams-occams-razor-to.html
trewmte.blogspot.com/2008/11/mobile-phones-and-fringe-coverage.html
trewmte.blogspot.com/2009/01/checking-masts-csa.html
trewmte.blogspot.com/2009/01/checking-masts-csa-2.html

There are many other discussions, too, at my webblog about SIM and mobile telephone examination where help and assistance has been given (free of charge and free of advertising I might add) to aid comprehension about mobile telephone evidence. Similarly, GPS must be taken seriously as people can lose their liberty and a whole lot more where evidence like this can add a contributory factor to the case against them. This matter will become more prevalent in the future as GPS modules are increasely being included in mobile telephones.

Market research from ABI indicates that shipments of GPS-enabled mobile phones will hit a speed-bump in 2009, but will still manage to post year-to-year unit growth through the current economic downturn. While global handset shipments are expected to drop by 4—5% in 2009, prior to 2009 GPS-enabled phones will show a climb to 240 million units, an increase of 6.4% for 2008. Moroever, Smartphones are expected to increase at an average 19% from 2009 to 2014 and it is predicted nine of every ten smartphones will contain GPS ICs in 2014, compared with one in three for 2008.Given these latest GPS statistics that have been released it is timely that Professor Last, the immediate past president of the Royal Institute of Navigation (RIN), should have his GPS forensics and evidence article ‘Silent Witness’ published in Navigation News (an RIN publication). I like the way David has woven in the use of computer forensics, which like mobile telephones, provides a complementary service to GPS devices for the data recovery process. Copying data though is simply not enough and the ‘Silent Witness’ article is strong on the importance of accurate interpretation of GPS data. A principle I wholehearted agree and why I have been promoting the importance of Mobile Telephone Forensics and Evidence Degrees.

David has kindly provided a copy of his ‘Silent Witness’ article that can be downloaded from Mobile Telephone Evidence at the link below:

www.filebucket.net/files/10614_ggvgt/pub356_scanned.pdf
Professor David Last ‘Silent Witness’
Navigation News January/February 2009
Pages 10-13

Thanks also to the RIN (www.rin.org.uk)

TomTom GPS Device Forensics

First published January 2009

Written by Ben LeMere (blemere@gpsforensics.org) & Andy Sayers (asayers@gpsforensics.org)

For more information visit GPSForensics.org

Introduction: The sales of portable navigation devices are at an all time high. Last year, more than forty million portable GPS devices like TomTom’s GO series or Garmin’s Nuvi series were sold worldwide. These devices can be a good source of evidence. With the entrance of hybrid devices into the marketplace, GPS devices now contain much more than navigational information and may contain data commonly found in cell phones as well as audio, video, and text based files like MS Word or PDF documents.The law enforcement community has seen a dramatic increase in the use of GPS devices as an instrument of a crime or as a “witness device” autonomously collecting and logging positional data while the crime is being carried out. TomTom and Garmin units are by far the most popular devices law enforcement have been encountering. The focus of this article will be on TomTom devices but the general process can be extended to other device types.

TomTom Specifics: TomTom provides a range of devices for navigation. Depending on the capabilities of the model, several different kinds of information can be acquired. Most models have an SD card slot or an internal memory and allow pictures, documents, audio and video files to be stored and accessed thru the device. Standard TomTom files found on a device may include:

– Location Information

– Device Info

– Called list

– Callers list

– Text Message Inbox

– Text Message Outbox

– Contacts

– Bluetooth Name and MAC ID

– User Information

All TomTom models will have a locations file which may contain the location the user set as home, a list of any recent destinations and possibly last journey data. It will also have a device information file which contains the device serial number, model number, software version and other general information about the device. Higher end TomTom models like the GO seriescan act as a hands free device for mobile phones and may contain call data, text messages, contacts and a list of paired phones by their MAC address.

Data Acquisition: Data acquisition can be achieved thru different methods depending on the TomTom model. This is specifically related to whether the device has internal memory or stores its data on a removable SD card.

In the cases of devices that use SD cards, the card can be removed and processed like any other removable media. A forensically sound copy of the SD cards should be made and used to analyze the data. An important note, TomTom devices do not support the write protection option built into SD cards and regardless of the write protection tab setting (located on the left of the SD card if looking at the top) will write data to the card.In the cases of devices that have internal memory, the devices will appear in Windows under “My Computer” when plugged in via USB as a removable storage device with the label “TomTom”. Once visible in ‘My Computer’, it is possible to open the TomTom directory and copy the contents. A more sound approach, than ‘clicking and dragging’ the files to the desktop, would be to acquire an image of the device and work from that disk image. AccessData’s FTK Imager is available from their support website and will acquire devices without a license. FTK 1.80 will parse up to five thousand files without a license dongle and is sufficient for devices with 2gb hard drives or less. FTK or Encase will make it easier to decode and view the files.

Note, when powering on the unit to acquire data, if the device establishes a lock from the GPS satellites the device will overwrite the Last GPS Fix information in the CurrentLocation.dat file with its present location. A faraday bag can be used to prevent this from happening or examining the device inside a building away from windows can accomplish the same thing.

Target Files: Once the data has been acquired the following files are good sources of information.

– *.cfg – contains locations. The file name depends on the model but is generally found in a folder with the name of the map. The file name is either ‘Mapsettings.cfg’ or .cfg. There may be more than one map installed on the TomTom. The map currently in use can be found by looking at the ‘currentmap.dat’ file.

– ttgo.bif or ttnavigator.bif – general device information, model number, serial number, user password (encrypted)

– Settings .dat – Paired phone ID and MAC address (max 5) and any user information.

– Called.txt – Name called (if in phonebook), Number called

– Callers.txt – Name of caller (if in phonebook), Number of caller

– Inbox.txt – Name, Number, Message, Date & time

– Outbox.txt – Name, Number, Message

– Contacts.txt – Name of contact, Number of contact. This file only exists if the user has chosen to import their address book from their phone.

Data Analysis: TomTom devices can store information relate to the owner’s home address and a list of their ‘Favorite’ locations. If a user selects to navigate to either their Home, a Favorite or an address entered as a destination then this information is stored in the ‘recent destination’ file that ends with a .cfg extension.

.cfg files contain:

– Home location

– Favorites

– Manually entered addresses

– Details of Last Journey (if entered)

– Last GPS Fix of the device

For each of the locations a Latitude and Longitude is stored along with both an automatically assigned name and a user editable name and a house number. It also stores how the user chose to navigate to the address (entering the latitude and longitude, selecting it from the favorites list, etc…).

TomTom devices can be paired to a mobile phone and used as a handsfree device. If this has happened it is possible to recover information that would normally be found in a mobile phone. These files are text files and can be viewed with any text editor.

‘Contacts’ folder contains: (earlier versions have these files in the root folder)

– The contacts list from the mobile phone previously connected

– A list of numbers called

– A list of calls received

– Sent/Received SMS messages

Unallocated Space – Useful information can be found in the deleted space on a TomTom. If the user has ‘reset’ their device then no live information will be available but the unallocated space will contain the information that was present before the reset. Also in the deleted space will be records of previous journeys plotted and potentially the actual GPS position of the device when the journey was plotted and its last GPS fix for that journey.

Last Journey – When a journey is plotted using a TomTom it takes the current GPS position of the device as the start point of the journey. Until the destination is reached the TomTom stores both the Origin and the Destination. If a wrong turn is taken in the journey the TomTom will initially attempt to make the user turn around or will try to steer the user back on to the route. If this fails then the TomTom will be forced to re-plan the journey. If this happens then the TomTom will again take the current GPS position as the origin, leaving the destination the same. When examined, the Last Journey Origin will be a place where the TomTom has been but it may not be the place the entire journey started from.

Last GPS Fix – A TomTom device always records where it is when it has a GPS fix, this is the ‘Last GPS Fix’ It may be in mid journey if the TomTom was turned off mid journey or it may be a place where the TomTom has been turned on since. Like the ‘Last Journey Origin’, this is a place where the TomTom has been. The last GPS fix can be found in the CurrentLocation.dat file and is only available on newer TomTom device. Older models may store the information in the .cfg file.

Triplog Files – TomTom devices collect anonymous usage data from users who allow it. If a user enables this function while setting up the device, in the device file system there will be a folder titled ‘statdata’ containing files titled ‘triplog-yyyy-mm-dd.dat’. These files are encrypted and there are no known tools that can read the contents.

Recommended Seizure Techniques: Like any other GPS device, TomTom devices are continuously collecting information and writing data to memory whenever they are powered on. When you seize a device, power the unit off and do not turn it on until you are ready to examine it. When you are ready to examine the device you should be inside away from windows so the device does not have a clear view of the sky. A faraday bag can be used to ensure that the TomTom cannot establish a lock from the GPS satellites. If it establishes a satellite lock, the device will overwrite the Last GPS Fix information in the CurrentLocation.dat file.

Until the latest software update, App 8.0.10, released in the July/August 2008 timeframe, turning a TomTom device off that is protected by a pin code would not prevent you from accessing the device with a computer. App 8.0.10 has “fixed” that issue and requires the pin code to be entered before the device will go into disk mode.

Tools Available: Currently the best tool available for examining TomTom devices is TomTology. It was developed by two computer crimes investigators from the UK. It is a forensic tool used exclusively for examining TomTom devices and provides users with the capability to; Decode live data (Home Location, Favorites, Recent Destinations, Last Journey Start and End Point, Stored Phonebook, Called Phone Numbers, and Received Phone Numbers), automatically retrieve deleted journeys from unallocated space, locate deleted phone numbers, export all or selected locations to Google Earth, and produce detailed HTML reports. TomTology will automatically perform a full analysis of a TomTom including unallocated space and can extract data from a disk image created by FTK or EnCase.

There is also a separate EnCase Enscript available to parse files from an image file using EnCase. Email us for information and to request a copy at info@gpsforensics.org.

Definitions:

ENTERED LOCATIONS – These locations have been entered into the TomTom, either as a Home, a Favorite, a Destination or a Point of Interest. They appear at the top of the list when a user chooses to navigate to a new address.

FAVORITES – It is possible for a user to enter a number of addresses or places into their TomTom and save them as a Favorite. It is then possible for a user to quickly access these places to navigate to them.

HOME LOCATION – The Home Location is the address or place that has been entered by a user into the TomTom as the location of their home.

LAST GPS FIX – The TomTom keeps track of where it is. It may be along a journey if one is in progress or just where the device was when it was last turned on.

LAST JOURNEY INFORMATION – TomTom devices can save the details of the last journey. The last journey Origin is the actual position of the TomTom unit. It does not always mean that this is the start of the journey. If the user takes a wrong turn and the TomTom has to recalculate the route it places this point as the Origin of the last journey. It can be said that the TomTom device has physically been at this location.

NAVIGATED BY – How the user selected the location is stored in the TomTom. When a user selects to navigate to a destination they can do so by selecting to navigate to:

– Home

– Favorite

– Recent Destination

– Postal Code

– Entering the address manually

– Selecting the point off a map

– Point of Interest

– Entering the Latitude and Longitude

– Selecting to go to a city centre

ORPHANED LOCATIONS – Orphaned Locations are those addresses found in the deleted space that are no longer part of a file or the header of the file has been overwritten. Because they are no longer part of a file all of the information may not be available. It may not be possible to say what type of entry they are, only that they are present upon the device.

RECENT DESTINATIONS – Recent Destinations are places that the user of the TomTom has selected to navigate to. It does not mean that they have been there, only that the address has been entered.