3 Major Issues with the Latest iPhone Tracking “Discovery”

1) Apple is not collecting this data.

And to suggest otherwise is completely misrepresenting Apple. I quote:

Apple is gathering this data, but it’s clearly intentional, as the database is being restored across backups, and even device migrations.

Apple is not harvesting this data from your device. This is data on the device that you as the customer purchased and unless they can show concrete evidence supporting this claim – network traffic analysis of connections to Apple servers – I rebut this claim in full. Through my research in this field and all traffic analysis I have performed, not once have I seen this data traverse a network. As rich of data as this might be, it’s actually illegal under California state law:

(a) No person or entity in this state shall use an electronic tracking device to determine the location or movement of a person.

I don’t think that’s a legal battle Apple wants to face considering the sale of over 100 million iDevices worldwide. That raises the question – how is this data used? It’s used all the time by software running on the phone. Built-In applications such as Maps and Camera use this geolocational data to operate. Apple provides an API for access to location awareness called Core Location. Here is Apple’s description of this softare library:

The Core Location framework lets you determine the current location or heading associated with a device. The framework uses the available hardware to determine the user’s position and heading. You use the classes and protocols in this framework to configure and schedule the delivery of location and heading events. You can also use it to define geographic regions and monitor when the user crosses the boundaries of those regions.

Seems pretty clear. So now the question becomes why did this “hidden” file secretly appear in iOS 4?

2) This hidden file is neither new nor secret.

It’s just moved. Location services have been available to the Apple device for some time. Understand what this file is – a log generated by the various radios and sensors located within the device. This file is utilized by several operations on the device that actually is what makes this device pretty “smart”. This file existed in a different form prior to iOS 4, but not in form it is today.
Currently, consolidated.db lies within the “User Data Partition” on the device. This is a logical filesystem that maintains non-system level privileges and where most of the data is stored. When you perform an iOS Backup through iTunes, it is backing up this partition. Prior to iOS 4, a file called h-cells.plist actually existed in the /root/Library/caches/locationd folder, but with hidden access from other software and applications. h-cells.plist contained much of the same information regarding baseband radio locations as consolidated.db does now, but in Apple Property List format rather than sqlite3. Through my work with various law enforcement agencies, we’ve used h-cells.plist on devices older than iOS 4 to harvest geolocational evidence from iOS devices.
So lets recap.
h-cells.plist = Pre iOS 4 / Radio Logs including Geolocational Data / Hidden from Forensic Extraction (usually)
consolidated.db = iOS 4+ / Radio logs including geolocational Data / Easily acquired through simple forensic techniques
The change comes with a feature introduced in iOS 4 – Mutlitasking and Background Location Services. Apps now have to use Apple’s API to operate in the background – remember, this is not pure unix we’re dealing with – it is only a logical multitasking through Apple’s API. Because of these new APIs and the sandbox design of 3rd party applications, Apple had to move access to this data. Either way, it is not secret, malicious, or hidden. Users still have to approve location access to any application and have the ability to instantly turn off location services to applications inside the Settings menu on their device. That does not stop the generation of these logs, however, it simply prevents applications from utilizing the APIs to access the data.

3) This “discovery” was published months ago.

I understand that Mr. Allan and Mr. Warden are valued researchers for O’Reilly, but they have completely missed the boat on this one. In the spirit of academia, due diligence is a must to determine who else has done such research. Mr. Allan, Mr. Warden, and O’Reilly have overlooked and failed to cite an entire area of research that has already been done on this subject and claimed full authorship of it. Let’s break down my history:
Back in 2010 when the iPad first came out, I did a research project at the Rochester Institute of Technology on Apple forensics. Professor Bill Stackpole of the Networking, Security, & Systems Administration Department was teaching a computer forensics course and pitched the idea of doing forensic analysis on my recently acquired iPad. We purchased a few utilities and began studying the various components of apple mobile devices. We discovered three things:

• Third Party Application data can contain usernames, passwords, and interpersonal communication data, usually in plain text.
• Apple configurations and logs contain lots of network and communication related data.
• Geolocational Artifacts were one of the single most important forensic vectors found on these devices.

After presenting that project to Professor Stackpole’s forensic class, I began work last summer with Sean Morrissey, managing director of Katana Forensics on it’s iOS Forensic Software utility, Lantern. While developing with Sean, I continued to work with Professor Stackpole an academic paper outlining our findings in the Apple Forensic field. This paper was accepted for publication into the Hawaii International Conference for System Sciences 44 and is now an IEEE Publication. I presented on it in January in Hawaii and during my presentation discussed consolidated.db and it’s contents with my audience – my paper was written prior to iOS 4 coming out, but my presentation was updated to include iOS 4 artifacts.
Throughout the summer, I worked extensively with Sean on both developing Lantern and writing custom software to interpret forensic data for customers of ours who needed better ways of searching for and interpreting data.