Today, two researchers for O’Reilly media published an article claiming discovery of a hidden tracking system on the iOS 4 operating system. Using simple techniques, Alasdair Allan and Pete Warden extracted data off of an iOS version 4 device and wrote an open source software utility to effectively graph this data onto a map. As a fellow researcher, I champion their creativity and their development. As an expert in this field, I have three points of argument to raise.
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.
When the iPhone 4 came out, I was one of the first people in San Francisco to grab one (yes I waited to be in the front of that awful line).
( Look for the RIT shirt )
Within 24 hours of the iPhone 4′s release, we had updated Lantern to support forensic analysis of iOS 4.0 devices. Within 36 hours, we had began writing code to investigate consolidated.db. Once a jailbreak came out for iOS 4, I wrote a small proof of concept application to harvest the contents of consolidated.db and feed it to a server for remote location tracking.
Ever since then, location artifacts have been a main area of interest for me. I’m now the Lead Engineer for Katana Forensics leading all technical research and development of both Lantern and private utilities. I travelled to Salt Lake City, UT in November for the Paraben Forensics Innovation Conference (PFIC) and presented with Sean on iOS Forensics including the content of consolidated.db. At that same conference, Sean and I announced the development of Lantern 2.0 which would fully support the interrogation of consolidated.db and other geolocational artifacts scattered throughout the device.
Sean and I even wrote a book detailing iOS forensics involving iOS 4 devices that came out on December 5th, 2010.
Sean Morrissey, Primary Author, Alex Levinson, Contributor
In the course of writing Chapter 10 – Network Forensics – I fully explain and detail the examination of consolidated.db and other network artifacts within the device!
Page 335 - Continued on page 336.
In February of 2011, Sean and I previewed Lantern 2.0 at the DoD Cyber Crimes Conference in Washington, DC including our geolocational features. Lantern 2.0 has been on the market for months now and performs the same functionality Mr. Warden’s utility does and much more. We correlate geolocational data embedded in images and third party application. We give you a geolocational timeline of events in list view showing much more than baseband logs within consolidated.db.
While forensics isn’t in the forefront of technology headlines these days, that doesn’t mean critical research isn’t being done surrounding areas such as mobile devices. I have no problem with what Mr. Warden and Mr. Allan have created or presented on, but I do take issue with them making erroneous claims and not citing previously published work. I’m all for creative development and research, as long as it’s honest.