The majority of mobile devices today are encrypted throughout, making extractions difficult or even impossible for major platforms. Traditional attack vectors are becoming a thing of the past with encryption being moved into dedicated security chips, and encryption keys generated on first unlock based on the user’s screen lock passwords. Cloud forensics is a great alternative, often returning as much or even more data compared to what is stored on the device itself.

The challenges of device forensics

The past years introduced a number of challenges to mobile forensic experts. It’s been a while since device encryption killed chip-off analysis, but there are more challenges than that. A few years back, Apple introduced USB restrictions, making data preservation a challenge. The release of the A12 platform patched the very effective checkm8 acquisition and made device unlocks more difficult.

In the land of Android, Google had finalized the move from the less-secure Full Disk Encryption (FDE) to the much more robust File-Based Encryption (FBE) that uses an encryption key based on the user’s screen lock password, rendering EDL extractions nearly useless without knowing the correct passcode. In many cases, experts could work around the FDE; however, the newer FBE encryption is a real challenge.

With passcode unlocks becoming more difficult with each generation of mobile devices, device forensics become more and more difficult year over year.

The benefits of cloud forensics

Cloud forensics overcomes most of the challenges associated with analyzing physical devices, while adding a share of other challenges. Compared to analyzing a single device, cloud forensics offers the following benefits:

• Authenticating into a cloud account is easier than unlocking a device. The password may be obtained from multiple sources (more on that in the next chapter), while the screen lock passcode is rarely stored anywhere.
• Government requests. Starting with iOS 8, Apple stopped accepting physical devices for extraction. However, the company readily serves government requests, returning iCloud data (except end-to-end encrypted types). Google and Microsoft do not use end-to-end encryption to the extent of Apple, and return nearly all information collected from their users.
• Limited token-based authentication. If you have access to the user’s computer, you may be able to use a token to authenticate into a cloud account. For Apple devices, this only works to a limited extent: you can only use macOS tokens, and only on the very same macOS computers they were extracted from, and even then you need an authenticated user session (or must know the account password).
• More information than a single device contains. This is especially true for Android as Google accounts typically hold years worth of historical data such as location information and browsing history. For Apple devices, cloud synchronization aggregates information submitted by all devices signed in to the same Apple ID.
• Data accessible even if the device is broken, locked or missing. You don’t need the device itself to pull data from the cloud (except for passing the 2FA challenge in certain cases).

The challenges of cloud forensics

Just like device forensics, cloud forensics has challenges on its own. The obvious challenge is the password: you won’t be able to authenticate into a cloud account without proper credentials. The password, however, may be obtained from one of the many sources, such as:

• Microsoft Account: browser stored passwords (with Elcomsoft Internet Password Breaker); brute-force cached Windows account credentials with Elcomsoft Distributed Password Recovery (if Microsoft Account is used for Windows 10 sign in); other devices and cloud services (e.g. Google Account with Elcomsoft Cloud Explorer, iOS keychain, macOS keychain, password manager apps and so on).
• Apple ID/iCloud: browser stored passwords; other devices and cloud services (e.g. Microsoft Account, Google Account).
• Google Account: browser stored passwords; other devices and cloud services (e.g. iCloud Keychain, Microsoft Account).

Two-factor authentication has been a major part of the authentication process for a long time. In recent years, Apple requires the use of two-factor authentication with all newly created Apple IDs (an exception is made for children accounts). In our experience, real-world use of two-factor authentication for Apple account has reached 90%. Overcoming the challenge of two-factor authentication may be as easy as pulling a trusted SIM card or as difficult as attempting to unlock a device or searching for a trusted FIDO U2F security key.

Then comes encryption. Zero-knowledge end-to-end encryption is commonly used by cloud services to protect essential bits and pieces of information. The protected bits and pieces become unextractable without additional steps. The “zero-knowledge” part means that the cloud service provider does not know and does not have access to such encrypted data, and is unable to provide such data to the law enforcement when serving government requests. The different cloud providers protect different bits and pieces, Apple leading the way in most regards. Below is the list of data protected with end-to-end encryption by major cloud services.

• Microsoft Account: Microsoft does not seem to be using end-to-end encryption. Everything is accessible with regular authentication.
• Apple ID/iCloud: lots of data uses end-to-end encryption, requiring the screen lock passcode or system password of any device enrolled into the trusted circle. See below for the full list.
• Google Account: Android backups starting with Android 9. Restoring such backups onto a new device requires entering the screen lock passcode of the original device.
• Amazon (consumer accounts): Amazon is not known to use end-to-end encryption for any of its consumer products (e.g. Kindle, FireOS and FireTV devices).
• BitWarden (password manager): all passwords are end-to-end encrypted with master password.

For Apple ID/iCloud, end-to-end encryption protects the following (iOS 14 and 15):

• iCloud Keychain
• Messages (SMS, iMessages, attachments)
• Apple Maps (searches, routes, frequent locations)
• Safari history (since iOS 13)
• Apple Health
• Screen Time
• Home data
• Voice memos

More on end-to-end encryption in iCloud Backups, Synced Data and End-to-End Encryption.

Authentication and encryption issues aside, there are other challenges to cloud forensics. The communication protocols are largely undisclosed and are constantly changing. Apple does everything it can to prevent third-party tools from accessing iCloud backups, going as far as requiring a valid Apple device hardware ID in order to release the data. Google makes constant changes to the various communication protocols and authentication methods, making it difficult to cope. Microsoft uses a complex synchronization protocol that is very difficult to grasp; it’s so difficult that even Microsoft’s own products (such as the iOS version of its Edge browser) may be unable to sync data they should be syncing.

Conclusion

Cloud forensics is the future. There are many challenges in cloud forensics, with more and more data being moved under the end-to-end encryption umbrella. At the same time, governments actively resist end-to-end encryption in the cloud, making major parts of user data (such as the photos) stored with no encryption, conveniently scannable for controversial materials.

Switching the iPhone into DFU mode is frequently required during the investigation, especially for older devices that are susceptible to checkm8 exploit. For newer devices that are locked with an unknown passcode or disabled one can still learn something about the device through DFU (in particular, the bootloader version, which points to the version of iOS installed on the device). However, switching to DFU requires a sequence of key presses on the device with precise timings. If the device is damaged and one or more keys are not working correctly, entering DFU may be difficult or impossible. In this guide, we offer an alternative.

Why you may need DFU mode

Putting the device in DFU mode is required when performing checkm8 or checkra1n extraction of an iPhone 5 or newer, up to and including the iPhone X, or using limera1n for the same purpose. The checkm8 exploit and the checkra1n jailbreak are based on bootloader-level vulnerabilities, and must be installed through DFU. You also need DFU when performing passcode unlocks (currently, our software supports the iPhone 4, 5 and 5c unlocks only). You can also use DFU for limited “Before First Unlock” (BFU) extractions. Finally, DFU can be used to reset a locked phone (although you’ll be facing iCloud lock when setting it up, and all the data will be irreversibly gone). For all these purposes, use Elcomsoft iOS Forensic Toolkit.

When DFU fails

The regular way for entering DFU requires a sequence of key presses with precise timings. The sequences may differ across devices. We compiled all known combinations into the DFU Mode Cheat Sheet published in our blog.

Notably, the DFU sequence involves pressing and holding several physical keys on the device for precise amounts of time. If one or more of these keys malfunctions (even an oxidized contact can break the timings), the DFU mode may fail after multiple attempts. Since you cannot force older iOS devices into DFU via software commands, you’ll have to disassemble the device and short some pins to trigger DFU. The procedure is described below.

There are three things that cause the BootROM to enter DFU mode on iOS.

1. A sequence of button presses
2. Failure to load LLB
3. Grounding the DFU pin on mainboard

We will jump straight to the third option, since the first option is well known and the second one is not viable for most forensic use cases.

For diagnostic purposes the mainboard of iOS devices has some test pins exposed. One of them is a pin called FORCE_DFU. At boot the pin is probed by the bootloader and if a voltage of 3.3V is applied, DFU mode is entered. We will explain the procedure in detail using the iPhone5 as an example device.

We will use a wire to connect to PINs on the mainboard in order to enter DFU mode. For other devices the procedure only differs in which particular pin need to be connected with the wire.

You will need the following tools:

• An iPhone device (an iPhone5 in this example)
• Screwdrivers and tools to disassemble the device
• A wire
• A USB cable

I suggest to have someone help you. If you need to perform the procedure alone, the following tools are also recommended:

• A standard charging adapter plugged into a power outlet
• A power outlet with an on/off switch

Instructions:

1. Make sure the device is sufficiently charged, then power it off.
2. Disassemble the device so that you can access the mainboard. Note: It may be required to remove some metal shielding. We recommend to look at iFixit disassemblies.
3. Connect the USB cable to the device. (Do not plug the other side in yet!)
4. Use the wire to connect the following PINs. Then, while holding the wire to the PINs, have a second person plug in the other end of the USB cable to the computer. Hold the wire connected for a few seconds.
5. The screen should stay black and the computer should recognise the device in DFU mode.

If you are performing the procedure alone:

4.1) Plug the other end of the USB cable to the charger.

4.2) Plug the charger to the power outlet with a switch. (Do not turn on the switch yet!)

4.3) Connect the two PINs with the wire.

4.4) With your foot enable the power switch, so that the device is charging now. Hold the wire to the test PINs with your hands for a few seconds.

5.1) The screen should stay black. Note: If the device boots normally, just turn it off and try again.

5.2) If the screen stays black, you can release the wire.

Unplug the USB cable from the charger and plug it into the computer.

The computer should recognize the device in DFU mode.

These pins need to be connected with the wire for the iPhone5.

For other iPhone models, the locations of the DFU pins are marked below.

iPhone 5c

iPhone 5s

iPhone 6

iPhone 6s Plus

iPhone SE (1st generation)

 

Conclusion

In iOS, DFU mode is akin to EDL (Emergency Download) in Android. Forensic specialists can use both modes for similar purposes: performing bootloader-level extractions and limited DFU analysis if the device is locked. Apple has a relatively small number of models, which allowed us to complete this research.

When analyzing connected computers, one may be tempted to pull the plug and bring the PC to the lab for in-depth research. This strategy carries risks that may overweigh the benefits. In this article we’ll discuss what exactly you may be losing when pulling the plug.

Is it powered on, sleeping, or hibernated?

Is the computer powered on, sleeping, or hibernated? If it’s powered on, do you have access to an authenticated user session? Your approach may be different depending on the answers.

Note: this article addresses the various sleep modes in desktop computers only. Laptops, ultrabooks and 2-in-1 capable of “modern standby” or “connected standby” have different forensic implications and are protected in a different manner (via BitLocker Device Encryption).

If the computer is running with an authenticated user session, we strongly recommend scanning the PC for encrypted (and mounted) disks and virtual machines before you do anything else. If there is encryption present, you may lose access to encrypted disks and/or virtual machines once you pull the plug, shut down the computer, log off the current user, allow the computer to sleep or hibernate or even allow the computer’s screen to lock after a timeout.

The reason for this are the security settings available in many crypto containers and encrypted VM apps that unmount encrypted data and delete the encryption keys from the computer’s memory on certain events. Depending on the settings, such events may include:

1. Computer reboot or shutdown, whether clean or forced. Most crypto containers (except BitLocker in TPM mode) will lose the encryption key and require the user to enter the password to unlock encrypted disks or VMs.
2. Sleep or hibernation. The default setting for many crypto containers (including BitLocker in all configurations) is resuming seamlessly after sleep or hibernation. This means that, by default, BitLocker disks will be kept mounted after the computer resumes, and there is no easy way to alter this setting other than modifying the system’s group security policy. VeraCrypt containers, on the other hand, have a handful of settings that, once selected, make VeraCrypt automatically lock encrypted disks and wipe the encryption keys from the memory when the computer enters a pre-configured state. By default, all of these settings are off, so VeraCrypt default behavior is similar to BitLocker.
3. User session is locked. This is a separate state that has a separate configuration setting. By default, no crypto container app unmounts encrypted disks once the user session is locked. However, VeraCrypt has a dedicated setting that does unmount the disk(s) on this condition. The default for this setting is “off”.

The difference between Sleep, Hybrid Sleep, Hibernation and Fast Startup in Windows

There are several low-power options in Windows desktop computers, each carrying certain forensic implications.

Sleep

Sleep is the first-engaged low-power mode in Windows. By default, Windows 10 computers come pre-configured with Hybrid Sleep (see screen shot).

If the “hybrid” option is not selected, when entering this low-power state, the computer will not save the contents of the RAM onto non-volatile media. This results in near-instant transition between active and sleep phases, and near-instant wake. However, if the power is lost while the computer is sleeping (which is exactly what happens when you pull the plug), the entire content of the computer’s RAM is lost.

To prevent this situation, Microsoft developed a so-called “Hybrid sleep” option.

Hybrid sleep

This option attempts to combine the benefits of sleep and hibernation. Once the computer begins transitioning into this low-power state, Windows saves the content of the computer’s RAM into a hibernation file. This file contains, among other things, on-the-fly encryption keys used by crypto containers and encrypted VM apps to access encrypted data on the fly.

If the computer is left connected to a power source, resuming from hybrid sleep is just as fast as resuming from normal sleep. If the power is cut (you pull the plug), the computer resumes from the saved hibernation file without losing the user’s authenticated session or the encryption keys (unless the crypto container is specifically configured to wipe such keys when entering low-power mode).

Hibernation

When hibernating, Windows saves the content of the computer’s RAM into a hibernation file, then switches the computer to the lowest low-power state, in which the computer’s RAM content is not maintained. The hibernation file contains, among other things, on-the-fly encryption keys used by crypto containers and encrypted VM apps to access encrypted data on the fly. Resuming from hibernation takes longer than resuming from the regular sleep mode.

Fast startup

Fast Startup is a feature of Windows 10 designed to reduce the time it takes for the computer to boot up after a gracious shut down (the feature is not engaged between reboots). When enabled, Fast Startup saves a small hibernation file onto the disk. That file basically contains kernel memory and not the user session. Specifically, this file should not contain any encryption keys such as BitLocker’s.

While most crypto containers do not distinguish between the various low-power states, there is one exception: VeraCrypt. In its main Settings dialog, the auto-dismount option is described simply as “Entering power saving mode”, which makes no distinction between the various sleep and hibernation modes. The exception here is buried deep under the “More settings” button:

If you don’t see any mentions of hibernation on that screen, you’re not alone. The affected setting is the last one on the very bottom of the screen, named “Activate encryption of keys and passwords stored in RAM”.

Once the user enables this setting (and restarts VeraCrypt), the app makes sure that the encryption key is stored in the computer’s RAM in an encrypted (or, rather, obfuscated) form. In addition, VeraCrypt makes sure that the key is never saved onto the disk. Since there is no easy way to achieve that goal in Windows, VeraCrypt makes a brutal move by disabling both Hibernation and Fast Startup just to ensure that the encryption key does not land on a disk. A howtogeek article has an explanation:

