I’ve been doing some research into the various data storage methods on smart phones and found myself getting engrossed in plists. Though I’ve mentioned them in classes and we’ve talked about how they were constructed and various roadblocks to extracting information from them ,I’d never really done an in-depth module or exercise on them.
Well, I hope with this series to change that omission. At the end of the series, I’ll provide a link to all the posts gathered into one paper. Now without further ado, here is the first of the series on Plists, XML and XPATH.
What is XML?
Although the term XML is thrown around in forensic classes and seen as an option in for analysis output in many of the major forensic tools, how many examiners understand how XML is constructed and the rules that apply to it? As it turns out, XML isn’t all that hard to understand and having a grasp on how it’s used to store data is useful to understanding Plists and other files stored on digital devices – such as current.gpx on Garmin GPS units – which use the XML format.
Let’s look at the building blocks that make up XML and some of the rules that govern them.
Definition of XML
First, let’s define the term XML. XML stands for Extensible Markup Language. This language is an official recommendation of the World Wide Web Consortium (W3C). XML is a metalanguage that allows for the creation and formatting of documents; it is in common use on the Internet and the default of many office productivity suites including Microsoft Office and Apple iWork.
Next, let’s discuss some terminology used in XML so we can understand when these terms are used in later discussions when we are looking at and reading plists. This is by no means all the terminology that is used in XML; rather these terms are covered here in order to give an examiner a working knowledge of items that may be encountered when working on XML formatted evidence.
Elements – XML is made up of one or more elements. Elements consist of two tags – an opening tag, which is the name of the tag delimited by a less-than sign (“”), and a closing tag, which is the same as the opening tag except that there is a forward slash (“/“) before the element name. An example of an element is MAC Address . The text inside the two tags is considered part of that element and is processed per the element’s rules.
Attribute – An element can have an attribute that serves to modify or refine the default meaning of the elements. Attributes can also be applied to empty elements which are used to provide non-texual content or give additional information to the application that is parsing through the XML. Here is an example of a picture element with the src attribute: . This could also be displayed as a short hand because the element is empty.
Declaration – Most XML documents begin by declaring information about themselves for a processing program as in the following example: . This would tell a parsing program that the XML document uses the Version 1.0 format and optimized for UTF-16 unicode encoding.
Document Type Definition (DTD) – This is an external file that specifies the rules for how all the elements, attributes and other data are defined and related. Below is Apple’s DTD for plists (also located at http://www.apple.com/DTDs/PropertyList-1.0.dtd)
Root Element – This is the outermost element to which the DTD applies and is usually the start and end points of the document. An example for a plist would be .
CDATA – This stands for “character data.” Anything that occurs after a CDATA section is not to be marked up and is treated as plain text.
PCDATA – This stands for “parsed character data” and means that any character data that is not an element can appear between the tags. In the above Apple DTD, means that any characters such as “WebbookmarkType” can show up between the key element tags but not another tag such as .
Keep checking back for regular updates to this series.
Check out this article in DFI News by Bram Mooij a veteran of the mobile forensics scene.
Great Article by Kipp Loving and Christa Miller on potentially missed evidence
This is an interesting article found in the Register on the iPhone and the Taliban
Though many phone examiners are traditional electronic forensic analysts who have been trained to examine phones, this is certainly not a foregone conclusion. A phone examiner may not be, to be tongue in cheek, “classically trained” in forensics. Up until just recently, little was needed to examine a phone other than the current toolset that is on the market and a handful of free tools.
Examining phones became harder with the iPhone. Apple’s revolutionary phone has garnered at least 28% of the Smart Phone market and is poised to snatch even more. Spawning many imitators and challenging the once thought invulnerable RIM Black Berry, Apple has raised the bar on the technical skill required by the phone examiner.
This series of posts on iPhone Forensic Examinations, is meant to help level the playing field for the phone examiner who may not also be a traditional forensic analyst of electronic evidence. The first post began by examining what is meant by the term “jailbreaking” and its forensic implications. This post will continue with the discussion and will be concentrating on the makeup of the iPhone’s filesystem.
Brief Overview of the iPhone Hardware
As I stated in the introduction to this post, the iPhone has raised the bar on the technical skill required by the phone examiner. The iPhone is much more than a device that is used for voice communications, it truly is a handheld computer. Below are listed some of the hardware specifications for the device.
- CPU : Samsung/ARM S5L8900B01 512 Mbit SRAM
- DISK: Samsung 65-nm 8/16 GB (K9MCG08U5M), 4 GB (K9HBG08U1M) MLC NAND Flash
- FLASH MEMORY: Intel PF38F1030W0YTQ2 (32 MB NOR + 16 MB SRAM)
Early reports of the CPU clock speed put the iPhone’s ARM processor running at about 400 MHz with a bus speed at 100 MHz (Hockenberry). It is speculated that the ARM CPU can run at 600 MHz or more but is underclocked to provide for heat dissipation and battery life. Further firmware updates are believed to begin providing this capability as the code and hardware are refined and optimized.
So as you can see from the above, you have what amounts to a full fledged computer running with impressive CPU speeds (given its small form factor) and a massive amount (for a hand held device and for mobile forensics) of Flash storage.
The non “classical trained” phone examiner, such as the narcotics officer or border patrolman, is now faced with a device that now at the very least requires an appreciation of its capabilities and may indeed require the acquisition of more advanced knowledge of computers and a deeper skill-set in the area of traditional electronic forensics.
The iPhone Hard Disk
Now that we have had a glimpse of the iPhone’s impressive hardware array, lets begin examining how the iPhone’s Disk is arranged.
The iPhone runs a a mobile build of Mac OS X Leopard (10.5). Schematically the OS is designed like the below graphic.
Since OS X is built upon a BSD Unix foundation (please see http://en.wikipedia.org/wiki/Berkeley_Software_Distribution for a discussion of BSD Unix), and this is used in the iPhone it is necessary to cover some of concepts of the operating system.
All Operating Systems use what is called a kernel. The kernel is the the nerve center of the OS and is responsible for managing the systems resources (such as communication between the hardware and the software of a device. The iPhone uses what is called a signed kernel to limit tampering with its function (though as we saw in the first post jailbreaking is accomplished through the exploitation or hacking of the kernel).
The iPhone also borrows how it partitions its hard disk from the Unix OS conventions as well. In order to store files on a hard disk, that raw physical device must first be prepared with partitions, or contiguous sections of a disk to store common groups of information. The difference in between the iPhone’s partitioning and a physical hard disk is that the iPhone uses solid state memory as its hard disk (flash).
There are two partitions on the iPhone. The first partition is 300 MB in size and is the system or root partition(not to be confused with the root folder which will be seen in the second partition). This partition contains the operating system and the default applications that are delivered with a factory fresh iPhone. This partition is designed (unless jailbroken) to be in this pristine state for the life of the phone.
The remaining space of the hard disk is partitioned as the user-space (or media) partition. This space is where all music, videos contacts, SMS etc are stored.
Another computer science concept that is also important to understand is the concept of mounting. A file system must be “mounted” or made available to the Operating System for use. Unix type Operating Systems (such as OS X) use mount points or the location in the directory structure where the particular partition (filesystem) is available for use. The Windows equivalent to this concept is drive mapping.
Since the iPhone uses a mobile build of OS X , it follows that the two partitions is has will have mount points. This is indeed the case as can be seen from the output of the fstab file( file system table) of a jailbroken iPhone. The fstab file usually lists all available disks and disk partitions, and their mount points.
# cat fstab
/dev/disk0s1 / rw 0 1
/dev/disk0s2 /private/var hfs rw,noexec 0 2
A discussion of the fstab is too lengthly and complicated to go into in this this post so readers are directed to http://en.wikipedia.org/wiki/Fstab for a thorough explanation of the output. It should suffice for our purposes here to state that the first (root partition) is mounted at the top of the directory tree (“/”) and that the media partition is mounted at /private/var. It is also of forensic importance to note that the root partition here is mounted read/write. This is the result of the jailbreaking technique.
The other thing to note on the output above is that the media partition is formated in the HFS file format, and is not allowed to execute files (the “noexec” option).
Depending on whether a user is Windows based or Macintosh based the iPhone will be formatted accordingly. In the case of Windows with a FAT filesystem (http://en.wikipedia.org/wiki/FAT_32) or HFS (http://en.wikipedia.org/wiki/Hierarchical_File_System) if formatted on a Macintosh.
Now that we know the partition structure of how the iPhone stores data, how it is mounted for user access by the Operating System, and what filesystem formating it employs, we can look at where the most relevant files for a forensic examiner might reside. Bear in mind that the tools mentioned in the first post obtain most, if not all, of these files and report on them. The single advantage that the jailbreaking method has (offset by its non ACPO compliant forensic implications) is that the jailbrekaing method comes very near to a true forensic image and can therefore obtain possible what I have oft termed the Holy Grail of Mobile Forensics – deleted data.
As was said in the previous section the root partition is designed to stay “factory fresh” for the life of the iPhone and contains the default applications and the untampered OS of the device. It should contain most of the following if not jailbroken.
Shown below is a graphic image of a jailbroken iPhone showing the media partition of a jailbroken iPhone. It was obtained by a jailbreaking the iPhone, setting up a wireless network and then using the “dd” command over the network. The resulting image was then mounted read only under OS X It should be noted that in a non jailbroken iPhone iTunes in its jailed access is only allowed to get to files mounted in private/var/mobile/Media or /private/var/root/Media depending on the generation of the firmware.
The iPhone stores the information most valuable to a forensic examiner, e.g. Contacts,SMS, Call Registers in Sqllite databases. In addition, the iPhone in sharing with the full fledged version of OS X stores additional information in XML like lists called Plists. Plists store a lot of cool forensic information but are beyond this post. Readers interested in Plists can find more information at http://en.wikipedia.org/wiki/Plist.
Below is a list of the plists and sqlite databases that are downloaded to a computer during an iTunes sync process.
Many of these tools are obtained and reported on by the logical analysis tools mentioned in the first post.
I will detail ways of analyzing the sqllite databases obtained in a computer sync in the next post.
As always, I stand upon the shoulders of others. Acknowledgement goes out to the following sources
iPhone Forensics, by Jonathan Zdziarski. Copyright 2008 Jonathan Zdziarski, 978-0-596-15358-8
Craig Hockenberry, http://furbo.org/2007/08/21/what-the-iphone-specs-dont-tell-you/
and of course the several wikipedia citations in the post
The Apple iPhone has been generating a huge amount of buzz lately both from the consumer and business customer and now from the forensic community. Several forensic companies have released tools to forensically examine iPhones; Radio Tatics LTD(Aesco), Cellebrite, Paraben (Device Seizure) and myself ( Sixth Legion, WOLF) to name a few. Each of these applications retrieves SMS, Call Records, Contacts as well as other information. And as you undoubtedly have heard it is always a good idea to have more than one tool in your toolbox for validation, preference and detail of information obtained. Each of the applications above have their place in your forensic arsenal.
However different and effective at obtaining the basics of a mobile forensic examination(Contacts, SMS, Calls) each the above applications are, they all share one commonality. None of the above mentioned products obtain what is considered the Holy Grail of Mobile Forensics, a true physical image and the ability to get deleted information out of the iPhone. There is one method however that can get very near to a physical image of the iPhone and this image can be data mined for deleted information. However, this method has two particular sticking points. One, it involves a fairly complicated process that relies on a knowledge of the command line interface and unix tools. Two it involves the breaking into the filesystem of the iPhone and injecting a toolkit to get this image, which is arguably not forensic and violates Apple’s intellectual property.
In this first of several posts on iPhone forensics, I am going to examine what is meant by the term “jailbreaking”, which is the term used for changing of the iPhone filesystem and allowing the injection of a forensic rootkit that will allow the examiner to use more traditional digital forensic tools to get as close to a physical image as possible. My goal in writing these posts is to try to demystify and bring technical language about this method down a notch so that phone examiners that may not also be cross trained in traditional electronic forensics can attempt this method particularly if the case is very important ( such as in terrorism or homicide) and the method is justified.
How the iPhone Communicates with a Computer
The iPhone is designed to communicate (read backed up) with a computer via an interface called the Apple File Communication Protocol (AFC). This protocol is a serial port protocol that uses a framework called MobileDevice that is installed with iTunes (default on Apple’s OS X). The protocol uses the USB Port and cable when it is connected to the computer and is responsible for things such as copying music and photos and installing firmware upgrades.
However, the AFC and iTunes are not allowed to communicate with the entire iPhone memory area. Instead access is limited to certain files on the iPhone, namely those located in the Media folder on the second partition of the device (I will detail the filesystem and partition layout of the iPhone in a follow-up article).
In other words, iTunes is allowed access to a “jailed” or limited area of the device memory. While the AFC can be used for transferring files, it is not effective for reading information from raw devices which is essential to obtaining a physical image. Therefore,some modification needs to occur to the filesystem in order to make access to the raw device and get a truer physical bitstream copy.
So iTunes accesses the iPhone in a jailed environment; what exactly does this mean? The idea of a jailed environment is actually borrowed from the Unix world ( Unix for those of you that don’t know is an operating system-see http://en.wikipedia.org/wiki/Unix). Simply put jailed access means that access to certain areas of memory and files is restricted and that access allowed is not of an administrative or root level. This is generally done to prevent damage to a system.
To recap, the system partition an iPhone, the partition where the OS and the default applications live on the flash memory, is protected from low level access by iTunes or processes unless modified in some way ( the partition layout I will again detail in another post). This “protection” is done through something called a jailed environment or sometimes called a ‘chroot jail’ which is, again, borrowed from the linux/unix lexicon.
When a Chroot occurs, it changes the apparent root directory. Any program that is re-rooted to another directory cannot access or name files outside that directory. This re-rooted directory is called the chroot jail or the jailed environment.
In reference to the iPhone, the chroot jail directory is Media folder (detailed in another post).
The term “jailbreaking” in reference to the iPhone refers to the breaking open of this chroot jail to allow read/write access to the entire device; not just the Media folder. This, coincidentally, is exactly what occurs in the computer world when a hacker breaks into an unauthorized system and gains root access.
What Occurs When an iPhone is Jailbroken
In essence, what occurs when an iPhone is “jailbroken” for forensic examination is that select Apple File Protocol is used to boot what is called a Ram Disk (An area of RAM that acts as if it were a disk drive) into the iPhone’s running memory. This Ram Disk then mounts the iPhones filesystem and the forensic payload is copied into the filesystem. The iPhone is then rebooted and the payload executes its tasks (for instance, installing traditional Unix tools such as DD and SSH for making disk images and secure networking).
This is of course a simplified explanation, readers who seek more detailed and thorough discourse are invited to read Jonathan Zdziarski excellent book on the subject that is cited at the end of this post.
Forensic Implications of Jailbreaking
You may find yourself in a situation with an iPhone where “Desperate Times Call For Desperate Measures” and need to use the jailbreaking method of examining the iPhone. However, one needs to bear in mind that it isnt really and truly forensically sound and does in fact violate Apple’s copyright and ACPO. Remember the four principal tenets of the ACPO guidelines
- No action taken by law enforcement agencies or their agents should change data held on a computer or storage media which may be subsequently be relied upon in court.
- In exceptional circumstances, where a person finds it necessary to access original data held on a computer or on storage media, that person must be competent to do so and be able to give evidence explaining the relevance and the implications of their actions.
- An audit train or other record of all processes applied to computer based electronic evidence should be created and preserved. An independent third party should be able to examine those processes and achieve the same result.
- The person in charge of the investigation (the case officer) has overall responsibility for ensuring that the law and these principals are adhered to.
As you can clearly see, jailbreaking an iPhone violates at least the first of these tenets, and it is incumbent upon the examiner to understand thoroughly the method and report on it per the second. There is also a potential problem with the third tenet as well. The examiner should strongly consider whether the applications named in the beginning of this post obtain what is necessary before taking the steps outlined in the jailbreaking method so as to not only follow the ACPO guidelines but avoid possibly destroying evidence.
While effective and very clever the jailbreaking method can be dangerous, especially to examiners that are not used to the command line interface and manually carving data out of an image.
I hope that this post has been informative for the mobile forensic community. In follow-up posts, my goal is to help you with the jailbreaking method of examination as well as looking at iPhone backups, the structure of the filesystem and databases.
Please post commentary about this guide and what you may like to see on follow-up posts.
I am indebted to Jonathan Zdziarski for his work in iPhone Forensics. I highly recommend his book for all those interested in the iPhone.
iPhone Forensics, by Jonathan Zdziarski. Copyright 2008 Jonathan Zdziarski, 978-0-596-15358-8.