iOS Forensic Toolkit 7.10 brings low-level file system extraction support for a bunch of iOS versions. This includes the entire range of iPhone models based on the A11, A12, and A13 Bionic platforms running iOS 14.4 through 14.8.

Before this update, iOS Forensic Toolkit could perform low-level extraction of all iPhone models running iOS 9 through iOS 14.3 in a truly gapless fashion. With this update, we made it possible to perform full file system and keychain extraction of iOS 14.4-14.8 for select iPhone models.

Benefits of agent-based extraction

There are several extraction methods of varying quality and applicability. Logical acquisition is the most used method, being the most universal and compatible. In many cases, logical acquisition delivers just enough evidence. However, low-level extraction offers tangible extras such as location data, comprehensive device usage stats, as well as all sandboxed app data including the working sets of secure messaging apps (along with decryption keys, if required).

Low-level extraction can be implemented in several vastly different ways. For older devices, the checkm8 extraction delivers the best results; our solution is unrivaled in providing truly forensically sound results (see Forensically Sound checkm8 Based Extraction of iPhone 5s, 6, 6s and SE and Checkm8 Based Extraction of iPhone 7 and iPhone 7 Plus), with support up to the latest iOS 15.2.

This method is not applicable to newer devices. To deliver low-level extraction for the rest of Apple hardware, we developed an in-house extraction agent that comes as close to being forensically sound as possible. This method is highly dependent on kernel exploits, which are extremely difficult to implement. This is why low-level extraction almost never comes to the current, up-to-date and fully patched versions of iOS. For newer models starting with iPhone Xr/Xs, using the extraction agent is the only way to extract the file system and decrypt the keychain.

What is the extraction agent?

When extracting an iOS device, we still need low-level access to the device. For this, we developed our own solution based on the extraction agent, which is an app sideloaded to the iPhone. The extraction agent establishes a communication channel between the device and the computer, escalates privileges, and gains access to the file and the encryption keys required to decrypt the content of the keychain.

In earlier versions of iOS Forensic Toolkit, we supported iOS versions up to and including iOS 14.3. Today, we are extending support all the way up to iOS 14.8. This includes the complete support (file system and keychain) for iPhone 8, 8 Plus and iPhone X devices.

For iPhone Xr, Xs, Xs Max, iPhone SE (2^nd gen) and the entire range of iPhone 11 devices, the complete support is only possible for iOS versions prior to iOS 14.5. For newer iOS builds (up to and including iOS 14.8) on these platforms only the file system is extracted, but we are working on keychain extraction too.

Using the extraction agent

You’ll need a supported iPhone or iPad device running a compatible version of iOS. Please refer to the following picture for the matrix of supported device models and iOS versions:

Using an Apple ID registered in Apple’s Developer Program is strongly recommended for installing the agent as it alleviates the need to open Internet access on the device. More about that in Why Mobile Forensic Specialists Need a Developer Account with Apple [article]. A workaround is available to Mac users.

Steps to extract the file system and decrypt the keychain

To extract the file system and decrypt the keychain from an iOS device without a jailbreak, follow these steps.

1. Connect the iPhone to your computer. Pair the device (establish trusted relationship) by confirming the prompt on the iPhone and entering the screen lock passcode.
2. Launch iOS Forensic Toolkit 7.10 or newer.
3. On the computer, sideload the extraction agent by using the corresponding command in iOS Forensic Toolkit.
4. On the iPhone, launch the extraction agent by tapping its icon.Windows: developer account required. Use app-specific password.
   macOS: developer account not required but strongly recommended. For non-developer accounts, use the regular password and pass 2FA. If a non-developer account is used, you will have to trust the certificate in device settings; for this, the device must establish an Internet connection. To avoid this, use developer account. For developer accounts, you can use either the regular password and 2FA, or an app-specific password, which you can specify in the EIFT config file to automate authentication.
5. If supported, extract the keychain. The keychain can be extracted from all supported devices and iOS versions except A12/A13 devices running iOS 14.5-14.8.
6. Extract file system image (full file system or data partition). We recommend extracting the data partition only; the full image may be usable e.g. to check the system partition for persistent malware.
7. On the iPhone, uninstall the extraction agent in a regular way.
8. You may now disconnect the iPhone and start analyzing the data.

Windows backups are rarely targeted during investigations, yet they can be the only available source of evidence if the suspect’s computer is locked and encrypted. There are multiple third-part backup tools for Windows, and most of them have password protection as an option. We are adding the ability to break password protection of popular backup tools: Acronis True Image, Macrium Reflect, and Veeam.

Windows backups: why third-party tools?

If you are an Apple user, you might be familiar with Time Machine, the macOS built-in backup tool. Time Machine backups can be protected with a password; we’ll get to that in subsequent articles. Windows does not have a truly convincing built-in system backup tool aside of the ancient “Backup and Restore (Windows 7)” tool that is severely lacking compared to its macOS counterpart. Users cannot encrypt these backups with a password (unless they opt to store them on an encrypted disk, which is a different story).

This is why there are numerous third-party Windows backup tools on the market. There are seemingly hundreds of tools, many of which are long abandoned by their developers. Some of the most popular tools are made by three companies: Acronis, Macrium, and Veeam.

Acronis True Image and Acronis Cyber Protect Home Office

Acronis claims to have over 5.5 million home users and 500,000 companies, which makes its backup tools among the most common among Windows users. The company’s backup tools include Acronis True Image 2020, Acronis True Image 2021, and Acronis Cyber Protect Home Office 2022, which is a rebranding of the company’s older tools. The backups are saved in .tib or .tibx files depending on the version.

Acronis tools use AES encryption with user-selectable 128, 192, or 256-bit keys. Considering the AES-NI instruction set accelerating the encryption, this selection of encryption methods seems rather pointless. It is not immediately obvious why the user would choose a less secure option versus AES-256. The choice of encryption algorithm does not affect the recovery speed in a meaningful way; in our tests, the results were very close regardless of the encryption used.

The older .tib format uses the old MD5 algorithm for hashing the password, resulting in a very high speed of 55,000 passwords per second when performing a brute-force attack using a CPU alone. Newer formats use a different password transformation function, resulting in significantly slower attacks.

Macrium Reflect

Macrium targets IT professionals and companies with its range of backup tools. The company does not disclose the number of users, yet we see Macrium as one of the more popular backup tools among the target group.

While there is a free version of Macrium Reflect, encryption is only available in the paid edition. The available encryption choices are AES-128, AES-192, and AES-256. In a rather counterintuitive way, Macrium limits the choice of available encryption methods depending on the user’s choice of the password. Users who set an 8- to 15-character password are limited to the weakest AES-128 encryption. Setting a 16+ character password unlocks the AES-192 encryption option, while the strongest AES-256 option is only available if the user opts for a 32-character or longer password. This choice of encryption is rather backwards; the stronger (and slower) protection is commonly used to compensate for shorter passwords.

In the case of Macrium Reflect, there is no meaningful difference between the encryption options when it comes to attacking the password. We are getting the speeds of 457 passwords/second on a single Intel i7-9700K CPU, while GPU-accelerated speeds range from 2500 to 7100 p/s or even higher depending on the GPU used, regardless of the encryption algorithm.

Veeam Backup & Replication

Veeam claims to have over 400,000 customers worldwide, which makes Veeam Backup & Replication one of the more common Windows backup tools.

When making an encrypted backup, Veeam Backup & Replication creates several files. Metadata is typically saved into a .vbm file (backup metadata file), while the content is stored in .vbk (full backup) or .vib (incremental backup) files; however, the extensions may be different depending on the tool’s version:

For this reason, we advise to look for the corresponding file in the file system when extracting Veeam encryption metadata:

If the user enables password protection, Veeam Backup & Replication uses AES-256 in CBC mode to encrypt the data. There is no choice of encryption algorithms or key lengths, and there are no artificial limitations when it comes to the password length.

The PBKDF uses SHA1, which is considered a less secure hash function due to the recently discovered collisions. The resulting speeds of brute-force attacks are high: using a single Intel i7-9700K CPU results in 7500 passwords per second, while GPU-accelerated recovery can break passwords at a rate of 45,000 to 120,000 passwords per second.

Benchmarks

We compared the speed of password recovery attacks among the three backup tools in different hardware configurations.

The older Acronis .tib format is the least secure of the three, with 55,000 passwords/s on a single CPU. Veeam offers comparatively weak protection with rather high recovery speeds using GPU acceleration. Macrium Reflect and recent versions of Acronis offer comparable protection.

How to Break Backup Passwords

When attacking a password, the traditional forensic workflow requires uploading the entire encrypted file or document into a password recovery tool. This approach, while simple and intuitive, has a major drawback when it comes to larger files such as system backups. The solution is obvious: use just the required minimum of information to run the attack. In the case of backups, this means you would only need a very small part of a file that contains the encryption metadata such as the hash and salt values. To use encryption metadata, you will need two tools working together: a tool to extract the encryption metadata from the files you are about to attack, and the tool that can use the extracted data to perform the attack.

When using Elcomsoft Distributed Password Recovery, the encryption metadata is handled by a small tool: Elcomsoft Hash Extractor, which is included in the package. You will first need to run Elcomsoft Hash Extractor to extract encryption metadata from Acronis, Macrium, and Veeam backups, then open the extracted metadata in Elcomsoft Distributed Password Recovery to launch the attack.

To extract encryption metadata, follow these steps.

1. Launch Elcomsoft Hash Extractor.
2. From the main window, specify the type of files or documents you are about to extract hashes from.
3. Open the files and click Process.
4. Save the resulting file.

Once you are done, collect the extracted hash files and open them in Elcomsoft Distributed Password Recovery instead of the original backups.

The new year is just around the corner, and so it’s the right time to review our achievements in 2021. We’ve done plenty of researching, developing and updating, and posted a great deal of content in our blog. Let’s run through the most exciting developments of the year!

Mobile Forensic Bundle – the R&D champion

In 2021, Elcomsoft iOS Forensic Toolkit received the most love and the most work. From the very beginning till the end of the year we kept adding features and extending support for new devices and iOS versions.

Our exclusive acquisition agent enables safe low-level extraction without a jailbreak, with iOS 14.8 support currently in the final testing.

Forensically sound, repeatable and verifiable checkm8-based extraction is a hallmark we are truly proud of. It is the smartest, safest, and the most complete extraction method for a wide range of devices running all version of iOS including the current iOS 15.2.

We brought back support for legacy Apple devices, bringing high-speed passcode unlock for iPhone 4 and 5/5c devices.

• Elcomsoft iOS Forensic Toolkit in 2021.

Elcomsoft Phone Breaker extended Microsoft account support and added the ability to use a trusted iOS device to authorize iCloud extractions.

• Elcomsoft Phone Breaker  in our blog.

Desktop Forensics – better bundle up!

For desktop forensics we have a higher number of tools which also got their updates. Our go-to solution for accessing encrypted disks and containers, Elcomsoft Forensic Disk Decryptor, can now handle BitLocker volumes created in the latest Windows 10 build (20H2).

The chain of custody begins from the first point of data collection, and we updated our tool for in-field investigations. Elcomsoft System Recovery has become truly forensically sound with write-blocking mode engaged by default.

Elcomsoft Distributed Password Recovery now supports the full range of disk encryption tools from the usual suspects (BitLocker, LUKS, PGP, TrueCrypt / VeraCrypt, FileVault 2) to BestCrypt Volume Encryption with quite an exotic protection.

Advanced Office Password Recovery now offers blazing fast, guaranteed recovery of encrypted .doc and .xls files saved in Office 97/2000 compatibility mode. Advanced Archive Password Recovery brought support for RAR5 and 7Zip archives

Our Blog: 12 years of sharing knowledge with you

Twelve years back, we launched our blog as a tool to keep our customers updated about the new releases of our tools and give insight information about the technologies empowering our products under the hood. More than 50 articles out of 500 in total have been written this year.

Mystically enough, the greatest recognition this year has gained the article about Bitlocker TPM protection written by our teammate Andrey Malyshev who left us this year. Andy, you will always stay in our hearts and memory.

The popularity of our articles in social networks and search engines signifies well deserved success in our effort to deliver quality content. Guys, we love writing for you!

Here is a top-5 selection of articles from our blog in 2021:

• Understanding BitLocker TPM Protection
• Breaking VeraCrypt: Obtaining and Extracting On-The-Fly Encryption Keys
• DFU Mode Cheat Sheet
• Breaking the iPhone 12: Forensic Extraction of iOS 14 Devices
• Breaking RAR5 and 7Zip Passwords

Have a good reading if you missed these articles and thank you again for placing your trust in our tools, developments and expertise.

May you and your dearest ones have Happy Holidays and a safe New Year!

BestCrypt, developed by the Finnish company Jetico, is a cross-platform commercial disk encryption tool directly competing with BitLocker, FileVault 2 and VeraCrypt. Volume encryption is available for Windows and macOS. Learn how to break BestCrypt full-disk encryption by recovering the original password!

Full-disk encryption and crypto-containers

When it comes to disk encryption software, there are generally two major options. One encrypts the entire disk or partition; this is how LUKS works in Linux, BitLocker in Windows, and FileVault 2 in macOS. The other creates a virtual disk image (a so-called “crypto-container”), usually stored on existing disk volumes in a single encrypted file or a set of files. For this purpose, many users choose VeraCrypt. BestCrypt offers a commercial, cross-platform alternative to these encryption tools. Currently, BestCrypt comes in two separate editions, BestCrypt Volume Encryption offering full-disk encryption and BestCrypt Container Encryption encrypting virtual disk volumes stored in files.

We already had support for BestCrypt containers; more on that in Breaking Jetico BestCrypt. Today, we’re adding support for Jetico’s full-disk encryption tool, BestCrypt Volume Encryption 5.

What about the previous version of BestCrypt Volume Encryption, version 4? There are two notable differences between BestCrypt Volume Encryption 4 and BestCrypt Volume Encryption 4. First, the v5 adds a new encryption option: the ARIA-256 algorithm. Second, the developers enabled a custom number of hash iteration, but for some reason only for the newly added ARIA-256 encryption algorithm. This does not change the attack or the workflow; the same principles and steps of password recovery apply to both generations of BestCrypt Volume Encryption.

Encryption

Similar to open-source encryption tools such as TrueCrypt/VeraCrypt, BestCrypt supports multiple encryption algorithms including AES, ARIA, Camellia, Serpent and Twofish. According to BestCrypt developers, every algorithm is implemented with the largest possible key size defined in the algorithm’s specification, all available with the most secure XTS encryption mode. In our experience, the choice of the encryption algorithm does not affect the speed of attacks. Choosing any encryption algorithm other than AES dramatically reduces the speed of data access for the end user, without delivering any tangible increase in security. If anything, choosing the wrong algorithm may hinder security by exposing the encrypted data to any vulnerabilities that may be discovered in such algorithms.

What does affect security (and the speed of the password recovery attack) is the choice of the hash algorithm and the number of hash rounds (iterations) used in the corresponding Password-Based Key Derivation Function.

Hash function

It is important to understand that the data on the encrypted disk is never encrypted directly with the user’s password. You may be surprised to learn that the data is encrypted with a long, binary, randomly generated key that has zero dependence on the user’s password.

Moreover, that encryption key is stored in the encryption metadata alongside with encrypted information. Naturally, a question arises: can we extract that key from the encryption metadata and use it to decrypt the files and folders? No we can’t: the key (often called a Media Encryption Key, or MEK) is encrypted with yet another key, the Key Encryption Key (KEK). The Key Encryption Key, in turn, is encrypted with the user’s password – but not directly.

The password is transformed into a binary key with numerous rounds of a certain one-way mathematical function, which is called a “hash function”; the correct name for the transformation function is PBKDF, or Password-Based Key Derivation Function. The resulting key is then used to encrypt (or decrypt) the Media Encryption Key, which we need to decrypt the data.

Traditionally, disk encryption tools make use of one or more well-known hash functions to perform the encryption. The most common choices are SHA-512, SHA-256, Whirlpool (512-bit), while the older SHA-1 should no longer be used due to the recently discovered collision. These hash functions are extremely fast to calculate, which would mean an extremely fast attack. In order to slow down potential attacks, developers of encryption tools use multiple thousands of rounds (or iterations) of the hash function to calculate the final encryption key.

Developers of password recovery tools, such as us, are well aware of that approach. We are using hardware acceleration, utilizing the massively parallel GPU cores found in today’s video cards to speed up the recovery by the factor of 50 to 500 compared to a CPU alone.

No GPU attacks

BestCrypt developers seem to be aware of the fact, and, instead of bumping the number of hash rounds to the million, decided to go with a hash function that cannot be accelerated with a GPU. The hash function used in BestCrypt full-disk encryption is called Scrypt. This algorithm is as fast as SHA-256, yet by design it makes it very costly to perform large-scale hardware-accelerated attacks by requiring large amounts of memory. Scrypt is also very common in newer crypto currencies.

The choice of the hash function makes GPU acceleration impossible since each thread would require a massive amount of memory, which the GPUs simply do not possess. As a result, you’ll be restricted to CPU-only attacks, which may be very slow or extremely slow depending on your CPU. To give an idea, you can try 18 passwords/sec on a single Intel Core i7-7700HQ CPU @ 2.80GHz (8 threads), or about 25 passwords/s on a single Intel Core i7-3930K CPU 3.20GHz (12 threads). Modern CPUs will deliver a slightly better performance, but don’t expect a miracle: BestCrypt’s PBKDF using the Script hash algorithm is made deliberately slow.

To give a point of reference, the same Intel Core i7-3930K 3.2GHz x12 CPU delivers a higher recovery speed for BestCrypt Container Encryption, which uses more traditional hash functions.

BestCrypt Container Encryption, Intel Core i7-3930K CPU 3.20GHz (12 threads):

• sha3-512 53 p/s
• Whirlpool-512 150 p/s
• sha-512 196 p/s
• Skein-512 262 p/s
• sha-256 273 p/s

BestCrypt Volume Encryption, Intel Core i7-3930K CPU 3.20GHz (12 threads):

• Scrypt 25 p/s

No OTFE keys

For many encrypted disks, extracting the encryption key directly from the device’s RAM, its page or hibernation file is the way to go. If live system analysis is performed while the encrypted container is mounted, one may be able to dump the content of the computer’s RAM into a file and scan that file for on-the-fly encryption keys, which can be used to mount or decrypt the data without attacking the original password. Breaking VeraCrypt: Obtaining and Extracting On-The-Fly Encryption Keys describes the benefits of this approach, which can be summed up as guaranteed, near-instant access to encrypted data without the need for a lengthy attack on the password.

At this time, we do not support the extraction of on-the-fly encryption keys from the device’s RAM, hibernation or page files. The function is currently under development.

Breaking BestCrypt Volume Encryption 4 and 5 passwords

Our tools can break BestCrypt Volume Encryption 4 and 5 passwords that are protected with password based encryption. Follow these steps to set up an attack.

Step 1: Extract encryption metadata

During the first step, you must extract encryption metadata from the encrypted disk or virtual volume. Unlike TrueCrypt/VeraCrypt, BestCrypt stores information about the encryption algorithm, hash function and the number of rounds in the disk header. This encryption metadata helps set up an attack by automatically applying the correct settings. The encryption metadata can be extracted with Elcomsoft Forensic Disk Decryptor, which is included with Elcomsoft Distributed Password Recovery and available separately.

Elcomsoft Forensic Disk Decryptor is a powerful tool for accessing encrypted disks. A limited version of this tool included with Elcomsoft Distributed Password Recovery. You can use Elcomsoft Forensic Disk Decryptor users to set up attacks on a tiny file instead of the original encrypted container. Since no raw or encrypted data is included in encryption metadata, the hash files produced with Elcomsoft Forensic Disk Decryptor offer significantly higher level of privacy, allowing remote and cloud processing without the risk of a data leak.

To extract encryption metadata, do the following.

1. Launch Elcomsoft Forensic Disk Decryptor.
2. Specify the BestCrypt disk to extract encryption metadata from.
3. Save the encryption metadata.

Once you are done, collect the extracted hash files and open them in Elcomsoft Distributed Password Recovery to set up the attack.

Alternatively, you may use Elcomsoft System Recovery to extract encryption metadata from the target computer by booting from the USB media. In this case, use the following workflow:

1. Prepare bootable USB media with Elcomsoft System Recovery on your computer (not the target computer).
2. Boot the target computer from that USB media.
3. In Elcomsoft System Recovery, specify the BestCrypt disk to extract encryption metadata from.
4. Save the encryption metadata.

Once you are done, bring the extracted hash files to your computer and open them in Elcomsoft Distributed Password Recovery to set up the attack.

Step 3: Use Distributed Password Recovery to break the password

Launching an attack against a BestCrypt disk is as simple as opening the encryption metadata you obtained in Step 1 with Elcomsoft Distributed Password Recovery. However, you may want to modify the attack as opposed to using brute force.

While BestCrypt does its best to protect encrypted disks against GPU-accelerated attacks by choosing Script as a hash function, you can still use the power of distributed computing by splitting the task to multiple computers on the local network or over the Internet. We have significant advances in password recovery attacks. Breaking a password today involves the use of targeted dictionaries and smart attacks supported by Elcomsoft Distributed Password Recovery. The user’s existing passwords are an excellent starting point. These passwords can be pulled from the user’s Google Account, macOS, iOS or iCloud keychain, Microsoft Account, or simply extracted from the user’s computer. The user’s existing passwords give a hint at what character groups are likely used:

Elcomsoft Distributed Password Recovery offers a number of options to automatically try the most common variations of your password (such as the Password1, password1967 or pa$$w0rd):

Masks can be used to try passwords matching established common patterns:

Advanced techniques allow composing passwords with up to two dictionaries and scriptable rules:

Backups are the primary way to preserve data. On smartphones, backups are handled automatically by the OS. Windows lacks a convincing backup app; numerous third-party tools are available, some of which feature strong encryption. Computer backups may contain valuable evidence that can be useful during an investigation – if you can do something about the password.

Mobile backups

For mobile devices such as smartphones and tablets backups are generally not an issue. Apple users enjoy the convenience of fully automated and highly comprehensive iCloud backups (with an option to create local, encrypted backups via iTunes or Finder). Google Android also offers backups, yet Google’s solution relies largely on synchronized data as opposed to backups. Since Android 9, Google backups are end-to-end encrypted with the user’s passcode. Apple, on the other hand, does not employ end-to-end encryption for iOS cloud backups, yet it uses the technology to protect some types of synchronized data (such as the user’s passwords). Apple’s local and cloud backups along with synchronized data (including end-to-end encrypted types) can be obtained with Elcomsoft Phone Breaker.

When it comes to local backups, Apple offers the ability to create plain or password-protected backups with the iTunes app (or Finder in modern versions of macOS). Password-protected backups contain more usable evidence compared to their unencrypted counterparts, yet the encryption of iOS backups is extremely strong. Breaking a password to a local iOS backup will be as slow as some 10 to 50 passwords per second even if you use a fast GPU. While it may be possible to reset the backup password, this requires access to the device itself, and you will have to enter its screen lock passcode. If the backup is all you have, your options will be limited.

The slow password recovery speed rules out the brute-force approach. You will need to target your attacks based on the human factor using custom dictionaries, masks and mutations in Elcomsoft Distributed Password Recovery.

Desktop backups

For Apple and Google smartphones, the backups are generally not an issue. macOS computers have Time Machine, a truly excellent backup system. Time Machine backups can be protected with a password, and we are yet to cover that. The Windows OS, however, lacks a convincing built-in backup tool. The Backup and Restore (Windows 7) is severely limited in functionality, and does not support encryption at all (Microsoft recommends saving backups onto a BitLocker-encrypted disk if security is important). There is also File History, which is far from comprehensive.

The lack of built-in backup tools made numerous third-party developers release their own Windows backup tools. There are perhaps too many of them, making it difficult to choose just the right one. Some of these tools offer password protection and backup encryption; we’ll talk about that in the next article. The upcoming January release will support passwords to some desktop backup tools; stay tuned for updates!

Encrypted backups: breaking the password

As mentioned above, the brute-force approach is no longer sufficient to break modern backups even if you use a high-end GPU for accelerating the recovery process. You must target the human factor to break most passwords. These attacks include using targeted dictionaries based on known passwords, dictionaries based on leaked password, automated mutations and smart attacks supported by Elcomsoft Distributed Password Recovery.

You can use Elcomsoft Internet Password Breaker to extract the list of the user’s passwords from their computer. You can also extract their passwords from their Google or iCloud account, macOS or iOS keychain, or the user’s Microsoft Account. The user’s existing passwords give a hint at what character groups are likely used:

Elcomsoft Distributed Password Recovery offers a number of options to automatically try the most common variations of your password (such as the Password1, password1967 or pa$$w0rd):

Masks can be used to try passwords matching established common patterns:

Advanced techniques allow composing passwords with up to two dictionaries and scriptable rules:

Conclusion

Backups are a valuable source of digital evidence. Backups are often protected with a password; strong encryption makes the recovery slow even on modern hardware. Accessing encrypted evidence requires using a combination of hardware acceleration and smart attacks targeting the human factor.

Last month we introduced forensically sound low-level extraction for a range of iPhone devices. Based on the renowned checkm8 exploit, our solution supported devices ranging from the iPhone 5s through 6s/6s Plus/SE. Today, we are extending the range of supported devices, adding checkm8 extraction of the iPhone 7 and 7 Plus.

Prior work

Exactly one month ago, we released the second beta version of iOS Forensic Toolkit 8.0. The second beta became the first publicly available one. That release introduced true forensically sound extraction for a range of iPhone and iPad devices that have a bootloader vulnerability making them susceptible to the checkm8 exploit.

What is “forensically sound” extraction, why you may need it, and how our extraction process differs from competing implementations? These questions are addressed in the Forensically Sound Extraction for iPhone 5s, 6, 6s and SE writeup.

To sum it up, our solution delivers true forensically sound extraction of the iPhone file system, including the keychain. Since all the patching occurs entirely in the device’s RAM, we never boot (and don’t even need) the operating system installed on the device. The result is reliable, verifiable and repeatable extraction. If you use iOS Forensic Toolkit to image the iPhone file system, power off the iPhone, store it for any period of time, then repeat the extraction process, you are guaranteed to get exactly the same result; the checksums of the two images will match.

The new beta also changes the UI. Instead of the menu-driven console, we are readying the tool for the new user experience. In the meanwhile, the beta version is driven via the command line. The experience differs significantly from iOS Forensic Toolkit 7, so much so that we published a manual: How to Use iOS Forensic Toolkit 8.0 b2 to Perform Forensically Sound Extraction of iPhone 5s, 6, 6s and SE

iPhone 7 support

The second beta supported quite a few devices ranging from the iPhone 5s through iPhone 6s, 6s Plus, and the original iPhone SE. Missing from the list were the iPhone 7, 7 Plus, and the entire iPhone 8/8 Plus/iPhone X range of devices. While we are still working on the latter, the iPhone 7 and 7 Plus support has arrived.

Meet iOS Forensic Toolkit 8.0 beta 3 for Mac! The tool expands the range of supported devices, adding support for iPhone 7 and 7 Plus devices, enabling bootloader-based, forensically sound extraction of supported devices running the latest available versions of iOS. The following models are added:

iPhone 7 (iPhone9,1 and iPhone9,3)

• A1778 (Global)
• A1660 (USA & China)
• A1780 (China)
• A1779 (Japan)
• A1853
• A1866

iPhone 7 Plus (iPhone9,2 and iPhone9,4)

• A1784 (Global)
• A1661 (USA & China)
• A1785 (Japan)
• A1786 (China)

The iPhone 7 support breaks down into the following parts. For iPhone 7 and 7 Plus devices that run iOS 10.0 through 13.x the complete, forensically sound checkm8 extraction experience. The tool can extract the file system and decrypt the keychain with zero modifications to the device, thus helping maintain the chain of custody. There is no need to remove the passcode.

For iPhone 7 and 7 Plus devices running iOS 14 and 15 (up to and including iOS 15.2), you’ll have to remove the screen lock passcode to apply the exploit. Since removing the passcode requires booting the device into the original OS, this process is not forensically sound. Once the passcode is removed, the tool makes full file system extraction and decrypts the keychain.

The full compatibility matrix is outlined below.

Note: the iPhone 6s and 6s originally shipped with iOS 9.0.1 onboard, while the iPhone SE was shipped with iOS 9.3. The iPhone 5s originally shipped with iOS 7.0, which is currently not supported for checkm8 extraction.

Placing the device in DFU mode

Placing the device in DFU mode can be tricky, especially if you’ve never done it before. DFU is different from Recovery in that Recovery was designed to be used in emergency situations by the end user, while DFU was never meant for the end user.

Steps to enter DFU are less than obvious, and there is no on-screen indication of successfully entering DFU. You must follow the steps while carefully observing the timings, and the end result will be a blank screen. To make the process easier, iOS Forensic Toolkit implements real-time guidance, indicating which buttons are to be pressed and implementing countdown timers.

The instructions are described in the following article: DFU Mode Cheat Sheet

If any of the device buttons is broken, follow these instructions instead: How to Put an iOS Device with Broken Buttons in DFU Mode

Also note that you may need a hub to install the exploit if you are using an Apple Silicon Mac: More on checkm8 and USB Hubs, Upcoming iPhone 7 Support.

Why the keychain is important

The keychain extracted from the device via low-level acquisition is very important. It contains all the passwords, authentication tokens and encryption keys to the most secure apps such as Signal. While most of these are included in password-protected local backups, some of the most secure parts (such as the Signal encryption keys) won’t be backed up at all. The only way to access these bits and pieces is performing the low-level extraction.

With this release, EIFT can extract the full keychain via the checkm8 exploit from all supported devices running all versions of iOS up to and including iOS 15.2. This feature is unique to iOS Forensic Toolkit.

Limitations and future work

There is one limitation about the iPhone 7 extraction with checkm8. For older devices, we could use the detected iBoot version to identify the iPhone iOS version. We do our best to guesstimate the iOS version, but using one version up or one version down usually does the trick as well. This is no longer the case for the iPhone 7; you must use the firmware that matches the installed iOS build exactly. If you use the wrong version, the iPhone will either reboot or fail to unlock the data partition. This means that you may have to try several times until the correct version of firmware is found.

We are in the middle of the journey. Our original checkm8 implementation now covers most devices that are vulnerable to checkm8. These range from the iPhone 5s all the way to the iPhone 7 and 7 Plus, with caveats. Currently, you must remove the screen lock passcode from iPhone 7 and 7 Plus devices running iOS 14 or 15, which breaks the “forensically sound” part. We are working on these restrictions; keep an eye on our blog for news to come.

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.

Getting the beta version

iOS Forensic Toolkit for Mac beta 3 is a public build available to everyone with a non-expired license. You’ll need your EIFT dongle (and, obviously, a Mac) to run the tool.

Conclusion

With this update, Elcomsoft iOS Forensic Toolkit becomes the most advanced iOS acquisition tool on the market. The toolkit now supports all possible acquisition methods (with known limitations we’re working on). Agent-based extraction and checkm8-based extraction via device RAM are some of the tool’s unique features.

Before the end of this year, we are releasing one last update. Advanced Office Password Recovery can now break 40-bit encryption in Microsoft Office documents, and gains support for Thunder Tables. What are Thunder Tables exactly, and is 40-bit encryption still relevant? Read along to find out.

What’s it all about?

For a very long time, we had two distinctly different tools sharing very similar names. Almost nobody could tell difference between Advanced Office Password Recovery and Advanced Office Password Breaker, let alone pick the right tool for the job. We’re finally ending this madness confusion, getting rid of the other tool and integrating its features into the one and only tool: Advanced Office Password Recovery.

What is it for?

In a word, it’s for quickly breaking the encryption of password-protected DOC and XLS files, which are Microsoft Word and Excel documents saved by modern versions of the app in the “compatibility” format as opposed to the current DOCX and XLSX formats. You’ll be surprised to learn how many companies are still using these “compatible” with Office 97/2000 apps, but totally insecure formats. The following formats are supported:

• Microsoft Office 97 and 2000: these versions of Microsoft Office use 40-bit encryption exclusively
• Microsoft Office XP and 2003: 40-bit encryption is used by default; adds optional CSP support
• Newer versions of Microsoft Office: documents saved as “Word 97-2003 .doc” or “Excel 97-2003 .xls” still using 40-bit encryption

Licensing

We’ve simplified licensing of the new product, too. Instead of having a number of Home, Standard, Professional and Forensic editions in two different products, we are now featuring just two: Home and Forensic editions. The main difference is the inclusion of Elcomsoft Thunder Tables into the Forensic edition; more on them below.

Microsoft Office: still using legacy encryption in “compatible” formats

So why Microsoft Office apps are still using legacy encryption when you save a document as a .DOC instead of .DOCX? The reason is buried deep in the history.

Microsoft Office 97 was once released with deliberately weak encryption due to US export restrictions. This exact encryption scheme was carried over to Microsoft Office 2000, even though by the time the export restrictions ceased to exist. The native US versions of Microsoft Office could be configured to use somewhat stronger encryption, yet the setting was rarely enabled because of compatibility concerns – the same concerns that are driving many organizations today to keep using the “compatible” DOC/XLS formats for their document workflow.

Technically speaking, the “compatible” formats are using the RC4 cipher for encryption and MD5 for hashing. A deliberately weak 40-bit encryption key and a single iteration of MD5 hashing are used to protect information.

Even 20 years ago, 40-bit encryption was considered weak enough to be cracked in reasonable time. Today, several hours of brute forcing is all you need to break 40-bit encryption on an average consumer-grade CPU; much less if you use a video card.

In other words, Advanced Office Password Recovery today can decrypt a password-protected Word .doc documents or an Excel .xls spreadsheet saved as “compatible” within a guaranteed, limited timeframe. The exact time needed for the attack will depend on your CPU power alone, and will NOT depend on the length and complexity of the user’s password.

However, brute forcing is not even needed to break 40-bit encryption. Meet Thunder Tables!

The Thunder Tables

Back in the day, crunching through the entire set of 40-bit encryption keys would take several days on an average computer. To cut this time, we fully refactored all possible 40-bit keys to build Elcomsoft Thunder Tables , an extension of the Rainbow Tables attack. Using Thunder Tables, you can break all compatible Word documents and about 97% of compatible Excel spreadsheets in just seconds instead of hours. The Thunder Tables are available in the Forensic edition of Advanced Office Password Recovery. You can read more about the Thunder Tables in Thunder Tables Explained | ElcomSoft blog.

Prior to this release, users would have to obtain Thunder Tables separately by either copying them from the supplied DVD or flash drive or manually downloading them from our Web site. This is no longer the case: Thunder Tables will be downloaded automatically when you need them. Advanced Office Password Recovery automatically detects the document format and the type of encryption, and suggests downloading Thunder Tables if the document uses 40-bit encryption. Thunder Tables are exclusive to the Forensic edition; Home edition users still have an option to brute-force all available 40-bit keys, which is plenty fast on modern CPUs.

Thunder Tables take a lot of space on your computer; think several GB of data. By default, the tables will be stored in %APPDATA%\Elcomsoft Password Recovery\Thunder Tables. If your system drive does not have the amount of free space required, or if you don’t want to store something as large as Thunder Tables on your boot drive, consider specifying a different path. You can do that by editing the
following Registry key:

Computer\HKEY_CURRENT_USER\SOFTWARE\Elcomsoft\Advanced Office Password Recovery\TTPath

No password required

It is important to note that the actual password is not needed to decrypt documents. Instead, we attack the binary encryption key. If, for any reason, you absolutely must recover the password, you can run a GPU-assisted attack that offers speeds in the order of tens of millions password combinations per second.

Conclusion

The Advanced Office Password Recovery update simplifies the recovery of Microsoft Office documents by automatically choosing the best attack, offering guaranteed timeframe decryption for legacy formats and GPU-assisted password recovery for modern documents with strong encryption.

WhatsApp is the fastest growing instant messenger app. With over 2 billion monthly users, WhatsApp keeps the crown of the most popular instant messaging tool in the Western hemisphere. The recent introduction of end-to-end encrypted backups and the change of Google’s authentication protocol broke things temporarily for EXWA users, but now everything is back to normal. Learn how Elcomsoft Explorer for WhatsApp can download and decrypt encrypted WhatsApp communication histories from Google Drive and Apple iCloud!

WhatsApp is secure. The iOS and Android apps make use of the Open Whisper Signal communication protocol to secure communications with end-to-end encryption. Recently, WhatsApp started rolling out end-to-end encryption of its cloud backups to offer an optional extra protection layer.

WhatsApp is extremely popular, easily being the number one instant messenger in the Western hemisphere. This, combined with its end-to-end encryption, make WhatsApp a popular tool among the criminals. Terrorists, scammers, extortionists and child molesters don’t hesitate using WhatsApp to lure their victims, plan and coordinate illegal activities. While end-to-end encryption is great for protecting personal privacy and civil liberties of ordinary users, stopping criminal activities was the primary driving force behind our decision to release Elcomsoft Explorer for WhatsApp.

WhatsApp end-to-end encrypted everything

WhatsApp advertises end-to-end encryption all around. Both messages in transit and the backup copies of users’ conversations are securely encrypted in such a way that only the original user and their recipient can access the messages. As to the backups, only the owner of the backup can decrypt the data, and only after successful authentication. The general idea behind end-to-end encrypted backups is described in End-to-End Encrypted Backups on WhatsApp – WhatsApp Blog, while the company shared some technical details in How WhatsApp is enabling end-to-end encrypted backups (fb.com).

