There are two types of acquisitions: live 🍀 and dead ☠️. Choosing based on the system’s initial state in question is usually preferable. So, for example, if the system is turned on, perform live acquisition first, capturing all volatile data that will be deleted after reboot. Otherwise, jump right to the dead acquisition (if the system is shut down).
⚠️ There are some caveats which need to be handled, though. For example, at the moment of this writing (📆
11/07/2022), macOS has introduced Share Disk mode for the newest M1 machines. Unlike the Target disk mode, which would treat the disk as external, making it possible to turn on the write blocker, this new mode is more like a network share and works over SMB (over the wire). This way, the target disk won’t show with the
diskutillist; thus, all standard procedures for write blocking won’t work. I don’t know if an ordinary physical write blocker will work since the mechanism is different. I have posted this question on forensicfocus.com but have not received any updates.
❗️ The target media needs to be sterilised first! Refer to the sterilisation article for more details.
diskpart DISKPART> list disk
sudo dd if=/dev/sda1 of=/case1/diska1.dd sudo dd if=/dev/sdb of=/case1/diskb.dd sudo dcfldd if=/dev/sda of=/home/diska.dd hash=md5 hashlog=/home/diskaa0md5.txt sudo dcfldd if=/dev/disk4 of=/Users/%username%/Documents/image.img hash=md5,sha1 md5log=/Users/%username%/Documents/md5.txt sha1log=/Users/%username%/Documents/sha1.log hashconv=after bs=512 # hashconv - calc hash after or before the conversion # the most forensically useful tool, calculates hashes of the input source and the image to make sure they match. Verbose output # to install on macOS - brew install dc3dd sudo dc3dd if=/dev/sdb hof=sdb.img hash=md5 hash=sha1 log=hash.txt
⛔️ If you get
dd: /dev/disk4: Resource busyon macOS when trying to make an image with
dd, ✍🏻 go to Disk Utility and unmount the drive (don’t eject it).
🧪 Will any USB work (GPT or MSDOS) or should I have both for different cases?
macOS / Linux
sudo fdisk -l # Linux lsblk mount
This property of containers runs contrary to the fundamental forensics need to preserve evidence. Container images that start and stop constantly represent moving targets and targets that frequently cease to exist. Sheward, Mike. Hands-on Incident Response and Digital Forensics (p. 177). BCS Learning & Development Limited. Kindle Edition.
The underlying container image is stored in one location; this image contains the configuration data and applications that form the container image. Any changes made while the container runs will be written to a separate file and can be committed into a new image on the fly without affecting the running container. If a container is believed to be compromised, you can run that newly committed image to explore its contents. Note, however, that such an action creates a new container from the image, not the exact same copy of the container you committed from. This differs from a VM snapshotting approach since running processes in the target container are not included in the image. Sheward, Mike. Hands-on Incident Response and Digital Forensics (p. 177). BCS Learning & Development Limited. Kindle Edition.
Dead Acquisition Checklist
- Ensure the target media (evidence drive) is sterilised (ref. Identification/Assessment stage above).
- Turn the machine off (better unplugging it to prevent data from being overwritten).
- On the forensic MacBook, make sure all remote functionality is off (Bluetooth, AitDrop, WiFi, Cellular etc.), and the software-based write blocker is on (if no hardware blocker is used) - see above for the latter.
- Connect the forensic machine to the target machine using a USB Type-C cable (for newer MacBooks) or Thunderbolt cable for older ones.
- Turn the target machine in either Target Disk mode (for older MacBook) or Share Disk (for newer MacBook).
- Share Disk.
- Turn the suspect machine off. Press turn on the button and hold until you see “Continue holding for startup options”. Stop holding when “Loading startup options” appears.
- On the top panel, choose Utilities -> Share Disk and select the disk you want to share. You might be asked to unlock it (if FileVault is enabled).
- On the forensic machine, go to Network () or see the device appear in the side panel in Finder. If it doesn’t, open Finder -> Preferences -> General and make sure External disks, Connected servers and hard disks are selected. Please move to the Sidebar tab and ensure it’s all selected there.
- Target Disk. There are two ways to boot into this mode. One is simply by pressing the power on the button and a
T-key while booting. The second one is from Preferences. This legacy option is not present on the latest Apple devices.
- Share Disk.
For newer MacBooks, it gets tricky. I posted the question here. No answer still (📆
At first, Mac imaging was no different from imaging other devices running other OS (Windows or Linux). But then they added Fusion Drives which was quite a trouble for analysts. Samuri stumbled upon it, and they had to work this out. But after T2, Mac imaging has become even more painful since it’s impossible to image a drive without a password and another Mac even if File Vault is turned off. At the moment, Mac forensics resembles iOS forensics because there is probably little you can do without a password. There used to be some disk mode in which one could perform imaging, but now it doesn’t work without a passcode.
Another interesting key point is that the kill signal can now be sent over Bluetooth. That means if someone with Bluetooth enabled on the crime scene, the owner of the evidence (Mac device) could send a command to wipe his notebook leveraged through the investigator’s Bluetooth. It sounds made up, but a Mac forensics expert said this is what it looks like now.
Also, they talked about the ITR tool that images and triages Mac devices. Supports live images of Apple Silicon Macs!
A fusion drive combines an ordinary drive and a small NAND flash drive that appear as one logical volume in the OS. Still, when you try imaging it, you’ll get two different images, and the image will be somewhat corrupted for the analysis tools if you don’t assemble it correctly. NAND flash drive stores the most often used files like system ones and those the user uses more often than others. The idea seems to be the same as with prefetch in Windows 🌈.
Target Disk (Intel)
I have an old MacBook (see this blog post) and a new one with an M1 chip. Following the instruction from the Udemy course of Michael Leclair, I’ve bought a Thunderbolt2-Thunderbolt3 cable to connect these two PCs. I’ve tried this and this first, but they worked only for connecting Displays. However, whatever line I tried using, I needed something to work. I then tried the Apple ones, but these did not work either. I have run across this text on official Apple docs for the Apple Thunderbolt 3 (USB-C) to Thunderbolt 2 Adapter:
This adapter is bidirectional so that you can connect Thunderbolt 3 devices to a Mac with a Thunderbolt or Thunderbolt 2 port. In that case, the Mac must use macOS Sierra or later, and the device using Thunderbolt 3 must provide its power. 
So, there are two prerequisites:
- macOS Sierra or later
- the device using Thunderbolt 3 must provide its power.
https://aliexpress.ru/item/1005001855199343.html?spm=a2g0s.12269518.104.22.168ae9776dYIfPHB&item_id=1005001855199343&sku_id=12000017867458221 USB TYPE-C Thunderbolt 3 2 к мини DisplayPort DP 4k 60 Гц для Macbook Air Pro Samsung dell XPS13 15 к Apple cinema display
https://www.aliexpress.com/item/1005001855439084.html?spm=a2g0s.12269522.214.171.124faf3d9dDfAwT5 Cabletime USB C 3.1 to Mini DP Adapter 4k60hz Projector Type C to Thunderbolt 2 Converter For Laptop Huawei Mate 40 Samsung N428
FileVault 2 Target Disk Mode Unlock Using the Personal Recovery Key. As is stated here on Reddit:
[…] USB-c charging cable provided is only usb2.0 for data transfer […] to do Thunderbolt target disk mode, you need a Thunderbolt three cable (expensive) […]
So, using the cable that came with the charger shouldn’t work since it supports USB 2.0 transfer only.
Share Disk on M1
I tried different channels and forums, but there was no obvious answer. This took quite an amount of research. By now, I can conclude the following.
Share Disk is very different from Target Disk and is relatively useless for forensic purposes (from what I’ve seen now). Unlike its predecessor, Share Disk operates over SMB protocol and is not mounted like a standard drive.
Diskutillist (or its GUI version Disk Utility), Disk Arbitrator (custom tool) or even
ls /dev/ | grep disk won’t show it. Its mounting seems not governed by
diskarbitrationd (framework for mounting and managing drives). Even though it looks like it’s mounted in GUI, different APIs are in place.
I’ve tried creating a file
/etc/fstab and using custom settings for mounting my test USB drive:
LABEL="TestDrive" none apfs ro,noauto. This USB device was not automatically mounted; when I mounted it manually, it was in read-only mode (
ro option). I did the same for the Macintosh HD, the label for my drive on target MacBook:
LABEL="Macintosh HD" /suspect apfs ro,noauto. Just in case, I acquired the volume’s UUID via
diskutil info /Volumes/Macintosh\'s\ HD | grep -i uuid from both the recovery mode and when booted normally (which were different).
This is a network share; you have the same rights as the PC user. I don’t know if there is any way to control the restrictions here, but at the moment, the most forensically sound way would be to use a physical write blocker. This tool from SUMURI is for Live acquisition only. And the page on the forum here has been updated a while ago.
Here is a video from SUMURI experts on the imaging issues, mentioning the Shared Disk mode. I am curious to know how they make it forensically sound.
⛔️ I could not make the whole thing work. I even thought there might be some problem with the genuine Apple cables. ✍🏻 However, in my case, the issue appears very primitive. The problem was that both my MacBooks had the same name. The airDrop was smart enough to rename one by appending (2), but it seems it was not easy in this mode. Once I named the PCs differently, it all started to work. Also, I’ve changed the HDD names, just in case.
❗️This option is not a write-proof one. I managed to delete a folder from the drive. Make sure the write blocker is on.
Bootable USB (Apple Silicon)
🧪 What if I could make a Kali USB bootable drive and boot into macOS from it?
This could be an option to make a raw image of Apple drive. This option will have other complications, like decrypting the drive, dealing with Fusion Drives and parsing APFS containers. But at least it would make the dead acquisition possible. Since there are arm versions of Kali and Kali has dd preinstalled and
gpart, this is a good start.
One of the concerns published on StackOverflow was that such functionality as Bluetooth and WiFi would not work. However, this would be even better for forensically sound acquisition.
As per the information from the Internet (in many places), macOS with M1 doesn’t support external boot.
[…]they all need to be backed by a disk image, which is a file that represents an entire raw physical disk. If forensic investigator finds themselves having to work with a VM in an investigation, the very fact that the disk is already an image file can be very advantageous. By their very nature, all forensic collections of VM drive images happen by way of a live acquisition, unless of course they are included in a wider powered-off imaging of the hypervisor’s storage. Once the investigator has located the virtual machine to be acquired using the hypervisor management software, they can determine the path to the machine’s disk image(s) (typically a
.vmdkformat file). Most hypervisors feature a function called ‘snapshotting’ which allows the VM disk image to be frozen in time. For instance, if a snapshot is triggered in VMware ESXi, a commonly used commercial hypervisor platform, a new copy of the disk image is created, writes are prevented on the original copy and the new image gets promoted to being the primary image in use. Essentially this is a software-based write blocker built right into the platform. This is perfect for incident response; the cost in terms of time and hardware when it comes to creating a snapshot for deeper examination is minimal. Of course, we need to stay on top of things to ensure that this step is completed – the flexibility of VMs means it can be just as quick to recreate the VM from scratch, disregarding any potential evidence. 1
built-in utilities in the VSphere client. Sheward, Mike. Hands-on Incident Response and Digital Forensics (p. 165). BCS Learning & Development Limited. Kindle Edition.
-  Tools: Memory Imaging, forensicswiki
-  Mac OS Forensics How-To: Simple RAM Acquisition and Analysis with Mac Memory Reader (Part 1), 2011
-  OSX (Mac) Memory Acquisition and Analysis Using OSXpmem and Volatility
-  If you don’t have permission to use files on a Mac disk
-  How to turn off Rootless (SIP, or System Integrity Protection) in OS X
-  Memory compression and forensics
- Brief Introduction to macOS Forensics | by darkdefender | Medium
- GitHub - mac4n6/Presentations: Presentation Archives for my macOS and iOS Related Research mac4n6.com https://github.com/mac4n6/Presentations
-  2020 overview of forensic challenges for different devices
-  DFSP Podcast, interview with Steve Wahlen (Samuri co-founder)
-  Imaging Mac surviving tips (before the release of the T2 chip, I presume)
-  Imaging Mac Fusion Drives
-  About the Apple Thunderbolt 3 (USB-C) to Thunderbolt 2 Adapter
-  PowerShell Tools for IR Forensics Collection