Journal of Digital Forensics, Journal of Digital Forensics,

Security and Law Security and Law

Volume 12 Article 7

3-31-2017

Find Me If You Can: Mobile GPS Mapping Applications Forensic Find Me If You Can: Mobile GPS Mapping Applications Forensic

Analysis & SNAVP the Open Source, Modular, Extensible Parser Analysis & SNAVP the Open Source, Modular, Extensible Parser

Jason Moore

Ibrahim Baggili University of New Haven

Frank Breitinger

Follow this and additional works at: https://commons.erau.edu/jdfsl

Part of the Computer Engineering Commons, Computer Law Commons, Electrical and Computer

Engineering Commons, Forensic Science and Technology Commons, and the Information Security

Commons

Recommended Citation Recommended Citation Moore, Jason; Baggili, Ibrahim; and Breitinger, Frank (2017) "Find Me If You Can: Mobile GPS Mapping Applications Forensic Analysis & SNAVP the Open Source, Modular, Extensible Parser," Journal of Digital Forensics, Security and Law: Vol. 12 , Article 7. DOI: https://doi.org/10.15394/jdfsl.2017.1414 Available at: https://commons.erau.edu/jdfsl/vol12/iss1/7

This Article is brought to you for free and open access by the Journals at Scholarly Commons. It has been accepted for inclusion in Journal of Digital Forensics, Security and Law by an authorized administrator of Scholarly Commons. For more information, please contact commons@erau.edu.

(c)ADFSL

Find me if you can: Mobile GPS mapping ... JDFSL V12N1

FIND ME IF YOU CAN: MOBILE GPS MAPPING

APPLICATIONS FORENSIC ANALYSIS & SNAVP

THE OPEN SOURCE, MODULAR, EXTENSIBLE

PARSERJason Moore, Ibrahim Baggili and Frank Breitinger

Cyber Forensics Research and Education Group (UNHcFREG)Tagliatela College of Engineering

University of New Haven, West Haven CT, 06516, United Statese-Mail: moore.p.jason@gmail.com, {IBaggili, FBreitinger}@newhaven.edu

ABSTRACT

The use of smartphones as navigation devices has become more prevalent. The ubiquity of hand-held navigation devices such as Garmins or Toms Toms has been falling whereas the ownership ofsmartphones and their adoption as GPS devices is growing. This work provides a comprehensivestudy of the most popular smartphone mapping applications, namely Google Maps, Apple Maps,Waze, MapQuest, Bing, and Scout, on both Android and iOS. It details what data was found, whereit was found, and how it was acquired for each application. Based on the findings, the work allowedfor the construction of a tool capable of parsing the data from all of the aforementioned applicationsas well as creating maps of the locations attained. It was discovered that much data relating to theuser’s navigation history, be it addresses, latitude longitude points, etc., were stored on the user’sdevice. It was also found that in almost all cases, discerning whether the user had actually traveledto a destination from the mapping application data was not possible.

Keywords: Mapping application forensics, iOS forensics, Android forensics, GPS forensics, Wazeforensics, Google Maps forensics, Apple Maps forensics, MapQuest forensics, Scout forensics, Bingforensics.

1. INTRODUCTION

In 2015, global smartphone ownership reached1.859 billion people. This is expected to rise toover 2 billion by the end of 2016, and by the endof 2018 smartphone penetration is projected toincrease to just over 36% of the global popula-tion (2.48 billion users) (Statista, 2016). Smart-phones have surpassed the ownership level of per-sonal computers and have become a main ele-ment of crime scene investigations (Umale, Desh-mukh, & Tambhakhe, 2014). McMillan, Glis-son, and Bromby (2013) conducted research inthe United Kingdom which illustrated the rise ofcriminal activities involving smartphones at an

average rate of growth of ten cases per year from2006 to 2011.

A segment of applications that has gonelargely unnoticed by the research community isthat of mapping applications. Paralleled withthe increase in smartphone adoption as naviga-tion devices has been the decrease in the useof hand-held navigation devices like Garmins(Statista, 2012). In the United States alone,Google Maps and Apple Maps, have 64.5 and 42million users, respectively (Buczkowski, 2014),while the remaining applications seen in Table 1account for around a total of 50 million users(Cohan, 2013). Worldwide, both Google Maps(46.7%) and Apple Maps (26.2%) have signifi-

c© 2017 ADFSL Page 15

JDFSL V12N1 Find me if you can: Mobile GPS mapping ...

cant penetration in the mobile domain (Statista,2015).

The nature of mapping applications, navigat-ing a user to a destination, directing users aroundtraffic, etc., makes them likely to hold data onwhere the user has been, what time they werethere, their traveling tendencies, etc., some evenoffer chatting services with other users (see Ta-ble 2). It is apparent why data such as this maybe of importance to investigators and as suchis the reason for the examination of the highlyadopted mapping applications listed in Table 1.

Table 1: Tested applications

Application Android Vers. iOS Vers.

Google Maps 9.6.1 4.8.62649Apple Maps NA 8.3Waze 3.9.3.0 3.2.9.1MapQuest 2.7.7 4.8Bing Maps 5.2.0.20140710 5.4Scout GPS 2.5.1.0021 2.1.1

At the time of writing this paper, literatureon the forensics of smartphone mapping applica-tions was sparse. Our work aimed at filling thegap in the scientific literature.

Our research informs practitioners, researchersand the digital forensics community at large onmethods of extracting data from the applicationsin Table 2. It identified the digital forensic arti-facts that can be found by analyzing each of theseapplications and resulted in a tool that can beused to analyze potential digital evidence fromthe applications.

