checkm8: Advancements in iOS 16 Forensic Extraction

 

In iOS device forensics, the process of low-level extraction plays a crucial role in accessing essential data for analysis. Bootloader-level extraction through checkm8 has consistently been the best and most forensically sound method for devices with a bootloader vulnerability. But even though we brought the best extraction method to Linux and Windows in recent releases, support for iOS 16 on these platforms was still lacking behind. In this article we’ll talk about the complexities in iOS 16 extractions and how we worked around them in the newest release of iOS Forensic Toolkit.

Note: checkm8 exploit currently does not work on Windows, so the device needs to be exploited externally first, either through a Raspberry Pi Pico (for A5/A5X devices like iPhone 4s) or through a Linux/macOS machine. You can check the current compatibility matrix below.

With the advent of iOS 16, a significant shift occurred as the RAM disk transitioned to the APFS file system. While Apple introduced APFS as the main filesystem on their mobile devices back in iOS 10.3, the RAM disk used for restoring or upgrading iOS, remained in the HFS file format up until iOS 16.

Previously, we used our own implementation of the HFS filesystem to on-the-fly modify the restore RAM disk from the IPSW firmware file, in order to delete unneeded files and insert our programs used for data extraction, but with the transition to APFS that was no longer possible.

For Mac users this did not cause major trouble, as APFS is natively supported in macOS, allowing us to fall back to using built-in tools like ‘hdiutil’ to resize the ramdisk and mount it to modify its contents. macOS users had to confirm the following prompt on their computer, and needed to authenticate with either Touch ID or password to continue:

On other platforms, proper tools for modifying (resizing/creating) APFS filesystems do not exist. Even if there are some public implementations out there to allow mounting APFS on linux, we can’t rely that they create a working ramdisk and on top of that most of those implementations are readonly anyways.

In recent development, we created our own implementation of the APFS filesystem similar to what we already had for the HFS filesystem, allowing us to resize and modify APFS ramdisk in-memory on-the-fly without relying on external drivers. This enables the extraction process on Linux and Windows, and streamlines the extraction in macOS (getting rid of the hdiutil pop-up).

With these enhancements in place, the extraction process for iOS 16-compatible devices becomes more accessible. Notably, extraction of iOS 16 is now supported on the following devices:

In conclusion, our implementation of the APFS filesystem, enhances compatibility for low-level extraction on iOS 16 devices. It is essential to note that while checkm8 provides access to device file system, certain limitations persist on A11 devices. For further details on iOS 16 security measures and their implications for forensic analysis, refer to the next chapter.

With the release of iOS 16, Apple made things more difficult for the mobile forensic specialists. iOS 16 added further hardening to the SEP (Secure Enclave Processor), which is responsible for the systems data protection. When booting the device through DFU-mode, SEP disables the cryptographic keys needed to decrypt userdata. In iOS 15 it was enought to remove the passcode when booting in normal mode, to not rely on those hardware disabled keys during extraction. In iOS 16 however, if a passcode was ever set on the device after a clean restore, it is no longer possible to not-rely on the keys that SEP disables, thus greatly improving protection of userdata.

On older A10X devices (like the iPad Pro 2) we can exploit SEP with blackbird and tell SEP not to disable those keys, while even older devices (<=A9) like the iPad 5 didn’t receive that hardening in the first place.

Therefore, the extraction will fail if a passcode was ever used on the iPhone 8, 8 Plus or iPhone X after the initial setup. The practical value of our solution for these devices is low as the overwhelming majority of Apple iPhones are (or at least were) protected with a passcode. You can still use it on other devices such as iPads, HomePods, and Apple TVs.

 By Elcomsoft R&D at 2024-03-15 11:55:25 Source ElcomSoft blog: