The bootloader vulnerability affecting several generations of Apple devices opens the door to forensically sound extraction. In today’s article we’ll discuss the compatibility and features of this exploit with different devices, iOS versions, and platforms. In addition, we’ll provide security professionals and researchers with valuable insight into potential issues and solutions when working with checkm8.

Understanding Bootloader Vulnerabilities

Bootloader vulnerabilities exist in several generations of Apple devices. checkm8, the most famous bootloader exploit, is available for chips that range from the Apple A5 found in the iPhone 4s and several iPad models to A11 Bionic empowering the iPhone 8, 8 Plus, and iPhone X; older devices such as the iPhone 4 have other bootloader vulnerabilities that can be exploited to similar effect. checkm8 plays a significant role in iOS forensics, enabling forensically sound extraction for a wide range of Apple hardware including several generations of iPhones, iPads, Apple Watch, Apple TV, and even HomePod devices.

In mobile forensics, checkm8 allows for low-level access to the device’s file system, making it a valuable tool for security professionals and researchers. While the exploit itself does not alter any data on the device’s system or user partitions, its various implementations including the checkmra1n jailbreak that are not as forensically sound as the underlying exploit. Here at ElcomSoft we developed a checkm8-based extraction process that is both repeatable and verifiable.

checkm8 Compatibility

The checkm8 exploit is available for a wide range of hardware platforms. Being a bootloader-level exploit, checkm8 was initially believed to be fully OS-agnostic. While the exploit itself can indeed be applied to a vulnerable device regardless of the OS version, newer versions of iOS largely mitigate its forensic effect, blocking access to the file system on certain combinations of hardware and software. In particular, iPhone 8, 8 Plus, and iPhone X devices running iOS 16 utilize SEP hardening measures that make it impossible to access the file system even after successfully applying the exploit if the device had a passcode enabled at any time after setup. The same devices running iOS 14 and 15 require passcode removal prior to extraction; the same measures may be required when extracting iPads based on the same chip.

checkm8 compatibility matrix (green cells indicate 32-bit devices, blue cells indicate 64-bit devices):

Using checkm8 for Data Extraction

The pure checkm8 exploit alone is not enough to extract the file system. We built a comprehensive solution based on the checkm8 exploit allowing to extract a copy of the file system from affected devices in a safe, forensically sound manner. For this to work, you’ll need a copy of Elcomsoft iOS Forensic Toolkit 8 and a macOS computer (Intel or Apple Silicon). Please note that the Windows edition of iOS Forensic Toolkit does not support checkm8, while the upcoming Linux version will include support for checkm8 extraction.

The complete step-by-step instructions for checkm8 extraction are available in the following articles:

• 64-bit iPhone and iPad Devices
• 32-bit models: Perfect Acquisition
• Apple Watch S3
• Apple TV 3, 4, and 4K
• HomePod

Using checkm8 requires placing the device into DFU. We wrote several articles on the subject:

• DFU Mode Cheat Sheet
• DFU for Devices with Broken Buttons
• iPhone 8, 8 Plus, and iPhone X
• iPhone X
• Automating DFU Mode with Raspberry Pi Pico

checkm8 Troubleshooting

Using checkm8 for device extractions may present challenges without obvious solutions. In this chapter, we will talk about the problems and solutions.

After checkm8 extraction, device always reboots into Recovery

This is expected behavior caused by the autoboot flag set by iOS Forensic Toolkit during the initial stage of applying the exploit. When the device boots into iOS, it alters the data on the user partition, causing checksum mismatch on repeat extractions. The iOS boot sequence may start, for example, if one makes a timing mistake when placing the device into DFU. For this reason, iOS Forensic Toolkit automatically alters the boot behavior of iOS devices by flipping the autoboot flag, making the device boot into Recovery instead of iOS. When you have finished processing the device and are ready to return it, connect the device to the computer with iOS Forensic Toolkit installed and execute the following command (the device must be in Recovery):

./EIFT_cmd tools autobootTrue

After this command, the device will automatically reboot into iOS.

Q: Does flipping the autoboot flag break forensically sound extractions?

A: No. The flag is stored in the device’s NVRAM and not on the data or system partition, so flipping the flag will not alter the checksum.

Detailed explanation: Forensically Sound checkm8 Extraction: Repeatable, Verifiable and Safe.

Important: iOS Forensic Toolkit automatically flips the autoboot flag only after successfully applying the checkm8 exploit, which happens in DFU mode. To prevent the device accidentally rebooting into iOS while you attempt to place it in DFU, we strongly recommend placing the device into Recovery first, then manually flipping the flag as follows:

./EIFT_cmd tools autobootFalse

Error attempting checkm8 extraction on a 32-bit device

When: unlockdata fails on a 32-bit device.

Cause: This is expected behavior.

Solution: For 32-bit devices without Secure Enclave we developed a unique process known as “perfect acquisition”, which, instead of a copy of the file system, makes and decrypts an image of the data partition. This in turn requires a different command sequence compared to the standard checkm8 extraction process.

Detailed explanation and extraction steps: Perfect Acquisition Part 4: The Practical Part

Screen lock passcode reset: when and why

Sometimes you may receive an error early during the boot stage. The error may look as follows (the values for code, line, and commit may vary):

[ERROR] EIFT: failed with exception:
[exception]:
what=Failed to open connection to device
code=11993119
line=183
file=../../../ra1nsn0w/iOSDevice.cpp
commit count=191
commit sha  =1d674084639c73f1397535ee8aec50b35f1760d6

If this happens, it may mean that you need to remove the screen lock passcode from the device, then repeat the extraction. This is caused by SEP hardening measures developed by Apple in an attempt to mitigate the checkm8 exploit.

When: The device is an A11 Bionic device running iOS 14 or 15 (always required), or a 64-bit device running iOS 16 (only if error occurs).

Solution: Boot the device into iOS; unlock with passcode (passcode must be known); open Settings; on devices with Face ID: Tap Face ID & Passcode; on devices with a Home button: Tap Touch ID & Passcode; then tap Turn Passcode Off.

Troubleshooting: Mind the autoboot flag (see above), which must be manually set to ‘true’ if previously attempted checkm8 extraction.

Forensic consequences: Passcode reset causes loss of certain types of data (e.g. downloaded Exchange mail, Apple Pay transactions and more) and removes the trusted device status (if accessing Apple ID/iCloud from that device afterwards).

Cannot place device into DFU

There can be several issues preventing the device DFU mode.

Insufficient charge. This is a common cause for devices with depleted batteries. The issue with this situation is that if you start charging, the device will automatically boot into iOS when the battery reaches a certain level. The only way to prevent this behavior is placing the device into Recovery first, which can be done at any charge level.

Broken or rattling physical buttons. DFU requires following a sequence of button presses with precise timings. If a button is faulty or ‘rattles’, this conditions cannot be satisfied. Solution: use DFU for Devices with Broken Buttons instead (warning: requires disassembly). For A11 devices (iPhone 8/8 Plus/X), you may use a Raspberry Pi Pico instead, which does not require disassembly: Automating DFU Mode with Raspberry Pi Pico.

Incorrect timings, human mistake. We strongly recommend practicing DFU mode beforehand with a known good device of the same model.

General considerations

DFU mode requires some skill. If you have trouble entering DFU mode or exploiting the vulnerability, first try again. Then try changing the cable (preferably use the original Apple part) and/or connecting the device to a different USB port. Do not use USB-C to Lightning cables; if needed, use a USB-C hub or adapter with a regular USB-A to Lightning cable. If this does not help, use another computer (if available). Finally, try entering DFU mode using a different method.

Unmatching or undefined version of firmware 

When: More then one link or no link to Apple firmware are displayed, or the device reboots or fails to unlock the data partition when using the firmware image or link.

Cause: Our implementation of checkm8 requires a copy of Apple original firmware, which will be patched on-the-fly and uploaded into the device’s volatile memory. For this to work, the patched firmware version must match the version of the firmware already installed on the device. In many cases, iOS Forensic Toolkit is able to correctly identify the firmware installed on the device, and displays a single download link (you can either download the entire image or pass the link as an argument to EIFT, in which case only the required parts of the image will be downloaded).

However, the detection works based on the iBoot version. There are multiple iOS releases utilizing the same iBoot, which results in several potential matches and multiple firmware download links. While using a slightly different firmware may work, sometimes the device may either reboot (make sure the autoboot flag is set to avoid booting into iOS) or fail to unlock the data partition.

Solution: If this happens, you will have to either:

1. Identify the correct version of the OS installed on the device by using Diagnostic mode (which is safer and more forensically sound than booting iOS for the same purpose), or
2. Try all firmware links listed by iOS Forensic Toolkit starting from the newest build. This is safe; worst case scenario is device reboot (once again, make sure the autoboot flag is set to avoid booting into iOS).

Sometimes the correct version cannot be determined (e.g. for firmware builds newer than iOS Forensic Toolkit). In this case, you will have to manually locate the download link at ipsw.me.

If the device is running a beta version of iOS, please contact our customer support. Links to beta firmware images are generally not published by Apple.

For Apple TV (often), Apple Watch (always), HomePod (always) and, on rare occasions, even for iPhone/iPad devices there may be no full .ipsw images available. A zipped OTA update may be available instead. OTA firmware links or downloaded .zip files are supported by iOS Forensic Toolkit; there is no need to unpack or rename such files.

‘Snapshot’ warning appears in the output

When: In certain cases, you may see the following output:

Mounts:
[RW] (hfs) /dev/md0 -> /
[RW] (devfs) devfs -> /dev
APFS Volumes:
/dev/disk0s1s1 (Whitetail14A403.D10D101OS) [NONE]
Snapshot: com.apple.os.update-151D1F6F36C3D125B3424A627391C16BCF5FCDA55D4BAE35
C3BE3D65720F574C23EE3363F263A1A37DBF741A65C4CC73
Snapshot: com.apple.os.update-MSUPrepareUpdate
/dev/disk0s1s2 (Data) [NONE]
/dev/disk0s1s3 (Baseband Data) [NONE]

Cause: When you see the “Snapshot” warning in the output log, it usually means your device is in one of two states:

1. Update downloaded, not installed: Your device has downloaded a software update, but it hasn’t been installed yet.
2. Modified system partition: The device’s system partition has been tampered with; it may have a jailbreak, malware, or spyware.

Solution 1: If the device has a downloaded update, you can manually delete it from the device Settings app.

Steps:

1. Open your device’s settings by launching the “Settings” app.
2. Select “General.”
3. Tap on “iPhone Storage.”
4. In the list of apps, find “iOS update” and tap on it.
5. Choose “Delete Update” and confirm.

If you can’t find any updates and still see “Snapshot,” contact our customer team.

There is a way to deal with the “Snapshot” warning without deleting the update, but it is somewhat risky. If required, reach out to our support team for assistance.

Important: Be cautious when allowing the device boot into iOS, as it can lead to potential risks.

Solution 2: If  the device has a modified system partition, please contact our support team.

Corrupted file system, APFS ‘copy-on-write’ issues

When: Some files have abnormally large sizes.

Cause: File system corruption or the consequences of APFS “copy-on-write” scheme may result in abnormally large file sizes for some files. When using EIFT extraction agent, the issue is detected and fixed automatically. However, this approach is not applicable for checkm8 extractions.

Solution: There is currently no universal solution.

Workaround: If you encounter this issue, you might need to access your device via SSH (iOS Forensic Toolkit does support SSH) or performing selective extraction,  manually downloading unaffected files or manually deleting corrupted ones. However, before doing so, we strongly recommend contacting our technical support for assistance.

Future work: We are currently working on a unified extraction agent that will handle file system extractions. This aims to standardize the handling of file system issues while bringing partial data extraction and metadata extraction tools to checkm8 extractions.

Conclusion

This troubleshooting guide provides steps by step instructions to address the various issues occurring during checkm8 extractions. Whether you’re dealing with pending updates or file system issues, our aim is to assist you in resolving these issues effectively and efficiently. If you encounter any issues not covered in this guide, please feel free to contact our customer support team for expert assistance.

We have exciting news: iOS Forensic Toolkit 8 is now available for Windows users in the all-new Windows edition. The new build maintains and extends the functionality of EIFT 7, which is now approaching the end of its life cycle. In addition, we’ve made the Toolkit portable, eliminating the need for installation. Learn what’s new in the eights version of the Toolkit!

Windows Edition

We’ve released iOS Forensic Toolkit 8 almost exactly one year ago. At the time, the eights version of the Toolkit was exclusive to macOS, while Windows users were served by EIFT 7, which was maintained and updated alongside with the newer and greater EIFT 8. Today, we are making iOS Forensic Toolkit 8 available to Windows users and finally discontinuing iOS Forensic Toolkit 7, which has now reached its end-of-life.

The Windows edition of iOS Forensic Toolkit 8 offers the familiar feature set carried over from EIFT 7, which includes advanced logical and low-level extraction with the help of the custom extraction agent. Forensically sound bootloader-level extraction is still exclusive to the macOS edition though.

Limitations of the Windows Edition

Compared to macOS, the Windows edition has the following limitations:

1. No checkm8 support (yet). Bootloader-level extraction remains exclusive to macOS for the time being.
2. Signing the extraction agent requires an Apple ID enrolled in Apple Developer Program. macOS users can use developer and ordinary Apple IDs.

Going Portable

We changed the way iOS Forensic Toolkit is installed and used. On a Windows system, EIFT 8 will no longer require installation. Just download the all-new portable package, unpack the archive with the password provided in your registration email, and start using the Toolkit right away!

Selective Folder Access During Low-Level Extraction

The updated low-level extraction agent now allows experts to pull individual folders or just the file system metadata such as file names, sizes, and timestamps. We’ve made a few other changes to the extraction agent, which are listed below.

The new function is implemented via a couple of extra commands: extract and metadata. The -o switch specifies path to the output folder, while the optional -p switch points to the source file or folder in the iOS file system to be extracted. If no -p switch is present, the tool will extract everything starting with “/private/var/” (the root of the data partition).

Command-line Interface

While EIFT 7 was built around a console-driven menu, iOS Forensic Toolkit 8.41 brings advanced user experience built around the command line. Why did we transition from the menu to a command-line interface? The main reason was the significantly increased number of functions supported by the new build, linked to the growing list of supported extraction methods, device models, and iOS versions. On the one hand, this new functionality introduced exciting possibilities; on the other hand, it led to increased complexity in use. For instance, when using checkm8 extraction, one or more additional commands may be required to unlock the data partition or to mitigate various issues, which could not be hidden behind a single menu item. As a result, we arrived at the current solution: a command-line interface that provides full control over each step of the process.

New Commands

While Windows users will be introduced to CLI with this new build, macOS users have been using the new UI for about a year. The new build introduces several new commands for extraction agent, and modifies the function of the output switch.

Previously, the extraction agent supported two commands: tar and keychain, complemented with the -o switch specifying the output file name, e.g.:

EIFT_cmd agent keychain -o passwords.xml EIFT_cmd agent tar -o data.tar

While you could specify the full path, e.g. “-o /Users/ElcomSoft/Desktop/data/data.tar”, that syntax is now deprecated. Instead, the mandatory -o switch must be used to specify output path (and not a file name as it used to be in the previous build). Starting with this release, file names will be assigned automatically. You’ll have to use the -o switch when pulling the file system image, extracting the keychain, or accessing individual files, folders, or file system metadata.

Examples

Extract file system metadata from the Media folder:

EIFT_cmd agent metadata -p /private/var/mobile/Media/ -o /Users/ElcomSoft/Desktop/metadata/

Extract the complete Media folder:

EIFT_cmd agent extract -p /private/var/mobile/Media/ -o /Users/ElcomSoft/Desktop/data/

Extract full file system image of the user partition:

EIFT_cmd agent extract -o /Users/ElcomSoft/Desktop/data/

Extract a single file Photo.jpg from the media album:

EIFT_cmd agent extract -p /private/var/mobile/Media/DCIM/Photo.jpg -o /Users/ElcomSoft/Desktop/data/

Going Multiplatform

The release of the Windows edition marks a significant step towards true multiplatform compatibility. We are actively working on a Linux edition, with an official announcement expected soon. Stay tuned!

In this tutorial, we will address common issues faced by users of the iOS Forensic Toolkit when installing and using the low-level extraction agent for accessing the file system and keychain on iOS devices. This troubleshooting guide is based on the valuable feedback and data received by our technical support team.

What kind of troubles are we shooting?

In this guide, we won’t dive into the inner workings of the extraction agent, which leverages known vulnerabilities to elevate privileges in Apple iOS. Instead, we’ll focus on what to do when you encounter a difficulty installing or using the extraction agent.

Common mistakes

First, let us cover the two most common mistakes our users regularly make when using the extraction agent.

1. Attempting to Sideload the Agent Without a Firewall: If you try to install and run the extraction agent without using a firewall (software-based or the one using our Raspberry Pi solution), you may expose the device to the risk of remote lock or wipe.
   • Solution: Follow the installation instructions provided in the user’s manual. Understand how to configure and use a firewall to install the extraction agent without putting the data at risk.
2. Extracting Only the File System Image Without Keychain: Only imaging the file system image without extracting the keychain is a common mistake.
   • Solution: Always perform keychain extraction before imaging the file system. We recommend going after the keychain in the first place, which is nearly instant, followed by file system extraction, which may take a while.

EIFT_cmd normal unpair

EIFT_cmd normal pair

Errors Installing and Using EIFT

In this section, we’ll cover the common problems that may arise during the installation and usage of the extraction agent and iOS Forensic Toolkit.

“Insufficient Permissions” or “Not Found” errors

If you receive the “Insufficient Permissions” error when running iOS Forensic toolkit or the firewall script, this can mean that the tool had not been correctly installed on the computer. These problems can be broken down into the following cases.

The xattr command was not run correctly

To fix this issue, follow these steps:

• Open Terminal.
• Navigate to the folder containing containing iOS Forensic Toolkit.
• Execute the following command (mind the dot at the end of the command):
  • sudo xattr -d com.apple.quarantine .

iOS Forensic Toolkit folder is located on the desktop

Solution: Move EIFT to a different location, such as the local Applications folder.

Shell does not have full disk access permissions

You must grant full access permissions to the OS shell.

• Go to System Preferences -> Security & Privacy -> Full Disk Access
• Click on the padlock icon to allow changes
• Click the ‘+’ button
• Press ‘cmd + Shift + .’ to display hidden files
• Select /bin/sh as a path

Misconfigured Internet sharing for USB devices

Typically, the problem arises from selecting the wrong internet source. Sometimes, more than one iPhone/iPad connection may appear in the list.

Solution: You need to manually identify the correct connection, often through trial and error, using a designated test device.

The firewall is running, tested OK, but sideloading does not work on the target device

• MDM profile on the device disallows sideloading
  • Solution: do risk assessment and either remove MDM profile (risking to lose some types of data) or use a different extraction type (e.g. advanced logical)

The firewall is running, tested OK, but signing does not work on the target device

• Incorrect date and time on the target device
  • Solution: check and set current time and date on the target device; repeat the process starting with agent sideloading

Not enough disk space or FAT32-formatted external drive

You need enough free disk space to fit the file system image. If using an external drive, make sure to format it in a file system other than FAT32, which limits file sizes to 4GB.

The extraction agent is not running or running in background

Ensure that the extraction agent runs as a foreground app during the entire extraction.

Wireless networks not fully disabled

First and foremost, the device must be placed into airplane mode during the extraction. However, depending on the last settings, the Wi-Fi and Bluetooth toggles may not be automatically disabled when the device enters airplane mode.

Solution: place the device into airplane mode first, then check and manually disable the Wi-Fi and Bluetooth toggles.

Error: “All exploits failed”

Cause: too long or too short a delay after booting or restarting the device.

Explanation: the exploits used by the extraction agent are time-sensitive. Some iOS versions require a delay of no more than 10 seconds after a reboot before launching the extraction agent, while iOS 16 requires a delay of approximately one minute to allow all kernel-level processes to stabilize. Providing an exact waiting time for each iOS version is challenging, so if you encounter issues with the exploit, try both shorter and longer delays, rebooting the device between attempts. In some cases, you may need to try up to five times.

Note: if the device has been running for a very long time (e.g. while sitting on a charger), the exploit will almost certainly fail. In this case, you will need to reboot the device.

Solution: reboot the device, wait 10 seconds to 1 minute.

Troubleshooting Guide

If none of the above resolves the issue, try identifying the issue by following steps from the Troubleshooting Guide.

Important: for the troubleshooting guide, always use a designated test device! Do not perform troubleshooting steps using the target device unless specifically instructed.

Step 1: Ensure Internet Connectivity on the Test Device

Ensure that the Internet sharing is working properly by checking that the Internet is accessible on the test device while wireless network interfaces (such as WiFi and mobile data) are disabled, and the text device is connect to your Mac computer via a cable. If you encounter issues with Internet sharing, refer to the “Misconfigured Internet Sharing for USB devices” section for solutions.

Step 2: Try Sideloading and Signing the Extraction Agent Without a Firewall

1. Try signing the agent on the test device without running the firewall script. If successful, the issue may be related to firewall settings.
2. If the agent signing fails even without a firewall, consider creating a new disposable Apple ID. Your goal is reaching a point where the entire process works correctly on the test device at this stage. If the agent signing still fails with a fresh Apple ID, contact our support team. You may need to update iOS Forensic Toolkit to the latest version.

Step 3: Try Sideloading and Signing the Extraction Agent With a Firewall

1. Try sideloading and signing the extraction agent with the firewall script running.
2. If the agent signing fails with the firewall script running, the issue is likely related to firewall settings. Occasionally, rebooting the test device while keeping the firewall script running may help resolve the issue. If rebooting doesn’t solve the problem, please contact our support team.

Step 4: Troubleshoot on the Target Device

If all previous steps were successful on the test device but signing the agent still fails on the target device, follow these steps:

1. Disconnect the target device from the computer and reconnect it, then attempt to sign the agent again (ensure that the firewall script is running).
2. If the issue persists, try disconnecting and rebooting the target device, and then reconnect it (with the firewall script running).

By following these steps, you should be able to troubleshoot and resolve common sideloading and signing issues. If you encounter any persistent problems, do not hesitate to contact our support team for further assistance.

Have you ever tried to unlock a password but couldn’t succeed? This happens when the password is really strong and designed to be hard to break quickly. In this article, we’ll explain why this can be a tough challenge and what you can do about it.

I’ve been running a password recovery attack for a while now, and the attack appears stalled. What should I do?

If the attack is taking a long time without success, this means that the data is protected with a strong password that cannot be quickly recovered. Strong passwords are intentionally designed to be challenging to break quickly.

Why is the password difficult to recover?

It the data is secured by a strong encryption algorithm and protected with a robust password, this makes it significantly harder to recover. Software developers use advanced encryption techniques and hashing algorithms to ensure the security of your data. As a result, the process of recovering a password becomes more computation intensive and, therefore, time-consuming.

What steps can I take to increase my chances of recovering the password?

While there are no guarantees, you can take the following steps to improve your chances:

• Dictionary Attack: Try using a dictionary of the user’s existing passwords and common leaked passwords followed by dictionaries of common words and variations that people frequently use as passwords. For common word dictionaries do use mutations; make sure to use them sensibly as mutations significantly expand the number of password combinations. Do not use mutations for lists of leaked passwords.
• Advanced Attacks: use any information you have about the password to enhance your efforts. Try extracting the user’s existing passwords from sources such as Web browsers, cloud services (e.g. iCloud Keychain, Google Account, Microsoft Account) and mobile devices.
• Brute-Force: If the dictionary attack fails, consider a brute-force approach. This involves trying every possible combination of characters until the correct password is found. You can also use “Brute-force with mask” if you know the specific pattern and characters in the password.

How long can a brute-force attack take for complex passwords?

Brute-force attacks can be time-consuming, especially for long and complex passwords. The time required depends on multiple parameters such as the length and complexity of the password, the data format, the type of attack, and resources available to break the password. Be prepared for the possibility that it might take a considerable amount of time to recover the password using this method, and be aware that long and complex passwords may not be discovered at all for the lifetime of the universe.

Can I speed up the recovery process?

Yes, you can accelerate the recovery process by using GPU acceleration. Both NVidia and AMD graphics cards are supported for this purpose. Additionally, you can create a network of computers using Elcomsoft Distributed Password Recovery to build a password recovery cluster, which can significantly speed up the process. Please note that modern data protection practically requires GPU acceleration for recovering any passwords except the unusually weak ones.

Remember, the recovery of a strong password is a challenging task and success is not guaranteed. By following these steps and leveraging the available advanced recovery methods, you’ll be getting the best possible chance to recover the password. If you have further questions or encounter issues, don’t hesitate to reach out to our support team for assistance.

Related articles:

We published numerous articles on the subject.

• Use The Brute Force, Luke! “There are several methods for recovering the original password ranging from brute force to very complex rule-based attacks. Brute-force attacks are a last resort when all other options are exhausted. What can you reasonably expect of a brute-force attack, what is the chance of success, and how does it depend on the password and the data? Or just “how long will it take you to break it”? Let’s try to find out….”
• A Word About Dictionaries “Dictionary attacks are among the most effective ones because they rely on the human nature. It is human nature to select passwords that are easily memoizable, like their pet names, dates of birth, football teams or whatever.”
• Accelerating Computer Forensics: the Low-Hanging Fruit Strategy Though this article doesn’t focus on password recovery directly, its insights are applicable to the field. The method discussed within can aid in accessing secured data without resorting to time-consuming attacks.

We are excited to announce the release of an open-source software for Orange Pi R1 LTS designed to provide firewall functionality for sideloading, signing, and verifying the extraction agent that delivers robust file system imaging and keychain decryption on a wide range of Apple devices with iOS Forensic Toolkit. This development aims to address the growing security challenge faced by forensic experts when sideloading the extraction agent using regular and developer Apple accounts.

Important: older developer accounts created before June 6, 2021, are exempt from the verification process. If you are using one of these accounts, you will not need a firewall to run the extraction agent.

TL&DR

Our research and development team has introduced an open-source project called EIFTPI (github/eiftpi) . This project has brought forth a custom firewall (or more accurately termed “proxy”) designed specifically for the Orange Pi R1 LTS device. This mini-router boasts several features that make it a better fit for this specific purpose then the more all-around Raspberry Pi 4, including two Ethernet ports, both of which are utilized by our software; lower price and wide accessibility.

Why do you need a firewall for iOS forensics? To perform a low-level extraction of iOS and iPadOS devices with iOS Forensic Toolkit, the extraction agent needs to be sideloaded onto the device being analyzed. Each sideloaded app, including the extraction agent, must be signed by Apple with a unique digital signature specific to the device. When installing (or launching for the first time) a sideloaded app on an iPhone or iPad, users are prompted to verify the digital signature, requiring the device to establish contact with an Apple server. However, connecting the device to the internet poses the risks of unwanted synchronization or remote blocking or erasing its content, especially if it is part of an evidence base.

Previously, we recommended a solution that involved enrolling the Apple ID used for signing the sideloaded app into the Apple Developer program, which in turn allowed for the validation of the digital signature without the need for the device to contact an online server. Unfortunately, due to recent updates on Apple’s side, digital signatures associated with new developer accounts must now undergo verification with an Apple server. Consequently, this reintroduces the potential risks that were previously exclusive to non-developer accounts. Considering these changes, we have developed several solutions to minimize risks by limiting the device’s connection solely to the server required for certificate verification. These solutions are:

1. A script for macOS that acts as an effective firewall
2. An open-source firmware implementing a functional firewall on a Raspberry Pi 4
3. YOU ARE HERE: An open-source firmware implementing a functional firewall on an Orange Pi R1 LTS

The Orange Pi R1 LTS router

Orange Pi R1 Plus LTS is an open-source single-board computer with Dual Gigabit Ethernet ports. It is highly compact with a dimension of 56X57mm. According to the manufacturer, it can run OpenWRT, Ubuntu, and Debian. It uses the Rockchip RK3328 SoC featuring a quad-core ARM Cortex-A53 64-Bit processor, 1GB LPDDR3 SDRAM, microSD card slot, and, most importantly, two physical Ethernet ports. The device uses a Type-C port as its power connector, and can be easily powered by connecting it to the Type-C port of your Mac or MacBook.

Advantages of the Orange Pi R1 LTS

Compared to a Raspberry Pi 4, for which we have also developed a functional firewall, the Orange Pi R1 Plus LTS is cheaper (around $35 at the time of this writing), and has two dedicated Ethernet ports, both of which are utilized by our project. Essentially, this means that you won’t need an extra USB to Ethernet adapter as you would in the case of the Raspberry Pi 4. In a word, the Orange Pi R1 Plus LTS is a better firewall/proxy than the Raspberry Pi 4, but the Raspberry Pi 4 is a more powerful general device. We would like to list the following advantages of the Orange Pi R1 LTS:

1. Wide Accessibility: The Orange Pi R1 LTS device is easily obtainable, both with and without the metal case, ensuring users can quickly procure the necessary hardware for their forensic needs. The EIFTPI firmware is readily available on GitHub, making it accessible to a broad community of forensic professionals and enthusiasts.
2. Cost-Effectiveness: In comparison to some other specialized forensic hardware options, including the Raspberry Pi 4, the Orange Pi R1 LTS is an affordable choice. This affordability extends to its components, as it comes with two Ethernet ports, eliminating the need for an additional adapter. This cost-effectiveness makes it a preferred option for those on a tight budget or smaller forensic teams.
3. Enhanced Connectivity: The Orange Pi R1 LTS features two Ethernet ports – one labeled “LAN” (located closer to the USB-C port) and the other labeled “WAN.” In our implementation, these ports serve distinct purposes. The LAN port connects the device to the internet, while the WAN port is dedicated to connecting iPhones and iPads through the use of appropriate adapters (such as USB-C to Ethernet or Lightning to Ethernet).

Setup requirements

To set up the EIFTPI firewall for iOS forensic purposes, users will need the following:

1. A microSD card
2. A Type-C power supply for the Orange Pi R1 LTS device (you may use a Type-C cable to power the device off a Mac or MacBook USB Type-C port)
3. An adapter for Ethernet connectivity on iPhones/iPads (USB-C to Ethernet or Lightning to Ethernet)
4. Two Ethernet patch cords – one to connect the device to a regular router (using the LAN port) and another to connect the iPhone/iPad to the Orange Pi R1 LTS (using the WAN port)

Setting up an Orange Pi R1 LTS as a functional firewall

The EIFTPI image is designed to work as a proxy for wired iOS internet connections, enabling safe agent signing with restricted communication to specific servers. This manual will guide you through the setup process.

First, download the firmware image from GitHub – Elcomsoft/eiftpi. There is a single unified image currently supporting several devices including Raspberry Pi 3B, Raspberry Pi 3B+, Raspberry Pi 4, Orage Pi 5, and Orange Pi R1 LTS.

The simplest way to use it is:

1. Flash image in microSD card (at least 4GB)
2. Insert card into the Pi and power on the Orange Pi R1 LTS device
3. Connect iPhone with Lightning to Ethernet adapter to the WAN port of the Orange Pi R1 LTS
4. Connect the Orange Pi R1 LTS to Internet through the LAN port of the Orange Pi R1 LTS

Important: On the Orange Pi R1 LTS, the downlink (i.e. the connection to the iPhone) is the port next to the USB-C port labeled “WAN”. The other port (the one closer to the GPIO pins) labeled “LAN” is downlink.

