Category: Uncategorized

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 key storage with obligatory auto-mount 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.

Every three years, NVIDIA releases a new architecture used in their GeForce series graphics cards. Powered by Ada Lovelace, the new generation of GPUs delivers 80% better performance in password recovery compared to Ampere. While the new generation of NVIDIA graphics is faster and more efficient than Ampere, it also received a price hike. Is the update worth it for the forensic experts? Let’s try to find out.

The 40 series of GeForce RTX graphics processors are based on the updated RTX architecture called Ada Lovelace, which gradually replaces three-year-old Ampere chips. In brute-force specific workloads the new generation delivers about an 80 per cent average performance uptick compared to Ampere. In our tests, the NVIDIA GeForce RTX 4070 Ti delivered a boost of approximately 80 per cent over the previous-generation NVIDIA GeForce RTX 3070 Ti board at around the same TDP, while the more affordable NVIDIA GeForce RTX 4070 beat 3070 Ti performance by some 40 per cent while dissipating 30 per cent less heat. Now let us investigate this in detail using Elcomsoft Distributed Password Recovery that received Ada Lovelace support in the recent update.

First, let us check out the Microsoft Office format, comparing the performance of several generations of NVIDIA boards. Here we try breaking a password to a Word .docx document.

 

The NVIDIA GeForce RTX 4070 Ti demonstrated the speed of some 30400 passwords per second, which beats the previous champion, NVIDIA GeForce RTX 3090 (25700 passwords per second), by a significant margin. The NVIDIA RTX 4070 (non-Ti) delivers the performance of 22900 passwords per second, which is about par with the GeForce RTX 3080 board, which in previous tests demonstrated the speed of 22600 passwords per second. Both Ada Lovelace cards beat the Ampere-based NVIDIA GeForce RTX 3070 Ti, which only demonstrated the speed of 16400 passwords per second.

It is interesting to note how much more efficient the new architecture is. Let us check the performance per watt of Ada Lovelace boards vs similar graphics cards based on the older Ampere architecture.

As one can see, the new architecture is twice as efficient as the one it replaces, meaning that you’ll be able to try twice as many passwords per watt with an Ada Lovelace board compared to a similar Ampere-based graphics card. A higher TDP means you will need a more powerful power supply as well as more efficient cooling to dissipate all that heat. A lower TDP, on the other hand, means you’ll be able to build a significantly more powerful workstation using the same case, power supply, and cooling.

Other formats demonstrate similar results. A 88% performance gain on SHA256 hashes, 93% faster WPA attacks, 85% performance uptick when recovering encrypted RAR archives and 70% faster ZIP password recovery average to some 82% overall gain for the 4070 Ti vs. 3070 Ti.

 

Performance per dollar

So we figured that the NVIDIA GeForce RTX 4070 Ti beats the older RTX 3090 while consuming less power and delivering greater performance-per-watt compared to yesterday’s champion. On the other end of the spectrum, the 4070 (non-Ti) delivers about the same performance as the RTX 3080. Should you fetch the wallet and upgrade your cards? This year, the answer is simple because we tested two boards with matching MSRP. The NVIDIA GeForce RTX 4070 has the same MSRP as the RTX 3070 Ti, which allows for a straight performance-per-dollar comparison. The new RTX 4070 gets you about 40% higher performance and about 30% lower power consumption at the same time. Considering the two cards are similarly priced, the choice is really a no-brainer.

Our recommendation

In the current upgrade cycle, NVIDIA concentrated as much on sheer performance as on power efficiency. While graphics cards based on the Ada Lovelace architecture cost more than their respective Ampere counterparts, the extra money get you either significantly better performance or much lower power consumption, or a little bit of both. Ada Lovelace graphics cards offer higher performance per dollar along with better efficiency when crunching passwords compared to the Ampere generation.

As a provider of mobile forensic tools, we at Elcomsoft strongly believe in giving back to the community. Our iOS Forensic Toolkit (EIFT) is a highly complex and powerful mobile acquisition tool, consisting of almost eighty sub-projects, many of which are open source. While we have benefited from the contributions of the community, we also believe that it’s time to contribute back to the open source community by publishing our changes to those projects as required by their permissive license.