The thing is still very new, being rolled out slowly in stages to the entire 2 billion users crowd. The new end-to-end encrypted backups are stored as .crypt14 files, implementing a new encryption algorithm. To access the data, you’ll need a unique cryptographic key that can be only obtained from the WhatsApp server after successful authentication. Without access to that cryptographic key, there is no way to decrypt the backup or access the conversation history – unless you are able to hack the device and do the low-level extraction thing.

There is one more thing that makes the extraction of the new (crypt14) backups difficult. Not only are the backups encrypted by WhatsApp with a unique encryption key, but downloading such backups from the corresponding cloud service (Google Drive or Apple iCloud depending on the platform) requires authenticating into the corresponding cloud service.

That’s a lot of authentication, and that’s a lot of things that can go wrong should Google, Apple, or WhatsApp make a change into their proprietary authentication or communication protocols, encryption, or the data format. This is exactly what happened some months ago: Google broke Google Drive authentication, while WhatsApp introduced end-to-end encrypted backups and also made a few changes to the format of internal tables. That was enough to break Elcomsoft Explorer for WhatsApp for the time being.

Interestingly, media attachments (images and videos) are still stored without any encryption at all, let alone end-to-end encryption. To access those, you’ll just need to authenticate into the corresponding cloud service (Google or Apple).

Elcomsoft Explorer for WhatsApp was updated to automatically download and decrypt end-to-end encrypted backups from the user’s iCloud and Google accounts. The cryptographic key is generated automatically based on the authentication code received as a text message and delivered to the user’s trusted phone number.

Work in progress

WhatsApp developers are working hard to deliver new features and increased security. End-to-end encryption was there since the beginning thanks to the choice of the Open Whisper Signal communication protocol. End-to-end encrypted backups are becoming a thing right now, literally at this very moment. There are several other things in WhatsApp that are not yet supported in our tool.

User key/password: this optional feature allows the user to encrypt their backups with a custom key or password. We are aware of the feature and are currently working on it.

In iOS, stand-alone WhatsApp backups are saved in iCloud Drive. While we do support the extraction of these backups from non-2FA accounts, we are currently struggling with iCloud Drive accounts protected with two-factor authentication. There is a fix in the pipeline; stay tuned for news.

Group calls. Elcomsoft Explorer for WhatsApp does not support them for the time being.

Google accounts with Google Prompt. Google Prompt is the default two-factor authentication method for many Google accounts. This method is also the easiest to use, as the only action the user needs to make is tapping “Yes” on the corresponding prompt. In certain cases, using Elcomsoft Explorer for WhatsApp to access the user’s Google Account requires two confirmations of the Google Prompt instead of one.

No FIDO keys 2FA for Google accounts. At this time, we do not support two-factor authentication with FIDO keys. A fix is in the pipeline, but no ETA.

Conclusion and additional information

WhatsApp is a moving target, and we do our best to deliver the most comprehensive WhatsApp extraction and decryption tool on the market. Stay tuned!

• Extract and Decrypt Android WhatsApp Backups from Google Account | ElcomSoft blog
• Extract and Decrypt WhatsApp Backups from iCloud | ElcomSoft blog

Installing the checkm8 exploit to perform forensically sound extractions with iOS Forensic Toolkit can be tricky, which is in part due to certain hardware peculiarities.  If you watch our blog, you might have already read the article on checkm8, checkra1n and USB hubs. We have some good news: we managed to fix some of the issues with or without the use of a USB hub.

What’s it all about?

As mentioned in the previous article, some devices in some circumstances may be picky about the way you connect the iPhone to the computer. Since checkm8 extraction requires a native Mac, we would generally recommend using a direct connection with a single USB-A to Lightning cable. Some Macs don’t have any Type-A ports, so one could naturally think that using the original (or certified third-party) Type-C to Lightning cable would be the right thing to do. Wrong! These cables have a different ID, and the checkm8 exploit would fail to install if you used such a cable. Oddly enough, some of the cheapest no-name Type-C to Lightning cables just worked; mostly those with no PD charging. I wouldn’t rely on that, though, as the different batches of no-name cables are made by all sorts of different OEMs, so the next one may or may not work with about equal probability.

The recommended solution would be using a single-port Type-C to Type-A adapter, and connecting the Type-A to Lightning cable to the corresponding port. This solution always works on Intel-based Macs; however, it just doesn’t seem to work reliably on the Macs built with Apple Silicon. For those Apple Silicon Macs we would generally recommend using a USB hub, just like the one shown below:

All that is old news; what had changed in iOS Forensic Toolkit to warrant a new blog post? We’ve managed to catch a few bugs and optimize the code to make things more reliable with or without the hub. The current state of affairs is shown below:

• If you are using an Intel Mac: we’ve made everything work reliably both with and without USB hubs. If you still experience problems, try the Type-A connection, but generally USB hubs are no longer an issue worth mentioning.
• If you are using an M1 (Apple Silicon) Mac: using a USB hub is still recommended as everything connected through it works reliably.
• If you are using an M1 (Apple Silicon) Mac without a USB hub, and connecting certain specific iPhone models: some iPhone models will require reconnecting during the process; iOS Forensic Toolkit will prompt for a reconnection. Some other iPhone models will not work without a USB hub at all.

The table below specifies which devices will require a reconnection, and which ones will require a USB hub on Apple Silicon Macs:

iPhone 7 support is coming soon

Our R&D just committed an update to iOS Forensic Toolkit with preliminary support for the iPhone 7. The next beta will feature a limited support for iPhone 7 devices. The beta build still has the following restrictions for iPhone 7 devices:

• iOS 10.x through 13.x: file system extraction and keychain decryption; removing screen lock passcode not required.
• iOS 14.x and 15.x: the screen lock passcode must be removed in order to perform the extraction. Note that this breaks forensically sound extractions. We are currently developing a workaround, which won’t be included in the first beta.

Stay tuned!

Many security practices still widely accepted today are things of the past. Many of them made sense at the time of short passwords and unrestricted access to workplaces, while some were learned from TV shows with “Russian hackers” breaking Pentagon. In this article we’ll sort it out.

Change your password. Do it on a monthly basis.

The necessity of changing one’s password to keep accounts secure is an ancient myth. The requirement to change passwords periodically is counterproductive. According to a recent study, Most People Have 70-80 Passwords. Changing this number of passwords monthly would quickly turn things into a mess, while changing only one or two passwords (and keeping the rest unchanged) would make zero sense. We can observe the practical result of such policies in sequential or very similar passwords that are humanly possible to remember. Password2019, Password2020, Password2021 are just examples, but they are close to what we’ve seen.

What if your system administrator sets a strong, random password instead of letting you pick your own one? Such passwords are the first candidates for the infamous yellow sticker, which brings us to the next myth.

Don’t write it down!

The “yellow sticker” has become a synonym for unsafe passwords that are insecurely stored alongside with protected device or media or are directly exposed to everyone.

Don’t keep your passwords in a place where they can be seen by someone who is not supposed to see them. Don’t store your passwords alongside with protected devices or media.

However, there’s nothing inherently wrong in writing your password down on a piece of paper provided that you store that piece of paper in a safe place. The definition of a ‘safe place’ varies. In your office, that might be the safe or even a locker. At home, it could be a simple drawer. The point is, a random passer by should not be able to see or easily access the password. In any case, do not attach that piece of paper to the device or media you are protecting.

Paper-based security might be fine for your purpose, but password managers could be a better solution.

Let’s use a password manager!

While there is nothing wrong in using a password manager per se, do your due diligence first. As an example, common Web browsers such as Google Chrome or Microsoft Edge have an option to store and synchronize your passwords through their respective cloud services. However, the passwords are not additionally encrypted, and anyone with access to your unlocked Windows PC can view your passwords in a few clicks with a simple app. In addition, anyone who knows your login and password (and can pass two-factor authentication if you’re using that) can retrieve your passwords from the cloud.

This is not exactly the case with other types of passwords. For example, the popular open-source password manager BitWarden has an option to automatically lock your password vault after a certain inactivity period, after which an attacker will need to enter your master password to decrypt the vault.

Password managers are a great option to store a number of strong, unique passwords no sane person would ever remember. Just do your due dilligense when choosing, and set a strong and unique master password if one is supported.

My data is secure because it’s encrypted with AES-256

Nope! AES-256 is a great encryption algorithm to protect data at rest. However, the cipher itself is only a part of the equation. Consider the cipher being the gate. As secure as the gate is, there are also the lock, and the key, and the fence. No one in their sane mind will ever attack the 256-bit encryption key. An attacker will try to pick the lock (by attempting to guess your password), or steal the key (by obtaining your password from wherever it’s stored), or jump over the fence (by extracting the key from your computer’s RAM), or… There are many effective attacks out there, but not a single one targeting the encryption algorithm itself.

A good example of strong encryption done wrong is covered in Synology NAS Encryption: Forensic Analysis of Synology NAS Devices. Should the user decide to automatically unlock encrypted volumes on boot, the system stores the encryption key alongside with the encrypted data, protecting the key with a fixed, known default passphrase “$1$5YN01o9y”. There are numerous other issues with this implementation such as the inability to change or passwords or revoke compromised keys, making this AES-256 based encryption significantly less secure than one might think.

Let’s not use AES-256 then! We need custom encryption

Not again… AES-256 is perfectly fine as an encryption algorithm. In Breaking VeraCrypt containers we tested the strength of the different encryption algorithms, and discovered that there is literally no difference in attacking AES-encrypted and Serpent-encrypted VeraCrypt containers. Granted, there are some 15 encryption options the user can choose from. The thing is, the choice of an encryption algorithm has almost no effect on the speed of the password recovery attack. The attack is affected by the choice of a hash function and the number of hash iterations, which most users have no idea about. The choice of any encryption option other than AES slows down the read/write speed of the encrypted container, but hardly affects its security.

There is no need to substitute AES with a different encryption algorithm to secure your data. You can read more about it in It’s Hashed, Not Encrypted.

Standard solutions are easy to break. Let’s make our own!

It’s a very sad situation for everyone involved when your IT security specialist wants to make everything from scratch. A recent example is covered in Tally ERP 9 Vault: How to Not Implement Password Protection. The developers decided that AES encryption and standard PBKDF were not secure enough to protect the data in their accounting product, and invented their own hash and encryption functions. The result was a total disaster. I invite you to read the article linked above to realize that “custom” solutions can become your worst enemy.

SMS is insecure, so I’ll skip two-factor authentication

Any two-factor authentication is better than no two-factor authentication. Granted, there are multiple ongoing issues with cellular networks such as described in Easy SMS Hijacking – Schneier on Security. The error here is in causation. The SMS is a poor choice of two-factor authentication. However, any 2FA is better and infinitely more secure than no 2FA. If you have an option to use a different 2FA method, by all means use it. If not, and the SMS is the only way of doing 2FA, then use SMS as a “much better than nothing” option.

All we need is a secure password

While your password should be reasonably complex and reasonably secure, there are much more important qualities of a good password than just its length and entropy (“randomness”). If you use the same strong and complex password to protect several different accounts, don’t be surprised if multiple accounts of yours are hacked in quick succession. Don’t be obvious either; in How to Break 30 Per Cent of Passwords in Seconds and How to Break 70% of Passwords in Minutes we listed the commonly used attacks that can be and will be performed on your passwords.

A single strong password is not enough. All of your passwords must be unique and not following an obvious pattern. They must be reasonably strong (with emphasis on “reasonably”), and they shouldn’t be found in the Top-10,000 Passwords list.

Is surveillance a good or a bad thing? The answer depends on whom you ask. From the point of view of the law enforcement, the strictly regulated ability to use real-time surveillance is an essential part of many investigations. In this article we’ll cover a very unorthodox aspect of real-time surveillance: iCloud.

Smartphones have become commonplace. These personal communication devices are used for everything from browsing the Internet to socializing with other users, taking pictures, shopping and doing a lot more. The “lot more” may include activities that some users would prefer to hide. Modern smartphones are designed to keep everything stored on the device securely encrypted to keep the data away from attackers with physical access to the device. There are ways that do not require physical access to the device in order to access the user’s data: one can get lots and lots of information about the user, often in real time, by accessing the vendor’s cloud service. This effectively turns smartphones into always-on personal surveillance devices.

Before we begin, it is important to realize several things: what Apple knows about its users; what Apple does not know (or does not want to know) about them; and what you can extract based on what you know. Sounds confusing? Read along!

What Apple knows

What Apple knows about its users is not necessarily what you will be able to get. Some parts of the data are specific to Apple the company, such as the user’s visits to Apple Store or their Genius Bar appointments. Some parts of the data are simply not stored in iCloud (or at least we don’t know if they are). Some other data, such as the user’s keychain passwords, are stored in iCloud but Apple does not have access to that data because of end-to-end encryption.