That’s it! You have successfully installed the firmware on Orange Pi R1 LTS. Connect the Orange Pi R1 LTS device to the internet and then connect your iPhone to the Orange Pi R1 LTS using a cable. We recommend connecting a test iPhone first to ensure that Internet access is limited. The test iPhone should only have access to ppq.apple.com and humb.apple.com. Additionally, www.elcomsoft.com should be accessible (you can use it for testing the connection), while www.apple.com (or any other address except those listed above) should not be accessible.

If you prefer building your own image or using Wi-Fi instead of the built-in Ethernet port (which we generally do not recommend), visit GitHub – Elcomsoft/eiftpi for additional instructions.

Conclusion

As we have shared our open-source software for Orange Pi R1 LTS with firewall functionality, we aim to secure the sideloading of the extraction agent in the iOS ecosystem. The limitations of checkm8 and the complex nature of developer accounts have necessitated new approaches to ensure data security. By embracing open-source solutions and providing alternatives, we strive to empower forensic experts and enhance the effectiveness of the extraction agent in safeguarding valuable information.

When it comes to iOS data acquisition, Elcomsoft iOS Forensic Toolkit is the top choice for forensic experts. Its cutting-edge features and unmatched capabilities have made it the go-to software for investigating iOS devices. In a recent update, we expanded the capabilities of the low-level extraction agent to support full file system extraction and keychain decryption on Apple’s newest devices running iOS 16.5. This achievement represents a breakthrough, as the delay between Apple’s iOS updates and our forensic software release has significantly reduced.

Introduction

Agent-based extraction is an advanced “consent extraction” method used to obtain the complete file system and keychain data from modern iOS and iPadOS devices, namely iPhones and iPads. “Consent extraction” is a term meaning that it can only be used when the device passcode is known or not set. Although agent extraction may not be considered completely “forensically sound” like the acquisition method based on the bootloader exploit, it stands as the sole available technique for the latest Apple devices equipped with A12-A16 Bionic and M1/M2 SoC, and even remains the only working extraction technique for A11 devices (iPhone 8/8 Plus/iPhone X) running iOS 16, for which bootloader-based methods fail. By employing agent-based extraction, investigators can retrieve the maximum amount of data, making it a valuable source of forensic evidence.

The Low-Level Extraction Agent

The low-level extraction agent is what sets iOS Forensic Toolkit apart. We have already established ourselves as pioneers in checkm8 extractions, extended support to various Apple devices, and introduced low-level extraction support for Apple M1 and M2 chip-based iPad models. Previously, our tool could extract the full file system image and decrypt the keychain from supported devices running iOS releases up to and including iOS 16.4; for some devices, the latest supported version of iOS was even older. Now, with full file system extraction and keychain decryption support for the same range of devices, we expanded OS version support all the way up to iOS 16.5 for devices based on Apple A11 Bionic and newer chips, up to and including the M1 and M2.

Investigators can now access crucial evidence in the latest Apple devices running relatively recent versions of iOS, including the contents of apps’ sandboxes, system data, and important online account passwords, shedding light on users’ digital activities. In addition to passwords, the keychain stores crucial keys required to unlock protected chat histories from messaging applications like Signal.

The current support matrix includes iOS 16.5 and beyond, and our development team is actively working to support upcoming iOS versions. Elcomsoft iOS Forensic Toolkit remains at the forefront of iOS forensic tools, continuously evolving to meet the demands of the ever-changing landscape.

A Major Achievement makes for a Breakthrough in Mobile Forensics

Apple is known for its dedication to security and regularly patches iOS with timely security fixes. Their commitment to protecting user data means they release OS updates promptly and frequently, making it challenging for forensic vendors to keep up and develop software that can effectively extract evidence from devices with known passcode running these latest iOS versions. However, despite these difficulties, our forensic team achieved a significant milestone this time, reducing the time gap between the release of iOS 16.5 and our forensic software update to approximately 2.5 months. This achievement may seem minor to some, but within the forensic industry, it represents a major breakthrough and highlights our unwavering commitment to staying at the forefront of iOS data acquisition. Our constant effort to bridge the gap between iOS updates and forensic capabilities ensures that investigators have the most advanced tools at their disposal to conduct thorough and effective digital investigations.

A Word on Apple A11 Chips

Devices equipped with A11 Bionic chips, such as the iPhone 8, 8 Plus, and iPhone X, were initially considered susceptible to checkm8, a powerful bootloader-level exploit that was thought to be unpatchable. However, with the release of iOS 16, Apple implemented a new SEP hardening patch, effectively shutting down checkm8’s access to user data if a screen lock passcode had ever been used on the device. We’ve already discussed it in iOS 16: SEP Hardening, New Security Measures and Their Forensic Implications.  This update rendered the exploit useless for accessing data on A11 iPhones running iOS 16.

Let’s reiterate: a bootloader-level extraction of A11-based iPhones running iOS 16 will fail if a passcode was ever used on the iPhone since the initial setup, making checkm8 extractions pointless for these devices if they run iOS 16.

Previously, other extraction methods for A11 Bionic devices proved to be challenging, as many existing OS-level exploits did not work on these chips, limiting forensic specialists to partial file system extraction for iOS 15.4 – 16.1.2, without access to the keychain. Fortunately, an updated agent-based extraction method is now available, leveraging a new OS-level exploit. This breakthrough now allows to perform full file system extraction and decrypt the keychain on A11 devices running all versions of iOS 15 and 16 up to and including iOS 16.5. With this advancement, investigators can now access critical data and evidence from a wider range of devices, enhancing their capabilities in the realm of digital forensics.

Wait A Minute!

When attempting data extraction using this new method, it is crucial to exercise patience. After restart the device, it is recommended to wait for at least a minute, preferably 2 to 3 minutes, before proceeding with the extraction process. This waiting period is essential to allow the device to stabilize and for background processes to settle. Note that the number of apps installed on the device can impact the kernel’s activity during this period, so an even longer waiting period may be required for successful extraction.

Additionally, make sure to place the device in airplane mode and additionally disable Wi-Fi and Bluetooth toggles before you begin the extraction. This not only eliminates the risk of remote lockout, but also helps minimize unwanted activity on the device, ensuring a more stable environment for the extraction process.

In real life, successful extractions might not be achieved on the first attempt. In our lab, one device took five attempts before the extraction succeeded, while several others required only two tries. Devices with limited data or minimal applications generally completed the process without issues on the first run.

How We Tested It

We extensively tested the update on a wide range of devices to ensure its reliability and compatibility. We hope that several more devices and iOS versions will be added to our testing list based on valuable feedback from our clients. This is the current list of devices/iOS versions/SoC we tested the update on:

• iPhone 8 & iPhone X, iOS 15.4, 15.6, 15.7.1, 16.0, 16.1, 16.2, 16.3, 16.4, 16.4.1, 16.5 // A11
• iPhone Xs Max, iOS 16.4.1 // A12
• iPhone 11, iOS 16.5 // A13
• iPhone SE (2nd generation), iOS 16.4.1 (а) // A13
• iPad Air (4th generation), iOS 16.5 // A14
• iPhone 13 Pro, iOS 16.5 // A15
• iPhone 13 Pro Max, iOS 16.4.1 // A15
• iPhone 13 Mini, iOS 16.4.1 // A15
• iPhone 13 Mini, iOS 16.5 // A15
• iPhone SE (3rd generation), iOS 16.5 // A15
• iPad Air (5th generation), iOS 16.4.1 // M1

Note: The exploit may not always work on the first attempt and could occasionally result in the device rebooting. In such cases, we recommend trying again, but it’s crucial to wait for at least a minute after the reboot to allow the system’s core components to stabilize. Furthermore, to increase security during the process, we advise using airplane mode, which can minimize external interference during the data extraction process.

Conclusion

Elcomsoft iOS Forensic Toolkit stands unrivaled in iOS data acquisition. With its powerful extraction capabilities, support for the latest iPhone and iPad models, and keychain decryption, it empowers forensic investigators with comprehensive access to valuable information. The recent addition of iOS 16.5 support, along with our commitment to future updates, solidifies EIFT as the most advanced iOS acquisition software available, unlocking new possibilities for your forensic investigations.

In the ever-evolving landscape of digital investigations, mobile forensics has become a critical aspect of law enforcement work. The challenges of extracting, handling, and analyzing data obtained from various sources have led to a growing demand for universal solutions. We’d like to emphasize the importance of every stage of mobile forensics, the significance of extraction, and the critical importance of expertise in this field.

Stages of Mobile Forensics

Mobile forensics involves several crucial stages that cannot be overlooked. These stages include preliminary tasks such as device isolation, transportation, and proper documentation. Following these, the actual extraction process takes place, which is then followed by analysis and generating reports for further investigation or archival purposes.

Extraction is a pivotal stage in mobile forensics as it can make or break an investigation. It is essential to choose the right extraction method to avoid damaging the device, missing critical data, or wasting time. A variety of extraction methods exists in mobile forensics, including advanced logical extraction, bootloader-based extraction, agent-based extraction, and cloud-based extraction. Each method has its advantages and limitations, so it’s crucial to understand them and have access to the necessary software. Please check out this article and follow our blog for updated information on selecting the appropriate extraction method, as the field constantly evolves.

The Choice of Forensic Software

Choosing the right forensics software is crucial for successful data extraction. Consider factors like compatibility with different devices, reliability, speed, and the platform the software operates on. It is important to conduct thorough research before investing in any software to ensure it meets the specific requirements of your investigations. A proper research may not be easy, as forensic vendors tend to hide essential information from their customers (read part 1 and part 2). It is crucial to understand that there is no single software solution that can fully meet the diverse needs of the DFIR field. Relying solely on press releases and marketing materials is ill-advised; always do your homework before trusting forensic software vendors’ claims.

The Choice of Extraction Methods

A variety of extraction methods exists in mobile forensics, including advanced logical extraction, bootloader-based extraction, agent-based extraction, and cloud-based extraction. Each method has its advantages and limitations, so it’s crucial to understand them and have access to the necessary software.

For iOS devices, low-level extraction is the most effective method by a large margin that returns the full file system image and decrypts the keychain containing important data like passwords and encryption keys. Low-evel extraction remains the only way to access encrypted conversations in secure instant messengers (e.g. Signal). However, low-level extraction availability is limited to older devices or versions of iOS, leading to delays in supporting newer iOS releases. This rapid succession of updates and patches makes data extraction a continuous challenge for forensic experts.

When it comes to low-level extraction, bootloader-level extraction and agent-based extraction are available. Bootloader-level extraction relies on vulnerabilities that exist in some devices’ bootloaders. For 64-bit Apple devices we’re using the checkm8 exploit, which, in our implementation, delivers repeatable, verifiable and safe extractions. Bootloader-level extraction, however, is only available for older devices (up to and including the iPhone 8/8 Plus/iPhone X generation and other Apple devices based on similar chips); moreover, there are severe limitations to bootloader extractions introduced in recent versions of iOS due to SEP hardening and other security measures.

If bootloader-level extraction is not available for a given device, yet another method based on the extraction agent may be used if the device is running a compatible version of iOS (at this time the highest OS version supported by the extraction agent is iOS 16.4, with support for newer releases in the works). The agent-based method is the second best after bootloader-based extraction. We published a comprehensive overview of the extraction agent in Exploring the Extraction Agent.

In cases where unsupported iOS versions are encountered, advanced logical extraction becomes the only viable option. While it allows the extraction of device backups, some system logs, media files and metadata, it may not retrieve critical data like email messages or conversation histories from popular instant messaging apps.

Last but not least, cloud extraction may provide a viable solution, especially in situations where the physical device is inaccessible for data extraction. Such situations may include physical damage to the device, such as water damage or hardware failures, as well as instances where the device has undergone a factory reset or has been wiped clean may hinder data retrieval efforts. In all these cases Elcomsoft Phone Breaker‘s cloud extraction option becomes the last resort, extracting all available information from Apple iCloud subject to authentication credentials.

Common Mistakes and Their Consequences

In general, some of the most significant mistakes during or before the extraction process that lead to data loss include:

• The device goes online during extraction, which may cause unwanted synchronization and/or remove wipe or remote lock.
• Failing to capture the complete file system and only creating a backup when low-level extraction is available.
• Neglecting to check other potential data sources, such as old local backups, cloud backups, or other devices.
• Resetting the password, inadvertently locking out access to critical data.
• Relying solely on one software tool without cross-verification.

These errors can have severe consequences and result in the loss of crucial evidence. Therefore, it is essential to exercise caution, follow best practices, and consider all available data sources to ensure the success of mobile forensics investigations.

The Analysis Stage

The analysis stage requires powerful hardware to process and interpret the extracted data effectively. Unlike extraction, analysis often demands a more thoughtful and manual approach. Knowing the tools and their options is extremely important. For example, disabling some computation-intensive options, such as image recognition, can significantly speed up the process. It’s best to use multiple software tools for cross-checking and compare their results for more accurate conclusions, and be cautious of vendors who prioritize the number of discovered artefacts over accuracy.

Although an all-in-one solution for extraction and analysis might be appealing, it is often not the most effective approach. For iOS devices, certain vendors provide outstanding extraction capabilities, while others specialize in Android devices, sometimes even specific chipsets (like ACELab targeting specifically MTK-based Android devices). In many cases, using separate tools for extraction and analysis yields better results and avoids unnecessary expenses.

Conclusion

It is essential to learn from others’ mistakes and utilize the right tools for the job. However, the most crucial aspect is to apply critical thinking and knowledge in every investigation. Armed with knowledge and understanding, you can avoid the pitfalls and achieve more successful outcomes in mobile forensics. Always stay vigilant, be informed, and trust your expertise to navigate the complexities of digital investigations effectively.

We continuously emphasize the importance of the extraction stage in mobile forensics. This stage holds significant weight, as the accuracy of the extracted data directly impacts the validity of the conclusions drawn from it. Even in high-profile cases, critical mistakes have been made during extraction. Fortunately, our approach to mobile forensics takes all these aspects into account. We prioritize forensically sound methods like checkm8, and we have developed an extraction agent with specific features and the widest coverage of Apple mobile operating systems. Please use our blog as a comprehensive reference covering the proper steps and methods for data extraction.

Acquiring data from locked, broken, or inaccessible devices poses significant challenges. However, there are ways to retrieve valuable information from such devices by obtaining the data from iCloud, including old data that has been deleted with no chance of recovery. In this article, we will explore the classic acquisition methods available for iOS devices and focus on the crucial role of Apple iCloud in forensic investigations.

Classic Acquisition Methods

For iOS devices, low-level extraction is an effective method that returns the full file system image and decrypts the keychain containing important data like passwords and encryption keys. Low-evel extraction remains the only way to access encrypted conversations in secure instant messengers (e.g. Signal). However, low-level extraction availability is limited to older devices or versions of iOS, leading to delays in supporting newer iOS releases. This rapid succession of updates and patches makes data extraction a continuous challenge for forensic experts.

In cases where unsupported iOS versions are encountered, advanced logical extraction becomes the only viable option. While it allows the extraction of device backups, some system logs, media files and metadata, it may not retrieve critical data like email messages or conversation histories from popular instant messaging apps.

No device – no data?

In some situations, accessing data directly from the device may not be possible or may not return all the desired information, even if the device is unlocked. This is particularly relevant when dealing with deleted data. When the device is factory reset, of data is deleted from a device, it may seem irretrievable. The specific type of data encryption used in modern versions of iOS renders deleted files completely inaccessible even if low-level access is granted to device storage.

Certain scenarios render the device inaccessible for data extraction. Physical damage to the device, such as water damage or hardware failure can pose significant challenges. Additionally, instances where the device has undergone a factory reset or has been wiped clean may hinder data retrieval efforts.

In such cases, cloud extraction provides a viable solution.

The Role of iCloud in Data Acquisition

Apple iCloud, being a centralized cloud storage and synchronization system for Apple devices, holds a wealth of information, including backups, synchronized data, and tons of sensitive information protected with end-to-end encryption.