“Fast Startup can interfere slightly with encrypted disk images. Users of encryption programs like TrueCrypt have reported that encrypted drives they had mounted before shutting down their system were automatically remounted when starting back up. The solution for this is just to manually dismount your encrypted drives before shutting down, but it is something to be aware of. (This doesn’t affect the full disk encryption feature of TrueCrypt, just disk images. And BitLocker users shouldn’t be affected.)”

For this reason, VeraCrypt disables Fast Startup when users enable the encryption of keys and passwords in RAM. If they don’t, the small hibernation file produced by Fast Startup may be scanned with Elcomsoft Forensic Disk Decryptor for TrueCrypt/VeraCrypt OTFE keys (if the computer was shut down graciously, and the user did not disable Fast Startup).

Analyzing the hibernation file

As we figured, the hibernation file is created in the following scenarios:

1. Gracious shutdown, if Fast Startup was enabled in Windows settings.
2. Sleep, if Hybrid sleep was enabled.
3. Hibernation.

The first small hibernation file produced during the shutdown operation if Fast Startup is enabled can be scanned for TrueCrypt/VeraCrypt keys. Hibernation files produced with the second and third option can be scanned for all kinds of encryption keys including BitLocker + TPM.

To scan a hibernation file for encryption keys, do the following.

Launch Elcomsoft Forensic Disk Decryptor. Select Decrypt or mount the disk from the main menu.

In the Key mining options, select “Hibernation file“. If you know which specific crypto container was used, select that one app and deselect the others to speed up the search. If you don’t know what kind of full-disk encryption was used, select all available options. In this case, the search will take longer.

Click Next to begin the scan. Once the keys are discovered, they will be displayed. You can now save them into a file. You can save multiple keys of different types into a single file.

Having the decryption keys, you can proceed to decrypting the disk.

Specify the type of the crypto container, select the file with decryption keys, and click Next.

If the encryption keys have been located, the tool will prompt you to either do full decryption (creating a raw image that can be mounted or analyzed with a third-party tool) or mount the volume into the current system. Mounting is implemented via ImDisk virtual disk driver (installed with Elcomsoft Forensic Disk Decryptor). Normally, you won’t need to change any settings and simply press the Mount button:

As you can see, this method is convenient and efficient. Whether or not you can use it depends entirely on the possibility of acquiring the decryption key from the computer’s hibernation file.

The “Bad Dream” attack on TPM modules

In 2018, researchers Seunghun Han, Wook Shin, Jun-Hyeok Park, and HyoungChun Kim from National Security Research Institute published a paper named A Bad Dream: Subverting Trusted Platform
Module While You Are Sleeping (PDF).  When the computer enters the energy-saving sleep state, the TPM saves its PCR registers in NVRAM, and restores them when the computer wakes up. The researchers discovered that, at this brief moment, the PCR registers can be manipulated, thus reading the chain of trust or modifying its content. The researchers notified major motherboard manufacturers such as Intel, Lenovo, Gigabyte, Dell, and hp, who in turn patched the vulnerability in BIOS updates. However, since few users install BIOS updates, there are many computers still vulnerable to this exploit.

Seunghun Han released two tools: Napper for TPM and Bitleaker. The first tool can be used to test the computer’s TPM chip for the “Bad Dream” vulnerability, while the second tool is the actual exploit one can run if the TPM module has the unpatched vulnerability.

The second tool requires manually creating a Live CD with Ubuntu, compiling and installing Bitleaker according to the manual. You will need to disable Secure Boot to run the tool. The alternative way would be signing the modified bootloader and kernel with your signature and adding the public key to BIOS; this, however, defies the purpose as it alters the content of PCR registers.

 

In just a few weeks, the new iPhone range will be released. Millions of users all over the world will upgrade, migrating their data from old devices. While Apple has an ingenious backup system in place, it has quite a few things behind the scenes that can make the migration not go as smooth as planned. How do you do the migration properly not to lose anything?

Do you remember the times when you could just push the SIM card into your new phone and call it a day? The only “customization” available was your phone book, and that was stored on the physical SIM card. Even if your phone was capable of keeping the contact list, you could always save it onto the SIM card if you wanted to, subject to the limited SIM memory size. With time, some vendors started offering PC tools to save and restore phone data, but those were usually limited to the contact list and some bits of extra data such as notes.

Today’s smartphones have infinitely more data to transfer. All models are capable of holding tons of information, and if you want your new device to look and work just like the old one (but better), you’ll need to spend some time. But if you are in the Apple ecosystem and your new phone is an iPhone as well, the migration is much easier, although there are a couple of tips we wanted to share with you.

My personal experience starts with the iPhone 3GS (released in 2012). I dragged my data consecutively from that iPhone all the way to my current iPhone 12 Pro Max; no doubt I will move it to my new iPhone 13 (or whatever it’s called) once it is released. I had some of my phones lost, stolen and broken; I also do the backup and restore process with many test devices in our lab, so I can probably do that with my eyes closed.

Having said that, Apple offers several data transfer mechanisms, and they are not the same. Which one to choose if you want to keep as much data as possible?

Before you begin

Make sure both iPhones are fully charged, and the target device is not locked. Even more important is that your new iPhone runs the same or newer version of iOS as the one you want to transfer the data from (except for the “sync” option that works regardless of iOS versions). This means that once you receive a new iPhone, normally you cannot start restoring it from the backup or using the old other device right after turning it on. You’ll have to first set up the iPhone as a new device, then to the update, then reset to factory settings, and only then – finally! – restore it from your backup. The reason is simple: you usually keep your iPhone updated, so most probably it is running the latest version of iOS, while the new device may ship from the factory with an older version of iOS, which must be updated to receive the backup.

Why does it have to be so complicated? Why does Apple just not update iOS before the restore? The company is silent on that.

Option one: iCloud sync

This is the fastest and easiest method that is familiar to all Android users. You do not actually need to do anything special other than making sure your iPhone is set up to sync as much as possible with iCloud (Settings | Apple ID | iCloud):

Simply connect your new device to your Apple ID, wait until it completes syncing, and you are there. No computer is needed, but your iCloud plan should have enough space to keep all the data.

Using this option, only essential pieces of data will be synced such as your contacts, bookmarks, browsing history, etc. If you enable iCloud Photo Library, your photos will also be synced, but again, make sure to double-check that you have enough space in your iCloud account first.

While setting up your new iPhone, you will be prompted for the passcode of the old one. This is done in order to add the new device to the “trusted circle” so that it gets full access to iCloud keychain and “end to end encrypted” data.

Using this option, you will not get everything back; far from it. Some apps do not even sync their credentials, let alone their data.

Option two: direct

In modern iOS versions, Apple allows to transfer the data directly from one iPhone to another using the Quick Start option:

Use Quick Start to transfer data to a new iPhone, iPad, or iPod touch – Apple Support

Honestly, we did not test it intensively. What is bad that Apple do not tell much details how it works, wired or wirelessly, and some points are really confusing, like “If you have more than one device, you might also need to enter their passcodes” – may we have some explanation, please? This is probably about “trusted circle” issue mentioned above, yes the information what data is transferred (and probably, synced) is missing.

Option three: iCloud backup/restore

iCloud backups are a thing we know a lot about. They are very close to local backups but not quite the same; a lot of data is missing, and if you want to get (back) as much as possible, you will have to combine restoring from an iCloud backup with syncing.

A quick example. If messages and photos are synced to the cloud, then they are not included into cloud backups. If you want your photos and messages back on your new iPhone, you’ll have to restore, then wait until the syncing completes.

Before iOS 15 there was another potential problem: not enough space in your iCloud account, so your iCloud backup may not fit there (especially if you are using the free 5GB tier). iOS 15 has a great improvement allowing you to create temporary iCloud backups of any size, regardless the space available in your iCloud account, see iOS 15 Forensic Implications: Temporary iCloud Backups.

Oh btw, in case you did not know: Apple does not offer any options to work with iCloud backups but only let you restore new devices from them. You can use Elcomsoft Phone Breaker to download them (in standard iTunes-like format), though.

The best choice: a local backup (with a trick)

This is the only method that restores as much data as possible, and it is also the fastest. Simply create a local backup with iTunes (Windows) or Finder (macOS). Yes, you need a computer for that, and a wire. We recommend reading the following article first: Backup methods for iPhone, iPad, and iPod touch – Apple Support. The process is simple and straightforward, well documented, and rarely fails (though it still may).

So what’s the trick? It’s the most important part: make sure to protect the backup you create with a password! If you do, you’ll be able to restore significantly more data onto a new device compared to a plain backup without a password. Read the following article for details: About encrypted backups on your iPhone, iPad, or iPod touch – Apple Support. In particular:

The Encrypt backup feature in the Finder or iTunes locks and encodes your information. Encrypted backups can include information that unencrypted backups don’t:

*    Your saved passwords
*    Wi-Fi settings
*    Website history
*    Health data
*    Call history

Naturally, you will need to supply the backup password during the restore process.

Still, not all the data is restored, and there is absolutely no way to transfer the remaining part like some application data, a lot of system artefacts, location data (including, but not limited to, Significant Locations) and much more. What you can do is just extract (and saved for analysis?) this data using Elcomsoft iOS Forensic Toolkit.

What to do next?

Let me give a word to Apple, this is also well documented:

Finish setting up your iPhone, iPad, or iPod touch

And last but not least:

What to do before you sell, give away, or trade in your iPhone, iPad, or iPod touch

Conclusion

Your new phone offers multiple choices. It is up to you how to transfer the data. Depending on the path you choose, you will get a different outcome. If you only use your iPhone just to make calls, swapping the SIM card may still work for you. If not, use one of the options we listed above.

iMessage, Hangouts, Skype, Telegram, Signal, WhatsApp are familiar, while PalTalk, Pigin, Psi Jabber client, Gadu-Gadu, Gajim, Trillian, BigAnt or Brosix are relatively little known. The tools from the first group are not only more popular but infinitely more secure compared to the tools from the second group. In this publication we’ll review the authentication methods used by the various instant messengers, and attempt to extract a password to the user’s account.

Do instant messengers store passwords?

Many modern instant messengers gave up using passwords for authentication purposes, let alone store them on the user’s device. How does authentication work in that case, and what do they use instead?

WhatsApp does not use passwords. Instead, the user is authenticated and a new device authorized based on the user’s phone number. Notably, authorizing a new phone with WhatsApp de-authorizes the previously used one. This is exactly what happens when experts use forensic tools to access WhatsApp data, and there is currently no known workaround to prevent such behavior. Users can opt to use a PIN as a second authentication factor, yet such PIN codes are only verified on the server and are never stored (even in a hashed form) on the user’s device.

Telegram uses a somewhat similar authentication method. The original link is established based on the user’s phone number, but the user may optionally set up two-factor authentication with a password. Here, the password is the second authentication factor, while the initial authentication step is a single-use code delivered as an instant message to one of the already authenticated devices or as a text message to the user’s phone number. Quite obviously, the password is verified on the server, and never stored (even in a hashed form) on the user’s device. Unlike WhatsApp, Telegram allows multiple linked devices, so authorizing a new device does not de-authorize any previously used ones. Newly authenticated devices receive full access to the user’s past communication history (except private chats). In addition to the password protecting the user’s Telegram account, the Telegram app installed on a device can be also protected with a passcode. This is a separate setting unrelated to account protection.

In both cases, even if the password is used, it’s never stored on the device, not even as a hash. Therefore, extracting or brute-forcing a WhatsApp PIN or Telegram password is out of the question unless the user keeps them elsewhere (e.g. in iOS Keychain or Web browser).

Skype is a whole new animal. Once an independent instant messenger, Skype is now owned by Microsoft, who pushed Skype logins under the umbrella of Microsoft Account services. Windows 8 and Windows 10 users who sign in to their computers with a Microsoft Account (as opposed to using a standalone login and password) enjoy fully a automatic sign in experience when they launch Skype on their computer.

While Skype does use the login and password authentication, it does not store the password on the computer. However, Windows does – if you use the same Microsoft Account to log into Windows! This fact enables the following possibilities:

• Break Microsoft Account password, if one is used to sign into Windows. This approach won’t work if the user has a local Windows account (and not Microsoft Account). If, however, they do use Microsoft Account credentials to sign in to Windows, the password can be attacked with a high-speed, hardware-accelerated attack that runs on local hardware. Once recovered, the password can be used to access OneDrive data, Skype conversations, and even passwords stored in Microsoft Edge. More information in Analyzing Microsoft Timeline, OneDrive and Personal Vault Files | ElcomSoft blog.To run an attack on the user’s login credentials, one can use Elcomsoft System Recovery to extract password hashes, which can then be attacked with Distributed Password Recovery. The potential roadblocks may include BitLocker encryption and two-factor authentication, which may be requested by Microsoft when attempting to sign in from a new device even if the user never enabled two-factor authentication for their account.

• The password can be also extracted from iOS keychain with Elcomsoft Phone Breaker if the user has an iOS device. You’ll be looking for records containing one of Microsoft-owned domains such as hotmail.com, live.com, outlook.com, microsoft.com, office.com and a few others.
• The password can be also extracted from the user’s Google account with Elcomsoft Cloud Explorer. This only works if the user stored the password on their Android device or the Chrome browser. You will require the Google Account password to extract that data.
• If you have access to a live computer with authenticated user session, you may be able to extract said password from the local Web browser (e.g. Edge, Chrome, Firefox etc.) with Elcomsoft Internet Password Breaker.

• Last but not least, you may be able to transfer the user’s authenticated Skype session from their computer to a different PC, with full access to past conversation histories. The transfer can be performed using Advanced IM Password Recovery.

What about Signal? The PC version of this secure instant messenger does not use a password (and thus does not store it). In order to initialize a new instance of Signal, the user must perform an interactive pairing procedure using their smartphone and the previously authenticated Signal instance. The newly initialized Signal instance does not receive access to past conversations, making such pairing rather pointless from the forensic point of view. The only way to extract Signal conversations from an iPhone is via low-level extraction as shown in this article.

Instant password extraction

Most popular instant messengers are secure, and most of them are neither using nor storing passwords on the computer. However, a great number of communication tools do! The list goes on and on: ICQ and ICQLite, AOL Instant Messenger, AIM Triton, AIM Pro, Yahoo! Messenger, MSN Messenger, Windows Live Messenger, Google Talk, Trillian и Trillian Astra, Odigo, Jabber IM, Miranda, Tencent QQ, Ipswitch Instant Messenger, Psi Jabber client, QIP Infium, Gizmo Project, MySpace IM, Exodus, Gadu-Gadu, Mail.Ru Agent, Just Another Jabber Client, Pidgin and a lot more apps listed on this page either keep a copy of the original password on the computer, or store a password hash that can be transferred to another computer. We’ve also added PalTalk, Pigin, Psi Jabber client, Gadu-Gadu, Gajim, Trillian, BigAnt, and Brosix to the list of IMs we can extract passwords from.

For any app from this list, you can use Advanced IM Password Recovery to extract the login and password. If the password is not stored, you will be able to extract the stored authentication credentials (everything required to log in, including the password hash or authentication token), and transfer the “authenticated session” to another computer.

