Tag: Digital Forensics

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!