source: http://az4n6.blogspot.de/2016/07/how-to-image-mac-using-single-user-mode.html

1) Boot into single-user mode
2) Determine the disk to image
3) Mount the USB drive that will hold the image
4) Run the dd command to create the image

Step 1 – Boot into single-user mode
The first step is to boot into single-user mode. While the system is booting, select COMMAND-S to enter single-user mode. I usually hold down this key combo before I even power on the system so I don’t accidentally “miss” it. At this time, I do not to have the USB drive that will hold the image plugged in.

Unencrypted
If the system is not encrypted a bunch of white text will scroll and finally present a shell with root:

Encrypted
If the system is encrypted, some text will fly by that says efiboot, and then a GUI window will pop up asking for the username and password:

After the username and password are entered, the single-user boot process continues and drops into a shell similar to the unencrypted system.

Step 2 – Determine what to image
The next step is to determine what block device to copy for the dd command. In order to determine this, use the ls command to get a list of the available disks under the /dev directory. As I mentioned before, I prefer to do this before I plug the USB drive in so I don’t have to try and guess which is the internal hard drive and which is the USB drive. (OS X has a disk utility called diskutil that presents more verbose information about the disks, however, it is not available in single-user mode)

The output is slightly different between the encrypted and unencrypted drive, which I discuss below.

Unencrypted Drive
On the test unencrypted system there is one disk, disk0, with three partitions: disk0s1,
disk0s2, and disk0s3.  For this particular system, the image should be of /dev/disk0:

Encrypted Drive
Note the addition of the /dev/disk1 on the encrypted system:

What is this /dev/disk1? Using file -sL on each partition can give a little bit more insight into what is going on. (Note – I ran these commands while in a terminal because there was no good way for me to get a screen shot in single-user mode…the text went all the way across the screen. However, the commands and outputs are similar while in single-user mode)

From these results I can tell that disk0s1 is the EFI partition, and disk0s3 is an HFS partition. disk0s2 is showing as “data”. This happens when the file command can’t tell what the file is, it just gives a generic “data” in response – which makes sense if the partition is encrypted.

Some quick math give us the partition sizes:

EFI disk0s1 size = 409600 sectors X 512 bytes per sector =  209715200 bytes = ~210 MB
HFS disk0s3 size = 4096 bytes per block X 158692 blocks = 650002432 bytes = ~650 MB

Next, I want to see what size disk0s2 is. I can use fdisk /dev/disk0s2 for this:

disk0s2 size = 1951845952 sectors X 512 bytes per sector = 999345127424 bytes =~999.3 GB. Definitely the biggest of them all!

Now I want to see how big /dev/disk1 is to compare it to the other partitions. Here I will use /dev/rdisk1 because /dev/disk1 is busy. /dev/rdisk is the raw disk of /dev/disk1:

rdisk1 size = 4096 bytes per block X 243898823 blocks = 999009579008 bytes =~ 999 GB

/dev/disk0s2 and /dev/disk1 are about the same size, 999GB, and /dev/disk1 is a readable HFS partition. Based on my experience and the outputs above, it appears /dev/disk1 is the OS X partition (disk0s2) in a decrypted state.

For imaging, either /dev/disk0 or /dev/disk1 can be used. If /dev/disk0 is used, all three partitions will be captured, but the data in the MacOSX partition – /dev/disk0s2 will remain in the encrypted state. If /dev/disk1 is imaged, it will have the MacOSX data in an decrypted state,but will not have partition 1 (EFI partition) and partition 3 (Recovery partition). I like to grab both /dev/disk0 and /dev/disk1.

Step 3 – Mount the external USB Drive 
The next step is to mount the external USB drive so the image can be saved onto it. The USB drive can be formatted in FAT32 or HFS. FAT32 has the benefit of both Windows and Mac being able to access it, but it has a 4GB file size limit. While HFS does not have the 4GB limit, Windows is not able to see it by default (if you have a Mac with bootcamp your Windows OS should be able to read HFS if the bootcamp drivers are installed).

For my tests I used a FAT32 USB drive for the unencrypted system, and an HFS USB drive for the encrypted system so I could demonstrate the syntax for both.

After plugging in the USB drive, run ls /dev/disk* again. Compare the outputs to determine which /dev device belongs to the USB drive