iCloud backups, introduced in 2011, store system and application data similar to passwordless local backups. However, synchronized data, like photos from iCloud Photos, may not be present in these backups; these and many other types of data can be retrieved from iCloud by accessing synchronized data.

Accessing iCloud backups typically requires restoring onto a physical Apple device. This is the only way officially supported by Apple; there are no backup management tools and no official way to download iCloud backups from Apple servers. Accessing synchronized data is somewhat easier as some categories can be accessed by setting up iCloud on a Mac or using iCloud for Windows. Still there exists no way to download iCloud backups with official Apple software.

Getting iCloud Data: The Legal Way

To obtain iCloud data legally, forensic experts can request the data from Apple directly. This process involves specific steps and documentation, which can vary depending on the jurisdiction and legal requirements. Additionally, they may need to obtain proper consent or court orders, depending on the circumstances.

Requesting information from Apple must follow a certain pathway. For U.S. law enforcement, Apple has published a number of guidelines for US and non-US law enforcement officials.

• Law Enforcement Guidelines (US)
• Government & Law Enforcement outside the United States

The printable request form is available here:

• Microsoft Word – gle-inforequest.docx (apple.com)

The following general resources are available:

• Privacy – Government Information Requests – Apple
• Legal – Contact Us – Apple
• iCloud User Guide – Apple Support

While the legal pathway ensures that the data is obtained with proper authorization, reinforcing the credibility of the evidence in any legal proceedings, the process may be lengthy and highly complicated.

Alternative Approach to iCloud Data Extraction

Elcomsoft Phone Breaker is a forensic tool that revolutionized iCloud backup extraction by eliminating the need for using authentic Apple hardware to restore iCloud data to. With this tool, experts can download iCloud backups created with devices running all versions of iOS up to and including iOS 16.x, access all types of synchronized data, and even decrypt end-to-end encrypted data (more on that later). Synchronized data encompass various types of information, such as calendars, contacts, notes, and more, which are synchronized by Apple apps across different devices linked to the user’s iCloud account.

To download iCloud backups and synchronized data using Elcomsoft Phone Breaker, the following requirements must be met:

1. The user’s Apple ID and password.
2. A one-time code for two-factor authentication, if enabled on the user’s account.

We published a comprehensive guideline on iCloud extraction:

• Cloud Forensics: Obtaining iCloud Backups, Media Files and Synchronized Data

End-to-End Encrypted Data

End to end encryption is used as an additional protection layer to safeguard some of the most sensitive information against unauthorized access even if the intruder knows the login and password to the user’s cloud account. Technically, end-to-end encrypted records belong to synchronized data. Data protected with end-to-end encryption requires an additional secret to unlock the encryption key. That key can be unlocked with a screen lock passcode (iOS) or macOS account password of one of the trusted devices. End-to-end encrypted data include iCloud keychain (authentication data and passwords), Health, Safari browsing history, iMessages, and several other categories.

Downloading end-to-end encrypted data requires all of the following:

• The user’s Apple ID and password
• One-time code for two-factor authentication (a must; end-to-end encryption is not available for accounts without two-factor authentication)
• Screen lock passcode or system password of a trusted Apple device with the same Apple ID

Apple itself states that it cannot provide this encrypted information when serving legal requests. However, our software is capable of retrieving end-to-end encrypted data, but requires the user’s passcode or password from one of the trusted devices associated with the iCloud account. This capability makes Elcomsoft Phone Breaker the only tool on the market capable of extracting end-to-end encrypted data.

Advanced Data Protection for iCloud

Advanced Data Protection for iCloud is an optional setting that provides Apple’s highest level of cloud data security. When enabled, it offers end-to-end encryption for the majority of the user’s iCloud data, including iCloud backups, photos, notes, and more. This advanced encryption ensures that no one, not even Apple, can access end-to-end encrypted data, making it highly secure, even in the event of a cloud data breach. As forensic experts, it’s important to be aware of this data protection feature, as it means that data stored in iCloud accounts with this feature enabled may not be accessible using either the legal pathway or conventional forensic tools, including our software. While our software excels in extracting a wide range of iCloud data, Advanced Data Protection poses unique challenges due to its advanced protection measures.

Legal Considerations

When it comes to forensic investigations for legal proceedings, complexities arise. While ongoing investigations have clearer guidelines, presenting evidence in court requires meticulous adherence to legal standards and potential challenges from opposing parties. Therefore, forensic experts must be educated in legal procedures and practices to ensure the integrity of their findings.

Conclusion

iCloud acquisition is a valuable resource for forensic experts facing challenges in acquiring data from locked, broken, missing, or wiped devices. While classic acquisition methods provide access to certain data, iCloud extraction opens up new possibilities for retrieving crucial information, even including end-to-end encrypted data. However, forensic experts must be aware legal complexities and always ensure compliance with the law to uphold the integrity of their investigations.

Acquiring data from Apple devices, specifically those not susceptible to bootloader exploits (A12 Bionic chips and newer), requires the use of agent-based extraction. This method allows forensic experts to obtain the complete file system from the device, maximizing the amount of data and evidence they can gather using the iOS Forensic Toolkit. In this article, we will discuss some nuances of agent-based iOS device acquisition.

How does it work?

Technically speaking, agent-based extraction involves gaining extended (usually root) privileges and bypassing the device’s sandbox restrictions. This enables access to the data in all the folders, and allows experts accessing all the files on the device, as well as the keychain. However, this process is far from simple. Apple iOS employs multiple layers of protection, making it challenging to breach. Mere kernel read/write access is insufficient; several exploits (a chain of exploits) are necessary to achieve the desired outcome.

The first step in the process is to install our app, known as the Agent, onto the target iPhone. However, this task presents a considerable challenge. But first let’s briefly explore the concept of sideloading.

What is sideloading?

Sideloading refers to the installation of apps on a device through methods other than the official App Store. This method involves using tools like Apple’s own Xcode or a third-party app, or utilizing an unofficial signing service (mostly using leaked enterprise certificates) directly on the device. To sideload an app on devices running iOS 16, users must enable Developer Mode in the device settings beforehand. Older versions of iOS do not require a special mode to sideload. Generally, Apple does not support sideloading, except for internal app testing and development using the official SDK. Official sideloading support might be coming to iOS 17 in conformance with the new EU directive, yet at this time we don’t know much about it.

After sideloading the app onto the device using a non-developer account, one must navigate to Settings > General > Device Management and trust the developer certificate associated with the sideloaded app. The certificate will be validated through ppq.apple.com. This additional step is required to allow the device recognize the app and allow it to run. This requires allowing the device to connect to an Apple server, which in turn has certain forensic consequences. There are several ways to solve this issue, one of which is using an Apple account enrolled into the Developer Program, and another using a software or hardware firewall to restrict device connectivity.

The importance of Apple ID

If the device is not jailbroken (we can safely assume it is not), sideloading the agent requires an Apple ID. No alternative methods exist. Whether you possess an Apple Developer account or not determines the approach you can take, and this distinction is crucial. Non-developers can sideload apps onto iOS devices only from macOS, but it necessitates bringing the device online, which poses certain risks (explained below).

Apple Developer accounts

Having an aged Apple Developer account is ideal for our purposes. With this type of account, sideloading the agent, or any other app, becomes a straightforward process. Furthermore, it is important to note that with iOS 15 and 16, sideloaded apps need additional verification during the first run, and presently, no workarounds exist for this limitation. However, if the account was registered prior to June 6, 2021, there is no requirement to bring the device online when launching the app for the first time (which only applies to devices running iOS 15 and 16 anyway). The request is processed through humb.apple.com.

For those using a corporate developer account rather than a personal one, keep in mind that Developer privileges alone are insufficient to sideload apps; App Manager privileges are also necessary.

An Apple Developer account allows you to sideload an app on up to 100 devices of each type (iPhone and iPad, in our case) per year. Nevertheless, there is a catch. After the tenth device, a delay of up to 72 hours occurs before adding a new device to the account and permitting app sideloading. The reasoning behind this limitation remains unknown, and it is highly unlikely that it is an anti-forensic measure.

Regular accounts

Regular, non-developer accounts can also be utilized for sideloading the agent (macOS only). However, it is important to have a trusted device connected to the account. Nonetheless, this is not the only obstacle. The main challenge lies in the requirement to verify the app’s certificate online from the device. The risks associated with allowing the device to access the internet are evident: it may actively sync and may be subject to remote lock/wipe commands.

Signing an app using a non-developer account also has a limitation: a maximum of three devices per week. Of course, you can create a new Apple ID, but remember to have a trusted device associated with it.

A brief note on firewalls

What should you do if the agent’s certificate needs verification or if the agent attempts to connect to the internet during its initial run? Solutions do exist:

• Sideloading the Extraction Agent using a Firewall
• Open-Sourcing Raspberry Pi Software for Firewall Functionality

The hardware-based solution is more robust, but requires additional hardware (Raspberry Pi or Orange Pi), adapters and cables. However, it is essential to note that these solutions are not foolproof, as Apple may modify the app verification process at any time.

Conclusion

If you possess an Apple Developer account created before June 2021, congratulations! You have an easier path ahead. Otherwise, paid accounts may not be worth the investment (unless you’re using Windows) since you will still need to bring the device online. However, rest assured, we have a solution to address this hurdle.

For forensic experts dealing with mobile devices, having a reliable and efficient forensic solution is crucial. Elcomsoft iOS Forensic Toolkit is an all-in-one software that aids in extracting data from iOS devices, yet it is still far away from being a one-button solution that many experts keep dreaming of. In this article, we will walk you through the preparation and installation steps, list additional hardware environments, and provide instructions on how to use the toolkit safely and effectively.

Installation Steps

The software is available in Windows and macOS editions, and there are two major releases available: v7 and v8. However, please note that v8 is exclusively designed for macOS, with a Linux version coming soon. To obtain the software, visit the official Elcomsoft website and follow the instructions provided when purchasing the license. You will need a registration code (the one starting with “IOFT-“) to download the software. Here’s what you’ll find on the website:

Elcomsoft iOS Forensic Toolkit v.7

• Windows Edition
• macOS X Edition

Elcomsoft iOS Forensic Toolkit v.8

• macOS Big Sur, Monterey and Ventura (Intel and Apple Silicon)
• macOS High Sierra, Mojave, Catalina (Intel only)

Version 7 offers a slightly simpler user interface with a text-based menu displaying available commands for data extraction. On the other hand, Version 8 is more advanced and feature-rich. Elcomsoft plans to release v8 for Windows and Linux platforms soon, leading to the retirement of v7.

To install Version 7, simply run the installer and provide the installation password. If you’re using a Mac, you might encounter a warning message on the first run; in such cases, just confirm the warning.

To install Version 8, mount the .dmg file (select the appropriate platform) and enter the password. Then, copy the folder named EIFTx.y (where x.y denotes the version number) to a folder on your local computer, such as the desktop folder. The next step involves opening the Terminal and removing the ‘quarantine’ flag from the entire program folder. Use the following command:

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

For example:

xattr -r -d com.apple.quarantine /Users/JohnDoe/Desktop/EIFT8.31

Using Elcomsoft iOS Forensic Toolkit v8

Once the installation is complete, navigate to the EIFT folder using the Terminal. For example:

cd /Users/JohnDoe/Desktop/EIFT8.31

Elcomsoft iOS Forensic Toolkit v8 provides a command-line interface (CLI). To utilize it, follow this format:

./EIFT_cmd {command}

For instance, to gather information about the connected iPhone, use the following command:

./EIFT_cmd info

Running the program without any parameters will display the complete list of commands and their respective options. For detailed instructions, consult the product manual, which provides comprehensive descriptions of each command.

Important note: Ensure that the USB dongle remains inserted throughout your work with the program. Do not remove it during the data acquisition process.

Additional Hardware Requirements and Working Environment Considerations

In addition to the software, you will require some additional hardware components to effectively use Elcomsoft iOS Forensic Toolkit. While having a computer (preferably a Mac) is essential, there are other cables, adapters, and extras that may be needed. We will soon release a comprehensive list of these devices. Even if you don’t need them immediately, it’s advisable to be prepared.

It is ideal to work in an isolated room, preferably a Faraday tent. Using a Faraday bag alone may not be sufficient, as you will need to connect the device to the computer and utilize its screen during the forensic process.

Device Preparation

Before beginning the forensic process, it’s important to ensure that the device you are working with is adequately charged. We recommend a minimum charge of 20%, although having 50% or more is preferred. This recommendation applies unless you are working with an Apple TV or Apple HomePod connected to a power supply.

It is crucial to have the correct date and time set on the device, as this plays a significant role in the agent acquisition method.

If you plan to use the extraction method based on a bootloader exploit, make sure you are familiar with the appropriate buttons needed to put the device into Recovery mode and DFU (Device Firmware Update) mode. Typically, these buttons include Power, Home, and Volume Down. For certain acquisitions, the touch screen should also be functional, e.g. to enter a passcode.

Regardless of the acquisition method you choose, it is vital to keep the device in Airplane mode. In addition to that, we strongly recommend manually checking (and disabling, if necessary) the individual wireless toggles for Wi-Fi and Bluetooth networks as these may not be automatically disabled when the device is placed to Airplane mode. This serves two purposes:

• Preventing the device from syncing: By disabling syncing, you minimize changes that could occur on the device during the forensic process.
• Preventing remote lock/wipe: If the device has FindMy enabled, keeping it in Airplane mode ensures that it won’t be remotely locked or wiped.

Please note that for some specific scenarios, such as iPhone 8, iPhone 8 Plus, or iPhone X running iOS 14 or 15 and utilizing the checkm8 exploit, you may need to reset the device settings. Once you do, the wireless isolation mode is automatically disabled after reboot, and it’s important to ensure that the iPhone does not accidentally connect to a cellular network (if a SIM card or e-SIM is inserted) or a known/open Wi-Fi access point.

Choosing the Right Acquisition Method

When using Elcomsoft iOS Forensic Toolkit, it’s important to select the appropriate acquisition method for the given device. We provide detailed information on this topic in our resource titled “Approaching iOS Extractions: Choosing the Right Acquisition Method.” It is crucial to gather as much information as possible about the device and plan the acquisition accordingly. In some cases, multiple methods may be applicable, and selecting the correct order is essential. Making the wrong choices at this stage can result in negative consequences, such as unnecessary changes to the device, the loss of irreplaceable data, or missing critical evidence.

While we won’t describe all the methods and commands in detail within this article, our product manual provides comprehensive coverage. However, we would like to highlight some important issues that may arise during the process. Please pay close attention to the information presented here, as it complements the documentation.

For example, if the device is vulnerable to a bootloader exploit, it is advisable to use this method first to maintain the forensic integrity of the process.

Extended Logical Acquisition

Logical acquisition is the simplest and most universal method that works for all Apple devices. However, it returns a limited set of data. Extended logical acquisition includes:

• Full device information
• iTunes-style backup *
• Media files and metadata
• Shared app files
• Crash and diagnostics logs

* There are important nuances to consider in this method. For instance, backups contain the maximum amount of data if they are password-protected. However, breaking an unknown backup password is virtually impossible. On the other hand, sometimes the backup password can be extracted from the Windows or macOS computer the device was connected to.

If a backup password is set and you are unable to break or reset it, the other parts of logical acquisition will still work. You can at least obtain media files (including valuable metadata) and logs, which can help build a timeline of device usage. It’s worth noting that logs are often underestimated in their significance. Remember to generate the logs as needed (refer to the manual for instructions). Additionally, we provide resources that offer more information on logs and how to interpret them (see the provided links).

1. GitHub – cheeky4n6monkey/iOS_sysdiagnose_forensic_scripts
2. Checkra1n Era – Ep 6 – Quick triaging
3. Sysdiagnose in iOS 16: a first look from a Digital Forensics perspective
4. iOS Crash Dump Analysis, Second Edition
5. Sysdiag -who? | WithSecure Labs
6. More useful information gleaned from sysdiagnose – The Eclectic Light Company

