Reverse Engineering Evernote Penultimate (or: When is a picture not a picture?)

In this post Alex Caithness takes a look at “Penultimate” on the iPad and discovers that a picture paints a thousand words… but only once you work out how that picture is stored.

Recently we came up against an iPad note-taking application by the name of “Penultimate”. As a user it’s actually really quite a nice app to use: you can create multiple “notebooks” each with as many pages as you require on which you can jot down notes, draw diagrams or just doodle with a stylus or your finger. For a user it’s nice, simple and intuitive, for an intrepid forensic analyst, it’s not quite as straight-forward…

Penultimate Hello World Screenshot

Penultimate Screenshot

After installing the application on a test iPad, creating a couple of notebooks and having a doodle in each of them, I performed an extraction of the device. Poking through the application’s folder, this is the layout of the files which we can acquire with a backup-style acquisition:

 │     com.cocoabox.penultimate.plist
 └───Private Documents
 │     notebookList
 │     notebookListBackup
 │     100F53F2-BD1F-4046-8104-714E42264DAE

Now, ideally what we’d liked to have seen at this point are some image files, a nice friendly JPEG, GIF or PNG or two would have been just lovely. But no, it’s not going to be that easy (and, in fairness, if it had been I wouldn’t be bothering with this blog would I?).

So what do we actually have? Well, we can see the familiar “Library” folder in which we find the (also familiar) “Preferences” folder which contains a property list, the contents of which are mostly mundane (though we do have application launch counts and dates which may be of interest in some situations). More interesting is the “Private Documents” folder and the files and folders which are contained within it.

In the root of the Private Documents folder is a binary property list file named “notebookList”. It is a ‘NSKeyedArchiver’ plist, which means, as we discussed in a previous blog, it needs some additional processing in order for us to see the actual structure of the data. Luckily I had PIP and the “ccl_bplist” Python module to hand, both of which can perform that transformation. With the data structure untangled I proceeded with digging around to see what, if anything, we could extract from the “notebookList”.

Among some less interesting data, the root object contains a list of the notebook objects which are stored by the device, under the “notebooks” key.

notebookList in PIP

notebookList in PIP

Each of the notebook objects (which are represented by dictionaries in the property list) contain the keys: ‘name’, ‘title’, ‘pageNames’, ‘created’, ‘modified’,  ‘changeCount’, ‘blankPages’, ‘creatingDeviceId’, ‘editingPageName’, ‘pageDataIsCooked’, ‘versionMajor’, ‘versionMinor’, ‘pagePaperStyles’, ‘paperStyle’, ‘imported’ , ‘coverColor’, ‘originalName’.

The first few there are of immediate interest: the value of “title” does indeed contain the title of the notebooks that I created during my testing and the “created” and “modified” timestamps also ring true. The values of the “name” keys are familiar as well, albeit for a different reason; in my test data we see the “name” values “DD47D226-0CB3-460F-A0F9-3A7E2A795B3D” and “23FDA4FF-CE5E-4353-8D9A-B0C3E3E8AAE7” – matching the directory names that were extracted underneath the “notebooks” folder (see above). Beyond this, the “pageName” key contains a list of values which also match the names of files in each of the “name” directories.

So, with the “notebookList” file we have some useful metadata and a helpful guide to how the other files are organised, but there’s still no sign of the content of the notes themselves. Delving deeper into the folder structure, our next stop is one of the files which was named in the “pageName” list mentioned above.

Opening one of the “page” files we find another “NSKeyedArchiver” property list. After unravelling the structure of the file we find a top-level object containing further metadata (including a “blankDate” which appears to match the “created” timestamp reported in the “notebookList” and the dimensions of the note) along with a list of “layers”. Each of the “layer” objects (again represented by dictionaries) have keys for the layer’s colour (more on that later) the layer’s dimensions and a list of “layerRects” – sections of the layer where the user has drawn their notes; and that’s where we finally find the image itself.

Sort of.

Structure of the page object

Structure of the page object

Each of the “layerRects” objects are represented by (and this shouldn’t be a surprise by now) a dictionary. There are two keys: firstly “rect” which contains a string of two sets of “x,y” co-ordinates: the bounds of this layerRect on the page. The second key is “values” which requires a little extra explanation. As noted in my previous post on NSKeyedArchiver files, their function is to represent a serialisation of objects; the object under the “values” key is a “CBMutableFloatArray” which is programmer talk for a list of floating-point numbers. With this in mind we quite reasonably expect to see just that – a list of floating point numbers; but no, instead we get a data field containing binary data! As nothing else in this data had been straight-forward this was disappointing, but by this point didn’t surprise me. Floating-point numbers (like any numerical data) can be represented quite happily in binary, so I set about trying to turn the binary data into a list of floating-point numbers. I extracted one of these data fields and with a nice Python one-liner did just that:

>>> struct.unpack("<18f", data)
(282.0, 589.0, 5.506037712097168, 281.8666687011719, 588.2999877929688, 5.506037712097168, 281.73333740234375, 587.5999755859375, 5.506037712097168, 281.5999755859375, 586.9000244140625, 5.506037712097168, 281.4666442871094, 586.2000122070312, 5.506037712097168, 281.33331298828125, 585.5, 5.506037712097168)

So now we can see the numbers, but what did they mean? The meaning becomes clearer if we group them into threes:

282.0, 589.0, 5.506037712097168
281.8666687011719, 588.2999877929688, 5.506037712097168
281.73333740234375, 587.5999755859375, 5.506037712097168
281.5999755859375, 586.9000244140625, 5.506037712097168
281.4666442871094, 586.2000122070312, 5.506037712097168
281.33331298828125, 585.5, 5.506037712097168

What we have here is sets of x-y co-ordinates and another value (the meaning of which will become clearer later). So, here, finally is our drawing; stored as a list of co-ordinates rather than any conventional graphics format – the combination of the points in the “layerRects” in each of the layer objects gives you the full picture.

But how to present this data? A list of co-ordinates like this is of little to no use; we want to see the image itself. So I got to thinking: how does the application treat these co-ordinates? Well, when the user draws in the application they are essentially ‘painting’: moving a circular ‘brush’ around the screen making up the lines in the drawing, so if I was able to plot a circle at each of these co-ordinates perhaps I would see the picture? This thought process also gave me an idea as to what the third value in each of the co-ordinate groupings might represent: part of what makes the drawings look natural is that the “line” that is drawn is not of a uniform width, it grows and shrinks with the speed at which the finger or stylus moves, giving an impression of weight – perhaps the final value related to this?

