USB Target Disk Mode

In earlier generations of Apple MacBook computers, TDM or Target Disk Mode was a boot mode that made all internal drives appear to an external FireWire capable system to be LUNs which could be consumed by another endpoint (This usually included the internal Hard Drive and CD/DVD-ROMs). Because of the peer-to-peer nature of FireWire and the standard SCSI command set, implementing a consumer in linux for this protocol was relatively straight forward. Modern USB and Thunderbolt based target disk mode requires a machine that is ordinarily a USB host to become a slave. Moreover, Apple’s security features such as encryption and effaceable storage complicate the implementation. What follows is an analysis of the USB based target disk mode protocol, and also a revelation that the FileVault2 key may be extractable (albeit in wrapped form) from a machine without the OS booted. This paper will be extended in the future to cover the slight differences when using Thunderbolt to replace USB mass-storage as an underlying transport.

USB Bulk-Only-Transport

The first layer of the TDM onion is a simple obfuscation. When an Apple laptop is booted into TDM and a USB 3.0 cable is attached (it should be noted that the USB-C cable needs all USB3.0 pins connected, UTDM does not work with 1.0, 1.1 or 2.0 cables or controllers), it declares itself to be a Apple, PID_1800, implementing a Diagnostic Class (0xDC) device with subclass 0x02 and protocol 0x01.

This provides two `1024` byte bulk endpoints that communicate with the device in what is called USB MSD BOT (USB mass-storage device, bulk only transport[1]). This provides basic framing/length, checksum, direction, logical targets, etc. Think of this level as TCP with a set number of pipes. These pipes end up translating into LUNs at the next level up the stack. Beyond this everything appears to be a superset of the standard SCSI command set.

USB Attached SCSI

Next up the stack is the SCSI transport. It should be noted that this is not UASP or USB attached SCSI protocol, but instead SCSI over the mass-storage BOT. This is a simpler protocol to implement as it doesn’t permit more eccentric things like native command queueing. A device in UTDM has 4 addresses or in SCSI language LUNs (logical unit numbers). SCSI sits on top of the BOT layer and provides basic commands, Apple extensions and LUN addressing.

• The Apple proprietary LUN0 - CONTROL endpoint, for managing power, device information, read/write protect and a few other things
• The Apple proprietary LUN1 - AppleKeyStore endpoint. This is for accessing a T2’s AppleKeyStore service to unwrap FileVault2 keys with a password. (see https://github.com/nabla-c0d3/iphone-dataprotection/blob/master/ramdisk_tools/AppleKeyStore.h)
• The Apple proprietary LUN2 - AppleEffaceableStorage endpoint. This is to wipe the device key that is used in the wrapping process, stored in special NOR memory (the NVMe is NAND). Wiping this key should provide protection for the entire disk, because without it the volume data cannot be decrypted.
• The “standard” LUN3 - DISK endpoint with a little non-standard opcode magic. This is a generally compliant SCSI disk.

Mounting the APFS volume

https://github.com/sgan81/apfs-fuse

Potential Linux Driver

Active Development, trying to reuse Kernel code and structures

https://github.com/rickmark/apple_utdm

Potential Security Fuzzing Points

• USB MSD BOT error modes
• SCSI command / length / invalid state
• Command / AKS / AES endpoints are non-standard and were likely not meant to be exposed outside the kernel