In addition to fulfilling legal requirements, there are several benefits to open sourcing some of our projects. Collaboration with the open source community can result in faster updates, improved features, and greater security. By sharing our efforts, we can help each other to build better tools, rather than reinventing the wheel. To this end, we are currently preparing to open source several of our projects. With a long list of projects that are going to be public soon, we are currently in the process of doing some technical preparations for publication. Once this is complete, we will start pushing code to our github. We are excited about the opportunities that this initiative will bring and look forward to working together with the open source community.

The benefits of open source

There are more reasons to opensource those components other than it being required by the license. Have you heard of palera1n, an opensource checkm8-based jailbreak? The work on kernel patches done by those people partially overlaps with the kernel patches we need to do for iOS Forensic Toolkit ramdisk. By joining forces with the opensource community we could help each other to build updates faster by sharing the efforts instead of doing the work twice. Another example are publicly available tools for iOS downgrading, which we can use internally to extensively test our software on every supported iOS version, in order to provide the best quality software to our customers.

Conclusion

We have been fortunate to benefit from the contributions of the open source community, and we believe that it is time to give back. As required by the permissive licenses, we are in the process of preparing to publish our changes to these open source projects. In addition to fulfilling our legal obligations, we are excited about the opportunities that this initiative will bring.

By collaborating with the open source community, we can work together to build better tools, faster updates, improved features, and greater security. We can learn from each other, avoid duplicating efforts, and focus on what we do best. We are currently preparing our projects for publication and are eager to push our changes to the community. We understand that this is a large undertaking, but we are committed to taking it one step at a time. We look forward to the benefits that this initiative will bring and to working with the open source community to create even better tools.

Last month, we introduced a new low-level mechanism, which enabled access to parts of the file system from many Apple devices. The partial extraction process relies on a weak exploit that did not allow full sandbox escape. Today, the limitations are gone, and we are proud to offer the full file system extraction and keychain decryption for the entire iOS 15 range up to and including iOS/iPadOS 15.7.2.

TL&DR

The previously announced partial file system extraction mechanism has been refined, now delivering the full file system and all keychain records for many devices running all versions of iOS 15 up to and including iOS/iPadOS 15.7.2. iPhone Xs/Xr and newer devices are supported, while older devices such as the iPhone 8/iPhone X still rely on the checkm8 extraction process (though agent extraction is also available for some versions). Devices running iOS 16.0 through 16.1.2 are still using the partial extraction process.

The updated compatibility matrix:

Before: partial file system extraction

iOS Forensic Toolkit includes 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 versions of iOS newer than iOS 15.6 no kernel exploits are currently available. Instead, we used a weak exploit that obtains higher-level privileges through a vulnerability in the iOS virtual memory management. Since this is not a proper kernel-level exploit, we’ve been unable to fully escape the sandbox, as some protective mechanisms that affect access to certain folders are implemented directly in the kernel. Therefore, we’ve only been able to access parts of the file system, mostly containing data of third-party apps.

This approach left many kinds of data out. The partial extraction process did not return data from built-in system apps and many system databases; it did not work for the keychain either. We recommended using advanced logical acquisition to access some of the missing data, and yet some bits and pieces remained unavailable even when combining the results of the partial low-level extraction process and advanced logical acquisition. Most notably this included some system artifacts and essential keys stored in the keychain such as the keys used to encrypt chat histories in protected messengers such as Signal and Wickr.

After: full file system extraction and keychain decryption

The limitations are over, at least for iOS 15. The newest release of iOS Forensic Toolkit now includes full support for all versions of iOS/iPadOS 15, which includes iOS 15.6, 15.6.1, 15.7, 15.7.1, and 15.7.2. With additional research (and some efforts) we’ve been able to fully escape the sandbox and gain access to previously inaccessible types of data, which includes the full file system and all keychain records regardless of their protection class. The latter in particular enables access to chat histories in protected messengers such as Signal and Wickr that use extra encryption to protect their working databases. The full low-level extraction closes all remaining gaps in data that were unavoidable when combining partial file system extraction with password-protected backups.

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)
• All corresponding iPad models including iPad Air 5 and iPad Pro 5 (Apple M1)

For older devices including the iPhone X, iPhone 8 and iPhone 7 ranges we recommend using checkm8 extraction, which delivers equally strong results.

In recent years, Apple had switched from 4-digit PINs to 6 digits, while implementing blacklists of insecure PIN codes. How do these measures affect security, how much more security do six-digit PINs deliver compared to four-digit PINs, and do blacklists actually work? Let’s try to find out.

The role of PIN codes/passcodes in mobile forensics

Simply put, a PIN code or passcode is the key to the content of an iOS device. While a passcode can be composed of an arbitrary number of alphanumeric characters, PINs are digit-only, fixed length passcodes. In this article we’ll discuss the security of PIN codes.

While some activities can be performed with a biometrically unlocked device (Face ID or Touch ID), a lot of activities require the use of a PIN code. Without a PIN code, most acquisition methods (except manual analysis) may not be available. A PIN code is needed to pair the device to the computer, which is a required pre-requisite to both the advanced logical and low-level extraction methods. The PIN is required even for extracting devices that are vulnerable to checkm8 as without the PIN most user data on the device will remain encrypted. The following table summarizes the differences between unlocking the device with biometrics (Touch ID/Face ID) and PIN code.

	Touch ID/Face ID	PIN
Unlock BFU device	No	Yes
Unlock AFU device	Sometimes	Yes
AFU DEVICES ONLY
Pair with new computer	No	Yes
Connect to a trusted computer	Yes	Yes
Make a local backup	Trusted/Lockdown only	Yes
Access media files	Yes (on device)	Yes
View saved passwords	Yes (on device)	Yes (on device)
Reset iTunes backup password	No	Yes (if no Screen Time password)
Disable iCloud lock	No	Yes
Use Apple Pay	Yes	Yes
File system image (low-level extraction)	No	Yes
Keychain (low-level extraction)	No	Yes
checkm8 extraction (on compatible devices)	No	Yes (except A11 devices with iOS 16+)
iCloud Keychain, Health, Messages	No	Yes
Bypass USB restricted mode	Partial *	Yes

* While you can unlock the device with biometrics and connect a USB accessory, pairing the device to a computer would still require a PIN.

Risk assessment

In the context of forensic investigations, the ability to recover PIN codes can be critical to gaining access to evidence stored on a device. However, with the Erase Data option turned on, there is a risk that all content and settings on the device will be permanently deleted after 10 (or less) consecutive incorrect attempts to enter the passcode. According to Apple, “If the Erase Data option is turned on (in Settings > Touch ID & Passcode), after 10 consecutive incorrect attempts to enter the passcode, all content and settings are removed from storage. Consecutive attempts of the same incorrect passcode don’t count toward the limit. This setting is also available as an administrative policy through a mobile device management (MDM) solution that supports this feature and through Microsoft Exchange ActiveSync, and can be set to a lower threshold.”

The risk of recovering PIN codes with the Erase Data option turned on is high, and experts must carefully balance the need for access to evidence with the potential risk of permanently deleting important information. Therefore, if you are considering attempting to recover a PIN code, be careful not to exceed the allowable number of incorrect attempts. This means you must have a solid understanding of the potential consequences of exceeding the limit, and must exercise reasonable caution when attempting to recover the passcode.

Note that the Erase Data option can be set to a lower threshold through MDM or Microsoft Exchange ActiveSync, which could make it even more challenging to attack a PIN code without losing access to the data.

PIN throttling

Apple has a comprehensive article on Passcodes and passwords in which the company explains how escalating time delays discourage brute-force attacks. Quote:

Weak PIN codes

Some PIN codes are weaker than others. According to PIN number analysis (datagenetics.com), these twenty PIN codes represent 26.83% of real-world PIN codes in use:

	PIN	Freq
#1	1234	10.713%
#2	1111	6.016%
#3	0000	1.881%
#4	1212	1.197%
#5	7777	0.745%
#6	1004	0.616%
#7	2000	0.613%
#8	4444	0.526%
#9	2222	0.516%
#10	6969	0.512%
#11	9999	0.451%
#12	3333	0.419%
#13	5555	0.395%
#14	6666	0.391%
#15	1122	0.366%
#16	1313	0.304%
#17	8888	0.303%
#18	4321	0.293%
#19	2001	0.290%
#20	1010	0.285%

Assuming that you know nothing about the suspect, the best attack strategy would be to try these most popular PINs first. In fact, you may try an even larger list of common PIN codes such as those published on github. Besides Apple’s 4-digit and 6-digit blocklists, the authors also created data-driven blocklists that are significantly (10x) smaller (27/29 PINs) and (10x) larger (2740/291,000 PINs) than the iOS 4/6-digit blocklists. Some of those lists are made available by the authors; please visit This PIN Can Be Easily Guessed for more information and download links.

#	Name	Source	Length	Blocklisted
1	iOS-4-digit	Apple iOS	4-digit	274
2	iOS-6-digit	Apple iOS	6-digit	2,910
3	DD-4-digit-27	Top Amitay	4-digit	27
4	DD-4-digit-2740	Top Amitay	4-digit	2,740
5	DD-6-digit-29	Top RockYou	6-digit	29
6	DD-6-digit-291000	Top RockYou	6-digit	291,000

Social engineering

The most common PIN codes work great if you know nothing about the suspect. However, if you do have some information about them, the best attack strategy would be to try a small list of the most popular PINs first followed by the list of PINs that might be significant for the suspect. Examples of such PINs include:

• Memorable years (four digits): dates of births of the suspect and their family members; years of other significant dates. Multiple studies suggest that PINs starting with 1900 are more likelyy to occur, followed by PINs starting with 2000.
• Memorable dates in MMYY, DDMM, MMYYYY and other representations (four or six digits): this also includes significant dates in various common representations.
• Parts of telephone numbers (first four digits, last four digits) of family members and frequent contacts.

Creative or too creative?

It is known that some patterns are more common than others for various reasons. For example, 696969 is one of the most common six-digit PINs, or 159753 (a “X” mark over the numeric keypad). There can be many different reasons making certain PINs more likely than the rest, and there are various studies such as PIN number analysis (datagenetics.com), [2003.04868] This PIN Can Be Easily Guessed: Analyzing the Security of Smartphone Unlock PINs (arxiv.org) or (PDF) On the Security of Smartphone Unlock PINs (researchgate.net) analyzing the patterns in many details. These studies are interesting reading, but in the end common PIN codes have all been published in the lists of weak PIN codes. There is no need to be too creative when attacking an iPhone PIN code. We recommend the following courses of action.

Cold attack (nothing is known about the owner)

1. List of common PIN codes

Smart attack/social engineering (some information is known about the owner and/or their surrounding)

1. Short list of common PIN codes
2. PIN codes composed of memorable years, memorable dates, and parts of telephone numbers
3. Long list of common PIN codes

Blacklists

A blacklist is a list of unacceptable PINs. Blacklists can be blocking (an unacceptable PIN will be rejected) and non-blocking (the user will be warned, but an unacceptable PIN can still be used). According to a study conducted by Philipp Markert, Daniel V. Bailey, Maximilian Golla, Markus Dürmuth, and Adam J. Aviv back in 2020, iOS maintains non-blocking blacklists for for 4-digits (274 PINs) as well as 6-digits (2910 PINs). The authors concluded that these “relatively small blocklists in use today by iOS offer little or no benefit against a throttled guessing attack“.

On the other hand, these built-in blocklists represent the most commonly used PIN codes, and they are non-blocking, which means that trying PINs from these blocklists may increase probability of a successful unlock. Note that iOS blocklists are already included to many lists of the most common PINs.

Additional information

Interested in smartphone PIN security? We recommend the following articles:

Analysis of Android lock patterns:

Just for fun:

The recent update to iOS Forensic Toolkit brought two automations based on the Raspberry Pi Pico board. One of the new automations makes it possible to make long, scrollable screen shots in a semi-automatic fashion. In this article we will show how to build, program, and use a Raspberry Pi Pico board to automate scrolling screenshots.

Scrollable screenshots

Capturing screenshots can be a crucial step in mobile device investigations. By taking a series of screenshots of what is displayed on a connected iOS device, investigators can gather digital evidence that may not be accessible through other means, such as advanced logical acquisition, where the data such as protected chat histories may not be available. In a way, the new feature can be viewed as new extraction tool in addition to cloud, advanced logical, and low-level extraction methods.

Using a Raspberry Pi board, one can also make long, scrollable screen shots in a semi-automatic fashion. Available for all devices and most versions of iOS, the experimental new feature also makes use of a Raspberry Pi Pico device with custom, ElcomSoft-developed software that is now included with iOS Forensic Toolkit. The feature is available for most iOS/iPadOS devices staring with iOS 14.

Capturing scrollable screenshots with a Raspberry Pi Pico

Compared to the auto-DFU process, you will only need a few things other than the iPhone or iPad itself.

• A Raspberry Pi Pico board
• Lightning to USB (the official Apple Camera Adapter is recommended)
• USB-A to micro-USB cable (to upload firmware, and to connect the iPhone to the Pico via the Lightning to USB adapter)
• USB mouse with a scroller (optional)

To capture scrolling screenshots, do the following.

• Flash your Raspberry Pi Pico
  • Press and hold BOOTSEL button on a Pico
  • Connect the USB cable to your computer
  • Copy the .uf2 file onto the newly detected drive called RPI-RP2
  • The drive will re-attach with the new name CIRCUITPY
• Install the code
  • Delete all files on the CIRCUITPY drive
  • Copy the lib directory to the CIRCUITPY drive
  • Copy the code.py file to the CIRCUITPY drive

The firmware is located by the following path:

pico/picoScrollNScreenshot/adafruit-(...).uf2

The files to copy (code.py and the lib folder) are also there.

Once the files are on the Pico, do the following.

• Disconnect the Pico from the computer
• Connect the USB adapter to the iPhone
• Connect the Pico board (micro USB) to the iPhone (via the USB adapter)
• In about 15 seconds the phone will start capturing scrolling screen shots. It will keep doing so until you disconnect the iPhone from the Pico.

Extra power is not required as the Pico takes 5V from the USB plug. However, with an Apple Camera Adapter, you can use its other (Lightning) port to power up the iPhone itself to prevent it from discharging during the process.

After that, copy the screen shots to your computer (by extracting media files, doing full logical acquisition, or with AirDrop). You may want to stitch the screenshots first; there are many iOS apps for that such as Tailor.

Finally, you can OCR the screen shots, index and analyze the text.

Tips and tricks

The process does not always work out of the box. The screenshots are always captured, but the scrolling sometimes fails unless you connect a USB mouse to the iPhone first and use the wheel to scroll up and down several times.

Also, we are not absolutely sure that this method works with non-native Lightning to USB adapters. It definitely works with an official Apple’s one though.

You may also need to edit the code.py file. The critical options are:

SCROLL_WITH_MOUSE = 1
SCROLL_MOUSE_DISTANCE = 250
DELAY_AFTER_SCROLL = 1

SCROLL_WITH_MOUSE means whether to emulate a keyboard (0) or mouse (1). The first option is more robust but some apps don’t support it (e.g. Telegram).

SCROLL_MOUSE_DISTANCE is only used when mouse emulation is enabled, and specifies the scrolling range. In our tests, the default value of 250 works great if you were to stitch the screen shots, but depending on a particular device you may need to set a different value.

DELAY_AFTER_SCROLL specifies the delay between scrolling and capturing screen shots; the default value is one second, but you can set a greater delay to let delayed images and URL information load after scrolling.

Note that the default behavior of the scrolling is in the down direction. That means that you need to start the process at a top of a page or conversation you need to save.

Finally, please note that the script starts working right when any device is connected to the Pico board. That includes a Mac computer; that’s why we implemented a 15-second delay after connection (so that you have enough time to edit or delete code.py).

Last but not least, the script cannot (and will not) detect when screen shooting is done. You have to stop it manually by disconnecting the cable.

Conclusion

This feature is experimental and not yet perfect. The biggest problem is that all the screenshots are captured and stored right on the device rather than the computer. Yet this may still be the only method to extract certain types of data from some iOS applications in case the device is not vulnerable to a bootloader exploit and not supported by the acquisition agent.

The latest update to iOS Forensic Toolkit brings two new features, both requiring the use of a Raspberry Pi Pico board. The first feature automates the switching of iPhone 8, iPhone 8 Plus, and iPhone X devices into DFU, while the second feature adds the ability to make long, scrollable screen shots in a semi-automatic fashion. In this article we will show how to build, program, and use a Raspberry Pi Pico board to automate DFU mode.

Auto-DFU

Placing devices into DFU is a pre-requisite to forensically sound low-level checkm8 extraction. Placing a device to DFU mode involves a sequence of button presses with precise timings. The procedure is even more complex if one or more buttons on the device are defective. Automatic DFU mode is indispensable when one has a device with broken buttons, which would otherwise require disassembly to be placed into DFU.

We’ve been able to make the process much easier and straightforward for the iPhone 8, iPhone 8 Plus, and iPhone X devices by developing a special firmware for the Raspberry Pi Pico board. We have already discussed the benefits of a Raspberry Pi Pico board in checkm8: Unlocking and Imaging the iPhone 4s, where we have published instructions on building one. The auto-DFU feature requires a slightly different build.

Notes on compatibility:

• The process is not compatible with previous-generation iPhones (iPhone 7 and older)
• This process may or may not work with newer iPhones (iPhone Xs/Xr and newer)