Unencrypted
For this system the FAT32 USB drive has been inserted, which shows up as /dev/disk1. The partition that needs to be mounted is /dev/disk1s1:

Encrypted
For this system the HFS USB drive has been inserted, which shows up as /dev/disk2. This drive has two partitions. The partition that needs to be mounted is /dev/disk2s2:

(If there are multiple partitions showing on the USB drive the file -sL command can be used to get more information if you’re not sure which one to mount.)

Once you’ve determined the USB device keep this handy for the mount command. The next few commands and outputs are the same for the unencrypted and encrypted system.

In order to mount the USB drive, the system drive will need to be changed to read/write by using mount -uw:

[EDIT 8/1/2016]  **** Please read the comments. There is information on how you can mount without changing the system drive to read/write****[END EDIT]

Next, a mount point will need to be created for the USB drive. For this example, the mount point will be created under /tmp/usb:

Now it’s time to mount the USB drive.The mount command will need the partition type (FAT32 or HFS), the disk to mount, and a mount point.

Mount the FAT32 USB drive on the unencrypted system
To mount the FAT32 drive on the unencrypted system the following syntax was used: 

Mount the HFS Drive on the encrypted system
To mount the hfs drive on the encrypted system, the following syntax was used:

I always create a subfolder on the USB drive to hold the image. This way I can list the contents of the mount point as a sanity check to ensure that it mounted ok:

Here I can see “MacEncryptedImage” and “MacImage”, the folders I created on the USB drive. Everything looks good to go.

Step 4 – Create the image 

To create the image, the dd command can be used.  For dd, I use the options recommend on the Forensic Wiki page. The syntax looks something like this:

dd if=/dev/disk0 bs=4k conv=sync,noerror of=/tmp/usb/mac_image.dd

Lets break down this command:

• if=/dev/disk0: 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

If /dev/rdisk is available this can be used instead of /dev/disk. rdisk provides access to the raw disk which is supposed to be faster then /dev/disk which uses buffering.

Unencrypted system
For the unencrypted system the image will be of /dev/disk0 to a FAT32 USB mounted drive. Since FAT32 has a 4GB file size limit, dd will need to be piped through the split command to keep the file size under 4GB:

Encrypted system
For the encrypted drive, this example will be of /dev/rdisk1. Since the image will be saved to an HFS USB drive there is no need to split the image:

Unfortunately, dd does not have a progress bar so patience is a virtue. Once it’s complete, a message similar to below should appear:

View Image
As a last step, I just wanted to show how each image looked when opened in FTK Imager.

Unencrypted
The unencrypted image looks as expected, three partitions in an unencrypted state:

Encrypted
During my testing, I imaged both /dev/rdisk0 and /dev/rdisk1. /dev/rdisk0 was the entire disk with all three partitions. Opening the rdisk0 image in FTK Imager confirms that all three partitions are present. As expected partition 2, MacOSX, is showing as an unrecognized file system because it is encrypted:

The image of /dev/rdisk1 was an image of just the second partition, which is the MacOSX partition. Opening it up in FTK Imager confirms that /dev/rdisk1 is in a decrypted state:

So, in summary, here are the steps and commands covered above:

• Use Command-S to boot into single user mode
• Use ls /dev/disk* to determine the disk(s) to image
• Plug in the USB Drive
• Use ls /dev/disk* to determine USB drive device
• Use mount -uw / to change internal drive to read/write
• Use mkdir /tmp/USB to create a mount point
• Use mount to mount the USB Drive
  • mount -t msdos /dev/disk1s1 /tmp/usb (for FAT32)
  • mount -t hfs /dev/disk2s2 /tmp/usb (for HFS)
• Create disk image using dd
  • dd if=/dev/disk0 bs=4k conv=sync,noerror | split -b 2000m – /tmp/usb/disk0.split. (FAT32 USB)
  • dd if=/dev/rdisk0 bs=4k conv=noerror,sync of=/tmp/usb/rdisk0.dd (HFS USB)

While these steps worked on my test Mac, examiners should always test and research the model they are encountering. I was limited to one test system, one hard drive and FileVault2 encryption. I also recommend trying this on a test Mac before running these steps on actual evidence. Single user-mode logs in as root, and this can be very dangerous.  Remember – Trust but Verify! 🙂

Mounting Drives

fsck and mount

