In this article, we will discuss how to access the hidden port of the first-generation HomePod and extract its file system image. Note that this process requires disassembly, voids the HomePod warranty, and requires specific tools, including a custom 3D-printable USB adapter, a set of screws, and a breakout cable. Therefore, this method is not recommended for casual users and should only be used by professionals who have a thorough understanding of the process.

Background

Introduced in early 2018, the HomePod is Apple’s smart speaker that has been designed to offer a superior audio experience while featuring a smart assistant, Siri, that helps users manage their daily tasks, listen to music, and control their smart home devices. While the HomePod is known for its sound quality, smart assistant, and tight integration into the user’s Apple ecosystem, it also contains valuable information that experts may want to access.

The first-generation HomePod is based on the Apple A8 chip, which is the same chip found in the iPhone 6. This chip is vulnerable to the checkm8 exploit, which makes the first-generation HomePod a potential source of digital evidence during forensic investigations. Just like the Apple TV, the HomePod cannot be protected with a passcode, which makes it a relatively easy target. Interestingly, the iPhone 6 was never updated beyond iOS 12.x, while the HomePod runs the latest OS version (currently 16.3.1). The OS is very similar to tvOS; we’ll discuss it in the next article.

Prerequisites

To access the information in the HomePod, you will need all of the following.

1. The original first-generation HomePod that was set up and used for some time (iOS version does not matter).
2. A custom 3D-printable USB adapter to connect the HomePod to a computer. If you build this adapter yourself, you’ll need access to a 3D printer and some soldering skills.
3. Speaking of the computer, you’ll need a Mac. Currently we only support checkm8 on macOS.
4. Elcomsoft iOS Forensic Toolkit 8 to apply the checkm8 exploit, pull and decrypt the keychain and extract the file system image. Did I mention you’ll need a Mac to run it?

Accessing the hidden port

The first-generation HomePod has a communication port hidden under the bottom lid. To access this port, you will need to remove the bottom lid first. The lid is glued in; you will need to heat it with a fan, then use a flat screwdriver. We had to repeat the heating process several times as to not damage the lid.

Before you begin, make sure the HomePod is powered off. Turn the speaker upside down and place it on a piece of soft cloth.

Once the HomePod is upside down, the bottom lid is exposed. The diagnostic port hides under the lid, so we need to remove it to access the port. The lid is held by some glue; you’ll need to heat and peel to take it off. Heat it with an ordinary fan; apply the heat in short sessions to avoid melting. 10 to 15 seconds is enough to start the process.

Then use a flat screwdriver:

Heat again and repeat as many times as needed. Do not rush or you may damage the lid.

Once the lid is gone, you will see the diagnostic port.

This is a combination USB/UART port. Since we don’t need UART for our purpose, we’ll just use a simple 3D-printable adapter to connect to the pins.

We’ve used the simplest 3D printable adapter, which exposes the connections and can be used for USB (only). The complete instructions are available in GitHub – Elcomsoft/homepwn. UART connections are also exposed, but aren’t needed for our purpose. Additionally you will need M2x6 screws and Pogo pins. The ones we used have the following properties:

• 1.02 mm outer diameter
• 15.8 mm total length
• 1.4 mm pin length (such as these)

Print with the side going into the HomePod facing upwards and print with support. First solder wires to the pins, only then insert them into the adapter (otherwise the 3D printed plastic will melt). Make sure they have a good solder connection, otherwise the USB connection will be very unstable or will not work at all.

Note: if you need UART access, you’ll need to insert two more pogo pins, then connect the two wires to a 1.8v UART to USB adapter. This is not needed for our purposes.

Attach the adapter with four screws:

The seated adapter looks like this:

Connect the wires to the USB breakout cable:

Finally, connect the USB cable to the computer. If your computer only has Type-C ports, you’ll need yet another USB-A to USB-C adapter:

Conclusion

We explained how to access the hidden communication port in the first-generation HomePod. The port is located under the bottom lid, which is glued in place, and requires heating and peeling to remove it. Once the lid is removed, the diagnostic port is visible, which is a combination USB/UART port. We’ve provided instructions for creating a simple 3D-printable adapter to connect to the pins and access the USB port. At this point, you’ve successfully pwned the HomePod and connected it to the computer. We’ll talk about the data in the next article.

Dictionary attacks are among the most effective ones because they rely on the human nature. It is human nature to select passwords that are easily memoizable, like their pet names, dates of birth, football teams or whatever. BBC counted 171,146 words in the English dictionary, while a typical native speaker (of any language) knows 15,000 to 20,000 word families (lemmas, or root words and inflections). Whatever the attack speed is, it will not take too much time to check all the English words.

There is a difference between a ‘dictionary’ and a ‘wordlist’. Even simple passwords are not always “words” from the dictionary but may be also common combinations (like “qwerty”) and abbreviations (like “ROFL&SMC”). Several wordlists are included with Elcomsoft Distributed Password Recovery, and of course you can use your own; you can find many collections in the public domain or order specific dictionaries from the manufacturer.

Is there a difference between a common wordlist and an optimized dictionary?

Dictionary optimizations

A dictionary can be optimized to increase the probability of finding a password at the beginning of the attack. One way to optimize a dictionary is using a specific order of word entries. For example, one may place the most commonly used words at the top of the list (e.g. English Word Frequency | Kaggle), while less frequently used words could be placed lower down the list.

Our tools use a different sorting scheme. Dictionaries provided with Elcomsoft Distributed Password Recovery are optimized for our software to deliver the fastest attacks. The dictionaries of natural languages and many specialized dictionaries we provide are sorted by the length of the entries; the shortest words are placed at the top of the list, while the longest entries are at the bottom of the dictionary. We chose this sorting because of the particular implementation of mutations in Elcomsoft Distributed Password Recovery; this may not be optimal for password recovery tools made by other vendors. Dictionaries of leaked passwords, on the other hand, are always sorted by popularity.

If you are composing your own dictionary, you may want to optimize it for your password recovery tasks. We recommend using frequency sorting for dictionaries composed of leaked passwords (e.g. “Top-100”, “Top-10000” and so on). If using dictionaries of natural languages, we only recommend frequency sorting if you are not using mutations. If using mutations, ordering entries by their length is more efficient.

Dictionary types

The dictionaries can be grouped as follows.

Common passwords. These dictionaries contain passwords that are common in certain communities or language groups. The “Top-100”, “Top-10000”, various lists of leaked passwords and similar dictionaries belong to this group. We recommend using these dictionaries for all attacks.

Specific dictionaries. Various argot and slang dictionaries (e.g. the “hacker’s slang”), dictionaries of common names and landmarks belong to this group. We only recommend using these dictionaries if you know that the user could be setting a password belonging to that specific group (e.g. after analyzing their existing passwords).

Dictionaries of natural language. These can be common English words or words that belong to the user’s native language. Various transliteration dictionaries for non-Latin alphabets also belong to this group. These dictionaries can be used for all types of attacks.

The use of mutations

You may or may not want to enable mutations depending on the dictionary used. For example, when using a dictionary that belongs to the “specific” or “natural language” group, mutations do come handy as they account for the common password variations (e.g. appending one or more digits to the end of the password or varying the letter case). On the other hand, dictionaries of common passwords do not benefit from enabling mutations because they already contain the final modifications of dictionary words (of course if the password is based on a certain dictionary).

There are two major types of mutations: generic and specific.

We recommend using generic mutations for all types of attacks as these are commonly used when composing passwords. For example, the most common mutation turns a dictionary word “password” into something like “Password1”, capitalizing the first letter and adding a digit to the end. Generic mutations are especially handy for cold attacks.

Specialized mutations, on the other hand, are in general rarely used. A good example of such mutations is a “l00p” mutation that transforms ordinary dictionary words into “hacker’s slang”. We only recommend using these specific mutation algorithms when you have reasons to believe that the user might have composed their passwords in that specific manner.

Using free dictionaries

If you were wondering if you can use a text dictionary or wordlist obtained from the Internet to set up a password recovery attack, you most certainly can. However, you have to make sure that the dictionary is converted to a supported format (see below). If you are going to use mutations, we recommend making all entries lower-case; this does not apply to dictionaries of common passwords. You may further improve performance by optimizing the dictionary for the particular password recovery tool. The following settings are applicable to Elcomsoft Distributed Password Recovery.

For common and specialized dictionaries:

• Save the dictionary as a “.udic” text file. The file must be using the Unicode LE (little-endian) encoding.
• Deduplicate.
• Make all entries lower-case.
• Sort entries by their length. The shortest words should be placed on the top of the list, while longer words should be at the bottom.

If you are using a password comprised of existing passwords, use a different workflow.

• Save the dictionary as a “.udic” text file. The file must be using the Unicode LE (little-endian) encoding.
• Do not change the case of the entries.
• Sort entries by popularity. Entries that show up more frequently should be placed on the top of the list, with less popular entries at the bottom.
• At this point, deduplicate.

Making a custom dictionary

You can create custom dictionaries for your circumstances. For example, a custom dictionary may contain a list of phone numbers, dates, document numbers, names of family members or pets of a given user, and any other personal information that might have been used as part of a password.

We recommend treating such passwords depending on whether or not you are planning to use mutations. With no mutations, the order of entries does not affect the recovery speed; you may want to place the more common passwords closer to the top of the list.

If, however, you are making a password based on natural words, you may need to use mutations to produce realistic passwords. In this case, we recommend lower-case conversion and sorting (see previous chapter).

If possible, try keeping the size of the dictionary within limits. About 10,000 entries make a good dictionary that can be realistically used on most data formats together with the most common mutations. A significantly larger dictionary will likely choke the attack if you use any but the most basic mutations.

Finally, Elcomsoft Distributed Password Recovery supports attacks that combine entries from two dictionaries. The two dictionaries can be different, or they could be the same dictionary; in the latter case the passwords will be produced as two-word combinations from that dictionary. Please note that if you use two dictionaries the number of passwords to try will be the multiple of the two.

Specifications

Elcomsoft Distributed Password Recovery supports dictionaries that conform to the following specifications.

• Format: text file, with one entry per line.
• Encoding: Unicode LE (little-endian). Do not use ANSI or UTF-8 dictionaries as they are not supported.
• Case: lower-case entries if you plan to use mutations; original case if you don’t.

Conclusion

Dictionary attacks are among the most effective ways to crack passwords due to human nature. Most users tend to use easily memorable passwords that are based on words that can be found in  a dictionary, making these attacks faster and more likely to succeed. There are different types of dictionaries, and choosing the right one and optimizing it correctly can cut the time of an attack severely while improving the success rate. Mutations can also be used to further increase the chances of finding a password while increasing the time required to run the attack. While free dictionaries from the internet can be used, they must be converted to a supported format and optimized for the specific password recovery tool being used. By understanding the various types of dictionaries and mutations, one can better plan and execute successful password recovery attacks.

In the previous article we discussed the different methods available for gaining access to encrypted information, placing password recovery attacks at the bottom of the list. Password recovery attacks are one of the methods used to gain access to encrypted information. In this article we’ll discuss the process of building a password recovery queue. Learn how to choose the appropriate workflow for the attack, the first prioritizing files with weaker protection, the second prioritizing faster and shorter attacks, and the third being a combination of the two. For your reference, we built a table to compare the relative strength of different file formats and encryption methods, helping users prioritize their attack queues.

Building the password recovery queue

The password recovery workflow consists of an ordered queue of individual jobs. Each job specifies a single attack on a single file. You may set up a queue consisting of multiple attacks on a single file, or attack multiple files. For example, your queue may look like this:

Workflow 1:

File #1
------ Attack #1
------ Attack #2
------ Attack #3
File #2
------ Attack #1
------ Attack #2
------ Attack #3
File #3
------ Attack #1
------ Attack #2
------ Attack #3

When you opt for the first workflow, files with the weakest protection should be on the top of the queue, while formats with the slowest attacks should be placed at the bottom. This workflow prioritizes files with weaker protection over faster and shorter attacks. However, you can also set up the queue like this:

Workflow 2:

File #1
------ Attack #1
File #2
------ Attack #1
File #3
------ Attack #1
File #1
------ Attack #2
File #2
------ Attack #2
File #3
------ Attack #2
File #1
------ Attack #3
File #2
------ Attack #3
File #3
------ Attack #3

If you opt for the second workflow, the queue will be ordered with the shortest attacks first, while longer and time-consuming attacks take the bottom of the list. This workflow prioritizes faster and shorter attacks over weaker protection.

Of course, nothing should stop you from combining the two approaches. For example, a classic example of Workflow 1 may look like this:

Newdocument.docx
------ Dictionary attack top-10000
------ Digit only passwords (1-6 digits)
------ Dictionary attack with mutations English.dic
------ Dictionary attack with mutations Spanish.dic
------ Brute force attack (1-8 characters)
Expenses.xlsx
------ Dictionary attack top-10000
------ Digit only passwords (1-6 digits)
------ Dictionary attack with mutations English.dic
------ Dictionary attack with mutations Spanish.dic
------ Brute force attack (1-8 characters)

However, the brute force attack on the first file may take forever, while a dictionary attack may end in reasonable time. You may want to modify your attack with an element of the second workflow, in which case your password recovery queue may look like this:

Newdocument.docx
------ Dictionary attack top-10000
------ Digit only passwords (1-6 digits)
------ Dictionary attack with mutations English.dic
------ Dictionary attack with mutations Spanish.dic
Expenses.xlsx
------ Dictionary attack top-10000
------ Digit only passwords (1-6 digits)
------ Dictionary attack with mutations English.dic
------ Dictionary attack with mutations Spanish.dic
Newdocument.docx
------ Brute force attack (1-8 characters)
Expenses.xlsx
------ Brute force attack (1-8 characters)

Notice that in the second example we moved the most time-consuming attack (the brute-force) to the bottom of the queue for both files. This makes sense if the files in the queue have similar encryption strength. However, if there is a big difference in attack speeds between the files, you may have a better chance of success with the first type of workflow, placing the weakest protected files on top of the queue.

Choosing the right workflow

Which of the two workflows should you choose when attacking a password? We have already discussed the “low hanging fruit” strategy (e.g. May the [Brute] Force Be with You!) where you would generally target data formats protected with weakest encryption. There is another side to “low hanging fruit”: attempting short, limited-time attacks on other formats before launching a longer attack on the weaker formats. Generally, you would place the fastest and shortest attacks on the top of the queue, with longer, time-consuming attacks taking the bottom of the list. The “Top-10000 passwords” attack will be fast on nearly every format. A dictionary attack with mild mutations may be already too slow on some formats but still meaningful on the others. To help you prioritize your password recovery queue we built a table comparing the relative strength of the different formats. WinZIP AES-256 will be the point of reference with the value of “1”. Attacks on NTLM passwords are nearly 45,000 times faster on the same hardware, while attacks on RAR5 archives are almost 10 times slower.

This table demonstrates that if you have a mix of files and hashes to break, it might be beneficial to attack NTLM passwords and individual hashes first if they are parts of the queue, making it a Workflow 1. If, however, you have a bunch of ZIP and RAR archives as well as a number of Microsoft Office documents, their relative protection strength is so close that you may ignore this factor and set up the attack as demonstrated in the Workflow 2.

The practical steps

Considering the above, we recommend setting up the following attack pipeline in Elcomsoft Distributed Password Recovery.

1. Use Top 10,000 password list and set up a straight dictionary attack as shown here:
2. Add a digit-only attack. Limit the length of the passwords to 8 digits (for formats with stronger protection limit to 6 digits).
3. Make use of the dictionary of English language followed with an attack based on the dictionary of your local language. Configure the attack using medium mutations as shown below:
4. If none of that worked, estimate your chances with a brute-force attack. You may still use masks and rules to throw out some very random passwords.

Conclusion

The password recovery process involves a queue of sequential jobs, each job representing a single attack on a single file. The queue can be set up in many different ways. We recommend one of the two setups: you can place the multiple attacks on a single file first, or attack multiple files with multiple attacks, placing the fastest and shortest attacks at the front of the queue.

The choice of workflow depends on the relative protection strength of files and hashes to be broken. A table comparing the relative strength of different formats will help prioritize the password recovery queue. In the first workflow, files with the weakest protection are placed on the top of the queue. Then, for each file, the fastest and shortest attacks are placed at the top, while longer and time-consuming attacks take the bottom of the list. In the second workflow, the most time-consuming attacks are moved to the bottom of the queue for all files. Ultimately, the choice of workflow will depend on the specific mix of files and hashes to be broken and their relative protection strength.

1. checkm8 (if compatible)

checkm8 extraction is the first process to consider if one is supported by the device. If successful, do not use any other extraction methods (except cloud extraction).

The reason for prioritizing checkm8 as the first extraction method is that it’s the only forensically sound extraction method that our extraction tools support. By utilizing checkm8, the content of the device remains unchanged, and subsequent extractions will be identical to the first one, which can be verified through matching checksums. Conversely, using any other extraction methods will lead to changes in the data partition that can’t be avoided, resulting in subsequent extractions no longer being 100% identical.

This extraction method (as well as the extraction agent and extended logical acquisition) are supported in iOS Forensic Toolkit.

Detailed instructions: checkm8 Extraction Cheat Sheet: iPhone and iPad Devices

2. Extraction agent (if compatible and device not supported by checkm8)

Next, consider using the extraction agent. If successful, do not use any other extraction methods (except cloud extraction).

The reason for ranking the extraction agent as the next best method after checkm8 is that it’s a safe and reliable option to extract data that extracts the full file system image and decrypts all keychain records including those that cannot be decrypted by analyzing a local backup.

If a device is compatible with both checkm8 and the extraction agent, it’s recommended to use checkm8 first. However, if the extraction agent supports the version of the operating system installed on the device, it should be utilized instead. In the event that neither checkm8 nor the extraction agent is supported, logical extraction is the recommended method.

Detailed instructions: iOS Forensic Toolkit 8 Extraction Agent Cheat Sheet

3. Logical extraction (local backup)

Make a local backup even if you don’t know the backup password.

It’s recommended to create a backup of the device “as is” first to preserve its original state. If necessary, the backup password can be reset in the device settings. However, resetting the backup password has serious forensic implications, such as the removal of the screen lock passcode. This, in turn, affects the device’s trust in iCloud and prevents access to end-to-end encrypted data for cloud extraction. Additionally, some types of data, such as Apple Pay data and transaction history, may be deleted from the device. If there’s no backup password, a temporary backup password of “123” can be assigned to access otherwise inaccessible types of data, like the keychain.

Detailed instructions: Advanced Logical Extraction with iOS Forensic Toolkit 8: Cheat Sheet

4. Extended logical extraction

The reason for performing an extended logical extraction is that it allows for the extraction of additional types of data, even if the backup password is set. For instance, using the “advanced logical” process to extract media files will not only return the media files themselves but also provide detailed metadata. This metadata can be useful in gaining more information about the extracted media files, such as album names, people and object recognition results, location data, and mode. In addition, metadata may contain information about deleted media that is no longer present on the device. Therefore, conducting an extended logical extraction can yield more comprehensive results, making it one of the preferred methods for data extraction.

Detailed instructions: Advanced Logical Extraction with iOS Forensic Toolkit 8: Cheat Sheet

5. Unknown backup password

We strongly suggest performing a risk assessment when encountering a backup protected with an unknown password. In the event that the password cannot be recovered with a brute-force or dictionary attack, you may be able to perform a soft reset by using the “Reset All Settings” command in the Settings app that also removes the backup password. However, it’s important to note that resetting the backup password also results in the removal of the screen lock passcode, which has significant forensic implications. After resetting the backup password, repeat the logical extraction process to obtain the data stored in the backup.

Please note that the chance of recovering the backup password with a brute-force or dictionary attack is low as the encryption used by Apple for backups is extremely robust; it may take a lot of time to break  even when using a powerful GPU accelerator. Given that a local backup may contain valuable evidence, it’s essential to exhaust all available options before considering the password unrecoverable.

Detailed instructions: iCloud backups: the Dark Territory and iOS Backups: Leftover Passwords

6. Cloud extraction

Apple offers by far the most sophisticated solution for backing up, restoring, transferring and synchronizing data across devices belonging to the company’s ecosystem. Apple iCloud can store cloud backups and media files, synchronize essential information between Apple devices, and keep highly sensitive information such as Health and authentication credentials securely synchronized.

Apple iCloud contains information belonging to several different categories, and you will require a different set of credentials to access some of these data.

For backups and synchronized data, you will need all of the following:

• The user’s Apple ID and password.
• A way to pass two-factor authentication (you can use one of the user’s trusted devices or a SIM card with a trusted phone number).

To access end-to-end encrypted data including iCloud Keychain containing the user’s stored passwords, you will need the following in addition to the above credentials:

•  A password or screen lock passcode to one of the user’s trusted devices.

Cloud extraction can be performed with Elcomsoft Phone Breaker.

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

Conclusion

When it comes to obtaining evidence from Apple devices, using the right extraction methods in the right order is essential to ensure admissible results.

If the device is compatible, go with the checkm8 extraction method. it is the only forensically sound way to access the data, and using it will not alter the content of the device.

If checkm8 is not an option, consider another low-level acquisition option using the extraction agent. This one will return a full file system image and access to keychain records, even the ones that cannot be accessed by analyzing a local backup.

If neither of those work out, resort to the logical extraction. Be sure to create a backup of the device “as is” first, then try resetting the backup password to get access to the data. Extended logical extraction comes next, as it can extract additional types of data, even if the backup password is set.

If you’re dealing with an unknown backup password, first, try brute-force or dictionary attack to recover it, but chances are low that it will work. If all else fails, you can always do a soft reset and start over.

Last but not least, you could always try cloud extraction, but be warned that there are some risks involved with that method.

Overall, following these guidelines will help you get that data accurately and reliably, without damaging or altering it.

 

Access to encrypted information can be gained through various methods, including live system analysis (1 and 2), using bootable forensic tools, analysis of sleep/hibernation files, and exploiting TPM vulnerabilities, with password recovery being the last option on the list. Each method has different resource requirements and should be used in order of least resource-intensive to most time-consuming, with password recovery as the last resort. Familiarize yourself with the different encryption recovery strategies and learn about data formats with weak protection or known vulnerabilities.

Why password recovery is your last resort

When presented encrypted evidence, one’s immediate thought is “I need to break a bunch of passwords”. However, decrypting protected information by recovering the original plain-text password is the most straightforward approach, but also the least efficient one. Since most encryption formats are designed to withstand password attacks with hundreds thousands rounds of hashing, the time required to break even a simple password could be days, months, or years. In real life, the chance of successfully breaking encryption by attacking passwords is low. For example, the authors of When Encryption Baffles the Police: A Collection of Cases describe as many as 55 criminal cases that involved data encryption. In 17 cases, encryption was fully or partially broken, which results in an approximately 30% success rate.

You may be able to improve this success rate by employing alternative techniques to decrypt information other than attacking plain-text passwords. If access to encrypted digital evidence takes precedence over retrieving the plain-text password (which is not always the case, e.g. Windows Account Passwords: Why and How to Break NTLM Credentials), a number of more efficient solutions may be available. The recovery methods for accessing protected pose very different resource requirements such as the time spent by the expert to set up the attack, and the time required to carry out the attack. We recommend trying the least resource-intensive methods first and only resorting to more time-consuming methods (such as brute force) when all other options have been exhausted. The following are our preferred recovery methods:

1. Encrypted disks and virtual machines: Live system analysis. This method, if available, enables the retrieval of binary encryption keys and/or imaging of the file system of a mounted disk without the need for lengthy brute-force attacks.
2. Live system analysis: If you have access to an authenticated user session, make the most of it before shutting down the computer. Even if full-disk encryption is not used, some data (such as DPAPI-protected items) will only be accessible when the user signs in with their password. DPAPI-protected items include passwords saved in web browsers (Chrome, Edge, etc.), passwords for network shares, keys, tokens, and certificates.
3. Computer in sleep/hibernation: Analyze page/hibernation files for disk encryption keys (using Elcomsoft Forensic Disk Decryptor). Keep in mind that volatile virtual machine images may also be stored in RAM.
4. Consider using bootable forensic tools (such as Elcomsoft System Recovery) to quickly image built-in storage media and extract encryption metadata.
5. BitLocker disks: Consider using TPM vulnerabilities to unlock the BitLocker boot drive before removing storage media for imaging.
6. Encrypted disks: Analyze hibernation and page files with Elcomsoft Forensic Disk Decryptor (searching for encryption keys). An authenticated user session is not necessary for this analysis.
7. Some data formats have weak protection or known vulnerabilities. Familiarize yourself with these formats (such as Microsoft Office documents saved in legacy formats like .doc/.xls instead of .docx/.xlsx); e.g. Decrypting Password-Protected DOC and XLS Files in Minutes.
8. Use the “low hanging fruit” strategy and prioritize files with weak protection.
9. Password recovery. This should only be used as a last resort, but you may have options such as a smart attack and/or custom dictionaries made up of the user’s other passwords (for example, extracted from the keychain/web browsers).

More information:

• What is Password Recovery and How It Is Different from Password Cracking
• A Bootable Flash Drive to Extract Encrypted Volume Keys, Break Full-Disk Encryption
• How Long Does It Take to Crack Your Password?
• How to Break 70% of Passwords in Minutes

 

On January 23, 2023, Apple have released a bunch of system updates that target the different device architectures. iOS 16.3 is available for many recent devices, while older models were updated to iOS 12.5.7, iOS 15.7.3 and iPadOS 15.7.3 respectively. While Elcomsoft iOS Forensic Toolkit supported these versions of the system from the get go, today we are rolling out an update that irons out minor inconveniences when imaging such devices.

iOS, iPadOS and tvOS 16.3 are available for multiple Apple devices, yet only a handful of them are affected by the bootloader vulnerability utilized in the checkm8 exploit. While Apple only release iOS 16 for the iPhone 8, 8 Plus, and iPhone X, many more devices received iOS 16 update even when built with an older SoC. A good example is the Apple TV HD (Apple TV 4), which are built on the Apple A8 chip used in the iPhone 6 (which, in turn, did not receive major system updates beyond iOS 12.x).

In addition, Apple rolled out security patches to older devices. iOS 12.5.7 targets devices based on the Apple A7, A8, and A8X chip sets, which includes the iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation), while iOS 15.7.3 and iPadOS 15.7.3 target devices based on the A9/A9X and A10/A10X chip sets, which includes the iPhone 6s and iPhone 6s Plus, iPhone 7 and iPhone 7 Plus, iPhone SE (1st generation), iPad Air 2, iPad mini (4th generation), and iPod touch (7th generation).

As we have previously posted in Apple Releases iOS 12.5.7, iOS 15.7.3. What About Low-Level Extraction?, iOS Forensic Toolkit utilizes an extremely robust extraction process that is almost OS-agnostic. Our implementation of the checkm8 extraction process survives through minor iOS updates such as iOS/iPadOS 15.7.3, and supports most public and developer pre-release versions of iOS/iPadOS. However, there is a minor inconvenience when using the checkm8 process with a version of iOS/iPadOS that is not yet known to iOS Forensic Toolkit.

The fixed inconvenience

Our checkm8 extraction process does not require us redistributing any parts of Apple proprietary code. Instead, the tool will request the end user to download the original firmware image from Apple, which will be used to boot the device. The tool displays a list of download links at some point of applying the exploit; the URLs depend on the hardware and version of iOS installed on the device. In some cases detecting the exact iOS build based on the iBoot version is impossible as some versions of iOS use the same iBoot. If this happens, the tool lists several download links to potential matches.

The inconvenience is this: if the device runs a version of iOS that iOS Forensic Toolkit does not know anything about, the correct download link will not be displayed. There are two possible solutions. First, one can try using the best match (the iOS build that is closest to the installed OS). This may or may not work. If it doesn’t, the device may simply reboot (learn how to deal with accidental reboots); in this case one can find the installed OS version in the log. Alternatively, one can manually look for the matching .ipsw image on Apple Web site and simply pass the URL as an argument when prompted. Yet another way is downloading the required .ipsw file and using the downloaded firmware image instead.

Things get a bit easier if iOS Forensic Toolkit knows about the installed version of iOS. In this case, the correct download link will appear on the list of potential matches. One can simply copy the right URL and paste it into the prompt, or download the firmware image and use its local path as an argument.

TL&DR: support for iOS/iPadOS 16.3, 15.7.3, and 12.5.7 added, download links correctly displayed, inconvenience solved.

The extraction agent

The checkm8 extraction utilizes a hardcoded vulnerability in the bootloader to obtain the highest possible privilege level on affected devices. The vulnerability exists in multiple generations of Apple devices up to and including the A11 generation (the iPhone 8, 8 Plus, iPhone X, and other Apple devices built on similar SoC). iOS 16 effectively mitigates the vulnerability for the iPhone 8, 8 Plus, iPhone X, which makes the checkm8 extraction ineffective on these iPhones.

For all newer devices a different extraction method can be used. We developed an in-house extraction agent,  which is a small app that, once sideloaded onto a device, attempts privilege escalation by exploiting system vulnerabilities. The agent returns pretty much the same set of data as the checkm8 process, which includes the full file system image and keychain. While the extraction agent is device-agnostic, it is limited to certain versions of iOS for which a kernel exploit is available, which is currently iOS 15.5 and older.

Apple TV and Apple Watch

Apple Watch и Apple TV are also supported by our checkm8 extraction process. iOS Forensic Toolkit is the only tool on the market that supports checkm8 on Apple TV and Apple Watch devices. While the Apple TV and Apple Watch devices use identical or similar SoC to other models from the Apple ecosystem, there are important differences that must be taken care of. The latest version of iOS Forensic Toolkit takes care of extraction issues with the Apple TV HD (aka Apple TV 4) running iOS 16. This model is based on the A8 SoC, which is identical to the SoC used in the iPhone 6, and runs a forked version of iOS 16. It is interesting to note that the iPhone 6 and 6 Plus devices do not support iOS 16, while the Apple TV HD (Apple TV 4) does. This in turn means that we had to adapt the checkm8 extraction process specifically for this platform, without a corresponding iPhone device.

In addition, we fixed checkm8 extraction on the Apple Watch S3, a device that set a record on being the longest Apple Watch model available for sale.

Discover the benefits of agent-based data extraction from iOS devices. Learn about the purpose and development of the extraction agent, when it can be used, and best practices. Get a comprehensive understanding of the cutting-edge approach for iOS data extraction.

The Extraction Agent: An Overview

The extraction agent represents a cutting-edge approach of extracting data from iOS devices. Initially developed as a safer and more reliable alternative to jailbreaking, agent-based extraction provides risk-free low-level access to the device and enables full file system extraction and keychain decryption. This method offers improved speed and accuracy while making no changes to system partitions and leaving minimal traces on the data partition. After the extraction, the agent can be easily and completely removed with one command, the only traces left on the device being several entries in the system event log.

To better explain the benefits of the extraction agent, let us look back several years. Back in the days, file system extraction and keychain decryption were largely carried out through publicly available jailbreaks. However, this approach was not ideal as it was risky to the device, posed a threat to the data integrity and was far from being forensically sound.

To address these issues, in early 2020 we developed an alternative solution. Instead of a jailbreak, this new approach utilizes a small app, the “extraction agent”. The agent combines known exploits to escalate privileges, access the file system, and decrypt the keychain content. Compared to jailbreak-based acquisition, the extraction agent offers numerous benefits, including increased safety, speed, and robustness.

How It Works

iOS employs numerous protections to keep apps within sandboxed space. Third-party and system apps can only access data in their own sandboxed space, and gain access to limited information explicitly shared by other apps. This, for example, means that the Files app, which is a system app introduced in iOS 11, cannot and does not have access to the full file system of the user data; in this example, users of the Files app won’t have direct access to files produced by e.g. Signal or Telegram messengers (unless the user opens the messenger app and shares a chat comment or attachment from within the messenger itself).

Low-level access to the file system is strictly forbidden to apps running in the user space. However, apps with a higher privilege level can access the entire file system, including files stored in other apps’ sandboxes. Obtaining a higher privilege level requires privilege escalation, which is not permitted by the iOS security model. For this reason the extraction agent obtains privilege escalation by exploiting kernel-level vulnerabilities in parts of the operating system. To do that, the agent packs a large number of known exploits. When launched on an iOS device, it detects the OS version and attempts to apply a compatible exploit. If successful, the extraction agent gains access to the file system and establishes a communication channel between the device and the expert’s computer, which in turn allows the expert to image the file system with iOS Forensic Toolkit.

Although the concept may seem straightforward, it is significantly more complex than meets the eye. A kernel exploit alone is not enough to access the file system, while decrypting keychain records always requires additional work. We strive to keep iOS Forensic Toolkit updated to allow both file system extraction and keychain decryption for all supported iOS releases without gaps and exclusions.

Better than checkm8?

The extraction agent works in a different manner and is supported on a different range of devices. While checkm8 extraction is compatible with devices built with certain Apple chips, the extraction agent is hardware-agnostic, even supporting devices based on Apple Silicon (M1) chips. On the other hand, the extraction agent supports a limited range of iOS versions, while checkm8 is mostly (but not entirely) OS agnostic.

checkm8: devices based A5…A11 chips; most iOS versions; does not work on A11 iPhones with iOS 16. Requires a Mac.

agent: devices based on any hardware platform if running iOS 6 through iOS 15.5. Requires an Apple Developer account (or a Mac for a workaround).

The checkm8 extraction process is only available for older Apple devices that have a hardcoded vulnerability in their bootloaders. The newer chips starting with Apple A12 (the iPhone Xs/Xr generation) are not affected, which makes checkm8 extractions unavailable for those newer generations of devices.

For older devices that are compatible with checkm8, we recommend using the checkm8 extraction process. For newer devices, you won’t have such an option. Instead of targeting the hardcoded bootloader vulnerability that no longer exist in these newer devices, the extraction agent leverages kernel-level vulnerabilities in various parts of the operating system to escalate privileges, escape the sandbox, and access the device’s content at a low level.

The Current State of Agent-Based iOS Extraction

The extraction agent is currently compatible with all iOS releases up to iOS 15.5 on all iOS/iPadOS devices. Windows users require an Apple Developer account to use the agent, while macOS users are recommended to have one. To perform an extraction, the device’s screen lock password must be known or absent. If the device is running a compatible version of iOS and the screen lock password is known, it is highly recommended to use the iOS Forensic Toolkit extraction agent for all data extractions.

The Practical Guide

There are several steps to using the extraction agent. First, make sure you want to use the agent as opposed to (or in addition to) other extraction methods:

• Approaching iOS Extractions: Choosing the Right Acquisition Method

During the second step you’ll need to sideload (install) the extraction agent on the iOS device being extracted. This is a somewhat more complex process than it seems, and you may need to enroll your Apple account into Apple Developer Program. If you have a developer account with Apple, sideloading the extraction agent is easy. If you don’t, you’ll have to use a risky workaround.

• iOS Low-Level Acquisition: How to Sideload the Extraction Agent

If you managed to sideload the extraction agent, launch it on the device by tapping its icon, and keep the app running in the foreground until the extraction is finished. The extraction steps are described in the following short manual:

• iOS Forensic Toolkit 8 Extraction Agent Cheat Sheet

Finally, remove the extraction agent by either uninstalling it from the device in a regular way or by issuing a command (refer to the Cheat Sheet above).

What does “forensically sound extraction” mean? The classic definition of forensically sound extraction means both repeatable and verifiable results. However, there is more to it. We believe that forensically sound extractions should not only be verifiable and repeatable, but verifiable in a safe, error-proof manner, so we tweaked our product to deliver just that.

TL&DR

During checkm8 extractions of supported iOS/iPadOS devices, iOS Forensic Toolkit 8 automatically disables auto-boot behavior of the device, which ensures that the device boots into Recovery on subsequent power-on and restart events. The flag is stored in the device’s NVRAM and is not automatically removed even between reboots and power-offs. Experts must manually set auto-boot to True before releasing the device to its owner; otherwise a “broken device” complaint is more than likely.

Forensically sound extractions must be verifiable

Forensically sound extractions must deliver results that are both repeatable and verifiable. Forensically sound extraction methods are designed to preserve digital evidence from the first point of data collection and establish chain of custody to ensure that digital evidence collected during the investigation remains court admissible.

First and foremost, a forensically sound extraction must deliver results that can be securely verified. Verifiable results prove authenticity of the extraction, certifying that the data obtained from the device had not been manipulated post extraction.

To do that, experts routinely document the extraction process, producing and saving (sometimes on paper) a digital signature, hash or checksum of the extracted data. The use of hashing at the time of extraction helps establish digital chain of custody, producing results that can be verified in the future. Our low-level extraction tool, Elcomsoft iOS Forensic Toolkit, calculates a cryptographic hash value that can be used to validate the image’s authenticity later on. We published a quick how-to guide in the following article: Forensically Sound Extraction for iPhone 5s, 6, 6s and SE. In addition, check out checkm8 Extraction Cheat Sheet: iPhone and iPad Devices.

Applicability: when it comes to mobile forensics, all extraction methods including logical acquisition can be made verifiable. However, only select few methods can deliver repeatable results; see next chapter.

Forensically sound extractions must be repeatable

A file system image can be checked against its hash value to prove the data had not been manipulated with after the extraction. What about a proof that the data was extracted from a particular device? A second extraction can be performed from the same device. The “repeatable” part means that any subsequent extraction from the same device shall match all previous extractions. To prove that the two data sets match, one can calculate the hash values of the new extraction and compare it with the hash value of the originally extracted data. Due to the nature of cryptographic hashes, even a single flipped bit in the data results in a drastically different hash value. If the hashes do match, you can be sure that the two images are identical.

Applicability: for iOS devices, only bootloader-based extractions (such as the checkm8 extraction method implemented in Elcomsoft iOS Forensic Toolkit) can deliver repeatable results. Note that not every checkm8-based extraction is repeatable depending on your workflow and the choice of tools.

Our checkm8 solution delivers forensically sound extractions; subsequent images will match the original if the device itself was not allowed to boot into iOS between extractions. Which, in turn, is more of a problem than we initially expected.

Repeatable extractions aren’t that easy

When the device boots into the installed OS, it inevitably makes multiple modifications into the user partition. Even if the device is isolated from all wireless networks, and even if it is not unlocked after a restart, iOS will add records to log files and change multiple timestamps. As we know, flipping a single bit in the dataset will result in a very different hash value being computed. The two images will no longer match.

Why would one allow the device to boot into iOS in the first place? Often, this happens as an accident. Placing iOS devices into DFU is a tricky process that requires precise timings. Press a button for too long or too short, and the device may start booting into the system. Since repeat extractions may be handled by a different expert, such an outcome is more than likely.

We tried to make the extractions more secure by offering an option that alters the boot behavior of iOS devices.

Our solution: flipping the ‘autoboot’ flag

First and foremost, experts can manually flip the ‘autoboot’ flag with the following command executed while the device was in Recovery:

./EIFT_cmd tools autobootFalse

Once executed, this command modifies device behavior during the boot sequence. If the device is powered on or if the device is restarted, with ‘autobootFalse’ it will load the Recovery instead of the main OS. Booting into recovery is safe as nothing in the user data is modified. The flag is stored in the device’s NVRAM, and survives reboots and power-offs.

We suggested keeping the device in the ‘autobootFalse’ state until the moment the device was released and returned to the owner, in which case another command would restore the ability to boot iOS:

./EIFT_cmd tools autobootTrue

Note that iOS Forensic Toolkit 8 automatically sets auto-boot value to False at some point after sending iboot, but before sending kernel and booting the ramdisk.

This behavior effectively secures the user data against accidental modifications caused by user error when entering DFU. An important consequence: the device will have the ‘autobootFalse’ flag still enabled after you finish the extraction. This means that any subsequent power-on or reboot will make the device launch Recovery instead of starting the installed operating system. We recommend keeping this flag enabled all the time while the device is retained as evidence, and only reverting to ‘autobootTrue’ immediately before the device is returned to its owner.

What happens if the expert does not reset the autoboot flag? In this case, the owner will receive an unbootable device that constantly boots into Recovery. This is not the original working state of the device, and one may receive a complaint. The situation is easily avoidable: simply use the ‘autobootTrue’ command prior to returning the device to its owner.

The auto-boot flag and forensically sound extractions

Flipping the auto-boot flag does not affect the forensically sound status of the extraction for two reasons.

1. The user data is not affected.
2. The system partition is not affected because the flag is stored in the device’s NVRAM.

Regardless, experts should always request permission to modify device content. checkm8 extractions are not always possible, while all other extraction methods alter the content of the device in one way or another.

If the battery is depleted

If the device is off and the battery is discharged below a certain minimum level, then plugging it into a charger will trigger the boot sequence. To keep the data intact, we need to ensure that the device boots into recovery as opposed to loading the operating system.

You can press and hold the Home button (or side button on the iPhone 8, 8 Plus, iPhone X), then plug in the charger and keep holding it until you reach recovery.

However, on fully discharged devices you’ll go into the battery trap first until the charge is high enough.

Alternatively, you can attempt to place the device from the battery trap to DFU directly. This is a bit tricky on the iPhone 8 generation as the timing needs to be very precise (best to use a stopwatch or a timer), but it’s fairly easy on the iPhone 7 and older.

A DFU boot doesn’t care about low battery and skips the battery trap. Leaving the device in DFU connected to the PC for approximately one minute should be more than enough to boot fine to recovery with iOS Forensic Toolkit. From there, once auto-boot is set to false, you can safely charge the device without the risk of accidentally triggering the boot sequence.

Apple is known for a very long time they support their devices. On January 23, 2023, alongside with iOS 16.3 the company rolled out security patches to older devices, releasing iOS 12.5.7, iOS 15.7.3 and iPadOS 15.7.3. iOS 12 was the last major version of iOS supported on Apple A7, A8, and A8X devices, which includes the iPhone 5s and iPhone 6 and 6 Plus generations along with several iPad models. We tested low-level extraction with these security-patched builds, and made several discoveries.

Low-level extraction methods

Low-level extraction can be done differently. For older hardware, which includes all models affected by the current security releases, the checkm8 extraction delivers the cleanest results. our solution is unrivaled in providing truly forensically sound extractions for all compatible devices, which include a number of iPhone, iPad, Apple Watch and Apple TV devices. checkm8 extractions are great, but they aren’t compatible with newer devices. To deliver low-level extraction for newer iPhones and iPads, we developed an in-house extraction agent that comes as close to being forensically sound as possible. This method is highly dependent on kernel exploits, which are extremely difficult to implement. This is why low-level extraction almost never comes to the current, up-to-date and fully patched versions of iOS. For newer models starting with iPhone Xr/Xs, using the extraction agent is the only way to extract the file system and decrypt the keychain.

iOS 12.5.7: low-level extraction available

iOS 12.5.7 targets devices based on the Apple A7, A8, and A8X chip sets, which includes the iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation). The official release notes only mention a single CVE-2022-42856, which relates to a vulnerability in WebKit. Both the checkm8 and extraction agent methods are available for these devices.

Agent: passed. We tested a device running iOS 12.5.7 with iOS Forensic Toolkit 8, and discovered that our extraction agent is fully compatible the freshly patched iOS release with full file system extraction and keychain decryption support. This means that Apple did not fix the vulnerability that allows our extraction agent to escalate privileges and escape sandbox.

checkm8: passed. We have also tested checkm8 extraction of a device running iOS 12.5.7 with iOS Forensic Toolkit 8; the test passed. Full file system extraction and keychain decryption are both available.

iOS 15.7.3: checkm8 extraction

iOS 15.7.3 and iPadOS 15.7.3 target devices based on the A9/A9X and A10/A10X chip sets, which includes the iPhone 6s and iPhone 6s Plus, iPhone 7 and iPhone 7 Plus, iPhone SE (1st generation), iPad Air 2, iPad mini (4th generation), and iPod touch (7th generation). The list of security patches is longer, and we still not have a way of privilege escalation. However, all device models that received the security patch are built with chips affected by the bootloader vulnerability that can be exploited with checkm8.

checkm8: passed. We have tested checkm8 extraction of iOS 15.7.3 with iOS Forensic Toolkit. Full file system extraction and keychain decryption are both available.

There is a small note: since the current build of iOS Forensic Toolkit was released before iOS 15.7.3, it can neither detect the OS version nor display the correct download link for the iOS 15.7.3 image. As a reminder, our checkm8 extraction requires downloading parts of Apple original firmware in order to boot the device. We’ll add the download link with the next update; meanwhile, you can find the matching .ipsw image on Apple Web site and simply pass the URL as an argument when prompted. Alternatively, you can download the required .ipsw file and use the downloaded firmware image instead.

We strived to make our checkm8 extraction process to be as robust as possible. The extraction process survives through minor iOS updates such as iOS/iPadOS 15.7.3, and supports most public and developer pre-release versions of iOS/iPadOS.

New compatibility matrix

The updated compatibility matrix is published below. We added a note on iOS 12.5.7 agent-based and checkm8 extraction support. checkm8 extraction is supported for iOS/iPadOS 15.7.3, but the extraction agent is not.

The updated iOS Forensic Toolkit 8.11 brings keychain decryption support to devices running iOS/iPadOS versions up to and including the 15.5 by using the extraction agent. The tool supports recent models that can run iOS 15 , which includes devices based on the Apple A12 through A15 Bionic, as well as Apple Silicon based devices built on the M1 SoC.

What’s it all about?

The ultimate goal of a forensic expert is extracting as much data from the device as possible, and the keychain is a true gold mine. While advanced logical extraction is the simplest to use and the most compatible method that supports all devices and all versions of iOS, a low-level approach yields a much better return. In particular, low-level extraction provides access to encryption keys stored in the keychain. These encryption keys can be used to access encrypted chat histories saved by secure instant messaging apps such as Signal, Wickr, Threema, and SnapChat. Naturally, the keychain contains information required to decrypt encrypted Notes saved by the native Apple app.

This time around we are targeting the newer generation of Apple devices that are built with the Apple A12 through A15 Bionic and Apple Silicone (M1) SoC. For older devices such as the iPhone 8/X, we still only support the file system and keychain extraction for iOS 15.3.1 and below, but this is not necessarily bad news as the entire iPhone 8/X generation running all versions of iOS 15.x is covered by checkm8 extraction.

For those newer devices we employ a custom developed extraction agent. The extraction agent is a small app that uses kernel-level exploits to escalate privileges, escape the sandbox and access the content of the device in the low level. It may sound simple, but in fact it is not: a kernel exploit alone is not enough to gain access to the file system, let alone decrypt the keychain. The new build of iOS Forensic Toolkit bumps iOS version support to allow keychain decryption for the all versions of iOS for which the file system extraction is supported, which is currently up to and including iOS 15.5.

What’s inside?

The keychain contains the most essential evidence, which includes passwords to web sites, Wi-Fi access points and mail accounts, passwords to cloud services/accounts, credit card numbers and a lot of encryption keys such as those protecting encrypted conversations in secure instant messaging apps.

Our agent-based extraction method is truly unique. We invented the approach for iOS devices, and we support the widest range of Apple devices and OS versions, including M1-based models. Our agent-based extraction solution is the only one on the market that capable to decrypt the keychain from OS versions up to and including iOS 15.5. For the full list of compatible device models and system versions please refer to the following chart:

There are several methods for recovering the original password ranging from brute force to very complex rule-based attacks. Brute-force attacks are a last resort when all other options are exhausted. What can you reasonably expect of a brute-force attack, what is the chance of success, and how does it depend on the password and the data? Or just “how long will it take you to break it”? Let’s try to find out.

The brute force attack

Encrypted volumes, archives, mobile backups, Microsoft Office documents and other types of data employ secure encryption based on a long encryption key. Attacking binary encryption keys without a currently non-existing quantum computer is pointless, so we have to resort to attacking the original password, which at least gives us a chance of success. Therefore, we’re back to attacking the good old plain-text password to decrypt the data.

In this context, ‘attacking’ a password would mean trying various password combinations to find one that fits. There are different types of attacks. For example, the brute force attack would simply try all possible password combinations starting with “0” and followed with “1”, “2”, …, all the way to “ZZZZZZZZZ” or whatever the last character or special symbol there is instead of the “Z” in the chosen character set.

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 try using words from the dictionary of English language (and/or the user’s native language) as possible passwords. This would commonly include phrases and mild mutations, such as “Password1979” or “LisaPassword1”.

Dictionaries can be built from passwords extracted from other sources (e.g. from Web browsers). ElcomSoft offers a number of tools allowing to extract available passwords from the user’s computer and automatically build a custom dictionary.

So, technically speaking, there are several things affecting how fast you can break the password:

• The number of passwords to try
• Recovery speed measured in the number of passwords we can try per second

Password length and smart attacks

The number of passwords to try depends both on the length and complexity of the password itself as well as on the type(s) of attack we choose to break a given password.

Let’s clear password complexity first. Let’s look at the following charts:

You can see that password recovery speeds vary greatly depending on the data format (more on that later). For Microsoft Office 2013 documents, we can realistically try about 7000 passwords per second if we use a single GPU acceleration unit. What does that mean, exactly? It depends on how many passwords you are about to try.

Using an online password strength meter, we can calculate the exact number of possible combinations for passwords of different length and complexity. A simple password that consists of 6 lower-case letters and no numbers already has 309 million possible combinations. With a computer equipped with a GTX 1080 board that is capable of trying 7100 passwords per second (Microsoft Office 2013) you’re looking at 12 hours of straight brute-forcing. Bump the password to 8 characters, add upper-case letters and include numbers, and you’ll have 2.8 trillion possible combinations. This takes 12.5 years to break.

In other words, you’re looking at the following real-world recovery speeds:

	Per second	Per hour	Per day
MS Office 2013	7100	25,560,000	613,440,000
What can be broken	2-3 characters	4 alphanumeric characters	5 alphanumeric characters (just barely)

As you see, the answer to “how long will it take?” depends greatly on the password itself.

Of course, you can limit the scope of the recovery by either using a custom dictionary consisting of user’s real passwords, or employing a readily available dictionary that consists of 10,000 most popular passwords from the recent leaks. This gives you a certain chance to break even the most complex password in a matter of minutes. These two methods are discussed in the following chapters.

Factors affecting attack speeds: password length, complexity, data format and hardware

We already posted these charts, but let’s have another look:

As you can see, the speed of attack (the number of passwords a given computer can try per second) depends on two major factors: the encryption algorithm of the protected data format, and the speed and architecture of the computer performing the attack.

The third major factor affecting the speed of the attack would be the password recovery tool itself, its optimization level as well as the ability to make use of available computational resources. We’re using Elcomsoft Distributed Password Recovery, one of the most advanced tools on the market, so at least this factor is not at play.

Depending on the data format, attack speeds may widely differ even when running on the same hardware. And even within a certain data format, the numbers may change depending on the particular implementation of the algorithm. Let’s take one example:

• iOS 9 (CPU): 2,400 passwords per second (Intel i5)
• iOS 9 (GPU): 150,000 passwords per second (NVIDIA GTX 1080)
• iOS 10.0 (CPU): 6,000,000 passwords per second (Intel i5)
• iOS 10.2+ (CPU): 0.05 passwords per second (or 5-6 per minute) (Intel i5)

Back in 2016, we discovered a bug in iOS 10. Apple screwed security of iTunes backups, allowing us to try some six million passwords per second using a single CPU unit. After we published a report, Apple has quickly fixed the problem. In iOS 10.2, they went overboard and made password recovery speed extremely slow with only 5-6 passwords per minute when using a CPU, or just a few passwords per second when using a GPU. This effectively rules our brute-force attacks, only allowing for highly targeted dictionary attacks.

Another example. Microsoft appears to tighten security with every major release of Microsoft Office. While files saved by Office 97-2000 applications could be recovered near instantly, Office 2010 was already much more secure:

Office 2013 documents become significantly slower to break with only 30 passwords per second using a CPU or about 7100 passwords per second using a GPU. Office 2016 is slower yet. Compare that to over 1 million passwords per second for OpenOffice documents (via GPU), and you’ll begin understanding how much of a difference the data format can make.

What do these numbers mean in real terms? Let’s look at the following table.

	6 characters, lower-case	6 alphanumeric, both cases	7 characters, lower case	7 alphanumeric, both cases	8 characters, lower case	8 alphanumeric, both cases
MS Office 2013, CPU	119 days	60 years	8.5 years	3700 years	220 years	Eternity
MS Office 2013, GPU	0,5 days	3 months	2 weeks	16 years	1 year	975 years
RAR5, CPU	56 days	28 years	4 years	1744 years	103 years	Eternity
RAR5, GPU	2 hours	26 days	4 days	4.4 years	3 months	273 years
BitLocker, CPU	5 years	900 years	127 years	eternity	3300 years	Eternity
BitLocker, GPU	4 days	2 years	3.6 months	130 years	7.7 years	Eternity

 

You can see that, for example, breaking a Microsoft Office 2013 document with a CPU alone via plain brute force can help you find a 6-character passwords consisting of lower-case letters only in 119 days (on a CPU) or in about 10 hours (if you use a single video card with a powerful GPU for hardware acceleration).

Should the user employ a significantly more complex password such as one consisting of 8 mixed letters (in both cases) and numbers, you’re looking at spending some 975 years brute-forcing that password with a single GPU.

If you have better plans for the next millennium, you can build a powerful cluster to speed up the attack. For example, you can equip each computer with 4 high-end video cards, which will cut the time from 975 years to “only” 243 years. From there, you can start adding computers to your cluster. Use a cluster of 500 computers, and you’re looking at 6-month timeframe for breaking that password. Whether it’s worth it or not is another story.

What if the user has at least one special character (such as #, $ or %) in their password? The use of special characters increases the time required to break the password by the factor of 33, meaning that the password you thought would only take a day to recover will suddenly require a full month of crunching.

You can play with the number of possible combinations by using the following password strength meter:

Password Meter – A visual assessment of password strengths and weaknesses (uic.edu)

As an example, let’s take the simplest password that only consists of one character.

• Numbers only: 10 possible combinations
• Small letters only: 26 combinations
• Numbers and small letters: 36 combinations
• Numbers, small and capital letters: 62 combinations
• Numbers, letters in both cases, and special characters: 95 combinations

Calculating the number of passwords consisting of those character sets is as easy as raising the number of (possible combinations) to a power of (password length).

For example, a numerical password consisting of two digits has 10^2, or 100 possible combinations.

A 6-character password that consists of small letters only will have 26^6, or 308,915,776 combinations, and so on.

Conclusion

Knowing just how long it will take to break passwords of a certain length (number of characters) and complexity (the character set) allows calculating the resources you’ll need to break that password during a set period of time, or calculate the period of time it will take to break that password with your existing resources. Statistically, passwords are frequently reused, so a dictionary attack based on the user’s existing passwords may have a greater chance of success compared to plain brute-force. If no information about the user’s existing passwords is available, a dictionary attack based on the top 10,000 most common passwords followed by an attack using an English and/or native language dictionary might work. Brute-force attacks should be left for attacking shorter and simpler passwords such as PIN codes or digit-only passwords.

Just before the turn of the year, we’ve made an important update to Elcomsoft iOS Forensic Toolkit, a low-level iOS file system extraction and keychain decryption tool. The update brings checkm8 support to iOS, iPadOS and tvOS 16.2 devices, and enables agent-based low-level extraction of iOS 15.5. We’ve also fixed what’s been long broken: the ability to sideload the extraction agent from Windows PCs, yet the two updates are delivered in different branches. Sounds confusing? We’re here to solve it for you.

checkm8: full file system extraction for iOS, iPadOS and tvOS 16.2

Not long ago we’ve made a big release. iOS Forensic Toolkit 8.0 brought checkm8 support to a plethora of devices. checkm8-based extraction is the cleanest, safest, and most technologically advanced extraction method available for a range of Apple devices with a vulnerable bootloader. Compared to other acquisition methods, our implementation of checkm8 is the only true forensically sound solution that delivers repeatable and verifiable extractions. Compared to logical acquisition, low-level extraction delivers significantly more information. For most system builds, checkm8 extraction can decrypt the entire content of the keychain including encryption keys and authentication tokens. The tool was a complete overhaul, introducing a command-line interface instead of the previously used console menu.

iOS Forensic Toolkit 8.10 is the first major update, now bringing low-level full file system extraction support to Apple devices running iOS, iPadOS and tvOS 16.2. The new build enables forensically sound checkm8 extraction of compatible iPhone, iPad, and Apple TV devices up to and including the iPhone X range, as well as iPad and Apple TV devices built with the corresponding SoC.

A small peculiarity: when loading ramdisk on a device running iOS, iPadOS or tvOS 16.1-16.2, the following prompt will pop up on your computer:

You will need to authenticate with either Touch ID or password to continue.

Note: keychain decryption for iOS, iPadOS and tvOS 16.2 is coming soon.

checkm8 limitations: iOS 16.x on the iPhone 8, 8 Plus, and iPhone X

With the release of iOS 16, Apple made things more difficult for the mobile forensic specialists. We’ve already talked about it in iOS 16: SEP Hardening, New Security Measures and Their Forensic Implications. That final build of iOS 16 introduced a brand-new SEP (Secure Enclave Processor) hardening patch that effectively prevents access to user data if a screen lock passcode was ever used on the device, thus ruling out the possibility to use the bootloader exploit for accessing data on pretty much all A11 iPhones in circulation. Older iPhones did not receive the update, but they didn’t get iOS 16 in the first place.

Let’s reiterate: 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 (e.g. iPads), as well as for R&D purposes.

checkm8 extraction and iPadOS 16: working good (with caveats)

We had to wait for the first official release of iOS 16 for iPads, which was iPadOS 16.1, to figure out if the same hardening patch was applied to iPads. It turned out this was not the case, and you can still use checkm8 extraction on iPad devices running iOS 16.x regardless of the generation of SoC they are built on.

The ability to use checkm8 extraction is limited on the iPhone 8, 8 Plus, and iPhone X devices. On these devices, the extraction only works if no screen lock passcode was ever used on the device since the initial setup. This limitation does not apply to any iPad or Apple TV models, yet you may have to remove the screen lock passcode when acquiring an iPadOS 16 device.

What about the caveats? It’s also about the passcode. If there is no passcode on the iPad being extracted (or if the passcode has been removed prior to the extraction), the extraction is guaranteed to work. If the passcode is enabled (and you know it), you may need an additional SEP unlock step (the loadnfcd command), but even then the extraction may fail. If this happens after you tried a few times, there’s no other choice but booting the device and removing the passcode in iPadOS Settings. Deleting the passcode has serious forensic implications, so don’t do it lightly; however, this can be the only way to do checkm8 extraction on iPads running iOS 16.x.

checkm8 on Apple TVs: generally fine

We tested checkm8 on the AppleTV 4K, and the extraction is stable. We’re still working on the newer AppleTV HDR running tvOS 16.x for which the extraction is not currently stable.

Extraction agent: experimental support of iOS 15.5

The new build of iOS Forensic Toolkit adds experimental agent-based low-level extraction support for iOS/iPadOS 15.5, but only for A12 and newer devices. For A11 and older platforms (the iPhone 8/8Plus and iPhone X), the agent still only supports iOS builds up to 15.3.1, but that does not really matter as a much cleaner checkm8 extraction process is available for these older platforms. Note that iOS/iPadOS 15.5 support is still experimental as we have only tested the exploit on a handful of devices.

We discovered that the exploit works most reliably after approximately one minute (or longer) after the device is rebooted. The device must be switched into airplane mode for the exploit to work. If the device was kept powered on for a long period of time, we recommend rebooting and unlocking the device, and waiting for at least one minute before applying the exploit. Mind the airplane mode!

If you encounter the “All exploits failed. Please reboot the device and try again” error, reboot the device and make sure it’s paired to the computer. Reconfirm the airplane mode, wait for at least one minute and repeat the attempt. Another error you may encounter is a spontaneous reboot.

The full list of supported devices includes the following models:

• iPhone Xr, Xs
• iPhone 11, iPhone SE (2nd gen)
• iPhone 12
• iPhone 13, iPhone SE (3rd gen)
• iPad 8, 9, 10
• iPad Mini 5, 6
• iPad Air 3, 4, 5
• iPad Pro 3, 4, 5

Note: you may need 4 to 5 attempts to apply the exploit on M1-based iPads.

Some of our competitors have also introduced their versions of iOS extraction agents. We discovered that those competing solutions rely exclusively on public exploits, which is sub-optimal to say the least. Our solution uses all known vulnerabilities; we deeply rework and improve the exploits, and test them on a large fleet of devices to ensure maximum stability. The extra work is essential as the kernel exploit covers about a fifth of what needs to be done to reliably run the extraction agent. The file system extraction requires several stages including privilege escalation, sandbox escape, Pointer Authentication bypass, and so on, while kernel exploits only cover the very first step.

What’s up with the Windows edition?

iOS Forensic Toolkit 8 is only available for Mac computers for the time being as we need more time to finalize the checkm8 support on Windows and Linux platforms. Our Windows customers are served with the EIFT 7.x branch, which is all but abandoned and is still in active development. To use low-level extraction in iOS Forensic Toolkit 7, you’ll need to use the extraction agent, which in turn is an app that must be sideloaded onto the iOS/iPadOS device running a compatible (vulnerable) version of iOS.

Agent-based extraction is second best to checkm8. By using the extraction agent, one can image the complete file system of the device. For most devices, the tool can also decrypt the keychain, accessing all keychain records regardless of their protection class. Unlike checkm8, agent-based extraction cannot be classified as completely forensically sound, yet it comes close by leaving almost no traces on the device once the extraction is finished.

The extraction agent is back

To install the extraction agent onto an iOS/iPadOS device, you’ll need to sideload it first. The term describes the process of pushing an app to a mobile device directly from the computer, bypassing the App Store and standard installation mechanisms. Apple is not keen of sideloading, and tries to limit the users’ ability to sideload apps onto their devices. A few years back anyone could install an app onto their iPhone using Cydia Impactor, a free sideloading tool that no longer works. In the meanwhile, we developed an alternative sideloading process that was used in iOS Forensic Toolkit to install the extraction agent. Some time ago Apple further restricted sideloading, which continued to work if you used a Mac but failed if you tried to install the extraction agent from a Windows PC.

We’ve been working hard to bypass this limitation. Finally, iOS Forensic Toolkit 7.70 brings back the extraction agent to Windows PCs: you can now sideload the agent to an iOS/iPadOS device by using a a Windows PC. The new signing mechanism now employs regular Apple ID passwords instead of the previously used one-time passwords, but you still need an Apple ID enrolled in the Apple’s Developer Program to sideload and sign the extraction agent.

Please refer to the following chart for details on the types of extraction supported on the different platforms:

Viewing the data

Viewing the extracted file system image is possible with Elcomsoft Phone Viewer, which was recently updated to support iOS 16.x file system images. The updated iOS release introduced multiple changes in the data formats, which required updating the viewing tool to conform to these changes. Alternatively, you may use a third-party forensic tool compatible with iOS 16 file system images.

 

The new year is fast approaching, and of course we are curious to know what it has in store for us in the field of computer, mobile, and cloud forensics. But before 2022 is over, we invite you to take a moment to reflect on what 2022 has been like for us. More research, development and updates remained our top priority, as it has been in all previous years. We have continued with constant improvement to our solutions by launching new features and expanding product capabilities. We’ve also got a chance to attend some conferences to meet with you in person and share our expertise. So, here’s our take on the results of 2022.

Networking

This year we again visited a few conferences, including FT-Day in Kandel by mh-Service GmbH and On Scene Triage online conference by The Investigator where we successfully delivered reports on the latest achievements in the field of mobile and computer forensics. Nothing can replace a face-to-face meeting, which is why we will continue to visit our partner conferences delivering our news and achievements.

Mobile and Computer Forensics

In addition to our seminar activities, we have been actively working on the products, and delivered more than 20 updates this year. Traditionally, Elcomsoft iOS Forensic Toolkit with a dozen new releases took the palm for updates. This year we officially launched the eighth version of the product, having previously perfected the functionality with the twelve beta versions. The all-new Elcomsoft iOS Forensic Toolkit 8 implements forensically sound data extraction, file system imaging and keychain decryption for 76 iPhone, iPod Touch, iPad, Apple Watch and Apple TV models, multiple generations of iOS and three generations of architecture.

Elcomsoft iOS Forensic Toolkit 8.0 brings a new, advanced user experience built around the command line, allowing experts to stay in control of every step of the extraction process. The toolkit now supports all possible acquisition methods including advanced logical, agent-based and checkm8-based low-level extraction.

In addition, Elcomsoft Phone Breaker and Elcomsoft Phone Viewer have been updated in the mobile product line, adding support for Windows 11, macOS 12 Monterey and 13 Ventura operating systems.

Elcomsoft Distributed Password Recovery has also received a number of updates, including support for password recovery for Acronis, Macrium and Veeam encrypted backups, support for LUKS2 and Windows Hello PINs, and support for the Alder Lake hybrid architecture.

And finally, our digital filed triage tool, Elcomsoft System Recovery was updated with a host of bootable forensic triage tools to help experts analyze computer systems in the field. The tool also added the ability to recover Windows 10 PIN codes and Windows 11 accounts with in-place PIN recovery, as well as added LUKS2 support and detection of Microsoft Azure accounts.

The Blog Stats

Our blog has also been frequently updated with new articles this year. 50 articles were published and the two most popular are about iPhone X, DFU mode and checkm8 and Preventing BitLocker Lockout and Recovering Access to Encrypted System Drive. Thank you for reading our blog and sharing articles with each other. If you have ideas for new topics that we have not yet covered, leave us a message on Telegram (you can dm to the channel owners) and we will consider your request.

Have a safe and peaceful holiday season, and see you soon in the new year 2023!

Windows account passwords, or NTLM passwords, are among the easiest to recover due to their relatively low cryptographic strength. At the same time, NTLM passwords can be used to unlock DPAPI-protected data such as the user’s passwords stored in Web browsers, encrypted chats, EFS-protected files and folders, and a lot more. In this article we argue about prioritizing the recovery of NTLM hashes over any other types of encrypted data.

What are NTLM hashes?

In Windows, NTLM hashes are used to verify passwords when users sign in to their Windows accounts. Microsoft still uses the NTLM mechanism to store passwords in modern versions of Windows. These passwords are stored in the SAM database, or in the NTDS database on the domain controller. Interestingly, NTLM hashes are faster to break than the much older LM hashes due to the way the algorithm is implemented.

NTLM hashes protect local Windows accounts as well as the newer types of accounts introduced in Windows 8: the Microsoft Account sign-in. Windows caches the password hash and stores it locally on the computer. This allows users to log in to their computer while using it offline. On another hand, this also allows extracting the cached hash file and running an offline attack to recover the original password. The hashed Microsoft Account passwords are stored locally in the SAM database along with the rest of NTLM hashes. Technically, the locally cached Microsoft Accounts passwords are protected with the same NTLM mechanism as other types of cached credentials, which makes them just as easy and as fast to attack as local Windows passwords.

In layman’s terms, breaking an NTLM hash reveals the user’s plain-text Windows account or Microsoft account password, allowing the expert to sign in to that user’s computer and extract DPAPI-protected ata.

NTLM hashes are poorly salted. Microsoft uses cryptographic salt to protect LM and NTLM password hashes (what’s the difference?). However, the same salt is used to protect all LM and all NTLM passwords, which allows attacking all user accounts that present on a certain computer simultaneously. This only changed in Windows Hello PINs.

The NTLM hashes are among the weakest and fastest to attack. A CPU-only attack already demonstrates very impressive speeds, while employing a mid-range NVIDIA RTX 2070 board allows trying up to 23 billion password combinations per second. Such a speed allows breaking 8-character passwords that consist of an extended character set (small and capital letters, numbers, and special characters) in under 87 hours. A more typical 8-character password containing only small and capital English letters and numbers (no special characters) can be broken in under 3 hours. A more powerful GPU, multiple GPUs, or several computers in a distributed attack can be used to speed up the recovery.

What is DPAPI, and how is it related to NTLM?

Windows uses Data Protection Application Programming Interface (DPAPI) as a transparent way to access encryption keys protecting various system resources. Examples of such DPAPI-protected resources are online forms and authentication credentials (passwords) stored in Microsoft Edge and Google Chrome, EFS (Encrypted File System, or NTFS file encryption) keys, passwords to network shares and FTP resources, and a lot more.

DPAPI transparently protects sensitive information stored in each user’s Windows account. For example, if the user enables file encryption by ticking the “Encrypt contents to secure data” box in the Advanced Properties of a file or folder, the encrypted files will be transparently accessible to the authenticated user, but cannot be accessed when analyzing a disk image.

In addition, DPAPI protects authentication credentials cached in Microsoft Edge and Google Chrome browsers. This protection is also transparent; the user does not need to enter any additional password to access these authentication credentials, but such credentials cannot be extracted when analyzing a disk image without an authenticated Windows session.

The “NTLM first” strategy

This strategy prioritizes easily accessible data that can be used to break other passwords or to decrypt data, disregarding its potential value as evidence. In particular, this strategy prioritizes stored passwords (e.g. Web browser password storage, keychain, DPAPI-protected data etc.)

So why do we need the NTML password after all? It’s because of the other things that are protected with it. The users’ passwords stored in Windows Web browsers such as Microsoft Edge and Google Chrome are encrypted with a key protected with Windows DPAPI. Decrypting the key (and accessing stored passwords) requires a Windows account unlock, which in turn means we’ll need to break the NTLM password to sign into the user’s Windows account. NTLM passwords are notoriously fast to recover, which makes them the perfect target.

You’ll need to take several steps to make the best use of the strategy.

1. Analyze unencrypted data for any passwords that can be accessed.
2. Create or update the custom dictionary.
3. Use the custom dictionary to attack the NTLM password.
4. Access DPAPI-protected data (such as browser passwords, SMB passwords etc.) e.g. with Elcomsoft Internet Password Breaker
5. Update custom dictionary.
6. Analyze the dictionary of the user’s passwords. Any repeatable patterns? Shared passwords? Common templates? What kind of mutations would fit the user’s profile?
7. Update custom dictionary with “cleaned”, pattern-based passwords (e.g. for entries such as “Password123” use “password” and medium strength of “Digit” mutations).
8. When attacking files and documents, place the fastest/easiest to break files at the top of the queue. NTLM passwords are among the weakest, and should always make it to the top of the queue.

Additional information

If you are interested in unlocking DPAPI-protected data, check out the following presentation first:

• DPAPI exploitation during pentest and password cracking

In addition, we recommend the following articles:

• DPAPI – Extracting Passwords – HackTricks – Boitatech

We offer a tool for extracting DPAPI-protected passwords from all major Web browsers:

• Elcomsoft Internet Password Breaker | Elcomsoft Co.Ltd.

There is also a free tool that can extract DPAPI-protected keys in binary form:

• DataProtectionDecryptor – Decrypt DPAPI (Data Protection API) data of Windows (nirsoft.net)

Conclusion

The described strategy may seem counter-intuitive; it is far less obvious than strategies prioritizing the most important evidence. When choosing your strategy, consider that the most valuable evidence may feature the strongest protection that may not be recoverable with brute force.

Several generations of Apple TV devices have a bootloader vulnerability that can be exploited with checkm8 to extract information from the device. The vulnerability exists in the Apple TV 3 (2012 and 2013), Apple TV HD (formerly Apple TV 4) 2015 and 2021, and Apple TV 4K (2017). Newer generations of Apple TV do not have the vulnerability. This guide lists the tools and steps required to fully extract a compatible Apple TV device.

Apple TV: cheat sheet

To extract data from an Apple TV box, follow these steps:

1. Launch iOS Forensic Toolkit 8.0 (Mac)
2. Connect the device to the computer with a USB cable (you will need a custom adapter for connecting the Apple TV 4K device)
3. Place the Apple TV into DFU (see below)
4. Run ./EIFT_cmd boot
5. Run ./EIFT_cmd unlockdata -s
6. Run ./EIFT_cmd ramdisk keychain -o {filename} to extract the keychain
7. Run ./EIFT_cmd ramdisk tar -o {filename} to pull the file system image
8. Run ./EIFT_cmd ssh halt to power off the device

Placing Apple TV devices to DFU

Placing the three generations of Apple TV into DFU requires different steps. The Apple TV 3 can be placed into DFU with a matching IR remote, while the Apple TV HD (formerly Apple TV 4) require a Siri remote. Apple TV 4K requires an additional adapter to connect it to the computer (due to the lack of USB port). You will need yet another adapter to place the device to DFU, but once you have it, simply connecting the adapter to the box is enough to make it boot into DFU. Please refer to the following article for instructions: How to Put Apple TV 3 (2012-2013), Apple TV 4/HD (2015) and Apple TV 4K (2017) into DFU

Apple TV extraction steps explained

Once you connect the Apple TV device to the computer, place the device into DFU as explained in the previous chapter. Then apply the exploit with iOS Forensic Toolkit by running the following command:

./EIFT_cmd boot

iOS Forensic Toolkit will detect the Apple TV in DFU mode and automatically apply the exploit. The toolkit detects the tvOS version installed on the device, and provides a download link to an Apple firmware image. If there are multiple potential matches, several download links will be displayed; we recommend taking the last link from the list. Download the file from the link, and drop it onto the console window, then press ENTER. Alternatively, you can simply paste the firmware download link instead. If you do that, the tool will only download parts of the firmware image that are required to apply the exploit and boot the Apple TV. It may take several attempts to place the device into DFU.

Notably, full IPSW images for Apple TV devices are scarce. Our tool can use OTA update images for the purpose of applying the exploit.

In many cases, the tvOS version will be detected automatically by EIFT during the first stage of the exploit. The detection is based on the detected iBoot version and device hardware. However, in some cases the iBoot version may correspond to several OS builds. If the wrong build is used, you will have an option to either repeat the process with a different version of firmware, or continue with the current firmware image (which works in many cases).

Please note: applying the checkm8 exploit on the first-generation Apple TV 3 (A1427) requires a Raspberry Pi Pico board. The workflow is similar to the iPhone 4s. The newer Apple TV 3 (A1469) does not require an external microcontroller.

./EIFT_cmd ramdisk unlockdata -s

This command unlocks the data partition and mounts it read-only. Since the Apple TV does not have a passcode, you will not need to provide one.

./EIFT_cmd ramdisk keychain -o {filename}

This command extracts and decrypts the keychain. If no path is specified, it will be saved into the current folder. Note that the number of keychain records extracted can be limited compared to the content of an iPhone or iPad device. Since the Apple TV cannot have a passcode, the Apple TV devices cannot access any end-to-end encrypted data in iCloud, which includes the iCloud keychain. Any keychain records extracted from the Apple TV are going to be local, entered by the user on a specific device.

./EIFT_cmd ramdisk tar -o {filename}

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

Analyzing Apple TV data

After extracting the data, load the file system image and a copy of the keychain in the forensic tool of your choice. For the time being, few if any third-party forensic tools have been optimized to support TV-specific data sets. Elcomsoft Phone Viewer fully supports Apple TV images. Alternatively, you can manually analyze the file system image by unpacking the resulting .tar archive. Please refer to Apple TV Forensics 03: Analysis for details.

checkm8 is the only extraction method available for the Apple Watch S3 allowing full access to essential evidence stored in the device. In this guide, we will talk about connecting the Apple Watch S3 to the computer, placing the watch into DFU mode, applying the checkm8 exploit and extracting the file system from the device with iOS Forensic Toolkit 8.0.

The Apple Watch Series 3 has set a record as the longest smartwatch that Apple kept around. Initially introduced in September 2017, this model remained on sale for five years until it was finally discontinued in 2022. This model is the last Apple Watch device compatible with the checkm8 exploit.

Please note: steps listed in this guide are provided for the release version of iOS Forensic Toolkit 8.0. The older article checkm8 Extraction of Apple Watch Series 3 is based on the fifth beta version of the tool, and has slightly outdated instructions. While the old instructions still work, please refer to this publication for all future Apple Watch extractions.

Before you begin

Unlike other Apple devices, the Apple Watch does not have a built-in USB port. The hidden diagnostic pins are available and can be used to attach the watch to the computer with an appropriate adapter. Make sure you have everything handy before you begin.

1. A Mac computer. You will need a Mac to install the exploit and perform the extraction. We support both Intel and M1-based Macs with a universal build of iOS Forensic Toolkit. At this time, Windows is not supported.
2. iOS Forensic Toolkit 8.0 for Mac. Currently, EIFT 8.0 is only available for Mac.
3. Apple Watch Series 3. The watch must be functional enough to be placed into DFU mode.
4. Apple Watch passcode must be known or empty. Otherwise, limited BFU extraction may be available, but very little information can be obtained this way.
5. A compatible USB adapter to connect the watch to the computer.
6. You must be able to download the official Apple firmware (download link will be provided during the extraction) that matches watchOS version installed on the device.

Note: while Apple had partially patched the vulnerability in iOS 14 and 15, watchOS 7 and 8, which are based on those versions of iOS, did not receive the same treatment. As a result, you will not have to remove the watch screen lock passcode in order to apply the exploit. We are not quite sure what’s going on here, but it does appear the patch was simply forgotten.

USB adapter

There are several types of Apple Watch adapters on the market that can be easily sourced from multiple vendors. We tested several adapters, and currently recommend one named S-Dock:

Note that some adapters may not support DFU mode. We recommend one of the adapters we tested in Apple Watch Forensics: The Adapters and Apple Watch Forensics: More on Adapters, which includes models by S-BUS, MagicAWRT and iBUS.

Cheat sheet: checkm8 extraction of Apple Watch 3

When extracting the Apple Watch, follow these steps:

1. Launch iOS Forensic Toolkit 8.0
2. Connect the Apple Watch 3 to the computer via a USB adapter (in a powered-off state)
3. Run ./EIFT_cmd boot -w
4. Place the Watch into DFU
5. iOS Forensic Toolkit will detect the watch and apply the exploit
6. Run ./EIFT_cmd ramdisk loadnfcd
7. Run ./EIFT_cmd ramdisk unlockdata -s (enter passcode when prompted, or ENTER if you don’t know the passcode)
8. Run ./EIFT_cmd ramdisk keychain -o {filename} to extract the keychain
9. Run ./EIFT_cmd ramdisk tar -o {filename} to extract the file system
10. Run ./EIFT_cmd ssh halt to power off the Apple Watch

Step by step instructions

Launch iOS Forensic Toolkit, then connect the Apple Watch to the computer by using a commercially available adapter. At this time, the watch must be powered down.

On the computer, launch EIFT in wait mode:

./EIFT_cmd boot -w

Then, place the watch into DFU. To do that, press and hold both the Digital Crown and the Side button for ten seconds, then release the Side button while still holding the Digital Crown for 10 more seconds. There will be no indication on the watch; the display should remain black. If you see an Apple logo, the timings were wrong, and you’ll have to repeat the procedure.

Once the watch is in DFU mode, the tool code detects the OS version installed on the watch, and provides a download link. If there are multiple potential matches, several download links will be displayed; we recommend taking the last link from the list. Download the file from the link, and drop it onto the console window, then press ENTER. Alternatively, you can simply paste the firmware download link instead. If you do that, the tool will only download parts of the firmware image that are required to apply the exploit and boot the watch. It may take several attempts to place the device into DFU.

Notably, full IPSW images for Apple Watch devices are scarce. Our tool can use OTA update images for the purpose of applying the exploit.

Once the exploit is applied, the watch screen will display the “Booting” message.

In many cases, the watchOS version will be detected automatically by EIFT during the first stage of the exploit. The detection is based on the detected iBoot version and device hardware. However, in some cases the iBoot version may correspond to several OS builds. If the wrong build is used, you will have an option to either repeat the process with a different version of firmware, or continue with the current firmware image (which works in many cases).

If the process was successful, you will see a confirmation.

The Watch will display the following screen:

./EIFT_cmd ramdisk unlockdata -s

This command unlocks the data partition and mounts it read-only. You may be prompted for the passcode; enter the passcode if you know it, or press ENTER to skip (limited DFU extraction will be performed in that case).

If you enter the wrong passcode, an error will be displayed. With correct passcode, the volume is fully unlocked and you can proceed with data (keychain and file system) extraction). If you don’t know the passcode, press ENTER on the screen below. In this case, a very limited BFU extraction will be performed.1

./EIFT_cmd ramdisk keychain -o {filename}

This command extracts and decrypts the keychain. If no path is specified, it will be saved into the current folder.

./EIFT_cmd ramdisk tar -o {filename}

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

The SoC and USB controller in the Apple Watch are significantly slower than their iPhone counterparts, which results in comparatively slow extraction speeds of approximately 3 MB/s.

Limited BFU extraction

If you do not know the screen lock passcode, just press ENTER when prompted. Despite “Device is not unlockable” error, you will be still able to perform a limited BFU (Before First Unlock) extraction).

Analyzing Apple Watch data

After extracting the data, load the file system image and a copy of the keychain in the forensic tool of your choice. For the time being, few if any third-party forensic tools have been optimized to support watch-specific data sets. Elcomsoft Phone Viewer fully supports Apple Watch images.

The Apple Watch contains a significant amount of data that is neither included in backups nor synchronized with iCloud. Such unique data may include extensive location data, messages, notifications, and more.

The extraction method or methods available for a particular iOS device depend on the device’s hardware platform and the installed version of iOS. While logical acquisition is available for all iOS and iPadOS devices, more advanced extraction methods are available for older platforms and versions of iOS. But what if more than one way to extract the data is available for a given device? In this guide, we’ll discuss the applicable acquisition methods as well as the order in which they should be used.

For iOS and iPad OS devices, low-level extraction requires exploiting undocumented vulnerabilities in order to access the file system and some encryption keys required to decrypt the keychain. Such exploits are typically discovered in older hardware platforms and older versions of iOS. In general, devices released less than five years ago and running a recent version of iOS are immune to known public exploits and can be only extracted with logical acquisition. Logical acquisition is universally available on iOS and iPadOS devices regardless of their hardware platform and version of iOS. However, logical acquisition on devices running tvOS and watchOS will be limited as there is no backup services on such devices.

Low-level extraction methods are available on older platforms and versions of iOS. These methods include checkm8 (a booloader-based exploit) and Elcomsoft’s software-based low-level extraction agent. Please refer to the following table to determine which acquisition methods are available to your device:

Notes:

• The iPhone SE 3 (2022) was released with iOS 15.4 on board, which is not supported by the extraction agent.
• For iOS 15.2-15.3.1 the extraction agent can only extract the file system but not the keychain.
• checkm8 extraction of Apple A11 devices running iOS 14 and 15 is only possible once the screen lock passcode is empty.
• No agent-based extraction is available for checkm8-capable Apple TV devices.
• checkm8 support for iOS 16 devices is under development and will be available soon for all supported devices.
• The extraction agent is in active development, with full support for iOS 15.5 and lower (including keychain decryption) coming soon.

Choosing the right extraction method

When more than one extraction method is available, the order matters. We recommend the following workflow.

Note: logical extraction is available for all generations of Apple hardware and all supported versions of iOS.

For older devices compatible with checkm8 (this includes iPhone devices up to and including the iPhone 8, 8 Plus, and iPhone X, as well as the corresponding iPad, Apple Watch, and Apple TV models):

• Only use checkm8 extraction. Attempt other methods if and only if the checkm8 extraction fails.

The checkm8 extraction is the most sophisticated extraction method available for Apple devices that have a vulnerability in their bootloader. Our implementation of checkm8 offers clean, forensically sound extractions with repeatable, verifiable results. If you’ve used checkm8, you have already received the fullest set of data extractable from the device; there is no need to use any other acquisition method.

Using checkm8 extraction: checkm8 Extraction Cheat Sheet: iPhone and iPad Devices

For devices not compatible with checkm8 but running a version of iOS supporting the extraction agent (currently, iOS 9.0 through 15.3.1 for devices supporting these OS versions):

1. First, make a local backup with iOS Forensic Toolkit. If the backup is password-protected, make a backup nevertheless. Do not reset the backup password in device settings.
2. Use the extraction agent. The backup password will be extracted along with the rest of the data.

For all other devices that support neither checkm8 nor the extraction agent, including the iPhone 14 range:

1. First, make a local backup with iOS Forensic Toolkit. If the backup is password-protected, make a backup nevertheless. Do not reset the backup password in device settings. If the backup password is empty, the tool automatically sets a temporary password of “123”.
2. Extract all other data that can be obtained through the advanced logical process. This includes media files (photos, videos and metadata), shared application data, some system logs and device information.
3. If the backup has an unknown password, attempt a local attack with Elcomsoft Phone Breaker or Elcomsoft Distributed Password Recovery. If unsuccessful, consider resetting the backup password through device settings. Mind the risks and consequences.

Using advanced logical extraction: Advanced Logical Extraction with iOS Forensic Toolkit 8: Cheat Sheet

Conclusion

This publication should help experts better understand their options when extracting Apple devices based on their hardware platform and OS.

iOS Forensic Toolkit 8 brings new powerful user experience based on the command line. While this approach offers experts full control over the extraction process, mastering the right workflow may become a challenge for those unfamiliar with command-line tools. In this quick-start guide we will lay out the steps required to extract the file system and decrypt the keychain of a compatible iPhone or iPad device.

Introduction

Low-level extraction can be done differently. For older hardware, the checkm8 extraction delivers the cleanest results; our solution is unrivaled in providing truly forensically sound extractions for all compatible devices, which include a number of iPhone, iPad, Apple Watch and Apple TV devices. checkm8 extractions are great, but they aren’t compatible with newer devices. To deliver low-level extraction for newer iPhones and iPads, we developed an in-house extraction agent that comes as close to being forensically sound as possible. This method is highly dependent on kernel exploits, which are extremely difficult to implement. This is why low-level extraction almost never comes to the current, up-to-date and fully patched versions of iOS. For newer models starting with iPhone Xr/Xs, using the extraction agent is the only way to extract the file system and decrypt the keychain.

What is an extraction agent?

The extraction agent is an app sideloaded to the iPhone being extracted. The app establishes a communication channel between the device and the computer, escalates privileges, and gains access to the file and the encryption keys required to decrypt the content of the keychain.

Agent-based low-level extractions deliver the cleanest experience for newer devices without checkm8 support. While the process is not fully forensically sound, the modifications made to the data are minimal. Once the extraction agent is uninstalled, the only traces left on the device are several records representing agent-related events in the device’s diagnostic logs.

Extraction agent cheat sheet

Note: we recommend using a USB 3.0 port to speed up the extraction of certain devices.

On the computer, launch iOS Forensic Toolkit.

Connect the iPhone to the computer.

Once the iPhone is connected to the computer, you will be prompted to establish trust between the device and the computer. On the device, confirm the pairing prompt and enter the screen lock passcode.

If the device was not automatically paired, you will need to manually pair the device to the computer by running the following command:

./EIFT_cmd normal pair

Sideload the extraction agent onto the device by running the following command:

./EIFT_cmd agent install

On the iPhone: if you are using a non-developer Apple ID to sideload the agent, validate the signing certificate on the iPhone. (Note: this requires an active internet connection and carries certain security risks).

If an error message pops up (e.g. “all exploits failed”), restart the iPhone.

On the computer:

./EIFT_cmd agent keychain -o keychain.xml

./EIFT_cmd agent tar -o data.tar

 

Only if suspecting root-level malware:

./EIFT_cmd agent tar –system -o system.tar

On the computer (uninstall the extraction agent):

./EIFT_cmd agent uninstall

Alternatively, you may uninstall the extraction agent from the device by long-pressing its icon and deleting the app.

Installing the extraction agent

The extraction agent is an iOS app that must be sideloaded (installed) onto the iOS device. Note: if a previous version of the extraction agent is already installed, remove it from the device as you would uninstall any other app.

When installing the extraction agent, the iPhone must be unlocked and paired to the computer.

Sideloading the extraction agent requires an Apple ID login and password. We strongly recommend using an Apple ID account enrolled in Apple Developer Program. If you use a regular, non-developer account, you will need to validate the agent’s signing certificate on the iPhone, which requires an active internet connection and brings the associated security risks

Pair the iPhone to the computer before sideloading the extraction agent. The pairing prompt is usually displayed automatically when you connect the iPhone to the computer. Confirm the pairing prompt and type the screen lock passcode on the device. If for any reason no pairing is established, run the following command:

./EIFT_cmd normal pair

On the iPhone: confirm pairing request and enter screen lock password when prompted.

Install the extraction agent by running the following command on the computer:

./EIFT_cmd agent install

You will be prompted for Apple ID credentials (login, password, and one-time code for passing two-factor authentication). A developer account is strongly recommended. If you use a regular, non-developer account, you will need to validate the agent’s signing certificate on the device before you can launch the app. This in turn requires an active internet connection, placing the device at risk of unwanted synchronization and/or remote lock or remote erase. When using an Apple ID enrolled in Apple’s Developer Program, this check can be skipped, and the device can be kept offline.

Using the extraction agent

The extraction agent enables full file system extraction from all supported devices, as well as keychain decryption on select supported devices.

To use the extraction agent, install (sideload) the agent onto the iOS device according to the instructions, then touch its icon to launch the app. Make sure to keep the app open in foreground at all times during the extraction; do not switch to any other apps.

The extraction agent will automatically attempt to obtain elevated privileges. Since the agent uses unofficial exploits, on rare occasions the device may reboot. If this happens, wait until the device fully boots, unlock it, and run the agent app again. There is no need to reinstall the agent.

Keychain decryption

Extract the keychain into a file named keychain.xml:

./EIFT_cmd agent keychain -o keychain.xml

File system image

The extracted file system image is saved into a .tar archive. The process may take a while depending on the size of the file system. Make sure the agent app is open and runs in the foreground during the entire extraction.

The following command extracts and saves a file system image from the device into a file named “data.tar”. Only the user data will be copied.

./EIFT_cmd agent tar -o data.tar

You can also extract the system partition. Generally, you would only need to do it if you suspect that a rootkit or other system-level malware on the device.

./EIFT_cmd agent tar --system -o system.tar

Please note that you would normally only need to extract the data and not the system partition.

Finally, uninstall the extraction agent by either doing it regularly on the device or running the following command:

./EIFT_cmd agent uninstall

Alternatively, you may uninstall the extraction agent from the device by long-pressing its icon and deleting the app.

Extraction steps explained

When sideloading the extraction agent, we strongly recommend using an Apple ID registered in the Apple’s Developer Program. This allows keeping the device offline and disconnected from the network. If you must use a regular Apple ID, you will need to validate the signing certificate in the device settings, which in turn requires an active internet connection. If this is the case, make sure to configure a firewall to whitelist access to Apple signing services only. More in Extracting iPhone File System and Keychain Without an Apple Developer Account.

1. Download and install the latest version of Elcomsoft iOS Forensic Toolkit.
2. Launch iOS Forensic Toolkit on your computer.
3. Connect and pair the iOS device ./EIFT_cmd normal pair
4. Install the extraction agent ./EIFT_cmd agent install
   You will need an Apple ID (preferably enrolled in Apple’s Developer Program) with a login, password, and one-time two-factor authentication code to sideload the agent app.
5. If you used a regular, non-developer Apple ID, validate the signing certificate on the iPhone. This step is not needed when using a developer account.
6. Launch the extraction agent by tapping its icon. Keep the agent running in the foreground during the rest of the extraction process.
7. Extract and decrypt the keychain ./EIFT_cmd agent keychain -o keychain.xml
8. Extract user data ./EIFT_cmd agent tar -o data.tar
9. Optional: if suspecting malware or rootkit, extract system data ./EIFT_cmd agent tar –system -o system.tar
10. Uninstall the extraction agent regularly or by running ./EIFT_cmd agent uninstall

Conclusion

The extraction agent is a software-based low-level extraction solution available in iOS Forensic Toolkit for iPhone and iPad devices running compatible versions of iOS. We actively develop the extraction agent, planning full support for iOS 15.5 and lower (including keychain decryption) in near future.

Apple offers by far the most sophisticated solution for backing up, restoring, transferring and synchronizing data across devices belonging to the company’s ecosystem. Apple iCloud can store cloud backups and media files, synchronize essential information between Apple devices, and keep highly sensitive information such as Health and authentication credentials securely synchronized. In this article we’ll explain what kinds of data are stored in iCloud and what you need to access them.

iCloud: what’s inside?

Apple iCloud contains information belonging to several different categories.

iCloud backups. This is the classic cloud-based backup and restore mechanism introduced back in 2011. iCloud backups contain a set of system and application data that is similar to the content of passwordless local backups, with select exceptions for synchronized data. For example, if the user enables iCloud Photos (as a synchronized category), the photos may be no longer present in iCloud backups.

Apple only provides basic backup management, and does not allow downloading iCloud backups in any other way except restoring onto a physical Apple device. By logging in to an iCloud account (or accessing backups from any logged-in device), users can only view and delete backups with no other options available. One can restore a new device from almost any backup (the iOS version on the device being restored should be the same or newer than the OS version of the original device). Note that one can only restore from a cloud (or local) backup during the initial device setup (for new devices or devices after a factory reset).

Elcomsoft Phone Breaker was the first tool on the market to download iCloud backups without requiring authentic Apple hardware. Today, the tool can download backups created with devices running all versions of iOS up to and including iOS 16.x. To download an iCloud backup, you will need all of the following:

• The user’s Apple ID and password
• One-time code for two-factor authentication, if enabled on the user’s account

Authentication tokens cannot be used to access iCloud backups. Downloading the initial backup may take a long time. Subsequent incremental backups are downloaded a lot faster. We do not recommend using a VPN during the download as the speed may suffer.

• How to open: Unless you enable the “restore original file names” option, iCloud backups will be downloaded in the standard iTunes format compatible with Elcomsoft and third-party forensic tools.

Note 1: you can download backups made by all devices registered with a given Apple ID. Due to the incremental nature of cloud backups, Apple keeps up to two most recent snapshots for each device. Elcomsoft Phone Breaker downloads all snapshots for the devices you specify.

Note 2: you can download the complete backup or selectively download only the essential parts. Selective download allows to speed up the investigation as a full download may take a while depending on the size of the backup.

Note 3: Apple attempts to detect and restrict non-Apple access to iCloud backups. During one time, Apple used to temporarily lock accounts from which iCloud backups were obtained. Currently this is not the case, and it never occurred when accessing other types of data.

Note 4: Apple only provides 5GB of free cloud space, which practically rules out the backup functionality of iCloud (with the exception of temporary iCloud backups). An iCloud+ subscription provides 50GB of cloud space, which might be enough to store cloud backups.

Temporary iCloud backups. This is a new type of backups that appeared in iOS 15 to solve the problem of insufficient space in the user’s iCloud account when transferring data to a new Apple device or restoring onto the same device after a factory reset. Temporary iCloud backups do not count against iCloud storage quota and are retained for 21 days, automatically deleted afterwards. Our tool can supports the extraction of temporary iCloud backups. More in iOS 15 Forensic Implications: Temporary iCloud Backups.

Downloading a temporary iCloud backup is subject to the same authentication rules and limitations as regular cloud backups.

Synchronized data. These data include calendars, contacts, notes, and many other types of data synchronized by Apple apps.

To download synchronized data from the user’s iCloud account, you will need all of the following:

• The user’s Apple ID and password
• One-time code for two-factor authentication, if enabled on the user’s account

Alternatively, you may use a supported authentication token to access synchronized data.

• How to open: Synchronized data are downloaded raw, and stored in a custom SQLite database. Elcomsoft Phone Viewer is the only product that supports these data.

Files. iCloud also serves as a file storage. By default, any files downloaded by the user through Safari land into an iCloud-synced folder. iCloud Files also include files from macOS computers, Books, and more. iCloud Files are accessible on all devices sharing a common Apple ID.

Extracting files from the user’s iCloud account requires all of the following:

• The user’s Apple ID and password
• One-time code for two-factor authentication, if enabled on the user’s account

Files can be also extracted with a supported authentication token.

iCloud Photos. This service uploads all of your photos and videos to iCloud and keeps them up to date across your devices. Technically, iCloud Photos belong to synchronized data, but we listed it separately because photos may belong to several different categories, sometimes simultaneously.

Downloading iCloud Photos requires all of the following:

• The user’s Apple ID and password
• One-time code for two-factor authentication, if enabled on the user’s account

iCloud Photos belong to the synchronized data category, and, as such, they can be accessed with a supported authentication token.

My Photo Stream. This is an older incarnation of the media storage service that uploads the most recent photos and keeps them in iCloud for 30 days. My Photo Stream is now legacy, and is no longer available for newly opened Apple ID’s. My Photo Stream and iCloud Photos can be enabled or disabled individually, which may result in two copies of the same picture stored in the cloud.

My Photo Stream is a legacy service that is not available for Apple IDs created during the past several years. For this reason, Elcomsoft Phone Breaker does not support the extraction of My Photo Stream.

End-to-end encrypted data. Technically, end-to-end encrypted records belong to synchronized data. However, these data are encrypted with a key that can be unlocked with a screen lock passcode (iOS) or macOS account password of one of the trusted devices. End-to-end encrypted data include iCloud keychain (authentication data and passwords), Health, Safari bookmarks and history, call history, iMessages, and several other categories.

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

• The user’s Apple ID and password
• One-time code for two-factor authentication, if enabled on the user’s account
• Screen lock passcode or system password of a trusted Apple device with the same Apple ID

You cannot use authentication tokens to access end-to-end encrypted data.

Authentication tokens

Authentication tokens are stored on the user’s computer to help installed Apple tools avoid re-authentication. In the past, authentication tokens were transferrable and could be used to access information in iCloud from another computer. Today, authentication tokens are non-transferrable, and can only be used on the computer they were originally created on. When it comes to Ecomsoft Phone Breaker, you can only use authentication tokens created on macOS computers (Windows tokens are useless), and only on the particular macOS computer the token was created on, which essentially limits the use of authentication tokens.

All previously created authentication tokens immediately expire if the user changes their Apple ID/iCloud password. In addition, the tokens are only valid for a limited time; we don’t know their exact lifespan.

Supported (non-expired, macOS, same physical computer) authentication tokens can be used to access the following types of data:

1. Synchronized data except end-to-end encrypted categories
2. iCloud Photos
3. iCloud files

iCloud extraction steps

To perform an iCloud extraction, you need all of the following.

1. Elcomsoft Phone Breaker (the latest version)
2. Basic authentication data: login, password, and a way to pass two-factor authentication
3. To access end-to-end encrypted data: screen lock passcode or system password from one of the user’s trusted devices (the list will be displayed in the extraction wizard)

First, run Elcomsoft Phone Breaker and select between iCloud backups and synchronized data. Since downloading an iCloud backup may lead to a temporary account lock, we recommend starting from obtaining synchronized data.

When selecting the types of data to extract, note the different check box colors. If a certain type of data is orange-colored, it means that the category is end-to-end encrypted, and you will require a screen lock passcode or a system password of one of the user’s trusted devices. If you don’t know the passcode, clear all end-to-end encrypted categories.

If you select at least one end-to-end encrypted type of data, Elcomsoft Phone Breaker will download the list of trusted devices.

You will need to select one of the trusted devices, then specify its screen lock passcode or system password to continue.

The data will be downloaded. The download may take a while depending on the size of the data and your Internet connection speed.

Downloading iCloud backups

To download iCloud backups, select the first option in Elcomsoft Phone Breaker.

Provide the user’s Apple ID and password.

Most Apple accounts nowadays are protected with two-factor authentication.

Specify the type of two-factor authentication. The most common types are “trusted device” (sends a push message to all of the user’s trusted devices that are online and connected to Internet), “text message” (an SMS to the trusted SIM card), and “code generator” (a time-limited one-time password generated from the Settings app on a trusted device, which may remain offline). The authentication process is self-explanatory.

Once you’ve passed two-factor authentication, you will be able to see the list of available backups. Some devices may have several snapshots, which are incremental backup copies. Currently, Apple keeps up to two snapshots per device. Click “See details” to view snapshot data. Elcomsoft Phone Breaker will download all snapshots, and produce the complete backups for each snapshot. The available options are:

Restore original file names: gives extracted files the same names as on the device. Select this option if you plan to manually analyze the backup. Keep it clear if you are planning to use a third-party forensic tool to analyze the data.

Download only specific data: selective download, allows quickly extracting only the essential bits and pieces. Keep it clear if you are planning to use a third-party forensic tool to analyze the data.

Click “Download” to download the backup. The process may take a while.

Once the backup is downloaded, you may open it in Elcomsoft Phone Viewer by clicking the “Open in EPV” link. Clicking on the “eye” icon opens the folder containing the backup in File Explorer (Win) or Finder (Mac). Third-party tools can be used to analyze iCloud backups downloaded with Elcomsoft Phone Breaker if you keep both options “Restore original file names” and “Download only specific data” clear.

Advanced logical acquisition is the most compatible and least complicated way to access essential evidence stored in Apple devices. In legacy versions of iOS Forensic Toolkit, we offered a 1-2-3 style, menu-driven extraction experience, while the updated release of iOS Forensic Toolkit 8.0 is driven by the command line. In this quick-start guide we will lay out the steps required to extract the most amount of data from Apple devices via the advanced logical process.

What is advanced logical acquisition?

Advanced (or “extended”) logical acquisition is an unofficial name for a set of data extraction methods available for all iPhone, iPad, and iPod Touch devices regardless of the version of iOS installed and regardless of the hardware platform. Advanced logical acquisition includes the extraction of a local backup, media files, shared files, and system crash logs and diagnostic logs. You must be able to unlock the device and pair it to the computer, which requires a screen lock passcode.

An iTunes-style backup is part of the logical extraction process. In iOS and iPadOS, local backups may be protected (and securely encrypted) with a password. Such password-protected backups have more information available to the examiner compared to unencrypted backups. For this reason, we recommend setting a temporary backup password (e.g., ‘123’) before creating a backup, which requires a confirmation with a screen lock passcode. Do not forget removing the temporary password when you are done; more on that in iOS Backups: Leftover Passwords.

Note that you can only change the backup password if the original backup password is known or empty. If the device has an unknown backup password, we recommend creating a backup nevertheless. After that, consider resetting the backup password with “Reset All Settings” (not to be confused with “Erase content and settings”, which factory-resets the device).

Note: changing a backup password in recent versions of iOS requires a screen lock passcode.

In addition to local backups, extended logical acquisition returns media-files, some diagnostic logs and shared app data. Additional information on logical acquisition is available in the following articles:

• Logical Acquisition: Not as Simple as It Sounds
• Demystifying Advanced Logical Acquisition

Extended logical extraction cheat sheet

To perform complete logical extraction, follow the steps:

1. Connect the iPhone to the computer’s USB port.
2. Once the iPhone is connected to the computer, you will be prompted to establish trust between the device and the computer. On the device, confirm the pairing prompt and enter the screen lock passcode. If the device was not automatically paired, you will need to manually pair the device to the computer by running the following command:

   ./EIFT_cmd normal pair

   On the phone, confirm the “Trust this computer?” prompt.

3. On the phone, you may be prompted for a passcode if the device is running a recent version of iOS. Enter the screen lock passcode to confirm pairing.
4. Extract information about the device:

   ./EIFT_cmd info

5. Check if a backup password is set:

   ./EIFT_cmd normal backuppwcheck

   If you are using an external pairing record file, pass it in the command line. Note: if this is the case, you will have to use the -r switch along with the path to the pairing record for all subsequent commands:

   ./EIFT_cmd normal backuppwcheck -r record.plist

   Check the output, looking for “Backup password” status:

   Started logging Thread!
   Got device:
   Mode: [normal]
   BuildVersion: 16H50 
   DeviceName: iPhone 
   HardwareModel: N53AP 
   Paired: YES 
   PasswordProtected: NO
   ProductName: iPhone OS 
   ProductType: iPhone6,2 
   ProductVersion: 5.4
   SerialNumber: <serial number> udid: <udid>
   Loading custom record from=record.plist 
   Checking backup password...
   Backup password is DISABLED 
   Done

6. If the backup password is enabled, make a password-protected backup nevertheless. After that, consider resetting the backup password with “Reset All Settings” (not to be confused with “Erase content and settings”, which factory-resets the device). To reset the backup password, follow Apple instructions: “On the iPhone, go to [Settings] | [General] | [Reset]. Press [Reset All Settings]; Follow the steps (you will be prompted for device passcode).”
7. (optional step) If the backup password is empty, you may manually set a known temporary password such as ‘123’. If you don’t, iOS Forensic Toolkit will automatically set a temporary password ‘123’ before the extraction, and remove it afterwards. Either way, the device will prompt for a screen lock passcode. Make sure to enter one quickly as the prompt is only displayed for a limited time.

   ./EIFT_cmd normal backuppwset -p "123"

8. Make a backup (the last parameter specifies using the current folder; you may provide a different path instead of “./”)
   Note: if the backup password is empty, iOS Forensic Toolkit will automatically attempt to set a temporary backup password of ‘123’. During the process, the device will prompt for a screen lock passcode. Make sure to enter the passcode prompted. If you don’t, the prompt goes away in a few seconds, and the backup is created without a password.

   ./EIFT_cmd normal backup -o ./

   If you are creating a large backup, you may want to use an external disk as a destination. In that case, use the following syntax:

   ./EIFT_cmd normal backup -o /Volumes/DISKNAME

   DISKNAME is the name of the disk as displayed in Finder. Note that the backup contains multiple files. If you need to attack the backup password, you will only need a single file named manifest.plist.

9. If you have manually enabled a backup password during Step 7, remove that temporary backup password. If you haven’t, iOS Forensic Toolkit will automatically remove the temporary password. Either way, the device prompt for a screen lock passcode. The prompt will be shown for a limited time. If you miss the prompt, the command will finish, while the temporary password will  still be enabled on the devide. In this case, you will have to manually remove the backup password. In the example below, “123” is the previously set password. It must be provided as an argument:

   ./EIFT_cmd normal backuppwunset -p "123"

10. Extract media files via afc. Note that the afc protocol returns media files regardless of the backup password, and is available on Apple TV and Apple Watch devices as well as the iPhone and iPad. In addition to photos and videos, afc returns valuable metadata.

    ./EIFT_cmd normal dumpafc -o afcdump.tar

    If you need to save the file in a different folder or disk, use the following syntax (also applies to subsequent commands):

    ./EIFT_cmd normal dumpafc -o /Volumes/DISKNAME/afcdump.tar

11. On the iPhone, generate sysdiagnose logs. To do that, hold Vol+, Vol- and Power buttons for 250 milliseconds, then wait up to 5 minutes.
12. Pull crash logs and diagnostic (sysdiagnose) logs:

    ./EIFT_cmd normal dumpcrash -o crashlogs.tar

13. Extract shared files (the command below uses a file named “container.tar” in the current folder):

    ./EIFT_cmd normal dumpshared -o container.tar

14. Decrypt the backup with Elcomsoft Phone Breaker or open it directly in Elcomsoft Phone Viewer providing the known backup password (e.g., 123).

TL&DR

Here is the short list of all commands you will need most of the time to perform advanced logical acquisition:

./EIFT_cmd info
./EIFT_cmd normal backup -o ./
./EIFT_cmd normal dumpafc -o afcdump.tar
./EIFT_cmd normal dumpcrash -o crashlogs.tar
./EIFT_cmd normal dumpshared -o container.tar

Using lockdown records (pairing records)

Lockdown records, or pairing records, are files containing cached authentication data for accessing trusted iOS devices without the need to re-pair them to a computer. In specific circumstances (the device’s screen is locked, the screen lock passcode is unknown, and the device’s USB port is not locked with USB restricted mode), a lockdown record may be used to perform advanced logical acquisition of a locked device. Today, the use of lockdown files is limited since lockdown files expire quickly.

The lockdown files are stored in the following folders.

Windows Vista, 7, 8, 8.1, Windows 10 and 11:

%ProgramData%\Apple\Lockdown

Windows XP:

%AllUsersProfile%\Application Data\Apple\Lockdown

macOS:

/var/db/lockdown

When performing live system analysis, a permission change is required to access lockdown files. More information on extracting lockdown files: Accessing Lockdown Files on macOS

When performing advanced logical acquisition, using a lockdown file requires an argument added to each command. For example, device information (also available in BFU mode) will use the following syntax (replace “record.plist” with a path to a lockdown file; please observe the UDID listed in the lockdown file, which must match the UDID of the device being extracted):

./EIFT_cmd info -r record.plist

If you were unable to unlock the device with a certain lockdown file, you may try other lockdown files obtained from that computer (once again, observe the UDID match). If still not successful, the lockdown record may be already expired, in which case you will need to unlock the device and establish a new pairing relationship, which requires a screen lock passcode.