So how to plot these co-ordinates? First of all I looked at various Python imaging libraries (PIL and PyGame both came on my radar), but there were issues with both (especially with PIL which still lacks a proper Py3k port) so I turned my attention to an alternative solution: SVG. SVG (Scalable Vector Graphics) is a graphics format specified by the W3C; it uses XML to describe 2D graphics. Because SVG just uses XML, no imaging libraries would be required; I could simply generate textual mark-up describing where each of my circular points should be plotted on the screen. Taking the data above extracted above as an example, the mark-up would be along the lines of:

<!DOCTYPE svg>
<svg height="865" version="1.1" viewBox="0 0 718 865" 
     width="718" xmlns="">
    <circle cx="282.0" cy="589.0" 
            fill="#000000" r="5.506037712097168"/>
    <circle cx="281.8666687011719" cy="588.2999877929688" 
            fill="#000000" r="5.506037712097168"/>
    <circle cx="281.73333740234375" cy="587.5999755859375" 
            fill="#000000" r="5.506037712097168"/>
    <circle cx="281.5999755859375" cy="281.5999755859375" 
            fill="#000000" r="5.506037712097168"/>
    <circle cx="281.4666442871094" cy="586.2000122070312" 
            fill="#000000" r="5.506037712097168"/>
    <circle cx="281.33331298828125" cy="585.5" 
            fill="#000000" r="5.506037712097168"/>

Each “circle” tag has an x and y co-ordinate (“cx” and “cy”) a fill colour (here expressed as an html colour code – black in this case) and a radius (“r”). Running some tests gave some good output; but things weren’t quite right, firstly, and most importantly, the image was mirrored in the y-axis, presumably caused by a difference of opinion between Penultimate and SVG as to where the y-axis originates, an easy fix (just subtract the ‘y’ value from the height of the image and use that value instead). Also, the lines in the writing all looked very chubby, making writing very tricky to read. Theorising that this was caused by Penultimate storing diameters and SVG requiring radii, I halved the value which improved things, but comparing the output with what I could see on the screen things still weren’t quite looking right so on a whim I halved the value again which made things look right (I’m not entirely sure why it should be the case that you have to quarter the value – it may be to do with penultimate adding a ‘feathered’ fade to the brush which increases it’s diameter though).

I created a proof-of-concept Python script to check that my thinking was correct and I was pleased to see that the output now matched what I could see on the iPad’s screen, save for the fact that the iPad was in glorious Technicolor and my script’s output was monochrome. I mentioned previously that the “layer” objects contained colour information under the unsurprisingly named “color” key.

The object stored in the “color” key has values for red, blue and green – each one a value between 0 and 1. Those readers who have had even the briefest dalliance with graphic manipulation programs will be familiar with colour-sliders: combining red, green and blue in different proportions in order to generate different colours, which is what these values represented. My SVG generated output was working with HTML colour codes which are made up of 3 bytes, each representing an amount of red, green and blue, this time using values from 0x00 to 0x0FF, to get colour into my output, all I had to do is multiply 0xFF by the correct value from the “layer” object’s colour fields and recombine those values into an HTML colour code. I modified my script and now the output reflected both the form and colour displayed by the App on the iPad.

Comparison between iPad and script output 1

Comparison between iPad and script output (1)

Comparison between iPad and script output 2

Comparison between iPad and script output (2)

Working on extracting data from Penultimate was a particularly enjoyable experience as it required a combination of a number of different concepts and led to the use of a number of different technologies to create a solution to automate the extraction of the data, which when it all boiled down was satisfyingly simple.

And as to the question: when is a picture not a picture? Well, quite simply: when it’s a series of serialised floating-point co-ordinate triplets representing points on a page, broken up into rectangles on a layer on a page which is stored in a NSKeyedArchiver property list file (obviously!).

If you have any questions, comments or queries regarding this post, as always you can contact us by dropping an email to or by leaving a comment below.

Update: As requested I’ve uploaded the script for research purposes. You can find it here: 

Alex Caithness, CCL Forensics

Cell site blog: ‘consistent’ data, or data ‘not inconsistent’

By Dr Iain Brodie, Senior Cell Site Expert

As cell site experts we are often asked to consider whether cell site data is ‘consistent’ with a specific scenario, in the knowledge that our words can have a significant impact on how a jury thinks.

For example, a typical question put to us might be:  is the data for a particular mobile phone ‘consistent’ with it having been at the scene of a particular incident which occurred, say, in the centre of Birmingham at 12:00 on a particular day?

If the cell site data for the phone shows that it connected via a cell site in the centre of Birmingham which serves the scene at 12:00, then in my opinion it is clear that the data is consistent with the phone having been at the scene. This does not mean that I think the phone necessarily WAS at the scene, as the cell ID used will cover an extended area and, of course, locations that are not the scene. Given the unpredictable ways in which phones are used, however – what data there is supports the contention that the phone was at the scene.

The situation is equally clear cut if, at 12:00, the phone connected via a cell in central London. It is physically impossible for the phone to have connected to a cell in London whilst located in Birmingham, so (if the records from the network are correct) such data would be in conflict with or inconsistent with the phone having been in central Birmingham at 12:00.

If, at 12:00 and 12:01 say, the phone connected via cells in central Coventry, the scenario is slightly different. It is not, under all circumstances, physically impossible for the phone to have connected to a cell in Coventry whilst located in Birmingham. But in all normal circumstances – given the huge number of other more likely cells in Birmingham for the phone to have used, I would still say that this data was in conflict with the phone having been in central Birmingham at 12:00. Such an opinion could be reinforced by carrying out further work if required, but in general such further work would not be required.

But imagine the data was less clear cut. For example, now my phone’s call data records show a cell site in Coventry connected to by the phone at 11:00, a cell site in Solihull at 11:30, a cell site in eastern Birmingham at 11:45 and a cell site in Wolverhampton connected to at 12:30.

In my opinion this data is again ‘consistent’ with the phone having been at the central Birmingham scene at 12:00, as the logical journey of the phone would have been close to the scene. Indeed there are not many plausible routes other than the phone passing close to the scene at 12:00 that could generate such data – although again, I do not believe the data means that the phone definitely was at the scene (and nowhere else) at 12:00.