You will require:

• A Raspberry Pi Pico board (with pins)
• USB-A to micro-USB cable (to flash Pico board using your Mac)
• A special Lightning cable

Preparing the special Lightning cable

The cable is quite simple – a Lightning connector on one end, and 4 Dupont connectors on the other side (to connect to the Pico board). We only need the following lines from Lightning:

• GND (Black)
• 5V (Red)
• ID0 (Yellow)
• ID1 (Blue)

Note: The colors might be different for your cable. We recommend checking the pinout using a voltmeter.

The important point: the cable should not have a chip inside. All standard Lightning cables and adapters do have one, with a single exception of a Lightning extender (Lightning male to Lightning female) like the following one:

You will need one of those. The cheapest one is OK, the average price of these cables is usually around $1.5 to $2. In fact, you may want to buy a few as the cable will be used as a “donor”: you’ll cut in half and solder connectors to the above mentioned lines/wires.

Alternatively, you can use any Dupont Cable Female (usually sold as “Hookup Wire for Arduino cable” or something like that) and solder just the wires. If you don’t care about the looks, you can just solder the wires directly to Arduino connector.

Preparing and connecting the Pico board

All you need to do with the Pico board is install proper firmware. For that, connect the Pico board to your Mac using a USB to micro-USB cable, while pressing the button on the Pico board; it will be recognized as an external storage. Then, drop the following file from the EIFT installation folder:

/pico/picoDFU.uf2

The Pico will flash and disconnect, and you’re done with that. Reconnect it to your Mac (the board will get power), and connect the cable as follows to proper Pico pins:

5V (Red)      VBUS
GND (Black)   GND
ID0 (Yellow)  GP2
ID1 (Blue)    GP3

Note: you may also connect the last two pins in reverse order: ID0 to GP3, and ID1 to GP2.

Entering DFU

Once you’ve built the Pico board and wired the special Lightning cable to the Pico’s pins, the rest is easy. To place the device into DFU, follow these steps.

• Turn off the device is it is powered on
• Place the device into Recovery mode: press and hold the Vol- button, then connect it with a USB cable to the computer and keep holding the button until the device enters recovery
• Run ./EIFT_cmd tools autobootFalse to disable auto-boot (to ensure the device never accidentally boots into iOS)
• Bring the device to DFU mode by connecting the Pico board (powered via micro-USB) via the Lightning cable wired to Pico’s IO pins as described above

That’s it, now you can connect the iPhone to a Mac and use the EIFT to extract the iPhone with checkm8.

Copyright notice

The code for picoDFU is mostly taken from the Tamarin firmware which is available under GPLv3, so we will make it available under the same license shortly.

The following method applies only to devices that meet the following conditions:

• iOS devices using the HFS file system (APFS not supported)
• iOS devices without SEP

Furthermore, our software currently does not work on iPhone 2G, iPhone 3G,iPod Touch 1, iPod Touch 2. This can change in future.

The following devices are fully supported:

• iPhone 3Gs – iPhone 5c
• iPod Touch 3 – iPod Touch 5
• iPad 1 – iPad 4, iPad Mini 1
• Apple TV 2 – Apple TV 3

The three stages of Perfect HFS Acquisition

The Perfect HFS Acquisition procedure consists of three stages.

1. Create a perfect dump
2. Acquire a complete set of decryption keys
3. Decrypt the dump

Creating a perfect dump

In this section, you will be creating a perfect dump of the data partition, extracting BFU keys, and making an optional dump of the system partition.

First boot into EIFT:

./EIFT_cmd boot -w

Dump the data partition

./EIFT_cmd ramdisk diskdump -o data.dmg

Note: If the device was shut down uncleanly or the file system is corrupt, you may get an error like this:

[Error] [!] Data partition is in an unclean state, please run fsck first to fix potential inconsistencies!
    Alternatively pass --unclean, to ignore this and proceed with dumping anyways!

In this case add the --unclean flag to ignore the error and dump anyways.

ATTENTION: If the file system is indeed corrupt, you may need to deal with it at a later stage. It may be require fix corruption in the dump or to inspect the image manually.

Note: In that case it is recommended to create a copy of the dump and perform modifications on the copy rather than on the original dump.

During this procedure the device will not be modified at any time and stays 100% sound and repeatable.

In case of an unclean file system, perform the dump with the following command:

./EIFT_cmd ramdisk diskdump --unclean -o data.dmg