So what does Apple know about its users? At this time, the following types of data are synchronized with iCloud without end-to-end encryption:

• Account information
• Photos (iCloud Photo Library), if enabled and if there is enough space in the user’s iCloud account
• Contacts, notes, calendars
• Call history
• Wi-Fi access points and passwords
• Apple Wallet
• iCloud Mail
• Books (iBooks), including PDF documents and third-party books added by the user
• Stocks, Weather
• Shortcuts
• iMovie, Clips
• iCloud Drive: Pages, Numbers, Keynote documents, other files

All of that data is synchronized with iCloud automatically and almost in real-time.

What Apple does not know

As we have mentioned above, some types of data, such as the user’s keychain passwords, are stored in iCloud but Apple does not have access to that data because of end-to-end encryption.

• Safari history, bookmarks, open tabs
• Apple Maps (searches, routes)
• iCloud Keychain (the passwords)
• Messages (SMS, iMessages, attachments)
• Apple Health (steps, heart rate if wearing Apple Watch, etc.)
• Screen Time password
• Voice memos

These types of data are additionally encrypted (on top of the “normal” iCloud encryption) with a key that is re-encrypted with the user’s device passcode (or multiple passcodes if there are several devices with different passcodes). Since Apple does not know the user’s device passcode, it does not have access to the user’s passwords or messages and does not know which Web sites they visit in Safari or what tabs they have open on their device. Apple refers to this protection scheme as “end-to-end encryption”. As a rule of thumb, Apple will not provide these types of data when serving legal requests; however, you may still be able to access them almost in real-time if you know the user’s password or have access to one of their trusted devices.

A trusted device can be used for surveillance

What happens if you lose your iPhone? If it meets certain conditions, it can be used to establish surveillance over your entire iCloud ecosystem, which includes data from all other devices.

Which iPhones can be used for surveillance?

1. It’s an old model (up to and including the iPhone 8/8 Plus/X range), and the screen lock passcode is known or empty, or
2. It runs an old version of iOS (up to and including iOS 14.3 at this time, while 14.5.1 is in the works), and the screen lock passcode is known or empty.

There are additional caveats. While the iPhone 8/X can be exploited, one will have to remove the screen lock passcode to install checkra1n if they are running iOS 14 or later. This effectively prevents access to the data protected with end-to-end encryption, yet all other information will remain accessible. In addition, if these models are running iOS 15, you won’t be able to install checkra1n at all as it currently only supports iOS 14.x and older versions.

Granted, it is extremely unlikely that you lose an old iPhone with its passcode conveniently written on the back, and you hadn’t updated it for a year, but you’ll be surprised how many of these devices are kept in the backroom of many forensic experts.

The tool

We have a tool for that! Elcomsoft Phone Breaker makes it possible to download the content of the user’s iCloud, enabling access to synchronized data, including end-to-end encrypted categories. At this time, Elcomsoft Phone Breaker is the only third-party solution on the market allowing to access end-to-end encrypted data and iCloud backups saved by iPhone and iPad devices running any version of iOS.

Additional information

We have more information on the subject, namely in these articles:

• Apple iCloud Keeps More Real-Time Data Than You Can Imagine | ElcomSoft blog
• iCloud Backups, Synced Data and End-to-End Encryption | ElcomSoft blog
• Hey Dude, Where Is My iCloud Data? | ElcomSoft blog
• Using a Trusted Device for iCloud Authentication | ElcomSoft blog

Conclusion

iCloud account credentials can be used to establish real-time surveillance over the users of Apple’s ecosystem. The most relevant types of data include iCloud messages (SMS and iMessage), Web sites and tabs opened in the Safari browser, as well as Health data (steps and heart rate). It is not a coincidence that all of these categories are end-to-end encrypted, requiring the use of one of the user’s screen lock passcodes to access and decrypt.

iCloud Photos, if enabled, are also a great source of data that is not protected with end-to-end encryption. Aside of their documental and artistic context, the photos typically store precise location information in the accompanying EXIF tags, which is one of the more important types of information for the purpose of real-time surveillance.

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 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 chis 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 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.

The second beta of iOS Forensic Toolkit 8.0 has arrived, offering repeatable, verifiable extraction for a limited range of iOS devices. The new release introduces a brand-new user interface, which differs significantly from the selection-driven console we’ve been using for the past several years. This article describes the new workflow for performing forensically sound extractions with iOS Forensic Toolkit 8.0 beta2.

Compatibility

The bootloader-level extraction is still exclusively available in the Mac edition due to technical limitations. You still need a real, physical Mac computer, no VMs and no Hackintosh builds. Both Intel and Apple Silicon are supported. At this time, iOS Forensic Toolkit has been tested on the following versions of macOS: 10.13 High Sierra, 10.14 Mojave, 10.15 Catalina, 11 Big Sur, and 12 Monterey.

The vulnerability exploited by checkm8 exists in a large number of devices ranging from the iPhone 4s all the way to the iPhone 8/8 Plus/X generation. However, our tool does not support the iPhone 4s due to the USB controller requirements; the iPhone 7, 7 Plus, 8, 8 Plus, and iPhone X are not currently supported due to SEP hardening. You may still extract these devices by other means such as using the extraction agent or going through a jailbreak.

At this time, forensically sound bootloader-level extractions are available for the following devices:

• iPhone 4 (iPhone3,1/iPhone3,2/iPhone3,3): A1332, A1349
• iPhone 5 (iPhone5,1): A1428, A1429, A1428
• iPhone 5c (iPhone5,4): A1507, A1526, A1529, A1516
• iPhone 5S (iPhone6,1/iPhone6,2): A1453, A1533, A1457, A1518, A1528, A1530
• iPhone 6 (iPhone7,2): A1549, A1586, A1589
• iPhone 6 Plus (iPhone7,1): A1522, A1524, A1593
• iPhone 6s (iPhone8,1): A1633, A1688, A1691, A1700
• iPhone 6s Plus (iPhone8,2): A1634, A1687, A1690, A1699
• iPhone SE (iPhone8,4): A1662, A1723, A1724
• iPod touch 6th gen: A1574
• AppleTV 3 (AppleTV3,2): A1469

Our tool supports all versions of iOS from iOS 8.0 to 15.1 (only release versions, no betas).

Installing iOS Forensic Toolkit 8.0

The installation procedure has changes since previous releases. To install iOS Forensic Toolkit 8.0 beta 2, follow these steps:

• Mount the DMG image specific to your version of macOS, supplying the password (you will receive the password in your order confirmation email)
• Drag the “EIFT8B2” folder to the desktop
• Open console
• Run xattr to remove quarantine:

  xattr -r -d com.apple.quarantine <path to folder>

• Alternatively, you can type part of the command (xattr -r -d com.apple.quarantine ), and drop the image onto the console window. Please note the whitespace at the end of the command.
• cd Desktop/EIFT8B2
• You can now launch /EIFT_ cmd to run the tool

The DMG image is different for macOS Catalina and older versions and the newer Bit Sur and Monterey. The file names are as follows:

• iOS-Toolkit-8-beta2-Mac-legacy.dmg for Catalina and older
• iOS-Toolkit-8-beta2-Mac.dmg for Bit Sur and Monterey

Command line parameters

For the past several years, iOS Forensic Toolkit was distributed with console-based, menu-driven UI. In EIFT 8.0 beta2, we have replaced the old UI with a console-based, command-line driven tool. There was a good technical reason for this, but please reserve your questions until the final release version of iOS Forensic Toolkit 8.0.

The available parameters include:

Main commands

Please do not use any of the following commands unless instructed:

• ssh
• scp
• serial
• tools

Device information

Commands related to logical acquisition

Commands for agent-based extraction

Commands for jailbreak-based extraction

Ramdisk-related commands (when extracting via bootloader exploit)

Additional commands: ssh, scp

Bootloader-level extraction cheat sheet

Technically speaking, bootloader-level extraction was the most challenging to implement in code. This extraction methods requires experts to possess a certain level of skills and experience in handling iOS devices and placing them into DFU. The cost of a mistake is high: shall you fail to follow the sequence of precisely timed key presses, and the device may start booting iOS, which breaks the “forensically sound” part of the extraction. For this reason:

Practice DFU mode and familiarize yourself with the extraction process on a different iPhone device before you start the extraction.

Once you’re able to place the iPhone into DFU 10 times out of 10, follow these steps with the real device.

Below are the steps for the following 64-bit devices: iPhone 5s/6/6s/SE.

1. Place device into DFU
2. ./EIFT_cmd boot
3. ./EIFT_cmd loadnfcd
4. ./EIFT_cmd unlockdata
5. ./EIFT_cmd ramdisk keychain -o {filename}
6. ./EIFT_cmd ramdisk tar -o {filename}
7. ./EIFT_cmd ssh halt

Bootloader-level extraction step by step

First, place the device DFU (several methods described in DFU Mode Cheat Sheet). The recommended method:

• Connect the device to a computer using a USB cable (USB-A cables only! If connecting to a Type-C port, use a Type-C to USB-A adapter, and a USB-A cable; no hubs, no Type-C to Lightning cables!)
• Hold down both the Home button and Lock button
• After 8 seconds, release the Lock button while continuing to hold down the Home button (шf the Apple logo appears, the Lock button was held down for too long)
• Nothing will be displayed on the screen when the device is in DFU mode. If open, iTunes will alert you that a device was detected in recovery mode (If your device shows a screen telling you to connect the device to iTunes, retry these steps)

Note that, unlike the checkra1n jailbreak, our tool does not require going through Recovery first before entering DFU.

After that, execute the following command:

./EIFT_cmd boot

The command launches the exploit. The code detects the iOS version installed on the device and provides a download link. If there are multiple potential matches, several download links will be displayed; we recommend taking the last link from the list. Download the file from the link, and drop the ipsw file onto the console window.

Our extraction solution does not use the operating system installed on the iPhone to boot the device. Instead, a separate, patched version of the original Apple firmware is booted in the device RAM. This process requires you to have a copy of the original Apple firmware image that matches the device’s iOS version and build number exactly.

In many cases, the iOS version will be detected automatically by EIFT during the first stage of the exploit. The detection is based on the detected iBoot version and device hardware. However, in some cases the iBoot version may correspond to several iOS builds. If the wrong build is used, EIFT will be able to detect and display the correct build number at a later stage of the exploit. You will then have an option to either repeat the exploit with a different version of firmware, or continue with the current firmware image (which works in about 99% of cases).

If the exploit successfully loads the firmware, you will see the following information:

The iPhone will display the following screens:

./EIFT_cmd loadnfcd

This command executes the code to bypass Secure Enclave protection. This must be done before you can mount the data partition.

./EIFT_cmd unlockdata

This command unlocks the data partition and mounts it read-only.

If you enter the wrong passcode, an error will be displayed. With correct passcode, the volume is fully unlocked and you can proceed with data (keychain and file system) extraction).

If you don’t know the passcode, press ENTER on the screen below. In this case, a very limited BFU extraction will be performed.

After 5 or 6 wrong passcode entries, the iPhone will be locked for 1, 5, 15 and 60 minutes in succession. You must wait for the block to expire. After 10 unsuccessful unlock attempts, regardless of the wait time, the system will wipe the encryption metadata, making subsequent extraction attempts futile.

./EIFT_cmd ramdisk keychain -o {filename}

This command extracts and decrypts the keychain. If no path is specified, it will be saved into the current folder. There are specific considerations for some iOS versions:

• iOS 15: keychain decryption is currently not available.
• iOS 8 through 14: all keychain records decrypted except a small number of system records.

./EIFT_ cmd ramdisk tar -o {filename}

This command images file system. The checksum (hash value) is calculated on the fly and saved alongside with the image file once the extraction is finished.

./EIFT_cmd ssh halt

This command powers off the iPhone. Always use this command at the end of the extraction as it is not possible to power off the iPhone with the buttons from DFU. If you try pressing and holding the power button, the iPhone will reboot and load the installed version of iOS, which breaks forensically sound extraction.

If you ever used the checkra1n jailbreak or the checkm8 acquisition method available in some mobile forensic products like iOS Forensic Toolkit, you know that the trickiest parts of the process are the first two: entering DFU, and using the exploit itself. Even if you have the right cables and enough experience, sometimes you may still bump into a weird issue or two. The device may not enter DFU whatever you do, or the exploit fails. How can you increase your success rate?

Cables first

You need the right cable for everything to work. Type-C to Lightning cables rarely work; always use a USB-A cable instead. Here’s the technical explanation (from checkra1n Installation Tips & Tricks):

