Welcome to Part 3 of the Perfect Acquisition series! If you haven’t read Part 1 and Part 2 yet, be sure to check them out before proceeding with this article. In this section, we will introduce our newly developed Perfect HFS Acquisition method, which enables the extraction of data from legacy iOS devices that do not have SEP and utilize the HFS file system.

• Perfect Acquisition Part 1: Introduction
• Perfect Acquisition Part 2: iOS Background
• Perfect Acquisition Part 3: Perfect HFS Acquisition (this article)
• Perfect Acquisition Part 4: The Practical Part

As a quick recap from the previous section, we consider an acquisition to be a Perfect Acquisition if we can obtain a complete data dump with keys while satisfying the following conditions:

1. We do not rely on any software running on the device that we did not write ourselves (for reliability).
2. We do not alter any single bit on the device (for verifiability).
3. Subsequent acquisitions should produce the same result (for repeatability).

In this section, we will examine how we can perform a (nearly) Perfect HFS Acquisition and explain why any (theoretical) imperfections in this approach can be disregarded.

Loading our code

Normally, iOS has a secure boot process with a chain of trust that reaches down to the immutable BootROM, where the first piece of code is executed. All following code is authorized by Apple and prevents any non-authorized code from being executed.

However, with our method, we use a BootROM exploit to bypass this restriction at the lowest level and gain the highest possible privileges on the SoC, allowing us to load our code at the earliest possible point in time. Our software uses the original iOS firmware downloaded from Apple servers (either automatically or provided by the user) and patches the signature checks to allow our code and modifications of later stages to be executed and boot into a ramdisk. We achieve this by sending the bootloader, kernel, and ramdisk over USB, resulting in a live system similar to booting Linux from USB or CD.

Technically, at this point, we have already violated the first constraint by running several components of the iOS operating system that we can consider as a black box, which to some extent, perform operations we don’t understand. However, the idea is to prevent malicious code from tampering with our acquisition. By downloading the firmware straight from Apple and loading it via USB without relying on any software installed on the device, we can be sure that the loaded code is not malicious. Even if malware is present on the device, it will not be loaded. Therefore, we can reasonably assume that the data hasn’t been tampered with.

From this point on, we are working with a complete operating system running in a ramdisk. We consider it trustworthy based on the following assumptions:

1. We assume that we are working with unmodified, original iOS firmware up until the point where we modify it ourselves to apply necessary patches and remove restrictions.
2. We assume that the original iOS does not interfere with our acquisition process.
3. We assume that the data being acquired does not exploit the operating system and alter it during the process (as is the case with Signal Messenger, but on a lower filesystem level)

We believe these assumptions are reasonable and, under these conditions, we consider the first constraint of reliability to be fulfilled.

We are confident that it is easy to acquire unmodified original iOS firmware, and it is highly unlikely that an attacker could trick users into downloading malicious firmware specifically modified to interfere with this type of acquisition.

We also assume that the original iOS firmware does not intend to and has no mechanism for tampering with raw block device reads, which is what we use for the acquisition process. Such a mechanism would be easy to detect, and we are not aware of any mechanisms that explicitly tamper with data dumps in iOS.

Finally, we are not aware of any vulnerabilities in the block device driver or any software that could compromise it to the point where it would target and alter data acquisition without being detected.

Based on these reasonable assumptions, we believe that we are operating within the listed constraints.

Dumping the data

We acquire the complete data by performing a raw block device dump using the command dd if=/dev/rdisk0s1s2 bs=32K. This process ensures that no bits are modified on the storage device.

To verify the integrity of the data, we can turn off the device and perform the exact same dump again at a later time. It’s important to note that we must not boot iOS in between dumps, as doing so will modify the data and make the two dumps non-identical.

By following this procedure, we can easily fulfill the second condition of verifiability and the third condition of repeatability without any compromises.

Dumping the keys

In addition to the data, we also need to dump the contents of the effaceable storage and derive several keys from the UID key, which we cannot extract directly.

If the passcode is known, we can extract the passcode key directly. Otherwise, we offer an option to crack the passcode on the device first

Final remarks

At the end of the process, we have successfully acquired a complete dump of the HFS filesystem using the Perfect Acquisition method. Finally, we can use the keys to decrypt the dump and gain access to all files, including their metadata, as well as all keys stored in the iOS keychain.

We have demonstrated that any theoretical shortcomings of this approach are not relevant in practice, and can therefore be safely neglected. This is why we refer to this method as the Perfect HFS Acquisition.

In summary, this is the best possible approach for acquiring data using pure software. However, if you have hardware-acquired dumps and the keys needed for decryption, we can also assist you in the decryption process.

Stay tuned for part 4, where we will provide step-by-step instructions on how you can perform Perfect HFS Acquisition using Elcomsoft iOS Forensic Toolkit.