xcode

Part 1: Step-by-step macOS Setup for iOS Research (via @bizzybarney)

in , ,

CLI…WTF

Command line interface (CLI) isn’t for everyone.  Trust me; I get it.  @iamevltwin forced me out of my comfort zone a few years ago and opened my eyes to the power of Terminal (command prompt on Mac).  Now it is pinned to the Dock on every Mac I use, but I still struggle at times and that is okay!  The internet provides plenty of support to help me along when I just can’t make something work.  I use and abuse my Notes application with random commands and ways to accomplish certain tasks in Terminal that I know I will want to recall sometime in the future.  Inevitably though, I find my way back to mac4n6.com to read an article because I am cussing at an iPhone I’m struggling to jailbreak because I forget if the port is 22 or 44.  

I recently bought a new MacBook Pro and the thing is a beast, but as soon as Apple setup was completed I started installing things to set it up for mobile testing.  I figured I would write a set of current instructions on how I setup my Mac, and do so in a way that someone unfamiliar with Terminal can follow along without issues.

DISCLAIMER.  Following these instructions worked for me and will work for you too.  As with anything else, proceed at your own risk but nothing we are doing here is dangerous for your machine if done correctly.  I tried to bold exactly the text you need to type or to highlight a key combination you need to press to grab your eye as you scan this article.

1. Terminal (CLI)

What:

We are going to use it but you don’t have to understand everything we are doing to still achieve the desired outcome.  To find Terminal, hold ‘command+space bar’ and Spotlight Search will appear on your Mac’s screen.  Type ‘terminal’ and select the application from the results.  I choose to pin it in my dock because I use it every day, you might want to do the same.

How: 

  1. Hold command key and press space bar

  2. In Spotlight search type ‘terminal’ 

  3. Select Terminal application and it will open

  4. Right click Terminal in your Dock, mouse up to Options and over to ‘Keep in Dock’ and select it.

2. Xcode

What:

Xcode is Apple’s development platform, and pieces of it are used in regular forensics work on iOS and Mac data.  This takes a while depending on your download speeds, so this might be a good place to grab a drink.  

How: 

  1. Open the App Store on your Mac and search for Xcode.  Download.

3. Homebrew

What:

I am a huge fan of craft beer, so perhaps I appreciate the naming convention here more than others.  Regardless of whether you like craft beer or are yet to learn that you love craft beer 🍻 - you need to install Homebrew to install some stuff Apple doesn’t install for you. 

How: 

  1. In a web browser, go to brew.sh  (DO NOT GO TO homebrew.sh, that is a super sketchy place and is not where you want to be)

  2. When the page opens, look directly under “Install Homebrew”, and copy the entire line: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Paste that into a Terminal window and press ‘return’ key.  (If you are asked for a password, it is the user password you enter to access the machine so you need to be an admin!  Also when you type your password nothing shows up on the screen, you aren’t crazy.) 

It tells you what the script will install, and you need to press ‘return’ again to install which will take a few minutes.

4. DB Browser for SQLite

What: 

My preferred SQLite database browser for everyday database research and analysis.  As with Terminal, I keep this one in the Dock of my Mac also

How: 

  1. Simply go to sqlitebrowser.org/dl/ and download and install the appropriate version. 

OR

Homebrew Install Method: You will notice on the download page that Homebrew is listed there with a command to install the application via Homebrew.  Since we already installed Homebrew, you can take a look at how it works by using it to install DB Browser for SQLite!

If you choose to install via Homebrew:

  1. In Terminal, type the following and press ‘return’ - brew cask install db-browser-for-sqlite

5. Hex Fiend

What:

Free hex viewer, and I love it.  I drag and drop files into the application to quickly check file contents every day I’m doing research.  This one also stays in the Dock.

How

  1. Simply go to ridiculousfish.com/hexfiend and download and install.  

OR…I wonder if Homebrew can do this for me?

Homebrew Install Method: 

To check if homebrew has the ability to install a certain utility, you can just type brew search hexfiend and press return

The results tell me there is a Cask named ‘hex-fiend’ so I can install via Homebrew just like we did before.

  1. In Terminal, type the following and press ‘return’ - brew cask install hex-fiend

6. libimobiledevice

What:

We will use the “iproxy” utility, which enables TCP service access to an iDevice.  It allows us to forward ‘localhost’ to the device, thus allowing an SSH connection over USB to jailbroken devices.  If you don’t know what TCP, SSH or ‘localhost’ means - don’t quit here.  Once this is setup and your iDevice is jailbroken, you simply need to type a few things in Terminal and boom!  You’re surfing the file system of a live iDevice!

How:

  1. In Terminal, type brew search libimobiledevice

  2. The results show us ‘libimobiledevice’ is available, so type brew install libimobiledevice and press return

And with that the Mac setup is now complete!  We arranged applications in the Dock for quick access, got Xcode ready to go, setup a SQLite database browser, a hex viewer, and finally the utility we will use to communicate with our iDevice via USB.  But wait..what about my favorite <insert tool name here>?  Personal preference will drive many other installs or setup tweaks, but if you follow these instructions your Mac is ready to do iDevice testing.  

If you successfully followed the instructions above, your iOS testing progress bar is at 51% - congratulations!  Part 2 is coming soon and will visualize and simplify the jailbreak process, getting your iDevice ready for testing.  You will be setup and ready to answer your own questions about the iOS file system, how it behaves, and you can prove or disprove that hunch you have!  

Until next time, “Stay classy, forensicators.”

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