I recommend not plugging in your USB drive yet. Then boot the system into single-user mode. When you do, you’ll be logged in as root at a command line prompt. (Which seems like a security risk. I could walk into any office, reboot a Mac into single-user mode, then wipe their hard drive. But that’s another story.)

The first things you’re supposed to do are to run these commands:

fsck -fy
mount -uw /

The fsck command takes a while to run, maybe 5 or 10 minutes, although that will vary depending on the size and speed of the drive.

The mount command is necessary because your hard drive is mounted read-only by default, so this re-mounts it in read/write mode.

Run some launchctl commands

Before running the following commands, I recommend running this lscommand:

ls /dev/disk*

This shows which disk devices are currently on your system. I’m not logged into my system at the moment, but when I did this on my iMac, I saw three outputs here, all beginning as /dev/disk0. Because I didn’t plug in my USB drive yet, I know those device listings are for the drives already in the computer.

Next, plug in your USB drive. After a few moments you should see some sort of message on screen. With the vertical stripes I can’t really read that message on my monitor, but it’s an indicator that the Mac hardware at least recognized the USB device was plugged in. (I think part of the message showed “USB,” or possibly “USBUHC”.)

If you’re lucky

If you’re lucky, you can run that ls command again, and you might see some new device files:

ls /dev/disk*

If you see new files here, congratulations, you’re in better shape than I was. If so, and assuming that your USB drive is formatted as a Windows/DOS filesystem, just follow these steps to mount the device:

mkdir /Volumes/usb
mount_msdos /dev/disk1s1 /Volumes/usb

If your USB device is formatted differently, use another mount command. I think there’s a command named something like mount_hfs for devices formatted with a Mac filesystem.

Once that’s done, you should be able to see the new filesystem with the dfcommand:

df

Because /Volumes/usb refers to the root directory of your USB device, when you copy files to that directory, you’re actually copying them onto the device. If these steps have worked for you, great, begin copying your files.

If the USB device didn’t show up

In my case, my iMac didn’t immediately create any /dev/disk* device files for my USB drive, so I had to dig deeper. In short, here’s what I had to do. First, per some other websites, I ran these launchctl commands:

launchctl load /System/Library/LaunchDaemons/com.apple.kextd.plist
launchctl load /System/Library/LaunchDaemons/com.apple.notifyd.plist
launchctl load /System/Library/LaunchDaemons/com.apple.configd.plist
launchctl load /System/Library/LaunchDaemon/com.apple.DirectoryServices.plist

Those may have helped, I don’t know. One of them caused the system to start posting information to my display, which combined with the vertical lines was a real pain in the butt.

While that’s what was recommended on other websites, I didn’t see the new /dev/disk* files until I also ran these commands:

launchctl load /System/Library/LaunchDaemon/com.apple.disk*

There are two “com.apple.disk” files in that directory, and I can’t remember their names now, but the last time I was in my system I just used that command, and it worked fine. Shortly after this, the /dev/disk device files showed up.

Once the /dev/disk* files show up

My system created the new files with names like /dev/disk1s1, and based on information I found on other sites, I thought that was the correct device to mount. So I created my mount point like this:

mkdir /Volumes/usb

and then mounted the USB drive like this:

mount_msdos /dev/disk1s1 /Volumes/usb

After that, I copied all the files I wanted to the /Volumes/usb directory (which is really the filesystem on the USB device), and then unmounted the USB device like this:

umount /dev/disk1s1

Once I saw that the /Volumes/usb result no longer showed up in the output of the df command, I removed my USB drive.

Shutting down the system

I haven’t looked into those plist files yet, but something about loading them was keeping my Mac from being shut down properly. So to shut my system down, I first unloaded all of the plist files like this:

launchctl unload /System/Library/LaunchDaemons/com.apple.*

At that point I think you can shut down your system by typing exit, but I was trying to do something else next, so I used the reboot command instead.

Other notes

Regarding that mount point, I don’t think there’s anything special about using the Volumes directory. In my younger days as a Unix admin, I’d create a mount point wherever I wanted to, so unless OS X is doing something unique, you can probably create a mount point wherever you want.

As mentioned at the beginning of this article, these notes pertain to a 2008 model iMac running Mac OS X 10.6.x. Other Mac operating systems are probably at least slightly different.

Summary

I hope these notes have been helpful, and will save you a little time. I know they would have saved me several hours if I knew about all of this last night.