Tagged: XML

Mobile forensic tools like Cellebrite and XRY allow you to export evidence that contains geo-location information. However when this information is exported and even reported from within these tools it can still lack context and meaning. The examiner must further work with the resulting KMZ export within Google Earth to make the evidence presentable to other investigators or in court proceedings.

If you have ever been frustrated and wondered “What now?” when looking at a KMZ file given to you by an analyst or one you have exported yourself, you aren’t alone. I have asked myself the same question. In fact, asking that question lead me to write my own class and book on the subject – Google Earth In Forensic Investigations. I’ve taken five quick tips from my research to help you in shaping your own geo-location cases in Google Earth.

Google Earth Forensic Tip #1 — Use HTML

Not many people know that you can use Hypertext Markup Language or HTML in the feature balloon description box within Google Earth. HTML is extremely useful to help format text for readability, add links to further forensic reports or images to enhance the location.

Feature Balloon in Google Earth showing HTML enhancement

Even knowing a few basic HTML tags such as <br> and <p> can help the readability of your geo-location feature. There are loads of HMTL tutorials on the web and since it involves straight text and markup tags its actually really easy to learn — unlike a lot of programming languages. I encourage you to learn some HTML for your Google Earth cases – you will be pleased with the results in your forensic work.

Google Earth Forensic Tip #2 — Organize!

The location features in your KMZ file may make sense to you, but are you looking at them from the viewpoint of an investigator or even someone further removed from the case such as a prosecutor? As you you begin to work on your exported geo-location evidence KMZ file in Google Earth, it is a good idea to separate similar features — for instance features in the same locations or having the same theme — into folders. Not only does this help you to keep from getting lost in the ‘weeds’ of your work, it helps the investigators and others who view the end result filter details of the case.

Google Earth Forensic Tip #3 — Think Visually

Unless you are looking at images or movies in a digital forensic case report, you are usually looking at plain text or hexadecimal. Geo-location evidence, while containing elements of this type of data — date and time stamps or coordinates — can mean nothing if not put in a proper visual context. This is a real strength of using Google Earth in your mobile forensic cases, it allows you to give visual context to the coordinates that are extracted from the smart phone or GPS device.

Visual context makes a powerful impact on people — so remember to think in visually and use Google Earth to tell a story by showing people the narrative of your geo-location evidence.

Google Earth Forensic Tip #4 — Branding

I’m not talking about coming up with a catchy slogan or tweeting about your forensic case — but putting an agency logo overlay on top of your evidence locations in Google Earth puts a professional polish to the case and can also help warn others that the file contains sensitive information. In addition to logos other overlays such as legends or banners an be added to your Google Earth forensic KMZ — the possibilities are limited only by your imagination.

Agency Logo and Legend Overlaid In Google Earth

Google Earth Forensic Tip #5 — Learn KML

This tip requires a little more work — but not much more than tip #1. KML stands for Keyhole Markup Language and is the underlying markup language that the Google Earth program uses to display details in its 3D viewer. KML is a descendant of the Extensible Markup Language or XML. XML also consists of text and markup tags called ‘elements’. Learning KML allows for greater control of the Google Earth program and how it displays information. I’ve used KML to create timelines and to get rid of the annoying directions link at the bottom of feature balloon.

The Directions link Removed From The Google Earth Feature Balloon

Though there is a slight learning curve and sometimes takes some debugging, learning KML is a useful skill to have in your bag. You can get a basic KML tutorial from Google, though sometimes the best way to learn is to look at others code and cobble up your own from that.

So there you have it, five tips for using Google Earth with exported geo-location evidence in mobile forensic cases. I hope that the tips help you and spark your imagination in how to use Google Earth in your forensic endeavors.

If you want more detailed information on geo-location forensics and using Google Earth, check out my Google Earth In Forensic Investigations course. Drop me a line or a comment about the article — I appreciate all constructive feedback!

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.

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

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

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

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”

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

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!

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!

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.

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.

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.

Location of Binary Plist Trailer

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.

Binary Plist Trailer in separate file

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.

Offset to Offset Table

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.

Length of the Offset 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.

Location of Offset Table

Offset table

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.

Size of integers, location of first object and first object data type

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.