iPhone Tracking – from a forensic point of view

– Introduction –

iPhoneTracking is sexy!!! Every mobile forensic suite, at least the ones dealing with iPhones, are providing it proudly. iPhoneTracking also has been a hot topic in the media all around the globe. People stated, that there is a way to display every step of an iPhone user ever since the device got bought. Hm… Sounds great for all kind of investigations! Let’s see…

Apples Point of View

Apple, on the other hand, stated that: “in no way Apple does tracking movements of iPhone users”. What Apple admits is to provide a well designed CoreLocation Framework.

(Apple Inc)

The goal behind CoreLocationFramework is to provide location based services being:

  • Available instantly everywhere, all the time, but
  • also resource friendly, saving battery life.

The Location sources or maybe the problems to be solved are:

  • GPS (is not available inside buildings, eats up battery-lifetime)
  • Cell towers (have no geo-coordinates available)
  • Wi-Fi hotspots (have no geo-coordinates available either).

The solution would be to provide geo-location information from the built-in GPS sensor when necessary and available and some kind of fall-back location estimation inside buildings or whenever GPS is not (yet) available. Most iPhone users do have mobile service and Wi-Fi enabled all the time. Cell towers and Wi-Fi hotspots can be concerned to be quite stable regarding their geo-location. And: there are several signal-stations availble all around the position of the user that can be used to calculate the actual position on base of triangulation. The problem for Apple is to build up a map, that has to be up-to-date and for best at no additional costs *smile*. How to achive that? I think, it is achieved by a mechanism, I call…

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.


Swarm-Mapping procedure

Apple has sold milllions of GPS-trackers (they call them iPhone) with additional mobile-/WiFi-chips. They can rely on a lot of iPhone users out there to provide data, even not knowing they do.

In general Swam-Mapping consists of three steps:

    1. Collecting data from enabled (and available) signal sources when CoreLocationFramework is active
      • on the iPhone recording current GPS-position and surrounding Cell Towers and Wi-Fi-hotspots infos
    2. Submitting the collected data to Apple
      • where the data is consolidated with already collected location informations from other iDevices
    3. Providing Data back to the iDevices
      • when requested from different location-based services.

I would like to provide a simple example for the consolidation process:
Lets think of three people on their way home… They do not use the same, but nearly the same way, receiving the same cell towers and Wi-Fi hotspots. With collected GPS data from different positions it is possible for Apple to refine the position for every seen radio source.
Now imagine thousands of people (maybe also the same user on the way to work the next day) providing location data for the same radio transmitter from different GPS-locations again and again.

iPhone Tracker – Pete Warden


One of the first persons, who brought the attention on this topic to the people in the public, was Pete Warden. He and his colleague Alasdair Allan provided a tool called “iPhone Tracker” to display the location informations saved on an iPhone.

(Screenshot: iPhoneTracker, Pete Warden)

What does the tool do?

  1. It searches for the SQLite3-database “consolidated.db” in the mobile backup of iTunes
  2. extract informations from the tables
  3. displays the geo-location information on a map in correlation to the timestamp, when the coordinates were received also regarding the amount of coordinates received for one certain timestamp.

My first experiences with iPhone Tracker from Pete Warden were, that

  • the tool isn’t using real GPS-Data from the iPhone
  • so the data are not accurate (why is there a grid?)
  • and the data-sources are not distinguished
  • the tool is not very user-friendly
  • only one timestamp selectable at a time
  • no resize of the window provided

I was quite dissapointed, cause it definitely was not forensic sound in any way! I then had the idea to develop my own framework. I’ve had already a tool displaying maps using the jxMapKit-framework for OpenStreetMap and another tool reading data from sqlite3-dbs. No big step to combine these tools into what I call a forensic suitable iPhoneTracker tool.

– Forensic Investigations –

my iPhoneTracker – first beta

My very first version did provide the following:

  • no grid alignment of the data
  • distinguish different data sources (CELLLOCATION, WIFILOCATION)
  • display specific timestamps
(Screenshot: iPhoneTrackerLE)

But more than that, I got a framework to examine data from a trusted, well known data source; my own iPhone. With this tool, I examined my different consolidated.db’s in correlation to my calendar 😉

I figured out, that there are more than just the consolidated-data provided by Apple used by Pete Warden’s iPhoneTracker. As stated above in the Swarm-Mapping chapter it is obvious, that Apple has to rely on location data of either celltowers or WiFi hotspots in order to provide an assisted GPS feature on the iPhone. They could buy the information from different providers, who have built up their own location-databases, but the problem is, that the location of the antennas or devices are not published by mobile carriers (celltowers) or are not known generally (WiFi hotspots). Beside that, the location informations are not totally static. Provider add celltower antennas and private people change their WiFi-hardware without informing anyone *smile*. So why not collect the data with the help of millions of iPhones all around the world? Brilliant! Ok. I mentioned that already.