The BootROM will only enter DFU if it detects USB voltage, which boils down to checking whether a certain pin is asserted from the Tristar chip. The Tristar does this based on the cable’s accessory ID, and apparently USB-A and USB-C cables have different accessory IDs, and the one of the USB-C cables makes the Tristar not assert the USB voltage pin.

But what if your Mac has the Type-C ports only? Just use a USB-C to USB-A connector, but not a USB hub. Most probably you will even need two: the second one for the USB dongle that most forensic products require. Also, you may need to use the third port to connect an external drive to save the data extracted from the iPhone.

What about the Macs based on the Apple Silicon? Please read The state of checkra1n on Apple Silicon Macs first, in particular:

The problematic part of the exploit can be disabled and replaced with a manual unplugging and replugging of the lightning cable.

There is actually an easier and safe workaround: if you experience troubles using checkm8 on an M1-based Mac, use a USB hub. Yes, that’s right; the very thing that causes problems on Intel Macs can be your savior on Apple Silicon. That’s true for the iPhone 6s and iPhone SE (first generation) at least: when they are connected though a hub, checkm8 works like a charm without reconnections.

Our mobile acquisition tools, Elcomsoft iOS Forensic Toolkit and Elcomsoft Phone Breaker, support a number of different extraction options. While many of our readers know the differences between logical and physical acquisition in general better than most, there are some things in our software making the logical/physical dilemma somewhat different. In this article, we laid out the differences between the extraction methods as implemented in our tools.

Logical acquisition

Today, “logical” acquisition becomes “extended logical” or “advanced logical”, as it not only extracts the well-known iTunes-style backup, but also media files (via the afc protocol), which includes photos, videos, music, and downloads, along with their metadata. All that works even if the backup if password protected. In addition, this method helps extract crash and diagnostic logs, which are difficult to parse, yet can really help to build the device usage timeline. Finally, this method can also extract the shared files. While most applications keep their data in their respective sandboxes, some apps allow external access, including even some password managers. Logical is the most universal, compatible, and easy to use acquisition method, but it returns a limited set of data.

Direct checkm8 extraction

This acquisition technique is theoretically available for all models based on the A5 through A11 SoC. The reality is different. The exploit itself is relatively easy to use, but that’s only part of the work. The next stage (extracting the data) is significantly more difficult. If implemented properly, this method is forensically sound and extracts everything down to the last bit, including the keychain. However, there are implementation issues for the A11 models (the iPhone 8/X and some iPads) running iOS 14 and 15: it looks like there is no way to obtain the data until the passcode is removed. Removing the passcode is generally not recommended as it has a lot of negative consequences, not saying that it is not always possible.

Acquisition agent

Elcomsoft’s acquisition agent returns the full set of data (just like with checkm8), but in itself is limited to the systems for which a kernel exploit is available. At this time, we have a full and reliable implementation for iOS 9 through 14.3, and support for some newer version is in the works (up to iOS 14.5.1 at least). Note that this method is not fully forensically sound, but very close to it. Also, it is absolutely safe to the device; the worst you can get is a reboot.

iCloud extraction

After many years, this method is still underestimated, probably due to the legal issues that vary across jurisdictions. Its main benefit is the fact that you do not even need the device itself. On the other hand, you need the user’s iCloud credentials (and a passcode of one of the trusted devices in order to get “end to end encrypted” data). While this method will not grant access to most system databases and application data, but you can get a lot of other data – and from several devices, not just one. Sometimes the historical data is also available, the one that is already deleted from the iPhone with no chance to recover.

Compatibility issues

Currently, only two methods are 100% compatible with all iPhone models and iOS versions: logical and iCloud. The other two (checkm8 and agent) have a large number of compatibility issues with both the hardware and iOS versions.

The above is the current compatibility status of all methods supported by our software; we will of course keep working on all of them, closing the remaining gaps – see below.

Future work

As you can see, our checkm8 implementation does not cover the iPhone 7, iPhone 8 and iPhone X yet. Support for the iPhone 7 is on the way; its SEP is different from the one we already know how to work with, and we need more time to create reliable code for it, keeping it forensically sound. The iPhone 8/X is a bigger headache, especially with iOS 14 and above; not sure if BFU extraction will be ever possible for the last version, but we are doing our best to at least make an extraction of the data partition without the need to remove the passcode.

Agent acquisition also needs improvements. We strive to improve it with every release, doing our best to make it as reliable as theoretically possible, and this is complex: you know, all the exploits we use have their own problems, and success rate (to get root access) depends on many factors. Our main target here is extending iOS version support beyond iOS 14.3, and we have a feeling that 14.4, 14.4.1, 14.4.2, 14.5 and 14.5.1 support will be achieved soon. We usually do not make forward-looking statements, but the work on new versions (up to 15.0.1) is also in progress.

To tell you the truth, iCloud acquisition is also in the works: we are expanding the range of iCloud categories to download (although we already support the wide range, some are still left out). Also, iOS 15 brings some surprises; the encryption basically remains the same, but the data format changed in some categories. And of course, we are making the whole process faster and more reliable.

Conclusion

We are proud to offer one of the most advanced and iOS acquisition solutions on the market. The latest build of Elcomsoft iOS Forensic Toolkit now delivers true forensically sound extraction of select iOS devices, offering repeatable, verifiable results after subsequent extractions. Elcomsoft Phone Breaker delivers best-in-class iCloud extraction, being the only tool on the market to access end-to-end encrypted data.

If you are doing Apple Watch forensics, I’ve got some bad news for you. The latest model of Apple Watch, the Series 7, does not have a hidden diagnostics port anymore, which was replaced with a wireless 60.5GHz module (and the corresponding dock, which is nowhere to be found). What does that mean for the mobile forensics, and does it make the extraction more difficult? Let’s shed some light on it.

What is the value of Apple Watch data? The Apple Watch not only save lives, but there are multiple cases like this one: Apple Watch Could Decide a Murder Case. There could be devices to extract the data from, but getting anything out of a locked iPhone may not be possible. In addition, the Apple Watch collects more data (such as heart rate), which can be important for digital forensics.

Extracting the Apple Watch has always been a headache. We covered this topic before:

• Apple TV and Apple Watch Forensics 01: Acquisition
• Apple Watch Forensics 02: Analysis

In a nutshell, there are three ways to get something out of a smart watch:

• Directly from the device
• From the iPhone the Watch is paired with
• From iCloud

Direct extraction requires an adapter connected to the diagnostics port. The Watch has no backup service running, just the AFC protocol (for media files), logs, device info and the list of apps installed, along with some metadata; there is no known workaround for watches locked with a passcode.

If you are extracting Watch data from the iPhone, expect very limited amounts of data. It’ll be mostly just the settings (as opposed to iPhone acquisition, where more methods can be used).

iCloud stores Apple Health data, but authentication credentials are required (and as far as Health data is “end to end encrypted”, you’ll need a passcode of one of the trusted devices as well).

The Watch itself is often the only source of data, like in the Assassination of Jamal Khashoggi case; that time some evidence was extracted from the cloud though.

Speaking of the Apple Watch connection, an adapter is always needed (or was required before Apple Watch S7). For a long time, the only adapters available were for the S1/S2/S3 series. The first generation IBUS adapters were unreliable, but later we discovered some better ones, covered in Apple Watch Forensics Reloaded.

The newer models such as the S4, S5, S6 and SE also use adapters; refer to Apple Watch Forensics: The Adapters for details. I took a picture of my table with some of those, and some Apple Watch (S2-S4) as a reference:

I have two personal favorites: the original Apple-built adapter (shown in the middle; extremely hard to find) because of the highest quality and compatibility; and MagicAWRT (top right), which is also high quality at fair price (and compatible with all watch models prior to S7). I haven’t had a chance to try the S-DOCK (bottom left), though it also looks solid (and the Lightning connector looks compatible with the serial cable, which is good for development).

Finally, what would you need for the acquisition? Elcomsoft iOS Forensic Toolkit to send the data over to the PC or Mac. We currently offer limited logical acquisition only, but we are working on checkm8 implementation for S2/S3. You can also use Elcomsoft Phone Breaker to extract the data from iCloud, including “end to end encrypted” categories.

iOS security model offers very are few possibilities to recover anything unless you have a backup, either local or one from the cloud. There are also tricks allowing to recover some bits and pieces even if you don’t. In this article we’ll talk about what you can and what you cannot recover in modern iOS devices.

Before we begin, I highly recommend reading our previous article aimed at demystifying bogus claims made by some unscrupulous vendors of data recovery tools: The iPhone Data Recovery Myth: What You Can and Cannot Recover. Below are the types of data you can actually recover.

Deleted records from SQLite databases

Apple stores many types of user data in various databases in SQLite format. Once the user deletes a record (such as an iMessage from the Messages app, or a Safari bookmark, or a history item), that record is not wiped clean in the SQLite database immediately due to performance considerations. Instead, the SQLite engine marks the record as “deleted”, marks the page as unused, adds a reference to the so-called “freelist”. Such deleted records could be stored in SQLite “freelists” for some time, which left room for data recovery tools to attempt the recovery.

The recovery trick would only work if:

1. You were able to extract the affected SQLite database with a low-level extraction tool (read: you need a jailbreak or Elcomsoft iOS Forensic Toolkit).
2. The database itself had not been vacuumed or defragmented, in which case the deletion becomes permanent (read: you must act soon).
3. You must be quick enough, extracting the affecting database in a matter of seconds after the record was deleted. Since iOS 12, the system wipes deleted records almost immediately after they are deleted. Since this is hardly practical, you are very unlikely to ever recover SQLite records deleted in iOS 12 and newer.

To sum it up, the SQLite trick is no longer effective for deleted iMessages, Safari bookmarks, tabs and history, or any other types of data stored in SQLite databases. Let’s forget about this trick, and move to the next one.

Data from WAL files

As we learned earlier, all even remotely recent versions of iOS effectively prevent the recovery of deleted records (be it messages, call logs or contacts) by quickly vacuuming SQLite databases. However, there is another feature of SQLite databases that may give us a chance. SQLite keeps new records in so-called Write Ahead Logs (WAL files). If such unmerged records are deleted, they are left in their respective WAL files until the moment they are merged with the main database, which means that some unmerged deleted records may still be recoverable.

This recovery trick works if:

1. You are using low-level access to the file system (read: you need a jailbreak or Elcomsoft iOS Forensic Toolkit).
2. The WAL files are still unmerged (read: you must act soon).
3. You have not created an iTunes backup between the time the record was deleted and the time of extraction. The moment you start the backup, the WAL files are merged with their respective main databases, and the deleted records are lost.

There is one exception to #3: media files. When extracting media files (from all kinds of devices including the iPhone, iPad, Apple Watch and Apple TV models) with iOS Forensic Toolkit, you’ll also receive unmerged WAL files. This allows recovering some image metadata.

Data from old local backups

The smartest data recovery trick is not a trick at all. If you have an old backup, then you have the data. If you do have a local backup, the only question is how to access the data without restoring the entire backup onto some iOS device. There are many tools on the market, including Elcomsoft Phone Viewer, allowing to parse the content of local backups, view or extract individual files or database records (e.g. messages or log entries).

Note that you will be able to access more information if your iTunes backup was password-protected. For the purpose of data recovery, it’s already too late to configure a password, yet we recommend setting up a strong backup password for security purposes.

Data from older iCloud backups

This trick is similar to the previous one, but not exactly the same. If you have cloud backups (I’d recommend checking if you actually do, as Apple’s free tier only includes 5GB of iCloud storage), you may have older copies of your data that you can download (with Elcomsoft Phone Breaker) and analyze (with Elcomsoft Phone Viewer). Notably, Apple keeps two last iCloud backups (used to be three), making it possible to download the oldest one.

There are other differences from local backups. For example, iCloud backups will normally not contain photos if you enable iCloud Photo Library (there is a manual override for that setting); they won’t contain some other kinds of synchronized data as well, depending on your sync settings and the version of iOS your device is running.

iCloud backups will not include any of the following:

• Keychain *
• Health data
• Home data
• iCloud Photos **
• Messages **
• Since iOS 13: Call logs
• Since iOS 13: Safari history

* In fact, the keychain is still there, but it is encrypted using a device-specific key. You won’t be able to access keychain items from iCloud backups unless you restore onto exactly the same device.

** Messages are not included if (and only if) the iCloud syncing of those categories is not enabled in device settings. Photos have a manual override, allowing you to keep both synced and backup versions (naturally, doubling the storage requirements).

Synchronized data

iPhones can synchronize many types of data to iCloud. The sync is supposed to happen in real-time, or very close to it. Anything you delete from the iPhone shall be also deleted from the cloud, but… there is always a ‘but’. If your iPhone was not online between the time you deleted a synchronizable item and the time you attempted the recovery, you have a very good chance to get that item back. In addition, there might be sync delays that would allow the recovery even after some time have passed. I personally wouldn’t count on it, but there is a chance. You can try Elcomsoft Phone Breaker to see what might be available.

