Half a year ago, we started a closed beta-testing of a revolutionary new build of iOS Forensic Toolkit. Using the checkm8 exploit, the first beta delivered forensically sound file system extraction for a large number of Apple devices. Today, we are rolling out the new, significantly improved second beta of the tool that delivers repeatable, forensically sound extractions based on the checkm8 exploit.

Introduction

The checkm8 exploit was a game changer. Exploiting a vulnerability in the bootloader of affected Apple devices, checkm8 lays the path to booting Apple devices to unsigned code. The iPhone models that have the vulnerability include the iPhone 4s, 5/5c, 5s, 6, 6s, 7, and 8, including all of the Plus models. In addition, the exploit can be used on the iPhone X and the original iPhone SE. You can read more about the checkm8 exploit and its forensic implications in our old article Forensically Sound checkm8 Based Extraction of iPhone 5s, 6, 6s and SE.

Many commercial forensic tools are using code based on the checkra1n jailbreak, which is based on the checkm8 exploit. While this is a quick and dirty approach to bootloader-level acquisition, the use of checkra1n does many things on the device that are far from what is considered forensically sound. With checkra1n, one always boots the device into the installed version of iOS, performing the type of analysis known as “live analysis of authenticated user session”. checkra1n alters the content of the device being analyzed, and leaves the device in the modified state once the extraction is finished. Needless to say that extractions performed in subsequent sessions will differ from the result obtained on the first run, making extracted evidence difficult to validate. Below is the output of one well-known forensic tool:

# Checkra1n beta 0.9.6
#
# Proudly written in nano
# (c) 2019 Kim Jong Cracks
#
#========  Made by  =======
# argp, axi0mx, danyl931, jaywalker, kirb, littlelailo
# nitoTV, nullpixel, pimskeks, qwertyoruiop, sbingner, siguza
…
Begin Checkra1n

Apparently, this extraction would not be forensically sound. What would a forensically sound extraction be?

Forensically sound extraction

Depending on who you ask, a forensically sound extraction should be both repeatable and verifiable. Let’s talk about each of the two parts, starting with verifiable.

Verifiable results

You can normally get a verifiable result by documenting the extraction process and producing a digital signature (hash or checksum) of the extracted data. The use of hashing at the time of extraction helps establish digital chain of custody, producing results that can be verified in the future. Elcomsoft iOS Forensic Toolkit calculates a cryptographic hash value that can be used to validate the image’s authenticity later on.

According to Peter Callaghan, Pagefreezer’s Chief Revenue Officer, hash values can be used to authenticate evidence. In Why Hash Values Are Crucial in Evidence Collection & Digital Forensics, he writes:

“As is hopefully clear from the info above, a hash value acts as a digital signature (or fingerprint) that authenticates evidence. As long as a piece of evidence was correctly collected and processed, any other party independently examining the hash value will find the same number string. In other words, if a person uses a tool (like this one) to authenticate a piece of evidence with a hashing algorithm during collection, anyone using the same algorithm to authenticate it at a later stage will see that exact same resulting hash value—and any change to the data will result in the hash value changing.“

To validate the extracted image of the iPhone’s file system, you can use the command-line certutil:

certutil -hashfile FILENAME md5|sha1|sha256

If the verification is successful, you will see the result as in the following example:

MD5 hash of disk.e01: 0d8a7ca3d87bf6c202c26dc363983836

CertUtil: -hashfile command completed successfully

In macOS, use these commands to calculate hashes:

md5 FILENAME

or

shasum FILENAME

Repeatable extractions

So we’ve got a file system image that we can verify with a checksum. What about “repeatable”? The term indicates that any subsequent extraction from the same device must match all previous extractions. The hash value we calculated during the first extraction can be easily compared to the hash values of subsequent extractions. Due to the nature of cryptographic hashes, even a single flipped bit in the data results in a drastically different hash value. If the hashes do match, you can be sure that the two images are identical.

What we’ve seen from many other forensic tools is the use of checkm8 (or even checkra1n) to boot the device in permissive (exploited) mode. The problem with this approach is that they boot the original version of iOS installed on the device, which turns the extraction into live system analysis with authenticated user session. Such analysis, by definition, introduces multiple changes into the very data being extracted. If you were to repeat the extraction, you would get a different image and a different hash value.

This is exactly what we are trying to change with our new, bootloader-based extraction method. Our technology delivers repeatable results across extraction sessions if you follow the correct steps in the right order. When using iOS Forensic Toolkit on a supported device, the checksum of the first extracted image will match the checksums of subsequent extractions. To ensure repeatability, you must keep the device powered off between extractions, and never allow it to boot the installed version of iOS in the meantime.

Our approach

Our direct acquisition method has stark differences compared to all other checkm8-based tools. We were not and are not using a single line of code from the checkra1n jailbreak. We don’t touch, mount, or modify the system partition, and we don’t change a single bit on the data partition. All the patching we do is done in the RAM, and we don’t even need the OS installed on the device as we are booting from an external firmware image downloaded directly from Apple.

Where the first beta was using the code published by the checkm8 team, the new build departs from the checkm8 code base to add support for the new versions of iOS and work around some SEP restrictions. We rewrote the extraction engine pretty much from the scratch, making our tool significantly more robust and widely more compatible compared to the first beta.

Verifiable logical extractions

If you’ve used iOS Forensic Toolkit before, you know how its output looks like when you follow through the advanced logical acquisition workflow. Multiple (sometimes many thousands) files are saved in several folders, making the extraction difficult to validate. This behavior was the reason why we didn’t want adding checksums; it would just take too long considering the sheer number of files in a single backup.

From now on, this is no longer the case. Starting with iOS Forensic Toolkit 8 b2 advanced logical extractions will be rolled into a single TAR archive accompanied with a cryptographic hash value. This allows getting digital evidence with verifiable authenticity from logical extractions as well.

Limitations and future work

This is just the beginning. Our original checkm8 implementation only covers devices including the iPhone 5/5c, 5s, 6, 6 Plus, 6s, 6s Plus, and the original iPhone SE. We are currently working on adding support for more devices including the iPhone 7 and 7 Plus as well as most iPad models based on exploitable SoC. We’re also researching the iPhone 8/8 Plus/iPhone X range, but no definite promises as of yet due to the different SEP implementation in these devices.

What about the passcode? In order to use our solution, you must know the screen lock passcode if one is enabled on the device. The exploit cannot be used to crack the passcode, at least at this time.

Conclusion

The new extraction method is the cleanest yet. Our implementation of bootloader-based exploit is derived directly from the source. All the work is performed completely in the RAM, and the operating system installed on the device is left untouched and is not used during the boot process. The repeatable, verifiable results delivered by the new extraction method help preserve digital evidence from the first point of data collection and establish chain of custody to ensure that digital evidence collected during the investigation remains court admissible.