From a forensic point of view, both kind of entries (received from Apple / recorded by the iPhone itself) exist within the database and need to be examined towards their forensic relevance. I will go into detail on that just in a minute.

For now, it can be stated, that neither the iPhoneTracker provided by Pete Warden nor actual commercial forensic products are usable in court regarding the forensic reliability of tracking informations!!!! (If you disagree in this; feel free to shoot an email or a comment to me; as long as you provide your product name and a free evaluation copy *cough*)

– Location Data provided by Apple (I) –

CellLocation, WiFiLocation

I further examined the data provided from Apple:


At first, I took a closer look at the table data:

Both tables provide nearly the same information:

  • an Individual Representation of the source for later location estimation
    • MCC, MNC, LAC, CI (for celltowers)
    • MAC (for WiFi hotspots)
  • a Timestampin CFAbsoluteTime format
    • when the location information of the device was retrieved,  that is, when location services were used and the location daemon needs to be updated.
  • the Location of the device
    • Latitude, Longitude,
  • the Horizontal- and Vertical- Accuracyof the device
    • to be interpreted as the transmitter range of the device (therefore celltowers do not transmit vertical, so the value is -1.0, many WiFi hotspots do have more than one antenna to provide a more all around transmitting range)
  • the Altitudeof the device
    • the Altitude of celltowers is 0, because the greater divergence resulting of a higher transmitting range
  • Speed / Course
    • not used
  • and the Confidenceof the source
    • to be interpreted as the reliability of the source
    • 50-70 for celltowers, maybe in relation to the consolidation experience from Apple
    • 50, “to be or not to be”, or 50% of reliability

Experiences and Problems

From what were my first experiences and from a forensic point of view, the location entries provided from Apple (CellLocation, WifiLocation) are not usable at court! One main problem is, that the entries in the table are derived from Apple as base information to the actual position estimation process. The data is not retrieved from the built-in GPS-sensor (the device itself).

There are several other problems, which I would like to outline:

There is no exact position of the device or user at one specific timestamp

The result data is not presenting only one location of the device at a specific time, but rather a set of cell towers or Wi-Fi hotspots around the estimated position of the device.

The center point is a rough estimation of the location, but not guaranteed. (The blue arrow describes the route I took with the car, the red cross the location I have been at that time)

The estimation of the actual position can be derived from other available sources

One of my suggestions is, that the iPhone uses the location of the actual used celltower or an estimated location of the IP-address you are using over Wi-Fi, when the GPS-signal is not available inside a building.

The red cross is the location I resided at the selected timestamp.

The result data from Apple might also include unconsolidated data

for instance, when Wi-Fi hotspots got “moved” or because cell tower antennas are not reachable from every direction.

The figure above shows the recorded Wi-Fi hotspots the day I was at the Cebit fair 2011 in Hannover, Germany. There were a lot of exhibitors from all over Europe, who used their own Wi-Fi hotspots which were formerly consolidated to their home-/ business-location. For that reason it is explainable, despite of residing in Hannover without moving to other countries, the iPhone saw MAC-Addresses from devices, all over Europe. Some Wi-Fi hotspots were even reported at locations in India and Asia!!

It would have been interesting to observe, if the hotspots would get consolidated through Apple to show the actual location in Hannover right the day after. But this is not the scope of this article. It is just another example, that it is not possible to get an exact movement profile of an iPhone user with that source of data (CellLocation, WiFiLocation). But maybe, there is more inside the database…

– Location Data collected by the iPhone itself –

Swarm-Mapping how it actually works

As I further examined different consolidated.db files, I came across a table containing 2401 timestamps from only one day with only one location-information for every timestamp. The data shows exactly the route I took, and the timestamps were recorded with an interval from seconds. I used Navigon MobileNavigator to navigate…

So: It is obvious, that Apple (or better: the LocationDaemon) records tracks of its users (*smile*)

The problem with these tracks: the waypoints do not contain any references like cell towers or WiFi hotspots to be consolidated and useful for others. But: There exist the so called “harvesting”-tables containing much less, but more interesting data. According to the timestamps and waypoints recorded in the CellLocation-table, the data in LocationHarvest and WiFiLocationHarvest save cell towers and WiFi hotspots seen from the actual GPS-position.

Harvesting Tables