If, however, the call data for the cell in Wolverhampton was not so. All we would have was call data consistent with movement of a phone towards the centre of Birmingham, but even less evidence that the phone was in the centre of Birmingham. Such a scenario presents quite a grey area for evidence of opinion. Some experts may say the data is still consistent with the phone being in the centre of Birmingham at 12:00, whilst it may be argued that there is, in fact, NO data consistent with the phone being in the centre of Birmingham at 12:00.

I would say that the data is consistent with the phone having travelled towards the centre of Birmingham in the times leading up to 12:00, although there is no data showing it had been used in central Birmingham.

A final scenario would be where the phone connected to a cell site in Coventry at 11:00 and again to the same cell site in Coventry at 12:45. In this scenario it is quite POSSIBLE that the phone had time to travel to the centre of Birmingham and back, but there is no data that would lead me to expect that this had been the case. Here I would use the phrase ‘the data is ‘not inconsistent’ with the phone having been in the centre of Birmingham at 12:00 but there was no data indicating it had done so’.

This may seem like semantics. However, in a case where I gave evidence for the defence earlier this year (in Birmingham Crown Court as it happens), the prosecution expert asserted that there was cell site evidence ‘consistent’ with the defendant’s phone having been travelling away from a location of a crime at a particular time, when the cell site used for all of the relevant calls provided service at his home address. The prosecution expert’s use of the word ‘consistent’ here was challenged and the challenge was accepted by the court.

The judge, Justice John Royce in summing up said:

‘although the data is not in conflict with such a theory <that the defendant was at the relevant scene>.  The data <for the time in question.> is not consistent with being at the site.  It could possibly be that the phone was en route however from the site to the defendant’s home…’

the prosecution has been driven to trying to construct theories because of the absence of solid evidence.  They have tried to make bricks with but a few straws, and have done so with admirable skill and ingenuity.  But is this sufficient evidence to be left to the jury?  Could a jury, on this evidence, properly directed, safely convict?  The conclusion to which I am driven is that they could not. Accordingly, I shall direct the jury to return not guilty verdicts’

Had the prosecution expert’s semantics not been challenged, the outcome may have been different resulting, possibly, in a miscarriage of justice.

New Epilog Signature files released

Epilog Signature files allow users to add specific support for new databases they encounter and although they are designed so that Epilog’s users can create their own signatures when the need arises, CCL-Forensics are committed to updating and releasing a sets of signatures, pre-written and ready to use.

In this new release we have had a real focus on smartphones adding support for:
• iOS6
• Android 4.0 (Ice Cream Sandwich)
• Android 4.1 (Jelly Bean)
• Android 3rd Party Applications
• iOS 3rd Party Applications
• Skype

We always welcome suggestions for signatures that you’d like to see added to the signature collection so please get in touch on

For more information on epilog please visit our website –

Chrome Session and Tabs Files (and the puzzle of the pickle)

In this blog post Alex Caithness investigates the file format and contents of Chrome’s “Current Tabs”, “Current Session”, “Last Tabs” and “Last Session” files and discovers that, even with the original source code at your side, you can still end up getting yourself into a Pickle.

A link to a Python script for automating the process can be found at the end of the post.

I’ve been on a bit of a browser artefacts kick as of late, digging around both on desktop and mobile platforms for stuff I haven’t tackled before. Taking a peek in my preferred browser’s (Chrome) “AppData” folder revealed that the ubiquitous-ness of SQLite as a storage format means that inspecting the data for a lot of artefacts has been made pretty simple. I had also recently tackled the Chromium web-cache format for another project (the format is now also used both on Android and RIM Playbooks) and, with the pain that caused me still fresh in my mind I had no desire to revisit it. There were, however, four likely looking candidates for a quick probing in the form of the “Current Tabs”, “Current Session”, “Last Tabs” and “Last Session” files.

Chrome AppData Folder

Hello there…

Broadly speaking, these files store the state of the opened tabs, their back-forward lists and the sites displayed therein. The files can be used by Chrome to restore your previous browsing session when you restart the browser (if that’s how you have it set up) or in the event of a crash. It turns out that these files can contain some really rich data, but first you had to do battle with the file format…

In previous posts I’ve made mention of the usefulness of having access to the source code that governs the format in which the data is to be stored, and as Chrome is open source I was heartened. “This shouldn’t be too tricky,” I thought to myself as I set about finding the ‘few lines of code’ which would unlock the file’s secrets… Let me tell you now: the Chrome source is a sprawling behemoth and my journey across the codebase (and on one occasion, outside of it) was long and arduous, and, when it comes down to it, it all boils down to understanding the ‘Pickle’…

Header of the Session file

The file header