Additional information

If you are looking for more information about instant messengers, check out Forensic guide to iMessage, WhatsApp, Telegram, Signal and Skype data acquisition in our blog to learn about the extraction of IM data from iOS devices and cloud services.

 

iOS 15 is about to bring a host of new features, some of which will have forensic implications. Today we’ll cover a feature that can help experts do cloud analysis, creating and extracting a copy of the device’s data even if the user does not have enough free space in their iCloud account via temporary iCloud backups. The temporary backups are designed to speed up the migration when changing Apple devices; they are not affected by the storage quota, but have a limited lifetime.

One of the main problems of iCloud forensics (unknown account passwords aside) is the sporadic nature of cloud backups. Experts often find out that a given user either does not have device backups in their iCloud account at all, or only has a very old backup. This happens primarily because of Apple’s policy of only granting 5TB of storage to the users of the free tier. While users can purchase additional storage for mere 99 cents a months, very few do so. iCloud Photos, downloads and other data quickly fill up the allotted storage space, leaving no space for a fresh cloud backup.

Now when you buy a new device you can use iCloud Backup to move your data to your new device, even if you’re low on storage. iCloud will grant you as much storage as you need to complete a temporary backup, free of charge, for up to three weeks. This allows you to get all your apps, data, and settings onto your device automatically. Apple

The ability to wirelessly back up and restore an iPhone is one of the hallmarks of the ecosystem. Currently, users can wirelessly transfer the content of an old iPhone onto a new device regardless of how much free space they have in iCloud. The problem, however, is that the process effectively backs up the original iPhone (which may take a lot of time), and restores the data onto the new device. The migration process occurs much faster without the first step, so in iOS 15 Apple offers an option to back up the iPhone temporarily whenever convenient, then restore the temporary backup onto a new (or even the same) iPhone. Unlike traditional iCloud backups, these temporary backups have the following properties:

• Requires iOS 15 on both devices
• Must be created manually (no scheduled temporary backups possible); device must be unlocked
• Does not count against iCloud storage quota
• Retained for 21 days, automatically deleted afterwards
• Currently, users cannot manually delete temporary backups (might be a bug in the beta version)

Creating a temporary backup

To create a temporary backup, do the following.

1.  Update device to iOS 15.

2. Open the ‘Transfer or Reset iPhone‘ tab (Settings/General/Transfer or Reset iPhone). In earlier versions of iOS this was the ‘Reset’ tab.

3. Click through the information screens.

4. When you create the backup, the Settings app will display its progress (iCloud Backup In Progress).

Once the backup is complete, you can see it in iCloud. Note that the backup does not count against storage quota.

Extracting and analyzing temporary backups

Currently, iOS 15 is still in beta. However, we have already added support for temporary iCloud backups to Elcomsoft Phone Breaker (Forensic edition). You can view these backups with Elcomsoft Phone Viewer. Elcomsoft Phone Breaker is the only tool on the market allowing to extract iCloud backups with no strings attached.

The following screen shot demonstrates how the 8.6GB backup is successfully created in the iCloud account with only 5GB of free storage.

At this time, users cannot manually delete temporary backups. This might be a bug in the beta version of iOS 15.

Conclusion

Temporary backups will have their use in mobile forensics, albeit a limited one. These backups can be only created manually, with the phone unlocked, which raises the question of making a local backup instead, which will contain a larger set of data. For this reason, temporary backups may be handy if you are unable to create or decrypt a local backup, e.g. if the device’s Lightning port is damaged or if you cannot reset the backup password.

With the release of iOS 15, we expect a significant influx of users upgrading to iCloud+ to use features such as Private Relay and Hide My Email. In addition to these features, users will receive 50GB of cloud storage, which will reopen the possibility to create regular cloud backups, decreasing the significance of temporary backups even further.

Established NAS manufacturers often offer some kind of encryption to their users. While anyone can use “military-grade AES-256 encryption”, the implementation details vary greatly. Synology, Asustor, and TerraMaster implement folder-based encryption, while QNAP, Thecus, and Asustor (MyAcrhive) employ full-disk encryption; the full comparison is available here. In this article, we’ll have a look at encryption methods used in TrueNAS, a system commonly used by computer enthusiasts for building custom NAS servers.

What is TrueNAS?

TrueNAS is an integrated open-source software that, once installed on a computer, turns it into a Network Attached Storage device. TrueNAS is based on FreeNAS that was initially released in 2005 by Olivier Cochard-Labbé. The project was soon acquired by iXSystems, a commercial company that continued developing the project. iXSystems split the project into two branches: the free, open-source FreeNAS for the enthusiasts and the commercial but still open-source TrueNAS marketed to enterprise customers. This year, the two branches were merged into a single product (TrueNAS), which was split again into FreeBSD-based TrueNAS Core and Debian Linux-based TrueNAS Scale.

Today, there is only one product (TrueNAS) in two branches:

• TrueNAS Core (based on FreeBSD)
• TrueNAS Scale (based on Debian Linux, currently in beta)

TrueNAS Branches: FreeBSD and Debian Linux

The two branches share a lot of the codebase, but are based on two different operating systems. From the forensic point of view, a major difference between the two branches is in the types of encryption supported.

• FreeNAS and TrueNAS (legacy versions): FreeBSD; GELI (supported)
• TrueNAS Core (FreeBSD): GELI (deprecated) and native ZFS encryption
• TrueNAS Scale (Debian Linux): native ZFS encryption only

As you may notice, TrueNAS Core can still access disks protected with GELI, but GELI is no longer officially supported: this type of encryption is deprecated, and users cannot encrypt newly created volumes with GELI. Users can migrate their encrypted data to use native ZFS encryption instead; however, even that is only supported in TrueNAS Core and not in TrueNAS Scale for reasons outlined below.

What you should know about TrueNAS

TrueNAS is a complex project with loads of features. If, however, your goal is decrypting the data, you must be aware of the following pecularities:

1. TrueNAS is always installed onto a dedicated storage device (hard drive, SSD drive, NVME or USB storage device). The boot device cannot be used to create storage pools. The boot device cannot be encrypted (unless the user activates device-level encryption, which is not a supported scenario). This allows for two things: one can safely move the datasets to a different TrueNAS installation, and one can attempt to extract the stored encryption keys from the boot device.
2. The data can be encrypted with a password or binary encryption key.
3. If a binary encryption key is used, TrueNAS can store the key on the boot device to facilitate automatic unlocks of encrypted datasets. If this is the case, these keys can be extracted from the boot device and used to unlock the encrypted datasets.
4. Native ZFS encryption is not full-disk encryption. Certain ZFS structures remain available without the encryption key for scrubs (integrity checks), snapshotting, replication, deduplication and other tasks accessible via zpool and zfs commands. In particular, one can extract information about the size of the file system; however, the number and sizes of individual files (let alone their content) are inaccessible without the encryption key. In comparison, folder-based eCryptFS encryption employed in Synology, Asustor and TerraMaster appliances exposes information about the file count and file sizes even without the encryption key.
5. The user can pick the encryption algorithm (AES-256-GCM by default) and the number of pbkdf2 iterations if they use passphrase-based encryption (350,000 by default). This choice is saved in encryption metadata; there is no need to guess the number of iterations when launching a brute-force attack.

TrueNAS encryption methods

TrueNAS distributions support several different encryption methods.

SED (Self Encrypting Drive) for SED-capable disks. The feature has a detailed description, which makes its intended function clear: in TrueNAS, SED encryption is designed specifically to protect data at rest. SED makes all ZFS features unavailable until the encrypted drive is unlocked, which, combined with the hardware requirements, makes this a niche solution for enthusiasts. At the same time, SED is commonly used in enterprise environments as the first layer of protection.

A SED-protected disk locked by TrueNAS is no different to a SED-protected disk locked by any other system.

GELI is a legacy encryption method that was used in TrueNAS and FreeNAS systems prior to TrueNAS 12. GELI is a block device-layer full-disk encryption system written specifically for FreeBSD. Since TrueNAS 12, GELI is no longer supported; however, users can still mount existing volumes and migrate them to ZFS native encryption. The migration process is lengthy and intrusive, so some existing users preferred not to migrate. These users may still have GELI-encrypted volumes in their TrueNAS systems.

If you encounter a GELI-encrypted disk, you may be able to mount it through one of the following paths:

1. Accessing encrypted disk(s) through a computer running a new FreeNAS/TrueNAS Core install. The version of TrueNAS should be the same or newer as the original user’s version to avoid conflicts with ZFS metadata version mismatch.
2. Accessing encrypted disk(s) via FreeBSD according to the documentation.

ZFS native encryption appeared in OpenZFS, which is now used in both TrueNAS branches. While ZFS native encryption protects the entire dataset, it is not considered a full-disk encryption. Some ZFS metadata such as the size of the file system (but not the number or sizes of individual files and folders) is exposed even without an encryption key, along with deduplication tables. On the other hand, users can scrab encrypted datasets, perform maintenance operations, create and replicate snapshots and basically do everything that zfs and zpool commands can do. Unlike folder-based encryption methods such as eCryptFS (used in Synology, Asustor and TerraMaster devices), ZFS native encryption allows changing the password without re-encrypting the dataset. Ars Technica published a very nice Quick-start guide to OpenZFS native encryption that is well worth reading.

When creating an encrypted dataset, the user can specify the encryption algorithm (the default is AES-256-GCM) and, in the case of passcode-based encryption, the number of pbkdf2 iterations (the default is 350,000).

Information about the encryption algorithm and the number of iterations is stored in the encryption metadata; you won’t have to guess it when setting up an attack.

The data can be encrypted with a passphrase (text password) or key. If a key is used, it can be stored on the TrueNAS boot device to facilitate automatic unlock of encrypted datasets.

TrueNAS supports inherited encryption settings, enabling inherited or different encryption settings for child data sets.

Importantly, ZFS native encryption is supported in both TrueNAS Core (FreeBSD based) and TrueNAS Scale (Debian Linux based), while GELI is only supported in FreeBSD-based FreeNAS and TrueNAS Core.

By design, ZFS encryption has several weaknesses that leak certain type of information about encrypted datasets. The first piece of information is the name and size of the file system, as well as other information available through the use of the zfs and zpool commands. I want to say it again: unlike eCryptFS, ZFS native encryption does not leak the number and size of encrypted files and folders.

ZFS encryption does not protect deduplication tables, which leaks the addresses of duplicate blocks on the disk (but not the content of individual data blocks). Finally, I will mention the CRIME (Compression Ratio Info-leak Made Easy), which is a theoretical vulnerability describing certain scenarios in which the data is compressed before encryption.

Additional information on ZFS native encryption is available at the following links:

• TrueNAS Core: Storage Encryption | (truenas.com)
• TrueNAS Scale: Encryption | (truenas.com)

How native ZFS encryption compares to other encryption methods

In my review of encryption methods used in commercial NAS appliances I was unpleasantly surprised. Folder-based encryption via eCryptFS, which is a fused encrypting file system, lacks in so many respects that its choice can raise questions. Folder-based encryption is slow, especially on smaller files. It leaks too much information about encrypted data (including the size and number of files in the folders), which enables profiling attacks on encrypted folders. The fact that you cannot (literally!) change the encryption password is just icing on the cake.

Some manufacturers prefer using full-disk encryption (LUKS) instead of or in addition to folder-based encryption. While LUKS is faster, more secure and more convenient compared to eCryptFS (hey, you can change that leaked password!), it does limit functionality: you cannot snapshot LUKS-encrypted volumes without unlocking them first; you can’t do multi-user; you cannot back up or restore encrypted data without providing the encryption key; you cannot scrub the data or perform file system maintenance without providing the encryption key. The many “can’t” are easily possible with eCryptFS, the very encryption option I criticized just one paragraph earlier.

ZFS native encryption addresses all the points of critique mentioned above. Access speed? It’s plenty fast. Changing a leaked password without re-encrypting the dataset? Easily possible. Scrubs and maintenance operations? You’ve got it. Snapshots of locked data sets? Yep. Replication without an encryption key? Doable. Add to that the ability to customize encryption and attack resistance (via a custom number of hash iterations), and you have a nicely balanced encryption scheme.

Does ZFS native encryption have drawbacks? I listed all known weaknesses, most of which are design decisions made to strike the right balance between security, convenience, and functionality. In my opinion, ZFS native encryption is currently the most well-rounded encryption method available for NAS appliances. While it leaks more information about encrypted data compared to LUKS, it’s infinitely more convenient than the former. Compared to folder-based encryption, it’s several generations ahead.

Conclusion

We have not discovered (nor looked for) any major vulnerabilities in the encryption methods supported by TrueNAS. The new ZFS native encryption standard does, but design, leak certain types of data. This is a well-documented phenomenon that is a result of a tradeoff between convenience and security. In our view, the new ZFS native encryption method strikes the right balance between features, convenience, and security, with none of the drawbacks of full-disk encryption and encrypting file systems and most of their benefits.

How do you extract an Apple Watch? While several methods are available, none of them will work if you want to access the device directly without an adapter. There are several different options available on the market, some of them costing north of $200. We tested a large number of such adapters. How do they stand to the marketing claims? In this article, I will share my experience with these adapters.

I will not discuss the extraction methods in this article, but only talk about the hardware parts. In many cases, you can obtain the data collected by the Apple Watch from iCloud. In this case, the data will be limited to Apple Health; and even though Health data is “end to end encrypted”, one can still obtain and decrypt it with Elcomsoft Phone Breaker. Alternatively, a limited amount of information can be extracted from the iPhone the Watch is paired with, or, more precisely, from its backups. In order to be able to acquire the data directly from the Apple Watch, one needs connecting to the hidden service and diagnostics port hidden under the Watch band, and here is where the adapter is absolutely necessary.

It all started with IBUS, an adapter for the original Apple Watch (sometimes referred as S0) and Series 1 Watch (S1):

A similar model became available for the S2/S3 models a bit later. Personally, I do not really like these ones: they are relatively cheap, but they do not work well. You’ll see what I mean when you try establishing a reliable connection.

I’s been a long time since the Apple Watch Series 4 release until the S4+ version of the adapter became available. I sourced as many as three, all from different providers, but none of them worked. At around the same time, we have also discovered a new adapters for the S0/S1 and S2/S3 generation watches. This one was slightly more expensive but of a much better quality. In fact, it looks like it might be a copy of the original adapter that was used by Apple itself. Check out Apple Watch Forensics Reloaded for more details.

I was trying to find an adapter that would work with S4 and newer watches, and finally received one. The renders on the seller’s page were really nice; the reality is a bit worse:

Let’s have a closer look:

I had to clean the contacts thoroughly before it even worked, but anyway, the result is what really matters, right?

Once I tweeted about it, one of my readers replied with a picture of how it looks from the inside when disassembled:

Currently, the “second version” of this adapter is available, and it looks more convenient compared to the original:

I don’t think I want to try it out.

A completely new universal adapter was recently released under the name of MagicAWRT. The provider claims support for all generations of the Apple Watch including S0, S1, S2, S3, S4, S5, S6, and SE. I ordered one immediately; hope it is going to work as good as it looks:

While the new toy is on its way from China (I am going to test it as soon as it arrives), I was able to find another interesting adapter for S4/S5/S6/SE series:

It’s difficult to say whether it this is an authentic Apple adapter or a good copy, but it works like a charm with Elcomsoft iOS Forensic Toolkit:

Make sure to install the sysdiagnose profile and produce logs afterwards:

Happy Apple Watch forensics!

Protecting one’s online privacy is becoming increasingly more important. With ISPs selling their customers’ usage data left and right, and various apps, mail and Web trackers contributing to the pool of “anonymized” data, de-anonimyzation becomes possible with big data analysis. This was clearly demonstrated with the recent event highlighted in Catholic priest quits after “anonymized” data revealed alleged use of Grindr.

“While this might be the first case of a public figure’s online activities being revealed through aggregate data, “it unfortunately happens very often” to the general public, Andrés Arrieta, director of consumer privacy engineering at the Electronic Frontier Foundation, told Ars. “There are companies who capitalize on finding the real person behind the advertising identifiers.” Furthermore, de-anonymizing data in the way The Pillar did is trivially easy. All you need to do to buy the data, Arrieta said, is pretend to be a company. There are no special technical skills required to sift through the data, he added.”

Apple did an attempt protecting their users’ location by introducing approximate locations in iOS 14. That change alone makes analyzing aggregate data from iPhone users more difficult but not impossible. In this publication, we compare the tools to protect one’s privacy online while using Apple iOS devices and desktop computers by making one’s browsing activities inaccessible to the middleman.

Encrypted DNS / DNS over HTTPS

Why would anyone want to encrypt their DNS requests? The reason is very much the same as encrypting HTTPS traffic. “When people access the web within your app, their privacy is paramount”, reads Apple’s 2020 WWDC Keynote. “When your app accesses a website, the system asks a question, a DNS query, to turn that name into a set of addresses. Generally, the question is sent to a DNS server configured by your local network. So where does privacy come into the picture? One concern is that DNS questions and answers are usually sent over an unencrypted transport, UDP. That means that other devices on the network can not only see what names you’re looking up, but they can even interfere with the answers. The other privacy concern is that you may not trust the DNS resolver on your local network. If you’ve joined a public Wi-Fi network, your internet usage could be tracked or blocked.”

“So how does encrypted DNS improve this situation? Encrypted DNS, simply put, is using encryption to protect your DNS questions and answers. And if you don’t trust the network you’re on, it can also involve sending your questions to a DNS server that you do trust.” (WWDC 2020 Transcript)

In Windows, using a secure DNS server is easy if you are using Microsoft Edge. For iOS, you’ll have to install an app or make a profile to use encrypted DNS; more on that later.

Which secure DNS service to choose?

There are multiple secure DNS services around. The most commonly used ones are Cloudflare, Google, OpenDNS, NextDNS, and AdGuard.

Cloudflare has opened its DNS servers to the public in 2018. The company claims its unique WARP technology offers a higher degree of protection compared to other DNS service providers. No logging policy, and the company claims it won’t share the data with advertisers. Link to Privacy Policy (scroll down to Public DNS Resolver Users).

Google Public DNS offers DNS resolution over TLS-encrypted TCP connections. Google is known to go after its customers’ data, and runs one of the largest advertisement networks. The data is collected according to the company’s Privacy Policy. Whether to trust Google your DNS queries is your decision.

OpenDNS is a public DNS service. In 2015 it was acquired by Cisco. OpenDNS has a controversial privacy policy allowing the company to keep logs of DNS queries for 2 business days if the user has no account with the company. Users with accounts can optionally select a different retention setting or opt out of the logging. Note that the name “OpenDNS” refers to the DNS concept that queries are accepted from any source. It is not related to open source software.

NextDNS advertises a zero logging policy, which is active by default for all users. Users can create an optional account, in which case NextDNS keeps 3 months worth of logs with an option to turn off the logging entirely.

AdGuard is a relative newcomer advertising strict zero-logging policy for its DNS services. In addition to resolving Internet addresses, AdGuard DNS service can automatically filter out ads, malicious websites, tracking, and phishing.

LibreDNS

This is a public encrypted DNS service run by LibreOps, an organization that contributes to other free, open source technologies, that people can use to maintain secrecy of their DNS traffic, but also circumvent censorship. The company keeps no logs, detailing that logs are disabled for their DNS daemon. In addition, the company claims to use a local resolver for the DNS requests, and OpenNIC as their Tier 1.

Using encrypted DNS in iOS 14 and newer

Starting with iOS 14, Apple natively supports encrypted DNS. However, if you try searching through the Settings app, you will find no mention of it anywhere. The support for encrypted DNS is there, but the setting is not. In order to actually use a different (secure) DNS server, you will have to download a third-party app, or install a third-party configuration profile.

There are several apps in the App Store offering encrypted DNS services such as Cloudflare, AdGuard and ‎NextDNS. If you’d rather install a configuration profile for a particular encrypted DNS service without using an app, you can create a custom NextDNS profile for your device, or download a ready-made, pre-signed one by paulmillr/encrypted-dns:

• OpenDNS
• Cloudflare
• Quad9
• Google

Paul Miller’s article on iOS 14, Big Sur & DNS over HTTPS / TLS is also worth reading.

Using encrypted DNS in Windows 10

As of today, windows 10 does not have a system-wide setting allowing to use encrypted DNS services. However, you can enable encrypted DNS in Microsoft Edge by choosing the corresponding service or entering a custom one under Privacy, search & services > Security (or by simply entering “DNS” in the Settings search box):

A matter of trust

How much protection does a public secure DNS service add compared to using your ISP’s default DNS servers? “If your ISP is no longer resolving DNS addresses, someone else must be doing it? Today, it’s probably cloudflare with its 1.1.1.1 public DNS, or google (8.8.8.8). So, instead of letting your ISP monitoring your DNS traffic, Cloudflare or Google will do it. Of course, they can sell collected data, or use it to create a dossier on someone.”, says Paul Miller. Indeed, while your ISP will be unable to clearly see which Web sites you visit, the public DNS service of your choice will. The choice of such service then becomes purely a matter of trust.

Key points:

• Your ISP or any other intermediary will not know which Web sites (domain names) you visit
• The IP addresses, however, will be still accessible
• The DNS service provider will see your requests; read their privacy policy and choose wisely
• Web site owners and trackers will see your real IP (and may be able to determine your location via reverse lookup)
• DNS requests are encrypted; the actual traffic is not (unless HTTPS)
• In iOS, DNS requests originating from Safari and all other apps are encrypted
• In Windows, only Microsoft Edge DNS requests are encrypted (other apps require separate settings; non-encrypted third-party DNS may be configured via network settings)

iOS 15 Hide IP Address

Hiding one’s IP address in Safari is a part of Apple’s Intelligent Tracking Prevention.

Starting with iOS 15, users will be able to hide their IP addresses from trackers and Web sites with a new privacy-centric Safari feature. This feature is not to be confused with Apple’s another new privacy feature called Private Relay. The Hide IP Address feature will be available for all users with iOS 15, while Private Relay is part of the pair iCloud+ subscription.

The new feature adds an option in Safari settings named “Hide IP Address” with the choice of “Trackers only” and “Trackers and Websites”, effectively allowing to hide your real IP address from online trackers that load alongside websites. The point of this feature is restricting access to your real location data, which can be traced via an IP geolocation database.

With iOS 15 still in beta, little is known about this feature.

Key points:

• Free service available to all Safari users in iOS 15
• Traffic encryption: unknown
• DNS encryption: unknown (but unlikely)
• Generally, the feature offers limited privacy protection in Safari only

iOS 15 Private Relay

According to Apple, “Private Relay is a new internet privacy service that’s built right into iCloud, allowing users to connect to and browse the web in a more secure and private way. When browsing with Safari, Private Relay ensures all traffic leaving a user’s device is encrypted, so no one between the user and the website they are visiting can access and read it, not even Apple or the user’s network provider. All the user’s requests are then sent through two separate internet relays. The first assigns the user an anonymous IP address that maps to their region but not their actual location. The second decrypts the web address they want to visit and forwards them to their destination. This separation of information protects the user’s privacy because no single entity can identify both who a user is and which sites they visit.”

What is Apple Private Relay exactly, and how does it compare to a VPN service? This is what we know at this point What is Apple Private Relay and is it worse than a VPN? | TechRadar (updated with comments from various VPN providers). According to this, Apple Private Relay looks a lot closer to Tor rather than a VPN. “Tor also uses a system where your connections are routed through multiple relays. But while Apple stops at two, Tor defaults to three, and there can be many more. These are all run by volunteers, too, greatly reducing the chance that any one person can track what you’re doing, and we’ve seen arguments that this makes Tor safer than Private Relay”, says TechRadar’s Mike Williams.

Key points:

• Apple Private Relay is available as part of paid iCloud subscription
• Limited to 50GB of monthly traffic with basic subscription
• Protects activities in Safari and apps with insecure connections (HTTP rather than HTTPS) by passing encrypted traffic through two hoops
• No device-wide traffic encryption
• IP address in geographical proximity used by default; users can select a wider region
• Encrypts both DNS queries and traffic
• Apple hasn’t released any details about who runs the Private Relay network (early hints point to Cloudflare, Fastly and Akami)
• Whoever those providers are, they won’t see who is visiting what (two hops, full anonymization)
• The feature will not work where it’s needed the most: Apple has confirmed that the feature will not work in China, Belarus, Colombia, Egypt, Kazakhstan, Saudi Arabia, South Africa, Turkmenistan, Uganda and the Philippines.

More information: No, Apple’s Private Relay is not a VPN – CNET, iCloud+ Private Relay explained: Don’t call it a VPN | Macworld.

Using Private Relay

Once iOS 15 is released, paid iCloud subscribers will be able to activate the new service by enabling Private Relay in iCloud settings.

Tor browser

Tor ensures fully encrypted and completely private Web browsing experience – if you opt to use a particular Web browser app. The Onion protocol routes encrypted traffic through three independent hops, making it (theoretically) impossible to intercept traffic even if one of the nodes is compromised. In real life, Tor protection is not as impenetrable as the theory claims, yet it’s much more than enough for the simple purpose of preventing someone from running a big data analysis attack against you.

For most platforms other than iOS, the Tor browser uses a modified version of Firefox. The browser runs in the incognito/private mode by default, which means no history is left and no cookies are kept on the device once you close the browser.

Things are different in the iOS land. In Can I run Tor Browser on an iOS device?, the developers recommend an iOS app called Onion Browser, which is open source, uses Tor routing, and is developed by someone who works closely with the Tor Project. However, according to the developers, Apple requires browsers on iOS to use something called Webkit, which prevents Onion Browser from having the same privacy protections as Tor Browser.

Should you use the Tor browser? On the one hand, it’s a complete overkill for the simple purpose of preventing tracking. On the other, you’ll be tied to a particular Web browsing app with missing cloud synchronization and deprived of the many convenience features one comes to expect from a modern Web browser. It’s probably okay on occasions, but using Tor all the time for the sole purpose of preventing tracking would be a massive overkill and a major inconvenience.

Key points:

• Protection only within a certain browsing app (Tor browser on desktops, Onion Browser in iOS)
• Your ISP or any other intermediary will not know which Web sites you visit, including their IP addresses
• Web site owners and trackers won’t see your real IP
• Both DNS requests and traffic are encrypted (even plain HTTP)
• Less protection (but still major inconvenience) in iOS due to Webkit

Proxies

The idea behind using a proxy is relaying traffic through an intermediary (proxy) server. This will hide your real IP address (and the location associated with that IP address) from Web sites and trackers. However, most proxy servers do not encrypt traffic, leaving your communications vulnerable to deep packet inspection. Note that, depending on the type, proxy servers may not be completely transparent, and may require additional configuration in some apps.

Key points:

• Protection within supported apps
• Your ISP or any other intermediary will not easily know which Web sites you visit, including their IP addresses
• …unless deep packet inspection is used
• Web site owners and trackers won’t see your real IP
• The traffic is tunneled but not encrypted
• Less protection compared to VPN but similar inconvenience factor

VPN

A VPN service creates a secure, encrypted tunnel to route all your traffic from your device to the end point. Nobody can see what is flowing through the tunnel; not even your ISP. A VPN service encrypts everything: your DNS requests, the sites you visit and their IP addresses, the actual traffic (even plain HTTP) regardless of the protocol. Your ISP will see a single encrypted connection between your device and  one remote server; it won’t be able to see any of your requests other than measure the amount of data flown through the tunnel. VPN services are frequently used to protect personal information, secure access to work locations or local networks in your home, encrypt your internet connection, and keep your browsing activities private.

Sounds too good to be true? A VPN is a double-edged sword. While a VPN service protects your data flow against the prying eye, in return, the VPN service provider itself gains full access to your online activities (naturally, except HTTPS and other encrypted traffic). For this reason, selecting a trustworthy VPN service is utterly important if you want to protect your privacy and not just gift someone your full browsing history.

It is not our intention to review or recommend any VPN service in particular. Do your research, and choose wisely. Several big-name VPN providers are ExpressVPN, NordVPN, PureVPN, Surfshark, CyberGhost, Private Internet Access, Tunnelbear; there are dozens of other VPN service providers of varying quality. If you prefer the big names, you can start by checking out a few articles:

• The best VPN service in 2021 | Tom’s Guide (tomsguide.com)
• The best VPN service 2021 | TechRadar
• Best VPN Service of 2021 | The Top Virtual Private Networks (security.org)
• 10 Best no log VPNs 2021 | Find proven zero log VPNs (proprivacy.com)

If you are after a lesser known one (but be aware of the caveats!) check out this:

• 5 Best VPNs You’ve Never Heard Of for 2021 (Hidden Gems!) (vpnmentor.com)

Also note that some well-known apps from reputable companies (such as AdGuard VPN or Speedtest by Ookla) provide limited VPN services for free while offering paid subscriptions through iTunes.

Technically, public VPN services in iOS are generally provided through dedicated apps made by their respective providers. If you know what you are doing, you can use ‎OpenVPN Connect on the App Store to set up connection to an OpenVPN server, install a VPN profile through iOS settings or manually configure your VPN service through the Settings app.

Key points:

• Device-wide traffic encryption: encrypts and relays all traffic through a secure tunnel
• Impenetrable from the outside
• No full anonymization: the VPN service provider can see your online activities (but won’t have access to HTTPS and other encrypted types of traffic)
• Due diligence required when choosing VPN provider
• Most VPN providers require subscriptions
• Limited free offers are available; few of them originate from reputable sources
• Subject to limitations (number of devices and monthly traffic)
• VPN services may offer services in a wider range of regions
• Both DNS queries and traffic encrypted
• VPNs may or may not work in certain countries (e.g. China)

Choosing the right VPN service provider is probably the most important.

Do:

• Do your due diligence.
• Read the reviews.
• Read the actual policies.
• Approach services offering affiliate programs with skepticism and scrutiny.

Avoid:

