Model & Software: nuvi 1490 A KP1 V5 LC 2 GB v4.70 Created: 7/8/13 Last Updated: 7/14/13
The primary purpose of this examination was to acquire data detailing trips calculated by the Garmin Nuvi 1490. These tracks can be used to determine where an individual may have traveled with the GPS. There are probably many software and hardware tools available to acquire this information (as well as and more data). This research details a manual method of acquiring trip data from GPX files (GPS eXchange Format, a lightweight XML file format used for storing GPS data). Research may be on-going (major revisions will be mentioned on the main blog page).
The device was imaged with software-based tools. No special privileges were acquired on the device. Physical hardware techniques for data acquisition and/or analysis would probably yield more interesting results but are beyond the scope of this rudimentary exam.
The information provided was analyzed using TSK/Autopsy 3.0.3 in Windows 7 and the TSK tools in Ubuntu. This research almost exclusively focuses on the GPX XML file. Please note that regardless of the use of a write blocker, the internal “metadata” time references will not change. This means that Trackpoint timestamps will stay the same since they are written to the file, not the file MAC times, those may change. Also, as is the case with Current.gpx, one internal time in particular will change whenever time the device is powered on. There doesn’t appear to be a way to stop this from occurring.
The formatting of XML coding may look strange. I’ll try to present it in a clear way. Also, many of the over-sized images can be clicked on to open them in a new window.
Lastly, it’s important to note that this analysis was conducted against an unlocked Garmin. Garmin’s that have a pin enabled must be unlocked in order to acquire this data. Unlock methods such as brute forcing are beyond the scope of this research.
***
Brief Technical Specifications:
Garmin Nuvi 1490
USB Type A to Mini USB, Bluetooth Capable (Software v1.73)
External Storage: microSD (no SD provided out of the box)
Internal Storage: 1.76 GB
Battery: Lithium Ion
Sector Size: 512*
More details about my full device image…
Technical Specs Gathered from Physical Image:
FILE SYSTEM INFORMATION
——————————————–
File System Type: FAT32
METADATA INFORMATION
——————————————–
Range: 2 – 59311846
Root Directory: 2
CONTENT INFORMATION
——————————————–
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 2 – 463374
Sectors per Track: 63
Bytes per Sector: 512
Sector Count: 3,743,744
Disk nuvi.001: 1916 MB, 1916796928 bytes
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
* There is no space detected before the file system (as illustrated above). Calculating offsets are not required for the purposes of extracting trip data using GPX files. If in doubt, use the above geometry as a guide. Remember to ensure that any image you create contains the device’s unallocated space. Fileslack may also be meaningful to you.
File Structure of Importance:*
.System GARMIN
— ExifData # Area I’d like to investigate further.
— sqlite # Contains: local_poi.db (A) mlg_history.db (A) mlg_history.db-journal (U) system.db (A) Garmin
autorun.inf JPEG # Stock and user-uploaded photos, displayed like a digital picture frame.
nuvi_drive.ico
.VolumeIcon.icns Text GPX
— GPX # Files: Current.gpx (A) Position.gpx (U)
— Archive # Many GPX files with critical data. This is the area we will be focusing on. help
Voice
Vehicle
* Please note that this is not a complete list of files for each directory. I was debating whether or not to provide the output of the tree command in linux for ease of viewing. Instead I’ve decided to only show mention critical areas worth analyzing.
Analysis of GPX Files
GPX is a very funny XML format. You’d think by the official documentation that importing Waypoints from GPX files into your GPS unit is commonplace. In reality, very few people actually know GPX files exist. You can leverage this to your advantage. But first a brief overview of terms is needed…
GPX – GPS eXchange Format – this is a type of XML file used for storing GPS data in a lightweight format. These files are thousands of lines of Waypoint and Trackpoint information. Routes – paths that are connected together through Waypoints
* Points of interest – saved locations classified name or group (in this case, “Food,” “Fuel,” “Transit,” “Lodging,” “Shopping,” etc. all generally manufacturer defined.) This is a type of route.
* User-generated Waypoints – user set, one type is accessed by tapping “Browse Map” from the main menu and selecting a location on a map to save. Another is simply saving specific locations.
Tracks – comprised of Trackpoints. Allows an examiner to determine the exact path someone took to get to a destination. This is what we really want!
* Active Track -> current track; as locations change while following the GPS, each of those Trackpoints are recorded. The Trackpoints are what are connected on the actual GPS screen while following driving instructions.
* Saved Track -> formerly accessed, exact track saved.
Tracks are overwritten as the the device’s internal memory is reached. There is generally more room for tracks than Waypoints (though some tools may not show them all, manual analysis is best but time consuming).
Waypoints appear as single points along the trip. These include locations you’ve searched, such as 215 East North., followed by a coordinate. They can be favorited locations. While this is great for getting addresses and end point coordinates, it really doesn’t tell us the path that the driver took along the way. Good for getting addresses, bad for “tracking” the user (pun intended).
Some tools like EasyGPS list every Waypoint in a GPX file. This is good but, by itself, lacks any timestamps or frames of reference (a good example is the lack of Trackpoints). In EasyGPS there seems to be an issue with parsing all available Trackpoints as well. Just because you do not see more than a few Trackpoints, don’t assume they aren’t recorded in the GPX file. This is a good reason to analyze the GPX files manually!
A tool like GPS Utility will show either Waypoints, Routes to and from a location including distance and duration, Trackpoints and more. Trackpoints are ordered in chronological order in GPX files (newest dates are on the bottom). The problem is determining where each entry begins. I’ll illustrate the technique of searching just for active log entries below.
.SystemGARMINGPXCurrent.gpx
This contains the most up-to-date data. The time noted in the file’s ‘metadata’ entry seems to be similar to a last access time in the simplest sense:
Note that the file’s actual modification time is 2013-07-05 at 2:26:00 PM (device was set for EDT). The close proximity in time reveals what could be a delta of some kind. Upon retesting this, the time was updated to reflect the last time the device was powered on. This was extremely accurate for me (only a few seconds difference). This entry is extremely volatile! Powering on the device will change the time listed in this GPX entry. Keep this in mind during your investigation!
All Trackpoints will begin with an Active Log. It’ll contain the date and time of the Trackpoint in UTC. While Waypoints are great for recovering human readable addresses, Trackpoints will populate the rest of Current.gpx — this is of most importance!
Trackpoints begin with an open and closing trkpt code. This is a common way of identifying Trackpoints in GPX files: every Trackpoint along the route will be represented. In the following example, I’ve replaced the coordinates with 1s to preserve some degree of privacy.
Wait. Speed and elevation?! Yeah, haven’t you heard? These devices are pretty accurate! If you can see the details on the GPS HUD while you’re driving, it’s usually recorded!
Another Trackpoint would follow the entry I just listed. When you plot all the points present on a map, you’ll be able to see the path taken with every single turn along the way.
The first Active Log entry is the oldest, 06 DEC 2012 18:17. The last Active Log is on top of the GPX under Waypoint addresses (05 JUL 2013 22:56).
Sample of GPS Utility displaying Active Log entries
You’re probably thinking there’s too much data. I agree, we’re talking about 74,194 lines just in this GPX file alone. Multiple Active Logs but still plenty of data. How would I approach the analysis? Correlate these times with your case’s working timeline and exclude all Active Logs that are not within the appropriate time frame. (Sorting and clipping repeats with uniq may also be good.)
You can use grep and output to a file or search the file for the Active Logs in Windows using notepad. This isn’t an ideal solution. Hopefully someone will come up with a better open source tool to do this in the future. There are enough costly approaches to GPS forensics out there, it’s time for some free research and tools! The point: once you know what you’re looking for, sorting through the data is easy (but still time consuming).
TrackMaker Against Current.gpx
Please note that Current.gpx does not represent 1 “trip” but many. Each “Active Log” would constitute a “trip” (or, in technical terms, a collection of Waypoints one segment at a time!).
.SystemGARMINGPXPosition.gpx
This file was recovered from unallocated space. Autopsy carved it with ease. I was informed recently that this file represents the time and position where/when the device was last powered down. It is very precise. The time inside Position.gpx is very similar to Current.gpx’s tag:
There’s a one second difference from what is recorded inside the file itself.
This file was last modified at its creation at 2013-07-05 14:25:28. It was immediately created and deleted and then the device was powered down. This is some more food for thought.
The major dilemma: should you trust this Position.gpx timestamp or the timestamp in Current.gpx for the device’s last power on? That’s a difficult question to answer. The moment an examiner accesses the device to analyze these values will change in both files. Hardware data acquisition may be the only way to recover this data without altering it. As for accuracy, I’d trust the Position.gpx entry as I’ve found it to be very accurate.
This is a satellite representation of Trackpoints on the day of my GIAC exam. In the illustration I’m trying to find a parking spot in the Bronx:
Google Maps: finding Parking in the Bronx stinks. This lot was full.
Note the Active Log entry, timestamp and direction of the car. MapSource will show distance between each Trackpoint as well as the speed. Why the speed? Because my speed can change drastically between Trackpoints (such as when I’m looking at the parking lot and not paying attention to the road!). The speed at which an individual travels to and from various Trackpoints may be important to your case.
The flag marks a popular Waypoint. The following location is where I actually ended up parking (notice that the Waypoint doesn’t end there, this is because I didn’t enter it into GPS, I was just ignoring the robot lady and parking in the only empty lot I could find. The important fact is that it does show my deviations!).
Bronx Parking lot With Tracks
.SystemGARMINGPXArchive*
This is a dump for older GPX files. They are also ordered sort of like an MRU list in the Windows Registry. My entries are numbered 10-29.
Fully realizing that there’s a considerable amount of Trackpoint data found in the archives sub-folder, I advise considering the file’s actual modification times as a point of reference.
We can glean a few pieces of information from this information so far:
1) The file was created and, 20 seconds later, it was modified (if the creation time is to be believed).
2) This file is not a copy of another file (time stamps analysis).
3) This is my last file in sequential order.
** Are FAT creation times accurate? Tread with care and remember that file times are not as critical as timestamps listed in the XML files themselves.
Inside this file we see some interesting information:
The idea that the archive data could have been created from old entries Current.gpx are consistent with these findings. This file does not appear to be a copied and renamed version of an older Current.gpx.
All of the Active Logs are from 2012 within the file. Disregard this entry and focus on the Trackpoints. I suggest using MapSource by Garmin. It makes great use of Google Earth, check it out (click to view):
MapSource & Google Earth – illustrates active log Trackpoints and the direction traveling
GPX Overwriting and Archive Details
Essentially the nuvi can store up to 10,000 Trackpoints in Current.gpx. Once this is reached, it’ll begin to create GPX archives and place the older tracks inside the archive files (append/insert). Garmin states that the device can hold 20 archived files. The oldest file in my archive is marked 29.gpx, but there’s a reason for that. The numbering begins at 10 and goes to 29 and there are only 19 archives here. Presumably this is because older archives, prior to the 2011 dates in listed in 10.gpx, have been overwritten as space was needed on the device.
10.gpx here contains the oldest archived Trackpoints while 29.gpx contains the latest.
For quickly determining a GPX file’s significance, you can use a metadata extractor to quickly pull the most recent Active Log data from the XML. The timestamp of the Active Log can then be used for coloration against your working timeline. For more information information on this, please see my blog post entitled “Metadata Extraction of GPX Files.”
GPX Fileslack
I have noticed that each GPX file has some remaining slackspace, complete with additional with GPS data. This data may be useful to supplement your analysis (just in case you didn’t feel like you had enough work). Pulling a few Trackpoints and hoping they clearly fall into an Active Log you pulled from the GPX-proper may be pushing it! These timestamps rarely match-up with known/pre-existing Active Log times found in the GPX-proper files. I should note that I did not check the archive data for hits to the partial entries found within a file’s slack (that would take a long time; use proper timeline correlation to make this determination).
Analysis of sqlite
File modification and creation times are available for each database. Databases contain tables and fields but very little data of forensic importance. It looks like a framework for storing data but not the data itself. I’ll briefly list the “important looking” tables and fields listed in each of the databases:
* system.db – contains a reference to mlg_history.db – there’s a table but no discernible data.
* mlg_history.db – history (table) with fields: distance, fuel_economy, speed_score, acceleration_score, deceleration_score, group_score, and fuel_usage
* local_poi.db – Appears to be user-saved locations or entries subsequently marked as favorite by the user.
I’d love to be able to know definitively how the SQLites are being used (with actual proof, that is, there’s a lot of misinformation on the internet). These databases are sparsely populated. The data may be useful for the Garmin’s operations and use but I don’t see the benefit of using them for forensic analysis at this point in time.
.SystemGARMINLogs
This contains the following sub-directories: bin, gpx, dbg, snr, per and nme. There are many deleted files with names that include the word “test.” They are generally 0 bytes. As with the SQLites, I’m failing to see a significance for forensic purposes.
.SYSTEMGARMINDiag3817093880.csv
Designed by NavTeq, a mapping company in the U.S., this file is chock full of coordinates and times. Generally speaking, NavTeq provides “traffic incident” information to the GPS unit (traffic conditions, etc.) I believe the entries in the CSV file are factory set-up Waypoints designed by NavTeq. Regardless, as interesting as it may sound, it isn’t terribly pertinent to a forensic examination. It may be more interesting to note that the Garmin’s privacy policy allows NavTeq to collect data from your device as needed.
Should you wish to decode the times found in the CSV, you can download DCode from the link in the “Forensics Tools Used” section below. Times are in Unix/Epoch time. This tool will convert the time to UTC or your own timezone for convenience. Dates are oldest to most recent.
I do not believe this CSV to be of significance to GPS forensics but I’ve included the timestamp information for those that wish to research this file further.
Forensics Tools Used
*AccessData FTK Imager 3.1.1.8 provides the cleanest overall view of GPS Exchange Format files. Since they are essentially XML files, FTKi will display all entries in a clear, color coded format complete with XML code. Use Export Directory Listing or TSK’s fsstat to pull critical geometry of target media. Imaging can be conducted with FTKi or any imager for that matter. *TSK & Autopsy 3.0.3 and TSK for Linux (analysis was mainly on Windows) – essential for viewing unallocated space. *SQLite Manager and SQLite Database Browser – optionally you can use sqlite3 from a linux command line against exported SQLite 3 databases and then use appropriate queries. *Garmin Communicator Browser Plugin & API – works for live analysis, I believe. I didn’t use Communicator. *Digital Detective’s DCodecan be downloaded here. *See Warnings section for GPX metadata longitude and latitude parsing warning.
GPS Tools Used
* GPS TrackMaker (demo) – allows you to import Google Earth KML or pull Google maps directly into the program. Allows for use with GPX files. Site: http://www.trackmaker.com/ * Google Earth – most play with this without giving it too much thought. You can actually pull almost every type of GPS or mapping file into Google Earth to map points (active logs are actually labelled over satellite imagery). Available for all operating systems. See: Google Earth
Optional GPS Tools Mentioned
* GPS Utility (Commercial Demo) is able to parse GPX files. You can export the GPX folder from the working image and import the files individually into GPS Utility. The demo version will limit how much data you’re able to retrieve. I do like how you’re able to break down GPX elements in a metadata timeline-driven table! Very barebones for a paid program. See: http://www.gpsu.co.uk/
* EasyGPS – completely free. See: http://www.easygps.com/
Further Analysis Needed
.Systemsqlite
SQLite3 database files – These database files are almost like references or configuration options. I don’t actually see valuable data in them. This may be due to a lack of database-foo skillz or something. Well worth exploring further.
.SystemExifData
Binary executable populate this folder. I’ve been unable to examine these files. Contributions in the form of help would be much appreciated!
Unallocated Space
TSK/Autopsy show both allocated and unallocated data. This is interesting. Part of what I’m finding is the remains of SQLite entries or parts of GPX files with coordinates. See this GPSForensics.org article on Forensic Focus detailing the forensic analysis of TomToms. Unallocated space is crucial to GPS investigations. Part of the issue – and I could be wrong – is that there doesn’t seem to be any wear leveling or garbage collection (the latter is common on YAFFS2 on android devices).
Warnings
* TSK/Autopsy, Timestamps and Visual Mapping – SQLite & GPX data can be found in unallocated space as well as allocated space. Using Autopsy, you can view critical timestamps and coordinates stored within these files. Remember that M-C times of the files are not as critical as the values stored within the files. Similarly, no additional timeline tools are needed for analyzing the GPX XML files. * Thoroughness of GPS Programs. Some of the GPS tools mentioned do not appropriately map the coordinates found within the GPX files on an actual map by default (EasyGPS and GPS Utility). You should use Google Maps or Google Earth for mapping the longitude and latitudes. Additionally, TrackMaker (demo) handles everything nicely. Technically you could save time by creating a script that pulls and maps the appropriate data. * Timestamp notice: While typically FAT stores time stamps in local time, the Garmin GPX’s have times in stored in UTC (since they are inside the XML files). Regardless, you should use forensic tools to examine the Garmin and not mount an image and view it in Windows Explorer. FTKi and Autopsy both present file times in UTC. * Exporting & Timestamps. Exporting files from an image will change the file’s timestamps but they will not change the GPX time entries.
I’d like to take the opportunity to thank the information security community for training me to think critically. I hope that that this research helps you understand GPS device forensics and, in particular, how travel data can be acquired from similar devices.
Garmin Research
Examination of Garmin Nüvi 1490
Model & Software: nuvi 1490 A KP1 V5 LC 2 GB v4.70
Created: 7/8/13
Last Updated: 7/14/13
The primary purpose of this examination was to acquire data detailing trips calculated by the Garmin Nuvi 1490. These tracks can be used to determine where an individual may have traveled with the GPS. There are probably many software and hardware tools available to acquire this information (as well as and more data). This research details a manual method of acquiring trip data from GPX files (GPS eXchange Format, a lightweight XML file format used for storing GPS data). Research may be on-going (major revisions will be mentioned on the main blog page).
The device was imaged with software-based tools. No special privileges were acquired on the device. Physical hardware techniques for data acquisition and/or analysis would probably yield more interesting results but are beyond the scope of this rudimentary exam.
The information provided was analyzed using TSK/Autopsy 3.0.3 in Windows 7 and the TSK tools in Ubuntu. This research almost exclusively focuses on the GPX XML file. Please note that regardless of the use of a write blocker, the internal “metadata” time references will not change. This means that Trackpoint timestamps will stay the same since they are written to the file, not the file MAC times, those may change. Also, as is the case with Current.gpx, one internal time in particular will change whenever time the device is powered on. There doesn’t appear to be a way to stop this from occurring.
The formatting of XML coding may look strange. I’ll try to present it in a clear way. Also, many of the over-sized images can be clicked on to open them in a new window.
Lastly, it’s important to note that this analysis was conducted against an unlocked Garmin. Garmin’s that have a pin enabled must be unlocked in order to acquire this data. Unlock methods such as brute forcing are beyond the scope of this research.
***
More details about my full device image…
* There is no space detected before the file system (as illustrated above). Calculating offsets are not required for the purposes of extracting trip data using GPX files. If in doubt, use the above geometry as a guide. Remember to ensure that any image you create contains the device’s unallocated space. Fileslack may also be meaningful to you.
* Please note that this is not a complete list of files for each directory. I was debating whether or not to provide the output of the tree command in linux for ease of viewing. Instead I’ve decided to only show mention critical areas worth analyzing.
Analysis of GPX Files
GPX is a very funny XML format. You’d think by the official documentation that importing Waypoints from GPX files into your GPS unit is commonplace. In reality, very few people actually know GPX files exist. You can leverage this to your advantage. But first a brief overview of terms is needed…
GPX – GPS eXchange Format – this is a type of XML file used for storing GPS data in a lightweight format. These files are thousands of lines of Waypoint and Trackpoint information.
Routes – paths that are connected together through Waypoints
* Points of interest – saved locations classified name or group (in this case, “Food,” “Fuel,” “Transit,” “Lodging,” “Shopping,” etc. all generally manufacturer defined.) This is a type of route.
* User-generated Waypoints – user set, one type is accessed by tapping “Browse Map” from the main menu and selecting a location on a map to save. Another is simply saving specific locations.
Tracks – comprised of Trackpoints. Allows an examiner to determine the exact path someone took to get to a destination. This is what we really want!
* Active Track -> current track; as locations change while following the GPS, each of those Trackpoints are recorded. The Trackpoints are what are connected on the actual GPS screen while following driving instructions.
* Saved Track -> formerly accessed, exact track saved.
Tracks are overwritten as the the device’s internal memory is reached. There is generally more room for tracks than Waypoints (though some tools may not show them all, manual analysis is best but time consuming).
Waypoints appear as single points along the trip. These include locations you’ve searched, such as 215 East North., followed by a coordinate. They can be favorited locations. While this is great for getting addresses and end point coordinates, it really doesn’t tell us the path that the driver took along the way. Good for getting addresses, bad for “tracking” the user (pun intended).
Some tools like EasyGPS list every Waypoint in a GPX file. This is good but, by itself, lacks any timestamps or frames of reference (a good example is the lack of Trackpoints). In EasyGPS there seems to be an issue with parsing all available Trackpoints as well. Just because you do not see more than a few Trackpoints, don’t assume they aren’t recorded in the GPX file. This is a good reason to analyze the GPX files manually!
A tool like GPS Utility will show either Waypoints, Routes to and from a location including distance and duration, Trackpoints and more. Trackpoints are ordered in chronological order in GPX files (newest dates are on the bottom). The problem is determining where each entry begins. I’ll illustrate the technique of searching just for active log entries below.
.SystemGARMINGPXCurrent.gpx
This contains the most up-to-date data. The time noted in the file’s ‘metadata’ entry seems to be similar to a last access time in the simplest sense:
Note that the file’s actual modification time is 2013-07-05 at 2:26:00 PM (device was set for EDT). The close proximity in time reveals what could be a delta of some kind. Upon retesting this, the time was updated to reflect the last time the device was powered on. This was extremely accurate for me (only a few seconds difference). This entry is extremely volatile! Powering on the device will change the time listed in this GPX entry. Keep this in mind during your investigation!
All Trackpoints will begin with an Active Log. It’ll contain the date and time of the Trackpoint in UTC. While Waypoints are great for recovering human readable addresses, Trackpoints will populate the rest of Current.gpx — this is of most importance!
Trackpoints begin with an open and closing trkpt code. This is a common way of identifying Trackpoints in GPX files: every Trackpoint along the route will be represented. In the following example, I’ve replaced the coordinates with 1s to preserve some degree of privacy.
Wait. Speed and elevation?! Yeah, haven’t you heard? These devices are pretty accurate! If you can see the details on the GPS HUD while you’re driving, it’s usually recorded!
Another Trackpoint would follow the entry I just listed. When you plot all the points present on a map, you’ll be able to see the path taken with every single turn along the way.
The first Active Log entry is the oldest, 06 DEC 2012 18:17. The last Active Log is on top of the GPX under Waypoint addresses (05 JUL 2013 22:56).
Sample of GPS Utility displaying Active Log entries
You’re probably thinking there’s too much data. I agree, we’re talking about 74,194 lines just in this GPX file alone. Multiple Active Logs but still plenty of data. How would I approach the analysis? Correlate these times with your case’s working timeline and exclude all Active Logs that are not within the appropriate time frame. (Sorting and clipping repeats with uniq may also be good.)
You can use grep and output to a file or search the file for the Active Logs in Windows using notepad. This isn’t an ideal solution. Hopefully someone will come up with a better open source tool to do this in the future. There are enough costly approaches to GPS forensics out there, it’s time for some free research and tools! The point: once you know what you’re looking for, sorting through the data is easy (but still time consuming).
TrackMaker Against Current.gpx
Please note that Current.gpx does not represent 1 “trip” but many. Each “Active Log” would constitute a “trip” (or, in technical terms, a collection of Waypoints one segment at a time!).
.SystemGARMINGPXPosition.gpx
This file was recovered from unallocated space. Autopsy carved it with ease. I was informed recently that this file represents the time and position where/when the device was last powered down. It is very precise. The time inside Position.gpx is very similar to Current.gpx’s tag:
There’s a one second difference from what is recorded inside the file itself.
This file was last modified at its creation at 2013-07-05 14:25:28. It was immediately created and deleted and then the device was powered down. This is some more food for thought.
The major dilemma: should you trust this Position.gpx timestamp or the timestamp in Current.gpx for the device’s last power on? That’s a difficult question to answer. The moment an examiner accesses the device to analyze these values will change in both files. Hardware data acquisition may be the only way to recover this data without altering it. As for accuracy, I’d trust the Position.gpx entry as I’ve found it to be very accurate.
This is a satellite representation of Trackpoints on the day of my GIAC exam. In the illustration I’m trying to find a parking spot in the Bronx:
Google Maps: finding Parking in the Bronx stinks. This lot was full.
Note the Active Log entry, timestamp and direction of the car. MapSource will show distance between each Trackpoint as well as the speed. Why the speed? Because my speed can change drastically between Trackpoints (such as when I’m looking at the parking lot and not paying attention to the road!). The speed at which an individual travels to and from various Trackpoints may be important to your case.
The flag marks a popular Waypoint. The following location is where I actually ended up parking (notice that the Waypoint doesn’t end there, this is because I didn’t enter it into GPS, I was just ignoring the robot lady and parking in the only empty lot I could find. The important fact is that it does show my deviations!).
Bronx Parking lot With Tracks
.SystemGARMINGPXArchive*
This is a dump for older GPX files. They are also ordered sort of like an MRU list in the Windows Registry. My entries are numbered 10-29.
Fully realizing that there’s a considerable amount of Trackpoint data found in the archives sub-folder, I advise considering the file’s actual modification times as a point of reference.
We can glean a few pieces of information from this information so far:
1) The file was created and, 20 seconds later, it was modified (if the creation time is to be believed).
2) This file is not a copy of another file (time stamps analysis).
3) This is my last file in sequential order.
** Are FAT creation times accurate? Tread with care and remember that file times are not as critical as timestamps listed in the XML files themselves.
Inside this file we see some interesting information:
The idea that the archive data could have been created from old entries Current.gpx are consistent with these findings. This file does not appear to be a copied and renamed version of an older Current.gpx.
All of the Active Logs are from 2012 within the file. Disregard this entry and focus on the Trackpoints. I suggest using MapSource by Garmin. It makes great use of Google Earth, check it out (click to view):
MapSource & Google Earth – illustrates active log Trackpoints and the direction traveling
GPX Overwriting and Archive Details
Essentially the nuvi can store up to 10,000 Trackpoints in Current.gpx. Once this is reached, it’ll begin to create GPX archives and place the older tracks inside the archive files (append/insert). Garmin states that the device can hold 20 archived files. The oldest file in my archive is marked 29.gpx, but there’s a reason for that. The numbering begins at 10 and goes to 29 and there are only 19 archives here. Presumably this is because older archives, prior to the 2011 dates in listed in 10.gpx, have been overwritten as space was needed on the device.
10.gpx here contains the oldest archived Trackpoints while 29.gpx contains the latest.
For quickly determining a GPX file’s significance, you can use a metadata extractor to quickly pull the most recent Active Log data from the XML. The timestamp of the Active Log can then be used for coloration against your working timeline. For more information information on this, please see my blog post entitled “Metadata Extraction of GPX Files.”
GPX Fileslack
I have noticed that each GPX file has some remaining slackspace, complete with additional with GPS data. This data may be useful to supplement your analysis (just in case you didn’t feel like you had enough work). Pulling a few Trackpoints and hoping they clearly fall into an Active Log you pulled from the GPX-proper may be pushing it! These timestamps rarely match-up with known/pre-existing Active Log times found in the GPX-proper files. I should note that I did not check the archive data for hits to the partial entries found within a file’s slack (that would take a long time; use proper timeline correlation to make this determination).
Analysis of sqlite
File modification and creation times are available for each database. Databases contain tables and fields but very little data of forensic importance. It looks like a framework for storing data but not the data itself. I’ll briefly list the “important looking” tables and fields listed in each of the databases:
* system.db – contains a reference to mlg_history.db – there’s a table but no discernible data.
* mlg_history.db – history (table) with fields: distance, fuel_economy, speed_score, acceleration_score, deceleration_score, group_score, and fuel_usage
* local_poi.db – Appears to be user-saved locations or entries subsequently marked as favorite by the user.
I’d love to be able to know definitively how the SQLites are being used (with actual proof, that is, there’s a lot of misinformation on the internet). These databases are sparsely populated. The data may be useful for the Garmin’s operations and use but I don’t see the benefit of using them for forensic analysis at this point in time.
.SystemGARMINLogs
This contains the following sub-directories: bin, gpx, dbg, snr, per and nme. There are many deleted files with names that include the word “test.” They are generally 0 bytes. As with the SQLites, I’m failing to see a significance for forensic purposes.
.SYSTEMGARMINDiag3817093880.csv
Designed by NavTeq, a mapping company in the U.S., this file is chock full of coordinates and times. Generally speaking, NavTeq provides “traffic incident” information to the GPS unit (traffic conditions, etc.) I believe the entries in the CSV file are factory set-up Waypoints designed by NavTeq. Regardless, as interesting as it may sound, it isn’t terribly pertinent to a forensic examination. It may be more interesting to note that the Garmin’s privacy policy allows NavTeq to collect data from your device as needed.
Should you wish to decode the times found in the CSV, you can download DCode from the link in the “Forensics Tools Used” section below. Times are in Unix/Epoch time. This tool will convert the time to UTC or your own timezone for convenience. Dates are oldest to most recent.
I do not believe this CSV to be of significance to GPS forensics but I’ve included the timestamp information for those that wish to research this file further.
Forensics Tools Used
* AccessData FTK Imager 3.1.1.8 provides the cleanest overall view of GPS Exchange Format files. Since they are essentially XML files, FTKi will display all entries in a clear, color coded format complete with XML code. Use Export Directory Listing or TSK’s fsstat to pull critical geometry of target media. Imaging can be conducted with FTKi or any imager for that matter.
* TSK & Autopsy 3.0.3 and TSK for Linux (analysis was mainly on Windows) – essential for viewing unallocated space.
* SQLite Manager and SQLite Database Browser – optionally you can use sqlite3 from a linux command line against exported SQLite 3 databases and then use appropriate queries.
* Garmin Communicator Browser Plugin & API – works for live analysis, I believe. I didn’t use Communicator.
* Digital Detective’s DCode can be downloaded here.
* See Warnings section for GPX metadata longitude and latitude parsing warning.
GPS Tools Used
* GPS TrackMaker (demo) – allows you to import Google Earth KML or pull Google maps directly into the program. Allows for use with GPX files. Site: http://www.trackmaker.com/
* Google Earth – most play with this without giving it too much thought. You can actually pull almost every type of GPS or mapping file into Google Earth to map points (active logs are actually labelled over satellite imagery). Available for all operating systems. See: Google Earth
Optional GPS Tools Mentioned
* GPS Utility (Commercial Demo) is able to parse GPX files. You can export the GPX folder from the working image and import the files individually into GPS Utility. The demo version will limit how much data you’re able to retrieve. I do like how you’re able to break down GPX elements in a metadata timeline-driven table! Very barebones for a paid program. See: http://www.gpsu.co.uk/
* EasyGPS – completely free. See: http://www.easygps.com/
Further Analysis Needed
.Systemsqlite
SQLite3 database files – These database files are almost like references or configuration options. I don’t actually see valuable data in them. This may be due to a lack of database-foo skillz or something. Well worth exploring further.
.SystemExifData
Binary executable populate this folder. I’ve been unable to examine these files. Contributions in the form of help would be much appreciated!
Unallocated Space
TSK/Autopsy show both allocated and unallocated data. This is interesting. Part of what I’m finding is the remains of SQLite entries or parts of GPX files with coordinates. See this GPSForensics.org article on Forensic Focus detailing the forensic analysis of TomToms. Unallocated space is crucial to GPS investigations. Part of the issue – and I could be wrong – is that there doesn’t seem to be any wear leveling or garbage collection (the latter is common on YAFFS2 on android devices).
Warnings
* TSK/Autopsy, Timestamps and Visual Mapping – SQLite & GPX data can be found in unallocated space as well as allocated space. Using Autopsy, you can view critical timestamps and coordinates stored within these files. Remember that M-C times of the files are not as critical as the values stored within the files. Similarly, no additional timeline tools are needed for analyzing the GPX XML files.
* Thoroughness of GPS Programs. Some of the GPS tools mentioned do not appropriately map the coordinates found within the GPX files on an actual map by default (EasyGPS and GPS Utility). You should use Google Maps or Google Earth for mapping the longitude and latitudes. Additionally, TrackMaker (demo) handles everything nicely. Technically you could save time by creating a script that pulls and maps the appropriate data.
* Timestamp notice: While typically FAT stores time stamps in local time, the Garmin GPX’s have times in stored in UTC (since they are inside the XML files). Regardless, you should use forensic tools to examine the Garmin and not mount an image and view it in Windows Explorer. FTKi and Autopsy both present file times in UTC.
* Exporting & Timestamps. Exporting files from an image will change the file’s timestamps but they will not change the GPX time entries.
Additional Resources
* TomTom GPS Device Forensics by GPSForensics.org — click here to view.
* GPS Definitions — http://www.gpsmap.net/DefiningPoints.html
* GPX Explained from Topografix — http://www.topografix.com/gpx_for_users.asp
* GPX Archives Explained by Garmin – click here for archive information.
* A complete guide for GPX 1.1 can be found on the Schema documentation: click here.
* Linux Sleuthing Blog on “Garmin GPS: What You Don’t Know Can Track you!” I highly recommend checking this blog post out. It covers a number of topics beyond the scope of this particular entry.
* NavTeq RDS-TMC Data Interception by Oona Räisänen – Finland hacker illustrates what data can be acquired from intercepting this traffic monitoring capability. Read more here.
Conclusion
I’d like to take the opportunity to thank the information security community for training me to think critically. I hope that that this research helps you understand GPS device forensics and, in particular, how travel data can be acquired from similar devices.
Share this: