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!
(This is not an April fools joke, I gather this is probably not the best timing to put this out.)
Many analysts and researchers work with a very limited budget, many of us can’t get those $uper expen$ive commercial mobile acquisition and analysis tools. I’ve been asked many times, “What tools can I use to analyze iOS with $0 in the budget for tools?”
With newer iOS devices that come with newer operating systems, the ease of forensic access to iOS devices has been quite limited. Every commercial tool has the capability to provide a logical dump of the phone (give or take the caveats of access to PIN/Passcodes or the reboot/unlock status of the devices of course!). This data dump may be fine for some analysts but I have found that it doesn’t quite provide me with the data that I’m looking for. I needed to find a different way of doing things.
Whether or not you think this is “forensically sound” or whether your legal policies allow you to do so I want to at least offer this method as a potential capability.
You should absolutely discuss this with the people you need to before you use this method operationally because, among other reasons:
Remember - Documentation is key! Sometimes to get to the files we need we have to Jailbreak - there is really no other way around this problem.
Of course if it is for research and testing – and it’s a device you own – go nuts!
Jailbreaking software is available for most iOS versions/device combinations. At the time of this writing iOS 9.1+ does not have a jailbreak available. One of my favorite sites to determine what jailbreaks are available for a specific device and iOS combination is https://www.theiphonewiki.com/wiki/Jailbreak. New jailbreaks can come out anytime from before an iOS update comes out to months afterwards - there is no guarantee that a jailbreak will even be available when you need it. Sometimes you just have to wait it out.
Popular jailbreaks for iOS 8 and 9 are TaiG and Pangu, available at the links below. Jailbreak instructions can be searched for easily and depends on the jailbreak software you are using.
In preparation for the jailbreak you will need the password for the device as some jailbreaks require you to remove this password. Also as part of jailbreak “best practices” some jailbreaks require the device to be backed up, in airplane mode, Find My iPhone turned off, and without a password. Be sure to read the directions carefully - each one works a little bit different.
A word of warning here - make sure you go to the legitimate link for the jailbreak software, otherwise you might be tricked into paying a fee. (As of this writing, most public jailbreaks are free - we can hope the iOS jailbreak creators continue this trend.)
Once jailbroken, you need to install SSH to make imaging and analysis possible.
Cydia is usually the tool of choice for this process as most jailbreak software includes and installs this application. OpenSSH is the preferred SSH utility for iDevices, find the OpenSSH application and install it.
You may need to “Refresh” the Sources before searching for it. Go to Sources tab in Cydia and Press “Refresh”.
Accessing the device is easy using SSH over WiFi, but when we copy data from the device that could be a bit slow. Instead, we are going to use a tool called iproxy to access the device over USB using the usbmuxd capability. To do this, we are going to install a package called iproxy, part of the libimobiledevice suite of utilities. This installation can be done using brew if you prefer. Please review the additional utilities available, many are very useful!
Connect the iDevice using a USB cable. iproxy creates a usbmuxd (USB) connection from an iDevice to the system by listening to SSH connections and forwarding them to another port. The iproxy usage is as follows:
iproxy LOCAL_TCP_PORT DEVICE_TCP_PORT [UDID]In the screenshot below, I’ve connected my iPhone via USB cable to my system and ran iproxy using ‘4242’ as my local port and ’22’ as the device port (SSH can usually be found port 22).
The next step is to SSH to the iDevice. We do this using the built in SSH client on OS X, one change we need to make is to specify the port we are going to use. In this case I will use port 4242 as configured from iproxy using the ‘-p’ flag. I will be logging in as ‘root’ on 127.0.0.1. I could also login as ‘mobile’, the devices ‘user’ account – by why limit myself! I didn’t jailbreak for nothing! The default password for both ‘root’ and ‘mobile’ accounts is ‘alpine’. I highly recommend changing both passwords immediately if you are going to be using this device continuously for research (use the passwd command).
This will dump the user into their home directory, since I used ‘root’ I am in /var/root.
We could cd to “/” if we wanted to start reviewing files in the file system but we’re here to dump data. (In fact, you don’t have to SSH into the phone at all before you image – it’s really just a test to make sure everything is in working order.) Before we exit out of this SSH session, let’s look at the partitions of this device. We can do this two different ways; using the ‘mount’ command, or by viewing the /etc/fstab file.
There are always at least two partitions that are of forensic interest, a “System” and “Data” partition.
The “System” partition contains the operating system, ideally it should be read-only as shown in the /etc/fstab output (ro). However, since we jailbroke our devices we can actually write to it if we wanted. This partition is on the /dev/disk0s1s1 device and is mounted on “/”.
The “Data” or “User” partition contains the user data files, configurations, and preferences. From a forensic perspective this is our “gold mine”. This partition is on /dev/disk0s1s2 device and is mounted on “/private/var”. To get to the user’s (mobile) data in the file system in SSH and other tools we have to navigate to /private/var/mobile/.
We have a few options here to make depending on the type of data we want. We can make a full dd-style image of the whole disk (or each partition separately) OR we can get a tar bundle of files (per disk or per partition).
One item to be aware of here – encryption.
*A note about unallocated space in iDevice – Due flash disks and how Data Protection works, even if you grab the unallocated space on an iDevice, there will likely not be much data available to carve or view in an unencrypted format.)
What I normally do is create a dd-style dump of System partition, and a tar bundle of the Data/User partition.
Let’s first create a DD image of our System partition. (If you are following along, be sure to exit out of your SSH session with your device.) The command below will use SSH to connect to the device (using the specific port, in my case I chose 4242). It will ask for the device’s password, and immediately start imaging the System partition using the dd utility on the device.
We have provided it the input file (if=) /dev/rdisk0s1s1. We are using the rdisk here as we don’t have permission to access the active disk on /dev/disk0. We are using a block size (bs=) of 4k or 4096 bytes. Finally, using the pipe “|” we can output the image to our host systems ‘dd’ utility to an output file (of=) called system.dd.
ssh root@127.0.0.1 -p 4242 dd if=/dev/rdisk0s1s1 bs=4k | dd of=system.dd
This will dump the file into your current working directory. The prompt will not update, however you should be able to see that the system.dd is growing in size. This should only take a few minutes. For my iOS 9.0.2 device the System partition was just over 3G in size.
We can check to make sure we have an HFS+ image by running the following command. Using dd we are going to look at the third sector on the disk. We skipped the first two (by design, they are blank) to look at the HFS+ Volume Header in the 3rd one.
dd if=system.dd skip=2 count=1 | xxdThe “HX” in the first two bytes, followed by “HFSJ” show us that this is a Journaled HFS+ (Case sensitive) partition.
Now let’s get to the Data/User partition. We going to use nearly the same command, except we are going to change a few items. We will be using the tar command to place the logical files into a tarball. We are specifically going to grab only the files in the /private/var directory. (We could do the whole drive here from ‘/’, but we already captured the system partition using the previous command. Again, this is user preference.) Finally, we will redirect the output of this to a user.tar file on our local systems. Depending on the allocated data on the user space on the device this could take a considerable amount of time!
ssh root@127.0.0.1 -p 4242 ‘tar -cf - /private/var/' > user.tar
Once you have the data dump, you can analyze in the tool of your choice or extract the tarball into a read-only disk such as a DMG for easier analysis/transport.
For my uses I extracted the tarball into a directory using the following command. (Note: Some forensic analysis software may allow you to use this tar file as is, some do not.)
tar -xvpf user.tar -C user_untar/Time to poke around! Have fun!
This week I had the privilege of presenting an updated version of my "Analysis and Correlation of Mac Logs" talk at the CTIN Conference.
The updated slides have been uploaded to my presentation area on GitHub.
Note: Some content from the older presentation is still valid, however due to timing I had to cut out some slides, therefore both presentations are still available.
I have added some output options to the script – CSV and KML.
See a related post here - "Parsing iOS Frequent Locations"
The script can now be called with a ‘-output’ argument with the following options:
Note: The verbose script output is still available from standard output.
python dump_freq_locs.py –output e <StateModel#.plist>
Updated script (v1.1) is available in GitHub
Example of the CSV output in Excel
Example of the KML output in Google Earth
Example of the KML output in Google ‘My Maps’
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.
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.
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.
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:
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.
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.
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:
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