It’s important to mention that backups can be obtained for iPhone, iPad, and iPod Touch devices. However, for Apple TV, Apple Watch, and Apple HomePod, you can obtain media files, logs, and other similar data. Occasionally, it is possible to access the full file system of these devices as well.

Full File System & Keychain Acquisition: Using Bootloader Exploit

Using the bootloader exploit for full file system and keychain acquisition provides forensic experts with a powerful method for extracting data. By carefully following the instructions for entering DFU mode, booting the device, and understanding the limitations and variations across different iOS versions and device models, one can unlock valuable evidence and ensure a robust forensic investigation process.

DFU Mode

Entering DFU (Device Firmware Update) mode can be a bit tricky, especially for those who are new to the process. Different models require different key combinations, and timing is crucial. It may take a few attempts before successfully entering DFU mode, as the device might simply reboot otherwise.

We recommend entering Recovery mode first, followed by DFU mode. The reason behind this is simple: Recovery mode is easier to enter and rarely fails. Once in Recovery mode, you can set the device to boot only into DFU mode, ensuring a forensically sound process.

Note that iPhone 8, iPhone 8 Plus, and iPhone X (and newer models) can be entered into DFU mode in an automated way. You can find instructions on automating DFU mode using a Raspberry Pi Pico here: Automating DFU Mode with Raspberry Pi Pico. On the other hand, if some buttons on the device don’t work, you may need to disassemble the device and use the test points. Refer to the article “How to Put an iOS Device with Broken Buttons in DFU Mode” for detailed instructions.

For more information on Recovery and DFU modes, you can explore the following articles on our blog:

• Everything about iOS DFU and Recovery Modes
• The True Meaning of iOS Recovery, DFU and SOS Modes for Mobile Forensics
• DFU Mode Cheat Sheet
• iPhone X, DFU mode and checkm8
• Entering DFU: iPhone 8, 8 Plus, and iPhone X
• How to Put Apple TV 3 (2012-2013), Apple TV 4/HD (2015) and Apple TV 4K (2017) into DFU

Booting the Device

Our approach to bootloader-based acquisition differs from other vendors. We detect the iOS (or iPadOS, WatchOS, tvOS) version installed on the device and provide automatic links for you to download and use the corresponding version. This ensures maximum compatibility across all devices and iOS versions. We patch the bootloader on-the-fly during the process.

However, there may be instances where the exact iOS build version cannot be detected. In such cases, we offer several best matches for you to choose from. If the process fails with the selected version, you can try using another one.

Restoring the Device to its Original State

Once your work with the device is complete, and it is time to return it to its owner in its original condition, it is important to reset the autoboot mode flag that is set automatically by iOS Forensic Toolkit to prevent accidental reboots into the main OS. This will ensure that the device can boot into iOS. Enter the following command in the Terminal or command line interface:

./EIFT_cmd tools autobootTrue

Note: the device will undergo an automatic reboot to complete the process.

By following this step, you can ensure that the device is returned to the owner without any modifications made during the checkm8 analysis.

Legacy Devices

Older devices without the Secure Enclave and with HFS file systems follow a different acquisition path compared to iPhone 5s and newer models. You can find detailed information in “Perfect HFS Acquisition“. Certain models can be unlocked by breaking the device’s passcode (with some limitations), while for others, it is possible to extract the full file system regardless of the passcode set.

Limitations

Devices powered by the Apple A11 SoC (iPhone 8, iPhone 8 Plus, and iPhone X) are technically compatible with the bootloader exploit. However, for iOS 14 and 15, you will need to remove the passcode first. There are a couple of issues with this:

• It is not always possible to remove the passcode
• Removing the passcode will result in some data loss, breaking forensically sound process

For iOS 16, the situation is even more challenging. Extraction never works if the passcode has been set on the device since the device was set up, so even removing it won’t help. Please note that this limitation applies only to A11-based iPhones. When dealing with iPads running iOS 16, you may need to remove the passcode, but it’s worth trying with the passcode first, as it often works.

Full File System & Keychain Acquisition: Using the Agent

Agent acquisition is the only available method used to obtain the full file system and keychain from devices based on A12 or newer SoC (System on a Chip). While it offers great potential in theory, practical use can sometimes be challenging.

To begin, you need to sideload the agent onto the device, which had become a challenge. Apple has implemented measures to prevent app installations from sources other than their App Store. However, it is still possible to sideload apps, especially with an account registered in the Apple Developer Program. Regular accounts can also work, but there may be additional hurdles to overcome.

The main challenge arises when the app, particularly our extraction agent, requires online verification. This can be problematic due to the need for device isolation and the associated risks of enabling online access to the device. To address this, you may need to set up a software or hardware firewall to control the verification process. It’s worth noting that even with a developer account, there are limitations. For example, only the first 10 devices (out of a total allowance of 100) are added in real-time, while for subsequent devices you may need to wait up to 3 days for the device to be “connected” and allow the agent to run. Additionally, iOS 16 requires enabling a special developer mode on the device (after agent installation).

In terms of version compatibility, agent-based acquisition is not as versatile as bootloader-based methods. While some zero-day exploits exist, it is unlikely that we will be able to work with the latest iOS versions. At the time of writing, our tool covers iOS 12 to 16.4. Note that support for iOS 9 to 11 was available previously but had to be removed due to technical reasons. However, if you urgently require support for those older versions, you can still use an older version of our product.

A Note about A11 Bionic

There is something specific about the A11 SoC that sets it apart from other chips (A12 Bionic and newer). It is comparatively less vulnerable, and fewer exploits are available for it. Consequently, in some cases, we can only obtain a partial file system using the agent, and the keychain may not be accessible.

Troubleshooting

No software is completely free of bugs, and it’s impossible for us to test every model/iOS combination thoroughly, despite our extensive testing with over 70 combinations and ongoing efforts to expand coverage. In version 8 of the toolkit, the logs are stored in the following folder:

~/Elcomsoft/EIFT/logs

If something goes wrong during the process, kernel panic logs can be incredibly helpful. You can find these files, named panic-full-{timestamp}.ips, on the device itself under:

Settings | Privacy & Security | Analytics & Improvements | Analytics Data

From there, you can use AirDrop or other methods to transfer the logs from the device to your Mac (or another iPhone, for example).

However, before delving into advanced troubleshooting steps, sometimes a simple reboot of your Mac and retrying the process can resolve minor issues.

Using the DCSD Adapter for Advanced Troubleshooting

In some cases, when utilizing an acquisition method based on the bootloader exploit, the logs mentioned earlier may not be sufficient to detect and resolve issues that may arise. To overcome such challenges, we highly recommend obtaining the DCSD adapter. This adapter is specifically designed for serial debugging purposes, allowing you to capture the traffic between the host and the device. It creates its own log, providing valuable insights when working with specific devices and iOS combinations that may encounter difficulties.

While we sincerely hope that you will never need to use the DCSD adapter, we strongly advise acquiring one as a precautionary measure. Its availability can prove invaluable in resolving complex issues during the forensic process. For detailed instructions on how to utilize the DCSD adapter effectively, please refer to the product manual, which provides comprehensive guidance.

By having the DCSD adapter at your disposal, you can enhance your troubleshooting capabilities and ensure a more robust and thorough analysis when using iOS Forensic Toolkit.

Conclusion

Elcomsoft iOS Forensic Toolkit offers forensic experts a powerful solution for extracting data from iOS devices. By following the installation instructions, considering additional hardware requirements, preparing the device appropriately, and selecting the right acquisition method, forensic experts can maximize their efficiency and accuracy in obtaining crucial evidence. Whether utilizing the logical acquisition method, the bootloader exploit, or the agent-based approach, each method has its considerations and limitations, which were outlined in this article. By understanding the nuances and troubleshooting techniques provided, forensic experts can navigate the complexities of mobile forensic analysis, ensuring a robust and effective investigative process.

In the world of digital investigations, the sheer volume of data and the challenge of identifying valuable evidence can be overwhelming. Often, investigators find themselves faced with the need for optimization — the ability to quickly and seamlessly identify what is valuable and requires further examination. We aim to fulfill this need by introducing a new forensic toolkit in Elcomsoft System Recovery, a powerful bootable tool designed to speed up investigations, quickly identify and collect digital evidence right on the spot.

The challenge of overburdened labs

Experts are overwhelmed with analyzing vast amounts of computers and data, which can lead to significant backlogs. Statistics show that numerous computers and disks lie dormant for months, not only leading to wasted time and effort but placing roadblocks on the way of criminal investigations. To address this issue, we have developed a streamlined approach, revolutionizing the way investigations are conducted.

Our approach

To help experts streamline investigations, we created Elcomsoft System Recovery, a portable field analysis tool for computer forensics. Built as a forensically sound computer analysis tool, Elcomsoft System Recovery enables experts to make real-time decisions on the spot. Key benefits of Elcomsoft System Recovery include:

1. Unparalleled compatibility: By utilizing the licensed Windows PE environment, Elcomsoft System Recovery ensures exceptional compatibility across various systems and hardware configurations. This compatibility enables investigators to access digital evidence on the nearly every Windows device in existence.
2. User-friendly experience: The tool runs off a ready-to-use bootable disk, simplifying the analysis and making it almost a one-click solution. Investigators can seamlessly navigate the interface, harnessing its power with ease and efficiency.
3. Breaking through password barriers: Elcomsoft System Recovery’s core functionality revolves around gaining access to crucial data without knowing the user’s Windows account password. This unique feature empowers investigators, enabling them to uncover vital evidence that may have otherwise remained inaccessible.
4. Quick access to essential data: In a matter of minutes, Elcomsoft System Recovery efficiently retrieves the most critical and valuable information. From passwords to important documents, the tool uncovers a wide array of artifacts, providing investigators with a solid foundation for decision-making.
5. Identifying potential leads: Upon discovering potentially significant findings, Elcomsoft System Recovery allows investigators to create forensic disk images for further analysis. These images serve as a starting point for deeper exploration, facilitating a thorough examination of potential leads.
6. Saving time and resources: By speeding up the identification and extraction of essential evidence, Elcomsoft System Recovery significantly reduces the strain on experts. This optimization frees up valuable time and resources, enabling investigators to focus on high-priority cases and complex analyses.

The “low-hanging fruit” strategy

Just like a fruit picker in an orchard, law enforcement professionals conducting digital investigations often encounter a similar concept known as the “low-hanging fruit” principle. Let’s imagine you’re strolling through an orchard, and the fruit within easy reach can be effortlessly picked as you walk by. However, if you want to reach the fruit higher up, you’ll need to drag a ladder, spending additional time and effort.

When it comes to digital investigations, the low-hanging fruit principle suggests that investigators should first target the most accessible and crucial pieces of evidence. These can include items like passwords, readily available documents, encryption keys, or logs of user activity. By swiftly and efficiently obtaining this information, investigators can establish a solid starting point for further analysis.

Applying the low-hanging fruit principle not only saves time but also allows investigators to make significant progress early on, effectively reducing or even eliminating potential backlog. By quickly gathering the most essential evidence, they can assess the situation, identify potential leads, and determine the next steps of the investigation. This strategic approach is particularly valuable when faced with limited resources or time constraints.

We designed Elcomsoft System Recovery around the “low-hanging fruit” strategy, allowing investigators to quickly gather the most critical and easily accessible evidence along with keys to encrypted disks and vaults. Since Elcomsoft System Recovery operates as a bootable disk, investigators can extract crucial data and make informed decisions on further actions on the spot. Based on the collected data, investigators can determine whether it is necessary to create a disk image and transport it to the laboratory for further in-depth analysis. This streamlined approach saves time and resources, ensuring that investigations can progress swiftly and accurately in both the field and the laboratory.

It is important to emphasize that Elcomsoft System Recovery goes beyond merely extracting a number of easily accessible forensic artifacts. It aims to provide comprehensive insights into user activity, both online and offline. The tool retrieves passwords, critical documents, and even provides visibility into the applications and files accessed by the user. While the exact list of data collected is extensive and continually expanding, rest assured that Elcomsoft System Recovery strives to quickly retrieve the maximum amount of relevant information on the spot.

Conclusion

By focusing on the most accessible and critical evidence, investigators can make swift progress and establish a strong foundation for their investigation. It is essential to balance this approach with the willingness to explore deeper, more complex areas when necessary. This strategic combination ensures a thorough and successful investigation.

When it comes to iOS data acquisition, Elcomsoft iOS Forensic Toolkit stands head and shoulders above the competition. With its cutting-edge features and unmatched capabilities, the Toolkit has become the go-to software for forensic investigations on iOS devices. The recent update expanded the capabilities of the tool’s low-level extraction agent, adding keychain decryption support on Apple’s newest devices running iOS 16.0 through 16.4.

Low-Level Extraction: File System Image and Keychain

iOS Forensic Toolkit is an all-in-one solution for iOS data acquisition. The low-level extraction agent, in particular, sets the tool apart from the competition. While we have already established ourselves as pioneers in checkm8 extractions and extended support to Apple TV, Apple Watch, and HomePod devices in addition to the full range of iPhone and iPad devices, our dedication to innovation continues.  We were among the first to implement low-level extraction support for the range of iPad models based on the Apple M1 and M2 chips, ensuring compatibility across a wide range of Apple devices.

The previously posted update gave our tool the ability to extract the full file system image from supported devices (which include all iPhones from the Xs/Xr up to the iPhone 14/14 Pro range, and iPads up to M1/M2), yet we have not included support for the keychain at the time. While low-level file system extraction is impressive on its own, the ability to decrypt and access the keychain opens up a wealth of opportunities for forensic investigators. We are proud to introduce full keychain decryption support for the same range of devices, at the same time expanding the range of supported OS versions.

The keychain stores crucial encryption keys required to unlock protected messaging applications like Signal. The keychain safeguards users’ online account passwords, granting investigators access to vital information that can shed light on their digital activities.

The current support matrix looks as follows:

iOS 16.4 Support and Beyond

Our company remains at the forefront of iOS forensic tools, constantly evolving to meet the demands of the ever-changing landscape. While the latest updates to iOS Forensic Toolkit introduced support for iOS 16.4, further enhancing its capabilities, we are committed to staying ahead of the curve, and our development team is diligently working on supporting subsequent iOS versions, including iOS 16.4.1 and 16.5. With each update, we ensure that forensic professionals have the tools they need to extract and analyze data from the latest iOS devices.

Conclusion

Elcomsoft iOS Forensic Toolkit continues to be the unrivaled leader in iOS data acquisition. With its powerful extraction agent, support for iPhone models up to and including the latest iPhone 14/14 Pro range and iPad models based on M1 and M2 chips, and the ability to decrypt keychains, EIFT empowers forensic investigators with comprehensive access to valuable information. The recent addition of iOS 16.4 support, alongside the ongoing commitment to support upcoming versions, solidifies EIFT’s position as the most advanced iOS acquisition software on the market. We are working dilligently to unlock new possibilities in your forensic investigations.

A while ago, we introduced an innovative mechanism that enabled access to parts of the file system for latest-generation Apple devices. The process we called “partial extraction” relied on a weak exploit that, at the time, did not allow a full sandbox escape. We’ve been working to improve the process, slowly lifting the “partial” tag from iOS 15 devices. Today, we are introducing a new, enhanced low-level extraction mechanism that enables full file system extraction for the iOS 16 through 16.3.1 on all devices based on Apple A12 Bionic and newer chips.

TL&DR

The previously announced partial file system extraction mechanism that, at the time, allowed low-level access to third-party app data for devices running iOS 16.0 through 16.1.2, has been refined. The enhanced process now delivers full unrestricted file system extraction (currently without a keychain) for a set of devices with iOS/iPadOS 16.0 through 16.3.1. iPhone Xs/Xr and newer devices are supported, including the iPhone 14 and 14 Pro range as well as iPad models based on the latest M1 and M2 chips.

Still no keychain (but coming soon)