Manual retrieval of data from these applica-tions would take a considerable amount of timeand expertise. Not all of the files associated withthese applications can be opened and read by hu-man eyes. Some files need to be decoded, somehave no structure making them difficult to follow,and certain files contain data of interest which ishidden amongst an immense amount of irrelevantdata.

Smart NAVigation Parser (SNAVP), the toolconstructed during this research (see Sec. 5),combats all of these issues by i) outputting an

organized, searchable, sortable, and easy to readExcel file where all of the data related to theseapplications can be found ii) eliminating the needto have a person with the expertise needed todecode/translate certain files to a human read-able format, and iii) removing the need for aninvestigator to manually search through a de-vice’s forensic image to locate and extract ev-idence. The tool also contributes a frameworkto the digital forensics community that can eas-ily be built upon to include new versions of thetested applications as well as any new mappingapplications released in the future.

In the remainder of the paper we first discussrelated work in Sec. 2. We then describe ourmethodology in Sec. 3. We later share our find-ings of the artifacts found from the various map-ping applications in Sec. 4. The constructed ex-tensible SNAVP tool is then described in Sec. 5.We lastly present future work and limitations inSec. 6 and conclusions in Sec. 7.

2. RELATED WORK

2.1 Hand-held satellite navigationdevices

Research has been conducted in the area ofhand-held satellite navigation devices such asGarmins, TomToms, and Magellans (Van Eijk& Roeloffs, 2010; Arbelet, 2014). Past work il-lustrated the importance of the digital evidencethat could be extracted from these devices suchas where the user has been, how they got there,who owns them, favorite addresses, etc. (Last,2009). Evidence such as this may lead to anumber of important discoveries during investi-gations including behavioral profiles of those whohave used the device (Colombini, Colella, Cas-tiglione, & Scognamiglio, 2012).

Notwithstanding, satellite navigation devicesare being replaced by smartphone mapping ap-plications. Garmin reported a company worthless than a third of its value in 2007 as well a 15percent reduction in sales in 2013 (Leber, 2013).Much of this drop was accredited to the increas-ing ubiquity of smartphones and the usage of themapping applications on them replacing GlobalPositioning System (GPS) devices.

Page 16 c© 2017 ADFSL

Find me if you can: Mobile GPS mapping ... JDFSL V12N1

Table 2: Application features

Application Navigation Directions Chatting ETA Home/Work Address Favorites Location Sharing

Google Maps X X - - X X -Apple Maps X X - - - X -Waze X X X X X - XMapQuest X X - - X - -Bing Maps - X - - - - -Scout GPS X X X X X X -

2.2 Mobile phone forensics

McMillan et al. (2013) conducted a survey whichfound that calls and Short Message Service(SMS) data held the most evidential importanceduring investigations, however, user and applica-tion data were also found to be of high impor-tance. Much of the work in the mobile forensicsdomain has focused on discovering these types ofdata on various Operating Systems (Hoog, 2011;Casey, Bann, & Doyle, 2010; Simao, Sıcoli, Melo,Deus, & Sousa Junior, 2011).

For instance, Al Mutawa, Baggili, and Mar-rington (2012) investigated the forensic arti-facts that could be extracted from different so-cial media applications such as Facebook, Twit-ter and MySpace. Furthermore, researcherssuch as Mahajan, Dahiya, and Sanghvi (2013)and Thing, Ng, and Chang (2010) examinedwhat digital forensic artifacts could be recov-ered from different messaging services and ap-plications such as WhatsApp and Viber. Newerstudies focused on examining the network foren-sic implications of similar social-messaging appli-cations (Karpisek, Baggili, & Breitinger, 2015;Walnycky, Baggili, Marrington, Moore, & Bre-itinger, 2015).

Maus, Hofken, and Schuba (2011) conducteda study concerning geodata on Android phoneswhere they used geodata from all applications ona device which stored location data in an attemptto provide the investigator with a viewable mapof where the user had been.

However, retrieving data from mobile deviceshas comes with several challenges for researchersand investigators (Bennett, 2012). The na-ture of smartphones, the Central Processing

Unit (CPU) architecture, their processing andmemory resources, as well as the sheer num-ber of used Operating Systems (OS), severelycomplicates the forensic acquisition and analy-sis of these devices (Barmpatsalou, Damopoulos,Kambourakis, & Katos, 2013).

The process gets more complex when one takesinto account the high rate of change in the mobilefield (new applications, application versions, OSversions, etc.), the number of different devicesthat are in use, and the lack of software, hard-ware and interface standardization (Lessard &Kessler, 2010; Baggili, Mislan, & Rogers, 2007).Casey and Stellatos (2008) also noted that en-cryption of the data on these devices is becom-ing more prevalent having notable implicationson digital forensic investigations. These chal-lenges present investigators and researchers witha difficult task whenever a mobile device is beingexamined.

2.2.1 Android forensics

The challenges posed by Android devices stemfrom the wide array of versions the platform sup-ports. Many developers and companies put theirown twist on the platform when releasing theirdevices leading to every device/Android versioncombination to possess unique characteristics. Aminor difference in the Android version may re-quire extensive testing and validation of tools be-fore they can be deemed forensically sound on agiven system (Hoog, 2011).

Android forensics is an active area of re-search. For example, Vidas, Zhang, and Christin(2011) focused on developing a general collectionmethodology for the vast amount of Android de-vices. Distefano, Me, and Pace (2010), however,

c© 2017 ADFSL Page 17

JDFSL V12N1 Find me if you can: Mobile GPS mapping ...

