Tagged: Iphone

Plists, XML and XPATH – A Series Pt. 4

Greetings from Veenendaal NL! While most of my colleagues from the Amsterdam Police are enjoying SinterKlaas, I thought I would post the next installment in my series on Plists, XML and XPATH.

In this installment we continue to break open the reverse engineering of Alex Caithness’ paper “Property Lists in Digital Forensics”. In our last installment we ended just before looking at the type descriptor byte of our first object.

type_descriptor

Data Type Descriptors

We see that the first byte of our first object is \xD4. Converting this to binary we get the value 1101 0100, which our table tells us is a dictionary. Remember that a dictionary is a collection of key-value pairs. Our table tells us that the second nibble of our byte(4) reveals that the amount of object reference pairs that are present in the dictionary. However, since they are pairs we have to double the amount to get the both the key and the value. The total number of object references in this dictionary are therefore 8. Looking at our bplist file we see that this is indeed true.

Dictionary collection object references

Dictionary collection object references

Since the beginning dictionary for our 0th entry we see that the first object reference after the dictionary is \x01. This refers to the index in the offset table – since the dictionary was found from the 0th index, the first object is found at index #1. The value at the first position is \x00\x11 or decimal 17.

Offset to first object reference of dictionary

Offset to first object reference of dictionary

Going to offset 17 we see that we have \x5f which converted to binary is 0101 1111. Our table indicates that this is a string and the left nibble of the byte “F” tells us that an integer byte follows to give us the length of the string. That byte is \x10 which is 0001 0000 – the data type for an integer. Since 2^0  = 1(remember that length of this data type is 2^nnnn), the length of the data will be read in the next byte – \x0F or 15. Sweeping fifteen bytes after this byte we see that we have the string of  “WebBookmarkType”.

ASCII representation of first object reference

ASCII representation of first object reference

Let’s verify our findings another way. Let’s look at the binary plist decoded into XML to see if our work with the hex is correct. Here we see that the first object is indeed a dictionary and that the first object of the dictionary is a key called “WebBookmarkType”. So far so good!

<?xml version="1.0" encoding="utf-16"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
  <dict>  -> Our first object at the 0th position of the offset table.
    <key>WebBookmarkType</key>  -> The first object of the dictionary collection. This was found at the first 
                                   position of the offset table as indicated by the dictionary object 
                                   reference.

Moving on, the dictionary object reference points to the second index of the offset table.  The value here is \x00\x23. This converts to decimal 35. We find another string – \x5f – at this offset. Reading the next two bytes – \x10 for the integer byte and \x0F for the length (again 15) – we can sweep for our string value, which is in this instance “WebBookmarkUUID”

Second object reference

Second object reference

ASCII Representation of second object reference

ASCII Representation of second object reference

Let’s again check our converted bplist to see if we got it right.

<?xml version="1.0" encoding="utf-16"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
  <dict>
    <key>WebBookmarkType</key>  
    <string>WebBookmarkTypeList</string>
    <key>WebBookmarkUUID</key>

 

Hey wait a second, <string>WebBookmarkTypeList</string> follows “WebBookmarkType”!

No, you haven’t parsed the hex incorrectly. The “value” of the key-value pairs follows in the hex after all the keys have been identified in the order that the keys are identified in the dict object pairs. Don’t believe me? Ok you Philistines, check out the fifth index of the offset table – remember that its zero based so count to five starting at zero. Did you find \x00\x57 (decimal 87)? Good. Now jump back to the bplist and find offset 87 – you should see a \x5f (by now you should guess that its a string). Its followed by integer byte \x10 and then the length by \x13 which converts to decimal 19 for the length of the string in bytes. Now sweep 19 bytes. Did you find “WebBookmarkTypeList”?

Offset to fifth object reference

Offset to fifth object reference

ASCII representation of fifth object reference

ASCII representation of fifth object reference

Recalling the XML conversion of the bplist is “WebBookmarkTypeList” the string value of the key “WebBookmarkType”? You betcha it is!

<?xml version="1.0" encoding="utf-16"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
  <dict>
    <key>WebBookmarkType</key>  
    <string>WebBookmarkTypeList</string>
    <key>WebBookmarkUUID</key>

 

This pattern repeats itself for each of the keys value pairs in the dictionary until it reaches the fourth key. Remember a key can contain as the data type of the element following another collection. This is indeed what we find as the fourth object of the topmost dictionary.

Our examination of the fourth object of the topmost dictionary will start us off on the next installment of our series. Until then, I wish you all the best in your forensic endeavors and a very good SinterKlaas!

References

Apple Inc. (2012) Mac OS X Reference Library, Manual Page for PLIST(5), [Online], Available:https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man5/plist.5.html [October 23 2012]

