Live Forensic Acquisition From Mac Computers

By Kevin J. Ripa
PI, GSEC, GCFE, GCFA, EnCE, BAI, CDRP, CEH
Mar 2, 2016

The instructions below are designed to extract a Live Acquisition from a running Mac Computer. This has NOT been tested on every Apple OS, but I have tested it on Mountain Lion, Mavericks, Yosemite, and El Capitan. It should work on any Intel based Mac. Instructions and screen shots are from El Capitan. Your system may vary slightly. Read all instructions FIRST, before attempting. This tutorial is about as simple and “step-by-step” as it gets. If, after reading this, there are still things you don’t understand, STOP before you START. If this is your first time dealing with acquisition of Apple computers, now is not the time to practice on a real case.

WARNING

It goes without saying that if you are doing a live acquisition, the computer is ON and LIVE. As such, you need to be extra careful about your processes and steps. The number one rule to live by is RECORD RECORD RECORD. Everything you do on the live machine needs to be recorded either via video/pictures, or in writing. Better yet, both. You WILL be changing system settings, and you WILL be potentially overwriting data. This is quite alright, as long as you have a GOOD reason, and can explain why.

Setup

There are some necessary steps to perform prior to actually collecting the live image.

1. Ideally, evidentiary intake is going to make the least amount of changes possible to the data on the drive. To this end, it is important to know where to get system and hardware information directly, rather than hunting around.
2. Ensure the subject computer is connected to a power cord. Do not do this on battery!
3. Click on the Apple symbol at top left of screen, and select “System Preferences” and then “Energy Saver”.

4. Make sure Computer Sleep and Display Sleep are both set to NEVER as shown below.

5. Click on the Apple symbol again at top left of screen, and select “About This Mac”, as shown below.

6. The screen below will appear. Depending on the OS X version, you may see a different name. Take a picture of this.

7. Click on the System Report button, and the image below will appear. In the left column, you see that Hardware is highlighted, which causes the data on the right to appear. Take a photo of this.

8. Now scroll down the column on the left and select SATA. The window on the right will show the physical particulars of the hard drive, along with the logical particulars. Take a photo of this.

9. Prepare an external drive to save the data to. The external drive needs to be formatted for use on a Mac. You can view a tutorial on formatting Mac drives and partitions HERE.
10. At this point, it is assumed that you have already captured a forensic image of the RAM. If you don’t need to, then proceed to step 11. Otherwise, imaging of RAM should ALWAYS precede imaging of hard drive. If you have not yet imaged the RAM, a tutorial outlining the acquisition of RAM on a Mac computer can be found HERE.
11. Now we need to go commando…err…. Command line. Go to the top right of the desktop screen and click on the magnifying glass (Spotlight Search).

12. In the middle of the screen, a box will open up. Type in the word “Terminal” as shown below. As you type, you will see the options appear below your typing. Once you have typed the whole word, press Enter.

13. After pressing Enter, the Terminal window will open.

When typing instructions in the following steps, only type what is inside the quotes. Don’t type the quotes themselves. It is assumed that you will hit Enter at the end of each instruction. It will not always look like you accomplished anything. Don’t worry about it. Keep following the steps unless you get some kind of error message. Especially at times when prompted for a Password, you will not see anything happening as you type it. That is normal. Just type it and press Enter. Anything placed inside < > is a variable that will be determined by you. Don’t type the < >.

Acquisition

1. Connect the destination external drive to the subject machine.
2. All of the remaining steps are assumed to be on the subject machine.
3. Note the User name, as you may need it later. Everything you will see behind the flashing cursor is info about the computer. In the example below, the computer name is “Sherlock”. The “~” means that we do NOT have Root level access on the system. The part you can’t see below because it is covered up is the User name, immediately followed by the “$” sign. Then you see the flashing cursor. This line along with the flashing cursor is called a command prompt.
4. Type “/bin/bash” as seen below. As you can see, if you type it wrong, you will get an error message. In the case below the error is “command not found”. You will be returned to another command prompt. Just try again. You can see that if you are successful, you have now changed the command prompt. There are arguments for and against doing the “/bin/bash” command. It is a throwback to the Unix days, and our testing has shown that it doesn’t seem to affect anything where forensic acquisition is concerned. In this demo, we use it to show it, but for no other particular reason.

5. Type “date” to get the system date, time, and time offset, as shown below, and take a photo. I like to take a photo of the screen while holding my phone beside it, so I capture the phone’s date and time beside the computer date and time. Reason being that the phone date and time are issued by a server, so are considered to be accurate. It will also give you a reference later, to determine accuracy of metadata on the computer.

6. Next, type “ diskutil info / | grep “Block Size””. Yes in this case you need to type quotes around Block Size when you type it in. You will see something like below.