As stated before, Apple needs to get data from users to build up the consolidated database. In summary, there are three different harvesting tables:

  • LOCATIONHARVEST (GPS-position recorded from GPS-Applications)
  • CELLLOCATIONHARVEST (strongest cell tower seen from the actual GPS-position)
  • WIFILOCATIONHARVEST (strongest WiFi hotspot seen from the actual GPS-position)

These tables usually do not contain any data due to the fact, their content gets deleted right after the data is successfully submitted to Apple. As for iOS 4.3.3 and later, the data gets submitted to Apple, as one of the first actions, when there is a WiFi-connection available. As far as I can say, the data is not transmitted over a mobile service network connection cause it would stress the mobile plan and would definitely mean more bad press for Apple. For safety, one of the first actions when seizuring an iDevice definitely is to put it into “flight mode”!

So: most of the time an investigator examines the harvesting tables, they might be empty. Nevertheless, I had luck to preserve a well populated consolidated.db before the transmission process towards Apple cleaned up the tables.


The table records the following information:

  • an individual Timestampfor every location with very short intervals
    • in CFAbsoluteTime format
  • Latitude, Longitude and Altitude values as expected for a location service
  • Horizontal- and Vertical- Accuracyvalues
    • maybe used for describing the exactness of the actual position information
  • navigation information like
    • Speed in m/s and a
    • Coursein degrees of direction meaning
      • 000 = north
      • 090 = east
      • 270 = west and
      • 180 = south
  • Confidence seems to be 90 all the time, which means, that information from the GPS-sensor seems highly valuable for the location service
  • TripId and Context maybe for internal use, though they are not reused in other harvesting tables as far as I can say, don’t know what they describe exactly

Within the tables I investigated, there weren’t more than the maximum of 2 routes recorded due to the fact, that after submitting the data to Apple, the data gets deleted as stated before. But this might be different, for a device seized on a journey with no possibility to transmit the information over WiFi. So put the device in “flight mode” right after seizuring the device!


The table records the same information as the CellLocation table:

  • an Individual Representation of the source for later location estimation
    • MCC, MNC, LAC and CI
  • a Timestampin CFAbsoluteTime format
    • describing the time, the GPS-position of the device was recorded
  • the Location of the device
    • as Latitude, Longitude and Altitude values
    • determine the location of the iPhone itself, not the celltower
  • Horizontal- and Vertical- Accuracyvalues
    • to be interpreted as the maximum derivation of the GPS-data
  • and the Confidenceof the source
    • to be interpreted as the reliability of the source
    • with 90 as the highest possible information cause of GPS

as well as additional information like:

  • the mobile Operator
    • in my case t-mobile Germany
  • the BundleId
    • naming the application, which is to be the source of the information
  • and navigation information like
    • Speed in m/s and a
  • Coursein degrees of direction meaning
    • 000 = north
    • 090 = east
    • 270 = west and
    • 180 = south

Keep in mind, that the presented geo-location is not the position of the cell tower itself but the location the device resides at the time, when the different cell towers were seen. This is exactly the same with the data recorded within the next table…


The table records the same information as the WiFiLocation table:

  • an Individual Representation of the source for later location estimation
    • the MAC-adress
  • a Timestampin CFAbsoluteTime format
    • describing the time, the GPS-position of the device was recorded
  • the Location of the device
    • as Latitude, Longitude and Altitude values
    • determine the location of the iPhone itself, not the celltower
  • Horizontal- and Vertical- Accuracyvalues
    • to be interpreted as the maximum derivation of the GPS-data
  • and the Confidenceof the source
    • to be interpreted as the reliability of the source
    • with 90 as the highest possible information cause of GPS

as well as additional information like:

  • the transmitting Channel
  • a flag describing the Visibility
    • Hidden: 0 = no, 1 = yes
  • the transmitting power
    • RSSI in decibel (?)
  • an Agevalue
    • (?)
  • the BundleId
    • naming the application, which is to be the source of the information
  • and navigation information like
    • Speed in m/s (in the case above 0) and a
    • Course of -1


Last but not least, I discovered another table called


I invested quite some time to think about the data stored in this table. And I was to release this article with the words: „I don’t know what this table is all about“. The columns of the table look the same as in CellLocationHarvest.

The table contains only one entry most of the time, which is not updated to often.

But there is a major difference to CellLocationHarvest: Obviously, at least one entry preserves the WiFi-transmit of data to Apple. Because of that, I think the stored data might be also used by other applications for getting a faster GPS-fix. But only Apple knows for sure 😉

– Location Data provided by Apple (II) –

