Tag: Digital Forensics

In the field of digital forensics, properly handling the task of disk imaging is crucial for preserving data integrity. Using write blockers ensures that no data is altered during the imaging process, a key requirement for maintaining the chain of custody. While there are many factors influencing the efficiency and speed of this process, this article offers advanced tips and considerations that can help achieve optimal performance.

A Brief Overview of Write Blockers

To recap, write blockers are software or hardware tools designed to prevent accidental modifications to the original evidence stored on disks being imaged. In this article, we will focus solely on SATA-based hardware write blockers. This type of write blockers act as intermediaries between the forensic expert’s computer and the storage device being imaged. We’ll focus on the latest generation of write blockers features a modern 1oGbps chip that supports USB 3.2 Gen2 connectivity, while maintaining backward compatibility with older USB versions down to USB 2.0. We will test disk imaging performance for SATA storage devices in 2.5″/3.5″ and m.2 form factors.

Does Imaging Speed Matter?

The speed of disk imaging is important, yet it is not a critical or factor. While imaging speeds for magnetic hard drives don’t vary significantly across different write blockers, the performance difference is much more pronounced with faster solid-state drives (SSDs). Using a modern write blocker equipped with a last-generation chipset can substantially reduce the time required to extract data.

How Fast is Fast?

A high imaging speed is one that approaches the maximum read speed of the specific storage device, considering overhead and port limitations. For SSDs operating over the SATA protocol, a good speed is close to the interface speed minus overhead costs. For SATA3 SSDs connected to a USB3.2 Gen2 port, a good imaging speed would be around 450 MB/s, while an excellent speed is approximately 500 MB/s. Magnetic hard drive speeds vary widely. Due to the hardware design, maximum read speeds are achieved on the outer tracks in the beginning of the imaging process, while dropping significantly towards the end of the disk. Note that these maximum speeds are unattainable via legacy USB coonnections such as USB3.0, USB3.1 Gen1, or USB3.2 Gen1 due to overhead crippling data transfer rates.

 

Performance Comparison of Imaging Tools with Write Blockers

In our testing process, we compared the performance of several imaging programs using the same disk and a 10 Gbps-capable hardware write blocker. Notably, enabling data compression may significantly affect the imaging speed, which will greatly depend on the compression type and the disk’s content.

Test Setup:

• Workstation: ASUS Vivobook S16 S5606MA, Intel Core Ultra 9 185H, 32GB RAM, Samsung 990 Pro 2TB SSD, USB/Thunderbolt 4 ports.
• Test Disk: SSD AMD Radeon R5 R5SL128G (128GB total capacity, 10GB free).

We tested the imaging performance using OSForensics, FTK Imager, and X-Ways Imager, selecting various compression levels. The results are summarized in the table below.

Observations

1. OSForensics:
   • Displays current speed during imaging, but the total time needs separate measurement.
   • Best performance with RAW format (480 MB/s).
   • Performance drops significantly with compression (87 MB/s and 79 MB/s for medium and maximum compression, respectively).
2. FTK Imager:
   • Does not display current speed but records total imaging time.
   • Serious performance drop with compression enabled.
   • In RAW format, it performs slower than OSForensics (360 MB/s).
   • Slight speed drop when imaging to E01 with no compression (267 MB/s compared to OSForensics’ 360 MB/s).
3. X-Ways Imager:
   • Does not display current speed but records total time.
   • Less compression-based performance drops compared to other tools.
   • Does not reach peak speeds of OSForensics when imaging into a RAW file, but demonstrates solid results with compression.

When using compresion, X-Ways Imager generally outperformed other tools. However, when imaging into an uncompressed RAW, OSForensics demonstrated the best performance, reaching 480 MB/s. FTK Imager lagged behind slightly, particularly in uncompressed E01.

Summary of Performance

• RAW Format
  • OSForensics: 480 MB/s
  • FTK Imager: 360 MB/s
  • X-Ways Imager: Consistently solid, though not as fast as OSForensics
• E01 Format (no compression)
  • OSForensics: 360 MB/s
  • FTK Imager: 267 MB/s
• Compressed Formats
  • OSForensics: Significant slowdown (87 MB/s and 79 MB/s)
  • FTK Imager: Solid but slower than RAW
  • X-Ways Imager: Best with medium compression

Our tests demonstrated that the choice of imaging tool and compression settings can greatly affect the imaging speed. If you aim for the fastest performance, particularly with uncompressed RAW data, OSForensics is the best choice. However, for better performance with compressed formats, X-Ways Imager is ahead. FTK Imager, while competent, tends to lag behind slightly in speed compared to the other tools.

Maximizing Disk Imaging Performance

We ran multiple tests in both desktop and portable environments, across different generations of USB ports, and with various cables. Here are the key findings and tips for achieving maximum performance.

Key Tips for Maximum Performance

1. Use a Powered Laptop
   • If you are using a laptop, ensure that it is plugged into a power outlet. Many laptops reduce USB power delivery and bus speeds when running on battery. Always perform disk imaging with the laptop connected to mains power to avoid this power-saving mode.
2. Connect to the Fastest Available USB Port
   • Use the fastest available USB port, ideally USB 3.2 Gen 2 (10 Gbps) or faster. This ensures the highest data transfer speeds, saturating the SATA protocol’s 6 Gbps limit. Avoid using older USB 3.0 (5 Gbps) ports if possible.
3. Use High-Quality Cables
   • Not every USB 3 cable supports speeds over 5 Gbps. Use cables certified for USB 3.1 Gen 2, USB 3.2 Gen 2, or higher, preferably with marked speed. Be cautious with fast-charge USB-C cables, many of which only supporting USB 2.0 speeds. Opt for certified USB/Thunderbolt 4 cables marked with their maximum speed, and pick shorter cables for better performance.
4. Use a NVMe SSD as a Target
   • Use an NVMe SSD for the target drive, either seated in the M.2 slot or connected via a 10 Gbps or faster USB port. NVMe SSDs offer significantly higher write speeds compared to traditional hard drives and SATA SSDs, preventing the target drive from becoming a bottleneck.
5. Ensure Ample Free Space on the Target Drive
   • Before imaging, ensure the target drive has ample free space. For SSDs, having sufficient free space is crucial as it allows for higher write speeds and avoids performance drops that occur when the drive is nearly full. Magnetic hard drives also benefit from more free space to avoid slowdown due to file system fragmentation.
6. Allow Your Computer to Stabilize After Booting
   • Wait up to 10 minutes after turning on the computer for all background processes to complete and the system to stabilize.
7. Minimize Background Disk Activity
   • Ensure there are no disk-intensive background tasks running, such as Windows updates, which can significantly reduce imaging speed.
8. Pause Indexing and Antivirus Software
   • Windows search indexing has minimal impact on performance, but antivirus software can greatly slow down the process. We found that temporarily pausing the built-in Windows Defender during disk imaging helps bump imaging speeds on some systems.
9. Beware of TRIM Commands on Source SSDs
   • Write blockers cannot prevent data loss resulting from the disks’s internal garbage collection and TRIM processing. While no new TRIM commands shall pass through a write blocker, background garbage collection is unavoidable. If an SSD was recently formatted or had lots of data deleted, avoid powering it up and instead use specialized access tools in factory mode to prevent further data loss.

Beyond the Basics

When it comes to using write blockers for imaging hard disks, there are a few additional considerations that can enhance performance, even if they aren’t strict requirements.

Size and Speed Considerations

Currently, the most common SSD sizes are 1TB or 2TB. Using a modern write blocker, copying 2TB of data can take just over an hour. With an older write blocker or without following the optimal conditions, this process could easily take 2 or 3 hours. For magnetic hard drives (HDDs), the read speed is much slower, so the difference in performance between different write blockers or software should be minimal.

Please note that smaller SSD drives will typically be slower than their higher-capacity counterparts due to decreased parallelism. In addition, SSDs with higher wear (greater write count) may demonstrate random slowdowns due to the overhead of the internal data correction algorithms. Finally, older SSD drives of equal capacity may be either faster or slower than their modern counterparts depending on the technology used (MLC, planar TLC, 3D TLC, or QLC NAND) and the number of NAND chips installed (which equals parallelism, which affects read and write speeds).

Image Formats

In forensic imaging, the most commonly used format is .e01 with default compression settings. Compression helps a lot when one needs to store multiple disk images. The dd/raw format is less commonly used due to its lack of compression and the resulting large size.

• RAW
  • Use When You Need:
    • Maximum compatibility and versatility are needed.
    • Maximum data extraction speed is required.
    • The source disk is almost full.
    • Compression is not required.
  • Avoid When:
    • Using E01 us mandatory.
    • Metadata in the file header is important.
    • Compression required.
• E01
  • Use When:
    • The source disk has plenty of free space or files compress well.
    • Using E01 is mandatory.
    • Metadata in the file header is crucial.
  • Avoid When:
    • The source disk is nearly full, making compression ineffective and complicating image creation.
    • Compression is not required.
• AFF4
  • Use When:
    • You’re after a modern solution.
    • More flexible metadata handling and improved performance are required.
  • Avoid When:
    • Using E01 us mandatory.
    • Your forensic analysis tool does not support AFF4.
• EWF Format:
  • Avoid When:
    • This format is not widely supported and thus may limit usability.

Conclusion

Achieving maximum imaging speed requires adhering to several conditions and using proper equipment and software. Implementing these recommendations can significantly reduce the time  you’ll need to spend for disk imaging.

We attack passwords instead of encryption because modern encryption methods are extremely secure and practically unbreakable due to their complexity and long key lengths. The industry-standard AES-256 algorithm used in practically all encrypted formats employs 256-bit keys, creating an astronomical number of possible combinations that would take an infeasible amount of time to crack through brute force. Passwords, on the other hand, are the entry point to this encryption and are often much weaker due to human limitations in remembering complex strings. Therefore, it’s more practical and efficient to target the password itself rather than attempting to break the encryption algorithm.

What is “strong encryption”?

Strong encryption is a type of encryption that can’t be cracked in a reasonable amount of time by directly attacking the encryption key. A strong encryption method should have no vulnerabilities that would allow an attacker to significantly reduce the time needed to break it. To decrypt data protected by strong encryption, one must know the password or possess the original encryption key. The AES encryption algorithm with 256-bit keys is considered secure as no vulnerabilities have been discovered during the many years of its use. Therefore, if strong encryption is used, attacking the password is the only viable way to access the encrypted data.

Will quantum computing change that?

Quantum computing does have the potential to change the landscape of encryption cracking. While classic encryption methods are incredibly secure against attacks with traditional computing methods, quantum computers can process information in fundamentally different ways. Grover’s algorithm, which quantum computers could use, would reduce the effective key length of AES-256 to 128 bits, immensely reducing the required time to brute-force the encryption key, yet even 128-bit keys are practically unbreakable. However, AES-256 is still considered secure in the face of quantum attacks because it would require a quantum computer with capabilities far beyond what is currently feasible. Therefore, while quantum computing poses future challenges (or opportunities, depending on which side you are), it does not yet fundamentally change the approach of attacking passwords as the entry point to encryption.

Is breaking passwords legal?

The short answer is “it depends”. Regulations jurisdictions have different rules; in some countries suspects must reveal their passwords when interrogated by authorities (welcome to France, the country of Liberté). Obviously, no one can stop you from breaking your own lost or forgotten password; however, if this password protects access to your data stored in some online service, it does not actually matter that the account is yours as you cannot legally attack it. In other words, breaking passwords is perfectly legal if you work with local data and the data is yours, or if you have the permission from the legal owner, or if you work for legal authorities and follow the local regulations. Cracking someone else’s data may be a criminal offence, but there is a huge gray area.

Everything You Wanted to Ask About Cracking Passwords

Is a million passwords a second a lot?

We have a tool that leverages the computational power of modern GPUs alongside with modern multi-core processors to maximize the speed of password attacks. Benchmarks demonstrate the recovery speed on various hardware configurations for different encryption formats. These speeds vary widely; for some formats, even the best hardware can only test a few passwords per second, while for others, speeds can reach millions passwords per second.

So, is a million passwords per second a lot or a little? The thing is, this is not the right question. The correct question to ask would be either “What kind of passwords can be broken withing a certain timeframe at a rate of a million passwords per second?” or “How long will it take to break a certain password at a rate of a million passwords per second?” To answer these, we published some formulas that will allow calculating the answer.

The ABC’s of Password Cracking: The True Meaning of Speed

In the first scenario, there is a typical situation where neither the length nor complexity of the password are known in advance, but there is a certain time limit on how long we can spend on the attack. In the second scenario, the limit is on the maximum password length and complexity (for example, we only try passwords containing digits and Latin letters in both cases plus a small set of special characters), while we calculate the time required to try all possible combinations.

For example, if a certain password can be attacked at the speed of 10 million passwords per second, it would take no more than five minutes to recover a password consisting of only 5 Latin letters in both cases. If the speed is 100 passwords per second and the password is at least 7 characters long and has symbols from the extended character range, the maximum attack time increases to around 700 billion seconds, or approximately 22,000 years. You can find formulas for calculating attack times and much more useful information in our guide.

May the [Brute] Force Be with You!

How to benchmark password recovery speeds?

Benchmarking password recovery is a bit more complex than the nice graphs may suggest. We always test using a full brute-force attack method with a fixed password length and a specific character set limitation. In addition, the testing is always performed by running a brute-force attack. 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. Finally, we don’t start measurements immediately. Instead, we wait for several minutes for the attack to ‘settle’, giving the tool some time to load and compile the required code into the GPU.

Elcomsoft Lab: Benchmarking Password Recovery Speeds

Why do we need video cards? What about distributed attacks?

Most password protection methods rely on multiple rounds of hash iterations to slow down brute-force attacks. Even the fastest processors choke when trying to break a reasonably strong password. Video cards can be used to speed up the recovery with GPU acceleration, yet the GPU market is currently overheated, and most high-end video cards are severely overpriced. Today, we’ll test a bunch of low-end video cards and compare their price/performance ratio.

Making use of GPU cores instead of the CPU helps break passwords faster. Even the slowest built-in GPU with a TDP of several watts may demonstrate performance comparable to a 190W CPU without a sweat. High-end GPUs such as the NVIDIA RTX 4080 can break passwords up to 500 times faster compared to a common Intel Core i7 CPU, while mid-range video cards delivering up to a 250x boost.

GPU acceleration offloads computational-intensive calculations from the computer’s CPU onto the video card’s Compute Units (CUs). A dedicated video card can deliver the speed far exceeding the metrics of a high-end CPU. Even a modest integrated GPU (the one built into a CPU) may be able to match or exceed the performance of the central processor while consuming significantly less electricity and dissipating a fraction of the heat produced by the CPU with similar load.

GPU Acceleration On The Cheap: Using Affordable Video Cards to Break Passwords Faster

Often enough, even multiple high-performance graphics cards might not be enough to successfully recover a password in reasonable timeframe. In such cases, distributed computing (see, Elcomsoft Distributed Password Recovery) comes to the rescue. The effectiveness of distributed computing versus using GPUs is highly dependent on on the data format and the hashing algorithm. If the data can be accelerated on a GPU, even basic graphics cards can outperform a large network of non-accelerated computers. However, several computers, each equipped with several of powerful GPUs, can provide a significant advantage over a single computer. Notably, some algorithms cannot be accelerated on GPUs at all, making distributed computing the only option for speeding up the attack.

Therefore, while a distributed network is generally better, each computer in the network should be equipped with powerful GPUs for optimal performance.

Will video cards eventually replace CPUs?

This is highly unlikely. GPUs will not replace CPUs because of their fundamental architectural differences. GPUs excel at parallelizing a single operation across thousands of threads, making them highly efficient for tasks like password cracking. However, for everyday tasks, CPUs are more suitable because their cores can operate fully independently. This independence allows CPUs to handle a variety of tasks simultaneously, whereas each GPU core is slower than an individual CPU core and can only perform the same operation concurrently. Therefore, while GPUs are faster for specific parallelizable tasks, CPUs are necessary for the diverse and independent tasks encountered in daily computing.

Which video card is best for breaking passwords?

If you are shopping for a new system, buy the most powerful NVIDIA board of the current generation that fits your budget. If you already have previous-generation GPUs, you can continue using those if they are powerful enough; if not, see above. Please note that previous-generation GPUs are generally not worth it if you are buying new, even if the price seems attractive. More on the subject:

NVIDIA RTX 40 Series Graphics Cards: The Faster and More Efficient Password Recovery Accelerators

The current NVIDIA range is complicated. There are multiple models of 4060 alone, as well as multiple variations of 4070 and 4080 to choose from. The following article will help you havigate NVIDIA’s product range:

Navigating NVIDIA’s Super 40-Series GPU Update: A Guide for IT Professionals

What about FPGA/ASIC?

They are great in theory, less so in real life due to their high cost and limited software support. Granted, one could build a cost-effective ASIC, but their price only goes down enough with economy of the scale. There is simply not enough demand from the password breaking perspective to build a cost-effective ASIC, and let us not forget about the still limited software support. If you are looking for efficient acceleration hardware, look for energy-efficient GPUs instead.

How to build an efficient computer for breaking passwords

Power consumption and power efficiency are two crucial parameters that are often overlooked in favor of sheer speed. When building a workstation with 24×7 workload, absolute performance numbers become arguably less important compared to performance per watt.

Building an Efficient Password Recovery Workstation: Power Savings and Waste Heat Management

We compared power efficiency and cooling solutions of various video cards:

Building an Efficient Password Recovery Workstation: NVIDIA RTX Passwords-per-Watt Benchmarks

How encryption works? What is the difference between passwords and encryption keys?

Passwords are used to protect access to documents, databases, compressed archives, encrypted disks, and many other things one can think of. When it comes to encryption, passwords are almost never stored, encrypted or not. Instead, passwords are “hashed”, or transformed with a one-way function. The result of the transformation, if one is performed correctly, cannot be reversed, and the original password cannot be “decrypted” from the result of a hash function.

Raw password hashes are rarely used directly as encryption keys. For example, many disk encryption tools can use passwords to encrypt a so-called “protector”, which in turn is used to protect the “key encryption key”, which in turn is used to protect the “media encryption key”, which in turn is finally used to encrypt and decrypt data. Notably, there are kinds of protectors that do not use passwords at all (instead, they can employ TPM, recovery keys, or USB flash drives for unlocking the disk). Password is the only thing that can be broken by trying multiple different combinations. More on passwords, hashing, and encryption:

It’s Hashed, Not Encrypted

Typically, a password is hashed using multiple rounds of a one-way transformation function, then stored in the file’s header, which allows verifying the password without actually decrypting the encrypted content. The encryption key itself is different from the saved hash, but password attacks are performed against this hash. If the correct password is found, the encryption key is calculated separately. Sometimes, the password hash is not stored in the file’s header, requiring part or all of the data to be decrypted to verify the password, which slows down the attack. The speed of such an attack depends on the size of data needing decryption. One common format using this approach is RAR4 archives. The later version, RAR5, is no longer using this approach.

Breaking RAR5 and 7Zip Passwords

What kinds of attacks are available?

There are several methods for recovering the original password ranging from brute force to very complex rule-based attacks.

Theoretically, during a brute force attack one would try all possible password combinations up to a certain length, but in practice, this is often limited to a subset of characters (like uppercase and lowercase Latin letters, digits, and a few special characters). Since the full Unicode set has 149,186 characters, running a brute-force attack on the entire character set is simply infeasible. Even a three-character password composed of the full Unicode set would take an impractically long time to crack. In reality, passwords rarely include symbols from such diverse and extended character sets, so brute force attacks are usually limited to certain alphabets.

Use The Brute Force, Luke

Brute-force attacks are the fastest, but due to the largest number of passwords one needs to try during these attacks, brute-force is the last resort when all other options are exhausted. Since brute force is extremely inefficient for longer passwords, other types of attacks were invented to reduce the number of passwords to try. Dictionary attacks use words from the dictionary of English language (and/or the user’s native language) as possible passwords. Various other attacks using masks, mutations, and custom rules are also available.

A Word About Dictionaries

Order matters

With the many types of password recovery attacks, when would you use each one of them, and in what order? The following article explains how to order password recovery jobs based on the types of data and information available about the owner.

Building a Password Recovery Queue

GPU and CPU utilization

When it comes to encryption, data formats differ in various ways. One of the major differences is the type of hardware that can be used for running and accelerating password recovery attacks. There are three main scenarios:

1. Brute force supports GPU acceleration, with minimal CPU usage.
2. Brute force only works on CPUs, making GPUs irrelevant. GPU acceleration not supported.
3. Both GPUs and CPUs are utilized, with GPUs doing the bulk of the work and CPUs providing additional support (sometimes using multiple cores).

GPU-accelerated attacks

GPUs excel at performing multiple simple calculations in parallel across many cores. This makes them ideal for brute force attacks on formats that can be split into a large number of simple tasks. When a job can be split to run across thousands of GPU cores, the few cores of the computer’s CPU become insignificant, as they add minimal performance gains while increasing overhead.

Most current data formats are optimized for GPUs, but we observe a slow shift toward algorithms designed to be GPU-resistant.

CPU-only attacks (GPU-resistant algorithms)

Some algorithms are designed to resist GPU-accelerated attacks. This can be achieved by various means. For one, GPU cores handle simple tasks well but falter with more complex computations required by some password-to-binary key transformations. Such algorithms must run on CPUs, significantly slowing down the attack speed.

GPU-assisted attacks with high CPU utilization

Some algorithms utilize both GPU and CPU cores. Typically, the GPU handles most of the workload, while the CPU performs essential supporting tasks. For instance, a powerful 16-core CPU can assist the GPU, but it won’t match the brute force speed achievable by the GPU alone.

Non-brute force attacks, which are often more efficient, still heavily load the CPU. These “smart” attacks are slower than brute force because they rely on batches of passwords, which must be generated. On certain formats, the CPU may struggle to generate password batches quickly enough to fully load the GPU, thus requiring the generation to be run on the GPU itself, which further strains the GPU and slows the attack.

Breaking Passwords on Alder Lake CPUs

Memory-intensive algorithms

Some hashing algorithms are designed to thwart GPU attacks by requiring significant memory usage. For example, the Scrypt algorithm, used in BestCrypt, ensures that even the weakest computers can check a single password without issues, but attempting to run many checks in parallel on a GPU would quickly exhaust its memory. This deliberate design choice makes such algorithms GPU-resistant.

Breaking BestCrypt Volume Encryption 5

More information

We will keep posting about password recovery, yet we have many existing articles on the subject. Below are just a few of them.

Decrypting Password-Protected DOC and XLS Files in Minutes

Microsoft Office encryption evolution: from Office 97 to Office 2019

Password leaks can be used to accelerate cold attacks:

How to Break 30 Per Cent of Passwords in Seconds

How to Break 70% of Passwords in Minutes

 

Password Crackers’ Gold Mine: Browser Passwords

Low-level extraction enables access to all the data stored in the iOS device. Previously, sideloading the extraction agent for imaging the file system and decrypting keychain required enrolling one’s Apple ID into Apple’s paid Developer Program if one used a Windows or Linux PC. Mac users could utilize a regular, non-developer Apple ID. Today, we are bringing this feature to Windows and Linux editions of iOS Forensic Toolkit.

While there are several different methods achieving essentially the same goal, modern devices (starting with those based on the chip found in the iPhone Xr/Xs) require the use of a special app called extraction agent. On the device, the extraction agent attempts to acquire the required level of privileges by utilizing a chain of exploits, which is an absolute requirement for accessing the root of the file system.

Agent-based low-level extraction allows capturing the full image of the device’s file system and a decrypted copy of the keychain. To perform low-level extraction, the extraction agent must be installed onto the device. The installation is implemented via sideloading, which is a method of installing apps onto an iOS or iPadOS device directly, bypassing the official App Store. Sideloading involves signing the app and verifying its digital signature with Apple, which in turn requires the use of an Apple ID. Another consequence is the need to allow the device connecting to an Apple server for certificate validation, which poses a security risk that may be mitigated by using a software-based or hardware-based firewall.

iOS Forensic Toolkit is available for macOS, Windows, and Linux computers. In previous builds, we supported sideloading in all three editions, yet the Mac edition was the only one that could be used to install the extraction agent with a regular, non-developer Apple ID. Users of Linux and Windows editions had no choice but to enroll their Apple ID into Apple’s paid Developer Program, which requires an extra investment. Newly enrolled developer accounts provide little to no tangible benefits over free, non-developer Apple ID’s other than the ability to sideload apps from other operating systems.

iOS Forensic Toolkit 8.60 brings an end to this discrepancy, fully enabling the use of regular, free Apple IDs for the purpose of sideloading and signing the low-level extraction agent. This new feature closes the gap between the Linux and Mac editions, while bringing the Window version one step closer to the Mac build.

Differences Between Editions

There are very few functional differences left between the Mac, Windows, and Linux editions. The Mac and Linux editions are currently on-par feature wise, while the Windows edition offers the same functionality in high-level logical acquisition and low-level, agent-based extractions. The Windows edition still lacks support for bootloader-level extractions available for Apple devices based on older chips, but this is its only functional limitation remaining.

Please note that we also provide a Live Linux edition, which boots from an external storage device such as a flash drive or external SSD. The Live Linux version has the updated sideloading mechanism already integrated. Therefore, if you don’t have a macOS computer at hand, you can simply download and flash the bootable image, boot your computer from an external drive, and then perform low-level extraction without any functional limitations.

Two-Factor Authentication

In the past, one could receive two-factor authentication codes delivered to a trusted SIM via a text message (you’ll need to pass two-factor authentication to sideload the extraction agent with your Apple ID). Currently this type of two-factor authentication is not recommended. We strongly recommend using an Apple ID that has at least one trusted device connected. This way you’ll be able to use two-factor authentication code pushed to the trusted device.

Conclusion

The latest release makes a significant advance in low-level forensic extractions across different operating systems. By bringing the ability to use regular, non-developer Apple IDs for sideloading the extraction agent on Windows and Linux systems, the Toolkit makes enrolling in Apple’s Developer Program optional. This change not only eliminates additional costs but also simplifies the process for many users.

The toolkit now offers a more unified experience across macOS, Windows, and Linux, with the Mac and Linux editions being feature-equivalent and the Windows edition closing in with nearly identical capabilities. The primary remaining difference is the lack of bootloader-level extraction support on the Windows edition for devices with older chips, but all other major functionalities, including high-level logical acquisition and agent-based low-level extractions, are fully supported.

Apple accounts are used in mobile forensics for sideloading third-party apps such as our own low-level extraction agent. Enrolling an Apple ID into Apple Developer Program has tangible benefits for experts, but are they worth the investment? Some years back, it was a reassuring “yes”. Today, it’s not as simple. Let’s delve into the benefits and limitations of Apple Developer accounts in the context of mobile forensics.

Why do we need an Apple ID?

Four years back, we published a comprehensive article Why Mobile Forensic Specialists Need a Developer Account with Apple. While some details in this article have been changed (more on that later), it still provides a good introduction into why forensic experts require an Apple ID for file system extraction.

On modern devices, low-level extraction means utilizing a chain of kernel exploits to obtain high-level privileges, escape sandbox and access the file system. For that purpose, we developed a special app, the low-level extraction agent.

The extraction agent is deployed on iOS devices in the form of a file with .ipa extension. The IPA package (iOS App Store Package) file is an iOS application archive file containing the iOS app. Technically speaking, it’s a simple ZIP archive that contains a binary for the ARM architecture that can be installed on an iOS device.

Each IPA file must be signed before you can install it onto an iOS device. For the installed package to be launched on the device, iOS requires digital signature verification. Unlike most other platforms, iOS not only verifies the application developer but also identifies the device(s) on which the application can be installed. An Apple ID account is used to sign the package.

About Apple Developer accounts

In layman terms, an “Apple Developer account” is just a standard Apple ID enrolled into Apple’s developer program. Participation costs $99 a year for individuals, more for organizations.

Developer account benefits

When it comes to mobile forensics, developer accounts have a major benefit over standard Apple IDs, enabling the sideloading of third-party apps while waiving the requirement to validate the signing certificate. This in turn means that using a legacy (see below) developer’s Apple ID allows sideloading, launching, and using the extraction agent completely offline, without a working Internet connection. When using a developer account, the device UDID is sent to Apple and registered with the the developer program (and is counted against the 100-device quota). Then a device-specific certificate is created, which iOS Forensic Toolkit uses to sign the IPA and sideload it onto the device. This certificate will be unique to the particular device, and no further verification is required. Please note that this applies to legacy accounts only; there is a slightly different procedure for new Apple ID’s (see below).

The biggest drawback of developer accounts is basically the fact that you have to enroll into the program, which is a bit of a hassle and requires the annual fee of $99.

The other drawback is major, but only applies to accounts enrolled after June 6, 2021. For these accounts, iOS will validate the signing certificate the first time you launch the extraction agent, which requires online connectivity. If you are using a Mac and just considering becoming an Apple Developer, please note that enrolling today will not allow for a fully offline sideloading.

Yet, offline sideloading is not the only benefit of developer accounts. An Apple Developer account is required to sideload apps if you are using iOS Forensic Toolkit on a Windows or Linux PC. Mac users may continue using standard, non-developer Apple ID’s for this purpose.

Legacy developer accounts: before June 6, 2021

If you became a Developer before June 6, 2021, you are in luck: you can sideload, launch, and use apps such as the extraction agent completely offline.

Recently enrolled Apple IDs

If you have enrolled your Apple ID, you will be subject to Apple’s new rules that will require online verification on the first launch of the extraction agent. This poses security risks that can be mitigated with a software or hardware firewall. Apple explais the difference:

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.

Applying as an individual or as an organization

Apple allows enrolling as an individual or as an organization. Personal memberships are faster and easier to get, while organizations will need additional paperwork (and a DUNS number). The annual fee is the same, as well as the limit of 100 devices of each kind per year.

Standard Apple IDs

Standard Apple IDs are free of charge, but you can only use them to sideload apps from a macOS computer. If you are using a Windows or Linux PC, you will need a developer account to sideload the extraction agent. In addition, you will be required to validate the agent’s digital signature online if you use a regular Apple ID to sideload the app (a firewall is a must in this case).

Understanding the limitations

As a forensic specialist, it’s important to be aware of the limitations and rules that come with standard and developer accounts.

Device registration limits

For developer accounts, Apple imposes a limit of 100 devices of each type (iPhone, iPad, Apple TV, etc.) per year. Once a device is registered, it cannot be removed from your list until the annual reset when you renew your developer program membership. Additionally, after registering the first 10 devices, you might experience delays of up to three days for subsequent device registrations.

For standard accounts, this limit is 3 devices per week.

Best practices for developer accounts

We recommend using your developer account with a trusted Mac that already has the account configured. This will simplify sideloading while making it more robust, and allow you to skip two-factor notification.

Standard account restrictions

Standard Apple accounts have stricter limits and constraints. You can only use up to 3 devices per week, and you can only use Macs for sideloading the extraction agent. Sideloading Windows or Linux is not supported.

Digital signature verification

Online verification of a digital signing certificate is mandatory for all standard Apple IDs. While this is not required for developer accounts, for newly enrolled developer accounts you will still have to allow the device connect to an Apple server when running the extraction agent for the first time. Using a firewall is strongly recommended to secure this process.

Trusted device requirement

For all types of accounts, having a trusted device is strongly recommended. While you can initially use text messages for authentication, Apple may eventually require you to authenticate through a trusted device exclusively.

Conclusion

Do you need a developer account? If you don’t already have one, note that the primary advantage of Apple developer accounts in the context of mobile forensics is the ability to sideload the extraction agent from Windows and Linux computers. With freshly enrolled developer accounts you will still need to protect your device with a firewall during the agent’s initial launch as iOS will enforce digital signature verification.

On the other hand, if you already have a developer account enrolled before June 6, 2021, it’s best to continue using it. Such accounts offer the advantage of fully offline sideloading, meaning that you won’t have to use firewalls when installing the extraction agent.

If you are a macOS user, there are no significant benefits to enrolling into Apple’s Developer Program today. You can still sign the extraction agent with a standard account, and there will be no difference in the requirement to allow the device going online.

iOS Forensic Toolkit comes in three flavors, available in macOS, Windows, and Linux editions. What is the difference between these edition, in what ways is one better than the other, and which edition to choose for everyday work? Read along to find out.

macOS, Windows and Linux editions compared

iOS Forensic Toolkit is a true multi-platform tool, sharing the same user interface and almost the same features across the different platforms. While the macOS edition remains the most feature-rich, the Linux edition is not far behind, while the Windows edition is the most limited of the three. However, there is much more to it than just features. The three editions differ in system requirements (beyond the obvious platform/OS support), convenience, and compatibility. Let’s start with the feature comparison, and move on to the rest once we’re clear on the feature set.

Feature comparison

The Windows edition of iOS Forensic Toolkit supports logical and agent-based extraction methods, but lacks support for bootloader-based extractions, which are only available for macOS and Linux platforms. The ability to sign the extraction agent using a regular, non-developer Apple ID remains an exclusive feature of the Mac edition.

Feature/platform	macOS	Windows	Linux
Extended device information	✓	✓	✓
Logical extraction: backups	✓	✓	✓
Logical extraction: media files and metadata	✓	✓	✓
Logical extraction: diagnostic logs	✓	✓	✓
Agent: low-level extraction with Apple developer account	✓	✓	✓
Agent: low-level extraction with regular Apple ID	✓	✕	✕
checkm8: bootloader-level extraction	✓	✕	✓
Additional service features (e.g. SSH)	✓	✓	✓

Please refer to the following chart to learn more about the differences between editions feature-wise.

Compatibility

The Windows edition can run on Windows 10 and Windows 11 (currently Intel only). Note that you must have iTunes (or Apple Devices app) installed on Windows computers; you must also ensure that iTunes/Apple Devices was launched at least once on that computer before you can use iOS Forensic Toolkit (you don’t have to have it running, just launch it once to ensure the system is properly initialized). You won’t need either tool on macOS or Linux computers.

The macOS edition supports macOS BigSur and newer releases. For macOS, Apple Silicon computers are preferred to the aging Intel platform, yet we still support the older Macs through the legacy build of iOS Forensic Toolkit. Note that you may need to re-connect the device on some Intel systems, while there is no such issue on Apple Silicon based computers. For Type-C only devices, a USB-C to USB-A hub will be required to connect both the device and the Toolkit’s USB dongle and, on some computers, the charging cable.

The Linux edition has been tested on multiple Linux distributions, officially supporting the current Debian, Ubuntu, Kali Linux, and Mint distros, ensuring seamless operation for forensic professionals using different Linux setups. We currently support Intel-based computers, yet a test ARMv8 build is already out for the Raspberry Pi 5 platform.

USB-C ports: you will need a USB-A port for the Toolkit’s USB dongle, and another USB-A port for checkm8 extractions. For other types of extractions (agent, extended logical) we strongly recommend using the USB-C port instead. Finally, yet another USB-C port may be needed on some MacBooks to connect the charging cord.

File systems: if you plan to use the extracted data on different computers, we strongly recommend formatting the media (such as external SSD drive) to exFAT, as exFAT is currently the only file system properly supported by all three OSes.

Convenience

While all three editions share the same powerful comman-line interface (CLI), there are plenty of things putting one or another edition ahead in some circumstances.

Installation is the easiest in Windows, where you can simply install iOS Forensic Toolkit and run it immediately (but do note that you’ll need iTunes or Apple Devices installed and launched at least once on that computer). The Linux edition requires additional dependencies that must be installed manually

The macOS requires removing the quarantine flag right after installing the Toolkit, which may be complex on modern Macs. On the other hand, the Mac edition supports a software firewall – a feature not available in Linux or macOS (you’ll have to use our Raspberry Pi based solution for that).

Reliability

Among the three platforms, the Mac edition wins hands down in the reliability department. This in part is due to the better drivers, and in part because of some things that can are native to the Mac but foreign to other platforms.

Conclusion

If you have a Mac, use it. If you can afford a Mac, buy it. If you cannot afford a Mac, the Linux edition is the next best thing with full checkm8 support (and we are working hard on the ARM edition that will allow running the thing on the affordable and highly portable Raspberry Pi 5 platform). In addition, we are about to document the Live edition of the Toolkit available to all registered users of iOS Forensic Toolkit. The Live version allows booting into the Linux edition of the tool from an external media. The Linux edition won’t let you use the agent without a developer account, which will be another $99/year investment. Finally, if Windows is all you have access to, do use what you have: iOS Forensic Toolkit will do great with advanced logical extractions and agent-based low-level extractions (if you have a developer account with Apple).

One more thing

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 in contributing back to the open source community by publishing our changes to those projects as required by their permissive license.

As a company, we are wholly dedicated to providing a solution that complies with licensing regulations, meeting all pertinent legal requirements. In addition to fulfilling our legal obligations, we want to point out the other 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. We welcome everyone to check out our GitHub account containing the relevant open-source projects:

 

Twelve years ago, we introduced an innovative way of accessing iPhone user data, retrieving iPhone backups straight from Apple iCloud. As our iCloud extraction technology celebrates its twelfth anniversary, it’s a fitting moment to reflect on the reactions it has provoked within the IT community. Let us commemorate the birth of the cloud extraction technology, recap the initial reactions from the forensic community, and talk about where this technology stands today.

Initial concerns

Back in 2012, our release of iCloud extraction technology led to heated discussions within the IT community. Two predominant sentiments have emerged, each with its own distinct perspective.

The ignorant: Some regarded iCloud Extraction with indifference, arguing that if one possesses the login credentials, accessing iCloud data becomes a trivial matter. This viewpoint sees little novelty in the extraction process, viewing it merely as a pathway to complete data accessibility.

The alarmists: Conversely, there are those who sounded the alarm bells, highlighting the potential risks introduced by iCloud extraction. To them, it represented a new avenue for hackers to exploit and a new way for oppressive regimes to spy on their citizens, exacerbating the already daunting challenges of cybersecurity.

While both viewpoints hold elements of truth, they also oversimplify the complexities at play. While having the authentication credentials does indeed grant access to the cloud vault, downloading an iCloud backup, even possessing the original login and password, is only technically possible by setting up a genuine Apple device, which in turn must run a compatible version of iOS and such. And then, one would still need to extract that data from the Apple device, which in itself is a challenge.

The alarmists’ viewpoint has its ground, proven by the infamous 2014’s Celebgate hack. Yet a tool is just a tool. It can be used for both noble and nefarious purposes. The extraction of iCloud data, like any technology, is inherently neutral. It’s the intentions and actions of those who use it that determine its impact.

Moving beyond the polarizing debate, it’s essential to look deeper into the technical and legal nuances of iCloud extraction and the technology’s implications for data security and privacy. While concerns about potential misuse are valid, dismissing the technology outright overlooks its legitimate uses, such as aiding law enforcement in criminal investigations or assisting individuals in recovering lost data. Moreover, it is important to recognize the evolving nature of cybersecurity threats and the need for continuous adaptation and improvement in defense mechanisms. The Celebgate incident served as a wake-up call for both Apple and users alike, prompting improvements in security protocols and user awareness. And Apple did react.

Sword vs. shield

While Apple did not immediately respond to the new threat, the availability of third-party cloud extraction technology made the company rush the release of new security measures already in the development pipeline. In March 2013, Apple released an optional two-step verification protection as a stopgap measure before introducing proper two-factor authentication in 2015. The half-baked two-step verification did not protect either photos or backups, as noted in Apple iCloud security exploit is a concern, experts say – BBC News and  Apple’s iCloud cracked: Lack of two-factor authentication allows remote data download | ZDNET.

Today, more than 95% of Apple accounts are protected with two-factor authentication that protects everything except Find My services (for a good reason). We added support for two-factor authentication soon after it was introduced, enabling access to data stored in accounts protected with the second authentication factor.

In addition to enhancing authentication protocols, Apple implemented various other measures to fortify iCloud security. These included strengthening encryption standards with end-to-end encryption, which additionally protects sensitive data (on top of the regular iCloud encryption) with a key that is re-encrypted with the user’s device passcode (or multiple passcodes if there are several devices with different passcodes registered on the same Apple ID). Since Apple does not know the user’s device passcode, it does not have access to the user’s sensitive information such as account passwords or messages in iCloud. In 2017, we added the ability to extract iCloud keychain, which is a major part of the end-to-end encrypted data set. As Apple continued moving more and more data under the end-to-end encrypted umbrella, we learned how to extract those other types of data.

iOS 17 partially broke third-party access to iCloud. We are still struggling with iCloud backups produced by some iOS 17 devices. The extraction may or may not work, and we are yet to determine the root cause of the problem. At least, synchronized data can still be extracted, including iCloud Photo Library and end-to-end encrypted categories. Or, rather, it could.

Until today.

In the end of 2022, Apple introduced an optional new feature called Advanced Data Protection for iCloud. This opt-in feature enables users to protect nearly all of their information with strong end-to-end encryption. Implementation of the new encryption mechanism differs from the standard end-to-end encryption. The old trick of providing a screen lock passcode and having the vault open no longer works. More than a year after this update, we still cannot access information stored in accounts with  Advanced Data Protection for iCloud. For the time being, the shield wins the battle.

The legal pathway

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.

The printable request form is available here:

The following general resources are available:

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. Moreover, Apple does not return any data that falls under the end-to-end encryption umbrella, which means absolutely no access to iCloud keychain (with the user’s logins and passwords), no messages, Safari history, and many other types of data that might become essential evidence. All of that data is downloadable with Elcomsoft Phone Breaker, but only if one has a screen lock passcode or system password to one of the user’s Apple devices registered in the same Apple ID account.

Legal considerations

In digital forensics, accessing and examining cloud-stored data comes with technical and legal challenges. Law enforcement often relies on such data for investigations, but accessing it requires following legal procedures like obtaining search warrants. The rise of cloud storage adds complexity, including jurisdictional issues and privacy concerns, complicating lawful data collection.

Efforts to regulate law enforcement access to cloud data aim to balance public safety and privacy rights. Policies shape the legal landscape in different sovereign states, while the U.S. CLOUD Act sets up legal framework for cross-border data access. Compliance requires adherence to due process, and mutual legal assistance treaties aid lawful data access. Understanding these legal frameworks helps IT specialists collect and examine iCloud data lawfully, ensuring compliance and respecting privacy rights.

Forensic acquisition using Elcomsoft iOS Forensic Toolkit (EIFT) has undergone significant changes over the last few years. The earlier major branch, EIFT 7, was a carefully crafted but Windows-only script that automated the use of several bundled tools and guided the user without requiring them to know how to use each of them individually. EIFT 8 brought many new features, a more powerful interface and widespread support for new devices and host operating systems. Due to restrictions and challenges, not all features were immediately available on all platforms. There are still some minor differences in features between Windows, Linux, and macOS versions of the tool.

While the macOS version is the most complete in terms of features, not everyone has a Mac. Purchasing one (or even several) can be a stretch to one’s budget. Most experts who are not using macOS would likely consider the Windows version as the next best thing, but unfortunately the Windows edition of iOS Forensic Toolkit is the least feature-rich (at the time of writing) due to challenges in developing iOS acquisition software. Most notably, it currently does not support checkm8 acquisition as running the exploit from Windows turns out to be quite a challenging task.

Thus, when Macs are absent, the next best option would be to use the Linux edition (made for Ubuntu). That edition is currently only behind in some features regarding the usage of non-developer Apple accounts for installing the extraction agent.

Those unfamiliar with Linux may hesitate to install it alongside the likely already-installed Windows, or perhaps company policy might prevent experts from doing so. In these circumstances, it might be tempting to consider a virtual machine; however, unfortunately, using one is not supported because the checkm8 exploit will not work inside a VM. The logical option would be purchasing dedicated hardware specifically for the purpose of performing low-level data acquisition with iOS Forensic Toolkit. Instead of wasting money on a cheap laptop, which will likely backfire as soon as one tries to use it, it would be wiser to acquire an inexpensive but still decent machine such as the Raspberry Pi 5. The Raspberry Pi 5 features a quad-core CPU, 8GB of RAM, and a PCIe 2.0 lane, which allows connecting an M.2 SSD using an appropriate third-party kit.

If you have a spare sum to spend on a decent Linux machine, our Research & Development Department can recommend the 2022 LG Gram 17″ Ultralight Notebook. However, at that price point, you might as well buy a MacBook, which will have better compatibility with iOS Forensic Toolkit to begin with.

Elcomsoft Forensic Acquisition System (EFAS)

For the purpose of running iOS Forensic Toolkit on a Raspberry Pi 5, we created a dedicated image called Elcomsoft Forensic Acquisition (Operating) System, short EFAS. It comes as a minimal environment based on Arch Linux for ARM, with dependencies pre-installed and pre-configured so that the user can jump right to performing forensic acquisition tasks with ease. For this purpose we created a dedicated iOS Forensic Toolkit build for Linux arm64 target and tested it to provide a smooth user experience on EFAS. EFAS has all the dependencies already installed and correctly configured, so that EIFT can be run and used intuitively.

Note: It is theoretically possible to run iOS Forensic Toolkit arm64 Linux build on other operating systems, however that is not officially supported because several dependencies need to be installed and configured for iOS Forensic Toolkit to run correctly.

EFAS Features

EFAS comes with SSH pre-installed and enabled. You can simply connect the Raspberry Pi to Ethernet, then ssh into it with the command ssh eift@EFASpi5 and the password Elcomsoft, then continue your workflow from your regular machine.

Note: If you don’t intend on using SSH, we recommend to disable it using the commands sudo systemctl disable sshd and sudo systemctl stop sshd to not potentially expose your acquired data to the network. If you later decide that you want to re-enable SSH, the commands are sudo systemctl enable sshd and sudo systemctl start sshd

Alternatively, you can connect a monitor over HDMI and attach a mouse and keyboard over USB, and use the Raspberry Pi as a desktop. EFAS will greet you with the GDM login screen, where you can select the eift user and login with the password Elcomsoft. You will be then welcomed by a KDE desktop environment with helpful shortcuts such as the Alacritty terminal emulator or the Nemo file viewer. Due to poor X11 compatibility with Raspberry Pi 5, we chose to go with a fully Wayland based system. This works fine for most basic applications, but unfortunatelly sometimes there are issues with non-working legacy programs (such as GParted) requiring to fall back to the terminal for some tasks.

Note: We strongly recommend to change the default password. This can be done using the terminal and the following command passwd.

Using iOS Forensic Toolkit

You can either download iOS Forensic Toolkit directly on the Raspberry Pi using Firefox, or download it on your regular computer and copy it to the RPI using a USB drive or scp.

Important: Do not unzip iOS Forensic Toolkit onto the USB drive as this is known to cause problems running EIFT later!

Instead, copy the zip file to the RPI (for example to the Desktop) and then unzip EIFT there (for example using the terminal unzip EIFT.zip). Afterwards, you can use EIFT as usual.

Using an NVME drive

Raspberry Pi 5 comes with a PCIe 2.0 lane, which can be use to connect an M2 SSD using an appropriate third-party kit. When connecting the M.2 drive for the first time, you may need to partition and format the drive. If you plan to use the M.2 drive for acquisition on the Raspberry PI, then disconnect it and connect it to a different computer for analysis using an external M.2 case, then you may want to format the M.2 drive to a filesystem that your host recognizes, such as exFAT. In all other cases we recommend formatting the drive as BTRFS. This will have advantages when dealing with Perfect Acquisition and large image dumps, as BTRFS supports features like COW (Copy On Write) and snapshots that can be useful (EIFT does use the former if the filesystem supports it).

When using iOS Forensic Toolkit, make sure to specify the output path -o to be a path located on the M2 drive for improved performance.

Formatting the M2 drive

First, check that the drive is detected correctly. This can be done using lsblk. The output should look something like this:

[eift@EFASpi5 ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 119.1G 0 disk
├─mmcblk0p1 179:1 0 160M 0 part /boot
└─mmcblk0p2 179:2 0 118.9G 0 part /
nvme0n1 259:0 0 465.8G 0 disk
└─nvme0n1p1 259:1 0 465.8G 0 part
[eift@EFASpi5 ~]$

Here you can see the M.2 is detected as nvme0n1.

To partition the drive use sudo gdisk /dev/nvme0n1. Use o to delete existing partitions (may need to be confirmed with y), then use n,1,,, (all entries need to be confirmed with enter, but the last 3 can be left blank) to create a new partition and finally w,y to write changes to disk.

Next format the partition using sudo mkfs.btrfs /dev/nvme0n1p1.

When done, you can mount the drive using Nemo gui.

Obtaining EFAS

Elcomsoft Forensic Acquisition (Operating) System is fully opensource, and the scripts used to build the image are available in our GitHub repo. Head to the “Releases” section and download the latest build generated by our CI pipeline.

Trusting the operating system you use is good, but it is much better when you can actually verify that no shenanigans are happening secretly in the background. In the field of forensic we are often dealing with very sensitive data after all. Thus we want to make sure that we know the data stays safe and secure. Therefore you can not only see all the custom files that will end up on the image, but you can also inspect the scripts that install and configure the software so that you know what is going to be on the image you install.

Even better, the full log of the CI runner that build the image is publicly visible on github so you can trace exactly how the image was built. If all that is still not enough, you can clone the repo and build the image yourself locally without needing to turst anyone but you!

Note: Building the image locally requires a Linux host and several dependencies installed and correctly configured such as systemd-binfmt and qemu. We recommend downloading the pre-built image.

At the time of writing EFAS is still in its early stages, so there may be some initial hiccups, which will be smoothed out in later revisions. Feedback, suggestions for improvement and contributions are welcome, so please open an issue on GitHub if you run into problems!

Conclusion

When macOS computers are unavailable and Linux cannot be co-installed on a desktop, or perhaps a portable solution is desired, a Raspberry Pi 5 is a great option. For such cases, Elcomsoft Forensic Acquisition System (EFAS) provides a pre-configured environment optimized to work seamlessly with Elcomsoft iOS Forensic Toolkit (EIFT). Just head to our GitHub, download EFAS, flash it to a microSD card, acquire the data using EIFT, and move on to the crucial analysis part of your work.

In the realm of iOS device forensics, the use of the checkm8 exploit for low-level extractions has become a common practice. However, when using this method, you may occasionally need to remove the device’s screen lock passcode, which can lead to several undesirable consequences. In this article, we’ll study these consequences and learn when you need a screen lock reset, when it can be avoided, and how what the latest iOS Forensic Toolkit has to do with it.

With the release of iOS Forensic Toolkit 8.55, we have managed to bypass the requirement for resetting the screen lock passcode for the vast majority of devices for which it was previously required. However, for three devices (iPhone 8, 8 Plus, iPhone X) running iOS 14 or 15, you still have to remove the screen lock passcode when using checkm8 extraction. However, we propose using an alternative low-level extraction method instead that does not care about the passcode.

Why a passcode reset may be required (and why it may not even help)

The vulnerability used in the checkm8 exploit resides in the hardcoded bootloader. This itself cannot be changed or patched by Apple. However, we’ve seen Apple developers largely mitigate the effects of the exploit when it comes to data extraction.

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

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

Therefore, the extraction will fail if a passcode was ever used on the iPhone 8, 8 Plus or iPhone X after the initial setup if one is running iOS 16. If one of those iPhones runs iOS 14 or 15, we can still access the user data; however, a passcode removal is required.

TL&DR: when a passcode reset is required

Removing the screen lock passcode is only required if (all conditions must apply):

• You are doing a checkm8 extraction
• The device is either an iPhone 8, 8 Plus, or iPhone X
• The device is running iOS 14 or 15

If any one condition is not true, you don’t need to remove the passcode.

Why removing the passcode can be detrimental

There are several consequences to removing the screen lock passcode during an investigation.

1. The extraction process is no longer forensically sound as many changes are made to the device.
2. The passcode removal causes some data to be permanently lost, such as Apple Pay transactions, downloaded Exchange-based mail, some application tokens etc.
3. Under certain circumstances, the passcode cannot be removed until one signs in to iCloud from the affected device, which creates the obvious risks of remote wipe/lock, as well as unwanted data sync.
4. If you use a workaround described in How to Remove The iPhone Passcode You Cannot Remove, the reset of device settings causes even more changes on the device, let along it’s not always possible (e.g. if a Screen Time password is set, or the device is managed).
5. The device is no longer “trusted” in a sense of accessing end-to-end encrypted data stored in iCloud.

For these reasons, we discourage this practice if it can be avoided. Consider removing the password as a last resort, one that should only be taken after careful consideration of all the pros and cons. If you still need to reset the screen lock code, make sure that a backup of the device has been made beforehand (even if it’s password-protected), media files have been extracted via the AFC protocol, and diagnostic logs and application files have been saved.

How to remove the screen lock passcode

While removing the screen lock passcode is normally a simple and straightforward procedure (Settings, Face ID & Passcode, Turn Passcode Off; you’ll be prompted for the original passcode), you may encounter problems even during this simple procedure. Screen Time password, MDM, external security policy and certain device settings may prevent you from disabling passcode authentication. Please read How to Remove The iPhone Passcode You Cannot Remove for more information.

When NOT to reset the passcode

By now we’ve figured that you only need to reset the screen lock passcode for iPhone 8, 8 Plus, and iPhone X devices running iOS 14 and 15 when you do checkm8 extraction. However, an alternative low-level extraction method exists that returns the same amount of data without requiring you to reset the screen lock passcode.

If the device is running iOS 14 or 15 (and even iOS 16, currently up to iOS 16.5.1), you can use the extraction agent in iOS Forensic Toolkit. The extraction agent does not require the screen lock passcode to be removed.

Important: Previously, you would be prompted to remove the screen lock passcode for the following iPad models if they were running iOS 16:

• iPad Pro // A9X
• iPad Pro 2 // A10X
• iPad 5 // A9
• iPad 6 // A10
• iPad 7 // A10

This is no longer the case with the latest release of iOS Forensic Toolkit 8.55. We recommend updating to the latest version of iOS Forensic Toolkit if you have an older version installed.

Conclusion

It is important to mention that competing solutions often necessitate the removal of the screen lock passcode over a significantly broader range than our solution does. In iOS Forensic Toolkit, we leverage all current exploits, including the SEP exploit for A10 processors, to work around the passcode whenever possible. Consequently, when using our products, resetting the screen lock passcode is only required when one cannot bypass it even theoretically.

iOS backup passwords are a frequent topic in our blog. We published numerous articles about these passwords, and we do realize it might be hard for a reader to get a clear picture from these scattered articles. This one publication is to rule them all. We’ll talk about what these passwords are, how they affect things, how to recover them, whether they can be reset, and whether you should bother. We’ll summarize years of research and provide specific recommendations for dealing with passwords.

iOS Backups: What Are They?

Within the Apple ecosystem, user data can be backed up in several different ways, with some redundancy. Here’s what is available:

1. iCloud backups: these can be either plain or encrypted if Advanced Data Protection for iCloud is enabled.
2. iCloud synchronized data: partially redundant, partially complementary to iCloud backups. E.g., the camera roll may be synchronized with iCloud via iCloud Photos, and may not be included in iCloud backups.
3. Local backups: created on the user’s computer with iTunes or Finder. These can be plain or encrypted (password-protected).

Note: The only iOS-based devices that have the backup service are the iPhone, iPad, and iPod Touch. All other iOS-based devices such as the Apple TV, Apple Watch, and HomePod, do not have a backup service. For those devices, advanced logical extraction is limited to extended device information, crash logs, and media files.

In addition to backups, which are extracted in the course of logical analysis, significantly more data may be available if a low-level extraction method is available for a given device. For older devices, checkm8-based extraction is available, while many iOS versions are supported by a different low-level method utilizing the extraction agent. Despite being able to extract much more information than is available in backups, these methods are limited in their scope due to either supporting outdated devices or older versions of iOS. Meanwhile, logical analysis (and thus backups) is available for all iPhone and iPad devices regardless of the OS version.

Device backups may contain valuable evidence; they are your best bet when performing logical acquisition. Apple’s documentation lists the data that is not included in local backups:

A computer backup of your device, which is not the same as a sync, includes almost all of your device’s data and settings. A backup from a computer doesn’t include:

• Content from the iTunes and App Stores, or PDFs downloaded directly to Apple Books
• Content synced from your Mac or PC, like imported MP3s or CDs, videos, books, and photos
• Data already synced and stored in iCloud, like iCloud Photos, iMessages, and text (SMS) and multimedia (MMS) messages
• Face ID or Touch ID settings
• Apple Pay information and settings
• Apple Mail data
• Activity, Health, and Keychain data (to back up this content, you’ll need to use Encrypted Backup.)

We have a note on the Camera Roll though.

Local Backups, iCloud Photos and Camera Roll

While Apple states that data already stored in iCloud (e.g., iCloud Photos) will not be included in local backups, our own tests do not confirm it. Based on our research, the Camera Roll is always included in local backups regardless of whether or not iCloud Photos are used. However, some pictures may be physically removed from the device if “Optimize iPhone Storage” is enabled. According to the documentation, “when Optimize Storage is turned on, full-resolution photos and videos are stored in iCloud, and, when needed, space-saving copies are stored on your device.” If this occurs, full versions of photos can be extracted from iCloud through cloud extraction using Elcomsoft Phone Breaker.

Photos along with metadata can be extracted from the device via the AFC protocol with Elcomsoft iOS Forensic Toolkit during of advanced logical acquisition. This method has an additional advantage: the AFC protocol cannot be password-protected. Using AFC extractions makes sense in the following situations:

• The backup is password-protected; cannot reset or recover the password.
• The backup creation fails.
• You only need photos and nothing else.

What is a Backup Password?

Producing Backups

The Password is Empty

As we figured, one can extract more information from a password-protected backup. If the password is empty and you use iOS Forensic Toolkit for extraction, the tool will automatically attempt to set the password to “123”. Watch the phone screen; you’ll need to key in its screen lock passcode to confirm password change. Note: the passcode request is displayed for a limited time (about 30 seconds); pay close attention to the device screen! If you miss this request, the backup will continue to be created without a password. In this case, you will need to repeat the extraction, setting the password manually with a special command (see the “cheat sheet” above, step 7).

Removing the temporary password after the extraction also requires entering the screen lock code on the device screen. The prompt will appear for a short time at the end of the process, so it’s quite easy to miss it. If you miss the prompt, the backup still be created, but the phone will be configured with a backup password. When you try making a backup another time, you’ll encounter an “unknown password”. Moreover, third-party tools are doing the same, and each tool sets has its own password. Therefore, if you have a device with a backup password set, start by trying the passwords commonly used in forensic software packages.

Temporary Passwords Set by Forensic Tools

We are listing all known temporary passwords below:

• Elcomsoft iOS Forensic Toolkit: 123
• Cellebrite UFED: 1234
• MSAB XRY: 1234
• Belkasoft Evidence Center: 12345
• Oxygen Forensic: 123456 (or oxygen for legacy versions)
• Magnet AXIOM: mag123
• MOBILedit Forensic: 123

So there are six commonly used passwords: 123, 1234, 12345, 123456, mag123, oxygen. You can try them on new and existing backups, or even add them to the beginning of your custom dictionary.

Handling Unknown Passwords

The primary ways to handle backup passwords are: discovery, recovery, reset, bypass, and ignore.

Discovery

If you have access to a macOS computer paired to the subject iPhone, you may check the macOS Keychain for the backup password. Accessing the keychain requires the user’s Mac account password.

Software: Keychain Acccess (free; built-in to macOS)

For users of other operating systems, the iOS backup password may coincide with one of the user’s other passwords, which, in turn, can be extracted from sources such as the user’s Web browser or password manager. Passwords from the user’s browser can be extracted using Elcomsoft Internet Password Breaker, which supports all popular versions of Chrome, Edge, Firefox, Opera, and many others.

Recovery

The only way to break an iOS backup password is through a password recovery job utilizing brute-force or dictionary attack. However, even with powerful GPU accelerators, processors, a full-scale brute force attack would be extremely slow and generally unfeasible. Even with a fast GPU, you can only expect the speed of a few dozen passwords per second. Clearly, this method can only find the shortest passwords. We recommend using a short, custom dictionary targeting the human factor. Known user passwords, password leaks and smart attacks are all available in Elcomsoft Distributed Password Recovery. Passwords extracted from the user’s Web browser would make a good starting point for such attacks.

If you would rather use Elcomsoft Phone Breaker for attacking the backup password, note that password recovery is only supported in the Windows edition.

Reset

Начиная с iOS 11, пароль к резервной копии можно сбросить; подробные инструкции – в статье Логический анализ iPhone: резервные копии iTunes. Сброс пароля к резервной копии осуществляется через настройки, пункт Reset All Settings (потребуется ввести код блокировки экрана). Помимо пароля к резервной копии эта команда сбросит и код блокировки экрана устройства, а вместе с ним – удалит те данные, которые зависят от наличия на устройстве кода блокировки. Пропадёт список транзакций Apple Pay, учётные записи Exchange и вся переписка в них, а также многие другие данные. По этой причине сброс пароля – крайняя мера, идти на которую стоит лишь после тщательной оценки всех “за” и “против”.

Кроме того, сброс настроек, помимо перечисленных выше неприятных последствий, отключает “полётный” режим, что может вывести устройство в онлайн со всеми сопутствующими рисками. По этой причине сброс настроек рекомендуется проводить в изолированном от радиочастот помещении или внутри клетки Фарадея.

Кстати, далеко не факт, что пароль удастся сбросить, даже если вы знаете код блокировки экрана. Политики безопасности и политики MDM, ограничения “Экранного времени” и некоторые другие настройки могут запрещать (внимание!) удаление кода блокировки экрана. Но сброс настроек через пункт Reset All Settings всегда сбрасывает и код блокировки; следовательно, внешние настройки безопасности запрещают использование этой команды. И если с паролем “Экранного времени” можно попробовать что-то сделать, то внешние политики безопасности могут быть вне вашего контроля.

В то же время пароль вовсе не обязательно нужно сбрасывать: его можно попробовать… обойти.

Bypass

More capable low-level extraction methods are available for older devices up to iPhone 8/8 Plus/iPhone X running iOS up to version 15 inclusive, as well as for all devices (including iPhone 8/8 Plus/iPhone X) running iOS versions up to 16.6.1 inclusive (at the time of this writing). For legacy iPhone models, unconditional physical extraction is available regardless of the screen lock. Any of these low-level methods, among other things, will also extract the backup password (from the device’s keychain). While there is no sense in making a new backup after you pull low-level extraction, such passwords may grant access to older backups created.

checkm8 extractions

For iPhone 5s to iPhone 8/8 Plus/iPhone X, you can use forensically sound checkm8 extraction (cheat sheet). Note: if the iPhone 8/8 Plus/iPhone X is running iOS 14 or 15, you’ll also need to remove the screen lock passcode for checkm8 to work. checkm8 extractions are unavailable for iPhone 8/8 Plus/iPhone X devices running iOS 16. In these cases, use the extraction agent instead.

Agent-based extractions

The extraction agent (cheat sheet, installation instructions) works on any iPhone or iPad if the device is running one of the supported iOS versions (currently, all versions from 12 to 16.6.1 inclusive are supported; older versions are supported with checkm8). This is a powerful low-level extraction methods that does not require removing the screen lock passcode.

Ignore

If none of the above worked, there’s only one option left: ignore the password and move on. You can still extract the entire Camera Roll, and you won’t need a password for that. You can also extract system logs, application data, and extended device information without needing the password.

One More Thing

Any low-level extraction method will, among other things, unveil the backup password. Creating a new backup after employing a low-level method is pointless; the backup won’t contain any new data. However, the password can be useful for decrypting existing, older backups found on the user’s computer.

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

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

iOS 16: the new RAM disk format

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

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

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

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

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

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

• iPhone 8, 8 Plus, X (see below for limitations)
• iPad Pro 1, 2
• iPad 5, 6, 7
• Apple TV 4 (HD), 4K (1st gen)
• Apple HomePod (1st gen)

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

iOS 16 checkm8 limitations on the iPhone 8, 8 Plus, and iPhone X (A11)

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

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

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