• Using “free VPN” apps from the App Store from unknown developers. If they cannot make money by selling subscription, they’ll profit by selling your data.
• Buying a “lifetime” subscription from any service. Many were sold in the early days; few are still around today.
• Signing up for anything without reading the relevant policies.

Conclusion

Which method or combination of methods should you use pick to protect yourself from ISP eavesdropping your traffic on your iOS device? If you are using a trusted VPN service, keep using it: a VPN is enough to protect against all known tracking methods. If not VPN, Apple Private Relay seems like a good option, and is cheaper in the basic level than most VPNs of comparable quality. If you are not using either service, consider configuring encrypted DNS from a trusted provider with a privacy policy that you approve. Enabling “Hide IP address” protection for “Trackers only” in iOS 15 won’t hurt, but I’d be wary using that for “Trackers and Websites” due to connection speed concerns.

Using a proxy server this day and age is a dubious choice due to the same inconvenience factor as a VPN, which offers a significantly higher level of protection. Tor is better used on occasions and not as a main Web browser due to major inconveniences and the lack of cloud sync.

Be aware: if you opt to use a proxy, encrypted DNS or VPN service, you’re trusting your data to a third party. Technically, a VPN service provider can learn your browsing habits; a third-party DNS service will know which domains you resolve. Apple Private Relay and Tor are exceptions due to multiple independent hops used to anonymize your activities.

While we are still working on the new version of Elcomsoft iOS Forensic Toolkit featuring forensically sound and nearly 100% compatible checkm8 extraction, an intermediate update is available with two minor yet important improvements. The update makes it easier to install the tool on macOS computers, and introduces a new agent extraction option.

macOS installation

Elcomsoft iOS Forensic Toolkit is a console tool, similar to many non-commercial forensic software products such as APOLLO, iLEAPP, etc. That does not make it any more complex to use compared to many GUI-based tools as we tried to make the menu-driven, console-based UI very simple and straightforward to use, without the need to set complex command-line parameters. But many of our customers reported problems with… installation. We recently made a Windows installation package to make it easier, taking care of raising privileges and setting up the proper default folders for extracted data. On macOS, however, one still had to do a few things manually: clean the quarantine flag (on Catalina and Big Sur), and tell the OS it was OK to run software from an “unidentified developer” in Security & Privacy settings. While that is not rocket science and most macOS users are familiar with this kind of things, we decided to pack the program (that consist of the script, several auxiliary command-line utilities and some additional data from patched firmware) into a single app bundle. With this, and all you have to do is drag and drop the package into the Applications folder, and run it from there like all other programs.

When you start the program at the first time, the following warning is still shown (as the program is not from Mac App Store); this is normal, just press Open.

Still, GUI is on the way!

New agent acquisition option

This option fixes the extraction of iOS devices with corrupted file systems. If the corruption occurs, the extraction may freeze when attempting to read a corrupted file. Moreover, even logical extraction would fail if the corruption is present.

We’ve added a new option related to agent acquisition. The new option allows you to set the maximum size of the files being copied. If the file system of the device being extracted is partially corrupted, the size reported for a particular file may be really huge (in the exabytes range). We do not know the reason that may be causing that, yet it is a real-life situation we’ve encountered it more than once. When it happens, the agent would simply freeze on copying the file, and the whole process would never complete, although everything is fine with the rest of the files.

Here is what we did: added an option for the maximum file size (you can also use it to skip “normal” yet very large files to speed-up the extraction process); larger files will be just skipped. The default setting is 512 GB, which is more than enough for normal operations, but you can set any size you like. To do that, locate the AcquisitionClient calls with the –image parameter, and add –max_file_size followed by the size and measurement value: k/M/G for kilobytes, megabytes and gigabytes respectively. The resulting string may look like this (an example from macOS, limiting the file size to 8 gigabytes):

"$AGENTDIR"/AcquisitionClient --image --max_file_size=8G -p "$outdir"

Editing the script

Changing some program settings require manual editing of the main script. In Windows, the script is located at the following path (Administrator privileges are required):

C:\Program Files (x86)\Elcomsoft Password Recovery\Elcomsoft iOS Forensic Toolkit\Toolkit.cmd

In macOS (and with the new installer and software packaging), right-click on the Elcomsoft iOS Forensic Toolkit in Applications folder, select Browse Contents from the pop-up menu, then navigate to:

Contents/Resources/macosx/Toolkit.sh

Please edit the script with care, and only do so if you know exactly what you are doing. The options you may need to edit are:

• IPORT: 22 by default, but 44 for BFU acquisition with checkra1n
• AGENT_ID, AGENT_PASSWORD, AGENT_TEAMID: for easier agent installation
• max_file_size: see above

Anything else?

Yes, a few other bits and pieces. First, we fixed a minor problem with the Windows installer: we have realized that one of the runtime libraries was linked dynamically was missing on some legacy Windows 7 systems with no updates, so you had to install the runtime package manually. We’ve fixed that.

Second, we have added a quick reminder to the log extraction process (which is a part of our extended logical acquisition) to install a sysdiagnose profile in advance; that will allow you to get more data. The profiles are available here (for iOS, tvOS and watchOS):

https://developer.apple.com/bug-reporting/profiles-and-logs/

Finally, although there is no official support for M1-based Macs, we have tested the new build and found no problems so far after adding the digital signatures and notarizing all of the toolkit components. All you need to do install Rosetta 2. Even support for legacy devices (based on limera1n and checkm8 exploits) works, though you still need to take care of connections (USB-A cable, no hubs and all that). The upcoming major release with forensically sound checkm8 extraction for newer models will feature native M1 code.

Have you got an Adobe PDF file that you can open but cannot edit, print or copy selected text to the clipboard? There is an easy solution: with just a couple of clicks, the file can be unprotected. Bad news: you’ll need software. Good news: we’ve built one for you.

The Adobe PDF format defines several protection methods. The PDF files can be protected from opening (so the password is required just to open and view the file), or you may be able to open the file without a password, but with certain restrictions applied, e.g. disabling the editing, printing or copying content to the clipboard.

Basic information about PDF protection is available in How to password protect PDF files and Choosing a security method for PDFs; restrictions can be specified in the full version of Acrobat (Standard or Pro, not the free Reader); alternatively, you can protect PDF files online.

Let’s start with the files that are not protected from opening. In Adobe Reader, the Print button is often disabled (grayed out), or you may be able to select the test, but there is no Copy option in the pop-up menu. If you open a file like that in Adobe Acrobat and try to edit it, you will see the following notice:

If you click Cancel, another error is shown:

If the password protects the PDF file from opening, you will see a prompt to enter the password once you try to open the file:

But even with that passwords, some restrictions (edit, copy or print) may still apply; it does not matter that you know the open (encryption) password.

The solution is simple. Download and install Advanced PDF Password Recovery (APDFPR). There are quite a lot of options, but the first thing you do is opening the file with the Open button. If the file is not protected from opening and only has restrictions set, you will be prompted to decrypt it immediately:

Press Yes and select the output file name; the PDF will be decrypted instantly with all restrictions removed. Try opening it now in Acrobat or Reader!

If the file is protected from opening, you will see a different message:

If you know the password, everything is as simple as above; enter the password and press Decrypt now unprotect the file.

What if the password to open (also known as the file encryption password) is not known? It depends on the PDF version and the choice of security options; the password length and complexity. Different PDF versions use different encryption algorithms and encryption key lengths from 40 to 256 bits. In some cases, the ‘open’ password can be removed almost instantly (using our patented Thunder Tables® technology), while strong passwords in recent versions of Adobe Acrobat cannot be recovered in reasonable time. Press Start recovery and attempt a brute-force, dictionary or key search attack, but that’s another story.

Please also note that PDF files may be protected with DRM such as LiveCycle Rights Management. Removing DRM protection is technically possible but may be illegal depending on jurisdiction, so we don’t support it in our software.

Elcomsoft System Recovery is a perfect tool for digital field triage, enabling safer and more secure in-field investigations of live computers by booting from a dedicated USB media instead of using the installed OS. The recent update added a host of features to the already great tool, making it easier to examine the file system and extract passwords from the target computer.

What’s it all about?

Elcomsoft System Recovery is a digital triage tool for examining computers in the field. The tool is particularly useful if the computer being analyzed is locked or is inaccessible due to unknown account passwords and/or full disk encryption. Elcomsoft System Recovery helps overcome the challenger of accessing a locked system, delivering a straightforward workflow for investigating computers in the field. The tool helps access information in encrypted disks and encrypted virtual machines, extract passwords and access encrypted file systems.

Once you get Elcomsoft System Recovery, you first make a portable version of the tool by creating bootable USB media on your computer. The bootable USB media is then used to boot the target computer, the one you will be examining. The ESR bootable media contains a customized version of Microsoft Windows PE with Elcomsoft-developed extras to help you extract passwords, access encrypted disks and examine the file system. The complete step-by-step workflow is available in Elcomsoft System Recovery: a Swiss Army Knife of Desktop Forensics.

The latest update adds a host of powerful features to make file system analysis and password extraction even easier.

Extracting Wi-Fi passwords

Home users frequently re-use passwords. Same or similar passwords built to a limited number of patterns are often used to protect access to online resources, encrypt disks, documents and VMs. Extracting all of the user’s existing passwords offers valuable insight to the way the particular user composes their passwords, drastically reducing the time required to discover the right password and increasing the chance of unlocking secure encryption.

Elcomsoft System Recovery already had the ability to quickly recover simple Windows passwords. Today, we’re adding one more type of passwords to extract: the Wi-Fi passwords. Together with other types of passwords, the Wi-Fi passwords can be added to a highly targeted custom dictionary that can be used to break strong encryption and attack passwords protecting encrypted documents, disks and accounts.

Extracting Windows license keys: why you need them and how to use

One more thing extracted by the latest update of Elcomsoft System Recovery is the ability to reveal Windows product keys. This information is buried deep in the system, and typically is not user-accessible. Elcomsoft System Recovery will instantly reveal the system’s product key, enabling investigators to request Microsoft for information about the owner of the license, which may be a great deal of help when examining a computer from a crime scene.

Password hints and QA

Another important piece of information extractable in the field are password hints, questions and answers. This information is intended to help users recall their forgotten passwords. In many cases, examiners can use password hints and QA to re-create the user’s original passwords. As an example, “questions and answers” may contain a hint that the password contains the user’s place of birth or the name of their spouse or sibling. In that case, the names and places can be added to a custom dictionary for a fast dictionary attack.

FAR Manager

One last thing added to Elcomsoft System Recovery is FAR, one of the most convenient two-panel file managers. The now embedded Far Manager is an open-source tool developed by Eugene Roshal for navigating the file system and managing files and archives. Far Manager works in text mode and provides a simple and intuitive way for performing the most common actions such as viewing files and directories, accessing hidden and system items, copying data and accessing archives.

Conclusion

The already powerful digital triage tool gained additional features. The extraction of Wi-Fi passwords, hints and Q&A for Windows account passwords, as well as the inclusion of the convenient two-panel file manager make Elcomsoft System Recovery the perfect tool for in-field investigations.

Elcomsoft Phone Breaker is not just about Apple iCloud data. It can also download the data from other cloud services including Microsoft accounts. In this new version, we have added support for even more types of data, including Windows 10 Timeline, Account Activity (logins to the account), OneDrive files, recent OneDrive files history, and files from Microsoft Personal Vault. Learn about these data types and how they can help advance your investigation.

Windows Timeline

Windows Timeline is a feature that first appeared in the Windows 10 April 2018 Update. The feature enhances Task View, enabling a glance into the past by displaying the user’s historical activities. The Timeline contains timestamped information about the user’s launched applications, searches, documents, and Web browsing history. Along with Windows jumplists, the feature is little known and rarely disabled, giving a valuable insight into the history of system’s usage.

If the user signs into their Microsoft account, Windows synchronizes the Timeline across devices. This is where we extract it from: Elcomsoft Phone Breaker 9.70 downloads the data, and Elcomsoft Phone Viewer 5.30 displays its content in a convenient layout.

By analyzing the Timeline data, experts can access to timestamped information about the app usage and Web page visits.

In addition to the Timeline, the tool extracts Account Activities detailing the user’s sign-ins to their Microsoft account.

OneDrive and Personal Vault

OneDrive needs no introduction, but the Personal Vault feature is still relatively unknown. According to Microsoft, “Personal Vault is a protected area in OneDrive that you can only access with a strong authentication method or a second step of identity verification, such as your fingerprint, face, PIN, or a code sent to you via email or SMS. Your locked files in Personal Vault have an extra layer of security, keeping them more secured in the event that someone gains access to your account or your device.”

When accessing Personal Vault, one would typically need to pass through all authentication steps: the login and password, and the second authentication step. For most tools, that would mean either no Vault extraction at all or a second, duplicate authentication effort. The newest update to Elcomsoft Phone Breaker can extract files from the user’s Personal Vault without the need to perform an additional (double) authentication.

Step by Step Guide

Extracting OneDrive, Personal Vault and Timeline data with Elcomsoft Phone Breaker is straightforward.

1. Install the latest version of the tool (EPB 9.70 or newer required).
2. Select “Download data from Microsoft account”
3. Authenticate into the user’s Microsoft account with login, password, and two-factor authentication.
4. Choose categories (e.g. OneDrive, Personal Vault, and Timeline).
   
5. Click Continue. The data will be downloaded.

To analyze, follow these steps.

1. Install and launch the latest version of Elcomsoft Phone Viewer (version 5.30 or newer).
2. Select “Microsoft account data”
3. Specify data types for parsing
4. Start analyzing specified data types

Conclusion

Now supporting the widest range of data in multiple cloud services, Elcomsoft Phone Breaker becomes truly indispensable for cloud analysis. The updates are free of charge to existing users with currently valid licenses.

 

 

Released back in 2013, VeraCrypt picks up where TrueCrypt left off. Supporting more encryption algorithms, more hash functions and a variable number of hash iterations, VeraCrypt is the default choice for the security conscious. VeraCrypt has no known weaknesses except one: once the encrypted disk is mounted, the symmetric, on-the-fly encryption key must be kept […]

How to break ‘strong’ passwords? Is there a methodology, a step by step approach? What shall you start from if your time is limited but you desperately need to decrypt critical evidence? We want to share some tips with you, this time about the passwords saved in the Web browsers on most popular platforms.

Breaking passwords becomes harder every day. Vendors are making their apps increasingly tough to break by hardening password protection. They are doing their best to slow down the attacks, often going as far as implementing special tricks targeting GPU attacks specifically, making password attacks run at terribly low speeds. What are your options then? Stored passwords and passwords re-use are often the key. Get the low-handing fruits first by collecting the user’s passwords that are saved in their Web browser.

Windows