We pushed this release as forensic experts do have a backlog of Apple devices with iOS 16.3.1 and older. The new extraction process enables low-level access to the file system, which includes access to sandboxed app data, system databases and other information available in the file system. We are working on bringing full keychain decryption support, which is scheduled for one of upcoming releases. We are also working on iOS 16.4 support.

The updated compatibility matrix:

Before: partial file system extraction for iOS 16.0-16.1.2

iOS Forensic Toolkit comes with a custom low-level extraction agent. Technically, the extraction agent is an app that, when installed on an iOS device, attempts privilege escalation by attempting to exploit one or more vulnerabilities in the operating system. For the most part, the exploits used in the extraction agent are kernel-level exploits allowing full sandbox escape with low-level access to the file system and keychain records.

For a long time, no usable exploit was available for any version of iOS 16. When one was finally discovered, it turned to be a weak exploit that was not quote up to the task of enabling full access to the  file system, let alone decrypt the keychain. When we initially used that exploit, we’ve been unable to fully escape the sandbox, as some protective mechanisms were still in place. As a result, we’ve been only able to offer access to parts of the file system, mostly with data of third-party apps. Obviously, that approach left many kinds of data out, so we continued our research that lead us to today’s release.

Now: full file system extraction for iOS 16.0-16.3.1

We are proud to release an update to iOS Forensic Toolkit with full file system extraction support for iOS/iPadOS 16.0 through 16.3.1. We’ve been able to fully escape the sandbox and gain access to previously inaccessible types of data, which includes the full file system. Currently, we do not support keychain decryption for these versions of iOS, but an update is coming soon.

The list of supported devices includes:

• A12: iPhone Xr, iPhone Xs, iPhone Xs Max
• A13: iPhone 11, iPhone 11 Pro, iPhone 11 Pro Max, iPhone SE (2nd gen)
• A14: iPhone 12, iPhone 12 Mini, iPhone 12 Pro, iPhone 12 Pro Max
• A15: iPhone 13, iPhone 13 Mini, iPhone 13 Pro, iPhone 13 Pro Max, iPhone SE (3rd gen), iPhone 14, iPhone 14 Plus
• A16: iPhone 14 Pro, iPhone 14 Pro Max
• All corresponding iPad models including iPad Air 5 and iPad Pro 5 (Apple M1), iPad Pro 6 (Apple M2)

Coming soon: keychain decryption and iOS 16.4 support

Certain data remains inaccessible without the complete chain of exploits. Secure messaging platforms, in particular, often necessitate specific keychain information for successful extraction. We are working hard to improve the extraction agent with additional features and expanded supported OS range. The next planned update will include iOS 16.4 support and keychain decryption for the entire iOS 16.0 – 16.4 range. Stay tuned!

Escalating complexity in iOS forensics

In an era defined by rapid technological advancements, the battle between digital security and forensic experts who seek legal access to incriminating evidence grows increasingly complex. The interplay between exploit chains, extended development timelines, and lagging support for iOS updates from vendors of forensic software poses significant challenges for both security experts and forensic specialists.

Data extraction stands as a primary stage of any forensic investigation. The success of subsequent analysis and evidence collection hinges on the effectiveness of this initial step. Therefore, it is crucial to employ reliable and comprehensive data extraction techniques.

With the advent of newer devices, starting from the iPhone 12, traditional methods for passcode recovery have become increasingly ineffective, even in high-end forensic tools. As a result, investigators must explore alternative, non-technical methods to obtain passcode information to enable access to the data. Device security measures have become increasingly complex, incorporating multiple layers of defense. Exploit chains required for bypassing these protections have grown longer, making the task of gaining access to secure devices more challenging than ever before.

There is often a significant time gap between the release of iOS versions and the availability of corresponding data extraction support from forensic tools. This delay can extend several months, impacting investigations. For example, iOS 16.3.1 supported in this release of iOS Forensic Toolkit was released on February 13th, while version 16.4 was released on March 27th. In addition to the delays in version releases, subsequent updates and patches quickly follow major iOS versions. For instance, while we are currently finalizing support for iOS 16.4, the already patched versions of iOS 16.4.1, 16.4.1a, 16.5, 16.5.1, and even a beta version 16.6 are already out. This rapid succession of updates poses ongoing challenges for forensic experts.

So what about those currently unsupported versions of iOS? For those newer iOS builds, the only viable option remains advanced logical extraction. This method allows the extraction of media files, including metadata, shared app data, and valuable diagnostic logs. However, it is important to note that this approach, while valuable, does not return many crucial bits and pieces such as email messages or conversation histories in most popular instant messaging apps.

Using the extraction agents is inherently safe for the device itself; however, it is not as clean and forensically sound as checkm8, and may compromise forensic soundness due to the alterations (however minor) introduced during extraction. However, despite not being classified as a “physical” extraction, the low-level extraction technique employed by the extraction agent yields as much data as that obtained through physical extraction methods like checkm8. We recommend exercising due caution when using this extraction method though, as installing and launching the extraction agent may require online connectivity in certain cases, which presents potential risks. We have a solution for this, which requires a Raspberry Pi device with custom firmware.

We are excited to announce the release of an open-source software for Raspberry Pi 4 designed to provide firewall functionality for sideloading, signing, and verifying the extraction agent that delivers robust file system imaging and keychain decryption on a wide range of Apple devices. This development aims to address the growing security challenge faced by forensic experts when sideloading the extraction agent using regular and developer Apple accounts.

Important: older developer accounts created before June 6, 2021, are exempt from the verification process. If you are using one of these accounts, you will not need a firewall to run the extraction agent.

TL&DR

To perform a low-level extraction of iOS and iPadOS devices, the extraction agent, an essential app, needs to be sideloaded onto the device under investigation. Each sideloaded app, including the extraction agent, must be signed with a unique digital signature specific to the device. When launching a newly sideloaded app on an iPhone or iPad, users are prompted to verify the digital signature, requiring the device to establish contact with an Apple server. However, it is crucial to be aware that connecting the device to the internet poses the risk of remote blocking or erasing its content, especially if it is part of an evidence base.

Previously, we recommended a solution that involved enrolling the Apple ID used for signing the sideloaded app into the Apple Developer program, which in turn allowed for the validation of the digital signature without the need for the device to contact an online server. Unfortunately, due to recent updates on Apple’s side, even digital signatures associated with new developer accounts must now undergo verification with an Apple server. Consequently, this reintroduces the potential risks that were previously exclusive to non-developer accounts. Considering these changes, we have developed a solution based on a Raspberry Pi 4 with open-source software that minimizes risks by limiting the device’s connection solely to the server required for certificate verification.

The importance of extraction agent and the decline of checkm8

The extraction agent is a small app for iOS that we developed in-house to enable low-level file system extraction and keychain decryption on Apple devices being investigated. Once installed onto a device, the extraction agent attempts to escalate its privilege level to break out of sandbox and gain full access to the file system and relevant encryption keys to access and decrypt keychain records.

The significance of the extraction agent cannot be understated, especially as the relevancy of checkm8 diminishes over time. With fewer checkm8-compatible devices and an increasing need to reset passcodes to access information, essential evidence is at risk of being lost. The compatibility gap between checkm8 and iOS 16 has reached critical levels, and iOS 17 can be installed on even fewer devices that are vulnerable to checkm8. While checm8 remains a remarkable extraction method, it is clear that a new approach is necessary.

Agent-based low-level extraction through extraction agent is gaining traction as a viable alternative. Hardware-wise, the extraction agent supports all iPhone and iPad models, including the latest iterations. However, it is important to note that the support for various iOS versions is never complete and requires significant catching up when it comes to supporting the newest builds.

Installing the extraction agent is a challenge

One of the most daunting challenges for forensic experts lies not in the usage but in the installation process of the extraction agent. Since the extraction agent will never be accepted into the App Store, experts must resort to sideloading to install the agent onto a device. The sideloading requires the use of a set of Apple ID credentials to sign the .ipa file being installed. Ideally, an Apple Developer Account, preferably an older one, is required for that purpose. However, even using a developer account is not without its complications.

First, this Device registration update states that, as per Apple’s guidelines, only the first ten devices are added immediately into the Developer program, while subsequent additions face delays of up to three days. This means that the extraction agent cannot be signed and deployed instantaneously. Moreover, online verification of provisioning profiles has also changed for developer accounts created after June 6, 2021 as detailed in the Provisioning profile update.

Contrary to previous practices, the verification now requires connecting to an online server to verify the digital signature:

New Apple Developer Program memberships created after June 6, 2021, require development- and ad-hoc-signed apps for iOS, iPadOS, and tvOS to check in with the PPQ service when the app is first launched. Your device must be connected to the internet to verify the certificate used to sign your app. If you’re behind a firewall, make sure that it’s configured to allow connections to https://ppq.apple.com. If the device can’t successfully make a connection, the app may not launch. If your app is running in a highly restrictive network environment or you need to temporarily build offline, alternative workflows are available.

Contrary to what is stated in the update, the verification takes place on humb.apple.com (and not on ppq.apple.com, which is used for a similar purpose for non-developer accounts), which has a dynamic IP that changes every five minutes. It is crucial to note that this verification occurs at the first launch of the agent or any other signed and uploaded application.

After these updates, the overall utility of developer accounts for the purpose of sideloading the extraction agent has significantly diminished, with standard accounts once again becoming increasingly attractive. While standard accounts limit the number of devices to three per week, creating a new Apple ID can circumvent this limitation if necessary. On the other hand, developer accounts face delays beyond the initial ten devices and are now subject to online verification during agent launch. Consequently, finding a solution for firewall functionality becomes essential for both types of accounts.

Advantages of developer accounts

Despite the challenges faced by developer accounts, they still offer certain advantages over regular, non-developer Apple ID’s. First and most importantly, Windows users can only utilize developer accounts to sideload the extraction agent. The sideloading process we developed for installing the extraction agent with regular, non-developer Apple IDs requires a Mac. Finally, older developer accounts created before June 6, 2021, are exempt from the verification process. For these accounts, you will not need a firewall solution.

Possible alternatives

If you don’t have a Raspberry Pi, you may be able to set up a firewall in an alternative way. We have already published a method that effectively turns your Mac into a firewall. While this method does not require additional hardware, it is more complex and less reliable compared to the Raspberry Pi based solution.

Another method involves setting up a firewall on your router, on which you can try to configure a whitelist. This, however, may not be simple. Even if you know all the addresses that ppq.apple.com resolves to (there are only a few of them), humb.apple.com can resolve to a much wider range of addresses. Only a very small number of routers with standard firmware allow whitelist functionality, especially based on the domain name rather than IP. Alternatively, you may try an alternative firmware such as OpenWRT, which is outside the scope of this article.

Finally, yet another alternative may appear for users in some jurisdictions in iOS 17. According to 9to5mac, a report last year revealed that Apple was working on allowing sideloading with iOS 17, but so far it didn’t happen in the first beta. We are waiting eagerly for the outcome of the new EU regulation.

Using the Raspberry Pi 4 as a firewall

Our Mac-based solution has been available for quite some time, but its usage can be complex and prone to errors (let alone the fact that it is not available to Windows users). It is important to be aware about the risks associated with devices being investigated connecting to the internet, with remote locking or remote wipe on the extreme end of the spectrum, and unwanted data synchronization on the other, which can lead to significant changes and jeopardize admissibility of evidence obtained from such devices.

To solve these issues, we are introducing a new open-source software that transforms the Raspberry Pi 4 into a firewall. With one end of the Pi box connected to the router and the other to the phone, this solution provides enhanced security during the signing and verification process. The software can be found in the public repository on GitHub. It is worth noting that Elcomsoft has an extensive presence on GitHub, with currently 19 projects and more to come. Instructions for using the software will be provided separately in a subsequent article, and rest assured, it is remarkably simple to set up (with a few nuances to consider).

Finally, our solution should work for any other sideloaded applications signed with either regular or developer accounts, which includes alternative agents.

To reduce the risks of exposing the iPhone device being remotely tampered with, we’ll need to restrict it’s online connectivity. Ideally, the iPhone should be only able to connect to a single certificate validation server – with all other communications being terminated. For this we developed an open-source software for the Raspberry Pi 4. This article contains step by step instructions for setting up a Raspberry Pi 4 as a firewall for sideloading the extraction agent.

Pre-requisites

You will need the following hardware:

1. Raspberry Pi 4 or newer (e.g. Raspberry Pi 4 Model B)
2. microSD card
3. Lightning to Ethernet adapter
4. USB to Ethernet adapter

Instructions for setting up a Raspberry Pi as a functional firewall

First, download the firmware image and flash it to an SD card using software like balenaEtcher. You can download balenaEtcher from the following link: https://etcher.balena.io/. Then follow these steps:

• Insert the SD card into your computer
• Launch balenaEtcher and select the downloaded/compiled firmware image (eiftpi.img)
• Choose the SD card as the target drive
• Click on the “Flash!” button to write the firmware image to the SD card
• Once the process is complete, remove the SD card from your computer

You will need two network interfaces on the Raspberry Pi. One interface will be connected to the internet, and the other will be used to connect the iPhone. To connect the iPhone, you will need a Lightning to Ethernet adapter.

• We recommend to use a USB-A to Ethernet adapter to connect the Raspberry Pi to the internet.
• Alternatively, you can connect the Raspberry Pi to the internet via Wi-Fi.

Important: the iPhone must be connected to the built-in Ethernet port.

Note: We purposely use a wired connection and do not recommend enabling WiFi on the iPhone as it may cause the device to accidentally to connect to a different known network, which would expose the risk of remote wipe.

For a simple and more reliable setup, use two wired connections. This is why you need the USB to Ethernet adapter.

If you prefer to connect the Raspberry Pi to Wi-Fi, follow these steps:

• Connect the Raspberry Pi to your Mac using Ethernet. (Note: If your MacBook does not have an Ethernet port, you will need a USB-C to Ethernet or USB-A to Ethernet adapter.)
• Open a terminal on your Mac and enter the following command:
  ssh eift@192.168.41.1
  • The password is “Elcomsoft” (without quotes).
  • Once you are logged in, run the following command to configure Wi-Fi:
  sudo nmtui

  • The nmtui interface will allow you to easily connect to the Wi-Fi network.

That’s it! You have now set up the Raspberry Pi with the firmware. Connect the Pi to the network (either via Ethernet or Wi-Fi) and connect your iPhone to the Pi using a cable. Note: we recommend to first use a test iPhone to ensure that internet access is restricted, while only ppq.apple.com, humb.apple.com and elcomsoft.com should be accessible.

Conclusion

As we have shared our open-source software for Raspberry Pi 4 with firewall functionality, we aim to secure the sideloading of the extraction agent in the iOS ecosystem. The limitations of checkm8 and the complex nature of developer accounts have necessitated new approaches to ensure data security. By embracing open-source solutions and providing alternatives, we strive to empower forensic experts and enhance the effectiveness of the extraction agent in safeguarding valuable information.

In the digital age, where information is a precious commodity and evidence is increasingly stored in virtual realms, the importance of preserving digital evidence has become a must in modern investigative practices. However, the criticality of proper handling is often overlooked, potentially jeopardizing access to crucial data during an investigation. In this article, we will once again highlight the importance of meticulous preservation techniques and live session analysis to prevent the loss of digital evidence.

Why password recovery is not (always) an answer

Password recovery tools such as Elcomsoft Distributed Password Recovery are commonly used to recover access to encrypted evidence by attacking (and recovering) the original plain-text password. It is important to realize that most data formats are designed specifically to withstand brute-force attacks. In real life, the attack will probably take a long time, and a chance to break a password to an encrypted container with brute force is far from a guarantee. We collected and analyzed information published about some 53 cases involving encryption, and found out that encryption was only successfully broken in 10 cases. In other words, we strongly recommend performing other types of analysis (and collecting as much supplementary information as possible) before resorting to password recovery techniques.