There are also exceptions. Some categories (Photos and Notes for sure, but there may be others) remain available in iCloud for a long time (usually around 2 or 3 weeks) after they’ve been removed from the “deleted” folder. A few years back, Apple would even keep such files indefinitely. You can read more about synchronized data in iCloud Backups, Synced Data and End-to-End Encryption.

Why no deleted files?

If I have access to the file system, can I carve the free space to look up for deleted data? Unfortunately, you cannot. Since iOS 4, Apple encrypts the file system, and since iOS 8 the encryption keys are based on the user’s passcode. In layman’s terms, the files on the user partition (such as the images, SQLite databases and such) are encrypted. Moreover; each file is encrypted with an individual key, which will be erased immediately after you delete the file.

IMAGE dpkeys.png

(Source: Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions (securephones.io))

In layman’s terms, the iOS file system (Apple uses APFS across devices; some older pre-iOS 10.3 devices using HFS+) has the following properties:

1. Nearly everything is encrypted.
2. Each file is encrypted with its own unique key.
3. All encryption keys are encrypted with another (common) key.
4. That common key is calculated when the user enters their passcode on first unlock.

Once you delete a file, iOS also erases the corresponding File key from the file’s metadata. As a result, even if you were to read the data blocks previously occupied by the deleted file, you would be unable to decrypt it without the File key.

If you reset your device to factory defaults (the “Erase all data” option), the Effaceable Storage is erased, which destroys the common key. This alone would render the data undecryptable and inaccessible, even if the NAND storage was not erased.

As you can see, undeleting files the way you can do it for rotating hard drives installed in a computer is simply not an option. There are no data recovery tools that can recover user files deleted from the iPhone.

Of course, this is a simplified scheme that does not take into account the differences between AFU and BFU mode and the fact that some files (very few except the main OS) are not encrypted.

Conclusion

In this article, we described the available option allowing you to recover data deleted from the iPhone. Unsurprisingly, you get the best backups when restoring from a backup (whether a local or cloud copy). In rare cases there is a small chance of getting limited success by downloading synchronized data from iCloud in the hope the iPhone did not sync the deletion. SQLite write-ahead logs (WAL) are only practically usable for media files metadata, which has extremely limited value to anyone except the forensic crowd. Low-level techniques are limited to the extent of being useless.

When accessing a locked system during an in-field investigation, speed is often the most important factor. However, maintaining digital chain of custody is just as if not more important in order to produce court admissible evidence. We are introducing new features in Elcomsoft System Recovery, our forensic triage tool, to help establish and maintain digital chain of custody throughout the investigation.

In order to preserve digital evidence, the chain of custody begins from the first point of data collection. For this reason, the traditional workflow used in computer forensics involves powering off the computer, pulling and imaging its storage media through a write-blocking device. These steps helps ensure that digital evidence collected during the investigation remains court admissible. With Elcomsoft System Recovery, we introduce a viable alternative to hardware-based write blocking disk imaging devices while offering real-time access to crucial evidence. Elcomsoft System Recovery is a digital triage tool for examining computers in the field. The tool helps overcome the challenge of accessing a locked system, delivering a straightforward workflow for investigating computers in the field. From the technical standpoint, Elcomsoft System Recovery is a Windows PE based bootable tool designed to safely image the target computer’s internal media, locate encrypted volumes and unlock encrypted virtual machines. In its latest release, the tool offers write-blocking, verifiable disk imaging.

Write-blocking disk access

Elcomsoft System Recovery 8.0 helps producing court admissible evidence with write-blocking mode and read-only disk imaging. The write-blocking mode is engaged by default during the first steps of running Elcomsoft System Recovery, ensuring that no data is modified on the target computer. In this mode, you can image disks and partitions, locate encrypted disks and extract encryption metadata, and use the supplied two-panel file manager to analyze the file system.

From this release onwards, write-blocking disk access becomes the tool’s default behavior. You will have to explicitly untick the “read-only” check box to access system management functionality such as resetting Windows user and administrative passwords.

Verifiable disk imaging

You can image connected disks into verifiable .E01 images. Together with read-only access, the use of hashing helps establish digital chain of custody, while employing the industry-standard .E01 format makes the images compatible with third-party forensic tools for comprehensive analysis.

certutil -hashfile FILENAME md5|sha1|sha256

MD5 hash of disk.e01: 0d8a7ca3d87bf6c202c26dc363983836
CertUtil: -hashfile command completed successfully

Producing a verifiable disk image in write-blocking mode

To enable read-only access and produce a verifiable disk image, follow these steps.

1. Download and run Elcomsoft System Recovery 8.0 or newer on your computer (not on the target computer).
2. Prepare Elcomsoft System Recovery bootable USB drive. Check Elcomsoft System Recovery: a Swiss Army Knife of Desktop Forensics | ElcomSoft blog for step by step instructions.
3. Configure target computer to boot from a USB device.
4. Boot target computer to Elcomsoft System Recovery.
5. You will be prompted to accept the License Agreement. At the bottom of the prompt you will see a check box enabling forensically sound, read-only access to the computer’s storage media. This check box is selected by default. Click Next to continue in read-only mode.
6. Create forensic disk images for further in-lab analysis. To produce a verifiable forensic disk image, choose the .E01 format. Multiple checksums will be embedded into the image to ensure data integrity, and the entire image will be signed with a hash value once the process completes.
   

In certain cases, Elcomsoft System Recovery may be unable to mount one or more disks in read-only mode. This may happen in the following cases:

1. You are booting Elcomsoft System Recovery from read-only media (such as a bootable CD/DVD drive, SD card in read-only mode, or a USB flash drive in read-only mode), or if there is not enough free space on the ESR bootable drive. We suggest installing Elcomsoft System Recovery onto a regular USB flash drive, a portable SSD drive or a portable hard drive with no write protection and plenty of available free space.
2. The name of the logical volume is “X”. All other volumes can be mounted read-only, except for disk “X:”, which is a Windows PE limitation.

If this happens, the following occurs:

1. If Elcomsoft System Recovery is unable to mount one or more disks read-only, it will display a warning.
2. Once you close the warning, the “read-only access” check box remains selected. If you want to continue without write blocking, you’ll have to manually unselect the check box and click Next. Alternatively, you may choose to stop using Elcomsoft System Recovery, power off the computer, pull the hard drives and image them offline.

While working in read-only mode, you will be able to make disk images, extract page and hibernation files, locate and mount BitLocker volumes, and extract encryption metadata. System management activities such as resetting passwords to Windows user accounts are not permitted in this mode. If you attempt to perform a management task, you will see the following warning:

Notes and troubleshooting

Note that any BitLocker volumes you mount after engaging the read-only mode will be also mounted read-only. The read-only mode will be deactivated when you shut down the computer via Elcomsoft System Recovery. If the computer locks up or the power is lost during the investigation, the disks on the target computer will remain read-only, which will prevent the computer’s normal operation. To fix this, you will have to boot into Elcomsoft System Recovery again, after which the tool will automatically detect the issue and will prompt to re-mount the disks in the regular read-write mode.

About Elcomsoft System Recovery

Elcomsoft System Recovery is a digital triage tool for examining computers in the field. The tool is particularly useful if the computer being analyzed is locked or is inaccessible due to unknown account passwords and/or full disk encryption. Elcomsoft System Recovery helps overcome the challenger of accessing a locked system, delivering a straightforward workflow for investigating computers in the field. The tool helps access information in encrypted disks and encrypted virtual machines, extract passwords and access encrypted file systems.

Conclusion

The already powerful tool can now maintain digital chain of custody. The combination of write-blocking access and verifiable disk images make Elcomsoft System Recovery a viable alternative to hardware-based write blocking disk imaging devices while offering a faster and easier forensic analysis workflow.

Many Linux distributions including those used in off the shelf Network Attached Storage (NAS) devices have the ability to protect users’ data with one or more types of encryption. Full-disk and folder-based encryption options are commonly available, each with its own set of pros and contras. The new native ZFS encryption made available in OpenZFS 2.0 is designed to combine the benefits of full-disk and folder-based encryption without the associated drawbacks. In this article, we’ll compare the strengths and weaknesses of LUKS, eCryptFS and ZFS encryption.

Encryption in NAS Devices

While Linux users may or may not encrypt their data, all major manufacturers of Network Attached Storage (NAS) devices offer some sort of encryption at least in some models. We have published a number of articles about the types of encryption used in the various NAS devices:

• NAS Forensics: TrueNAS Encryption Overview
• NAS Forensics: QNAP Encryption Analysis
• Attached Storage Forensics: Security Analysis of ASUSTOR NAS
• Attached Storage Forensics: Security Analysis of TerraMaster NAS
• Attached Storage Forensics: Security Analysis of Thecus NAS
• Synology NAS Encryption: Forensic Analysis of Synology NAS Devices

In addition, we published an article on Breaking LUKS Encryption. Finally, we have a great overview comparing the types of encryption used by the various NAS vendors in NAS Forensics: Synology, ASUSTOR, QNAP, TerraMaster and Thecus Encryption Compared. As you can see from the table below, while some vendors opt for either LUKS or eCryptFS, Asustor offers the choice of LUKS or eCryptFS for the different types of volumes, while Qnap allows cherry-picking or stacking SED, LUKS and eCryptFS encryption. TrueNAS is missing from the table; the classic FreeNAS and TrueNAS Core support GELI (FreeBSD full-disk encryption method) and native ZFS encryption, while TrueNAS Scale only supports native ZFS encryption.

LUKS

LUKS (Linux Unified Key Setup) is a well-known, secure, and high-performance disk encryption method based on the classic dm-crypt. Originally developed for the Linux OS, LUKS is widely used across many types of devices running all kinds of Linux distributions. It is also a popular encryption format in Network Attached Storage (NAS) devices.

LUKS supports a range of different hash functions and encryption algorithms including AES, Serpent, Twofish, CAST-128 and CAST-256 in ECB, CBC-PLAIN64, CBC-ESSIV:hash or XTS-PLAIN64 modes. The default option in most Linux distributions is cbc-essiv:sha256 that uses AES encryption with a 256-bit key. Being the only hardware-accelerated encryption algorithm, AES is by far the most common of the three, especially when used in enterprise environments and network attached storage (NAS) devices. AES encryption offers that highest stream cipher performance when used on chip sets featuring AES encryption acceleration (e.g. the AES-NI instruction set in Intel CPUs). Serpent and Twofish can be manually specified by the user at the time of creating the encrypted volume, yet they offer no tangible benefit in security over AES with a significant performance penalty.

In disk encryption, hash functions are used as part of the Key Derivation Function (KDF). KDF are used to derive the binary wrapping key out of the user-provided input (typically, a text-based passphrase). The following hash functions are supported in the LUKS specification: SHA-1, SHA-256, SHA-512, RIPEMD160 and WHIRLPOOL. The SHA-1 and RIPEMD160 are explicitly not recommended; the SHA-256 is used by default, yet SHA-512 and WHIRLPOOL can be manually specified.

Most Linux-based appliances automatically use the default settings, while users can manually specify alternative hashing and encryption settings at the time they encrypt the disk on their Linux computer. LUKS stores information about the selected encryption settings in the encryption metadata, making it possible for the attacker to determine the correct encryption settings ahead of launching the attack.

A single LUKS volume may be protected with more than one key. The specification allows multiple user keys to decrypt the master key that is used for encryption. As a result, a LUKS-encrypted device may contain multiple key slots, which are used to store backup keys/passphrases and to allow multiple users unlock LUKS volumes each with their own password. Each key slot is protected with a unique salt, making the reverse brute force attack (matching the same KDF of a password against the different slots) unfeasible. A KDF must be calculated separately for each key slot during the attack. As a result, attackers will have to select a particular key slot to brute-force. Another result is the fact that, if the last available key slot is cleared, the entire LUKS-encrypted disk becomes inaccessible and non-decryptable (unless a copy of encryption metatada was backed up with cryptsetup luksHeaderBackup). Erasing the encryption metadata effectively implements near-instant secure erase of the encrypted disk.

LUKS encrypts the whole disk, and delivers very high performance. The whole-disk encryption has its drawbacks, too. LUKS encrypted volumes must be mounted (with the matching key or password) to perform operations on the file system. One needs the encryption key to check the file system for consistency, verify data integrity, create, restore or replicate snapshots, or make backups of encrypted data (other than saving a copy of the entire partition).

Of these problems, the difficulties in creating and restoring backups without unlocking the volume and decrypting the data was the one that triggered the development of an alternative encryption scheme.