focused on discovering different anti-forensicmethods used on Android devices. Albano, Cas-tiglione, Cattaneo, and De Santis (2011) devel-oped a technique that provided the ability tomodify and erase, securely and selectively, dig-ital evidence on an Android device using simplesoftware tools that are commonly seen on *nix-like operating systems such as Android.

The analysis of phone memory has also beenof importance to Android forensics as valuabledata such as passwords, text messages, etc. maybe contained within the memory (Thing et al.,2010). Many tools have been created to aid inthis process.

Several plugins for Volatility – an advancedmemory forensics framework – were created toread data such as passwords, chat messages, usernames, and e-mail (Macht, 2013). Sylve, Case,Marziale, and Richard (2012) designed a kernelmodule for dumping memory that addressed thedifficulties in developing device-independent ac-quisition tools while Leppert (2012) focused onacquiring and analyzing heap-dumps of Androidapplications.

2.2.2 iOS forensics

Breaking the security barriers of the newer ver-sions of iOS devices so that physical images maybe acquired without jailbreaking the device hasbecome increasingly difficult (Belenko & Skl-yarov, 2011). Jailbreaking involves removing re-strictions on the device so that a physical im-age may be acquired, however, this process al-ters data on the device itself possibly taintingits forensic value. One would have to know thatnone of the user data was altered and that theexact alteration of any other data on the devicebe known for an acquisition method to be con-sidered forensically sound.

The difficulty of acquiring a physical image ofan iOS device has made other extraction meth-ods more prominent when dealing with neweriOS devices. A common approach leveragesthe iPhone backup files created with the iTunesbackup utility (Bader & Baggili, 2010; Morrissey& Campbell, 2010). This method only acquiresdata that has been synchronized by the backupprotocol, but as stated by Hoog and Strzempka

(2011) most of the allocated data can be re-trieved using this method. This method was de-termined to be the premier method for logicalacquisition for iOS devices (Tso, Wang, Huang,& Wang, 2012). Another often used approach islogical extraction. This procedure extracts ac-tive folders and files directly from the iPhone,but does not retrieve any data from the unallo-cated space.

3. METHODOLOGY

The methodology used in this research followedthe guidelines for forensically examining artifactspresented by NIST (Kent, Chevalier, Grance, &Dang, 2006). The smartphones that were usedin our examination were a Samsung S4 Active(SGH-i537) running Android version 4.4.2 andan iPhone 4s Model A1387 running iOS 8.2. To-wards the end of the research, the Samsung S4Active stopped turning on and could no longerbe used, therefore, a Samsung Galaxy S4 Zoom(SM-C101) running Android version 4.4.2 wasused when investigating Google Maps and Bing.

Our research methodology was broken intothree phases data creation and acquisition(Sec. 3.1), data analysis (Sec. 3.2), and tool cre-ation (Sec. 3.3). The high level methodology isportrayed in Fig. 1.

3.1 Phase I: data creation andacquisition

Several actions were performed on each applica-tion. These actions were chosen based on the fea-tures of each application shown in Table 2. Eachaction was recorded and logged so that any dataon the mobile device resulting from the given ac-tion could be discerned.

The devices were acquired using .XRY 1. .XRYis software which forensically extracts data froma variety of mobile devices. A device image wasacquired after each entry shown in Table 3. TheSamsung S4 Active and the Samsung Galaxy S4Zoom were physically acquired, while all of theimages of the iPhone 4S were logical due to phys-ical acquisition of the iPhone 4s not being sup-

1Micro Systemation AB (MSAB), https://www.msab.com/, last accessed 2015-09-29

Page 18 c© 2017 ADFSL

Find me if you can: Mobile GPS mapping ... JDFSL V12N1

Figure 1: High level methodology for Androidand iOS

ported by any tools at the time of conducting theacquisition.

We note that although we used different ac-quisition methods on the devices, our work’sscope focused on the allocated space, makingthe method of extraction not as significant asit would be had any of the data discovered wasfound in unallocated space.

3.2 Phase II: data analysis

Analysis of the acquired forensic images wascompleted using a variety of tools. .XRY andCellebrite were used to mount and explore theacquired images to discover files related to thetested applications.

Once files were identified, several tools wereutilized to inspect the file contents. WinHex 2, auniversal hexidecimal editor, was used to identifyfile headers and inspect the content of files that

2http://www.x-ways.net/winhex/, last accessed2015-11-23

Table 3: Actions performed

# Recorded action

1 A fresh install of the application2 A location was inserted into the appli-

cation and traveled to3 A location was inserted into the appli-

cation and not traveled to4 Application specific features such as

sending messages, sharing locations,etc.

were not recognized by .XRY.

DB Browser for SQLite3 is a visual open sourcetool that allows for the creation, design, editing,and viewing of database files that are compatiblewith SQLite. This tool was used to explore thecontents of any SQlite database encountered.

XML files were inspected with Sublime Text, atext editor for code, markup, and prose 4, whileany binary plist files encountered were inspectedusing a combination of Xcode 7, a powerful IDE5, and the Terminal.

3.3 Phase III: Smart NavigationParser (SNAVP)

SNAVP, the tool created during this research wasdesigned to parse out as much of the data as pos-sible that was found based on our findings. Itwas designed as a command line tool with mod-ularity and extensiblity in mind so that addi-tional parsers may be added it to it at any time.SNAVP is discussed in further detail in Sec. 5.

4. RESULTS

This section describes the results of the artifactsfound in detail. For a summary of the artifactsfound, refer to Table 5 and Table 6.