Google Chrome? We’ve got you covered. Microsoft Edge (or old-school Internet Explorer)? No problem as well. Mozilla Firefox and Opera? We support them too, as well as several popular Chinese browsers (Tencent QQ Browser, UCWeb UC Browser, Qihoo 360 Safe Browser) and even Tor. All these browsers have the ability to save passwords once they are entered on a Web sites, and we know how to extract and decrypt them. You’ll need an authenticated session to extract most of these passwords from the user’s Windows account. Elcomsoft Internet Password Breaker can also collect POP3/IMAP/SMTP/NNTP passwords, as well as the passwords saved in Microsoft Outlook, Outlook Express, Windows Mail and Windows Live Mail, and Thunderbird.

macOS

In macOS, the passwords are stored in the user’s keychain. To extract them, you will need the keychain database itself (and so physical access to the computer with root privileges), as well as the user’s password. That’s it, the passwords will be extracted and decrypted in seconds, just use Elcomsoft Password Digger (and read Digging Mac OS Keychains to get some insides).

iOS/iPadOS

On Apple mobile devices, the passwords along with other sensitive data such as credit card numbers, encryption keys, certificates etc. are saved in the keychain, pretty similar to macOS. The extraction may be more difficult compared to macOS. The easiest way to access stored passwords is to create a password-protected device backup with iTunes (Windows), Finder (Mac), or any forensic software that supports logical acquisition, then using Elcomsoft Phone Breaker or Elcomsoft Phone Viewer to decrypt the keychain and view the passwords (either tool will work).

Clouds

Cloud accounts are another excellent source of passwords. Four years ago, we discovered a way to extract cloud keychain from Apple iCloud (see Acquiring Apple’s iCloud Keychain). While this method has some limitations (you need authentication credentials and the user’s screen lock passcode), it is really worth it: iCloud saves tons of passwords, and most of Apple users (especially those with more than one Apple device) have it enabled. Use Elcomsoft Phone Breaker to download iCloud keychain as well as many other “end-to-end encrypted” data categories.

Google Chrome, the most popular browser in Windows and Android devices, also saves passwords in the cloud, specifically into the user’s Google Account. The passwords don’t have any special protection and can be easily extracted with Elcomsoft Cloud eXplorer (of course, you’ll authentication credentials to sign in to the user’s Google Account).

What’s next?

All of the tools mentioned above not only allow decrypting the passwords stored in Web browsers but export them into ‘wordlists’ (or ‘dictionaries’). You will have to do some homework: frequency sorting, deduplication etc., and remove passwords that are obviously incorrect (sometimes ‘false matches’ are returned such as base64-wrapped binary data). Then convert the result into Unicode and use as the dictionary in Elcomsoft Distributed Password Recovery.

For more than ten years, we’ve been exploring iPhone backups, both local and iCloud, and we know a lot about them. Let’s reveal some secrets about the different types of backups and how they compare to each other.

Full file system acquisition is probably the best method delivering the most complete data set, but there’s a catch. iPhone backups (both local and iCloud) may contain some data that is not available from the iPhone anymore, and there is no way to recover from the device. Also, there could be several devices connected to the same iCloud account and the data is collected from all of them (if synchronization is enabled, of course). Finally, some records (notes and media files in particular) remain available in iCloud for quite some time (typically one to three weeks) even after they disappear from the Recently deleted folder.

Apart from the device itself, there can be several other sources of data:

• Local (iTunes) backups without a password
• Local (iTunes) backups protected with a password
• iCloud backups
• iCloud synced data (regular)
• iCloud synced data (“end to end” encrypted)

Note that we put encrypted and non-encrypted iTunes backups into different categories, and there is a reason for that. Encrypted backups contain significantly more data than unencrypted ones; in particular, they have Safari browsing history, Health data and keychain. Well, the keychain is always there, but it cannot be obtained from backups that have no password set.

What about iCloud backups? The closest match are non-encrypted local backups. Neither of those contain the following data:

• Safari browsing history
• Maps data
• Call log
• Health data

Anything else? You may also miss Messages (both SMS and iMessage) and media files (pictures and videos).

The reason? Depending on iCloud settings on your device, this data may be synced directly with iCloud, see Use Messages in iCloud and Set up and use iCloud Photos. In that case the synced data is not included in iCloud backups. What does iCloud back up? explains it further:

When you use Messages in iCloud or turn on iCloud Photos, your content is automatically stored in iCloud. That means that they’re not included in your iCloud Backup.

But wait, there is more:

Your iPhone, iPad, and iPod touch backups only include information and settings stored on your device. They do not include information already stored in iCloud such as Contacts, Calendars, Bookmarks, Notes, Reminders, Voice Memos, Messages in iCloud, iCloud Photos, and shared photos. Some information is not included in an iCloud backup but can be added to iCloud and shared across multiple devices like Mail, Health data, call history, and files you store in iCloud Drive.

In fact, this information is only partially correct. Regardless of the settings, Contacts, Calendars, Bookmarks, Notes, Reminders and Voice Memos are still stored in iCloud backups.

There is something special about the call history. If you follow our news, you might remember that we covered it almost five years ago:

• iPhone User? Your Calls Go to iCloud
• iOS Call Syncing: How It Works
• “We take privacy very seriously” – Apple, we do not buy it, sorry

So this is the story: the call history is synced to the cloud, but there was never a setting to control that behavior. There is no such setting even now in iOS 14.6. We learned how to download these call logs in Elcomsoft Phone Breaker, but with the release of iOS 13, they just stopped syncing. Or at least it looked like it. Some people including some of my colleagues reported they get the sync working, while the others (including myself) cannot get it to work. I have a dozen devices connected to my iCloud account, and none of them sync the call logs at the moment. Maybe the reason is that they all run different versions of iOS, ranging from iOS 10 to 14.7 beta. There is also a chance that call logs are synced directly between devices (so true end-to-end encryption, like Screen Time statistics) when they are physically close to each other and maybe connected to the same wireless network (if they aren’t using Wi-Fi Direct), but it never worked for me during the last year or so. And the setting is still missing on the iPhone (although we can see Apple Watch here, which is quite interesting; as far as we know, Apple Watch data only syncs with the phone it is paired with, but not directly to the cloud).

iCloud security overview gives some further explanation on “end-to-end” encryption:

End-to-end encryption provides the highest level of data security. Your data is protected with a key derived from information unique to your device, combined with your device passcode, which only you know. No one else can access or read this data.

These features and their data are transmitted and stored in iCloud using end-to-end encryption:

• Apple Card transactions (requires iOS 12.4 or later)
• Home data
• Health data (requires iOS 12 or later)
• iCloud Keychain (includes all of your saved accounts and passwords)
• Maps Favorites, Collections and search history (requires iOS 13 or later)
• Memoji (requires iOS 12.1 or later)
• Payment information
• QuickType Keyboard learned vocabulary (requires iOS 11 or later)
• Safari History and iCloud Tabs (requires iOS 13 or later)
• Screen Time
• Siri information
• Wi-Fi passwords
• W1 and H1 Bluetooth keys (requires iOS 13 or later)

To access your data on a new device, you might have to enter the passcode for an existing or former device.

Messages in iCloud also uses end-to-end encryption. If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn’t stored by Apple.

The last paragraph is intriguing. Looks like the key is stored in the keychain (and not synced to iCloud keychain), and so can be decrypted only by the very same device. It’s hard to verify, unfortunately.

What’s the deal about “end-to-end encryption” in iCloud? If you ever parsed Apple warrant returns, you know that such data is not there, which means that Apple has no decryption keys for it. Is it still possible to access this data from iCloud? Yes, with our software.

As usual, the devil is in the details. To access end-to-end encrypted data, not only will you have to supply the login credentials and pass 2FA, but also provide the passcode of one of the trusted devices.

Note that this is the only way to access (download and decrypt) Apple Maps data, Health, keychain, messages, Safari browsing history and some ScreenTime data.

Last but not least, you have a certain degree of control on what data is included in iCloud backups via Settings | {Apple ID} | iCloud | Manage Storage. Here you can see the types of data stored in your iCloud account in backups, synced data and files in iCloud drive.

If you go further to Backups | {Device}, you can specify apps that are allowed to back up their data as part of iCloud backups.

I played with these options a bit and was able to cut the size of my iCloud backup from about 140 GB to 16 GB on the first attempt, and then to just 5 GB. A smaller backup will be much easier and faster to restore if something goes wrong.  Still, I have 230GB worth of photos and videos and 32GB of messages (that’s including attachments) stored in iCloud. He is the comparison; a fresh local (iTunes) backup goes first; 280 GB:

An iCloud backup made over a month ago, 140 GB:

The next one, two weeks later (note the reduced number of media files, and so the locations; 15 GB):

And the latest one, created yesterday (5 GB only):

As you can see, none of the iCloud backups contain Health data, messages or calls, yet you can still download them from synced data storage.

To conclude: make sure to collect everything you can access including all the backups mentioned above, plus the full file system if possible, plus any data from other sources such as laptops and desktops, as well as Apple Watch devices. And then carefully analyze everything you have got to extract the most critical evidence. Below are some screen shots of the data opened in Elcomsoft Phone Viewer extracted from an iCloud backup and from iCloud synced storage. They are two weeks apart, so the data itself should be very similar, yet the content of cloud backups and synced data is quite different with many overlaps and some unique data in either source. Both are extracted with the same tool: Elcomsoft Phone Breaker.

It’s been 10 years since we have released one of our flagship products, Elcomsoft Phone Breaker. The first version appeared in April 2011, and was named “iPhone Password Breaker”.  Since then, we made tons of improvements. The tool lost the “iPhone” designation, and the “Password” part was dropped from its name because it was no longer limited to iPhones or passwords. Today, the tool can offer unmatched features for the mobile forensic specialists.

The initial release was quite simple with its one and only feature: breaking passwords of iOS backups created with iTunes. At that time, we already had over 20 password recovery products for more than two hundred different file formats and algorithms, but iTunes backups are something very special; The Most Unusual Things about iPhone Backups has more details. This tool was actually our first mobile forensics product that marked the beginning of our long journey in the mobile and cloud forensics.

The new tool enables forensic access to password-protected backups for iPhone 2G, 3G, 3GS, and iPod Touch 1st, 2nd, and 3rd Gen. Elcomsoft iPhone Password Breaker performs customizable wordlist-based attacks. The tool supports multi-core CPUs, extended CPU instructions, and acceleration with NVIDIA video cards (ATI support coming soon). Recover the original plain-text password to encrypted backups containing address books, call logs, SMS archives, calendars, camera snapshots, voice mail and email account settings, applications, Web browsing history and cache. (source: ElcomSoft news)

Why iPhone backups are so important? They contain most of the content of the device. Accessing a backup was be the only way to get the data when the device is broken, lost, erased, locked after 10 unsuccessful attempts and so on (remember, there was no iCloud at the time).

Just a few months later, we added an exciting feature, giving experts the ability to decrypting the iOS keychain. At the time, that was a real breakthrough.

In Apple iPhone devices, passwords to email accounts, Web sites, and certain third-party software are stored securely in keychains that are encrypted with hardware keys unique to each individual device. Prior to the release of iOS 4, keychains remained encrypted with a device-specific key even when exported to an off-line backup file. With iOS 4 this is not necessarily the case.

With the release of Apple’s new OS, iOS 4, the keychains can now be stored in device backups encrypted only with backup’s master password. Knowing the password protecting the off-line backup, it is now possible to gain access to encrypted keychains. (source: ElcomSoft news)

I do not think I need to explain why the keychain is so important with all the passwords and account authentication data it contains.

In May 2012, we made another breakthrough: downloading iCloud backups! Nobody did that before. I can say that it was extremely difficult to break into iCloud. We had to jailbreak the phone, sniff the traffic while restoring from a cloud backup, learn the iCloud protocol (of course, undocumented), and get the knowledge of how the data is stored and encrypted to learn how to decrypt everything, then compile the complete backup from the parts. That was an exciting challenge worth another blog article.

ElcomSoft Co. Ltd. discovers yet another way to access information stored in Apple iOS devices by retrieving online backups from Apple iCloud storage. The company updates Elcomsoft Phone Password Breaker, a tool to retrieve user content from password-protected backups created by Apple iOS devices and BlackBerry smartphones, with the ability to retrieve iPhones’ user data from iCloud. No lengthy attacks and no physical access to an iPhone device are required: the data is downloaded directly onto investigators’ computers from Apple remote storage facilities in plain, unencrypted form. Backups to multiple devices registered with the same Apple ID can be effortlessly retrieved. Investigators need to know user’s original Apple ID and password in order to gain access to online backups. (source: ElcomSoft news)

The reaction from the community was… mixed. While some people said “hey, anybody can access the iCloud having the credentials in hands”, the others complained “these pesky Russians broke Apple” (neither is true, actually).

The era of cloud forensics had begun. Even today, Elcomsoft Phone Breaker remains the only product on the forensic market that is able to get the full set of data from Apple iCloud. This includes the backups, synced data (including “end-to-end” encrypted Messages, Health and more, which is unavailable even directly from Apple via Law Enforcement Requests), and third-party app data from iCloud Drive (inaccessible by other means).

Anything else about Phone Breaker worth mentioning? It’s a lot. We discovered a way to break BlackBerry devices using encrypted media cards, and we learned how to decrypt BB 10 backups (the key was stored in the BlackBerry ‘cloud’). We implemented 1Password master password recovery for databases extracted from the device itself or from iCloud. We added Windows Phone support, and we can extract lots of data from Microsoft accounts, from contacts to Skype conversations and Edge browsing history. We added a feature to access iCloud without the password using authentications tokens. All iPhone and iPad models are supported, as well as all iOS/iPad versions down to the latest iOS beta, with all 2FA methods (SMS, push messages and offline codes generated on the device); no extra hardware or spare iPhone devices are needed. And there is more to come.

Back in 2019, independent researcher axi0mX has developed a ground-breaking exploit. Targeting a vulnerability in the bootloader of several generations of iOS devices, checkm8 made it possible to obtain BootROM code execution and perform forensic analysis on a long list of devices running a wide range of iOS versions. In this article, we’ll talk about the forensic use of checkm8 with iOS Forensic Toolkit.

checkm8 is widely accepted in the mobile forensic community. Multiple solutions exist, but none of them are perfect, and most aren’t even trying. Our solution works entirely in RAM; it does not boot the OS installed on the device, and does not touch the system partition. There won’t be a trace left on the iPhone extracted with iOS Forensic Toolkit, not a single log entry and not even a changed timestamp. How did we make it possible?

Introduction

The checkm8 exploit was a game changer. Exploiting an unpatchable vulnerability in iDevice bootloader, checkm8 allows breaking into a wide range of Apple devices regardless of the “patch level” or the version of iOS installed on these devices. The exploit covers a plethora iPhone, iPad and companion devices. The iPhone models that can be exploited include the iPhone 5s, 6, 6s, 7, and 8, including all of the Plus models. In addition, the exploit can be used on the iPhone X and the original iPhone SE. The vulnerability existed in the iPhone 4s, 5, and 5c, although without Secure Enclave these devices could be broken into in a different way, although not just forensically sound as using checkm8.

Unlike ‘traditional’ jailbreaks that exploit vulnerabilities in the operating system (that are promptly patched by Apple with the next iOS update), checkm8 targets the device bootrom, which contains the first code executed when the iPhone is powered on or rebooted. Due to the read-only nature of the bootrom, this vulnerability cannot be patched (however, Apple were able to strengthen security of the latest vulnerable devices, the iPhone 7, 7 Plus, 8, 8 Plus and iPhone X range, by hardening SEP protection).

checkm8 does not affect the Secure Enclave. It cannot be used to break the screen lock passcode, and without the passcode it cannot be used to decrypt the majority of the data in the file system (limited BFU mode access might be possible).

On the other hand, checkm8 is ideal when it comes to forensic extractions. By its very nature, the exploit does not need to modify any bits in the file system; all modifications are performed on the fly in the device’s volatile memory (RAM).

checkra1n vs. checkm8

The use of checkm8 in mobile forensics began with utilizing checkra1n, a public, closed-source jailbreak based on the public, open-source checkm8 exploit. The checkra1n jailbreak was quickly adopted in Elcomsoft iOS Forensic Toolkit to get access to the file system and keychain on jailbroken iOS devices.

From the forensic point of view, checkra1n extractions are not too much different of any other jailbreak-based extractions except for the extra steps required to switch the device into DFU mode. The workflow remained similar, the outcome was the same, and even the drawbacks remained the same compared to all other jailbreak-based extractions; more on that later.

The use of a public jailbreak, including checkra1n, inevitably modifies certain areas on the device’s system and data partitions. Public jailbreaks, including checkra1n, are known to perform steps and install additional services, such as the Cydia store, which aren’t required to perform the extraction but are needed to install mods and software from third-party sources. All that has negative impacts on the forensic use of jailbreaks, making jailbreak-based extractions unacceptable to many examiners.

To sum it up, checkra1n-based extractions have the following drawbacks:

• Jailbreak-based extractions are not forensically sound.
• Such extractions may not be allowed in certain cases.
• The installation process is complicated and prone to errors.
• Due to lack of public interest, checkra1n has limited compatibility compared to the underlying exploit. Only iOS 12.0 and newer are supported.

How our solution compares to checkra1n

Compared to checkra1n-based extractions, the new, direct extraction process has the following advantages:

• Untouched system and data partitions.
• Data partition is mounted read-only.
• Zero modification policy: 100% of the patching occurs in the RAM.*
• The installation process is fully guided and massively more reliable compared to jailbreaking.
• Much wider iOS compatibility (but currently limited hardware support). iOS 8.0 through iOS 14.5 are supported (compared to iOS 12.0 and up).

* An exception to zero notification policy: extracting devices running some very old versions of iOS with HFS ‘file system dirty’ flag. A file system check is required in order to mount the system/data partition read-only.

Compatibility, requirements, and features

In order to use checkm8 extraction, you must have access to a compatible device running a supported version of iOS. At this time, we support all versions of iOS from iOS 8.0 onwards, with no exceptions, that are or ever were available for supported devices .

• Supported hardware: iPhone 5s, iPhone 6, iPhone 6 Plus, iPhone 6s, iPhone 6s Plus, iPhone SE (original model)
• Supported versions of iOS: iOS 8.0 through iOS 14.5, subject to availability for a given device.
• Additional requirements: the ability to place the device into DFU mode. Must download the official Apple firmware (download link is provided during the extraction) that matches iOS version installed on the device.

Elcomsoft iOS Forensic Toolkit now fully supports the file system extraction and keychain decryption from unlocked iOS devices (the passcode must be known or empty). To check which devices are supported, use the following table.

Device	Min. supported iOS version	Latest supported iOS version
iPhone 5s	8.0	12.5.3
iPhone 6, iPhone 6 Plus	8.0	12.5.3
iPhone 6s, iPhone 6s Plus	9.0.1	14.5.1
iPhone SE (original)	9.3	14.5.1

Note: the iPhone 6s and 6s originally shipped with iOS 9.0.1 onboard, while the iPhone SE was shipped with iOS 9.3. The iPhone 5s originally shipped with iOS 7.0, which is currently not supported for checkm8 extraction.

In additional, the following devices are unofficially supported:

• iPod touch 6th gen
• iPad Air (original)
• iPad mini 2/3/4
• iPad 5th gen

Placing the device in DFU mode

Placing the device in DFU mode can be tricky, especially if you’ve never done it before. DFU is different from Recovery in that Recovery was designed to be used in emergency situations by the end user, while DFU was never meant for the end user.

Steps to enter DFU are less than obvious, and there is no on-screen indication of successfully entering DFU. You must follow the steps while carefully observing the timings, and the end result will be a blank screen. To make the process easier, iOS Forensic Toolkit implements real-time guidance, indicating which buttons are to be pressed and implementing countdown timers.

How our solution compares to other checkm8-based software

As time passed, some digital forensic vendors have started using the checkm8 exploit directly in their tools without relying on the public jailbreak. To tell the truth, most vendors borrowed code from the checkra1n jailbreak, sometimes even leaving the copyrights.

# Checkra1n beta 0.9.6
#
# Proudly written in nano
# (c) 2019 Kim Jong Cracks
#
#========  Made by  =======
# argp, axi0mx, danyl931, jaywalker, kirb, littlelailo
# nitoTV, nullpixel, pimskeks, qwertyoruiop, sbingner, siguza
…
Begin Checkra1n

Do you believe it’s a checkra1n log? It is not. This is the output of one of the checkm8-based forensic solutions. An interesting fact is that, while the forensic tool has been released in January 2021, the checkra1n 0.9.6 has been around since December 2019.

While checkm8 is a bootloader-level exploit, when it comes to forensic implementations the devil is in the detail. Until today, we have not encountered a single checkm8-based forensic extraction solution that would be 100% forensically sound. Believe or not, all other solutions, including those marketed by the big names, are not forensically sound. They do modify parts of the iPhone file system, and they do affect the result. Granted, the impact is fairly low, but there is no single vendor who would describe exactly what is changed.

Our solution is based completely on patching the device RAM , and does NOT boot the operating system installed on the device. There will be no log entries added, and absolutely no changes are made to any area on the device, neither in the system nor in data partitions. It does not leave any records in the system logs or any other log or database simply because it works completely off the RAM. The only exception when we must do an alteration is a situation of the file system being in the “dirty” state. The “file system dirty” flag is set after an abnormal shutdown or spontaneous reboot, a failed software update if there was not enough free space, and so on. A file system check will be performed in order to clear the flag and mount the system/data partition read-only.

Next comes the iOS version compatibility. Most checkm8-based solutions (and all solutions based on the checkra1n jailbreak) require the minimum version of iOS 12.0. Custom checkm8-based solutions may support iOS 12.0, but we haven’t seen a single solution supporting iOS 8 through 11 or the beta versions.

Our solution supports all versions of iOS that can or could be installed on supported hardware, with no gaps or exceptions.

Compared to competition, our new, direct extraction process has the following advantages:

• Unique, forensically sound extraction: 100% of the patching occurs in the RAM.
• We never boot the OS installed on the device, and never touch the system partition.
• Our checkm8 solution does not bring along any proprietary Apple code. The firmware is downloaded directly from Apple and patched on the fly.
• For that to work, you’ll have to download the correct firmware matching the iOS version installed on the device (we provide the link).
• Real-time guidance with instructions and countdowns displayed to help install the exploit.
• Much wider iOS compatibility (but currently limited hardware support). iOS 8.0 through iOS 14.5 are supported (compared to iOS 12.0 and up).

How does it fare against agent-based acquisition?

Apart from the compatibility issues, one can note that agent-based acquisition is not completely forensically sound, although the changes it makes are minimal (mostly in the system logs). In this respect, checkm8-based extraction is superior.

On the other hand, agent acquisition supports a much wider range of devices, and works on the models based on the A12/A13/A14 SoC, where checkm8 has been patched. For these models, agent is the only recommended low-level acquisition method.

checkm8 advantages:

• Extended software compatibility
• A 100% forensically sound extraction
• Works for most ‘stuck’ devices
• USB restricted mode is not applicable (passcode must be known)

checkm8 disadvantages:

• Need original iOS firmware
• Currently no BFU extraction
• Hardware limitations (no iPhone 7/8/X and iPads support; currently in the works)

Limitations and future work

This is just the beginning. Our original checkm8 implementation only covers devices including the iPhone 5s, 6, 6 Plus, 6s, 6s Plus, and the original iPhone SE. We are currently working on adding support for more devices including the iPhone 7 and 7 Plus as well as most iPad models based on exploitable SoC (currently supported models are listed above). We’re also researching the iPhone 8/8 Plus/iPhone X range, but no definite promises as of yet due to the different SEP implementation in these devices. A native ARM build is coming for the M1 CPU, which the beta version supports via Rosetta2.

What about the passcode? In order to use our solution, you must know the screen lock passcode if one is enabled on the device. The exploit cannot be used to crack the passcode, at least at this time.

Conclusion

With this update, Elcomsoft iOS Forensic Toolkit becomes the most advanced iOS acquisition tool on the market. The toolkit now supports all possible acquisition methods (with known limitations we’re working on). Agent-based extraction and checkm8-based extraction via device RAM are some of the tool’s unique features.

The previous publication talks about the basics of using the bootloader-level exploit for extracting iOS devices. In this article, we are posting a comprehensive step-by-step guide of using the new checkm8 capability of iOS Forensic Toolkit for performing forensically sound extractions of a range of Apple devices.

Pre-requisites

Before you begin, make sure you have everything required to perform the extraction. Since checkm8 is a very specific exploit, you’ll need all of the following to do the job.

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 expected at the time of the final release. At this time, Windows is not supported.
2. iOS Forensic Toolkit 8.0 beta for Mac (or newer). Note that you will need the Mac edition of the tool. Note: the checkm8 extraction functionality is in active development, so frequent updates are expected for the time being.
3. A supported iPhone or iPad device (see below). The device must be functional enough to be placed into DFU mode. Locked, disabled and USB-restricted devices are supported.
4. Screen lock passcode must be known or empty. Otherwise, limited BFU extraction may be available, but very little information can be obtained this way.
5. A supported version of iOS. At this time, we support all official and most beta versions of iOS that could be installed on supported devices, with a sole exception of the iOS 7 range (iPhone 5s).
6. A USB-A to Lightning cable. Note that Type-C to Lightning cables are incompatible with this extraction method. The cable must be connected directly, absolutely no hubs. The use of USB-A to Type-C adapters is allowed if your Mac only has Type-C ports.
7. You will have to determine the exact version and build number of iOS installed on the iPhone. If you don’t know it, it will be detected automatically during the unlock (see “Detecting iOS version” for details).
8. You must be able to download the official Apple firmware (download link will be provided during the extraction) that matches iOS version installed on the device.

Supported devices

All models of iPhone 5s, iPhone 6, iPhone 6 Plus, iPhone 6s, iPhone 6s Plus, iPhone SE (original model) are supported including the following devices:

• iPhone 5S (iPhone6,1): A1453, A1533
• iPhone 5S (iPhone6,2): A1457, A1518, A1528, A1530
• iPhone 6 (iPhone7,2): A1549, A1586, A1589
• iPhone 6 Plus (iPhone7,1): A1522, A1524, A1593
• iPhone 6s (iPhone8,1): A1633, A1688, A1691, A1700
• iPhone 6s Plus (iPhone8,2): A1634, A1687, A1690, A1699
• iPhone SE (iPhone8,4): A1662, A1723, A1724

Unofficial support for the following models:

• iPod touch 6th gen: A1574
• iPad Air: A1474, A1475, A1476
• iPad mini 2/3/4: A1490, A1491, A1599, A1600, A1601, A1538, A1550
• iPad 5th gen: A1822, A1823

We’ve been able to test the toolkit with all supported iPhone models running all major versions of iOS. The support for iPad and iPod Touch models is unofficial as we’ve been unable to source every iPad model running every version of iOS.

You may have noticed that the iPad Air 2 and iPad Pro (1st gen) are missing from the list. This is because these devices are built on the A8X/A9X platforms unlike the rest of the models that are using SoC that are similar to those used in the corresponding iPhone models. The list of similar devices is available in Apple Mobile Devices Cheat Sheet | ElcomSoft blog.

Detecting iOS version

Our extraction solution does not use the operating system installed on the iPhone to boot the device. Instead, a separate, patched version of the original Apple firmware is booted in the device RAM. This process requires you to have a copy of the original Apple firmware image that matches the device’s iOS version and build number exactly.

In many cases, the iOS 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 iOS builds.

If this is the case, you can attempt to use the first version of iOS suggested by EIFT. After you boot and unlock the iPhone using the downloaded image, EIFT will either be able to unlock the disk, or will display the correct iOS version.

Alternatively, you can check the iOS version in Settings – About on the iPhone itself.

Tap iOS version to see the build number:

Note that you can still boot the phone using a close enough iOS build suggested by EIFT. If the wrong build is used, EIFT will be able to detect and display the correct build number at a later stage of the exploit.

What is extracted

If you know the screen lock passcode (or if the passcode is empty), Elcomsoft iOS Forensic Toolkit 8.0 can extract the file system image and decrypt the keychain. Otherwise, limited BFU extraction is available.

Note that the location of the extracted information has changed in EIFT 8.0 compared to previous versions. EIFT will create a folder named “ElcomSoft” in your home folder on the Mac. The following subfolders will be created:

• logs
• eift_logical
• eift_physical
• eift_checkm8
• eift_legacy
• eift_jailbreak

For checkm8 extraction, the “logs” folder will contain the debug logs, while “eift_checkm8” will receive the data extracted (the file system and keychain).

Step 1: exploiting the device

1. Launch Elcomsoft iOS Forensic Toolkit 8.0 (or newer).
2. Enter “P” access the checkm8 functionality.
3. Prepare to put the iPhone into DFU. Initial state: the iPhone is powered on and connected to the computer with a USB-A to Lightning cable (locked, disabled and USB restricted devices are OK).
4. The procedure is the same for all supported devices. To receive on-screen guidance with timed instructions, enter “1” in EIFT.
5. Follow the on-screen instructions appearing in EIFT.
   1. Press Power and Home buttons for 8 seconds (exact timings are crucial at this step).
   2. Release Power, keep holding Home for another 8 seconds (exact timings are less important here).
   3. The iPhone screen should be black. If the device reboots or displays the “iTunes” icon, repeat the procedure.
6. In iOS Forensic Toolkit, use the “2” command to perform the exploit.
7. The toolkit detects iBoot version and device model. Based on this information, the toolkit attempts to detect the iOS version, and displays the corresponding link or links to download the original firmware. You must download the version of iOS that matches the iOS build installed on the device (see “Determining iOS version” for details).
8. Download the iOS firmware image using the link(s) displayed.
9. Drag and drop the downloaded IPSW file onto the EIFT window. The EIFT console will display comprehensive debug information while patching and booting the build. You may use this information when contacting support.
10. The iPhone screen will remain black for a while, then display the Booting screen.
11. Once the exploit is installed, the following information will be displayed on the iPhone screen:
12. The console will contain an entry reading “Booting done”.

At this point, you have successfully exploited the device.

Step 2: exploring and extracting the device

Once the exploit is installed, you will be able to list partitions, unlock and extract data.

[3] Diskinfo

This optional command displays the list of partitions available on the iPhone after you exploit the device. Newer versions of iOS use APFS as a file system, in which case the number of partitions can be up to 7. EIFT will only extract DATA partitions.

This command may be useful in a case the file system is marked as “dirty”. The “file system dirty” flag can be set by iOS if the device had not been shut down correctly, e.g. after a forced shutdown, interrupted boot, and similar cases. If this is the case, you will see the following information:

Note that, contrary to what you see on the screen shot, you won’t have to manually run any commands. Instead, EIFT will initiate a file system check in order to mount the system/data partitions read-only.

[4] Unlock

This option is mandatory for subsequent extraction. In all iPhones, the data is stored encrypted. In order to access the data, you need to unlock the device. Since the iPhone is in the “Before First Unlock” (BFU) state, you must provide a valid screen lock passcode in order to access the data.

EIFT will first prompt if the passcode is known. If you do know the passcode, or if the passcode is empty, type “Y” or “y”. If, however, the passcode is set but unknown, enter “N” or “n” for BFU extraction.

If the passcode is empty, EIFT will automatically unlock the disk.

For non-empty passcodes, you will have 7 attempts to enter the passcode. Once the correct passcode is entered, the toolkit will automatically mount the disk.

WARNING: After 10 incorrect passcode attempts the iPhone will be permanently locked, and only BFU extraction will be available. This is why EIFT stops after only 7 unsuccessful attempts.

On successful unlock, you will see the following screen on the iPhone:

Troubleshooting

There are several specific conditions that may prevent unlocking the disk and extracting the data.

Version mismatch

While EIFT attempts to detect (“guesstimate”) the correct version of iOS installed on the iPhone based on the device hardware ID and bootloader version, there may be no concrete match between versions of iBoot and iOS. If this is the case, EIFT will list several possible versions of iOS along with download links. If you don’t know the exact version of iOS installed on the iPhone (as could be seen in the Settings – About on the iPhone), you may try using one of the listed firmware images. In many cases, this is enough to unlock the disk and extract the data. In some cases, there could be a mismatch between SEP and iOS versions. If this is the case, you will see the following error message:

If this occurs, download the exact version of iOS that is listed in the error message as shown on the screen shot above, and try again. However, you may still try the current version of iOS; there will be no risk, and the extraction may still work.

Dirty file system

On very old versions of iOS using the HFS file system, iOS may raise the “file system dirty” flag if the device had not been shut down correctly, spontaneously rebooted of did not finish the boot sequence. This is not applicable to 64-bit devices running iOS 10.3 and up; there is no ‘dirty’ bit in APFS that replaced HFS since iOS 10.3.

If the file system is marked ‘dirty’, the device will refuse to boot the supplied disk image. For this reason, initiate a file system check to mount the system/data partitions read-only. This is performed automatically during the unlock.

Once you have unlocked the disk, you can extract the keychain and image the file system. Subsequent commands are very similar in form and function to agent-based extraction except you won’t need to perform any actions on the iPhone.

Locked and disabled devices

If the iPhone is disabled after multiple incorrect passcode entries, you will be unable to unlock the disk even after the device is exploited due to SEP protection.

There is no known workaround. The only option for locked and disabled devices is BFU extraction. To invoke BFU extraction, answer “N” or “n” to the prompt asking if you know the passcode.

Device is running a beta version of iOS

There is no official support for iOS betas. However, more likely than not, the closest official iOS release will allow to unlock the disk and extract the data. You can try one version down and one version up. For example, for devices running iOS 11.2 beta, try iOS 11.1 and 11.2.

[5] Decrypt keychain

Run this command to extract and decrypt the keychain.

[6] Tar user partition

Run this command to extract a file system image and save it into a .tar file.

[7] SSH

This is a highly optional command allowing to establish SSH connectivity between the computer and the iPhone. For advanced users and support inquiries only.

Other notes

• No support for iOS 7 (iPhone 5s), at least for the time being.
• You may encounter errors when attempting to boot and unlock the device. Since there are multiple combinations of hardware and software, we decided to leave the full debug output enabled by default. If you encounter a problem booting or unlocking the device, please contact our technical support and provide the debut output from the EIFT window.
• The iPhone 6s and iPhone SE were built using Samsung and TSMC chips. Both chips are supported transparently. You can see which chip it was in the boot log (CPID on the screen shot below). 0x8000 corresponds to Samsung chips, 0x8003 to TSMC.
• If you experience problems placing the device into DFU or applying the exploit, try using a different Lightning cable and/or USB port. If that does not help, try again on a different Mac. If that fails, try placing the iPhone into Recovery before DFU.
• On iPhone 6s and iPhone SE devices in particular, there are two slightly different DFU modes. Try the following sequences if the exploit does not work:
  • Recovery mode first, DFU after
  • Directly to DFU, immediately after rebooting the iPhone (before unlocking the phone)
  • Directly to DFU but after unlocking the phone
  • Directly to DFU with the iPhone initially powered off
• If you experience problems during the unlock stage, it may indicate a problem in our software. Please contact our technical support with the full debug log copied from the EIFT window.
• Note that passcode unlock is not currently possible. The device will be locked down permanently after exhausting the 10 unlock attempts. We are well aware of the issue, and are working hard searching for a workaround.

In older iPhones, the “file system dirty” flag indicates unclean device shutdown, which affects the ability to perform bootloader-level extractions of Apple devices running legacy versions of iOS (prior to iOS 10.3 released in March 2017). As such, the “file system dirty” flag must be cleared before the extraction. In this article we discuss the very different forensic implications of this flag if it is set on the Data or System partitions.

What is a file system?

A file system is a concept of storing files and directories on a (usually block based) storage medium. It provides an abstraction for creating, reading, writing and deleting files. These events can occur randomly and even concurrently. It’s the operating systems task to serialize those operations and, with the file system as a strategy, write data to a storage medium.

What are atomic file operations?

Generally speaking, storing files is trivial as long as everything follows the protocol and no unexpected events happen. However what happens when the system crashes or loses power in the middle of a write? In these cases the file system can get corrupted. For example, the metadata of a file says it is of a certain size, but the actual data write aborted mid-way.

In order to prevent having half-written-files or other types of corruption, modern file systems introduce the concept of atomic file operations. This means that an operation always either completely succeeds, or is it never happened. Thus there are no longer half-written files.

But how is this implemented in practice?

Since the possibility of a crash or a sudden power loss always exists and isn’t even rare, this has to be somehow dealt with. One possible solution is a concept called journaling, which, as the name suggests, keeps a journal of file operations that are to be performed, that are in progress and that were already completed. The general idea to achieve atomicity when writing files is:

• First, create a journal entry saying “i am now going to write a file of size X”.
• Then, perform the actual file write.
• Finally, update the journal entry saying “I am done performing this file write”.

If at any point in time the system shuts down and thus any of these operations are interrupted, it is possible to either finish the (so called) transaction, or to revert the write altogether. Thus, we achieve atomic file operations

What is the “file system dirty” bit?

In case of a journaling file system, how do we tell whether there was a crash or not? Sure, we could check the journal and verify whether the files are written as they were intended, but what if the shutdown happened while updating the journal itself? Furthermore, checking the journal on every mount can be slow. Ideally we’d want to check it only if something went wrong.

To solve this, some file systems like Apples HFS use a so called “dirty bit” in the file system header. When the file system is mounted, this bit is set to 1, thus indicating that “this file system is in use and it will potentially be modified”.

Once all modifications are done and the file system is unmounted (eg. when performing a clean system shutdown), the dirty bit is cleared (set back to 0) indicating that “everything went fine, there were no issues here”.

Now what happens in case of an unclean shutdown (like a system crash)? Well, the dirty bit is still set, because since the system crashes, the bit never got cleared. This serves as an indicator that the file system may be in a corrupt state and needs fixing. If that happens, it is required to check the journal and either finish the writes (if possible), or revert to the state where the file wasn’t created at all (thus achieving atomicity).

How do I clear the HFS dirty bit?

The file system implementation usually takes care of that on its own, without the user having to perform any action at all. For example, when an HFS file system is mounted and the system crashes and reboots, the system automatically performs a check, repairs the journal and continues to use the file system.

Another method is to manually run a file system check (fsck). In case the dirty bit is clear, there is nothing to do since the file system is in a clean state. On the other hand, if the bit is set, checks are performed, journal and files are fixed up and finally the dirty bit gets cleared indicating that the file system is in a clean state again.

What does my iPhone have to do with all of this?

The iOS operating system used HFS as a file system up to iOS 10.3 (and then switched to APFS on 64bit devices). HFS uses journaling and the concept of the dirty bit, thus the previously explained concepts apply.

On iOS there are at least two partitions, namely the “System” partition and the “Data” partition. As the name suggests, the “Data” partition stores all user data like apps, messages, photos and much more. Therefore the partition is mounted readable and writable. In the case the system crashes a check is performed on the next boot and the file system is repaired.

Why does EIFT need to clear the dirty bit?

As already explained, the dirty bit is set (or rather remains set) when the system has had an unclean shutdown. This can be caused by a kernel panic or a hard reset. For example, when putting the device into DFU mode, you are instructed to hold the power + home button for 10 seconds, then release the power button and keep holding the home button for additional 15 seconds. When taking a closer look on what is happening under the hood, we notice that after the first 7 seconds of holding the power+home combination the system performs a “hard reset”, i.e. the device is instantly reset without the system getting a chance to properly finish remaining work and flush the file system. This is equivalent to pulling the power cord on a desktop computer. Thus, when then booting into EIFT the dirty bit is still set so that the file system needs to be checked first.

Now in the case of HFS the need of manually running fsck only arises because EIFT mounts the file system read-only (since we want to be forensically sound and don’t want to introduce any modifications to the file system like accidentally modifying file access dates). The iOS HFS implementation disallows mounting a file system read-only if the dirty bit set. This is because read-only implies that we cannot do any modifications to the file system, but it also means that files might be corrupted and cannot be fixed (due to it being a read-only mount).

Note that when mounting the file system writable, the system automatically checks and recovers corrupted state before allowing programs to access files.

What exactly does EIFT do to the file system?

If the dirty bit is not set, the file system is mounted read-only straight away. In that case absolutely no modifications are performed.

If the dirty bit is set, then EIFT first runs Apple’s own tool fsck_hfs (file system checking utility), which checks the filesystems state, recovers corruption, replays interrupted journal, fixes up broken files and finally unsets the dirty bit. Afterwards the file system can be mounted read-only and no further modifications are performed.

Does this mean we’re not forensically sound anymore?

Well, no.

It is true that, technically, we do some modifications to the file system, so we can’t say it’s untouched at all. However, the modifications are so minimal that they do not have any impact at all to the data analysis. Furthermore, the fact that the “dirty” bit is set has no practical information in first place, since it could have been introduced by an expert when resetting the device in order to access DFU mode to begin with.

Thus, even when performing a file system check we can say that we don’t (reasonably) impact the soundness of the extraction. Userdata itself (which wasn’t corrupt in first place) isn’t altered during this process.

Can we avoid manually running fsck?

Yes!

In order to let the system handle everything without the need of interfering manually, all we need to do is to perform a clean shutdown. Even clearing a previously dirty bit can be left entirely up to the system. In order to do so, simply power on the device. Then, hold the power button until the “power off” option appears and proceed with powering off the device by sliding the UI element. At this point the device was powered off cleanly and the dirty bit is clear. Now, we only need to make sure we don’t accidentally set it again.

If your device is connected to your computer, you should disconnect it now. Now we proceed by holding the home button while powering on the device (either press the power button once, or plug in a cable).

Important: Make sure to keep holding the home button while powering on the device.

The device will boot into recovery mode and you should see the “connect to iTunes/computer” logo on screen. Since the operating system wasn’t booted yet, the file system wasn’t mounted either. Thus, the dirty bit is still clean and also will remain clean. From recovery mode we can proceed to put the device into DFU mode. Even if we hard reset the device from recovery mode (in order to get into DFU mode), the dirty bit remains untouched since the file system isn’t mounted in first place. When we now boot to EIFT ramdisk, the dirty bit is still clear and there is no need to manually perform file system checks and thus, EIFT does not modify the device at all.

How relevant is this in practice?

First and foremost, even theoretically, this only affects devices that run systems released before iOS 10.3, which was pushed by Apple some four years ago.

I would say the “dirty” bit of the Data partition isn’t relevant at all, since it gets set and unset during normal operation and may remain set in case of a user induced hard reset. This really doesn’t tell you anything useful.

Does that mean I can learn nothing from dirty bits?

For Data partition: yes, this doesn’t really tell you anything.

For System partition, on the other hand, this is a whole different story.

In iOS, the System partition is never mounted writable and thus during normal operation the dirty bit gets never set in the first place. Even in the case of an unclean shutdown (like hard reset or system crash) the dirty bit is never set, since the System partition is never mounted writable. It makes sense that if you never modify a file system, then even a crash can’t corrupt any files, since, well, you’re never writing any files. In fact, starting with iOS 6, the kernel checks for the System partition and even prevents mounting it writable.

Yet still, we can sometimes observe a set dirty bit on the System partition. How is that possible? The answer is Jailbreaks or (more generally) tampering with the device security. Jailbreaks usually patch the kernel, then remount the System partition and deploy files on it. However, as soon as the System partition is re-mounted readable and writable, the dirty bit gets set!

Now here is the interesting part: When the system shuts down uncleanly, the dirty bit remains set. But due to the fact that on the next boot the System partition is then mounted read-only (due to signed bootchain unless there an iBoot exploit), the bit remains set. Remember that a file system can’t be mounted read-only when the dirty bit is set? Well, there is one exception! The file system may have the dirty bit set and mounted read-only if it’s the root file system (which makes sense, since otherwise the system wouldn’t boot).

Furthermore, since the System partition is mounted read-only, the dirty bit won’t get cleared during normal system operation. It will survive several reboots! The only way to un-set the System dirty bit is to exploit the kernel again, then remount the System partition writable, then perform a clean shutdown (or to manually run fsck, but nobody does that). Keep in mind that unless the system is jailbroken (or hacked/implanted) in untethered fashion (which means a kernel exploit is automatically executed on every boot), clearing the System dirty bit requires active user interaction (eg. kickstarting a tethered jailbreak by running an app).

What does it mean if the System partition dirty bit is set?

It means the system was tampered with and the System was shutdown uncleanly (either due to a kernel panic or hard reset). It essentially means the device was either jailbroken by the user at some point or (a bit less likely) that some malware was installed that remounted the System partition writable at some point.

How can I check for the dirty bit?

Elcomsoft iOS Forensic Toolkit ships with a utility called diskinfo which (among other things) checks for HFS dirty bit for System and Data partition if they are not currently mounted.

Does this apply to APFS too?

No.

Without going into much detail, the APFS implementation does not use the concept of dirty bits. Atomicity is implemented in a different manner. When mounting APFS read-only, even after an unclean shutdown, it is never required to perform any modifications to the file system.