You can read more about the LUKS encryption system as well as setting up a password recovery attack on LUKS-encrypted disks in our older article Breaking LUKS Encryption.

Filesystem-level Encryption

The most common implementation of filesystem-level encryption in Linux is eCryptFS, an open-source cryptographic file system.

eCryptFS supports several encryption algorithms including AES, Blowfish, DES3_EDE, Twofish, CAST6 and CAST5. Similar to other encryption tools, using any encryption algorithm other than AES will unnecessarily slow down the encryption without delivering tangible benefits in security.

eCryptFS is a file-based encryption system that encrypts individual files and stores them on top of the regular file system. Optional encryption of file and folder names is also available, which limits the maximum length of the file names to 143 ASCII characters.

Each file is encrypted with a unique, randomly generated session key, which in turn is encrypted (wrapped) with the user’s key or passphrase. The wrapped key is saved in the encryption metadata, which gets stored in each file’s header. This way, each encrypted file becomes self-contained, which allows seamlessly copying individual files or folders onto a different computer.

This implementation effectively lifts the restriction of requiring the encryption key to perform file system maintenance, back up and restore files and folders. For example, system administrators can backup and restore users’ home folders without having access to each user’s encryption keys, while NAS manufacturers implement blind backups to untrusted destinations via snapshot replication.

The ability to back up and restore encrypted data without asking for a key is pretty much the only benefit of eCryptFS. Everything else about this encryption method is a drawback.

1. Encryption overhead, low performance. eCryptFS adds encryption metadata to each encrypted file, which hurts performance (especially for smaller files) and adds storage overhead.
2. Information leakage. eCryptFS encryption leaks information about the size of each encrypted folder; the number, size, date and attributes of each file, allowing profiling attacks.
3. Cannot change encryption password (NAS). Off the shelf NAS units made by Synology, Asustor and other manufacturers do not allow revoking or changing compromised passwords. The only way to change the password is decrypting and re-encrypting the entire dataset.
4. Functional limitations. If the option to encrypt file names is enabled, the names cannot be longer than 143 ASCII characters (or even less if Unicode characters appear in the names). There are other restrictions, too, such as lack of NFS support for encrypted shares.
5. Some file system functions are unavailable. For example, BTRFS deduplication features will not work on encrypted datasets.

These limitations made the developers think about a different, modern encryption method. Meet native ZFS encryption, part of OpenZFS 2.0.

ZFS Encryption

First and foremost: native ZFS encryption is only available on disks using the ZFS file system, particularly via OpenZFS 2.0. While ZFS native encryption protects the entire dataset, it is different from traditional full-disk encryption schemes such as LUKS. Namely, some ZFS metadata such as the size of the file system (but not the number or sizes of individual files and folders) is exposed even without an encryption key, along with deduplication tables. On the other hand, users can scrub encrypted datasets, perform maintenance operations, create and replicate snapshots and basically do everything that zfs and zpool commands can do. Unlike filesystem-level encryption methods such as eCryptFS, ZFS native encryption allows changing the password without re-encrypting the dataset. Ars Technica published a very nice Quick-start guide to OpenZFS native encryption that is well worth reading.

When creating an encrypted dataset, the user can specify the encryption algorithm (the default is AES-256-GCM) and, in the case of passcode-based encryption, the number of pbkdf2 iterations (the default is 350,000).

By design, ZFS encryption has several weaknesses that leak certain type of information about encrypted datasets. The first piece of information is the name and size of the file system, as well as other information available through the use of the zfs and zpool commands. I want to say it again: unlike eCryptFS, ZFS native encryption does not leak the number and size of encrypted files and folders.

ZFS encryption does not protect deduplication tables, which leaks the addresses of duplicate blocks on the disk (but not the content of individual data blocks). There are some changes in the way of IV generation outlined in the following slide from the presentation of ZFS encryption:

How ZFS encryption works

ZFS encrypts data with AES-256 in GCM mode by default, with options for 128, 192 or 256-bit keys and CCM or GCM modes. Information about the encryption algorithm, key length and mode is stored in the encryption metadata. The encryption key is protected (wrapped) with a key generated with a certain number of iterations of PBKDF2. By default, 350,000 iterations are used; however, the user can specify a different number (but no less than 100,000 iterations).

Encrypted pools are created with the following command:

zfs create -o encryption=[algorithm] -o keylocation=[location] -o keyformat=[format] poolname/datasetname

Users can create encrypted pools that can be automatically mounted on boot. This requires the use of a binary key that is stored in a file (file:///path/to/keyfile). The encryption key is strictly 32 bytes, and should be comprised of random data. A random encryption key can be generated with the following command: if=/dev/urandom bs=32 count=1 of=/path/to/keyfile

Datasets that without auto-mount can be encrypted with either a binary key or a password. If a password is used, it must be 8 to 512 characters long.

zfs create -o encryption=aes-256-gcm -o keyformat=passphrase poolname/ datasetname

Notably, ZFS does not use the key or the password to directly encrypt the data set. Similar to LUKS and other disk encryption methods such as BitLocker, ZFS encrypts data with a master key. The master key, in turn, will be encrypted (wrapped) with a key encryption key (KEK), which can be either a user-provided binary key or the result of N iterations of PBKDF2 performed on the user’s passphrase.

(Source: presentation of ZFS encryption)

To sum it up, ZFS encryption has the following properties:

• AES encryption only. No third-party encryption algorithms or hash functions supported for the time being.
• Performance is comparable to non-encrypted pools regardless of file size.
• Password protection can be strengthened by using a larger number of hash rounds.
• Encrypted datasets leak several types of data, all of which are insignificant.
• Deduplication does affect security, and should be disabled for critical data.
• Blind backups and snapshot replication to untrusted destinations supported without the encryption key.
• Can be used to protect disks or individual datasets.

Conclusion

Traditional encryption methods used in Linux computers and storage appliances are all about tradeoffs. Filesystem-level encryption via eCryptFS lacks in nearly every respect. eCryptFS is slow, has a non-zero storage overhead, leaks information about encrypted data (including the size and number of files in the folders), and does not allow changing the encryption password. eCryptFS is a crippled file system, restricting the maximum file name length to only 143 characters, and limiting the use of certain features such as online deduplication or NFS support.

Full-disk encryption (LUKS) is faster, more secure and more convenient compared to eCryptFS, yet it does limit functionality in a different way: one cannot snapshot LUKS-encrypted volumes without unlocking them first; backup and restore functionality is unavailable on encrypted datasets without entering the encryption key; one cannot scrub the data or perform file system maintenance without providing the encryption key. The many “can’t” are easily possible with eCryptFS, the very encryption option I criticized above.

ZFS native encryption addresses all the points of critique mentioned above. High-speed data access, the ability to change encryption keys and passwords, support for filesystem-level maintenance operations such as scrubbing, snapshots of locked data sets, blind replication to untrusted remote destinations and a lot more things can be done on ZFS-encrypted datasets without entering an encryption key. Users can customize encryption options and attack resistance (via a custom number of hash iterations).

While ZFS native encryption does have its share of drawbacks, most of them are relatively minor. The most prominent drawback is ZFS itself: one must use the ZFS file system in order to use native ZFS encryption. This is very different from filesystem-agnostic LUKS and eCryptFS encryption: LUKS works one layer under, and eCryptFS one layer above the file system. If you do use ZFS, however, then its native encryption method is the most well-rounded encryption method available for Linux computers and NAS appliances. While it leaks more information about encrypted data compared to LUKS, it’s infinitely more convenient than the former. Compared to filesystem-level encryption, it’s several generations ahead. If you are flexible about the file system, I suggest checking out ZFS and its native encryption to secure your data.

To perform an iCloud extraction, a valid password is generally required, followed by solving the two-factor authentication challenge. If the user’s iPhone is everything that you have, the iCloud password may not be available. By using a trusted device, one can gain unrestricted access to everything that is stored in the user’s iCloud account. This article gives a comprehensive walkthrough on this alternative authentication method.

What device-based authentication is and how it’s different from token-based authentication

If, for the purpose of iCloud extraction, the user’s Apple ID and password are not available, you may be able to use an alternative method for authenticating into iCloud. Currently, Elcomsoft Phone Breaker supports two alternative authentication methods: token-based and device-based.

Token-based authentication employs binary authentication tokens extractable from the user’s computer (currently, macOS systems only) to access limited sets of synchronized data stored in iCloud. The use of authentication tokens allows bypassing two-factor authentication even if no access to the second authentication factor is available. However, authentication tokens are tied to the computer they are extracted from, which means you must run Elcomsoft Phone Breaker on the user’s computer to make use of the authentication token. Currently, iCloud tokens extracted from Windows systems cannot be used for iCloud extractions. Tokens are not only device-specific, they are also short-lived, and must be periodically refreshed.

Device-based authentication offers significantly more than token-based authentication. This method offers unrestricted access to everything stored in the user’s iCloud account. This includes cloud backups produced by all devices on the same Apple account, iCloud photos, synchronized data, as well as end-to-end encrypted data such as iCloud keychain, Health, Safari history, and much more.

Device-based authentication means that, in place of the login and password, you can authenticate to iCloud with the user’s trusted iOS device such as an iPhone or iPad that is signed in to their Apple ID at the time of extraction. The trusted device must be unlocked and compatible with a jailbreak or the included agent app.

Pre-requisites

Using the new device-based authentication method has several requirements. First, you’ll need access to the user’s iOS device such as an iPhone or iPad that is signed in to the user’s Apple ID at the time of extraction. The device must be unlocked (known or empty screen lock passcode), and it must remain online and connected during the extraction.

A jailbreak or agent app installation is required to perform device-based authentication. The agent app is included with Elcomsoft Phone Breaker and supports all 64-bit iOS devices running iOS 9.0 through 14.3. Sideloading the agent app requires a developer account with Apple if using Windows; macOS users may use a regular Apple ID to sideload the agent. The new agent app has the same compatibility requirements as the extraction agent used in iOS Forensic Toolkit.

Our solution has been tested on about a dozen devices from iPhone 5s to iPhone Xr, running iOS 9 to 14.8 (there is no jailbreak for iOS 15 today; there is no support for an extractor agent either). iPhone 11 and 12 devices are supported if they run a version of iOS supported by the agent app. At the same time, any data contributed from devices running iOS 15 (including cloud backups and synced data) will be successfully retrieved from the cloud even if the device that is used for authorization runs an older version of iOS.

We tested the solution with checkra1n, Electra and unc0ver jailbreaks.

Trusted device authentication is exclusive to the Forensic edition, and is supported only for accounts with two-factor authentication. For accounts without 2FA, you can use a token from the keychain, which is also supported in EPB.

Using the new authentication method

To use a trusted device for iCloud extraction, follow these steps.

1. Launch Elcomsoft Phone Breaker 10.0 or newer.
2. Select Download from iCloud (backups, sync, drive)
3. Observe the available authentication options: Password, Token, Device. Select “Device” to use the new method.
4. Unlock and connect the trusted iOS device to the computer. Perform the required steps to establish trust between the device and the PC.
5. You will now see the status of the device (jailbroken or not). If the device is jailbroken, proceed directly to extraction. The extraction agent will be installed transparently. If no jailbreak is installed, follow the steps to sideload and launch the extraction agent.

Sideloading the extraction agent

These steps are only required if the device has not been jailbroken. The agent app is included with Elcomsoft Phone Breaker and supports all 64-bit iOS devices running iOS 9.0 through 14.3.

1. Sideload the extraction agent.
2. Sideloading the agent app requires a developer account with Apple if using Windows; macOS users may use a regular Apple ID to sideload the agent.
3. Manually launch the agent on the iOS device by touching its icon.

Extraction

The trusted device must be connected to the PC and kept online during the entire duration of the extraction. Once authenticated, you will see the list of available backups, synced data categories, or files from iCloud Drive.

The extraction process using the new authentication method is similar to password-based authentication, with one exception: at some point, you will be prompted for a screen lock passcode on the device. Enter the screen lock passcode to enable access to certain records.

During the extraction, the device will display the following information:

Conclusion

The new authentication method offers the complete iCloud extraction, enabling experts to download iOS backups and synchronized data, including end-to-end encrypted categories. At this time, Elcomsoft Phone Breaker is the only third-party solution on the market allowing to access end-to-end encrypted data and iCloud backups saved by iPhone and iPad devices running any version of iOS. Pulling backups from the cloud is often the only means of accessing critical evidence that may no longer present on the iPhone itself.

Every year, Apple tightens security by placing more types of data under the end-to-end encrypted umbrella. Elcomsoft Phone Breaker is the only tool on the market that can recover many end-to-end encrypted categories including the user’s passwords from iCloud Keychain, iCloud Messages, Health, Screen Time, and Maps, and more.