3http://sqlitebrowser.org/, last accessed 2015-12-09

4http://www.sublimetext.com/, last accessed 2015-12-07

5https://developer.apple.com/xcode/, last ac-cessed 2015-11-20

c© 2017 ADFSL Page 19

JDFSL V12N1 Find me if you can: Mobile GPS mapping ...

4.1 Google Maps - Android

Google Maps contained four files of evidentiaryvalue: da destination history, search history.db,com.google.android.apps.maps preferences.xml,and DATA SYNC DATA.

da destination history was a SQLite databasefile that contained location data related to thestarting and ending locations that the user se-lected to retrieve directions to. In order for datato be present in this database the user had tohave selected navigate after entering in locations.

search history.db, another SQLite database,held the user’s search data. This meant thatnavigation was not necessary for data to appearin this database, the data was entered as soon asthe user searched for any location within GoogleMaps.

com.google.android.apps.maps preferences.xmlwas an XML file that contained the user’spreferences and more specifically the last useraccount name to use Google Maps.

DATA SYNC DATA contained cloud databased on the user account that was using theapplication. So, for example, if a user had saveda search using a different device, that locationwould be found in this file so that it could beused on any device as long as the user was signedinto Google Maps.

4.2 Google Maps - iOS

No data that related to the user’s searches, nav-igation, or saved locations were found on theiPhone, however, the file com.google.Maps.plistdid include the user’s last known location alongwith what seemed to be other files of interest. Incom.google.Maps.plist was a reference to a plistfile called 1436530344726.plist. The name of theplist file, 1436530344726, was in the form of aUnix timestamp that converted to July 10, 8:12AM EST, the time at which the last search oc-curred while using Google Maps.

4.3 Apple Maps

Only one file, GeoHistory.mapsdata, was foundto contain data related to the user’s actions inApple Maps. GeoHistory.mapsdata was a plistfile that held data pertaining to what the userhad searched for within the application as well as

Yelp reviews for the given locations if applicable.

4.4 Waze - Android

The files waze log.txt, user.db, tiles nt.db, andtts.db were found to hold data related to theuser’s activity while using the Waze application.

waze log.txt contained an immense amount ofdata. The file was separated into active sessionswhich were defined as the time from when theuser had opened the Waze application to whenthey closed out of it. Three different actionswere found to cause a RoutingRequest within thisfile i) when a route was requested by the userii) when GPS signal was lost and then foundagain during navigation, and iii) when reroutingoccurred during navigation. A RoutingRequestcontained a starting and ending location in theform of latitude and longitude points for the re-quested route, and the two lines directly aboveeach RoutingRequest contained a timestamp andcurrent location of the user.

user.db was a SQLite database that containeda plethora of data including the destination theuser had received directions to, the time at whichthe directions were requested, and the EstimatedTime of Arrivals (ETAs) that were sent or re-ceived. It is critical to note that the data men-tioned appeared in the database at the time nav-igation was selected within Waze; meaning thatthere was no way to discern whether the user hadactually traveled to the destination form the datafound in this database.

tiles nt.db was a SQLite database that con-tained data which related to images of the piecesof maps that were needed for navigation sessions.An approach to relate the entries in this databaseto the many locations that were navigated to wasnot discovered and warrants future research.

tts.db was another SQLite database. It heldpaths to the audio direction files that were usedduring navigation, i.e. turn right, continuestraight, etc. However, a way to link the entriesin this table to specific navigation sessions wasnot found.

Waze uniquely had the feature of sending andreceiving messages to other users. The messagesthat were sent and received were not found onthe device, however, prior research by Storozuk

Page 20 c© 2017 ADFSL

Find me if you can: Mobile GPS mapping ... JDFSL V12N1

(2014) found that the messages could be foundin the device’s memory.

4.5 Waze - iOS

The only file found on the logical image of theiPhone was user.db. This SQLite database hadthe exact same structure and data as its Androidcounterpart (see Sec. 4.4).

4.6 MapQuest - Android

A SQLite database named search.db containedall of the data pertaining to the places that theuser navigated to while using MapQuest. Threefields within the search table were found to holdthe most importance in this research.

Two fields contained UNIX timestamps. Thectime field referred to when the user hadsearched for directions, while the atime field re-ferred to the time that MapQuest actually re-trieved the directions that were queried.

The third field was titled json and was a jsonfield that contained the address and longitudeand latitude coordinates of the destination alongwith a userInput key that held the text that theuser had actually searched for.

4.7 MapQuest - iOS

The data that related to the user’s navigationhistory while using MapQuest was found in thefile com.aol.mapquest.plist. This plist file con-tained data such as latitude and longitude co-ordinates and addresses of destinations searchedfor or marked as a favorite by the user. How-ever, there were no timestamps associated withthese entries and the data structure was the samewhether the destination was actually traveled toor not.

4.8 Bing Maps

Bing Maps was unique in that it was not a standalone mapping application; the Bing Maps seg-ment was just a part of the overall Bing appli-cation. As the purpose of this research was totest mapping applications, only the Bing Mapsportion of the application was tested. Further,Bing had the option to search privately, and ifthe user was in private mode, Bing claimed thatthe users search history would not be stored bythe application.

4.8.1 Bing Maps - Android

A single SQLite database file, SearchHistory-Database.db, held the user’s search history whenprivate browsing was not enabled. It had a sim-ple structure of three tables with the table of in-terest being SearchHistory. The NAME field inthis table referred to the text that was searchedfor and the LAST field correlated with the timethat the search occurred.

4.8.2 Bing Maps - iOS

