30 November 2011

[Forensic] iPhone Tracking


Bài viết liên quan:


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…

Swarm-Mapping


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

http://petewarden.github.com/iPhoneTracker/
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
    • CELLLOCATION and
    • WIFILOCATION
  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 experience with iPhone Tracker from Pete Warden was, 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!!!! (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:
  • CELLLOCATION
  • WIFILOCATION.
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)
  • Timestamp in 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- Accuracy of 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 Altitude of the device
    • the Altitude of celltowers is 0, because the greater divergence resulting of a higher transmitting range
  • Speed / Course
    • not used
  • and the Confidence of 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.

LocationHarvest

The table records the following information:
  • an individual Timestamp for every location with very short intervals
    • in CFAbsoluteTime format
  • Latitude, Longitude and Altitude values as expected for a location service
  • Horizontal- and Vertical- Accuracy values
    • maybe used for describing the exactness of the actual position information
  • navigation information like
    • Speed in m/s and a
    • Course in 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!

CellLocationHarvest

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
  • Timestamp in 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- Accuracy values
    • to be interpreted as the maximum derivation of the GPS-data
  • and the Confidence of 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
  • Course in 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…

WiFiLocationHarvest

The table records the same information as the WiFiLocation table:
  • an Individual Representation of the source for later location estimation
    • the MAC-adress
  • Timestamp in 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- Accuracy values
    • to be interpreted as the maximum derivation of the GPS-data
  • and the Confidence of 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 Age value
    • (?)
  • 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

CellLocationLocal

Last but not least, I discovered another table called
  • CELLLOCATIONLOCAL.
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.
I then combined different sources to figure out, which entry would fit best. Or do you get it at a glance, if it is the first, the average or the last entry for that timestamp…
Well. Long story short: it fits best to take the first entry from every timestamp. After applying the horizontal accuracy value (range in meters) for this WiFi hotspot, you even get a better idea of where the iPhone has been.
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 do sometimes “move”
  • cell towers are more stable concerning their positions but have bigger transmission ranges
But if there are real GPS-informations from the harvesting-tables, you should prefer to look at them.

0 comments:

Post a Comment

Để lại góp ý của bạn để blog của mình hoàn thiện hơn :))