Mac Live Imaging: Functionality Versus Speed

My series on imaging a Mac would not be complete without covering how to do a live acquisition of a Mac. Now that FileVault2 appears to be the default during installs with Sierra, a live image may be very useful moving forward:

If a hard drive is encrypted, a live image will allow you to create a logical image of the partition in an unencrypted state. In my previous posts I covered how to image a Mac using single user mode and a Linux USB boot disk. I've put off doing this blog post because there is a very detailed and well written post by Matt at 505Forensics that covers this topic. In his blog post, Matt walks though step by step how to image a Mac using the FTK Imager command line tool for Mac OS X operating systems. As such, I wanted to cover how to do a live image using the dd command as another option.

Out in the field, I've found that it seems to take a longer time when using FTK Imager. I finally had a chance to do some testing and found that it took FTK Imager almost 2 hours to image a drive to a raw image (no compression). It took just 15 minutes using dd with an MD5. My test system was a MacBook Air, Early 2015, OS X El Capitan with a 75GB partition that was being imaged.

Using FTK command line has some distinct advantages over dd. There are options to compress the image, choose e01 format and supply case information.  However, if time and speed are an issue, dd may be a better option. For example, I've been onsite when 10 Macs needed to be imaged - dd was nice to use so we could finish up in time for dinner. If you can leave an image running overnight  - it's probably not as critical. See below for the test data:

FTK Imager: Total image time 1 hour, 49 min and 04 sec:

dd image with md5: 15 minutes

Please note - this testing is not by any means extensive (unlike the recent testing by Eric Zimmerman on some forensic software). I created several images using both methods and the image times listed above were about the same.

The first step is to run diskutil to see what the disk layout looks like and to determine what to image. I like to do this before I plug in my external USB. This makes it easier to see what drive needs to be imaged.

diskutil list

No FileVault2/No Encryption

My system has both OS X and Windows (Bootcamp) installed. As you can see /dev/disk0 is my physical drive. Partition 2 is the Machintosh HD and Partition 4 is the Windows aka Bootcamp partition. The logical, active device I want to image is /dev/disk1. As you can see in the screenshot above, it is listed as the logical, unencrypted volume and refers back to disk0s2. (If you do run across a system with Bootcamp you will probably want to grab that partition as well, but for the purpose of this blog post I am focusing on the Mac partition)

Below is a screen shot of what the same system looks like with FileVault2 turned on. Note that it says "Unlocked Encrypted". In this scenario, /dev/disk1 is logical volume I want to image.

Each /dev/disk has a corresponding /dev/rdisk:

rdisk is supposed to be faster than /dev/disk. As such, we are going to use /dev/rdisk1 instead of /dev/disk1 in the dd command.

Now would be a good time to plug in the external drive that will hold the image. On my system it auto mounted under /Volumes/<Device Name>

For dd, I am going to use the syntax suggested by the Forensic Wiki Page. The syntax looks something like this:

sudo dd if=/dev/rdisk1 bs=4k conv=sync,noerror of=/Volumes/MAC-Images/my_image.dd

 
Lets break down this command:

• sudo: run as super user
• if=/dev/rdisk1: this stands for input file. This will be the disk that requires imaging
• bs=4k : this is the block size used when creating an image. The Forensic Wiki recommends 4k
• conv=sync,noerror: if there is an error, null fill the rest of the block; do not error out

Better yet - let's add in an MD5 so we can have a hash of the image to make it more "forensicky". In order to do this:

dd if=/dev/rdisk1 bs=4k conv=sync,noerror | tee /Volumes/MAC-Images/my-image.dd | md5 > /Volumes/MAC-Images/my-image-md5.txt

According to the forensic wiki:

"The above alternate imaging command uses dd to read the hard-drive being imaged and outputs the data to tee. tee saves a copy of the data as your image file and also outputs a copy of the data to md5sum. md5sum calculates the hash which gets saved in mybgifile.md"

Try not to fat finger the password like I did though...

That's it! Happy imaging whichever tool you use.

Cookie Cruncher Update, Timelines, Chrome Parser and more

I just wanted to pass on that I had a chance to update my Google Analytic Cookie Cruncher to support Firefox up to version 48. I can't believe it's been two years since I've updated the code!

I know I've said it before, but if you need me to update a tool to support a newer version of "X", please let me know - I'm happy to do so :) With everything else on my plate, I don't always have time to test each new browser for compatibility issues. Thanks to Heather Mahalik for reaching out to me with a student request to get it updated - sometimes I need that extra motivation.

I also updated my script that parses Google Analytics from Safari binary cookies. Mike O'Daniel reached out to me when the script crashed on him. Although he was unable to share the data due to privacy reasons, with a little back and forth trouble shooting we were able to determine what the issue was. He was parsing cookies from an iPad which contained URL encoded strings. None of my test data contained cookies formatted in this way and I did not have access to an iPad. Once the issue was fixed in the script he was off an running. Thanks to Mike for reaching out  to me to let me know that there were issues, and taking the time to help trouble shoot it since I was not able to replicate the issue.

I also wanted to push out a simple little parser for Chrome Internet History and Downloads. I recently spoke at the HTCIA conference  about mini-timelines (and even micro timelines). While this concept is nothing new, I have found this process to be invaluable during the cases I work. Harlan has blogged many times about the process and advantages of it, so I won't go into detail here. For the lab I taught, I just needed to output some basic Chrome Internet History into TLN format so I wrote a Chrome parser in python.

Now this tool does not show every single thing that is available in the Chrome History. I just stuck to the basic information: Visit time, URL, Hit Count etc. Sometimes too much information can cloud the timeline, making it difficult to pick out patterns of activity, or create so much noise the next lead gets lost in all the output.

I like the data in my timeline to be concise and clear. It reminds me a little of keyword searching. If the term is vague, you may be casting a wider net, but relative results could get buried in a million hits. It's going to take a lot of sifting to find that golden nugget. However, if you use a carefully crafted keyword, you can focus in on what it is you are looking for. Timelines are the same. Carefully picking the artifacts you want to add in to the timeline can help you hone in on relevant data quickly.

The other thing I wanted to discuss was Volatility plugins. I recently had the chance to run through a demo at a Python Meetup group on what Memory forensics is, and how Volatility can be used to analyze memory. As part of this, I "wrote" my first volatility plugin. Now, I say "wrote" because it was really just modifying a couple of lines in someone else's code to do something a little different.

Volatility has provided a nice interface to grab various keys from the registry. In fact, it reminds me of the way plugins are handled in RegRipper. If there is a key that you want that is not currently supported, look for a plugin that is similar and see if you can tweak it. It's a great way to start out, and as you tweak more and add a little bit here and there, you being to understand how things work.

I just started with something simple - pulling the computer name. This is just one key, with no binary data to convert:

HKLM\CurrentControlSet001\Control\ComputerName\ComputerName

I found another Volatility plugin that pulls a key from the system hive, shutdown.py - changed a few lines of code, and et voila! My first plugin. Ok - nothing earth shattering or difficult, but it's the first step in understanding how things work. That's often the way that I write many of my scripts - break it down into pieces, find code examples, and put it all together. Pretty soon I actually remember some of it, and my skill set advances.

The original code was written by Jamie Levy (@gleeda), and pulls the shutdown time from the registry. Below is a example of what I did. I just commented out what I didn't need, and modified what I did need.

While it may not be complex, it gets the job done and I learned something new in the process.