Caithness, Alex (2010). Property Lists in Digital Forensics, Available:  http://www.cclgroupltd.com/images/property%20lists%20in%20digital%20forensics%20new.pdf, CCL Solutions Group Ltd: Stratford upon-Avon, UK

Eckstein, Robert & Casabianca, Michel(2001). XML Pocket Reference (2nd edition). Sebastopol, CA:O’Reilly and Associates Inc.

Erack Network(2012). Xpath – predicates[Online}, Available:  http://www.tizag.com/xmlTutorial/xpathpredicate.php, [November 1, 2012]

Wikimedia Foundation(2012) Wikipedia: XML[Online], Available: http://en.wikipedia.org/wiki/XML, [October 30, 2012]

World Wide Web Consortium(2012) Extensible Markup Language Tutorial (XML)[Online], Available: http://www.w3schools.com/xml/ [October 24, 2012]

World Wide Web Consortium (2012) Extensible Markup Language (XML) [Online], Available: http://www.w3.org/XML/ [ October 24,  2012]

World Wide Web Consortium(2012) XPATH Tutorial, [Online], Available: http://www.w3schools.com/xpath/default.asp/ [October 28, 2012]

Advertisements

iPhone Forensics – A Series #2

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.

 iPhone OS Schematic

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.

 

 

Data Storage

 

 

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.

 

  • SMS
  • Calendar
  • Photos
  • Camera
  • Youtube
  • Stocks
  • Maps
  • Weather
  • Clock
  • Calculator
  • Notes
  • Setting
  • ITunes
  • Phone
  • Mail
  • Safari
  • IPod

 

 

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.

iPhone OS Schematic

Photobucket
 

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.

 

  • Library_AddressBook_AddressBook.sqlitedb
  • Library_AddressBook_AddressBookImages.sqlitedb
  • Library_Calendar_Calendar.sqlitedb
  • Library_CallHistory_call_history.db
  • Library_Cookies_Cookies.plist
  • Library_Keyboard_dynamic-text.dat
  • Library_LockBackground.jpg
  • Library_Mail_Accounts.plist
  • Library_Mail_AutoFetchEnabled
  • Library_Maps_Bookmarks.plist
  • Library_Maps_History.plist
  • Library_Notes_notes.db
  • Library_Preferences_.GlobalPreferences.plist
  • Library_Preferences_SBShutdownCookie
  • Library_Preferences_SystemConfiguration_com.apple.AutoWake.plist
  • Library_Preferences_SystemConfiguration_com.apple.network.identification.plist
  • Library_Preferences_SystemConfiguration_com.apple.wifi.plist
  • Library_Preferences_SystemConfiguration_preferences.plist
  • Library_Preferences_com.apple.AppSupport.plist
  • Library_Preferences_com.apple.BTServer.plist
  • Library_Preferences_com.apple.Maps.plist
  • Library_Preferences_com.apple.MobileSMS.plist
  • Library_Preferences_com.apple.PeoplePicker.plist
  • Library_Preferences_com.apple.Preferences.plist
  • Library_Preferences_com.apple.WebFoundation.plist
  • Library_Preferences_com.apple.calculator.plist
  • Library_Preferences_com.apple.celestial.plist
  • Library_Preferences_com.apple.commcenter.plist
  • Library_Preferences_com.apple.mobilecal.alarmengine.plist
  • Library_Preferences_com.apple.mobilecal.plist
  • Library_Preferences_com.apple.mobileipod.plist
  • Library_Preferences_com.apple.mobilemail.plist
  • Library_Preferences_com.apple.mobilenotes.plist
  • Library_Preferences_com.apple.mobilephone.plist
  • Library_Preferences_com.apple.mobilephone.speeddial.plist
  • Library_Preferences_com.apple.mobilesafari.plist
  • Library_Preferences_com.apple.mobileslideshow.plist
  • Library_Preferences_com.apple.mobiletimer.plist
  • Library_Preferences_com.apple.mobilevpn.plist
  • Library_Preferences_com.apple.preferences.network.plist
  • Library_Preferences_com.apple.preferences.sounds.plist
  • Library_Preferences_com.apple.springboard.plist
  • Library_Preferences_com.apple.stocks.plist
  • Library_Preferences_com.apple.weather.plist
  • Library_Preferences_com.apple.youtube.plist
  • Library_Preferences_csidata
  • Library_SMS_sms.db
  • Library_Safari_Bookmarks.plist
  • Library_Safari_History.plist
  • Library_Voicemail_.token

 

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.

References

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/

 

http://www.uninnovate.com/2007/07/11/dear-iphone-give-me-my-data/

 

and of course the several wikipedia citations in the post