7. Device Block Size is akin to Sector Size in the NTFS world, and Allocation Block Size is akin to Cluster Size in the NTFS world. If your Device Block Size above is 512, then continue on with these steps. If it says 4096, we have problems. 4096 Byte Device Block Size is something that no programs or systems can read right now, other than systems of the same Block Size. This new format was introduced by Apple in 2015, and is seen on their new MacBook and MacBook Air so far. If you continue imaging normally, you will be stuck with an image that cannot be opened by anything but another Apple device with the same Block Size. A great article on this can be read HERE. So far, the only method we have found around this (other than mounting with a computer with the same Block Size) is to image the logical slice with Macquisition, which defeats the purpose of this tutorial, but does get the job done.
8. Type “diskutil list” and press Enter. This will now give you the list of hard drives, as well as the architecture of each hard drive. It will also list various elements such as if the drive is encrypted or not (CoreStorage), and if there is a Fusion drive in use. You MUST understand this layout in order to identify exactly what to image, and how. A description of this can be seen HERE.

9. In our example, CoreStorage is not enabled, FileVault is not enabled, and the drive is not a Fusion drive, so we will proceed with the instructions based on that. CoreStorage, FileVault, and Fusion bring an entirely different dynamic to the playing field, and change the way you would image them. I have written a paper on the differences in acquisition of the different situations you may face. That paper can be read HERE. As well, a tutorial for acquiring FileVault (CoreStorage) can be seen HERE, and a tutorial for acquiring Fusion drives can be seen HERE.
10. Back to the task at hand. In the picture above, we see /dev/disk0 and /dev/disk1. This is quite a simple layout. /dev/disk0 is the physical hard drive in the subject machine, and /dev/disk1 is the external hard drive that will be accepting the forensic image we are creating. In the right most column, you see disk0s1, disk0s2, disk0s3, etc. These are the partitions or Volumes of the hard drive. On Macs (and Linux/Unix flavors), they are called Slices, hence the s1, s2, s3 following the disk0.
11. In this demonstration, we are imaging disk0 and saving the image to disk1.
12. Next, type “date”, press Enter, and take a picture. Don’t waste any time from this point forward, as any time unaccounted for will be difficult to explain in court.
13. Type the instruction to start the imaging, as seen below. The line to type is sudo dd if=/dev/rdisk0 of=/Volumes/<name of your destination Volume>/<name of your image file>.dd bs=64k conv=noerror,sync

14. Let’s break down what is happening in that line. “sudo” means “SuperUser Do”. In other words, run the following command as “Root”. “dd” is the name of the program we are using to perform the forensic image. “if=” means “Input File equals”. In other words, what are you imaging? This is the file path to the subject drive. You will note that we have used “rdisk0” instead of “disk0”. Why? Google it. Biggest reason that matters is it speeds up imaging by 20-30%. Next command is “of=”, or “Output File equals”. This is the file that will be created on the destination drive, so we have typed the path to the destination drive, and given our acquisition a name, and .dd on the end. Next is “bs=64k”. This is the block size that the program will use as it is imaging. In other words, in this case, it will process the data in 64 kb chunks. Why does this matter? When the chunk of data is being read, if there is a problem with the media, it will just fill the rest of the block with zeros. If the block size is small, you will not have lost much data, but if the block size is large, you may very well lose vast amounts of data that you otherwise would have gotten. So you might think that making it really small is better. Block size will also dictate how long the imaging process will take. The same drive that takes 1 hour with a 64k block size will take a dozen hours or more at 4k. So we need a happy medium. 64k is that happy medium. Next in line is conv=noerror,sync. This means that if, when reading a block, there is a problem, don’t stop the imaging process. Just skip over the rest of the block to the next one, and pad the space on the destination drive with zeros. It is also worth noting that if there are any issues during the imaging process, you will be notified at the end, of any blocks that had problems.
15. Back to the process. Once you type the instruction and press Enter, you will be prompted for the password of the machine. Enter it here and press Enter, and the imaging will start. It will look like nothing is happening. Nothing will appear on the next line until the image is complete, at which time you will see something like the picture below.

16. Again, type “date”, and immediately take a photo. The reason you have done this is to show that you have not had time to alter data in the dump. You can see that the total time for the image is listed above in seconds.

Immediately hash the RAM dump by typing md5 /Volumes/<name of your destination>/<name you called your RAM dump>.dump”. This process will take some time.

17. Once done, the hash of the file will be shown as below. It goes without saying that you should record this.

18. If you would rather hash using other processes like SHA, refer to the document outlining the different commands at HERE.
19. You are now done. Close the terminal window, and navigate to your destination drive. Right click on the .dd file you just created, and select “Get Info”. In the screen that appears, click in the box beside the word “Locked”, as seen below. This will lock the file and protect from inadvertent writing later.

As a point of reference, I have prepared a paper outlining testing on how long it takes to perform imaging using a variety of different destination media and interfaces. It can be found HERE.