Android Tracking – from a forensic point of view

– Introduction –

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):

Get The Latest DFIR News

Join the Forensic Focus newsletter for the best DFIR articles in your inbox every month.

Unsubscribe any time. We respect your privacy - read our privacy policy.

                 key   accuracy confidence       latitude      longitude            timestamp
     262:2:309:54101       1225         75      52,x67885      13,x90695  16.11.2011 08:21:48
   262:2:65534:65535         -1          0       0,x00000       0,x00000  16.11.2011 08:21:48

                 key   accuracy confidence       latitude      longitude            timestamp
   7c:4f:b5:df:ef:cf         -1          0       0,x00000       0,x00000  16.11.2011 08:21:48
   bc:05:43:eb:90:8f         75         87      52,x66898      13,x90329  16.11.2011 08:21:48
   88:25:2c:22:06:a2         72         92      52,x66372      13,x89764  16.11.2011 08:21:48
   54:e6:fc:b6:57:88        182         82      52,x66961      13,x90662  16.11.2011 08:21:48
   00:1f:3f:d0:59:7a         75         87      52,x66441      13,x89421  16.11.2011 08:21:48
   00:09:5b:da:2c:be        176         87      52,x66774      13,x90851  16.11.2011 08:21:48
   00:23:08:82:69:87        113         87      52,x66436      13,x91162  16.11.2011 08:21:48

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.

The last step is then to start the parsing process by clicking (4) in the “ParsingPattern” window. Et Voila: See the result in the “Output”-Window at the bottom (5).

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:

  1. cache.cell
  2. cache.wifi

The files can be found on the device within the folder “/data/data/”

With AndroidTrackerLE, you can load two files at the same time. After loading both files, it is possible to perform different tasks like:

  1. select Cell Towers as Input
  2. select WiFi Access Points as Input
  3. enable position estimation(*)
  4. enable transmission range visualization(*)
  5. choose multiple timestamps to render either cell towers or wi-fi antennas on the map
  6. retrieve more information on a specific location item by clicking on it
  7. 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.

Position accuracy

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.

What else?

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: or leave a comment.

Thanks for reading this far and feel free to shoot my an email or leave a comment!

Also see my post on iPhone Tracking – from a forensic point of view

11 thoughts on “Android Tracking – from a forensic point of view”

    • Depends on what you are thinking of 😉

      SQLite databases are well documented, you can use APIs and query-languages to easily interact with them. ByteStreams have to be reverse engineered in order to retrieve the information inside. Normally, they are not documented. Carving on the other hand is very hard for SQLite files, much easier for byte-streams….

  1. I’m extremely impressed together with your writing abilities as well as with the format in your weblog. Is that this a paid subject matter or did you modify it yourself? Either way keep up the excellent high quality writing, it’s uncommon to see a nice
    blog like this one today..

    @retirement planning: Just as a side-note: I am not the owner of this weblog rather than just one of many other marvelous contributors. Nevertheless: Thx for your compliment!!

  2. What’s up to every one, the contents present at this web page are really remarkable for people knowledge, well,
    keep up the nice work fellows.

  3. My partner and I absolutely love your blog and find many of your post’s
    to be precisely what I’m looking for. Does one offer guest writers to
    write content to suit your needs? I wouldn’t
    mind creating a post or elaborating on a lot of the subjects you write about here.
    Again, awesome site!

Leave a Comment

Latest Articles