University of Amsterdam
MSc System and Network Engineering
Computer Crime & Forensics
Forensics on mobile travelplanner applications
Authors:
Thom [email protected]
Robert [email protected]
March 30, 2016
Abstract
Nowadays, using smartphones has become ubiquitous for everyday tasks. Anexample is the planning of public transport journeys. The information storedby travel applications may leave traces of a person’s travel history, which maycorrelate to locations visited by this person at a particular time.
In this research, we investigate the forensic value of data originating fromthe two of the most prevalent Dutch travel planning applications for Android:“NS Reisplanner Xtra” and “9292”. We define several use cases to generatesimulated user data. The data stored by the NS application captures locationinformation and location relations. The data stored by the 9292 applicationonly captures location information. However, by matching the timestamps ofvarious locations, the relations between these location may still be derived.
In the NS application, users may remove their travel history data. However,we found that this data may remain on the database after deletion. Instead ofbeing erased, the data merely marked for deletion in the Unallocated Space ina SQLite database. Using a hex editor we were able to extract all informationfrom the database after it was ‘removed’.
We spread a questionnaire that aimed to correlate application data to actualtravel behaviour. We found that most respondents visit the location they look upusing the aforementioned applications. However, we conclude that these resultsshould not be extrapolated to the general Dutch public as our respondents arenot representative for this population.
Contents
1 Introduction 11.1 Research question . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Report structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Experimentation 32.1 Research outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.1 Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . 42.3.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Results 53.1 Database structure . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 NS Reisplanner Xtra . . . . . . . . . . . . . . . . . . . . . 53.1.2 9292 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2.1 NS: Plan a journey from address to station . . . . . . . . 63.2.2 NS: Remove trip history . . . . . . . . . . . . . . . . . . . 73.2.3 NS: Remove locations . . . . . . . . . . . . . . . . . . . . 83.2.4 9292: Plan a journey from current location . . . . . . . . 93.2.5 9292: Plan a journey from address to station . . . . . . . 103.2.6 9292: Save a journey . . . . . . . . . . . . . . . . . . . . . 113.2.7 9292: Remove a journey . . . . . . . . . . . . . . . . . . . 12
3.3 Counter-forensics and detecting counter forensics . . . . . . . . . 133.3.1 In-app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.2 In Android . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Questionnaire results . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.1 Respondents and platforms . . . . . . . . . . . . . . . . . 153.4.2 Application usage . . . . . . . . . . . . . . . . . . . . . . 15
4 Discussion 184.1 Counter Forensics . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2 Unallocated space data retention . . . . . . . . . . . . . . . . . . 184.3 Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Conclusion 19
6 Future work 206.1 SQLite forensics . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.2 Data correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.3 Volatile memory . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.4 Other platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A Test environment 22A.1 Phones and Emulator . . . . . . . . . . . . . . . . . . . . . . . . 22A.2 Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22A.3 Tools and software . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B Use cases 24B.1 NS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.1.1 NS: Plan a journey from station to station . . . . . . . . . 24B.1.2 NS: Save location . . . . . . . . . . . . . . . . . . . . . . . 25B.1.3 NS: Save a journey to ’Mijn reizen’ . . . . . . . . . . . . . 26B.1.4 NS: Log in . . . . . . . . . . . . . . . . . . . . . . . . . . 27B.1.5 9292: Plan a journey from station to station . . . . . . . 28B.1.6 9292: Save a location . . . . . . . . . . . . . . . . . . . . 29B.1.7 9292: Remove a location . . . . . . . . . . . . . . . . . . . 30
AcronymsAPI Application Programming Interface.
GPS Global Positioning System.
NS Nederlandse Spoorwegen (Dutch Railroad operator).
OS Operating System.
OV Openbaar Vervoer (Public Transportation).
SDK Software Development Kit.
VM Virtual Machine.
CHAPTER1
IntroductionNowadays, using smartphones has become ubiquitous for everyday tasks. Anexample is the planning of public transport journeys. In the past people wouldrely on the information given to them at the physical station, they may nowlook at one of the several applications on their smartphone for exact traveltimes, planning, delays and other information. This development has lead tothe removal of most static information boards on Dutch train stations [1].
Currently, the police and criminal investigation services actively use traveldata from the OV-chipkaart to track (missing) persons [2]. Data stored by travelapplications may also leave traces of a person’s travel history, which may reveallocations visited by this person at a particular time.
In this research, we aim to identify the forensic value of data originatingfrom Dutch mobile public transport planning applications. We investigate whatdata is stored by these applications, what user actions can affect the integrityof this data, how these actions can be detected, and how the affected data canbe restored. Additionally, we use a questionnaire investigate how applicationdata correlates to actual travel behaviour.
1.1 Research question
The main question that will be answered in this research is: What is the valueof local data stored by Dutch mobile public transport planning applications in aforensic investigation?.
To answer the main question, we addressed several subquestions that guideour research:
• What data can be gathered from Dutch public transport planning appli-cations on Android phones?
• What actions can affect the integrity of this data?
– how can these actions be detected?
– how can the original data be restored?
• How does data from public transport planning applications correlate toactual travel behaviour?
1
1.2 Related work
A considerable amount of research has been done in the field of forensics onAndroid devices. Researches have investigated the Android OS, applications,and its services for this purpose. Among others, Instant Messenger applicationssuch as WhatsApp are investigated by Mahajan et al. [3]. More general services,and their derived data is also investigated; geodata from GPS is investigatedby Maus et al.[4]. He proposes an automated tool to collected this data from avariety of applications that use the GPS service.
In this research, we will focus on data that can be obtained from Dutchmobile public transport planning applications. To the extent of our knowledge,research into these applications has not yet been conducted.
1.3 Report structure
In this chapter (1), we introduced our research. In the next chapter (2) wewill describe the scope of our research and in what setup the experiments wereperformed. In general, we will elaborate on how the research was conducted.In chapter 3 we describe the results to our research. We elaborate on thedata stored by the applications, how the integrity of this data can be harmed,and how counter-forensics may be detected. We also present the results of aquestionnaire that aims to correlate application data to actual travel behaviour.In chapter 4 we will discuss our results, and we will draw conclusions on ourresults in chapter 5. In the last chapter (6), we will propose future work.
Throughout the report we will refer to the appendix where appropriate. Theappendix may be used complementary to the main text of our report, as it doesnot contain any leading information.
2
CHAPTER2
ExperimentationIn this chapter, we will describe the scope of our research and in what setup theexperiments were performed. In general, we will elaborate on how the researchwas conducted.
2.1 Research outline
To investigate what information can be derived from the application (9292 andReisplanner Xtra) we composed use cases to generate simulated user data. Eachtime we performed a use case, the application’s database was retrieved from thedevice and it was compared to a baseline database. We use this method toidentify how data is affected when user performs certain actions.
Valuable data may be stored in some use cases, and may be removed inothers. In addition to these use cases, we also investigate how Android’s systemfunctionality may be used to harm the integrity of application data.
Using a variety of tools (subsection 2.3.3: Tools), we analyse and recoverdata affected by our experiments. The aim of this investigation is to determinethe forensic value of the data.
As data stored by the application may not correspond to actual travel be-haviour, we spread a questionnaire that aims to correlate application data toactual travel behaviour. The results to our experiments are shown in chapter 3:Results
2.2 Scope
This research focuses on the 9292 and the NS Reisplanner Xtra applications.These applications are the most installed Dutch public transport applicationsfrom Google’s Play1. This research mainly focuses on Android, as all forensicsand counter-forensics experiments are performed on this platform. We inves-tigate how counter-forensics can be performed using in-app functionality, andonly user-privileged system functionality. To investigate how counter-forensicscan be detected and how corrupted data can be recovered, our research has doesnot specify any constraint on the user’s privileges.
1NS Reisplanner Xtra: between 1,000,000 - 5,000,000 & 9292: between 1,000,000 - 5,000,000
3
2.3 Test environment
In this section, we will elaborate on what platforms where used to conductour research, what application versions were investigated, and which tools wereused to perform the research. A detailed overview of our test environment andsoftware versions is provided in Appendix A: Test environment.
2.3.1 Platforms
The research was conducted in an environment consisting of an Android emu-lator (API Level: 23), and two rooted Android devices: the Motorola Moto E(XT1021) and the Oneplus One (bacon A0001). The two devices operated onAndroid 5.1, build LPC23.13-34.8, and Android 5.0.2, build LRX22G respec-tively. A more detailed overview of the platforms used in our experiments canbe found in section A.1: Phones and Emulator.
2.3.2 Applications
As aforementioned, we investigated the two most installed Dutch travel plan-ning applications available for the Android platform. Both applications havebeen installed on between one to five million devices [5, 6]. We investigatedReisplanner Xtra version 4.2.4 which was released on February 23, 2016, andwe investigated 9292 version 1.4.6, which was released on December 18, 2015.
2.3.3 Tools
One of the tools we used was the Android Debug Bridge (ADB) from Androidplatform-tools 23.1. This tool provides an interactive shell which may be used tosynchronize data to and from the device. To analyse the the data obtained fromthe device, we used several tools. We inspected the obtained SQLite Databasesusing SQLite3 version 3.8.7.4 and SQLiteBrowser version 3.2.0.
Each time we performed a use case, the application’s database was retrievedfrom the device to identify how data is affected. We used sqldiff2 to comparea baseline database to the same database after a user case was performed.sqldiff derives what SQL statements have been executed in order for thechange to happen. We used sqldiff version 3.11.1 during experimentation.
To recover deleted entries and to investigate the unallocated spaces in SQLitedatabases, the commercial tool “Sqlite Forensics Explorer”3 was used. All toolsavailable for Linux were installed on Ubuntu 15.10, running on the 4.2.0-27-generic kernel. Tools that are only available for Windows were installed on aWindows 7 VM.
2https://www.sqlite.org/sqldiff.html3http://www.sqliteviewer.org
4
CHAPTER3
Results
3.1 Database structure
In this section we will elaborate on data fields found in the application’s databases,which contain valuable data from a forensics point of view. Later in this chapter(section 3.2: Use cases) we show how certain use cases affect the data in thesefields.
3.1.1 NS Reisplanner Xtra
The NS Reisplanner Xtra the location table stores all locations looked up bythe user. The location table may record the name, address, GPS coordinates,and other location identifiable information. Along with the location information,a timestamp is stored recording the time when the location was firstly used.
The NS Reisplanner Xtra application’s database also contains journey table.It contains what locations where used in what travel plan. It therefore capturesthe relation between two or more locations.
3.1.2 9292
The 9292 application also stores location information in its locations table.This table also stores all locations looked up by the user. The location tablemay record the name, address, GPS coordinates, and other location identifiableinformation.
9292 may also be used to store journeys, however, in contrast to NS Reis-planner Xtra, the user has to save its journey explicitly. This table also capturesthe relation between two or more locations.
3.2 Use cases
To investigate what information can be derived from the application (9292 andReisplanner Xtra) we composed several use cases to generate simulated userdata.
Per use case, we will give a describing of the use case, elaborate on what datais affected by the use case, and evaluate on what valuable data from a forensicspoint of view is either stored or removed. Some use cases proved affect morevaluable data than others. These use cases are covered in this chapter, the usecases that affected less valuable data can be found in Appendix B: Use cases.
5
3.2.1 NS: Plan a journey from address to station
Description
Figure 3.1: NS: addressto station
The NS Reisplanner Xtra applications offers severalways for planning a journey, one of which is plan-ning a journey from an address to a train station. Toplay a journey, a user goes to the the planner screenand selects the station from which he wishes to de-part and the address on which he wishes to arrive (orvice versa). The user may also choose a departuretime, or an arrival time. This is set by default to de-vice’s current system time as the departure time. InFigure 3.1: NS: address to station this use case is il-lustrated; the user wishes to travel from Science Park904 to Amsterdam Central.
Data altered
When this use case is performed, three rows added tothe database: two rows for locations, and one row fortravel history.
The information stored for locations consist an en-try for the train station (e.g. Amsterdam Central),and an entry for the address (e.g. Science Park 904).For both locations a timestamp is stored capturingthe time (i.e. current device’s system time) when thelocation was firstly used. When performing this usecase, at least two locations will used: a departure andan arrival location. Optionally, an intermediate station may also be used.
The journey itself is also stored and may be viewed in ‘Trip history’ by theuser. Journeys capture the relation between two (or more) locations. It con-tains the timestamp on which indicates when the journey was planned (currentdevice’s system time), and the GPS coordinates (longitude, latitude) for boththe departure and arrival location. The the types of locations is also stored, inthis case station and address.
When this use case is performed, three rows added to the database: tworows for locations, and one row for travel history. In a simular use case, we plana journey from station to station, this use case can be found in B.1.1: NS: Plana journey from station to station.
Valuable data
When this use case is performed, some valuable information will be stored. Thisencompasses location identifiable information (e.g. GPS coordinates, addresses,and station names), location relations (e.g. departure, intermediate, and arrival
6
location), and timestamps (e.g. creation time of locations, creation time ofplanned journey).
3.2.2 NS: Remove trip history
Description
Figure 3.2: NS: removeall travel history
This use case might be a continuation of the use casedescribed in B.1.1: NS: Plan a journey from stationto station and 3.2.1: NS: Plan a journey from addressto station. The NS Reisplanner Xtra application en-ables users to remove their travel history. There aretwo ways in which users can remove their travel his-tory:
1. remove travel history per entry.
2. remove all travel history;
The latter is illustrated in Figure 3.2: NS: remove alltravel history.
Data altered
Depending on how this use case is performed, one orall entries from the journey table are removed. Theentries in this table contain the relation between twoor more locations, i.e. they describe a journey byspecifying the departure locations, destination loca-tion, optionally intermediate locations.
Although the travel history is removed, the loca-tions that make up the journey are preserved. Thisbehaviour was still observed when locations had alltheir relations removed. This implies that even whenall travel history is removed, their location informa-tion resides unaffected in the database.
Valuable data
When this use case is performed, valuable information will be removed. Entriesfrom the journey table, which encompasses location relations (e.g. departurelocation, and arrival location), and timestamps (creation of planned journey)will be removed.
As aforementioned, the location information itself will remain unaffected inthe database, only the journeys are removed. As locations also contain a creationtimestamp, it may still be possible to derive journeys from this information. Iftwo timestamps of locations match, it is very likely that these where part ofthe same journey. However, information identifying which location was used forwhat purpose (e.g. departure, or arrival) is lost.
7
3.2.3 NS: Remove locations
Description
Figure 3.3: NS: removelocation
The NS Reisplanner Xtra application enables usersto remove their recently chosen locations. Recentlychosen locations are created when a user looks up alocation, for instance by planning a journey from onelocation to another (B.1.1: NS: Plan a journey fromstation to station). It is also possible to remove savedlocations (B.1.2: NS: Save location). In this use casethe user may remove both types of locations (Fig-ure 3.3: NS: remove location).
Data altered
Depending on whether a location is recently chosen,saved, or both, removing it will have different effectsfor different types of locations.
If a saved location is removed, that has not beenrecently chosen, it will be removed from the database.Vice versa, if a recently chosen location which was notsaved is removed, it will also be removed from thedatabase.
However, if the location is recently chosen andsaved, the user must remove the location for bothtypes in order to remove it from the database. Other-wise, only a boolean value indicating that the locationwas recent or saved, will be set to zero, but the loca-tion will remain in the database.
The information stored for locations may differ. If the location is a station,the name of the station is stored. If it is an address, the city, street name, housenumber, and zip code are stored. In both cases, the location’s GPS coordinatesand its creation timestamp are stored.
Valuable data
When this use case is performed, some valuable information may be removed.This encompasses location information (e.g. GPS coordinates, addresses, andstation names), and timestamps (creation time of location).
However, only the location will be removed. Any journeys associated withthe locations remain in the database. Location information may thus still bederivable from this table, as it contains the GPS coordinates and other locationinformation for these locations.
8
3.2.4 9292: Plan a journey from current location
Description
Figure 3.4: 9292: cur-rent to station
Like the NS Reisplanner Xtra application, 9292 offersseveral ways to plan a journey. Unlike NS ReisplannerXtra, 9292 can also be used to plan a journey fromthe device’s current location. It uses GPS coordinatesprovided by the GPS service of the OS. Users mayalso select a destination, this is either a station (e.g.train or bus) or an address (e.g. street or zip code).By default, the departure time is set to the currentdevice’s time. In Figure 3.4: 9292: current to stationthis use case is illustrated; the user wishes to travelfrom its current location to Beverwijk.
Data altered
When this use case is performed, two rows added tothe database: one in the locations table and one inthe usedlocations table.
The data stored in the locations table encom-passes the location’s name (id), its details, and atimestamp capturing when it was looked up most re-cently. The location’s details contain the name, theGPS coordinates, regional codes, and the type loca-tion (e.g. train station).
The information stored in the usedlocations ta-ble contains the location’s name (id), the timestampof the week in which it was looked up, and a counter keeping track of how manytimes the location was used that week.
An interesting observation is that only ”browsed” locations are stored: theuser’s current location utilising the GPS service is not stored by the application.No row containing this location are added to the table. Another observation isthat no journey history is stored. It is therefore not possible to determine exactlocation relations from the information obtained from this use case.
Valuable data
When this use case is performed, some valuable information will be stored. Thisencompasses location information (e.g. GPS coordinates, and station names),and timestamps (e.g. creation time of locations. Moreover a counter that keepstrack of how many times a location is used in a certain week is also recorded inthe database. This counter may be used to derive location look up behaviourin a weekly basis.
9
3.2.5 9292: Plan a journey from address to station
Description
Figure 3.5: 9292: ad-dress to station
Analogous to the NS Reisplanner Xtra application,users may plan a journey from two stationary loca-tions. The user selects departure and arrival loca-tions, this is either a station (e.g. train or bus) oran address (e.g. street or zip code). In Figure 3.5:9292: address to station, this is illustrated by plan-ning a journey from an address (Creutzberglaan) toa station (Amsterdam Science Park). The departuretime is set to the current time.
Data altered
When this use case is performed, four rows added tothe database: two in the locations table and two inthe usedlocations table.
As with the previous use case (subsection 3.2.4:9292: Plan a journey from current location). The in-formation stored in the locations table stores the lo-cation’s name (id), its details, and a timestamp whenit was last used (lastused). The information storedin the usedlocations table contains the location’sname (id), the timestamp of the week in which it waslast used, and also the counter keeping track of howmany times the location was used that week.
In contrast with the previous use case, an addresswas used in the journey in addition to a station. The location details of anaddress are slightly different than those of a station. An additional value holdingthe house number is stored. In both cases the GPS coordinates are stored, whichoriginates from the application’s API rather than the GPS service of the OS.
Valuable data
We observed that four rows were stored in the database, as compared to thetwo rows in the previous use case (subsection 3.2.4: 9292: Plan a journeyfrom current location). This is because we used the application to ”browse” twolocations, instead of using our current location. Since two lastused timestampsare stored per location, we can derive locations’ relations to some extent. Iftimestamps of two locations match, we may conclude that they were used in thesame journey. However it is not clear from comparing the timestamps whichlocation was used for what purpose (e.g. departure or arrival location).
In addition, the same valuable information as in subsection 3.2.4: 9292:Plan a journey from current location is stored.
10
3.2.6 9292: Save a journey
Description
Figure 3.6: 9292: savejourney
This use case is a continuation of the use case de-scribed in subsection 3.2.5: 9292: Plan a journeyfrom address to station and subsection 3.2.4: 9292:Plan a journey from current location. Users can savea journey they planned. This will enables them toquickly look up departure times and possible disrup-tions of travel plans they have saved. This informa-tion is accesible through the My 9292 menu as illus-trated in Figure 3.6: 9292: save journey.
Data altered
Since this use case is a continuation of subsec-tion 3.2.5: 9292: Plan a journey from address tostation and subsection 3.2.4: 9292: Plan a journeyfrom current location, all information stored in thoseuse cases is also stored when this use case is per-formed. In addition, an entry capturing the relationbetween two locations is stored in the journeys table.
This entry contains detailed information about thejourney. It stores the departure location, arrival lo-cation, the interchange time, and what travel modeswere enabled (e.g. bus, train, subway). The depar-ture and arrival time of the overall journey are alsostored. In addition, all intermediate stations (called”legs”) are stored as well. These records capture all locations where the trans-port stops (e.g. stations or bus stops) and on what times.
Valuable data
The additional, valuable data stored as compared to subsection 3.2.5: 9292:Plan a journey from address to station and subsection 3.2.4: 9292: Plan ajourney from current location, is the relation between two locations. When ajourney is saved, the application stores the locations that are visited during thejourney and the timestamps on which certain events occur. For instance, itstores a timestamp for the departure, and arrival in a journey.
In subsection 3.2.5: 9292: Plan a journey from address to station we wereable to derive which two locations were used in the same journey by comparingtheir lastused timestamp. However, we were unable to derive which locationwas used for which purpose: either departure, arrival, or intermediate. The in-formation stored in this use case does provide this information and may thereforebe of additional value as compared to the previous use case.
11
3.2.7 9292: Remove a journey
Description
Figure 3.7: 9292: re-move journey
In continuation of subsection 3.2.6: 9292: Save ajourney, users may remove the journeys they saved.This will result in the journey being removed fromthe database, and subsequently disappears from theMy 9292 menu.
Data altered
When the journey is removed, its corresponding en-try from the journey table in the database will beremoved. This includes all the detailed informationof a journey such as ”legs” (subsection 3.2.6: 9292:Save a journey), and the departure and arrival loca-tions.
Although the journeys are removed, the locationsthat make up those journeys are preserved. Moreover,there appears not to exist any in-app function thatenables a user to remove these locations. This meansthat users cannot remove the locations they visitedthrough the interface of the application.
Valuable data
When this use case is performed, valuable data is lost.A journey contains detailed information, this includesthe arrival and destination locations (e.g. GPS coor-dinates, addresses, station names). It captures therelation between two or more locations, and also the events that occur on theselocations at what time (subsection 3.2.6: 9292: Save a journey). This use caseremoves entries from the table capturing this data.
However, the information about the location used to plan the journey ispreserved. This location information is still visible in the interface of the appli-cation and remains present in the database. By examining timestamps of theentries in the location table, (removed) journeys may still be derived. How-ever, as aforementioned, the entries in the locations table do not capture thepurpose of that location (e.g. departure or arrival location).
12
3.3 Counter-forensics and detecting counter foren-sics
In this section, discuss how the integrity of information can be harmed (counter-forensics), how these actions can be detected, and how data can be recoveredfrom these actions. We distinct two ways of performing counter-forensics: in-app, and in Android. In in-app counter-forensics we will investigate how thefunctionality of an application can be used harm the integrity of data. In An-droid counter-forensics we investigate what functionality in the Android OS canbe used to fulfill the same purpose. We define counter-forensics as any actionthat can be done within software to harm the integrity of the data stored bythe 9292 and NS Reisplanner Xtra application.
In addition to investigating how the integrity of data can be harmed, wedescribe how counter-forensics can be detected, and how affected data can berestored.
3.3.1 In-app
The NS Reisplanner Xtra application offers functionality to remove entries fromits database and subsequently from its user interface. This includes removingjourney history (subsection 3.2.2: NS: Remove trip history) and removing loca-tions (subsection 3.2.3: NS: Remove locations).
When removing the data through the functionality offered by the application,SQLite statements are executed to remove references to the data. However, theactual data might still be available in the database. When a delete statement isexecuted on a SQLite database, the data is not removed, but rather marked as”overwritable”. Using the “SQLite Viewer” tool we are able to determine theoffset of Unallocated (”overwritable”) data blocks. In these blocks of data, wefound all ”removed” entries.
Besides the applications’ database file, android also automatically storesdatabase journal files. We found that the database journal file may contain old,unused entries. During experimentation, an entry containing a journey madein July 2015 was found1 in the journal file. This shows that journal files maycontain valuable information, even when the data is unused by the applicationor even has been marked as deleted for a considerable amount of time. The testdevice that contained the journal file has been used as the primary smartphoneby one of the researchers. However, we did not investigate for what time, underwhat usage this information remains obtainable, as an analysis on the the refreshrate of this data is out-of-scope for our research.
3.3.2 In Android
In this text, we will elaborate on how functionality in the Android OS can beused to harm the integrity of applications data.
1In March 2016
13
Removing data
Using Android’s settings application, users can manage their applications. Usersmay uninstall or clear the data of user applications. This functionality can beused to remove data and thereby harming the integrity of application data.
In our research, we uninstalled both the NS Reisplanner Xtra and 9292application. We also cleared the data stored by these applications. The firstresulted in the removal of the entire application, including its user data. Thesecond experiment resulted the removal only the user data.
In both cases we were able to obtain all previously removed data, which al-lowed us to reconstruct the entire database. We used “scalpel” for this purpose.However, as more disk space of an Android device is used, user data may be lessreconstructable. This phenomena is the result of fragmentation, and is relatedto how Android’s file system (ext4) allocates space to files: it initially reservesa considerable amount of free space between files. As data uses increases, databecomes more agglomerated, eventually resulting in fragmented data.
Time changes
Harming the integrity of data can also occur without removing the data. Inmany use cases, timestamps are stored. The timestamps record when a certainevent happened, and may be crucial in determining in which order certain eventshappened.
In our research we altered the system’s time and investigated how this wouldaffect the data stored in the databases. We found that in both applications, thestored timestamps would change accordingly, and this could thus be used as ameans of counter-forensics.
However, in none of these cases changing the timestamps would result in thedistortion of the order of recorded events. This is because order in the databasesis captured by an ID for each entry in the database. This ID is incremental.The actual order of events may thus still be derived from the IDs .
Moreover, changing the system time is recorded by Android’s logcat, whichlogs system events. The time change event includes to what time the systemtime was changed, and may optionally record at what (previous) time this eventhappened. Changing the time may thus be easily detected, and the original timemay even be recovered. However, due to the limited buffer-size of logcat, whichspans from 64K to 16M, this data may be lost over time.
Another interesting observation is that 9292 will remove used locations overtime. The application uses this as a truncation mechanism. When the time isset to some date far in the future (e.g. 1 year later), the application will auto-matically remove its location entries when the application is started. However,this information can be recovered using the methods we described in 3.3.2.
14
3.4 Questionnaire results
Using a questionnaire, we aimed to investigate how the data found on 9292and NS Reisplanner Xtra corresponds to actual travel behaviour. We asked therespondents several questions to which their answers show how often they usepublic transport, how often they use the planning applications, and how manyof the journeys or locations appearing in their applications they rememberedmaking or visiting.
3.4.1 Respondents and platforms
The questionnaire was filled in by 27 respondents, of which most are master ITstudents. Of these respondents, 11 had an iOS device, 14 had an Android deviceand 2 had a Windows Phone device. 4 respondents had no travel planningapplication installed, 14 had both the NS Reisplanner Xtra and the 9292OVapp installed, 4 only had the 9292OV app installed and 5 had only the NSapp installed. A table summarising this information can be found in Table 3.1:Apps on respondents phones. In Figure 3.8: Respondent operating system types.a graph representing this data is shown.
OS NS app 9292OV Neither Both TotalAndroid 4 2 2 6 14iOS 1 1 2 7 11Windows Phone 0 1 0 1 2Total 5 4 4 14 27
Table 3.1: Apps on respondents phones
3.4.2 Application usage
We asked our respondents how often each of the applications (if installed) wereused on a periodic bases. Figure 3.9: Frequency of the respondents using the9292OV app. shows a graph of the planning frequency of 9292 users. It showsthat most 9292 users use the application about once a week. In Figure 3.10:Frequency of the respondents using the NS Reisplanner Xtra app. a similar graphis shown for the respondent with NS Reisplanner Xtra installed. From thesecharts it becomes apparent that a majority of respondents use a travel planningapplication at least once a week.
Actual journeys
If a location or a journey is present in the database, it does not necessarilymean that the user has actually visited the location or made that journey. Thequestionnaire contained questions to determine how data from the respondents’applications corresponds to their travel behaviour.
15
Figure 3.8: Respondent operating system types.
Figure 3.9: Frequency of the respondents using the 9292OV app.
The results are shown for both applications separately in Table 3.2: Numberof planned trips/visits and actual trips/visits. We can observe that the majorityof journeys planned by our respondents were also made.
However, due to the relatively small sample, and the lack diversity of respon-dents (mostly master IT students), we rationalise that the results are inadequateto generalize to the general Dutch public transport users. This will be discussedin more detail in chapter 4: Discussion.
16
Figure 3.10: Frequency of the respondents using the NS Reisplanner Xtra app.
iOS Android Windows Phone Total9292 Planned 25 55 11 91NS Planned 373 82 5 4609292 Visited 23 52 11 86NS Visited 335 60 5 400
Table 3.2: Number of planned trips/visits and actual trips/visits
17
CHAPTER4
DiscussionIn this chapter we will discuss our findings and elaborate on how they should beinterpreted. We describe the limitations of detecting, and recovering removeddata using our methods, and we discuss the results of our questionnaire.
4.1 Counter Forensics
During our research, we found that using in-app and Android’s system func-tionality to remove data, the data was never wiped entirely. Instead, data ismarked ”unallocated” and only references to this data are removed. We foundthat using tools like ‘Scalpel’, removed data may still be retrieved, although thedatabase may be fragmented. Due to the way ext4 stores files, higher fragmen-tation may occur as used space increases. Forensics as described in this reportmay there be less convenient on devices with few free space.
4.2 Unallocated space data retention
We found that data may still remain in the database after deletion (section 3.3:Counter-forensics and detecting counter forensics). This data is not removed,but rather marked as Unallocated Space in SQLite database files. Utilising a hexdumper, we were able to retrieve this information from the database. However,when a page or section inside the database file is marked as unallocated, newwrite operations on that table may overwrite the unallocated section. Thesesections are therefore volatile and not all previously removed information maypersist. During experimentation we found no indication of how long the datacan persist. We did however, found several entries of approximately 8 monthsold. This may indicate that the data is not overwritten promptly. Additionalresearch should conclude the rates in which this data is overwritten.
4.3 Questionnaire
The questionnaire was spread among a small group of people, of whom 27 re-sponded to our questions. The respondents from this population all have hada technical education or are currently enrolled in one. It is likely the result ofthe questionnaire is not representable for the general Dutch public using thesetransportation applications. Therefore, we argue that this data should not beextrapolated to those users.
18
CHAPTER5
ConclusionNS Reisplanner Xtra and 9292 both store location information. Depending onthe application, and what type of location (e.g. station or address), differentinformation may be stored in the applications’ databases. In both applications,in all cases where locations are stored, GPS coordinates are stored along withthe location. This allows for highly accurate location identification.
Both applications store timestamps, recording when certain events hap-pened. For instance, a timestamp is stored each time a journey was planned.NS stores the relation between two locations whenever a journey was lookedup. Among others, it records the arrival and destination locations of a journey.In 9292, journeys (location relations) are not stored implicitly when a journeyis planned. However from examining the lastused timestamp, we can derivewhat locations where used in a journey.
The NS Reisplanner Xtra application enables users to delete locations andjourneys they looked up. This will remove the entry from the database. How-ever, SQLite does not wipe data, but rather marks it as unallocated data. In-formation may therefore still be retrieved from the database. Moreover, func-tionality in the Android OS such as clear data and uninstall may be usedto remove application data from Android’s file system. When data is deleted,only references to the data are removed and the data is marked as unallocated.Counter-forensics performed using these methods two may thus be detected,and removed data may even be recovered. We successfully recovered all re-moved data during this research.
In accordance to our results, we rationalise that the investigated public trans-port applications may be valuable in a forensic investigation. Our results showthat not all data from the application corresponds to actual travel behaviour.This information should therefore not be interpreted as such. However, as de-tailed location information and relations between locations can be derived fromthe applications, we believe information from these applications may serve asleads in a forensic research.
19
CHAPTER6
Future workIn this chapter, we will suggest future research that is comparable or comple-mentary to this research.
6.1 SQLite forensics
To inspect the unallocated spaces in SQLite database we used the commercial“Sqlite Forensics Explorer” tool. We used it since no open-source tools whereavailable serving the same purpose. We believe that verifiable source code con-tributes to the integrity of forensic research. An open-source tool like this mightbe developed as future work.
6.2 Data correlation
We aimed to correlate data from public transport applications to actual travelbehaviour. We received 27 responses on our questionnaire, most of which camefrom master IT students. We believe that our results should not be extrapolatedto the general Dutch public. Future research may be done on a larger, morediverse population to identify how this data correlates in such populations.
6.3 Volatile memory
In the 9292 application users can plan journeys from their current location.Although, this location was not stored in the database, it may reside in theapplications’ memory. We did not investigate the applications’ memory duringthis research. Future research may reveal what information can be retrievedfrom volatile memory.
6.4 Other platforms
There are numerous public transportation applications available for Android.We investigated two: 9292, and NS Reisplanner Xtra. Other public transportapplications, such as Google Maps, may also be investigated. These applicationscan yield other interesting (forensic) data about the user. Moreover, applicationsfor different platforms (e.g. iOS) may store different information, we thereforealso consider this as future research.
20
Bibliography[1] ANP. NS haalt gele borden met vertrektijden weg van stations. Dec. 4, 2013.
url: http://www.nu.nl/binnenland/3645099/ns-haalt-gele-borden-met-vertrektijden-weg-van-stations.html (visited on 03/15/2016).
[2] Olof van Joolen. Politie gluurt in ov-chip. Dec. 27, 2013. url: http://www.telegraaf.nl/binnenland/22169048/__Politie_gluurt_in_ov-
chip__.html (visited on 03/15/2016).
[3] Aditya Mahajan, MS Dahiya, and HP Sanghvi. “Forensic analysis of instantmessenger applications on android devices”. In: arXiv preprint arXiv:1304.4915(2013).
[4] Stefan Maus, Hans Hofken, and Marko Schuba. “Forensic analysis of geo-data in android smartphones”. In: International Conference on Cybercrime,Security and Digital Forensics, http://www.schuba.fh-aachen.de/papers/11-cyberforensics. pdf. 2011.
[5] Nederlandse Spoorwegen. NS Reisplanner Xtra - Android Apps on GooglePlay. url: https://play.google.com/store/apps/details?id=nl.ns.android.activity&hl=en (visited on 03/01/2016).
[6] 9292. 9292 - Android Apps on Google Play. url: https://play.google.com/store/apps/details?id=nl.negentwee&hl=en (visited on 03/01/2016).
21
APPENDIXA
Test environmentIn this chapter, more detailed information on the test environment is listed.
A.1 Phones and Emulator
• Moto E (XT1021)
– Kernel: 3.4.42-g66226a1-00001-g70ad15f
– System version: 23.26.8condor reteu.retuall.en.EU reteu
– Build-number: LPC23.13-34.8
– Android version: 5.1
– Build fingerprint: motorola/condor reteu/condor umts:5.1/LPC23.13-34.8/9:user/release-keys
• Oneplus One (bacon A0001)
– Kernel: 3.4.67-cyanogenmod-gf34ed89
– CyanogenOS Version: 12.0-YNG1TAS2I3
– Build-number: LRX22G
– Android version: 5.0.2
– Build fingerprint: oneplus/bacon/A0001:5.0.2/LRX22G/YNG1TAS2I3:user/release-keys
• Emulator
– Kernel: Linux 3.4.67-g2011b1c
– Build-number: sdk phone armv7-eng 6.0 MRA44C 2166767 test-keys
– Android version: 6.0
– Build fingerprint: generic/sdk phone armv7/generic:6.0/MRA44C/2166767:eng/test-keys
A.2 Apps
• Reisplanner Xtra [5]
– Version: 4.2.4
22
– Downloads: 1,000,000 - 5,000,000
– Release date: February 23, 2016
• 9292 [6]
– Version: 1.4.6
– Downloads: 1,000,000 - 5,000,000
– Release date: December 18, 2015
A.3 Tools and software
• ADB
– From Android platform-tools 23.1
• Android emulator
– From Android SDK tools 24.4.1
• SQLdiff
– From sqlite-tools 3.11.1
• SQLite3
– Version: 3.8.7.4
• SQLiteBrowser
– Version: 3.2.0
– Qt Version: 5.3.0
– SQLite Version: 3.8.5
• Hexdump
– From bsdmainutils, Version 9.0.6ubuntu1
23
APPENDIXB
Use cases
B.1 NS
B.1.1 NS: Plan a journey from station to station
Description
Figure B.1: NS: stationto station
The NS Reisplanner Xtra applications offers severalways for planning a journey, one of which is planninga journey from one train station to another. To play ajourney, the user goes to the the planner screen andselects the station from which he wishes to depart andthe station on which he wishes to arrive. The usermay also choose a departure time, or an arrival time.This is set by default to device’s current system timeas the departure time. In Figure B.1: NS: station tostation this use case is illustrated; here the user wishesto travel from Amsterdam Amstel to Maastricht.
Data altered
When this use case is performed, three rows added tothe database: two rows for locations, and one row fortravel history.
The information stored for locations consist of thename of the train station (e.g. Amsterdam Amstel),and a timestamp capturing the time when the locationwas firstly used (current device’s system time). Whenperforming this use case, at least two locations willused: a departure and an arrival location. Optionally,an intermediate station may also be used.
The journey is also stored and may be viewed in‘Trip history’ by the user. Journeys capture the rela-tion between two (or more) locations. It contains thetimestamp on which the journey was planned (cur-rent device’s system time), and the GPS coordinates (longitude, latitude) forthe departure and arrival location. The means by which the journey is planned,in this case station, is also stored.
24
Valuable data
When this use case is performed, some valuable information will be stored. Thisencompasses location information (e.g. GPS coordinates, and station names),location relations (e.g. departure, intermediate, and arrival location), and times-tamps (e.g. creation time of locations, creation time of planned journey).
B.1.2 NS: Save location
Description
Figure B.2: NS: save lo-cation
This use case can be used to store locations. To storea location, the user looks up the locations he wantsto store. Subsequently a pinpoint on the map willbe shown, a screen similar to Figure B.2: NS: savelocation will be presented to the user.
When the user presses Save location, the loca-tion will be stored. Whenever a user wants to plan anew journey, the saved location will be shown in My
locations.
Data altered
The information stored in the database may vary, de-pending on what kind of location is stored by theuser (i.e. station, or address). In case of a station,the name of the station is stored. When an address isstored, the city, street name, house number, zip code,and GPS coordinates are stored. In both cases thetimestamp of the device’s current time is also stored.
Also, a boolean value indicating that this locationwas explicitly saved by the user is set.
Valuable data
When this use case is performed, some valuable in-formation will be stored. This encompasses locationinformation (e.g. GPS coordinates, addresses, andstation names), and timestamps (creation time of locations).
25
B.1.3 NS: Save a journey to ’Mijn reizen’
Description
Figure B.3: NS: savejourney
This use case may be a continuation of B.1.1: NS:Plan a journey from station to station, or anotheruse case where a journey is planned. When the userplans a journey, the NS Reis planner Xtra app allowshim to save the journey. This way, the user may re-ceive notifications on certain events (e.g. in case ofdisruptions).
Data altered
Before a user can save a journey, it must first beplanned. Therefore, location and journey history in-formation will be stored similar to that in use caseB.1.1: NS: Plan a journey from station to station.
Furthermore, more detailed information about thejourney is stored in the mijnreizen table. This in-cludes information about travel time, intermediatestations, and pricing information. It also stores thetimestamp on which the journey was saved. Infor-mation on what events the user should be notified isstored in the seintjes table.
Valuable data
No additional, valuable data will be stored when per-forming this use case. The location information andtimestamps that might be valuable, are the result ofa prior use cases that needs to be performed prior to this use cases (B.1.1:NS: Plan a journey from station to station). The additional, more detailedinformation that is stored in this use case, is public information.
26
B.1.4 NS: Log in
Description
Figure B.4: NS: log in
Users with a Mijn NS account can log in on theNS Reisplanner Xtra application with this account.When the user has multiple OV-cards connected tohis account, he will be prompted to a selection menuwhere he can choose which card should be used bythe application.
Per OV-card, the balance on that card can be re-quested and the most recent check-ins and check-outswith this card will be shown. This is illustrated inFigure B.4: NS: log in
Data altered
Although the interfaces shows interesting informationsuch as the most recent check-ins and check-outs, thisinformation is not stored in the database; it is merelyfetched from the server and shown in the interface.
However, some information is stored in thedatabase. This information is related to the Mijn
NS account of the user. For instance, the username(an e-mail address) is stored in the database. Also,meta data about what card is currently selected isalso stored by the application.
Valuable data
Except for an e-mail address, no valuable information is stored when this usercase is performed.
27
B.1.5 9292: Plan a journey from station to station
Description
Figure B.5: 9292: sta-tion to station
This use case is analogous to subsection 3.2.4: 9292:Plan a journey from current location and subsec-tion 3.2.5: 9292: Plan a journey from address tostation. In both these use cases, a user plans a journeyusing an arrival and destination location. In this spe-cific use case, the user plans to travel from one stationto another. This is illustrated in Figure B.5: 9292:station to station where Amsterdam Science Park isthe departure location, and Beverwijk is the arrivallocation.
Data altered
When this use case is performed, four rows added tothe database: two in the locations table and two inthe usedlocations table.
The information stored in the locations tablestores the location’s name (id), its details, and atimestamp when it was last used (lastused). The loca-tion’s details contain the name, the GPS coordinates,regional codes, and what kind of location it is (e.g.train station). There are two of these rows added tothe database, since a departure and arrival locationis selected.
The information stored in the usedlocations ta-ble contains the location’s name (id), the timestamp of the week in which it waslast used, and a counter keeping track of how many times the location was usedthat week. There are two of these rows added to the database, since a departureand arrival location is selected.
Valuable data
When this use case is performed, some valuable information will be stored. Thisencompasses location information (e.g. GPS coordinates, and station names),and timestamps (e.g. creation time of locations. Another interesting piece ofinformation that is stored, is the counter that keeps track of how many timesa location is used in a certain week. This counter may be used to derive travelbehaviour in a weekly basis.
28
B.1.6 9292: Save a location
Description
Figure B.6: 9292: savelocation
Newly or previous looked up locations can be saved.Saving the location enables the users to quickly reusethese locations when planning another journey. It alsoprevent the location from being removed over time(section 3.3: Counter-forensics and detecting counterforensics). When a location is saved, it will appearin the user’s interface in the Departures menu underMy locations as shown in Figure B.6: 9292: savelocation, here the location Science Park Terra is saved.
Data altered
If a newly looked up location is saved, the informa-tion being stored is analogous to subsection 3.2.5:9292: Plan a journey from address to station andsubsection 3.2.4: 9292: Plan a journey from cur-rent location. Next to this information, a specialboolean value is set. The value (isfavorite) indi-cates whether a locaiton has been marked as ”saved”or not.
Valuable data
No additional, valuable location information is storedwhen a location is saved a compared to when it is notsaved. In both cases the same location identifiableinformation is stored. However, the difference is thatin this case a special boolean value (isfavorite) is set. This may indicate thatthe user frequently uses this location in his journeys or to look up departureand arrival times of public transport on those location.
29
B.1.7 9292: Remove a location
Description
Figure B.7: 9292: re-move location
This use case is complementary to subsection B.1.6:9292: Save a location. Saved locations can be ”re-moved” through the user interface of 9292. When auser removes the location a message box indicatingthat the that the location was ”deleted” will appear.
However, the location is not removed from theuser interface as well as from the database. Althoughit will not show up in the Departures menu as de-scribed in subsection B.1.6: 9292: Save a location, itwill remain in the list of used locations when plan-ning a journey. The entire location record in thelocations table will subsist. The difference beingthat the isfavorite flag is unset.
Data altered
When this use case is performed, the record of the lo-cation will be updated. If the location was previouslysaved, a isfavorite flag was set. By executing thisuse case, the isfavorite flag is unset.
Valuable data
No valuable location data is removed when this usecase is performed. A minor change will affect the rowcorresponding to the location in the database: theisfavorite flag will be unset.
30