The iOS version of Bing was found to hold sev-eral files that contained data regarding the ac-tions performed by the user, a History.plist filealong with multiple *.dat files.

History.plist contained the search history ofthe user as long as private searching was not en-abled. Any search that occurred while privatesearching was enabled did not result in an en-try in Historys.plist. For an entry to be madehere, the location had to be searched for usingthe search bar of the Bing Maps application. Ifthe “get directions” icon was pressed prior tosearching for a location then that location wouldnot appear in Historys.plist.

The *.dat files, where the * represents an inte-ger value, were found at two locations. The non-private version of the *.dat file was stored in theDocuments/Journal directory. This directorydid not exist until a search had occurred withinthe application, while the private version of thesefiles were stored in the Documents/PriJournaldirectory, and similar to the non-private version,the PriJournal directory did not exist until asearch had occurred when privacy was enabled.

It was found that the highest numbered *.datfile contained data on the most recent locationthat was searched by the user, with or withoutprivate browsing enabled.

4.9 Scout - Android

Two files were found which contained datadeemed of evidentiary value, a SQLite databasenamed scoutAppDatabase.db and an XML file ti-tled Route *.

scoutAppDatabase.db contained eight tablesthat held data pertaining to the user’s actionswhile using Scout. This included members of

c© 2017 ADFSL Page 21

JDFSL V12N1 Find me if you can: Mobile GPS mapping ...

chat sessions, the messages themselves, config-uration data, the address along with the longi-tude and latitude coordinates of locations thatwere navigated to, and usernames of friends ofthe user.

A different Route * file was created each timea location was navigated to where the * was re-placed by the UNIX timestamp of when the nav-igation session was first created. Within the filewas detailed information about every route thatwas offered to the user for a given destinationand also specified the exact route that the userhad chosen. Each route was broken up into seg-ments, thereby allowing one to reconstruct eachgiven route by combining their respective seg-ments.

Unfortunately, in both files, the location datawas created at the time that navigation was re-quested, making it difficult to discern whetherthe user had actually traveled to the destination.

4.10 Scout - iOS

Only one plist file, namelycom.telenav.scout.push store.log was foundto hold data related to user’s navigation, how-ever, the data within this file was incomplete.For example, the file held the UNIX timestampof when the navigation was started and onlythe final direction of the navigation session, i.e.in one of the test scenarios, the only directionfound was “Turn left to Ruden St” (the finaldirection before the user would reach theiractual destination). Because of this, the se-quence of actions performed on the iOS devicewere completed several times as to ensure thatthe lack of data was not caused by an error,but still, only incomplete data was found incom.telenav.scout.pushstore.log.

Our findings helped us construct the basis fora parser for all of these applications which wediscuss in the Sec. 5 that follows.

5. SMART NAVIGATIONPARSER (SNAVP)

In its initial release, SNAVP was designed as acommand line tool that took one required pa-rameter and one optional parameter. The re-

quired parameter was signified by a -i and tookthe location of the input, i.e. a file, a directory,a device image, a zip file etc., as an argument.The optional parameter was signified by a -o andwas the location where the program would writeits output to. If no argument was provided forthe output location, the output defaulted to thecurrent working directory.

After the input was received, the program pro-ceeded to determine the nature of the input, i.e.whether it is a tar file, an image file, a single file,or a directory. The type of input determined thenext steps, a tar file would have to be unpacked,an image would have have to be mounted, etc.,however, we note that not all image files weremountable (see Sec. 6). Each file in the inputwas then iterated over and had its file header orextension checked to determine if it was a file ofinterest.

A file of interest was defined as a binary plist(bplist), a sqlite database, a text file, or an XMLfile. These were all of the file types from thetested applications that were found to hold digi-tal evidence of forensic value. If a file was of in-terest, the parsers would run their validity checkagainst the file, and if passed, the parser wouldthen parse the file and send the parsed data backto the main program where it would be writtenout to an Excel file.

The first sheet of every Excel file, titledParsers Ran (see Figure 2), lists the parsers thatwere run on the input given, provide the file pathto the file that they were run on and the colorof the marks for each respective application thatcan be seen on the All Applications Map (Fig-ure 3). The data retrieved from each individualparser was contained on its own respective sheetwithin the created Excel document.

5.1 Program structure

The first file shown in Figure 4 is ParseCon-trol.py. This file controlled the overall program.It received the user’s input, ran the necessaryparsers, collected the data, created the map files,and wrote it all out to an Excel file.

The Dependencies folder contained three keyelements of SNAVP. FileCheck.py determinedwhether or not a given file was of the type txt,

Page 22 c© 2017 ADFSL

Find me if you can: Mobile GPS mapping ... JDFSL V12N1

Figure 2: First sheet of SNAVP output

Figure 3: All applications map

sqlite, plist, or xml. This was determined byusing the file header and/or the file extension.The action of Mount.py is determined by the in-put that was given. If the input was an imagefile, Mount.py would attempt to mount the fileso that its contents could be read. If the inputwas a tar or zip file, it would extract the datato a given folder so that it may be read, etc.WorksheetData.py contained the WorksheetDataclass. This class was used to store the data fromthe individual parsers in a manner that ParseC-ontrol.py could interpret.

The Parsers folder contained all of the indi-vidual parsers that could be executed. As men-tioned in Sec. 3.3, SNAVP was designed in amodular manner. To add a new parser to thetool, one would only have to add the parser fileto this folder, and add the file name to the init.pyfile. As long as the parser created followed theWorksheetData class, it would be correctly inte-

