Mock Locations

 In previous posts I have looked into manipulating the SQLite database files for applications in order to provide manually selected coordinates. Doing so could impact a forensic investigation as suspects could mislead the investigators with false coordinates and claim that they were nowhere near the crime scene.

Providing false coordinates is an inconvenient process and would require a rooted phone as well as the skills and knowledge to pull, edit, and then push the database back to the phone. There are far simpler methods available in the Google Play Market that will work on any device, rooted and not.

Mock Locations

Mock Locations setting

The Android operating system includes an option to allow 'Mock Locations'. This option exists to allow developers to test their GPS enabled apps from within the Android SDK Emulator which does not have GPS. The option can be found within the Developer options; depending on the version of Android this may be hidden by default. To enable it go to Settings -> About Phone and tap on 'Build Number' seven times.

I was unable to follow the steps located at the bottom of this page to set the location on an actual device. Multiple applications in the Google Play Market that can set fake GPS coordinates require that this setting be enable in order to function unless the application is moved into the '/system/app' directory (which requires root).

I tested 'Fake GPS location' by Lexa as it was the first result that comes up when searching for 'fake gps'. This application is very simple to use and will prompt the user to enable Mock Locations if it is not already on.

Lexa's Fake GPS location

Fake GPS location's notification

To set the GPS location simply pan and zoom the map until the red bubble is pointing to the desired location  and click 'Set location'. The application will then hide and display a notification to remind the user that it is currently on.

I tested the applications that I have looked at in previous blog posts and  they all believed that the phone was where I had set the location. I also looked at the various SQLite entries and could not see anything to indicate that the application knew that the GPS coordinates were false. I was expecting the 'is non authoritative' field within the messages table of Facebook Messenger's threads_db2 to be different for these messages but they were not.

As the picture on the below shows, Lexa's Fake GPS location stores the previous locations that have been set. Knowing this I set out to find the specific database on the device.

Location history

I found the database within /data/data/com.lexa.fakegps/databases. There was only a single SQLite database file called 'fakegps'. This database contains the history for set locations as well as any that have been favorited.

Both the history and favorites tables contain the same fields:

1. _id
2. name
3. lat
4. long
5. zoom

Entry from the history table

One field that is not stored in this database are timestamps of when the location was set. It may be possible to determine this by checking the last modified time of the database file, but as I extracting the database file using adb pull I was unable to verify this.

Detecting Mock Location Applications

Determining if Currently Installed

As the presence of these types of applications on the device can call into doubt any of the coordinate artifacts outlined in my previous posts, knowing if one of these applications is installed is crucial.

To see if the application is currently installed search for the .apk file signature which is:  

50 4B 03 04 14 00 08 00

08 00
You can also manually check for the .apk which should be in either /data/apps or /system/apps.

Localappstate.db found in com.android.vening/databases also lists every application installed on the device.

Determining if Previously Installed

It is also important to determine if one of these applications was previously installed on the device as it could have been uninstalled before the phone was acquired. The Play Market database files contain information on the applications that have been linked to the Google account and those that have been installed on the device. Found in com.android.vending/databases are three SQLite databases:

1. library.db
2. localappstate.db



Removing an application

3. suggestions.db

Library.db contains every application that has ever been installed via the Google Play Market. This includes applications that have been deleted from the account. I tested this by deleting an application from my account by clicking the button highlighted on the right. After checking the database the application was still listed. I then reset the phone using the 'Factory data reset' option that is built into Android. I then added the same Google account and extracted the database. The application was still listed.

Suggestions.db will list every term searched in the Google Play Market including the time that it was entered. This can be used to see if the suspect was searching for applications to fake the gps coordinates, or even other applications to aid in anti-forensics.

Google Maps

The fourth application I have looked at is Google Maps (version 6.14.3). I decided to include it due to its default inclusion with the majority of Android based devices. It also has the potential to include a wealth of relevant location data due to the applications nature.

The location settings for Google Maps (seen on the right) include multiple options for background location reporting and sharing via Google Latitude.

Google Maps stores data on the device in two main locations:

1. /data/data/com.google.android.apps.maps
2. sdcard/Android/data/com.google.apps.maps

The majority of the relevant information can be found in the first directory. This directory has six subdirectories:

1. files
2. databases
3. shared_prefs
4. app_da_speech
5. app_sslcache
6. cache

As the databases folder for other applications has contained almost all of the data that I have been looking for, I decided to start there. This folder contained eleven SQLite 3 databases:

1. da_destination_history
2. google_analytics.db
3. google_latitude_activityDetections.db
4. google_latitude_history.db
5. google_latitude_latitudeLocations.db
6. LayerInfo
7. search_history.db
8. userfeedback.db
9. webview.db
10. webviewCookiersChromium.db
11. webviewCookiesChromiumPrivate.db

search_history.db

search_history.db

The search_history.db contains the tables and fields shown on the left which relate to searches conducted from within the application. 

suggestions table

The suggestions table contains the latitude/longitude and timestamp for each search term. If a search term has multiple results the latitude and longitude will both be set to '200000000'. Otherwise, the coordinates of the result will be in the table as can be seen below.

da_destination_history

The da_destination_history database contains an entry for each time Google Navigation is used. Google Navigation is the turn-by-tub direction component of Google Maps. Each entry contains the destination latitude and longitude as well as the source coordinates. If the destination has a title, such as the name of a restaurant, it will also be stored. Also present in this database are the street addresses, a destination token, and the timestamp of the directions. 

da_destination_history

DATA_LAYER_X

Within /data/data/com.google.android.apps.maps/files are a series of files called DATA_LAYER_X. Each file is named with a different number and contains about each layer within Google Maps. Layers can contain information such as searches for businesses or directions to an address. Only a low percentage of these files are human readable, but in the case of direction layers every direction can be read. At the very end of the file is a URL to a Google Street View thumbnail (example). 

Data_Layer

google_latitude_latitudeLocations.db

Latitude is the component of Google Maps which broadcasts the current location of your device to friends. This allows friends to instantly see where you are. The google_latitude_latitudeLocations database keeps a list of each set of coordinates and the time that they were sent. 

Unfortunately for our purposes each set of latitude/longitude coordinates are encrypted. However, the rest of the table is in plain text and could be used to gain a very rough idea of where the user was or was not. By looking at the batteryCharging Stationary fields you could get an idea if a user was at home and sleep, as most people charge their phones at night, or they could have just left their phone at home. The speed field could potentially be used to verify if a person was driving home from work as they claimed to be. 

google_latitude_latitudeLocations.db

Twitter Location Artifacts (part 2)

This is part two of my look into Twitter Location Artifacts. Part 1 can be found here.

Place Bounding Revisited

In Part 1 I discussed Twitter for Android's place bounding coordinates and how they are used to determine the Place name and Place ID. I was partially incorrect as more testing showed that the place bounding's for different Place IDs can overlap, as shown by the shaded red area in the image below.

Place Bounding Coordinates for Colchester and Burlington, VT

I believe what actually happens is that the Place ID and Place name are determined using the latitude and longitude of the tweet and then that ID's bounding coordinates are found. I tested this by tweeting from a few different locations: one from the edge of Burlington and one from within Colchester. Both of these tweets were sent from within the Burlington place bounding coordinates.

As the above image shows two different tweets sent from different coordinates within Burlington, VT had the same bounding coordinates and Place ID. The tweet sent from within Colchester, VT had a different place bounding and ID.

I am not exactly sure what the bounding coordinates are actually used for and was unable to turn anything up via research.

Deleted Messages

I tested what happens when a tweet is deleted by deleting one using the Android Twitter client and another from Twitter.com. 

When the tweet was deleted from the Android client it immediately disappeared from the apps timeline and was also removed from the Twitter.com.

Deleting the other tweet from Twitter.com immediately removed it from the website, however it still showed up in the Android client. 

Upon looking at the <userid>.db the first thing that jumped out to me was that both tweets were displayed normally in the statues table. I found this interesting as the tweet which was deleted from the phone and no longer displayed in the Android client was still listed in the database. I did not see anything in this table to determine if a tweet had been deleted or not. 

Deleted Message shown in the statuses table

Looking in the status_groups table I noticed that the status id from the tweet deleted from the Android client was not listed at all, however the tweet that was deleted from the web was listed. Each status id had two entries, one with a type of 0 and another with a type of 1. I was unable to determine that the tweet had been deleted from Twitter.com, however as the client still shows the tweet normally I do not believe that knows it has been deleted.

Message deleted from twitter.com shown in the status_groups table

Manipulating <userid.db>

Notification that Tweet was saved to drafts

I attempted to edit database entries to set false GPS coordinates like I was able to do with Facebook Messenger but was unsuccessful. By setting the phone to Airplane Mode I was able to force a Tweet to fail and be saved to drafts.

The draft showed up in the statues table of the <userid>.db database and the only indication that it was a draft was the significantly shorted status id which can be seen below.

I manually edited the latitude and longitude fields for the tweet and pushed the database back to the phone using adb (refer to the  Facebook Messenger post for more info).