Dump the system partition (optional)

Optionally, it is possible to also dump the system partition. On unmodified devices there will be nothing interesting on the system partition, however a jailbreak or malware could modify the system partition. On older devices (especially those which used to be jailbroken a lot) the system partition should be dumped for good measure.

Dump the system partition with this command:

./EIFT_cmd ramdisk diskdump --system -o system.dmg

Note: If the device was shutdown uncleanly or the file system is corrupt, you may get an error. In that case pass the --unclean parameter to dump the partition anyways.

Dump BFU keys

To dump BFU keys run the following command:

./EIFT_cmd ramdisk dumpkeys -n -o keys_bfu.plist

This dump will contain an incomplete set of keys. A complete set of keys will be acquired at a later stage.

Congratulations, you now have a perfect dump of the device. The system partition is not encrypted and can already be analyzed. To decrypt the data partition, a complete set of keys needs to be acquired as described in the next section.

Acquiring a complete set of decryption keys

You need to acquire a complete set of decryption keys in order to access userdata. Without those keys only limited (BFU) data will be available.

The following passage will describe how to acquire a complete set of keys by using the target device as an oracle.

IMPORTANT: You have to perform the following procedure on the exact same device as you acquired the dump from. You cannot use a different device.

Note: It does not matter what state the device is in. The device can still be used even if it has been tampered with or the data has been erased from device in the meanwhile. Modifications to the device at this point do not impact the soundness of the dump created earlier.

In the following we assume the device is already booted into EIFT ramdisk mode.

Extract systembag.kb

In order to extract the system keybag, you need to be in possession of a data dump (data.dmg) and the corresponding bfu keys (keys_bfu.plist).
Note: A complete set of keys can also be used at this stage.

Run the following command to extract the system keybag:

./EIFT_cmd hfstool -i data.dmg -p /keybags/systembag.kb -e -o systembag.kb -k keys_bfu.plist --no-passcode

The command should create a new file called systembag.kb.
At this point you should verify whether the file got decrypted correctly! The file is expected to start with the bytes bplist. This can be verified using the following command on a UNIX system:

head -c 6 systembag.kb | hexdump -C

This should output:

00000000  62 70 6c 69 73 74                                 |bplist|
00000006

Alternatively, you can try opening the file in any plist viewer. If the file can be opened, then the decryption was successful!

Cracking the passcode

If the passcode is not known, it can be cracked at this point. If you already know the passcode, you can skip this step.

For cracking the passcode you will need the system keybag (systembag.kb) and the BFU keys (keys_bfu.plist). This will allow cracking the passcode of that specific system keybag from the corresponding device.

To run passcode crack with the default config, run the following command:

./EIFT_cmd ramdisk passcode -b systembag.kb -k keys_bfu.plist

Getting a complete set of keys

To get a complete set of keys, you are required to have the system keybag (systembag.kb) and the BFU keys (keys_bfu.plist) as well as to know the passcode of the keybag. If the passcode is not known, you can crack it as described in the previous step.

Run the following command to get a full set of keys:

./EIFT_cmd ramdisk dumpkeys -k keys_bfu.plist -b systembag.kb -o keys.plist -p 

Replace with the device passcode. For example if the passcode if 0000, the command looks like this:

./EIFT_cmd ramdisk dumpkeys -k keys_bfu.plist -b systembag.kb -o keys.plist -p 0000

If the device does not have a passcode set, you can omit the -p parameter.

This should create a new file called keys.plist, which is the complete set of keys required to decrypt all files.

Decrypting the dump

For decrypting the data dump (data.dmg), you need to have a complete set of decryption keys (keys.plist). The previous section describes how to get them using the same device the dump was performed on.

Decrypt the data

To decrypt the dump, run the following command:

./EIFT_cmd tools decrypthfs -i data.dmg -o data_dec.dmg -k keys.plist -j 16

Note: The -j parameter specifies the number of threads to use for decryption. The number 16 is a good value for a modern machine. You can decrease the number if you have an old machine with very little RAM or increase it if you have a lot of computing power.

Extract the keychain

To extract and decrypt the keychain from the dump, run the following command:

./EIFT_cmd tools keychain -i data.dmg -k keys.plist -o keychain.xml

Note: It doesn’t matter if the encrypted or decrypted image is used for this command. If the encrypted image is used (as shown) the necessary files are decrypted on the fly.

This should create a new file called keychain.xml