Figure 4: SNAVP structure

grated into SNAVP.

5.2 Dependencies

• The Sleuth Kit - is a C library along witha collection of command line tools that al-low the analysis of disk images. Many tools,such as Autopsy, use The Sleuth Kit behindthe scenes 6. SNAVP used The Sleuth Kitto mount image files and extract files of in-

6The Sleuth Kit (TSK), http://www.sleuthkit.org/,last accessed 2015-09-29

c© 2017 ADFSL Page 23

JDFSL V12N1 Find me if you can: Mobile GPS mapping ...

terest so that they may be parsed.

• pytsk3 - is a Python package that is aPython binding for The Sleuth Kit 7. Thisallowed SNAVP to programmatically mountimages so that they could be searched to de-termine if any files of interest resided on theimage. Those files were then extracted andparsed if applicable.

• pygmaps - is another Python package that isa Python wrapper for Google Maps 8. Thisprovided SNAVP with the capability to gen-erate HTML files that plot given coordinateson Google Maps.

• ccl-bplist - is a Python module that helpsdeal with binary plist files (bplists) 9.SNAVP utilized this module when attempt-ing to parse any bplists that it encountered.

• XlsxWriter - is a Python module that al-lowed the creation of Excel XLSX files 10.This module was used to organize and pro-duce the parsed data into an Excel work-book in a meaningful manner.

6. LIMITATIONS & FUTUREWORK

The rate at which new versions of applicationsare released is overwhelming. SNAVP was testedon the specific application versions shown in Ta-ble 1. This does not mean it will not work onother versions, however, it is possible that newand old versions of these applications have dif-ferent file names, schemas for their files, etc. Tocombat this challenge SNAVP was created in amodular manner so that new parsers may beadded to support any new or old versions of thetested applications as well as any additional GPSapplications.

7pytsk3, https://github.com/py4n6/pytsk, last ac-cessed 2015-09-29

8pygmaps, https://code.google.com/p/pygmaps/,last accessed 2015-09-29

9ccl-bplist, https://code.google.com/p/

ccl-bplist/, last accessed 2015-09-2910XlsxWriter, http://xlsxwriter.readthedocs.org/,

last accessed 2015-09-29

It is also important to note that the data thatall of these applications were tested with wasminimal in comparison to real data. The toolmay error out on larger sets of data as not all pos-sibilities could be accounted for with such smallsets of test data.

When a device image file was used as input,not all of the images were mountable. For exam-ple, .XRY used a proprietary file type .xry thatcaused the program to error out when attempt-ing to mount the image. Therefore, any imagefile that could not be mounted resulted in theuser having to manually locate and extract thefiles of interest, then use the directory that thefiles were placed in as the input to the tool.

All of the latitude longitude points mappedby SNAVP were only accurate within the UnitedStates. Many of the applications did not putthe decimal point in the latitude or longitudecoordinate when it was saved; SNAVP had toperform this action. The decimal points vary inlocation depending on the actual latitude or lon-gitude, therefore, the tool only guaranteed accu-racy when it placed the decimal point for loca-tions that were in the United States.

7. CONCLUSION

An immense amount of potential digital evidencerelated to the examined applications were dis-covered during this research (summarized in Ta-ble 5 and Table 6). This data could hold greatevidentiary value during different types of inves-tigations. The timestamps combined with thecurrent locations in Waze can place users in cer-tain vicinities at certain times thereby corrobo-rating a story or an alibi. Knowing the routethat a user had taken (data from the Scout ap-plication) can be used to locate evidence the sus-pect may have dropped along a route or locatecameras that may be used to track a suspect.

Table 4 rates the tested applications, 1 beinghighest and 10 being lowest, on the determinedforensic value that they hold. The rankings arerelative to each other and are a reflection onthe amount and the type of data that was as-certained from each application during this re-search. It is important to note that none of the

Page 24 c© 2017 ADFSL

Find me if you can: Mobile GPS mapping ... JDFSL V12N1

data mentioned in this work was found in unal-located space on the devices.

Table 4: Determined forensic value ranking ofapplications

Forensic value Application

1 Waze (Android)2 Scout (Android)3 Google Maps (Android)4 Waze (iOS)5 MapQuest (Android)6 Bing (iOS)7 MapQuest (iOS)8 Apple Maps9 Google Maps (iOS)10 Scout (iOS)

The Android version of Waze topped the list.In addition to the starting and ending naviga-tional points, it was found to periodically storethe current location of the user. Scout for An-droid was next, it was found to store all of theroutes given to the user for a navigation sessionalong with the route that was chosen by the user.It also contained messages that were sent be-tween users on the application. Google Maps wasranked third because it stored the starting andending location of provided routes. Only the toprated applications provided a starting location.

Applications ranked 4 through 6 were all sim-ilar as they provided data about the locationsthat were searched for or navigated to. Notwith-standing, they did not provide starting locations.MapQuest for iOS and Apple Maps were ranked7th and 8th respectively. They both provideddata on the user’s search and navigation historybut they did not store any timestamps with thedata making it difficult to determine a timelinefor the user. Google Maps for iOS ranked slightlyahead of Scout due to being able to determine theuser’s last location right before exiting GoogleMaps. The iOS version of Scout came in lastas almost no data that related to the locationssearched for or navigated to were found on thedevice. Note that the Android version of Bing isnot listed in Table 4 since it could not be fully

examined during this research.