For example, this is how fast our tool can try VeraCrypt passwords depending on the key generation function and encryption method used. The speed of around 1,000 passwords per second means that even the simplest password consisting of only 6 English letters and no numbers will take 3.5 days to break. As for a typical 8-character password, which includes an unknown mixture of numbers, lowercase and uppercase English letters, breaking it through brute-force would consume nearly 7,000 years. Even if you were to enhance the attack by employing a distributed network of computers, each equipped with several potent GPU accelerators, we would still be facing years, not days, of persistent attacks. A password more complex than that would leave the brute-force attack no chances.

Year after year, the field of digital forensics and incident response (DFIR) presents us with new challenges. Various vendors from around the world are tirelessly striving to simplify and enhance the work of experts in this field, but there are some things you probably do not know about (or simply never paid attention to) that we discussed in the first part of these series. Today we’ll discuss some real cases to shed light onto some vendors’ shady practices.

The yellow leader T-Shirt

One striking observation is the prevalence of self-proclaimed leaders among these vendors. It’s fascinating to see the consistent use of grandiose titles in their press releases. Almost every company claims to be the “global leader” or “industry’s leading provider” in digital forensics and intelligence solutions. I absolutely love this; here are some real quotes from press-releases of different vendors:

• Company A, the global leader in Digital Intelligence Solutions…
• Company B, a global leader in forensic technology for mobile device investigations…
• Company C is a global leader in digital forensics technology…
• Company D, a global leader in digital forensics for law enforcement…
• Company E, the industry’s leading provider of digital forensic investigation technology…
• Company F is a world leader in forensic technology…
• Company G is a global leader in digital forensics software.
• Company H is a leading provider of mobile device digital forensics.

There is one vendor that stands out from the crowd, and they have earned immense respect from us precisely because they refrain from such self-promotion. They must be the real leader after all:

“Founded in 2010, Magnet Forensics is a developer of digital investigation software that acquires, analyzes, reports on, and manages evidence from digital sources, including computers, mobile devices, IoT devices and cloud services.”

Secrets are lies by another name

Another intriguing aspect pertains to the secrecy surrounding certain products. Some vendors require customers to sign nondisclosure agreements (NDAs), preventing discussions about sensitive topics such as the capabilities of their products.

No discussion of sensitive topics commonly protected by NDA such as PRODUCT’s capabilities.

Can you imagine that the features and capabilities of a tool are protected with a NDA? The reasons behind such restrictions may vary. One motive could be the desire to conceal vulnerabilities. In the past, a software vendor revealed that wide disclosure had led to severe repercussions, prompting Apple to restrict certain forensic capabilities. Another reason could be the fear of competitors gaining access to valuable information, potentially resulting in stolen ideas or advantages. Here is what we one software vendor told us in a comment to our blog article:

There have been cases where that wide disclosure policy has caused severe implications and responses from Apple’s side – directly causing the unfortunate shut down of capabilities the forensics community had before the disclosure.

However, the true motivations for these NDAs are likely different. Vendors are primarily focused on selling licenses, preferably through long-term contracts, with the expectation that customers will eventually become accustomed to the limitations imposed. In our view, the entire “they’ll get used to it because the choice of available tools in the field is limited” approach is borderline bait-and-switch tactics.

Anyways, whatever the reasons are, the complete product specifications, including a comprehensive list of supported devices, detailed extraction and recovery methods, and any limitations, are often withheld. All you get is some marketing descriptions such as “Advanced strategy 1” or “Supersonic brute-force” without a mention of any specific requirements or limitations. In some cases, even after acquiring a license, customers may still find themselves lacking vital information, unless they attend expensive courses that may cost more than the license itself.

Need for speed

When it comes to passcode cracking, the lack of transparency becomes even more apparent. Most vendors avoid publicly disclosing the speed at which their tools can crack passcodes. Instead, they use terms like “brute force,” “supersonic brute force,” “SE-bound fast brute force,” and “Brute Force Turbo Boost v2.” The only numbers provided are often framed in comparisons, such as “6-digit passcodes in under 24 hours (other vendors ~25 years)” or “Can Brute Force 6-digits in 6 months”.

It is evident that obtaining accurate and comprehensive information about passcode cracking speeds is quite challenging. In case if you are curios, “supersonic” brute-force is slightly above 5,000 APD (Attempts Per Day); I am not saying this speed is bad (especially as most other vendors cannot do that at all), but I definitely would not call it “supersonic”.

Juggling with Numbers

The bigger, the better! In product descriptions, you have probably come across texts like this:

Version X.Y supports over N device models, more than M application versions, and P cloud services.

The numbers are staggering, reaching tens of thousands. However, upon closer inspection, one thing becomes clearly apparent: the so-called “different” device models are in fact a number of nearly identical models. The inflated numbers account for every variations like memory capacity or color (they do receive different model identifiers).

The intrigue develops to the count of supported apps, where every version ever released counts, even if the data format remained unchanged. The same goes for cloud services – for example, some manufacturers count a dozen “different” services from a single Apple iCloud service, considering each data category like contacts or calendars as separate services.

When it comes to artifacts, things get even more amusing. For instance, while reviewing the backup contents of my iPhone in one of the products, I came across some 7,000 Apple Wallet artifacts:

When I examined them closer, the counter displayed a significantly lower number, but even there, the data was heavily inflated (the actual number of records was less than 300):

The same approach is often applied to data from other applications – practically any data and files, no matter how meaningless or useless, are considered “artifacts.”

Such exaggerations significantly hinder the customers’ ability to correctly assess whether all the data has been extracted and analyzed. It becomes even more challenging to verify the results by comparing what different programs yield. One product shows 7,120 “artifacts” in a certain category, while another might display two thousand, and yet another product displays only 288 (based on the actual number of records). Evaluating which product has performed more accurately is nearly impossible, thanks to these “inflations.”

The first and only

We all love Apple’s presentations with all these “amazing”, “exciting”, “incredible” and so on. But there is only one Apple.

In the highly competitive world of digital forensics, vendors constantly strive to be at the forefront, claiming to be innovative and the first to introduce groundbreaking features. However, the reality doesn’t always align with these vendors’ claims. It is not uncommon to witness conflicts on social media platforms like Twitter and LinkedIn, where one company touts a supposedly revolutionary new feature, only to be countered by another company claiming they had already implemented it years ago. The race to be first can lead to dubious claims and attempts to redefine innovation to fit marketing narratives.

Once upon a time I experienced a similar thing. One company publicly claimed that they were those who invented “cloud forensics”. I was really surprised as we were the first (indeed) who released iCloud acquisition software over 10 years ago; so I wrote personally to their marketing director, and reminded her about that. “Yes, I know that”, she replied, “but we support more cloud sources, so our software deserves the ‘first’ anyway”. Oh, never mind.

Another company decided to advertise that they were the second who implemented a certain feature. So what? Does that mean that a potential customer should first try the solution of the company who claims to be the first, and if they don’t like it for some reason, pick the next one who was the second? Seriously?

Innovations and limitations

Occasionally, vendors overstate the capabilities of their products in press releases, leaving out critical limitations. I recall one mobile forensic company’s press release from 2017, boldly stating that they had “overcome data encryption on Android devices” and had “gained direct access to complete user data even if it was previously deleted” that made their tool “the most complete and up-to-date password recovery and decryption solutions for Android devices”. However, upon closer examination, it became apparent that these claims were applicable only to select smartphone models from a single manufacturer and were subject to several limitations. While still an impressive feature, it fell short of the lofty promises made in the press release.

In general, marketing materials naturally tend to downplay or omit limitations altogether. Sometimes, a product manual may contain fine print detailing certain conditions, but uncovering the complete list of supported models, operating system and application versions, and other critical details can be a daunting task.

Back to the “innovations”, my favorite is the dark theme support. That’s obvious that no forensic expert can live without it, right?

Genuine innovations in the DFIR field are few and far between. Examples include MSAB‘s app downgrade extraction method and the checkm8 exploit, which, although not attributed to any specific forensic vendor, has had a significant impact. Some vendors may offer exciting features in their premium versions, but they rarely disclose the specifics.

License to kill

Licensing terms for forensic software are often unclear, leaving users in a state of uncertainty. When a license expires, the software may either cease functioning entirely or severely limit its capabilities, forcing users into read-only mode or preventing them from saving reports. Remembering to renew licenses on time can be challenging, and failing to do so can lead to unfavorable consequences. Moreover, it has been reported that some vendors retain the right to terminate licenses under certain circumstances, such as suspected illegal use or compliance with court orders or legislation.

The user agreement for the company’s products mentions a “Disabling code”, and claims COMPANY retains the right to remotely shut down its devices if it believes the customer is using them illegally, or following a court order or legislation.

However, sources suggest that “using the devices illegally” and “court order” are not the only factors that can lead to license termination.

When it comes to trial versions — please note that they are often very limited; here is an example:

If you love something, set it free

Many (if not all) forensic products rely heavily on open-source code developed and maintained by the community. While this is generally acceptable, forensic vendors often fail to acknowledge the community projects they utilize. The contributions made to GPLv3 projects, such as those related to checkm8, are seldom acknowledged. The lack of recognition for the community’s work is concerning. A great example of this are the many checkm8-based extraction tools developed by various vendors. As a coincidence, most forensic vendors tout the same compatibility with checkm8 extraction methods as the checkra1n jailbreak does. To see our take on this issue, read iOS Forensic Toolkit and Open Source.

When marketing is king

Everything mentioned above in no way diminishes the merits of forensic products we’re talking about. They all possess the required functionality for unlocking, extracting, and analyzing digital evidence. Their speed and usability are impressive (although, of course, there is still room for improvement).

The problem lies in the fact that marketing and sales clearly take priority over research and development. In their pursuit of customers, manufacturers have started behaving rather unethically, concealing shortcomings and limitations (which inevitably exist) while significantly exaggerating capabilities. This “competition” is absolutely detrimental to the cause.

One thing we have not yet mentioned are bugs and issues. Unfortunately, some of these bugs and issues remain unaddressed for months, if not years. Manufacturers take advantage of their monopolistic position in certain markets and the fact that users have become accustomed to their solutions, making it difficult for them to switch to alternatives.

The truth is out there

There are a couple of things I wanted to outline. It is crucial to understand that there is no single software solution that can fully meet the diverse needs of the DFIR field. Relying solely on press releases and marketing materials is ill-advised. It is essential to verify and compare claims made by vendors. If a vendor refuses to disclose crucial information prior to securing a deal, it should raise concerns about their transparency and reliability. The truth lies beyond the marketing façade, and it is imperative to dig deeper to ensure the best outcomes.

The market of digital forensic tools is a tight one, just like any other niche market. The number of vendors is limited, especially when catering such specific needs as unlocking suspects’ handheld devices or breaking encryption. However, amidst the promises of cutting-edge technology and groundbreaking solutions, there are certain limitations that forensic vendors often don’t like to disclose to their customers. These limitations can have a significant impact on the applicability, effectiveness and reliability of the tools being offered.

The ever evolving security landscape

In the realm of password recovery, benchmarking the speed of attacks holds significant importance. It is a customary practice to gauge the speed of attacks on various data formats using diverse hardware configurations. These tests yield results that are visually represented through graphs clearly demonstrating the performance of our products. However, these graphical representations merely scratch the surface of a much broader scope. Today, we delve deeper into the objectives and methodologies behind our password cracking speed tests.

The importance of benchmarks

While aesthetically pleasing graphs and benchmarks showcasing our products’ performance are readily available to our blog readers and website visitors, these nice looking graphs are not the sole objective. Internally, we do a much more thorough and comprehensive testing than could be fit ingo any reasonable graphical representation.

When benchmarking password recovery speeds, we pursue a diverse set of objectives.

Optimizing algorithms:

One of the key purposes of conducting performance tests is to gather data on the performance improvements achieved by internal optimizations. We compare the performance of the current (optimized) algorithm with its previous iteration, aiming to identify any enhancements but also inconsistencies across different hardware configurations. These benchmarks are performed using various hardware setups, focusing solely on a single algorithm. Such tests not only allow us to highlight the improved efficiency resulting from algorithm optimization but also reveal potential performance inconsistencies across different hardware configurations.

Introducing new data formats:

When introducing support for new data formats, we strive to compare the figures achieved in our tools against theoretical limits on as many different hardware configurations as possible. We share the results with our audience when announcing the support for a new data format. These tests enable us to assess the performance and effectiveness of our algorithms in handling different data formats, showcasing the extent of optimization achieved.

Supporting new GPU architectures:

With the introduction of new GPU architectures like NVIDIA’s Ada Lovelace or Intel’s Xe, it becomes crucial to adapt and test our algorithms on these hardware platforms. We conduct tests on graphics cards utilizing the new architecture, focusing on maximizing performance across multiple data formats. The measured performance is then compared against theoretical expectations, including performance on graphics cards built on already supported architectures. This approach ensures that our code performs optimally on the latest hardware. Whenever possible, we supplement the results with newly captured benchmarks on various models and architectures.

Benchmarking against competitors:

In all scenarios, we aim to compare our performance data with that of competing products. A significant deviation (over 20%) in either direction prompts the need for further investigations. Substantially lower performance may indicate inadequate optimization, while significantly higher performance demands additional scrutiny to ensure that no passwords of varying lengths are overlooked during an attack.

Testing methodology

To maintain consistency and comparability of results, we have established a rigorous testing methodology. Our testing tool is the internally used in-house developed command-line utility, epr_bench.exe. Except when introducing support for new data formats, our tests are based on the same set of files encrypted with robust passwords (more on that later).

We always test using a full brute-force attack method with a fixed password length and a specific character set limitation. The brute-force attack allows us to measure the pure attack speed on a particular  GPU or CPU model. Other attack methods, such as mask attacks, dictionary attacks, or more complex hybrid attacks, require additional computations that may limit the utilization of the graphics card.

The results of our testing are outputted as a CSV. Each entry in the file contains the test’s date and time, the model and parameters of the graphics card and CPU, and the acceleration algorithm used (e.g., CPU, NVIDIA, OpenCL). Additionally, it includes details such as the name and format of the test file, and the plugin used for testing. These entries are manually verified and stored in our internal database.

1682344293;"wz_aes256_sfx_456456456.exe";0;nvidia;0;"NVIDIA GeForce RTX 4070 (368 SP @ 2475 MHz, 4095 MB)";"12th Gen Intel(R) Core(TM) i9-12900K";24;1;1;"ZIP AES256";"ZIP Archive Files";"espr_zip.dll";"4.50.2531";399441920;59973;6660000;
1682344170;"v.1.2_sha256_aes256_pbkdf2-1024_123456789.odt";0;nvidia;0;"NVIDIA GeForce RTX 4070 (368 SP @ 2475 MHz, 4095 MB)";"12th Gen Intel(R) Core(TM) i9-12900K";24;1;1;"OpenDocument v1.2 (AES 256)";"OpenDocument";"espr_opendoc.dll";"4.50.2497";194445312;58629;3310000;

Our database allows us to extract specific datasets for analysis, enabling us to determine, for example, the relative performance of different graphics card models on the same set of test data or to compare the performance of our algorithms before and after optimization. The collected data serves as the foundation for generating informative graphs, which illustrate the performance characteristics and trends.

Special considerations

Occasionally, we emphasize specific aspects that are not part of the regular testing process. For instance, during the period of graphics card scarcity caused by cryptocurrency miners, we analyzed the results in terms of the price-performance ratio. Currently, with the decline in graphics card prices, we prioritize absolute performance and energy efficiency above everything else, the latter measured in the number of passwords per second per watt of power consumption. While we take these graphs with a grain of salt, as we rely on manufacturers’ specifications for power consumption rather than real-time measurements, they still allow us to compare different graphics cards with acceptable accuracy.

Beyond graphics cards: exploring password recovery speeds on complex hardware configurations