Back to the beginning… As I stated before, the main problem with the location data retrieved from Apple is, that there are always several location-entries received from Apple for one single timestamp entry. It would be nice to figure out one single geo-location at one timestamp.

I tried out different techniques:

  • the first entry,
  • the last entry,
  • the average over all points.

It was obvious to me, that it would not be an exact GPS-position, because from the idea of swarm-mapping I have, the actual position is calculated from different sources according to the different signal strength received. But one of the entries has to be at least in the range of the iPhone mobile or WiFi connection.

To figure it out, I combined different sources. As you can see below, there is a gps timestamp quite in the middle of the set of WiFi hotspots. The question is: which one fits best concerning the GPS position?

Is it the first, the average or the last entry for that timestamp… what would you guess?

Well. Long story short: for implementation aspects, it is very easy to take the first entry from every timestamp. After applying the horizontal accuracy value (range in meters) for this hotspot, you even get a better idea of where the iPhone has been.

From my further research, it has to be stated, that there is no general rule, which entry in the set of location-data retrieved from Apple fits best. In most cases the first entry, with horizontal Accuracy applied, gave the best results.


Position estimation helps a lot, but validating every timestamp still is necessary!!!!!!!!

My latest experiences regarding position estimation from consolidated-iPhone-data:

  • WiFi hotspots are very accurate (small transmission range), but may sometimes “move”
  • Cell towers are more stable concerning their positions but have greater transmission ranges

But if there are real GPS-informations from the harvesting-tables, you should prefer to look at them.

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

What else??

In the meantime I finished iPhoneTrackerLE v. 1.7 with great features like

  • using GPS-values recorded directly from the iPhone itself with course direction applied (I don’t think anyone else has included that in an iPhoneTrackingTool or Forensic Suite?!)
  • position estimation from Apple provided data (I did not see anyone else featuring this; all the other tools provide is a horrible amount of data to every timestamp)
  • providing the horizontal accuracy (the transmission range), which indicates even better, where the iPhone has been
  • internationalization (english, german) (help me to provide even more languages; all you have to do is to translate about 100 words…)
  • some minor bug-fixes

I will provide iPhoneTrackerLE FREE for LawEnforcement agencies through a download from a restricted website. You may contact me by mail: 4rensics@gmx.de or leave a comment.

See also my post on Android Tracking – from a forensic point of view

22 thoughts on “iPhone Tracking – from a forensic point of view”

  1. Very nice article !!
    Have you tried looking for deleted rows (from harvest tables) which are sometimes easy to retrieve in sqlite db ?
    I’m also interesting in an evaluation copy.

      • 4RENSIKER, isn’t using a device like this, as lawenforcement, going a little past violation of peoples right to privacy? I ask this, because it seems a little to creepy for any government agency to have the ability to just look up where someone is at any time, with or without a warrant. While I’m sure many Lawenforcement professionals do not abuse the power given, we both know many do.

        • Hi Chris. You are right: “With great power comes great responsibility”. But this is totally out of scope for my article…

          I believe, that investigators, who rely on forensic software should have an understanding of what is behind the reported results. In case of iPhoneTracking, still today, no forensic mobile software suite uses real GPS data. They still rely on and present lots of different locations instead of providing one single location for a single timestamp. They also do not state anywhere, that these data (especially from WiFi-hotspots) has to be validated!

    I went home last night thinking about the fact that the technology could be used inappropriately, but then I realized that the people buying this technology likely realize that they are opening theirselves up to this kind of a problem, (if ever it were to be used inappropriately.) I personnally have never owned and I don’t think I’ll ever buy one. I hate electronic leashes enough as it is.

  3. Hey, I know this is kind of old but I’m putting some material together for a Forensics seminar as part of an Information Security education program and I’d like to know if you still have the program. I work in the Network Security industry and I can provide my real email address on request.

    • The Software is still available as it is still working the same way for years… Unfortunately, due to certain circumstances, I am only able to share these tools with full time law enforcement officers from high tech crime units… Sorry

  4. Hello, I have read your article carefully, very good indeed, in addition to the questions and comments, I am the systems director of a public university in Mexico, our area helps the judiciary in various cases, your tool seems valuable if it is still working with the current versions of iOS, I understand that we are not a police force, could we still have a copy? Thank you.

    • Hi there. Thanks for the compliment and yes, iPhoneTrackerLE3.0 is still working with all versions of consolidated.db, cache.db, cache_encrypted*.db and so on from iOS4.0-10.x. Regarding the software: Still only available to LE without exception, Sorry. Maybe you can team up for the case with them?!

Leave a Comment

Latest Articles