In my iOS Frequent Locations blog post, I mentioned that the locations are stored in a ‘less than analyst friendly’ format. These plist files are in a binary plist format – no different than other binary plists except it is hard to put context to their structure. Rather than directly associated key/value pairs, the keys and values are stored in a seemingly random way.

I noticed that this format is being used more often, especially in iOS device files. The binary plist format is not going away anytime soon! Expect to see them on iOS and OS X systems.

About the NSKeyedArchiver Format

Generally speaking, this format is used to allow developers easier access to their stored data. They can also be used for backward/forward compatibility with their applications. As far as forensic analysis is concerned, think of them as data stored in a serialized tree-based format. We need to start at the base of the tree and work from there to manually put context to these values. The following links describe the NSKeyedArchiver format in greater detail.

The “Ugh Why!?” Moment

As an analyst if you ever open a plist file and are presented the following plist structure, you can be sure there will be groans, expletives, and general signs of discontent coming from the analyst. Analyzing this file will not be as easy as just popping it into your favorite plist viewer and reading keys and values like a “normal” binary plist file.

I was recently reviewing new and changed artifacts on an El Capitan (10.11) system when I came across a drastic change in the “Recent Items” for each user. The file com.apple.recentitems.plist no longer existed in the user’s /Preferences directory. In previous versions, the plist file looked like the example below. Keys and values have context and I can quickly see the last ten applications the user accessed.

In 10.11 this data now uses the NSKeyedArchiver format. The location of this artifact has also changed. These files are now located in ~/Library/Application Support/com.apple.sharedfilelist/ directory.

The file extension has also changed from ‘.plist’ to ‘.sfl’. However, they are still binary plists as shown in the screenshot below - note the file header ‘bplist00’.

Because of the file extension change, just trying to open them in the Xcode plist viewer is challenging. We end up with the following view. (Note: Not all NSKeyedArchiver binary plists will have a custom file extension, some do have the expected ‘.plist’ extension. These should open up as expected in Xcode.)

We could rename all these ‘.sfl’ files as ‘.plist’, open them in Xcode, and review. You will see something like the following screenshot. Notice the keys named $version, $objects, $archiver (with the value of NSKeyedArchiver), and $top. These are the telltale signs you got yourself an NSKeyedArchiver binary plist on your hands. Lucky you!

If we expand the plist a bit more, we can see items of potential interest. We can see application names, file paths, binary blobs - all sorts of good stuff! Unfortunately, there is no context to any of this. It is not guaranteed that keys in sequential order are related in any way.

Xcode isn’t even showing you everything here, a better tool to review these types of files is the command line utility plutil. (Note: Other plist viewers may show you this information without the need to use other utilities, I’m looking at you Blacklight – excellent work!)

In the terminal we will use the command below to dump these files making them easier to analyze. The ‘-p’ flag to plutil prints to standard output in a JSON format. I have also redirected them to an output file rather than standard output so I can review the file easier.

plutil –p <plist_file> > <output_file_here>

The partial output below shows what was missing in the Xcode viewer. Notice the additional information in the ‘1’ key from the Xcode example above. We now can view the ‘NS.keys’ and ‘NS.objects’ along with their values and class types. This is exactly what we need to put context to this data.

Here is a copy of the example output I am using in this article if you would like to follow along.

Analysis Time! Starting at the $top:

The root of these files is the ‘root’ key in $top. Always go here first to find the start of the tree. In the example below the ‘root’ key has a value of ‘1’. This means we start at key ‘1’. Time to scroll to the top of the output file!

Looking at key ‘1’ under ‘$objects’, we see it has two sub keys, ‘NS.keys’ and ‘NS.objects’.

The Keys and Objects are directly related, in the example below, key with value 2 is associated with object value 5, key 3 with object 6, and key 4 with object 10.

Each ‘value’ number is a key within the plist, so for this section we will be looking at keys 2, 3, 4, 5, 6, and 10.

There is also a $class (value ‘9’) listed here – these values describe the type of data contained. In this case we are looking at a ‘NSDictionary’ data type. In many instances, depending on the plist file, you will find proprietary data types. The StateModel files used in the iOS Frequent Locations makes heavy use of these.

Lets look at keys 2, 3, 4. ‘NS.keys’ usually tell us what the key name is:

2 – “version”
3 – “properties”
4 – “items”

Now let’s look at their associated objects, in the 5, 6, and 10 keys. This is usually where the data is stored for each key name above.

2 – “version”
- 5 – “1”
3 – “properties”
- 6 – Another NS.key/NS.object data field. We need to dig further.
4 – “items”
- 10 – A NS.object data field. We need to dig further.

Ok, so we are looking at version 1 of something. We need to keep digging into these nested values to figure what what that something is!

Let’s look into key 3, object 6. We see this has a $class value of 9 (NSDictionary). Enumerating this data gives us a key of 7, with an associated object of 8.

“com.apple.LSSharedFileList.MaxAmount” = “10”

Looks like we have a max file count of 10 for LSSharedFileList recents. This is expected, 10 recent items have been the max amount for years!

Let’s go back and look at key 4, value 10. This is listed as “items”. The 10 key holds ten objects (0-9) with the following values 11, 21, 27, 33, 39, 45, 51, 57, 63, 69. All these have to be enumerated themselves. Let look at the first “item” key 11.

“Item” key 11 has the following data:

"$class” – (Value 20) – “SFListItem”
- One of those “proprietary” data types.
“order” – “-146”
“bookmark” – (Value 18) – A binary BLOB containing the “bookmark” information for the Recent Application.
- Copy this hex out and view it in a hex editor.
“uniqueIdentifier” – (Value 12) – A UUID
“properties” – (Value 19) – An empty NS.key/NS.object dictionary.
- Not populated in this instance.
“URL” – (Value 15) – An “NSURL” data type ($class with value 17).
- If we follow this down using the key 16, we get “file:///Applications/System%20Preferences.app/”.
“name” – (Value 14) – “System Preferences”

We could now go through and enumerate the rest of the “items”, however, I will leave that task to the reader for practice!

You can see that these files can be highly nested with many different data types. Going through these files can be a very manual process which is why I expect to write many scripts parsing these files out when I get the time (or am frustrated enough) to do so.

Each one of these NSKeyedArchiver files is its own special file, no two will be alike which makes parsing these even more difficult. For the scripters out there – I have become very fond of ccl_bplist.py to help in this process.

UPDATE (1/2/15) - Additional blog article and python implementation for SFL files by @mikeymikey