While graphics cards play a vital role in password cracking, CPUs are still important, especially for formats that demand a high usage of CPU resources alongside hardware acceleration. The performance and architecture of the CPU, along with proper implementation in our products, significantly impact the overall cracking speed. This is particularly evident in the challenges we faced when dealing with the hybrid architecture of Intel’s Alder Lake processors and their hybrid architecture. It is worth noting that certain algorithms, like Scrypt, cannot be implemented on a graphics card due to their inherent nature.

The technical nuances

Testing password recovery speeds is never simple. One significant aspect is the vast disparity (by 6-7 orders of magnitude) in attack speeds across different formats. This disparity poses challenges for both situations. Very slow recovery speeds require ample time to evaluate the stable recovery speed, while very fast attacks require adjusting the length of the test password to align with the expected recovery speed. Extremely high cracking speeds introduce another issue: the CPU may struggle to generate password packets at the same rate that GPU-based graphics cards can verify them. To overcome this limitation, we develop additional code that enables password packet generation directly on the graphics card for such formats.

Running the benchmark

Let’s focus on another aspect of our testing approach. We do not have the technical capability to test all supported data formats on all possible graphics cards using our products. If you are a licensed user of Elcomsoft Distributed Password Recovery and you need to determine the cracking speed for specific data but cannot find the corresponding benchmarks on our website, you have the option to conduct the test yourself. Follow these steps:

1. Launch Elcomsoft Distributed Password Recovery and add the encrypted file to the task queue.
2. Configure the attack as follows:
   • Attack type: Brute force
   • Password length restriction: Set both the minimum and maximum password length to 8 characters.
   • Character set restriction: Use lowercase Latin letters and digits only.

In the settings, select the graphics card for which you want to measure performance as the sole device (this is important because systems equipped with both a discrete graphics card and an integrated graphics core in the CPU will use both devices by default).

Next, start the attack and wait for 3 to 5 minutes. The program requires time to “ramp up.” During this period, the tool compiles and loads the code onto the GPU. The packet size, i.e., the number of passwords transmitted to the graphics card in one iteration, is dynamically calculated, and other necessary initializations are performed. After a few minutes, the performance will reach its maximum. The average speed is displayed in real time in Elcomsoft Distributed Password Recovery, but we recommend opening the agent window to view real-time performance.

Accurate performance data is extremely important. Even a modest 10% difference in cracking speed allows for better selection of optimal attacks. It enables either a larger range of password combinations to be attempted within the time constraints or faster completion of the task.

Conclusion

Testing the speed of password recovery serves multiple purposes beyond graphs and benchmarks. By conducting comprehensive performance measurements, we validate the optimizations we make, assess the compatibility with new GPU architectures, and benchmark against competitors. These tests enable us to deliver cutting-edge products with enhanced efficiency and provide our customers with reliable high-performance solutions.

Synology DSM 7.2 introduced a highly anticipated feature: volume-level encryption. This data protection mechanism works faster and has less limitations than shared folder encryption, which was the only encryption option supported in prior DSM releases. However, upon investigation, we determined that the implementation of the encryption key management mechanism for full-volume encryption fails to meet the expected standards of security for encrypted data for many users.

In this article, we will explore the current implementation of encrypted volumes in DSM 7.2 and shed light on the challenges posed by the existing key vault design. We will examine the limitations of the system, particularly in relation to the potential vulnerability of encryption keys and passwords stored on the same disk as the encrypted volume. Additionally, we will compare this design with the previously used encrypted folder approach, highlighting the advantages of the older method in terms of security.

Before: shared folder encryption

Back in 2019, we analyzed the encryption of shared folders in Synology NAS units, and discovered a potential vulnerability in the encryption key vault if the user enabled the Auto-mount option. You can read about the issue in Synology NAS Encryption: Forensic Analysis of Synology NAS Devices. As to my knowledge, there were no major changes to shared folder encryption or encrypted key vault since that publication.

Instead of discussing the protection of the shared folder encryption key vault, let us talk about the pros and contras of shared folder encryption. There are tangible benefits to this protection method, namely:

1. Since one encrypts shared folders and not volumes, the location of encrypted data does not matter much. However, SynologydoesnotsupporttheencryptionofexternalUSBdrives.
2. A unique password can be used to protect each individual shared folder. Multiple users can set their own passwords to their folders.
3. One can copy an unmounted shared folder back and forth to another device without having to decrypt the content or even knowing the encryption password. This makes encrypted shares perfect for backups, especially remote backups to untrusted destinations.
4. The internally used eCryptFS file system encrypts both the content and names of files and folders (the latter comes with a tax).

Despite these benefits, shared folder encryption has several drawbacks that restrict its usability in real-world scenarios.

1. Encrypted file names may only contain up to 143 ANSI characters or up to 47 Asian characters.
2. While file and folder names are encrypted, the overall file system structure remains accessible along with metadata (file sizes, date/time/attributes and so on). This may not be acceptable in some applications.
3. Low read/write performance, especially when it comes to multiple small files.
4. Synology DSM does not use the concept of separate media encryption keys and key encryption keys. The data is encrypted directly with a key generated straight from the user-provided password, which in turn means that one cannot change that password without decrypting and re-encrypting the entire content of the encrypted hare.
5. Finally, the encrypted key vault in DSM makes encryption useless if the user enables the Auto-mount option, in which case the encryption password is wrapped with a known, fixed, leaked password, and stored alongside with encrypted data.

While we do list the 5) as a negative, do take a note on the following: the potential vulnerability only exists if the user manually enables the optional Auto-mount feature. If they don’t, or if they decide not to store the encryption password in the vault at all, accessing the encrypted share will require the intruder to perform a complex password recovery attack with no guarantee of success. This is no longer the case for volume encryption.

DSM 7.2: full volume encryption

DSM 7.2 introduced full появилась возможность шифрования тома – volume encryption, which is implemented via LUKS in aes-xts-plain64 mode.

One can only enable encryption on newly created volumes. You won’t be able to decrypt or decrypt an existing volume. When a new encrypted volume is created, DSM will save the recovery key (which one can recall and replace with a new one in the future).

Essentially, the system stores a key to the encrypted volume on the same storage device as the encrypted data. This in turn enables DSM to automatically mount encrypted volumes on system startup with no user interaction. There is no way for the end user to change this behavior unless they employ a remote KMIP server to manage encryption keys. Currently, only another Synology NAS (one that supports full volume encryption) may be used as a KMIP server. While beta versions of DSM 7.2 allowed for third-party KMIP servers, the feature was removed in the release build. Therefore, DSM 7.2 currently provides two options for encryption key management:

1. The key is stored locally on the same device as the encrypted data. Synology does not reveal the exact location and format of that key. It appears that the encryption key vault protects the key with a user-provided password (which is the same password the user enters when creating the encrypted volume). The vault password can be reset by the user; if the encrypted volume is mounted at that time, there will be no need to enter the old vault password (the user will have to enter their DSM login password though).
2. The key is managed by a remote KMIP server on another Synology NAS. In this case, to access the data, the intruder will have to gain physical control over two separate devices, including the KMIP server. If the key is stored on the other server’s encrypted volume, the intruder will have to overcome encryption on that volume first to access the key to the target NAS. While this management scheme appears more secure than a locally stored key vault, in the end it boils down to whether or not at least one of the two devices keeps a volume encryption key locally (which would normally be the case for the KMIP server).

Volume encryption vs. shared folder encryption

The table below provides a concise overview of the features and characteristics of volume encryption and shared folder encryption as implemented in Synology DSM 7.2.

Volume encryption offers comprehensive protection for everything stored on the encrypted volume, including shared folders, virtual machines (VMs), containers, and logical unit numbers (LUNs). On the other hand, shared folder encryption primarily focuses on safeguarding the content of files and their names, while excluding certain elements like the file system structure and metadata.

In terms of flexibility, both volume encryption and shared folder encryption allow users to change the encryption key vault password. However, volume encryption offers the additional capability of changing the encryption key by regenerating the recovery key. In contrast, shared folder encryption requires full decryption of all data to change the encryption key.

There are some differences in file and folder name length limitations, with volume encryption adhering to the Linux standard of 255 ANSI characters, while shared folder encryption restricts names to 143 ANSI characters.

Performance-wise, volume encryption is advertised to be up to 48% faster than shared folder encryption, with only minor performance impacts during backups and snapshot replication (as data must be decrypted when performing backups/replication). Shared folder encryption, on the other hand, experiences a noticeable performance drop when accessing multiple small files, but this does not affect snapshot replication because replication deals with raw (encrypted) data.

Key storage methods also differ between the two encryption types. Volume encryption allows for local, albeit unprotected, key storage or remote storage using a Key Management Interoperability Protocol (KMIP) server, although the latter is currently limited to compatible Synology devices. Shared folder encryption utilizes a local key vault, which can be password-protected, with the option to store the password. Additionally, shared folder encryption supports storing keys on USB devices.

Regarding backups, encrypted volumes can only be backed up when encrypted volumes are mounted on both devices (if the destination device also uses volume encryption). In contrast, shared folder encryption supports fully transparent backups that do not require mounting or decrypting the data, making it ideal for backups to untrusted remote destinations.

Both volume encryption and shared folder encryption provide options for automatic mount on startup, with volume encryption enforcing it and shared folder encryption making it optional.

Stacking encrypted shares on top of volume encryption

DSM 7.2 supports encryption stacking: one can create plain and encrypted shared folders on encrypted volumes. Volume encryption is implemented transparently in DSM, so there are no restrictions to stacking protection methods. One can create, backup, restore, and replicate encrypted shares on encrypted volumes without any additional restrictions. This in turn means that there are three types of protection available in DSM 7.2:

1. Plain shared folders on encrypted volumes.
2. Encrypted shared folders on plain volumes.
3. Encrypted shared folders on encrypted volumes.

Stacking protection methods by creating encrypted shared folders on encrypted volumes delivers additional security due to the way the encryption keys are managed in DSM. At the same time, one will also experience all the limitations of both encryption methods. There may be a small performance hit when placing an encrypted share on an encrypted volume, too; we plan to benchmark the different combinations of encryption in the future.

Using volume encryption

To create an encrypted volume, start in the same way as you would when making a regular one. The encryption settings will show up in the volume creation wizard:

On the next step, you’ll need to specify a password to protect the key vault. Later on, you’ll be able to use that password to unlock the key vault and mount the encrypted volume.

The system creates a recovery key:

After a final warning, the encrypted volume will be created:

Note: full volume encryption in DSM 7.2 enforces volume auto-mount on startup.

If you forget the vault password, you’ll be able to reset it by signing into your NAS device and resetting the vault password while the encrypted volume is mounted (the original vault password is not required, but you will be prompted for a local DSM password).

You won’t be able to disable encryption key vault unless you store the key on a KMIP server.

You can use another Synology NAS as a KMIP server:

The key can be stored on plain or encrypted volumes:

You can use the recovery key to unlock and mount the encrypted volume if you lose access to the key vault. You can also regenerate the recovery key, which automatically invalidates the old recovery key:

One Synology NAS can be a KMIP server and client at the same time.

However, you won’t be able to use a pair of Synology NAS devices to be each other’s KMIP server and client. If device A is a KMIP server and device B is a client, device B cannot be used as a KMIP server to device A (but can be used as a KMIP server to device C).

Note: third-party KMIP servers are not supported in the release version of DSM 7.2. Beta versions of the OS did not have such restrictions, and this open-source KMIP server provided a viable alternative to a second Synology NAS.

Conclusion

In this article, we discussed the introduction of volume-level encryption introduced in Synology’s DSM 7.2. This highly anticipated feature offers enhanced data protection, boasting faster performance compared to the previously exclusive shared folder encryption mechanism and addressing many of the limitations associated with folder-based encryption.

However, upon further examination, we discovered a significant drawback in the implementation of the encryption key management mechanism. Despite the advancements in volume-level encryption, the current approach fails to provide the desired level of security for encrypted data on the majority of devices, specifically nearly all devices owned by home users who may not have the ability or skills to use a remote KMIP server.

While the new encryption method offers improved speed and flexibility, the effectiveness of any encryption system heavily relies on the robustness of its key management. Unfortunately, the current key management implementation on local devices falls short in adequately safeguarding the encryption keys, leaving encrypted data vulnerable to potential breaches.

We strongly believe it is crucial for Synology to address this security concern, as the strength of encryption lies not only in the encryption algorithm but also in the protection of the keys. Without a reliable key management system, the overall security of the encrypted data remains compromised.

Therefore, it is essential that Synology focus on refining the encryption key management mechanism to ensure the desired level of security for encrypted data. Only through comprehensive security measures one can truly leverage the potential benefits of volume-level encryption and protect sensitive information from unauthorized access.

Intel has unveiled its latest lineup of dedicated graphics cards, driven by the powerful Intel Xe architecture. The Intel Arc series showcases impressive performance, rivaling mid-range offerings from competing brands, while maintaining an exceptional price-performance ratio that outperforms NVIDIA’s counterparts. In this article, we explore the potential of Intel Arc GPUs for forensic password recovery and delve into their performance capabilities, comparing them with both Intel’s built-in graphics and mid-range NVIDIA RTX boards.

Introduction

Password recovery is a critical process in the field of digital forensics. The process of password recovery involves attempting to gain access to password-protected data such as encrypted disks, files, or systems, by trying different password combinations until the correct one is found. Due to the constantly increased encryption and security measures leading to the increase in the complexity and length of passwords, traditional CPU-based methods for password recovery become inefficient and unfeasible due to unrealistic time constraints. To address this challenge, we at ElcomSoft developed GPU acceleration techniques to significantly speed up the password recovery process.

What is GPU acceleration?

GPU acceleration is a technique for accelerating complex calculations by utilizing the large number of graphics processing units (GPUs) found in today’s common graphics cards. Traditionally, computationally intensive tasks have been carried on computer’s central processors (CPUs). However, GPUs, which were designed for rendering and processing graphical data in the context of 3D gaming, are equipped with a large number of cores capable of performing certain kinds of calculations in multiple parallel threads.

GPU acceleration involves offloading certain calculations from the CPU to the GPU, taking advantage of the GPU’s massive capabilities in parallel processing. This parallelization enables the GPU to perform multiple (in the order of hundreds and thousands) tasks concurrently, significantly accelerating the process. GPU acceleration is particularly effective for tasks that involve calculating hash values, which are used by data encryption tools in their respective password-based key derivation functions for turning text-based passwords into binary encryption keys.

Intel Xe architecture

Intel’s foray into dedicated graphics cards began with the development of the Intel Xe architecture. The new architecture had the first limited release in the company’s OEM-only DG1 boards that did not get much traction and were criticized for their limited compatibility and extremely poor drivers. The Xe architecture was publicly released as the Intel Arc series of graphics cards. Featuring contemporary technologies such as hardware-accelerated ray tracing and AI enhancements, Intel Arc graphics cards sought to deliver higher performance, power efficiency, and affordability compared to established GPU manufacturers.

The initial release of the first generation of Xe boards received a varied response from the community. While Intel made efforts to address the discovered issues through driver updates, one prominent challenge remained unresolved: the high idle power consumption of their cards. This issue is primarily considered a hardware-related issue and is expected to be rectified in the next generation of Intel’s graphics cards. It’s worth noting, however, that this particular concern is largely irrelevant in the context of computationally intensive password recovery tasks, where the focus is on maximizing performance rather than idle power consumption.

Intel Arc performance benchmarks

Conclusion

GPU acceleration, particularly with Intel Arc graphics cards, offers a game-changing approach to password recovery, enabling faster and more efficient attacks. By utilizing the massively parallel processing power of GPUs, experts can significantly reduce the time required to recover passwords, while IT security specialists can audit and strengthen the security of their wireless networks by eliminating weak passwords that can be recovered quickly by an attacker. Intel’s new discrete GPUs offer unbeatable performance for the price, delivering higher password recovery rates per dollar spent on GPU acceleration hardware. After testing an Intel Arc A380 board, we’ve been impressed by the performance it delivers, which must be viewed in the context of the card’s rock bottom price compared to competition.