misc

Making it Rain on this Labor Day – Giving Back to the DFIR and Security Communities

in

Discover & share this Money GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

In the spirit of our American holiday Labor Day, where normal people might be watching a parade, barbecuing, and shopping Labor Day deals - I’ve decided to forgo the crowds the mall and give back to the community, monetarily. (BBQ is still fair game.) 

Donating is of those things that can easily be put off, and put off, and put off. Tomorrow's holiday is a perfect day to celebrate the contributions of folks who work on research and software in my communities that I use all the time.

First up is Patrick Wardle’s Objective-See Tools and Blog. I’ve been reading his research and using (and recommending) his tools for years. His Patreon site is here. Uniquely, his Patreon donators can attend his new Objective by the Sea Mac security conference in Maui for free (as if you need more excuses)! I’m really stoked to be able to attend and speak there myself!

Next is a tool that I’ve come to love and use daily, DB Browser for SQLite. Doing mainly Mac and mobile forensics (yes, I do Android too! Shh, don’t tell anyone, it’ll ruin my Apple street cred), I use this seriously every single day. I appreciate that its multi-platform and really allows me to dig into SQLite databases. The tool has really improved greatly in the last few years. They recently introduced their Patreon. 

Back to blogs - I decided to throw some Dollarydoos towards my Aussie friend and insane blog aggregator Phill Moore. Phill takes the time each week read and comment on hundreds of blogs and organizes them to give DFIR folk a quick and easy way to catch up with what’s going on in the community on his thisweekin4n6.com blog. He also condenses some of this information in a monthly podcast! His Patreon for his podcast is here.

Finally, I will end on more tools – Jailbreaks! I use all sorts of jailbreaks for forensic research. In no way could I have done much of my current iOS research without the contributions of Meridian and LiberiOS jailbreaks for iOS 10 and 11. I depend on jailbreaks to provide me with full file system access, so I can dive into various databases and third-party app data that isn’t backed up with a normal iTunes backup. These can be forensic gold mines and without jailbreaks those of us in the forensic community likely wouldn’t have a chance to know or capture the data contained within them. Ben Sparks (Meridian) has a donate link on his page. Jonathan Levin (LiberiOS) advertises (upon successful jailbreak) to donating to the charity of your choice using the hashtag #LiberiOS. I chose Girls Who Code.

I encourage everyone who uses something (tool, research, whatever) and appreciates it to give something back – whether it be additional research, donations, a drink, or a simple ‘hey, this really helped me’ kind of message (you’d be surprised the warm fuzzies this can give to a frustrated researcher!). FWIW - I prefer a cool story involving my research/tools alongside a drink.

Discover & share this Mrw GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

 
 

Nominated for the "Digital Forensic Investigator of the Year" Award

in

If you like my blog, my presentations, my class, or my other resources - please consider voting for me in the Forensic 4Cast Awards for "Digital Forensic Investigator of the Year". 

I appreciate your consideration! I promise to keep researching!

https://forensic4cast.com/forensic-4cast-awards/

(This is not an April fools joke, I gather this is probably not the best timing to put this out.)

Manual Analysis of ‘NSKeyedArchiver’ Formatted Plist Files - A Review of the NEW OS X 10.11 “Recent Items”

in , , ,

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

Hello World!

in

I know, cliche right? Welcome! 

I hope to create a useful blog and website to help Mac OS X and iOS forensic examiners stay up-to-date with the latest in Mac forensic research.

I also have an online archive of my conference presentations and a calendar showing where I'll be presenting or teaching SANS FOR518 at any given time.

If you have an OS X topic or an iOS app you would like to see more about, please feel free to email me or use the contact form in the Contact page. I can't promise that I'll blog about it immediately but I'm always looking for suggestions to help us analysts out!