The downfall to the data that was found onthe devices was that actual travel was never re-quired for data to be saved. Most of the testedapplications stored their data when it was eithersearched for or navigated to. This could hurtcases as the user cannot be placed at a particu-lar point or on a particular route without someother form of corroborating evidence. Again, theAndroid version of Waze was the only applicationthat was found to store the user’s current loca-tion at different times; this data was found inWaze’s log file. To combat this challenge, futurework could attempt to correlate GPS locationsfrom multiple devices, as well as GPS log datafrom the OS with the ones found from the stud-ied applications.

As mentioned in Sec. 2, valuable data wasfound on handheld navigation devices such asTomToms and Magellans. In fact, the data foundwas very similar to that which was found in thisstudy. As with the data found on the smart-phones, data such as locations entered to, home,work, and favorite addresses could be found onhandheld navigation devices, however, there wasone immense benefit gained from the data foundon handheld navigation devices as opposed tothe data found on smartphones. With handheldnavigation devices one was able to differentiatewhether a location in the GPS was actually trav-eled to (Nutter, 2008).

Although being able to differentiate betweenthese two circumstances may be of importance,the rest of the mapping data found on the smart-phones was decidedly similar to that found onhandheld navigation devices. Thus, as it hasbeen discussed by Strawn (2009) that GPS de-vices have helped prosecutors win cases, one mayargue that the mapping data found on the smart-phones during this research would still be ofparamount importance during investigations.

REFERENCES

Albano, P., Castiglione, A., Cattaneo, G., &De Santis, A. (2011). A novel anti-forensicstechnique for the android os. In Broad-band and wireless computing, communica-

c© 2017 ADFSL Page 25

JDFSL V12N1 Find me if you can: Mobile GPS mapping ...

tion and applications (bwcca), 2011 inter-national conference on (pp. 380–385).

Al Mutawa, N., Baggili, I., & Marrington, A.(2012). Forensic analysis of social network-ing applications on mobile devices. DigitalInvestigation, 9 , S24–S33.

Arbelet, A. (2014). Garmin satnav foren-sic methods and artefacts: an exploratorystudy. (Unpublished doctoral dissertation).Edinburgh Napier University.

Bader, M., & Baggili, I. (2010). iphone 3gs foren-sics: Logical analysis using apple itunesbackup utility. Small scale digital deviceforensics journal , 4 (1), 1–15.

Baggili, I. M., Mislan, R., & Rogers, M. (2007).Mobile phone forensics tool testing: Adatabase driven approach. InternationalJournal of Digital Evidence, 6 (2), 168–178.

Barmpatsalou, K., Damopoulos, D., Kam-bourakis, G., & Katos, V. (2013). A criticalreview of 7 years of mobile device forensics.Digital Investigation, 10 (4), 323–349.

Belenko, A., & Sklyarov, D. (2011). Evolutionof ios data protection and iphone forensics:from iphone os to ios 5. In Blackhat abudhabi conference.

Bennett, D. (2012). The challenges facing com-puter forensics investigators in obtaininginformation from mobile devices for use incriminal investigations. Information Secu-rity Journal: A Global Perspective, 21 (3),159–168.

Buczkowski, A. (2014). The us mobileapp report - google maps app 64.5musers, apple maps 42m - geoawe-someness. Retrieved 2015-9-29, fromhttp://geoawesomeness.com/the-us

-mobile-app-report-google-maps-app

-64-5m-users-apple-maps-42m/

Casey, E., Bann, M., & Doyle, J. (2010). Intro-duction to windows mobile forensics. digi-tal investigation, 6 (3), 136–146.

Casey, E., & Stellatos, G. J. (2008). The impactof full disk encryption on digital forensics.ACM SIGOPS Operating Systems Review ,42 (3), 93–98.

Cohan, P. (2013). Four reasons google

bought waze. Retrieved 6.16.2015,from http://www.forbes.com/sites/

petercohan/2013/06/11/four-reasons

-for-google-to-buy-waze/

Colombini, C. M., Colella, A., Castiglione, A.,& Scognamiglio, V. (2012). The digitalprofiling techniques applied to the analysisof a gps navigation device. In Innovativemobile and internet services in ubiquitouscomputing (imis), 2012 sixth internationalconference on (pp. 591–596).

Distefano, A., Me, G., & Pace, F. (2010).Android anti-forensics through a localparadigm. digital investigation, 7 , S83–S94.

Hoog, A. (2011). Android forensics: inves-tigation, analysis and mobile security forgoogle android. Elsevier.

Hoog, A., & Strzempka, K. (2011). iphone andios forensics: Investigation, analysis andmobile security for apple iphone, ipad andios devices. Elsevier.

Karpisek, F., Baggili, I., & Breitinger, F. (2015).Whatsapp network forensics: Decryptingand understanding the whatsapp call sig-naling messages. Digital Investigation, 15 ,110–118.

Kent, K., Chevalier, S., Grance, T., & Dang, H.(2006). Guide to integrating forensic tech-niques into incident response. NIST SpecialPublication, 800–86.

Last, D. (2009). Gps forensics, crime, and jam-ming. GPS World .

Leber, J. (2013). A shrinking garmin navigatesthe smartphone storm. Mar.

Leppert, S. (2012). Android memory dumpanalysis. Student Research Paper, Chairof Computer Science, 1 .

Lessard, J., & Kessler, G. (2010). Android foren-sics: Simplifying cell phone examinations.

Macht, H. (2013). Live memory forensics on an-droid with volatility. Friedrich-AlexanderUniversity Erlangen-Nuremberg .

Mahajan, A., Dahiya, M., & Sanghvi, H. (2013).Forensic analysis of instant messenger ap-plications on android devices. arXivpreprint arXiv:1304.4915 .

