Having now done a cursory overview of XML, I’d like to turn my attention to property lists or plists as they are commonly known. Plists according to wikipedia (http://en.wikipedia.org/wiki/Property_list) are files that are used to store serialized object – read data. Very often they are used to store application and user settings. They are a rich source of forensic data that is, at least in my opinion – little understood and under-exploited.
I will be concentrating on binary plists as this is the most common format encountered in iOS and will be using as a launch point the excellent paper ” Property Lists in Digital Forensics “by CCL Forensics’ Alex Caithness (you can find a link to the paper at the end of this post). My aim in the next few posts is to illuminate Caithness’ work and break it open in the hopes that it will be understandable to a wider audience.
I have to confess the motivation behind this was slightly selfish. I myself had some trouble following the work and once I had “cracked the code” so to speak, thought it might be useful for others to benefit from a more in-depth discussion of Alex’s work.
So without further fanfare – here is part three , that which concerns binary plists.
Caithness points out in “Property Lists in Digital Forensics” that the binary plist is constructed of four distinct parts (Caithness, p 4). Further more he describes them in the order that he presents as the way to read the file for interpretation. I summarize his findings below.
The file starts out with a recognizable header. This header comprises the first eight bytes of the file and is the ASCII String “bplist00” (\x62\x70\x6C\x69\x73\x74\x30\x30) – which is the file format and the version.
The trailer of the file consists of the final 32 bytes. It contains data that is needed to read the file properly. The trailer will be discussed in detail later as we traverse a binary plist and read it.
The offset table – which will also be discussed later – is a table that contains the offsets – or locations within the file, which point to objects in the object table – meaning the data of the file.
The final part of the file as was mentioned above is the object table. This is the “meat” of the file, which contains the binary encoded data of each object or element in the plist. Like the trailer and offset table we will deal with the unique features of objects in a following section.
We will be using the bookmarks.plist file that is located here .
Finding the trailer on an existing plist is relatively straightforward. Since we know that the trailer is 32 bytes in length (Caithness p.4)- we can sweep the bytes from the end of the file until we reach a count of 32.
Now that I have located the trailer I like to copy and paste the selection into a new hex file so I can refer to its offsets in a separate window and do not have to keep moving back and forth in the file as is seen in the next image.
We are now set to parse the trailer to locate its key elements and find the location of the offset table of the plist which will enable us to parse the the objects contained in the rest of the file.
The below table is a key to parsing out the file – this has been adapted from Alex Caithness’ table found on page 4 of “Property Lists in Digital Forensics”.
|Interpreted Data||Offset in Table||Length of Data||Data Type|
|Size of integers for offset table(bytes)||6||1||8 bit unsigned integer|
|Size of collection object reference integers(bytes)||7||1||8 bit unsigned integer|
|Number of Objects in file||8||8||64-bit unsigned integer (big endian)|
|Beginning object index||16||8||64-bit unsigned integer (big endian)|
|Offset location of object offset table||24||8||64-bit unsigned integer (big endian)|
Binary plist trailer data
Now we will begin figuring out the parts of the trailer to read the rest of the file. I recommend recording the values on a sheet or in a file for easy reference.
- Read the offset to the offset table. Out table above tells us the location of the object offset table occurs at the 24th offset in our trailer and runs for a length of eight bytes. Using our trailer that we copied out of the binary plist file (again this is supplied – link -) we can see that from offset 24 and running eight bytes we get the value of \x02\x89. This is decimal 649.
- Calculate the length of the offset table. The length of the table is obtained by taking the “Size of integers” value located at offset six of the trailer and the number of the objects in the file located at offset eight in the file and running for eight bytes and multiplying the decimal values of these bytes to arrive at the length of the table.
- Find the offset table and block it off. Going to offset 649 – or \x0289 – sweep from that offset for 58 bytes. Then copy those values into a separate hex file for reading.
Our next step entails reading the offset table to find the location of our objects or data. We know that the offset table is a zero based index of the objects in the file, ie. The first object is the 0th entry on the offset table, and the size of the offsets (encoded big endian) from the value at offset six of the trailer(\x02). Now we can look at the offset table and find the location of the first object in the object table. This will occur immediately after the file header(“bplist00”).
We see from the below that this is indeed the case as the offset table indicates the first object occurs at \x00\x08.
The offset table will be read again and again as we go through the objects of the file. Now we must turn our attention to interpreting the objects that are found at each offset that is specified in the offset table.
We have just found our first object at offset 8 in the bplist. The first byte of the object is known as a type-descriptor byte (Caithness p 5) and will hold the clue on how to read and interpret the object.
Reading and interpreting this first object will start us off on the next installment of our Plist, XML and XPATH Series. Until then, I hope that this series is proving informative in your forensic endeavors. I look forward to seeing you next week.
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]
The phrase “profile forcing” refers to using an extraction profile of mobile model numbers in and around the model you are seeking to examine when that model is either officially unsupported or for some reason won’t work with the existing profile. Though not a sure thing, this has proved to be a successful attack on problematic phones and yielded information on what might have been a lost cause otherwise.
I used this tactic just today when trying to grab a physical image of a Samsung GT-s5322A. It was officially not supported for a physical or logical download in XRY and Cellebrite. In fact, the phone was being problematic with the NSPRO box as well. As my frustration mounted, I reached for the UFED again and tried a physical dump using the s5230 profile.
Suddenly a beam of light shot from the sky, the clouds parted, and a heavenly choir began to sing…
Well, the extraction started and I did the Geek dance of joy…over 250 MBs of juicy data – yum!
When using this method always be sure to validate the findings and report the success to the vendor so they can do additional research and add it into their profiles for others to enjoy equally in their forensic endeavors.
Mahalo nui loa Cellebrite for making me look like a rock star in Saudi Arabia today!
Stephen Shankland in his “Deep Tech” blog for CNET is reporting that Andy Rubin, the leader of Google’s Android Project has stated that Android is open source from a “software” perspective not a “community” perspective.
The reason for Google’s approach is so the company can control Android’s interfaces, the underlying features that Android apps use, Rubin told reporters at the Google I/O conference.
These application programming interfaces (APIs) are best developed in private and released only when Google deems them done, a process that ensures app compatibility, he said.
“Open source is different than a community-driven project,” Rubin said, in which a broad collection of people collectively determine the software’s future. “Android is light on the community-driven side and heavy on open source.”
Read more: Android Quasi Open Source
Josh Lowensohn is reporting in his CNET Apple Talk blog that Apple has addressed the public outcry over its devices’ location-tracking behavior including that information’s security in its latest update to iOS.
Lowensohn writes “iOS 4.3.3, which is a free update delivered through Apple’s iTunes software, reduces the size of the “crowdsourced” location cache, no longer backs up the cache to iTunes in the form of a device recovery image, and deletes the cache when a user turns Location Services off. ”
Looks like RIM and Steve Balmer have something that is keeping them awake at night. As Marguerite Reardon writes about in Signal Strength RIM and Microsoft are desperately trying to outdo Google and Apple. Ms. Reardon states that the two new allies are likely only to close the gap in the smartphone race. That’s right – catch up, not pass over. From the sounds of Ms. Reardon’s article, there is a lot of ho-hum going on.
In a related note, I was watching Castle last night and was surprised to see the Apple iPhone replaced by a Windows 7 mobile phone. Rick Castle has been a staunch Apple user – interesting. How much was paid by Lord Balmer for that switch?
Oh yeah and Body of Proof? iPads galore.
Redmond and Waterloo Canada may need some Tums.
I am facinated by SQLite. But before you say “Mike you really need to get out more and get a life! ” consider this -the two most popular smartphone operating systems of today, iOS and Android, use SQLite databases to store important information such as contacts, SMS, and call records. That’s a lot of users – both victims and perpetrators. Have you ever wondered how the SQLite structures its records? An understanding of the SQLite record architecture is crucial to validating the output of forensic tools and for knowing where to look for evidence – including that elusive brass ring, deleted information.
SQLite database images always begin with a well know 16 byte signature which in ASCII is represented by “SQLite format 3” followed by a null byte. The database image header is 100 bytes in length. A full discussion of the database image header can be found on the official SQLite page. Amongst other things a well formed serialized database image will have a database schema or table layout. Knowing the schema of tables is a key bit of knowledge as it will provide the guide to the record header and subsequent record contents.
We will be using a record from the sms database of a first generation iPhone running iOS version 3.13 as an example for this post. Below is a screen shot taken of the schema of the message table using my favorite Mac SQLite editor Base.
Having noted the schema of the message table within the sms database, lets take a look at a record in a hex viewer.
The record is structured as is show in the below graphic.
In addition the record uses the values in the below table to represent the values of the bytes.
So let’s take our example and work through the record header. The first byte of course is our record length – in this case the record is 110 bytes long. The second byte is our key.
The next byte is the length of our record header including this byte – which is 19 bytes.
The next byte is null which indicates that the value is not included in the record. This would have been the ROWID from the schema. The next byte corresponds to the address row in the schema. The byte 0x27 is odd and greater than 13. According to our table this corresponds to text and the byte length is derived by taking the decimal value subtracting thirteen and then dividing by two.
39 -13 = 26 / 2 = 13
We can see from the below graphic that the address or telephone number is indeed 13 bytes in length.
The next byte, 0x4 corresponds in the schema to the date of the SMS. This is a four byte value and is stored in epoch time. The value here is 1296980309 and translates to Sun, 06 Feb 2011 08:18:29 GMT.
The next byte, 0x81 is, as is indicated in the schema, the text message – but it is unique. SQLite uses a compression method based on Huffman coding to store values greater than 127 bits. In this instance the byte in the record header indicating the text message is \x81 or 129 and therefore greater than 127. Since the method uses 2 bytes up to a decimal value of 16,383, we can assume the next byte \x0D is also for the length of the text message. The method to calculate the length of the text message is as follows – where X = the first byte value and Y = the second byte value –
(X-128) x 128 + Y
Calculated out this comes to the below
(129-128) x 128 + 13
To find the length of the header we now refer to the table and do our calculation as normal
This is indeed the length of the text message. The message is straight hex to ascii.
The next byte in the header is 0x1 and in the schema refers to the flags row. The value in this case is 0x02 which means that it is an incoming text.
The last byte of significance in this record occurs at offset 17 in the record and as our table indicates is a value greater than 13 (0x11 = decimal 17). Since the calculation is N-13/2 the value we have here is 2 bytes and this refers in the schema to the country. In our example this is 0x6A 0x6F or “jo” for Jordan.
I hope that you find this post useful in your forensic endeavors. This post would not have been possible without the generous help and counsel of DC Shafik Punja of Calgary and Sheran Gunasekera of ZenConsult Pte Ltd.
Research regarding Huffman encoding in SQLite records was conducted using Murilo Tito Pereira’s article “Forensic analysis of the Firefox 3 Internet history and recovery of deleted SQLite records” published by Elselvier.