The file header was easy to track down, I headed over to the definition for session_backend (src/chrome/browser/sessions/ where we confirm that “SNSS” is simply a file signature followed by a 32bit integer giving the version of the file, which, at the time of writing, should always be 1 (all data is stored little-endian). Also in this file we encounter a method named “AppendCommandsToFile” which appears to be responsible for writing the details into the files. The method describes that for each record, a 16-bit integer is written to the file giving the size in bytes of the record (not including this value), followed by an 8-bit “id” (which appears to relate to the ‘type’ of the record) and the contents of the “SessionCommand”.

Record structure overview

Record structure overview

So now I knew what the overview of the structure in the file was: a nice simple size, contents, size, contents, size, contents… etc. file format, with the records written sequentially, one after another. But I still had no information about the structure of those contents. SessionBackend was operating with a SessionComand object so I tracked down the source code describing this object (src/chrome/browser/sessions/session_command.h) but was disappointed to find the following explanation in the source code’s comments:

“SessionCommand contains a command id and arbitrary chunk of data. The id and chunk of data are specific to the service creating them.”

OK, so the information I wanted isn’t going to be here, but the comments go on to say:

“Both TabRestoreService and SessionService use SessionCommands to represent state on disk”

Aha! So although I hadn’t quite found what I was looking for here, I have found a useful signpost pointing in the right direction. Now, neither “TabRestoreService“ (src/chrome/browser/sessions/tab_restore_service.h) nor “SessionService” (src/chrome/browser/sessions/session_service.h) themselves give us the information we’re after, but both of them ‘inherit’ from a common base class called “BaseSessionService” (src/chrome/browser/sessions/ (I gave a brief overview of object oriented principals including inheritance in a previous blog post)  and it is in BaseSessionService where we finally get what we’re after…

BaseSessionService contains a method called “CreateUpdateTabNavigationCommand” which is responsible for writing that “arbitrary chunk of data” into the SessionCommand which eventually gets written to disk. The record starts with a 32 bit integer which gives the length of the data (this is in addition to the length value outside the SessionCommand). The rest of the SessionCommand’s contents structure is described in the table below.

SessionCommand serialisation

SessionCommand structure

Data type Meaning
32 bit Integer Tab ID
32 bit Integer Index in this tab’s back-forward list
ASCII String (32 bit Integer giving the length of the string in characters followed by an ASCII string of that length) Page URL
UTF-16 String (32 bit Integer giving the length of the string in characters followed by a UTF-16 string of that length) Page Title
Byte string (32 bit Integer giving the length of the string in bytes followed by a byte string of that length) “State” (A data structure provided by the WebKit engine describing the current state of the page. We will look at it in detail later)
32 bit Integer Transition type (explained below)
32 bit Integer 1 if the page has POST data, otherwise 0
ASCII String (see above) Referrer URL
32 bit Integer Referrer’s Policy
ASCII String Original Request URL (for example if a redirect took place)
32 bit Integer 1 if the user-agent was overridden, otherwise 0

As SessionCommands contents can be populated by other means, not every Session command contains data formatted as shown above. During testing it was shown that it is the SessionCommand’s 8-bit ID which identifies whether the record contains this kind of data (when the ID was 1 or 6 then this data format was found). Those with other IDs were typically much shorter (usually around16-32 bytes in length) and did not appear to contain information which was of so much interest.

There are a few fields in the table above which are worth taking a closer look at; the “State” field we’ll explore in detail later as it’s a complicated one. The “Transition type” is a little easier to explain; this field tells Chrome how the page was arrived at. The field will be an integer number, the meaning of which is described in the tables below. The value is essentially split into two sections: the least significant 8-bits of the integer give a type of transition and the most-significant 24-bits form a bit-mask which gives other details. These details are gathered from page_transition_types (content/public/common/page_transition_types.h).

Least Significant 8-bits Value Meaning
0 User arrived at this page by clicking a link on another page
1 User typed URL into the Omnibar, or clicked a suggested URL in the Omnibar
2 User arrived at page through a  bookmark or similar (eg. “most visited” suggestions on a new tab)
3 Automatic navigation within a sub frame (eg an embedded ad)
4 Manual navigation in a sub frame
5 User selected suggestion from Omnibar (ie. typed part of an address or search term then selected a suggestion which was not a URL)
6 Start page (or specified as a command line argument)
7 User arrived at this page as a result of submitting a form
8 Page was reloaded; either by clicking the refresh button, hitting F5 or hitting enter in the address bar. Also given this transition type if the tab was opened as a result of restoring a previous session.
9 Generated as a result of a keyword search, not using the default search provider (for example using tab-to-search on Wikipedia). Additionally a transition of type 10 (see below) may also be generated for the url: http:// + keyword
10 See above
Bit mask Meaning
0x01000000 User used the back or forward buttons to arrive at this page
0x02000000 User used the address bar to trigger this navigation
0x04000000 User is navigating to the homepage
0x10000000 The beginning of a navigation chain
0x20000000 Last transition in a redirect chain
0x40000000 Transition was a client-side redirect (eg. caused by JavaScript or a meta-tag redirect)
0x80000000 Transition was a server-side redirect (ie a redirect specified in the HTTP response header)

NB during testing, although the transition types looked correct in the “Current Session” and “Last Session” files, in the “Current Tabs” and “Last Tabs” files the transition type was always recorded as type 8 (Reloaded page).

When it comes to the record structure, there is still a little more to the story, and yes, this is where the Pickles come in.

This data structure is not being written directly to a file, but rather to what Chrome calls a “Pickle” (src/base/pickle.h). A Pickle is a sort of ‘managed buffer’; a way for Chrome to write (and read) a bunch of values, like those in the tables above, into an area of memory in a controlled way. Indeed, the “length-value” structure we see with the strings is down to the way Pickles write strings into memory, as is the, apparently superfluous, extra ‘length’ field at the start of the record structure. One other pickle-related side-effect which isn’t necessarily immediately obvious when you look at the data in a hex editor is that pickles will always write data so it is uint32-aligned. This means that data will always occupy blocks of 4 bytes and if needed (such as in the case of strings) will be padded to ensure that the next data begins at the start of the next 4-byte block.

It turns out that the contents of the mysterious “State” field are also governed by a Pickle. This field contains serialised data from the WebKit engine. The data is held in a “NavigationEntry” (content/public/browser/navigation_entry.h) “content state” field, but is originally populated by glue_serialize  (webkit/glue/ It duplicates some of the data that we have already described from the outer record, but also contains some more detailed information regarding the state of the page, not least the contents of any forms on the page. The code describing the serialisation process is found in glue_serialize in the WriteHistoryItem method.

The state byte string begins with a 32 bit Integer giving the length of the rest of the record (this is in addition to the length defined in the outer record structure) and then continues with the “WebHistoryItem” structure shown in the table below:

WebHistoryItem structure

WebHistoryItem structure

Data type Meaning
32 bit Integer Format Version
String (see below) Page URL
String (see below) Original URL (for example if a redirect took place)
String (see below) Page target
String (see below) Page parent
String (see below) Page title
String (see below) Page alternative title
Floating point number (see below) Last visited time
32 bit Integer X scroll offset
32 bit Integer Y scroll offset
32 bit Integer 1 if this is a target item otherwise 0
32 bit Integer Visit count
String (see below) Referrer URL
String Vector (see below) Document state (form data) – explained in more detail below
Floating point number (see below) Page scale factor (Only present if the version field is greater than or equal to 11)
64 bit Integer “Item sequence number” (Only present if the version field is greater than or equal to 9)
64 bit Integer “Document sequence number” (Only present if the version field is greater than or equal to 6)
32 bit Integer 1 if there is a “state object” otherwise 0 (Only present if the version field is greater than or equal to 7)
String (see below) “State Object” (only present if the value above is 1 and the version field is greater than or equal to 7)
Form data (see below) Form data
String (see below) HTTP content type
String (see below) Referrer URL (again, for backwards compatibility apparently)
32 bit Integer Number of sub-items in the field below
WebHistoryItem Vector (see below) A number of sub items (for example embedded frames). Each record has the same structure as this one

That table has a lot of “See below” in it, so let’s get down to explaining some of the subtleties/oddities that this data structure provides.

Strings: strings are actually stored differently to those in the outer record. Despite the fact that the data is still being written into a Pickle, the source code uses a different mechanism to do so. The source code forsakes the Pickle’s built in string serialisation methods (for reasons best known to the Chrome programmers), instead taking a more direct route of writing the length of the string directly, followed by the in-memory representation of the string. Basically, this results in the string fields comprising a 32-bit Integer giving the length of the string followed by a UTF-16 string only, this time the length refers to the length in bytes, not the length in characters. To further confuse matters, if the length is -1 (0xFFFFFFFF) this indicates that the string is not present (or ‘null’ in programming terms) or un-initialised (and therefore empty). There is an exception to this structure: if the version field is 2, where, as the comments in the source code suggest, the format was “broken” and stored the number of characters, this was fixed in version 3 onwards.

String Vector: “Vector” in this case essentially means ‘List’. The vector begins with a 32-bit Integer giving the number of entries in the list which is then followed by that many strings in the format described above. In the data structure above this is used to serialise what is described as the “document state”. In testing this appeared to contain information regarding any form fields that may be present on the page (including hidden fields). The list of strings can be broken up into groups of 3 strings, the first of which gives the name of the form field, the second the type of field and the third the current contents of the field.

Floating Point Numbers: IEEE 754 double-precision floating point numbers are used as a representation, but Pickles do not directly support this data type. Because of this, the code uses the Pickle’s “WriteData” method, passing the internal, in-memory representation of the floating point number into the Pickle. The upshot of using the “WriteData” method is that the 64-bit floating point number is prefaced with a 32-bit integer giving the length of the data (which will always be 8 for a double-precision float).

Form Data: the (slightly convoluted) format for this data serialisation is detailed in the WriteFormData method in glue_serialize, however across testing this data was never populated so I can’t vouch for its contents.

Sub items: this contains further WebHistoryItems for any embedded pages or resources on the page. During testing I saw it used to store details of adverts, Facebook “like” buttons and so on. The structure for these sub items is identical to the structure described in the table (note, however, that unlike the top-level WebHistoryItem they do not begin with a size value).

So that’s the structure of the file – not the most pleasant file format I’ve ever dealt with and, even with the source code on hand, it was a lengthy task. So was it worth it?

Well first the case against: a lot of the data is duplicated in other places, not least the History database (which is SQLite so much nicer to work with), and between the “Current” and “Last” versions of the files you only have information regarding 2 sessions worth of browsing, although, increasingly in today’s “always-on” culture, this could still account for a significant period of browsing. Which brings me to the other significant disappointment for these files – timestamps (or rather the apparent lack of them); of course, this makes perfect sense when you consider what Chrome needs the files for – timestamps simply aren’t required for restoring sessions, all the same, it’d make the file more useful to us if they were there.

But it’s not all doom and gloom (which is lucky, otherwise this blog post would be a bit of a waste of time). Firstly, although we only have 2 sessions worth of browsing live on the system, colleagues have already demonstrated to me that there is plenty of scope for recovering previous examples of the files – especially from volume shadow copies, and the 8-byte long static header means that carving files from unallocated space may be possible (no footer though, so some judgement would need to be made regarding the length of the files). Probably more importantly these files give us access to information which it would be tricky to acquire otherwise (or at the very least another opportunity to recover information which may have been deleted); the form contents are obviously a nice additional source of intelligence, both in terms of user credentials, email addresses and possibly message contents (I was able to recover Facebook chat messages from the form data in the “document state” for example). Also, the presence of the transition types, referrer and requested URL fields means that you can build up detailed browsing behaviour profiles, tracking the movement between sites and tabs.

This is not a file format that I would want to parse by hand again, so to automate the process I have written a Python script which we’re happy to make available to the forensics community. The script is designed both as a command line tool which generates a simple HTML report and a class library in case anyone wishes to integrate it into other tools (or create a different reporting format). You can download the script from

As always, if you have any comments or questions you can get in touch in the comments or by emailing

Alex Caithness

July 2012 cell site blog: The top five (potential!) pitfalls in cell site analysis.

By Nicholas Patrick-Gleed, Cell Site Analyst

This month’s cell site blog takes on a slightly different style.  The team here at CCL-Forensics has been discussing the most common potential pitfalls encountered in the world of cell site evidence, and thought it would be a useful exercise to commit some of them to the blogosphere.  So, rather than focusing on a particular topic, we’ll look at the top five (as we see them) issues which need to be at the forefront when planning and, more importantly, carrying out a cell site investigation.

We’ve touched on some of these in previous blogs, but they form a concise summary of some of the ‘issues’ we have seen experts (almost) experience.

This Month’s Topic: Five things to be wary of in cell site analysis

1. Exhibits without interpretation

When working for the defence, we regularly see prosecution evidence which can best be described as “exhibits without interpretation”.  A good example of this is a series of maps plotted by an intelligence analyst, who has carried out a series of instructions based on some call data records, but presented them without any explanation of what they mean.  This not only causes confusion and delay within the criminal justice system (the defence will, no doubt, ask for the explanation at some point – so it may as well be provided at the outset) but also means that an opportunity could be missed as part of the investigation stage.  Simply ‘blindly’ plotting information on a map is hardly investigative – but we have seen it more than once.  What is the point of an exhibit without context?

From the prosecution’s perspective this is an obvious potential pitfall – as it means that the evidence does not include something which could enhance the prosecution’s case.

There have also been occasions where the defence leaves it until the 11th hour before ‘complaining’ that the person who has produced the exhibit is not an expert – and the judge could rule that the prosecution needs to carry out more expert analysis.

It’s simply not worth chancing these situations.  Moral of the story: produce exhibits which mean something; it makes for a smoother investigation.

2. Who’s who on the call data records?

Cell site is full of idiosyncrasies.  It’s what keeps us experts on our toes.  But there are small variations between networks and circumstances can lead to major confusion.  The best example of this is when you are analysing a call data record, and the person is in contact with someone on the same network.  There are occasions when both parties cell IDs appear on the same CDR – which can immediately confuse things.  Furthermore, and lets use the ‘3’ network as an example here, if an incoming call to the subject phone is unsuccessful, then the cell ID for the person making the call still appears on the CDR.  This is particularly a problem, as the CRD doesn’t differentiate between the A and B phone (in columns) and so this needs to be taken into account.  It’s pretty easy to spot if there’s a day’s worth of cell IDs in London, and one in Edinburgh – but when both parties are geographically close, then vigilance is the watchword.

This is especially the case if the person plotting the calls is not trained in these nuances – as they may easily go unnoticed.

Moral of the story: be thorough.

3. Timely surveys

Networks change and evolve.  Nothing new there, but the sooner the survey is carried out after the incident in question, the better.  It means the results will be more accurate and better reflect what happened.

We previously touched on our use of historic data, which may help to counteract this problem – and this is a benefit of the robust methodology which CCL uses.  But, timeliness is still a big potential pitfall for a number of reasons.

One of the biggest is the evolution of “Everything Everywhere” – or the merger of
T-Mobile and Orange as most people still know it.  This means that “Everything Everywhere” now has many more channels available than each of their competitors – and consolidating cells seems like a sensible thing to do.  If there are two cells covering the same approximate area, it seems only prudent to use just one of them and either deactivate the other, or reallocate it to, say, the new 4G networks, which have been in the news recently.  This clearly impacts on the survey, especially if the cell in question is no longer transmitting.

Moral of the story: Consider the impact of the T-Mobile and Orange merger before surveying.  What are you expecting to see – and what are you expecting NOT to see?

4. Getting the whole picture – not just a small slice

Cell site is all about focusing on a phone’s movements around the time of a crime, right?  Wrong.  Yes, this is often the best place to start, but it can also be vitally important to look at the patterns of usage within the data as a whole, rather than just isolating and concentrating on a small piece of evidence.

There may be no evidence of a phone being in an area of interest at a particular time, but the best advice here it to stop, look around and think.

There may be behaviour patterns, where the time in question shows some deviation from the norm. There may be evidence elsewhere of the use of ‘clean’ and ‘dirty’ phones.  There may be evidence someone ‘casing the joint’ before the crime, which goes against the usual pattern of usage.

One just doesn’t see these when points are blindly plotted on a map.  The solution is to have as much data available as possible at the outset of a cell site assignment (or as much as can be reasonably requested under RIPA).

At the end of the day, it depends on what question you are trying to answer, but the moral of this story is: Don’t just rely on data from the time of the incident.  More complex investigations need more data.

5. Surveying techniques

Quite honestly, this is something of a bugbear of ours, and a topic which we have covered numerous times.  With that in mind, I won’t go into any major detail, but just summarise something which we think all cell site experts should adopt.  (And we’ve had this published in a peer-reviewed journal, so it’s more than just a passing fad!)

Movement is key to getting an accurate overall picture of how a phone interacts with cells.  The concept of ‘dragging’ a cell can be key to determining if a cell provides coverage at a location.  Driving to a location from a number of directions can result in a different cell providing coverage, depending on which direction you arrive from.  This is because the phone has a tendency to “hold onto” a cell, rather than chopping and changing – (to reduce the risk of a dropped call).  Spot samples (i.e. turning up at a location, surveying without moving, and then leaving, is hardly comprehensive).  This is about so much more than simply dotting the i’s and crossing the t’s.

While we’re on the subject, it’s worth touching on tracking frequencies.  Network Operators, typically use two or three 3G frequencies at their cell sites.  When moving geographically, a phone may use a new cell which uses a different frequency than the original one.  This created a potential pitfall when surveying, as the expert needs to be mindful of how many frequencies are available, and ensure the most appropriate survey is therefore carried out.  The moral of this part of the story: remember there is more than one available frequency – and be as thorough as the investigation requires.

I hope you’ve enjoyed our whistle-stop tour through the potential pitfalls of cell site analysis – and as, ever, we’re always keen to hear your thoughts on the matter.  If you would like to discuss any aspect of cell site analysis, please don’t hesitate to drop us a line at

Next month

Next month, Dr Iain Brodie analyses comments made by a judge during a recent case, and highlights what the criminal justice system REALLY wants from cell site experts.

Cell site blog – Never mind the quality, feel the width

Thoughts and observations on how ‘more’ could mean ‘less’ in the presentation of cell site analysis.

By Matthew Tart, Cell Site Analyst

This month – we look at quality over quantity in cell site analysis – with particular emphasis on a recent example where a pile (literally) of maps could easily have left jurors’ heads spinning.  And cost the prosecution a considerable sum.

This month’s topic: Getting the balance right in cell site analysis 

This blog starts with a case we were involved in recently, involving a high profile crime with a number of defendants.  On this occasion we were working for the defence, but this story acts as a useful pointer for the prosecution by illustrating techniques that experts used by the Crown should – and should not – be doing.  We’ll focus on a method used by a large number of cell site analysts (but not ourselves) which is not necessarily robust or stand up to close scrutiny.

Q: What were the details of the case?

A: The prosecution were investigating the probability of a suspect being at a crime scene – a pub in an inner city location.  At the time of the crime, one of the suspects (we were working for that suspect’s defence solicitor in this case) made a phone call.  The call data records showed that this phone call was made on what we’ll call ‘cell A’, which was on a mast near the crime scene – but also near to his home address which was about 500m away.

The suspect’s alibi was that he was at home at the time of the crime and the phone call.

The prosecution’s outsourced expert carried out ‘spot samples’ (i.e. turned up at a location with a piece of equipment) at both the crime scene and the alibi location.  Their report showed a different cell serving at each location.  Cell A was shown as best serving at the crime scene – but not at the alibi location.

Q: So what did we do differently?

A: We carried out a much more extensive survey i.e. a drive survey at the home address and the surrounding area.  This was carried out with regard to the cell of interest (Cell A), and we used multiple pieces of equipment and repeatedly moved in and out of the area.  We found that cell A provided coverage north, south, east and west of both locations (crime and alibi scene), and based upon this, could not distinguish between the mobile phone being at either location.  The evidence was simply not strong enough to suggest one or the other.

Q:  So, were both sides saying something different?

A: Yes and no. Before the court date, the prosecution’s outsourced expert asked for a copy of our defence report, which we provided.  We then discussed the contents with the expert over the phone, who claimed that he wouldn’t expect cell A to provide coverage at the home address.  After looking at our evidence, he admitted that our assertion that the cell served at both addresses was actually the most valid interpretation of the evidence.  This is a worrying admission/u-turn to say the least.  This is despite his evidence not documenting that cell A also serves at that crucial home address.

Q:  The other side claimed that a different cell provided service at the home address.  Did your survey find that cell as well?

A: Yes, but we found four cells which served at the home address.  Cell A, the one the other side claimed – AND two others.

Q: How was this data presented by the prosecution’s expert?

A: In a rather cumbersome, and lengthy fashion, to say the least.  There were a number of suspects, and their report showed the same maps over and over – and over – again.  It showed the locations of interest, calls for varying time periods, and whether the cells used actually covered the locations.  This came to more than 100 (one hundred) maps.  All printed on A3 paper and bound into a daunting, unwieldy piece of physical evidence, which the jury would have to absorb.

I would defy even the most attentive juror to have easily made sense of this massive tome.  Notwithstanding the threatening size of the document, but all the pages were practically the same, or almost identical copies of other similar pages.  You simply wouldn’t be able to take it all in.  Especially as one wouldn’t expect jurors to be familiar with this type of evidence – making it all the more crucial to have it presented in a friendly form.

Q: What would we have done differently?

A: Firstly, not produced a huge weighty un-jury-friendly document. The best way of presenting this evidence (for which we would have had MUCH more survey data, having done more than carry out simple spot samples) would have been a series of two or three detailed maps which can be presented interactively at court with the relevant points being highlighted by the expert in the course of presenting the evidence.  These maps would have covered specifically the period of interest – and would have a secondary, financial, benefit.

By not producing hundreds of maps, we would have saved a considerable amount of time – and therefore cost.  We would estimate that producing this unmanageable number of maps and documents would have potentially cost tens of thousands of pounds. Our approach would almost certainly have been cheaper AND more robust.

Q:  So the lesson here is…

A: …to think about what you need to achieve, and the best way of doing it.  Don’t be held to ransom by an outsourced experts ‘way of doing something’.  Hopefully this example has shown two things.  One, that carrying out spot samples (as we’ve mentioned in previous blogs) may not be the most appropriate way of surveying.  And secondly, that the end product i.e. what the jury see and have to understand, can be something a little more sophisticated than a batch of similar-looking, repetitive – and quite frankly, uninspiring – maps and tables.  Technology has moved on.  So has cell site analysis.  And so has the presentation of evidence in court.

In terms of maps it is quality not quantity that delivers the most impactive conclusions in relation to the possible locations of a mobile phone.

For more information about this – or any aspect of cell site analysis, please contact Matthew Tart (or any of our other cell site analysts) on 01789 261200 or by emailing

Parsing Apple System Log (ASL) files on iOS and OSX for Fun and Evidence (and a Python script to do it for you)

(If you’re dying to get stuck in and are only after the links to the Python scripts, they can be found at the bottom of the post!)

After every update to iOS I like to take a file system dump of one of our test iDevices and have a poke around to see what’s changed and what’s new. Recently, on one of my excursions around the iOS file system, I came across something that looked promising that I hadn’t dug into before: a bunch of files with the “.asl” extension which were located on the data partition in “log/DiagnosticMessages”. There were lots of them too –each with a file name referring to a particular date – they went back months!

DiagnosticMessages file listing

Log Files!

“Loads of lovely log files!” I thought to myself as I excitedly dropped one of the files into my current text editor of choice (Notepad++ if you’re interested) only to be disappointed by what was clearly a binary file format.

ASLDB File in a text editor


So I headed over to Google and entered some hopeful sounding search queries and came across a very useful blog post ( which described the role of ASL files on OSX and listed some ways for accessing the logs from within OSX, but I was interested in gaining a better understanding of the file format (besides, the nearest Mac to me was on a different floor!).

A little more digging revealed that the code that governed the ASL logging, and the files it generated were part of the Open Source section of OSX, as a result I was able to view the code that was actually responsible for creating the file – my luck was looking up!

The two files I was particularly interested in were “asl.h” (most recent version at time of posting: and “asl_file.h” (most recent version at time of posting: C header files are great; basically, their purpose is to define the data structures that are subsequently used in the functional code, so when it comes to understanding file formats, quite often they’ll tell you all you need to know without having to try and follow the flow of the actual program. Better yet, these files were pretty well commented. I know that not everyone reading this is going to want to read through a bunch of C code, so I’ll summarise the file format below (all numeric data is big endian):

First, the file Header:

Offset Length Data Type Description
0 12 String “ASL DB” followed by 6 bytes of 0x00
12 4 32bit Integer File version (current version is: 2)
16 8 64bit Integer File offset for the  first record in the file
24 8 64bit Integer Unix seconds timestamp, appears to be a file creation time
32 4 32bit Integer String cache size (not 100% sure what this refers to, may be maximum size for string entries in the records)
36 8 64bit Integer File offset for the last record in the file
44 36 Padding Should all be 0x00 bytes

So nothing too ominous there, although all of those pad-bytes at the end of the header suggest redundancy in the file spec in case apple ever fancy changing something. Indeed the fact that the header tells us that we’re on version 2 of the file format suggests that this has already happened.

The records in the file are arranged in a “doubly linked list”, that is, that every record in the file contains a reference (ie. the file offset of) the next and previous records.  From a high level, the records themselves are made up of a fixed length data section, followed by a variable length section which allows the storage of additional data in a key-value type structure, finally followed by the offset of the previous record. The table below explains the structure in detail.

NB: The string storage mechanism the records use is a little bit…interesting – I’ll explain in detail later in this post, but for now if you see a reference to an “ASL String”, I mean one of these “interesting” strings!

Offset Length Data Type Description
0 2 Padding 0x00 0x00
2 4 32bit Integer Length of this record (excluding this and the previous field)
6 8 64bit Integer File offset for next record
14 8 64bit Integer Numeric ID for this record
22 8 64bit Integer Record timestamp (as a Unix seconds timestamp)
30 4 32bit Integer Additional nanoseconds for timestamp
34 2 16bit Integer Level (see below)
36 2 16bit Integer Flags
38 4 32bit Integer Process ID that sent the log message
42 4 32bit Integer UID that sent the log message
46 4 32bit Integer GID that sent the log message
50 4 32bit Integer User read access
54 4 32bit Integer Group read access
58 4 32bit Integer Reference PID (for processes under the control of launchd)
62 4 32bit Integer Key-Value count: The total number of keys and values in the key-value storage of the record
66 8 ASL String Host that the sender belongs to (usually the name of the device)
74 8 ASL String Name of the sender (process) which send the log message
82 8 ASL String The sender’s facility
90 8 ASL String Log Message
98 8 ASL String The name of the reference process (for processes under control of launchd)
106 8 ASL String The session of the sender (set by launchd)
114 8 * Key-Value count ASL String[Key-Value count] The key-value storage: A key followed by a value, followed by a key followed by a value… and so on. All keys and values are strings

The level field mentioned above will have a numerical value which refers to the levels shown below:

Level Meaning
0 Emergency
1 Alert
2 Critical
3 Error
4 Warning
5 Notice
6 Info
7 Debug

As mentioned, the “ASL String” data type is a little odd. The ASL fields above take up 8 bytes, if the most significant bit in the 8 bytes is set (ie is 1), the rest of the most significant byte gives the length of the string, which occupies the remaining 7 bytes (unused bytes are set to 0x00). Conversely, if the top bit in the ASL String data type is not set (ie. Is 0) the entire 8 bytes should be interpreted as a 64bit Integer which gives the file offset where the string can be found. The string will be stored thusly:

Offset Length Data Type Meaning
0 2 Padding Padding bytes 0x00 0x01
2 4 32bit Integer String length
6 String length UTF8 String (nul-terminated) The string data

In order to get a better grip of what can be held in these files I decided to create a Python module to read these files and used it to dump out the contents of the ASL files I found on the iPhone.

Running the script

Running the script

Output from the script (iOS)

A snippet of the output produced by processing an iPhone’s ‘DiagnosticMessages’ folder

The first thing that struck me after running the script was the volume of messages: 16161 log messages spanning 10 months – and this was on a test handset which had lay idle for weeks at a time. The second thing was the prevalence of messages sent by the “powerd” daemon, over 87% of the messages had been sent by this process. The vast majority of these messages related to the device waking and sleeping – not through user interaction, but while the device was idle. Most of these “Wake” events occurred 2-5 minute apart, presumably to allow brief data connectivity to receive updates and push messages from apps.

Output from the script (iOS powerd messages)

Some powerd Wake and Sleep messages

The key thing that interested me about these messages was that they also noted the current battery-charge percentage in their text: this is the sort of data that just begs to be graphed, so I knocked up a little script which utilised the parsing module I had just written to extract just this data and present it in a graph-friendly manner.

Graph Friendly powerd Data

Graph Friendly Data

After graphing it (you want to use a scatter graph in Excel for this, not line as I discovered after some shouting at my screen) you are left with a graph which gives you some insight into the device’s use.

iOS Battery Use Graph

Some iPhone Power Usage (click for full-size)

The graph above shows around 3 weeks of battery usage data from the test handset. As noted previously, this test device would lay idle for days at a time (as suggested by the gentle downward gradients) but there were periods when the handset was in use, as shown by the steeper downward gradients on the 26th and 27th of April, which mostly took place within office hours. You can also clear see the points where the device was plugged in to be charged, suggested by the very steep upward gradients. As noted the power messages occur around ever 2-5 minutes, so the resolution is actually fairly good. The exception to this is while the device is plugged in as it no longer needs to sleep to preserve battery charge; typically I only saw an event when charging began and another when the device was unplugged and the battery began to discharge again.

There are a few other messages in the iOS ASL log that look interesting, but at this time I don’t have enough nice control data to make much of them. One thing that did hearten me somewhat was the fact that on the few extractions I’ve had the opportunity to take a look at from later revisions of iOS 5, there did seem to be some extra processes that were logging messages, so it’s my hope that we’ll see more and more useful data make its way into the ASL logs on iOS.

In addition to looking at iOS ASL files, I thought I’d take a look at some from an OSX installation. Pulling the logs from the “var/log/asl” on Lion (10.7.3) and running the parsing script across the whole directory brought back a far more varied selection of messages.

Output from the script (OSX)

Variety is the spice of life.

The number of records returned was actually far less than on iOS, partially due to the iOS “powerd” being so chatty, but more crucially because OSX tidies up its logs on a weekly basis. That’s not to say that you will only recover a week’s worth of logs though – on this test machine I recovered logs spanning 7 months. Rather, OSX has short-term log files (those with file names which begin with a timestamp) which have a shelf-life of a week and long term log files (those with file names which begin with “bb” followed by a timestamp). The “bb” in the long term log’s file name presumably stands for “best before” and the date, which is always in the future, is the date that the file should be cleared out. The short term log files tend to hold more “intimate” entries, often debug messages sent from 3rd party applications; the long term logs err more on the side of system messages. One particularly useful set of messages in the long term log are records pertaining to booting, shutting down, logins and logouts (hibernating, waking and failed logins are recorded too, but they end up in the short-term logs).

(As an aside:  one of my favourite things that I discovered when looking through these logs was the action of waking a laptop running OSX by wiggling a finger on the trackpad is recorded in the logs as a “HID Tickle”. Lovely.)

Like I did with the iOS power profiling, I put together a script which extracted these login and power records and timelines them.

OSX Login and power timeline

Login and power timeline

A couple of things worth noting beyond the basic boot/shutdown/login records: firstly when the device wakes it records why it happened – this can be quite specific: a USB device, the lid of a laptop being opened, the power button being pressed, etc. Secondly, you can see terminal windows (tty) being opened and closed as opening a terminal window involves logging in to a terminal session (OSX does this transparently, but it’s still logged).

We’ve released the scripts mentioned in this post to the community and they can be downloaded from The “ccl_asl” script is both a command line utility for dumping the contents of ASL files as well as a fully featured class module which you can use to write scripts along the lines of the battery profiler and login timeline scripts.

ASL files are, on the one hand, fairly dry system logs, but on the other, with a little work you can harvest some really insightful behavioural intelligence. As always if you have any questions, comments or suggestions you can contact us on or leave a comment below.

Alex Caithness