Maus, S., Hofken, H., & Schuba, M. (2011).

Page 26 c© 2017 ADFSL

Find me if you can: Mobile GPS mapping ... JDFSL V12N1

Forensic analysis of geodata in androidsmartphones. In International confer-ence on cybercrime, security and digitalforensics, http://www. schuba. fh-aachen.de/papers/11-cyberforensics. pdf.

McMillan, J. E. R., Glisson, W. B., & Bromby,M. (2013). Investigating the increase inmobile phone evidence in criminal activi-ties. In System sciences (hicss), 2013 46thhawaii international conference on (pp.4900–4909).

Morrissey, S., & Campbell, T. (2010). iosforensic analysis for iphone, ipad, and ipodtouch (Vol. 23). Springer.

Nutter, B. (2008). Pinpointing tomtom locationrecords: A forensic analysis. Digital Inves-tigation, 5 (1), 10–18.

Simao, A. M. d. L., Sıcoli, F. C., Melo, L. P. d.,Deus, F. E. G. d., & Sousa Junior, R. T. d.(2011). Acquisition and analysis of digitalevidencein android smartphones.

Statista. (2012). People who use their cellphone for maps/gps navigation (usa),2012. Retrieved 2015-9-29, from http://

www.statista.com/statistics/231615/

people-who-use-their-cell-phone-for

-maps-gps-navigation-usa/

Statista. (2015). Mobile apps: U.s.smartphone audience reach 2015— statistic. Retrieved 2015-9-29,from http://www.statista.com/

statistics/281605/reach-of-leading

-us-smartphone-apps/

Statista. (2016). Number of smartphoneusers* worldwide from 2014 to 2019 (inmillions). Retrieved 20.1.2016, fromhttp://www.statista.com/statistics/

330695/number-of-smartphone-users

-worldwide/

Storozuk, D. (2014). Waze forensics adigital forensic capstone researchproject. Retrieved 7.6.2015, fromhttp://wazeforensics.blogspot.com/

Strawn, C. (2009). Expanding the potential forgps evidence acquisition. Small Scale Dig-ital Device Forensics Journal , 3 (1), 1–12.

Sylve, J., Case, A., Marziale, L., & Richard,G. G. (2012). Acquisition and analysis

of volatile memory from android devices.Digital Investigation, 8 (3), 175–184.

Thing, V. L., Ng, K.-Y., & Chang, E.-C. (2010).Live memory forensics of mobile phones.digital investigation, 7 , S74–S82.

Tso, Y.-C., Wang, S.-J., Huang, C.-T., & Wang,W.-J. (2012). iphone social networking forevidence investigations using itunes foren-sics. In Proceedings of the 6th internationalconference on ubiquitous information man-agement and communication (p. 62).

Umale, M. M. N., Deshmukh, A., & Tambhakhe,M. (2014). Mobile phone forensics chal-lenges and tools classification: A review.International Journal on Recent and Inno-vation Trends in Computing and Commu-nication, 2 (3), 622–626.

Van Eijk, O., & Roeloffs, M. (2010). Foren-sic acquisition and analysis of the randomaccess memory of tomtom gps navigationsystems. Digital Investigation, 6 (3), 179–188.

Vidas, T., Zhang, C., & Christin, N. (2011).Toward a general collection methodologyfor android devices. digital investigation,8 , S14–S24.

Walnycky, D., Baggili, I., Marrington, A.,Moore, J., & Breitinger, F. (2015). Net-work and device forensic analysis of an-droid social-messaging applications. Dig-ital Investigation, 14 , S77–S84.

c© 2017 ADFSL Page 27

JDFSL V12N1 Find me if you can: Mobile GPS mapping ...

Table 5: Android - summary of results

Application File Description

Google Maps da destination history SQLite database that containeddata related to navigations that oc-curred within Google Maps

Google Maps search history.db SQLite database that containeddata related to searches that oc-curred within Google Maps

Google Maps DATA SYNC DATA Contained data from the user’s ac-count that did not take place on thegiven device or took place prior toGoogle Maps being uninstalled

Waze waze log.txt Text file that contained locationdata related to routes selected bythe user and their current locations

Waze user.db SQLite database that containeddata related to navigations selectedby the user

MapQuest search.db SQLite database that containeddata related to the navigation his-tory of the user

Bing SearchHistoryDatabase.dbSQLite database that containeduser search history when privatebrowsing was disabled

Scout scoutAppDatabase.db SQLite database that containednavigation and messaging data re-lated to the user

Scout Route * XML file that contained the differ-ent routes for navigation sessions,the * represented the unix times-tamp of the start of the respectivenavigation session

Page 28 c© 2017 ADFSL

Find me if you can: Mobile GPS mapping ... JDFSL V12N1

Table 6: iOS - summary of results

Application File Description

Apple Maps GeoHistory.mapsdata Plist file that contained data relatedto the user’s search history

Waze user.db SQLite database that containeddata related to navigations selectedby the user

MapQuest com.aol.mapquest.plist Plist file that contained navigationdata relating to the user

Bing Historys.plist Plist file that contained data thatpertained to user searches

Bing *.dat (Non-private browsing) Plist file that contained data on themost recent search, the * repre-sented an integer value

Bing *.dat (Private browsing) Plist file that contained data on themost recent private search, the *represented an integer value

Scout com.telenav.scout.pushstore.log Plist file that contained incompletenavigational data

c© 2017 ADFSL Page 29

JDFSL V12N1 Find me if you can: Mobile GPS mapping ...

Page 30 c© 2017 ADFSL