In my last article on iPhoneTracking, I tried to explain Apple’s crowd-sourced location based service. Obviously Android has to do something similar to provide a good user experience using location based services…
Also back in April 2011 some people, who wrote stuff about iPhoneTracking, also mentioned Android with a sentence or two without going to much into detail. So, what I would like to provide with this article is a more detailed discussion especially suitable for mobile forensic investigators.
Why doing caching at all
As I am an iPhone user from the very beginning in 2007, when I first held a freshly installed Samsung Galaxy i5800 in my hands, I was quite disappointed by the user experience of Google Maps! But to be successful and in order to compete with iOS, Android is in desperate need for stuff like indoor and most of quick localization. From what I know, Android offers quite the same features as iOS, but each device manufacturer has the possibility to brand his own stuff, even with different settings and last but not least Android seems to be more restrictive concerning privacy settings.
But one step after another…
– First tests / First hands on –
Sample Files (foreign data)
Because of the lack for a test device, my first sample files were kindly provided by a German security researcher from the FH Brandenburg. From what he told me, the data was collected over a total time of 2 weeks. So, once again, I was quite disappointed, that only 1 valuable cell location and 6 valuable wi-fi locations were reported (see below):
My first impression was, that it seems to be quite the same scenario like in iOS (multiple entries to a single timestamp) but with much less data cached. I have had a little conversation to get a better idea of how to interpret the recorded(?) data, but the most obvious problem was: the data were not mine.
Test Device (my own data)
Then, on my first day back in office in 2012 I was in luck getting a test device from my chief. It was a Samsung Galaxy i5800, that was not supported by any forensic investigation software we use.
So, to be honest: My first experiments were not forensic sound at all:
- I installed a file browser (no files in /data/*)
- I tried to “root” the device (no success)
- I flashed the device to a newer firmware (Android 2.3)
- I finally got the device “rooted”
- I installed another file browser (yeah: files in /data/*)
But, there were no cache.cell, cache.wifi files anywhere on the device. Why not?
In “Location & Security” the option “GPS” was activated. But in order to enable caching it is also necessary to enable “Use wireless networks”!
Finally, I got the desired two files… Jippie!
The files are very small (under 5kb), so: I simply synced them with Dropbox in order to keep different versions for different investigations I wanted to carry out after different location-based operations like taking photos, navigating or using google maps.
– Some basics explained –
How does Google-Crowd-Mapping work
I found a thread in a google product forum describing the process like this:
If your location is being incorrectly detected by a Google Maps or Latitude using Google’s cell ID (cell tower) or WiFi (wireless network) location database, you can help provide updated info to correct Google’s database using Google Maps for mobile. At this time, you cannot provide individual updates to Google’s location databases, though they are being updated and improved constantly over time.
Open Google Maps on an Android 2.0+, Windows Mobile, or Symbian S60 phone and enable GPS. While Maps is simultaneously connected to a GPS satellite and a cell tower or WiFi router, you will be providing updated anonymous geographic data for the cell tower or WiFi router to which you’re connected. Please note that this data is anonymous and may require a significant amount of data from you and other users before changes are made to Google’s location database.
Android: You must enable Settings > Location & security > Use wireless networks and have previously given consent for anonymous location data collection. You can check if you’ve given consent by un-checking and re-checking the ‘Use wireless networks’ setting.
Also, the user experience is much better, when “Us(ing) wireless networks”. The time to retrieve the user-location is reduced substantially.
Decoding the byte stream
The cache-files are organized in so called java byte streams. As you can see below, within the byte stream “Input”, you can identify some UTF-Strings with additional non-printable characters.
To get a better idea of what data is stored in these files, I implemented “ByteStreamAnalyzer”. The idea behind that piece of software is to easily analyze the “Input” data with additional help features like bold-style-formatting the most obvious data type (1) with converting the retrieved value, for example into an UNIX-timestamp (2). Then clicking on the data-type (3) in the “Data” window moves the cursor further in the “Input” frame as well as adding the pattern to the “ParsingPattern” window.
By now, the software is not really forensic sound, cause all text areas are editable. But it helps to get a better idea, of what is stored inside the cache-files. From what is my experience when examining different Android 2.3 files, the structure is as you can see below (and there is no additional data inside):
Structure of the byte stream
As mentioned by Magnus Eriksson (I think, he was the first one) in his python script at github, the structure is like this:
Heading Information (4 bytes sequence)
- 2 bytes: Unsigned Short (version)
- 2 bytes: Unsigned Short (Entry Count)
Location Entry(ies) (loop sequence)
- x bytes: UTF-String (Cell-Information or MAC-adress)
- 4 bytes: Integer (transmission range)
- 4 bytes: Integer (confidence)
- 8 bytes: Double (latitude)
- 8 bytes: Double (longitude)
- 8 bytes: Long (UNIX-timestamp)
What are the refresh rates / the limits?
Magnus Eriksson also presented some older Android source code fragments, that stated the limits:
// Maximum time (in millis) that a record is valid for, before it needs // to be refreshed from the server. private static final long MAX_CELL_REFRESH_RECORD_AGE = 12 * 60 * 60 * 1000; // 12 hours private static final long MAX_WIFI_REFRESH_RECORD_AGE = 48 * 60 * 60 * 1000; // 48 hours // Cache sizes private static final int MAX_CELL_RECORDS = 50; private static final int MAX_WIFI_RECORDS = 200;
My experiences from Android 2.3:
- the data get refreshed as the location changes significantly and location based apps are used
- stored for a maximum of 14 days or when the cache is filled up (cell: 50, wi-fi: 200)
– Forensic Investigations –
In order to get everything out of the Android location-cache-files, you need to inspect two files:
The files can be found on the device within the folder “/data/data/com.google.android.location/files/”
With AndroidTrackerLE, you can load two files at the same time. After loading both files, it is possible to perform different tasks like:
- select Cell Towers as Input
- select WiFi Access Points as Input
- enable position estimation(*)
- enable transmission range visualization(*)
- choose multiple timestamps to render either cell towers or wi-fi antennas on the map
- retrieve more information on a specific location item by clicking on it
- and last but not least create a forensic report.
(*) free registration is required in order to get these features, see below for further information.
Position estimation (cell towers)
In my tests, I never saw a more than 1 cell tower at a specific timestamp, so position estimation is unnecessary for cell towers.
Position estimation (wi-fi hotspots)
For estimating the best/nearest wi-fi access point, it seems to be that the MAC address from the nearest hotspot is send to google and google sends back up to 10 MAC-adress/geolocation items that are saved all with the same timestamp. From my experience, I can tell, that the first entry is the actually connected or at least nearest wi-fi hotspot.
As you can see from the above picture, cell- and wi-fi location entries are
- often combined (cell/wi-fi) at a specific timestamp (5) and
- the combined wi-fi hotspot lies inside the cell tower transmission range area with the
- device normally located inside the wi-fi transmission range area.
These information seem to be very accurate in contrast to my experience with location estimations retrieved from Apple’s databases.
Sometimes, there are inconsistent combinations reported, where the wi-fi location is not reported within the transmission area. In these cases, from what was my experience, the actual location is neither within the cell- nor the wi-fi transmission range as can be seen below. The actual position was, where the yellow star is painted.
When there are singular timestamps reported, the position has to be validated from other sources, although all timestamps I examined where accurate.
– Conclusion –
Comparison between Android and iOS
The most obvious difference between location cache data from Android to iOS is the file structure:
- Android uses a binary byte-stream
- iOS uses a SQLite File
Another major difference is the file size:
- Android from ~2kb to ~10kb
- iOS from ~30kb to ~12mb
From what is my experience, the data is very limited, but therefore very accurate. The transmission areas are much more concentrated than on iOS.
On Android devices any kind of harvesting data is non existent . More likely it seems, that harvested data is send to google right away, when using wireless networks in addition to GPS.
I can not really confirm that an entry has to be updated after a certain time.
In the meantime I finished AndroidTrackerLE v. 1.1. I will provide AndroidTrackerLE FREE for LawEnforcement agencies through a download from a restricted website. You may contact me by mail: firstname.lastname@example.org or leave a comment.
Thanks for reading this far and feel free to shoot my an email or leave a comment!