Entry for Draft tweet in the statuses table

Sending Drafts

Once the updated database had been pushed to the phone I went to send the draft. This can be done by hitting the 'Me' table in the Twitter application and then scrolling down to 'Drafts".

After sending the draft I checked to see if the manually added coordinates had been added; they had not. The app will find the current coordinates and use those instead.

Upon looking at the database after sending the draft I noticed that the original entry for the draft is still there. When the client sent the draft it just took the content from the draft and sent it as a new entry.

statues table after sending drafts

Evernote

The third application that I have looked into is Evernote (current version 4.5.6.2). This is a popular service to store and sync notes across multiple devices and platforms. It is as of 3/19/13 the 197th most popular free application on the Android Play Store.

Location Settings

Application Behavior

Evernote includes an option to enable the current location to be included with each new note. The option can be found in Settings -> Other Options and can be seen to the right. Once enabled, GPS is turned on as soon as the user hits new note. The current location is automatically inserted into each new note, and there is no way to choose which notes include location short of enabling and disabling the setting for each note.

Unlike the previous applications that I have looked at, the majority of Evernote's data on the local device is stored on the SD Card (/sdcard/Evernote). This means that root access would not be required.

Within /sdcard/Evernote is a folder called 'user-<xxxxxxxx>'. This directory contains three folders and a SQLite database which can be seen below.

Contents of /sdcard/Evernote/user-<xxxxxxxx>

SQLite Database 

 .External-1363467132967-Evernote.db contains a variety of tables which can be viewed below.

.external-136467132967

Location Data 

The majority of the data is stored within the notes table. The notes table contains large amount of information for each individual note, however the contents of the note are not stored here, only a hash. The relevant fields for our purpose are: City, State, Country, Latitude, and Longitude.

Notes table

The two screenshots below show the relevant data for an individual note, in this case the 'Getting Started' note which is created automatically when the application is first installed. Each note belongs to a notebook which has an identifier called a 'notebook quid'. Each individual note has an identifier known as a 'quid'.

An interesting thing to notice with this particular note is that even though it was created automatically when the application was first launched, it still contained location data. This could be used to show you the specific location the device was when Evernote was installed.

Note Contents

As the contents of notes are not stored in the SQLite database, it requires slightly more effort to read. Within /sdcard/Evernote/user-<xxxxxxxx>/notes are folders for each individual note. These folders are named with the first three characters of the notes quid. Inside each folder is another directory named with the full quid of the note. 

Within this directory is a file called content.enml. ENML stands for Evernote Markup Language and is a superset of XHTML. I am unsure what the best method is to view these files, however the text can be viewed by opening the .enml in a web browser, however formatting and attachments did not display correctly for me. 

Some notes also contained an .html file however I was unable to determine why it existed for some notes and not others. 

Evernote also allows for photos to be taken and added to a note. The images are stored within the note folder along with the content.enml file. The md5 hash of the image is used as the name but for some reason the extension is '.dat'. When viewed with WinHex, as shown below, the header shows that it is actually a jpeg file. 

Add caption

Deleted Notes

When notes are deleted they are removed from both the website and the phone no matter which they were deleted from. This is consistent with Evernote syncing everything between devices. However, notes deleted from both the mobile application and the website are kept in the SQLite database. The time that the note was deleted is placed into the deleted column in unix time. 

Manual Location

Evernote contains the ability to manually set the location for a note. To do so, tap the overflow menu button (the three squares) and select 'Set location'. This will bring up a map which allows you to pan around and zoom in and out until the desired location is found. 

I have had difficulty determining if the location was found through GPS or manually set. I believe that when the location is manually set, the altitude field is set to 0.0. When location is set via GPS/mobile network the altitude is filled in as appropriate  I did have two instances of the altitude being set for notes whose location was set manually, but I have been unable to reproduce this and so am not sure what caused this.

It is possible to detect that the feature was used by looking at the Google Analytics database for Evernote. This database can be found in /data/data/com.evernote/databases/google_analytics.db. As this is located within /data, root access is required. 

Set location option

Google Analytics for Android allows application developers to gain anonymous real world data about how their application is used. As the picture below shows, we can use this feature to see that the 'Set location' feature was used, and the associated timestamp. The only issue with this method is I do not believe entries are kept in this database for any significant amount of time. I noticed that entries had been removed within hours. 

Setting Location

Analytics for Set Location being used

That's what I have found for Evernote so far. Feel free to leave any comments, suggestions, or questions and stay turned for future posts!