All posts by Oleg Afonin

Today’s smartphones collect overwhelming amounts of data about the user’s daily activities. Smartphones track users’ location and record the number of steps they walked, save pictures and videos they take and every message they send or receive. Users trust smartphones with their passwords and login credentials to social networks, e-commerce and other Web sites. It is hard to imagine one’s daily life without calendars and reminders, notes and browser favorites and many other bits and pieces of information we entrust our smartphones. All of those bits and pieces, and much more, are collected from the iPhone and stored in the cloud. While Apple claims secure encryption for all of the cloud data, the company readily provides some information to the law enforcement when presented with a legal request – but refuses to give away some of the most important bits of data. In this article we’ll cover the types of data that Apple does and does not deliver when served with a government request or while processing the user’s privacy request.

What’s Stored in iCloud

Apple uses iCloud as an all-in-one cloud backup, cloud storage and cloud synchronization solution for the user of iOS, iPasOS and macOS devices. iOS 12 and 13 can store the following types of data in the user’s iCloud account:

iCloud backups

iCloud backups contain a lot of data from the iPhone, which includes device settings and home screen icons, the list of installed apps and individual apps’ private data (if allowed by the app developer).

The content of iCloud backups is exclusive. Any information that is synchronized with iCloud is excluded from cloud backups. For example, if the user enables the iCloud Photo Library, pictures and videos will synchronize to iCloud and will not be included in iCloud backups. The same is true for many other categories. Here’s what Apple says in What does iCloud back up?

Your iPhone, iPad, and iPod touch backup only include information and settings stored on your device. It doesn’t include information already stored in iCloud, like Contacts, Calendars, Bookmarks, Mail, Notes, Voice Memos, shared photos, iCloud Photos, Health data, call history, and files you store in iCloud Drive.

In iOS 13, iCloud backups do not include any of the following:

  • Keychain *
  • Health data
  • Home data
  • iCloud Photos **
  • Messages **
  • Call logs
  • Safari history

* While the keychain is still physically included, records marked as ThisDeviceOnly are encrypted with a device-specific key and can only be restored onto the same physical device they were saved from.

** Photos and Messages are not included if (and only if) the iCloud sync of those categories is not enabled in device settings.

Synchronized data

iOS allows synchronizing many types of data with the user’s iCloud account. While users can enable or disable the sync for some of the data categories (as defined in Change your iCloud feature settings), some other types of data (e.g. the call log) are always synchronized unless the user disables the iCloud Drive feature entirely.

The following types of data are synchronized to iCloud:

  • Photos
  • Safari History & Bookmarks
  • Calendars
  • Contacts
  • Find My (Devices & People)
  • Notes
  • Reminders
  • Siri Shortcuts
  • Voice Memos
  • Wallet passes
  • iCloud Mail
  • Maps
  • Clips
  • Data covered by the iCloud Drive category (e.g. Call logs)

Files

There are two distinct data types that fall under the “Files” category.

The first category includes files the user stores in their iCloud Drive (e.g. by using the iOS Files app). These files are user-accessible, and can be downloaded by using the iCloud Drive app on a Mac or Windows PC.

The second category includes files stored by system apps (e.g. downloaded books and documents in the Books app) and third-party apps (e.g. stand-alone WhatsApp backups, game saves etc.) While large amounts of data may accumulate under this category, users have no direct access to these files. For example, any files stored by third-party apps are only displayed as toggles in the iCloud | Apps section. The only control the user has over these files is the ability to disable sync (and remove stored files) for a certain app.

End-to-end encrypted data

Apple uses end-to-end encryption to secure sensitive types of data such as the users’ passwords, Health data or credit card information. The data is secured with an encryption key derived from some device-specific information and the user’s screen lock passcode. Users must enroll their devices into the trusted circle in order to enable the sharing of end-to-end encrypted data.

The following types of data are covered by end-to-end encryption as per iCloud security overview:

  • Home data
  • Health data (iOS 12 or later) *
  • iCloud Keychain (includes saved accounts and passwords)
  • Payment information
  • QuickType Keyboard learned vocabulary (iOS 11 or later)
  • Screen Time password and data
  • Siri information
  • Wi-Fi passwords
  • Messages in iCloud **

* iOS 11 devices synchronize Health data as a regular data category without using end-to-end encryption. According to Apple, “End-to-end encryption for Health data requires iOS 12 or later and two-factor authentication. Otherwise, your data is still encrypted in storage and transmission but is not encrypted end-to-end. After you turn on two-factor authentication and update iOS, your Health data is migrated to end-to-end encryption.”

** According to Apple, “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. Since iOS 13, Apple no longer stores Messages in iCloud backups if the user activates Messages in iCloud.

What Apple Provides When Serving Government Requests

Apple discloses certain types of information when serving a valid government request. This data typically includes information that falls into iCloud backups, Synchronized data and Files categories.

When serving government requests, Apple also delivers iCloud backups. End users exercising their rights under the European Data Protection Directive (EDPR) or requesting their personal data via Apple’s Data & Privacy portal do not receive a copy of their iCloud backups.

The following principles apply when Apple serves government requests: https://www.apple.com/privacy/government-information-requests/; of particular interest are the following excerpts:

Apple will notify customers/users when their Apple account information is being sought in response to a valid legal request from government or law enforcement, except where providing notice is explicitly prohibited by the valid legal request, by a court order Apple receives, by applicable law or where Apple, in its sole discretion, believes that providing notice creates a risk of injury or death to an identifiable individual, in situations where the case relates to child endangerment, or where notice is not applicable to the underlying facts of the case, or where Apple reasonably considers that to do so would likely pervert the course of justice or prejudice the administration of justice.

The second category includes files stored by system apps (e.g. downloaded books and documents in the Books app) and third-party apps (e.g. stand-alone WhatsApp backups, game saves etc.) While large amounts of data may accumulate under this category, users have no direct access to these files. For example, any files stored by third-party apps are only displayed as toggles in the iCloud – Apps section. The only control the user has over these files is the ability to disable sync (and remove stored files) for a certain app.

Apple defines information provided to the LE as follows:

iCloud stores content for the services that the subscriber has elected to maintain in the account while the subscriber’s account remains active. Apple does not retain deleted content once it is cleared from Apple’s servers. iCloud content may include email, stored photos, documents, contacts, calendars, bookmarks, Safari browsing history, Maps Search History, Messages and iOS device backups. iOS device backups may include photos and videos in the Camera Roll, device settings, app data, iMessage, Business Chat, SMS, and MMS messages and voicemail. All iCloud content data stored by Apple is encrypted at the location of the server. When third-party vendors are used to store data, Apple never gives them the keys. Apple retains the encryption keys in its U.S. data centres.

While Apple correctly claims that it does not keep deleted content once it is cleared from Apple’s servers, we have found that, in many cases, some content may still be available on Apple servers. As a result, tools such as Elcomsoft Phone Breaker can access and download such content.

Additionally, Apple does not explicitly mention certain types of data such as the phone-to-cloud communication logs. These logs record the phone’s dynamic IP address and store records going back some 28 days.

What Apple Provides When Serving Privacy Requests

Apple is committed to disclosing information to end users according to the European Data Protection Directive (EDPR) or serving a request for personal data submitted via Apple’s Data & Privacy portal. Users can request a download of a copy of their data from Apple apps and services. This, according to Apple, may include purchase or app usage history and the data users store with Apple, such as calendars, photos or documents. Below is the list of information disclosed by Apple:

Note: iCloud backups are only provided when Apple serves government requests. End users exercising their rights under the European Data Protection Directive (EDPR) or requesting their personal data via Apple’s Data & Privacy portal do not receive a copy of their iCloud backups.

What Apple Does Not Provide

Any information that falls under the End-to-end encrypted data category as defined in the iCloud security overview is never disclosed to the law enforcement. End users may only obtain end-to-end encrypted data by setting up a compatible Apple device and typing a screen lock passcode of their past device.

Obtaining End-to-End Encrypted Data

Since Apple refuses to provide legal access to any of the data the company protects with end-to-end encryption, experts must use third-party tools to extract this information from iCloud. Elcomsoft Phone Breaker is one of the few tools on the market that can touch these encrypted categories. Elcomsoft Phone Breaker can extract the iCloud backups, files and synchronized data. In addition, the tool can download and decrypt the following types of end-to-end encrypted data:

  • iCloud Keychain
  • Health
  • Messages in iCloud
  • Screen Time password
  • FileVault2 recovery token

In order to access end-to-end encrypted data, the following information is required:

  1. The user’s Apple ID and password
  2. A valid, non-expired one-time code to pass Two-Factor Authentication
  3. The user’s screen lock passcode or system password to any current or past device enrolled in the trusted circle

More information:

Conclusion

In this article, we described the discrepancy between the data Apple collects from its users and stores on its servers, and the data the company gives away to the law enforcement when serving a government request. Some of the most essential categories are not disclosed, particularly the user’s passwords (iCloud Keychain), text messages and iMessages (Messages in iCloud), the user’s physical activity logs (Health), device usage patterns (Screen Time) and Home data. Most of this information can be only accessed by using third-party tools such as Elcomsoft Phone Breaker, and only if the complete set of authentication credentials (the login and password, 2FA code and screen lock/system password) are known.

What is DFU, and how is it different from the recovery mode? How do you switch the device to recovery, DFU or SOS mode, what can you do while in these modes and what do they mean in the context of digital forensics? Can you use DFU to jailbreak the device and perform the extraction if you don’t know the passcode? Read along to find out.

iOS Recovery Mode

The recovery mode is the easiest to explain. According to Apple, you can put your iOS or iPadOS device in recovery mode to restore it using your computer.

The recovery mode comes handy if one of the following situations occurs:

  • Your iOS or iPadOS device is locked after multiple unsuccessful unlock attempts and displays the infamous “Connect to iTunes” message. In many cases, connecting the device to iTunes will be unsuccessful because the data connection of the device is blocked with USB restricted mode. If this is the case, you must switch the device to recovery mode and connect to iTunes to restore.
  • You forgot the screen lock passcode and want to reset the device to factory settings. Activation lock: following the reset, you’ll have to provide the Apple ID/iCloud password of the device’s Apple ID account.
  • The device cannot fully boot; the display is stuck on the Apple logo for several minutes with no progress bar. I have personally seen this multiple times after unsuccessful iOS updates (the latest case being the almost-full iPhone 7 updated from iOS 9 straight to the latest iOS 13.3).
  • Your computer doesn’t recognize your device or says it’s in recovery mode, or you see the recovery mode screen.

How to switch the device into recovery mode

The recovery mode is well-documented in “If you can’t update or restore your iPhone, iPad, or iPod touch” (link). Connect the device to a computer with iTunes installed. Perform a force restart of the device by following instructions laid out in “If your screen is black or frozen” (link):

If your screen is black or frozen

If your screen is black or frozen, you might need to force-restart your device. A force-restart won’t erase the content on your device. You can force-restart your device even if the screen is black or the buttons aren’t responding. Follow these steps:

  • iPad models with Face ID: Press and quickly release the Volume Up button. Press and quickly release the Volume Down button. Then press and hold the Power button until the device restarts.
  • iPhone 8 or later: Press and quickly release the Volume Up button. Press and quickly release the Volume Down button. Then press and hold the Side button until you see the Apple logo.
  • iPhone 7, iPhone 7 Plus and iPod touch (7th generation): Press and hold both the Top (or Side) button and the Volume Down buttons until you see the Apple logo.
  • iPad with Home button, iPhone 6s or earlier and iPod touch (6th generation) or earlier: Press and hold both the Home and the Top (or Side) buttons until you see the Apple logo.

After following the force-restart instructions, do not release the buttons when you see the Apple logo, wait until the recovery mode screen appears:

  • iPad models with Face ID: Press and quickly release the Volume Up button. Press and quickly release the Volume Down button. Press and hold the Top button until your device begins to restart. Continue holding the Top button until your device goes into recovery mode.
  • iPhone 8 or later: Press and quickly release the Volume Up button. Press and quickly release the Volume Down button. Then, press and hold the Side button until you see the recovery mode screen.
  • iPhone 7, iPhone 7 Plus, and iPod touch (7th generation): Press and hold the Top (or Side) and Volume Down buttons at the same time. Keep holding them until you see the recovery mode screen.
  • iPad with Home button, iPhone 6s or earlier, and iPod touch (6th generation) or earlier: Press and hold both the Home and the Top (or Side) buttons at the same time. Keep holding them until you see the recovery mode screen.

(source)

How to use the recovery mode

We know of several viable usage scenarios for the recovery mode.

  1. Reinstall iOS (if the iOS device is running the latest version), perform an in-place update or switch from a beta version of iOS to the current release version using the iTunes app. In this scenario, the data is preserved.
  2. Restore the device. This is what you want if you forgot the passcode. The passcode will be removed and USB restrictions disabled, but the data will be already erased by that time. Mind the activation lock.
  3. Perform a (limited) forensic extraction through recovery mode. You’ll need a reasonably up to date version of iOS Forensic Toolkit (EIFT 4.10 or newer).

Information available in recovery mode

When performing a forensic extraction of a device running in the recovery mode, note that only a very limited set of data will be available. The following information is available:

Device Model: iPhone8,1
Model: n71map
ECID: XXXXXXXXXXXXXXXX
Serial Number: XXXXXXXXXXX
IMEI: XXXXXXXXXXXXXXX
MODE: Recovery

The Recovery mode may return the following information:

  • Device model: two representations of the device model, e.g. iPhone7,2 (n61ap), iPhone10,6 (d221ap) etc.
  • ECID (UCID): XXXXXXXXXXXXXXXX. The ECID (Exclusive Chip Identification) or Unique Chip ID is an identifier unique to every unit, or more accurately, to every SoC.
  • Serial number: XXXXXXXXXXX (or N/A)
  • IMEI: XXXXXXXXXXXXXXX (or N/A). Note that we have not seen IMEI information on any of our test devices, with or without a SIM card.
  • Mode: Recovery

How to exit recovery mode

The procedure for leaving the recovery mode is different for different devices. In general, you’ll use the following steps:

  • Unplug the USB cable.
  • Hold down the sleep/wake button or side button depending on device model until the device turns off.
  • Either keep holding the button combination or release and hold it down again until the Apple logo appears.
  • Let go of the buttons and let the device start up.

This is the Apple-recommended procedure for exiting the recovery mode:

  • iPhone 6s and earlier, Touch ID equipped iPads: hold the Home button and the Lock button until the device reboots.
  • iPhone 7 and iPhone 7 Plus: hold down the Side button and Volume Down button until the device reboots.
  • iPhone 8 and newer: click the Volume Up button, then click the Volume Down button, then hold down the Side button until the device reboots.

Forensic implications of iOS recovery mode

The recovery mode has a positive yet limited value for mobile forensic specialists.

  • Enables obtaining device information without a passcode.
  • Allows bypassing the USB restricted mode (albeit accessing limited amounts of information).
  • For newer iOS devices (A12 and newer), returns more information compared to the DFU mode.

Interestingly, when users install the checkra1n jailbreak from the device GUI, the jailbreak first switches the device into recovery (unlike DFU, the recovery mode is available through the API). Only after the device is switched to recovery, the jailbreak prompts for a switch to DFU and displays step-by-step instructions and timings. Alternatively, the jailbreak can be installed from the command line, which will bypass the intermediary recovery mode.

iOS DFU Mode

The undocumented DFU stands for “Device Firmware Upgrade”. Unlike the recovery mode, which is designed with an ordinary user in mind, the DFU mode was never intended for the public. There is no documentation about DFU anywhere in Apple Knowledge Base. Entering the DFU more involves a complicated sequence of pressing, holding and releasing buttons with precise timings. Wrong timings during any of the multiple steps would reboot the device instead of switching it to DFU. Finally, there is no on-screen indication of DFU mode. If the device is successfully switched to DFU, the display remains black. Entering DFU mode can be difficult even for experts.

DFU is part of the bootrom, which is burned into the hardware. On A7 through A11 devices, a vulnerability has been discovered allowing to bypass SecureROM protection and jailbreak the device via DFU mode. More in our blog: BFU Extraction: Forensic Analysis of Locked and Disabled iPhones.

Steps for entering DFU mode differ between devices. Some devices have several different methods to invoke DFU, making it even more confusing. The differences in procedures may be severe between device generations. Since no official instructions are available, we have to rely on third-party sources for information.

Note: the device screen will be completely black while in DFU mode. The iPhone Wiki explains steps required to enter the DFU mode in a dedicated article. According to the article, this is how you enter DFU mode on the different device models. If you are more of a visual learner, check out this link with video tutorials instead: How To Put An iPhone In DFU Mode, The Apple Way

Apple TV

  1. Plug the device into your computer using a USB cable.
  2. Force the device to reboot by holding down the “Menu” and “Down” buttons simultaneously for 6-7 seconds.
  3. Press “Menu” and “Play” simultaneously right after reboot, until a message pops up in iTunes, saying that it has detected an Apple TV in Recovery Mode.

A9 and older devices (iPad other than the ones listed below, iPhone 6s and below, iPhone SE and iPod touch 6 and below)

  1. Connect the device to a computer using a USB cable.
  2. Hold down both the Home button and Lock button.
  3. After 8 seconds, release the Lock button while continuing to hold down the Home button.
    • If the Apple logo appears, the Lock button was held down for too long.
  4. Nothing will be displayed on the screen when the device is in DFU mode. If open, iTunes will alert you that a device was detected in recovery mode.
    • If your device shows a screen telling you to connect the device to iTunes, retry these steps.

Alternative method 1:

  1. Hold the Lock Button for 3 seconds
  2. Continue holding the Lock button and also hold the Home button (15 seconds)
  3. Release the Lock button while continuing to hold the Home button (10 seconds)
  4. Your device should enter DFU mode

Alternative method 2:

  1. Connect the device to your computer and launch iTunes. Turn the device off.
  2. Hold down the Lock button and Home button together for exactly 10 seconds, then release the Lock button.
  3. Continue holding the Home button until iTunes on your computer displays a message that a device in recovery mode has been detected. The device screen will remain completely black.

A10 devices (iPhone 7 and iPhone 7 Plus, iPad 2018, iPod touch 7)

  1. Connect the device to a computer using a USB cable.
  2. Hold down both the Side button and Volume Down button.
  3. After 8 seconds, release the Side button while continuing to hold down the Volume Down button.
    • If the Apple logo appears, the Side button was held down for too long.
  4. Nothing will be displayed on the screen when the device is in DFU mode. If open, iTunes will alert you that a device was detected in recovery mode.
    • If your device shows a screen telling you to connect the device to iTunes, retry these steps.

A11 and newer devices (iPhone 8 and above, including the iPhone Xr, Xs and Xs Max; iPad Pro 2018, iPad Air 2019, iPad Mini 2019)

  1. Connect the device to a computer using a USB cable.
  2. Quick-press the Volume Up button
  3. Quick-press the Volume Down button
  4. Hold down the Side button until the screen goes black, then hold down both the Side button and Volume Down button.
  5. After 5 seconds, release the Side button while continuing to hold down the Volume Down button.
    • If the Apple logo appears, the Side button was held down for too long.
  6. Nothing will be displayed on the screen when the device is in DFU mode. If open, iTunes will alert you that a device was detected in recovery mode.
    • If your device shows a screen telling you to connect the device to iTunes, retry these steps.

If your device shows a screen telling you to connect the device to iTunes, retry these steps.

Sources: iphonewiki and other third-party sources

Information available in DFU mode

The DFU mode returns even less information compared to the recovery mode.

Device Model: iPhone8,1
Model: n71map
ECID: XXXXXXXXXXXXXXXX
Serial Number: N/A
IMEI: N/A
MODE: DFU

To obtain this information, use iOS Forensic Toolkit 4.10 or newer.

  • Device model: two representations of the device model, e.g. iPhone7,2 (n61ap), iPhone10,6 (d221ap) etc.
  • ECID/Unique Chip ID: XXXXXXXXXXXXXXXX
  • Serial number: not available in DFU mode
  • IMEI: not available in DFU mode
  • Mode: DFU
  • Exiting DFU Mode

How to exit DFU mode

The process of exiting DFU mode is also different across devices.

For devices with a physical Home button (up to and including iPhone 6s and iPhone SE): hold the Home button and the Lock button until the device reboots.

For iPhone 7 and iPhone 7 Plus: hold down the Side button and Volume Down button until the device reboots.

For iPhone 8 and iPhone 8 Plus, iPhone X: click the Volume Up button, then click the Volume Down button, then hold down the Side button until the device reboots.

Forensic implications of DFU mode

The DFU mode may have a huge value for mobile forensic specialists depending on the device model. iPhone, iPod Touch and iPad devices based on A5 through A11 generations of Apple processors (iPhone generations from iPhone 4s through iPhone 8, 8 Plus and iPhone X, as well as the corresponding iPad models) have a non-patchable, hardware-based bootrom vulnerability. This vulnerability allows installing a jailbreak on affected devices regardless of the version of iOS that is installed. This also makes it possible to extract a limited but still significant amounts of data through DFU mode without knowing or breaking the passcode.

  • All devices: enables obtaining device information without a passcode
  • All devices: allows bypassing the USB restricted mode (albeit accessing limited amounts of information)
  • Vulnerable iOS devices (A5 through A11 generations): returns significantly more information compared to the recovery mode
  • Criminals exploit the vulnerability to remove Activation Lock from vulnerable devices (A5 through A11 generations) running older versions of iOS. Reportedly, this vulnerability has been fixed by Apple in iOS 13.3; however, considering the nature of the exploit, this functionality may reappear.

The following information is extractable from vulnerable iOS devices:

  • Limited file system extraction: the list of installed applications, some Wallet data, the list of Wi-Fi connections, some media files, notifications (these may contain some chat messages and other useful data), and many location points.
  • Keychain records with kSecAttrAccessibleAlways and kSecAttributeAccessibleAlwaysThisDeviceOnly
  • Oxygen Forensic Detective additionally processes files such as /private/var/wireless/Library/Databases/DataUsage.sqlite (apps’ network activities), /private/var/preferences/ (network interfaces) or /private/var/mobile/Library/Voicemail/ (voicemail messages) to display even more information.

More information in BFU Extraction: Forensic Analysis of Locked and Disabled iPhones and iOS Device Acquisition with checkra1n Jailbreak.

Differences between DFU and recovery modes

While both DFU and recovery are designed to fulfil essentially the same goal of recovering a non-bootable device by flashing known working firmware, they are very different in the way they work.

The recovery mode boots into the bootloader (iBoot), and works by issuing commands through the bootloader. The bootloader is part of the operating system, and can be flashed, updated or patched if there are any vulnerabilities discovered. The recovery mode will only accept signed firmware images, so going back to firmware that is no longer signed by Apple is not possible. While the device is in recovery mode, the user gets a clear visible indication on the device:

DFU or Device Firmware Upgrade, on the other hand, allows restoring devices from any state, including devices with corrupted bootloader. DFU does not operate through a software-upgradeable bootloader. Instead, DFU is burned into the hardware as part SecureROM. DFU cannot be updated, patched or disabled. As a result, the bootrom vulnerability and the corresponding checkm8 exploit cannot be patched by Apple, allowing experts extract certain data from affected devices while bypassing passcode protection and USB restrictions.

DFU will also accept only signed firmware packages. As long as a package is still signed by Apple, the user can upgrade and downgrade firmware at will since there is no downgrade protection in DFU. There is no indication on the device that the device is in DFU mode. During DFU interfacing, the device screen remains black.

The recovery mode was designed for end users and Apple facilities, while the DFU mode was never meant for the end user at all. Entering the recovery mode is easy; any reasonably experienced user can follow the instructions. Entering the DFU mode is not only significantly trickier, but requires precise timings. Hold a button one second too long, and the device simply reboots instead of entering DFU.

The S.O.S. mode

The third and final special mode we’re about to discuss today is the S.O.S. mode. The S.O.S. mode can be manually invoked by the user while the device is running. Apple has a comprehensive description of S.O.S. mode in Use Emergency SOS on your iPhone.

Activating S.O.S. mode

On newer devices without the Home button (as well as the iPhone 8 and 8 Plus), the S.O.S. mode is activated in exactly the same way as the power-off sequence. Users press and hold one of the volume buttons and the side button. The power off/emergency screen appears.

On older devices, the S.O.S. mode is activated by rapidly pressing the side (or top) button five times. The Emergency SOS slider will appear. Users in India only need to press the button three times, after which the iPhone automatically makes an emergency call.

“If you use the Emergency SOS shortcut, you need to enter your passcode to re-enable Touch ID, even if you don’t complete a call to emergency services.” (Source: Use Emergency SOS on your iPhone)

How to exit S.O.S. mode

To exit the S.O.S. mode, users tap on the “Cancel” icon. The device will prompt for the passcode (biometric identification methods are disabled). Alternatively, one can slide the Power off slider to the right to switch off the device.

Forensic implications of S.O.S. mode

Once invoked, the S.O.S. mode has the following forensic implications.

  • All biometric authentication methods (Touch ID and Face ID) are disabled. The device must be unlocked with a passcode.
  • Data transmission on USB port is switched off (USB restricted mode is immediately activated). This makes traditional acquisition efforts fruitless, potentially affecting passcode recovery solutions offered by companies such as Cellebrite and GrayShift.

TerraMaster is a relatively new company specializing in network attached storage and direct attached storage solutions. The majority of TerraMaster NAS solutions are ARM64 and Intel-based boxes aimed at the home and SOHO users. TerraMaster’s OS (TOS) is based on Linux. At this time, TOS 4.1 is the current version of the OS.

TerraMaster advertises secure AES encryption with unspecified key length through the entire range of its current NAS devices. This time around, we’re dealing with folder-based encryption that runs on top of the open-source encrypting file system eCryptfs. TerraMaster’s implementation of data encryption is extremely simplistic and lacks any sort of management for either the encryption key or the encrypted data.

Abstract and Summary

TerraMaster implements folder-based AES encryption with a single, fixed, unchangeable encryption key based on the user-provided password. The company does not specify the length of the key used for AES encryption. A 42-byte (336-bit) encryption key file can be manually exported for backup purposes. Users can unlock encrypted volumes by either typing the original plain-text password or uploading the encryption key.

TerraMaster has never documented any technical details about the underlying encryption mechanisms.

Encryption key: plain-text password or key file (must be manually exported while the encrypted share is mounted and unlocked).

The original password is used as Media Encryption Key. The concept of Key Encryption Keys is never utilized here; as a result, users cannot change their encryption password at all. In addition, TerraMaster OS does not have provisions for encrypting existing data or permanently decrypting encrypted shares. Any changes to encryption require deleting and re-creating shares and filling them up with data.

The entire encryption scheme lacks any sort of technical documentation.

Test Bench

We analyzed a TerraMaster F2-220 device based on a quad-code ARM64 design. A non-SED WD Red HDD was used to set up the NAS perform the analysis. The NAS was running on the latest available version of TOS 4.1.

TerraMaster: Folder-Based Encryption

TerraMaster uses folder-based encryption based on eCryptfs, an open-source stacked cryptographic file system. Detailed information on eCryptfs is available here. This is the same encryption scheme as used in consumer Synology NAS devices. However, while Synology properly documents the restrictions of folder-based encryption, TerraMaster does not. As a result, the user finds out about the fact that encrypted file names are restricted to 143 Latin characters in a hard way by getting a write error when attempting to store a file with a name that is longer than permitted. Using Asian characters makes the possible file names even shorter.

From the point of view of a normal consumer, TerraMaster’s implementation of encryption is not just restrictive; it’s restrictive by surprise since no advance warning is given and no documentation is available about it.

Once the encrypted share is created, users cannot change the encryption passphrase.

Encrypting

Users can only encrypt newly created, empty shares. Encrypting an existing share is not possible. One must first delete the encrypted share, create a new one while selecting the encryption option. As a result, encrypting shares with existing data is not supported.

The good thing about this encryption scheme is the ability to create multiple shares, each with its own unique password. If there are multiple users, each user can encrypt their personal share with their own password. However, the complete inability to change the encryption password makes this approach dubious in the grand scheme of things.

Creating an encrypted share

The first step is creating a new share:

The “Encrypt this shared folder” box activates the encryption. The encryption feature requires a password, which is used as an encryption key. There are no obvious limitations (minimum or maximum) to the length of the password or supported character sets.

The process is concluded after setting access permissions and confirming settings:

The encrypted share is created and mounted. Note the “lock” icon:

Exporting the encryption key

Pretty much the only thing users can do with their encryption key other than using it for mounting shares is exporting it to a file.

In order to export the key, users must re-enter their encryption password:

Mounting encrypted shares

The encrypted volumes can be only mounted manually. Users must log in to the TOS Web UI, click on the encrypted share and use the Mount command. There are no auto-mount options available, and there are no vulnerabilities connected with the improper storage or handling of encryption keys.

The following two options are supported.

  1. Mounting with the original plain-text password.
  2. Mounting with the exported key file.

Choosing between these two options, the key file appears to be the more secure one as users can generate a long, random password with high volatility and use that password to produce the backup key file.

Unmounting encrypted shares

Encrypted shares are unmounted automatically once the NAS is powered off or rebooted. Manually unmounting the encrypted share requires accessing the Web UI:

Permanent decryption

Your familiar full-disk encryption tools such as Microsoft BitLocker allow removing the password from an encrypted volume. This is possible because these encryption tools use a concept of separate Media Encryption Keys (MEK, which are used to protect the data) and Key Encryption Keys (KEK, which are used to protect, or “wrap”, the MEK).

TerraMaster does not use the concept of separate MEK and KER. As a result, removing the password is not possible without physically decrypting the entire set of data (which is not supported by TOS). The only way to permanently decrypt the data is removing the encrypted share, re-creating the share without encryption and filling it up with data.

Changing the password: impossible

Decades ago, manufacturers came up with a brilliant idea of separating the binary encryption keys that are used to encrypt and decrypt the data, and secrets that are used to unlock the encryption keys. This wonderful concept allows many things such as using any one of the several different passwords (or multiple types of authentication credentials, such as a smart card or a password) to unlock encrypted volumes. Sadly, this concept is rarely used by NAS manufacturers. TerraMaster is no exception; users cannot change the password because the password itself is the Media Encryption Key.

Manually Decrypting Encrypted Shares

Looking at the path that contains the encrypted files, I wonder if TerraMaster could be inspired by Synology’s implementation of folder-based encryption. The path to encrypted share looks as follows:

/mnt/md0/@encrypted@/

Where “encrypted” is the name of the share (as seen on screenshots above).

Path to decrypted files/mounted share:

/mnt/md0/encrypted/

Since TerraMaster uses eCryptfs, we can use the familiar command to mount the encrypted share:

mount -t ecryptfs /mnt/md0/@encrypted@ /mnt/md0/encrypted

You will need the user’s original, plain-text encryption password. TOS does not appear to be storing the encryption password or the encryption key file anywhere on the disk or in the boot DOM.

If you are able to decrypt the files, but the file names remain encrypted (ECRYPTFS_FNEK_ENCRYPTED), check out the following threads:

Alternatively, this open-source tool: pecryptfs – Portable Userspace eCryptfs may help decrypting individual file names.

What Risks Are Covered by TerraMaster Security Model

Similar to other implementations of NAS encryption, the security model employed by the TerraMaster is stripped down to the bare essentials. I have the following remarks about the TOS security model.

  1. Unlike volume encryption schemes, folder-based encryption comes with encryption metadata duplicated in every file. “eCryptfs stores cryptographic metadata in the header of each file, so that encrypted files can be copied between hosts; the file will be decrypted with the proper key in the Linux kernel keyring.” (source) This makes secure erase of encrypted data impossible. To securely erase data encrypted with eCryptfs, one must either wipe (overwrite) encryption metadata in each and every encrypted file; wipe the full content of every file; or wipe the entire disk.
  2. This encryption model does not properly protect the data if one needs to send the disk out for repair/replacement or simply wants to sell the disk. The encryption metadata is duplicated in every file in the encrypted folder. As a result, the attacker can obtain a single file and run a (fast) attack on the encryption key. Open-source tools such as pecryptfs – Portable Userspace eCryptfs may help decrypting individual files.
  3. The lack of any sort of technical documentation for the data protection scheme is discouraging. This might be passable for the home user and occasional small office use, but unacceptable for anything beyond that.
  4. The encryption key cannot be changed. Enough said.

Conclusion: TerraMaster Folder Encryption

When it comes to attached storage encryption, we are still in the Stone Age. The lack of basic features, many of which we accept as a given, makes TerraMaster encryption hardly usable. The lack of technical documentation, undocumented functional restrictions and encryption metadata duplicated in every file makes this encryption hardly useful. TerraMaster OS does not separate Media Encryption Keys and Key Encryption Keys, which makes password changes impossible.

The lack of the key management, the inability to change the encryption password, and the inability to encrypt or permanently decrypt existing shares makes TerraMaster NAS encryption one of the least flexible implementations, on par with Thecus NAS encryption. The protection system uses the well-established eCryptfs encryption framework, yet the TOS implementation still lacks transparency or any sort of technical documentation. Security wise, the data would be impossible to decrypt without knowing (or breaking) the user’s encryption password (or, alternatively, without access to the exported encryption key).

At the same time, TOS encryption implementation is straightforward enough to appeal to some users. However, those same users may be put off by the need of re-entering their encryption password in the Web interface every time they power on or reboot the NAS.

Thecus has been manufacturing NAS devices for more than 15 years. The company develops an in-house Linux-based NAS OS, the ThecusOS. At this time, the most current version of the OS is ThecusOS 7. Thecus advertises secure data encryption in most of its NAS devices. The company’s volume-based encryption tool allows users to fully encrypt their entire RAID volume, defending essential data in instances of theft of the physical device. We found Thecus’ implementation of encryption somewhat unique. In this research, we’ll verify the manufacturer’s claims and check just how secure is Thecus’ implementation of 256-bit AES encryption.

Abstract and Summary

Thecus uses volume-based 256-bit AES encryption with a single, fixed, unchangeable encryption key. The 3968-byte (31744-bit) encryption key file is generated at the time the user creates a new encrypted volume based on the user’s password (4-16 characters, 0-9, a-z, A-Z only). Creating several encrypted volumes with the same password produces different encryption key files.

The encryption key is stored on an external USB drive (the only, forced option) and does not have any additional protection.

The encrypted volume is automatically unlocked once the user inserts the USB drive that contains the correct encryption key.

The original password the user typed when creating an encrypted volume is never used again, anywhere. Users cannot change the encryption password. Users cannot encrypt existing data. Users cannot permanently decrypt encrypted volumes. Any changes to encryption require deleting and re-creating the volume and filling it up with data. The entire encryption scheme lacks any sort of technical documentation.

The entire protection scheme is completely undocumented. For example, it is not clear what the password is used for since the user never has to type it again (ever) to mount or otherwise access encrypted volumes.

Note: SED is supported by ThecusOS but was not tested in our lab.

Test Bench

We analyzed a Thecus N2810 device based on an Intel Celeron Processor N2810. A non-SED WD Red HDD was used to set up the NAS perform the analysis. The NAS was running on the latest available version of ThecusOS 7.

Volume-Based Encryption

ThecusOS supports volume-based encryption. Unlike folder-based encryption that allows protecting (or not protecting) individual shares, volume-based encryption protects the entire RAID volume. The closest analogy to volume-based encryption would be BitLocker in Microsoft Windows or FileVault 2 in Apple macOS. However, the Thecus implementation is significantly more basic compared to Apple’s or Microsoft’s full-disk encryption tools.

Encrypting

Users can only encrypt newly created, empty RAID volumes (regardless of the number of disks; a single-disk RAID volume can be encrypted just as easily as a volume spanning across multiple physical disks).

Encrypting an existing volume is not possible. One must first remove the volume, create a new one and tick the “Encrypt” box. As a result, encrypting volumes with existing data is not supported.

The first step is creating a new volume:

The optional encryption feature requires a password. The password must be 4 to 16 characters long; character groups 0-9, a-z, A-Z are supported (no special characters and no local characters).

Users don’t have to memorize that password as they’ll never have to type it again to access the encrypted data. Instead, ThecusOS will generate a 3968-byte (31744-bit) encryption key, and store that key on an external USB drive that must be connected to the NAS at the time the encrypted volume is created.

Once the user inserts an external USB drive (e.g. a flash drive) into one of the available USB ports, the NAS saves the encryption key on that drive and creates and mounts the encrypted volume.

Mounting encrypted volumes

The encrypted volumes are mounted automatically when the user inserts a USB drive that contains the volume encryption key into any available USB port on the Thecus NAS. There are no additional prompts, and there is no need to open the Web UI.

The following scenarios are supported.

  1. The NAS is powered on or rebooted; no USB drive containing the encryption key is inserted. In this case, the encrypted volume is locked, and the data is not accessible.
    However, the NAS can still complete the boot sequence as the main OS (and some configuration files) are stored on a small NAND storage chip and not on the hard drive(s).
  2. The NAS is powered on or rebooted; the USB drive containing the encryption key is inserted. In this case, the encrypted volume will be mounted by the time the device completes the boot sequence.
  3. The most interesting scenario is when the NAS is powered on or rebooted without a USB drive inserted, and the user inserts the USB drive containing the encryption key at a later point. In this case, the OS will automatically recognize the USB drive, read the encryption key and automatically mount the encrypted volume.

Locking encrypted volumes

As we figured, encrypted volumes are mounted automatically when the user inserts the correct USB drive. What happens after the USB drive is removed? In this case, the NAS keeps the encrypted volume mounted. The volume remains mounted until the NAS is powered off or rebooted, or until the user manually locks the volume through the Web UI.

Decrypting

If you are used to BitLocker, you probably know it is easily possible to remove the password from an encrypted volume. Interestingly, BitLocker will not decrypt any data that has already been encrypted; instead, it’ll just store the unwrapped encryption key in the volume header, allowing the system to pick up the key and access information without a password. Any new information saved on such BitLocker volumes would be saved unencrypted.

With Thecus, the situation is much simpler. Users cannot remove encryption or permanently decrypt encrypted volumes, period. The only way to permanently decrypt the data is removing the encrypted volume, re-creating the volume without encryption and filling it up with data.

Changing the password: impossible

Decades ago, manufacturers came up with a brilliant idea of separating the binary keys that are used to actually encrypt and decrypt the data, and user-provided secrets that are used to access the data. In symmetric cryptography, only one unique binary encryption key may be used to encrypt and decrypt the data; this is called the Media Encryption Key (or Data Encryption Key). However, users can unlock encrypted data by using multiple different types of credentials such as plain-text passwords, credentials stored on secure smart cards or TPM modules, binary keys (files) or combinations of thereof. These credentials (Key Encryption Keys) are used to encrypt (wrap) the Media Encryption Key. Multiple different Key Encryption Keys may be used to wrap the same Media Encryption Key, allowing the user to instantly change their plain-text password, add or remove smart cards and other credentials.

ThecusOS 7 does not use the concept of Key Encryption Keys. The user’s original plain-text password is used to produce a single, fixed Media Encryption Key. Neither the password nor the encryption key can be changed after the volume is encrypted.

Observations

While users are required to enter a password when encrypting the volume, this password will never be used again anywhere in the ThecusOS interface. I was unable to find any references to this password in the Thecus technical documentation or the online knowledge base. The password is not used to decrypt data or to mount encrypted partitions. Users will never have to type that password again. In other words, the password seems completely redundant in this setup. The lack of a proper explanation, let alone comprehensive technical documentation, makes me shake my head.

ThecusOS produces different encryption keys when creating volumes protected with the same password. This is a good hint that the password is salted with some random data. The lack of proper documentation makes this guess as good as any others.

Thecus and SED Encryption

ThecusOS supports SED (Self-Encrypting Drive) encryption, as seen on the screen shot below.

We have not tested the SED implementation due to the lack of a compatible hard drive. Considering the cost and market positioning of the Thecus N2810, the model is likely to be used with consumer-grade NAS hard drives such as the Western Digital Red or Seagate Ironwolf series, both of which lack the SED support.

What Risks Are Covered by Thecus Security Model

The security model employed by the ThecusOS is stripped down to the bare essentials. I have the following remarks about the Thecus security model.

  1. It is not clear why the system prompts for a password if that password cannot be used to unlock volumes and cannot be changed. If the user’s password is only needed as a random seed of a sort, this must be properly disclosed and documented.
  2. The lack of any sort of technical documentation for the data protection scheme is discouraging. This might be passable for the home user and occasional small office use, but unacceptable for anything beyond that.
  3. The encryption key is stored on a separate USB drive. Users can conveniently insert that USB drive at any time to automatically unlock encrypted volumes. As a result, the entire protection scheme is based exclusively on “something you have”. Anyone who has access to the USB drive holding the encryption key will be able to mount encrypted volumes.

As one can see, it all comes down to whether or not the attacker has access to the USB drive containing the encryption keys.

If the USB encryption key is stored separately of the NAS unit, and the NAS is powered off, the encrypted data is protected against the theft of the hard drives and the theft of the whole NAS unit.

If the attacker has access to both the NAS unit and the USB drive containing the encryption key, the protection is nil.

Conclusion: Thecus Encryption vs. Microsoft BitLocker

When it comes to full-disk encryption, Microsoft BitLocker and Apple FileVault 2 are the first things that come to mind, with TrueCrypt and VeraCrypt being the most popular third-party implementations. Secure encryption, comprehensive key management and multiple methods for encrypting and unlocking volumes are supported by all of these crypto-containers.

When it comes to attached storage encryption, you are welcome back to the Stone Age. A typical NAS advertising 256-bit AES encryption lacks any kind of key management; often to the point the user cannot even change their encryption password without deleting the entire volume, re-creating, re-encrypting and re-filling with data. Many NAS manufacturers have no idea about the existence of separate Media Encryption Keys and Key Encryption Keys, let alone their multiple instances. A typical NAS sold to a home or small office user does not allow encrypting existing data or removing the password from encrypted volumes should you no longer need to protect them.

All of these statements are true for the ThecusOS 7. The lack of even the basic key management, the inability to change the encryption password, and the inability to encrypt or decrypt existing volumes makes Thecus NAS encryption one of the least flexible ever. The protection system lack transparency or any sort of technical documentation. How does the system come up with a 3968-byte encryption key based on the user’s 4 to 16-character password? In a case of data loss, is it possible to decrypt the data with the user’s password instead of the encryption key? Does the key contain the user’s password, the hash of a password, or is it mostly random data? None of these questions have answers in the technical documentation.

At the same time, the encryption implementation is simple and straightforward. Based on a file stored on a removable USB drive, the data would be impossible to decrypt without said USB drive (unless a vulnerability is found). This encryption would likely be sufficient to protect most data stored by home and small office users.

Challenges in Computer and Mobile Forensics: What to Expect in 2020

The past two years introduced a number of challenges forensic experts have never faced before. In 2018, Apple made it more difficult for the police to safely transport a seized iPhone to the lab by locking the USB port with USB restricted mode, making data preservation a challenge. The release of the A12 platform, also in 2018, made it difficult to unlock iOS devices protected with an unknown password, while this year’s release of iOS 13 rendered unlock boxes useless on iPhones based on the two most recent platforms.

On desktop and especially laptop computers, the widespread use of SSD drives made it impossible to access deleted data due to trim and garbage collection mechanisms. The users’ vastly increased reliance on cloud services and mass migration off the forensically transparent SMS platform towards the use of end-to-end encrypted messaging apps made communications more difficult to intercept and analyze.

Sheer amounts of data are greater than ever, making users rely more on external (attached) storage compared to using internal hard drives. Many attached storage devices are using secure encryption, some of them without even prompting the user. Extracting data from such devices becomes a challenge, while analyzing the huge amounts of information now requires significantly more time and effort.

The number of online accounts used by an average consumer grows steadily year over year. While password reuse and the use of cloud services to store and synchronize passwords makes experts’ jobs easier, the spread of secure, encrypted password management services is turning into a new challenge.

Knowing everyday challenges in desktop and mobile forensics, we can now peek into the future. (more…)

Skype synchronizes chats, text messages and files sent and received with the Microsoft Account backend. Accessing Skype conversation histories by performing a forensic analysis of the user’s Microsoft Account is often the fastest and easiest way to obtain valuable evidence. Learn how to use Elcomsoft Phone Breaker to quickly extract the complete conversation histories along with attachments and metadata from the user’s Microsoft Account.

What’s It All About?

With over 1.55 billion accounts and more than 420 million daily users, Skype is one of the world’s biggest instant messaging apps. While there is no lack of competition in the highly crowded market of instant messaging apps, Skype maintains its user base. This feature-rich app is available for all relevant platforms, and is actively developed and frequently updated by Microsoft. Skype is secure (enough) while maintaining transparency to the law enforcement, which makes Skype the only allowed VoIP communication app in countries such as the UAE. The free Skype-to-phone calls included with all Microsoft Office 365 subscriptions help Skype gain popularity among corporate and small office users, while integration with Alexa and Cortana voice assistants makes Skype the tool of choice for voice calls.

(more…)

Why wasting time recovering passwords instead of just breaking in? Why can we crack some passwords but still have to recover the others? Not all types of protection are equal. There are multiple types of password protection, all having their legitimate use cases. In this article, we’ll explain the differences between the many types of password protection.

The password locks access

In this scenario, the password is the lock. The actual data is either not encrypted at all or is encrypted with some other credentials that do not depend on the password.

  • Data: Unencrypted
  • Password: Unknown
  • Data access: Instant, password can be bypassed, removed or reset

A good example of such protection would be older Android smartphones using the legacy Full Disk Encryption without Secure Startup. For such devices, the device passcode merely locks access to the user interface; by the time the system asks for the password, the data is already decrypted using hardware credentials and the password (please don’t laugh) ‘default_password’. All passwords protecting certain features of a document without encrypting its content (such as the “password to edit” when you can already view, or “password to copy”, or “password to print”) also belong to this category.

A good counter-example would be modern Android smartphones using File-Based Encryption, or all Apple iOS devices. For these devices, the passcode (user input) is an important part of data protection. The actual data encryption key is not stored anywhere on the device. Instead, the key is generated when the user first enters their passcode after the device starts up or reboots.

Users can lock access to certain features in PDF files and Microsoft Office documents, disabling the ability to print or edit the whole document or some parts of the document. Such passwords can be removed easily with Advanced Office Password Recovery (Microsoft Office documents) or Advanced PDF Password Recovery (PDF files).

(more…)

Home users and small offices are served by two major manufacturers of network attached storage devices (NAS): QNAP and Synology, with Western Digital being a distant third. All Qnap and Synology network attached storage models are advertised with support for hardware-accelerated AES encryption. Encrypted NAS devices can be a real roadblock on the way of forensic investigations. In this article, we’ll review the common encryption scenarios used in home and small office models of network attached storage devices made by Synology. (more…)

Just like the previous generation of OLED-equipped iPhones, the iPhone 11 Pro and Pro Max both employ OLED panels that are prone to flickering that is particularly visible to those with sensitive eyes. The flickering is caused by PWM (Pulse Width Modulation), a technology used by OLED manufacturers to control display brightness. While both panels feature higher peak brightness compared to the OLED panel Apple used in the previous generations of iPhones, they are still prone to the same flickering at brightness levels lower than 50%. The screen flickering is particularly visible in low ambient brightness conditions, and may cause eyestrain with sensitive users.

Google has equipped its new-generation Pixel 4 and Pixel 4 XL devices with innovative OLED panels offering smooth 90 Hz refresh rates. While these OLED panels look great on paper, they have two major issues. First, the 90 Hz refresh rate is only enabled by Google at brightness levels of 75% or higher. Second, the displays flicker at brightness levels below 75%.

In this article, we’ll describe methods to get rid of OLED flickering on the last generations of Apple and Google smartphones without rooting or jailbreaking. (more…)

The first Microsoft Office product was announced back in 1988. During the past thirty years, Microsoft Office has evolved from a simple text editor to a powerful combination of desktop apps and cloud services. With more than 1.2 billion users of the desktop Office suite and over 60 million users of Office 365 cloud service, Microsoft Office files are undoubtedly the most popular tools on the market. With its backward file format compatibility, Microsoft Office has become a de-facto standard for documents interchange.

Since Word 2.0 released in 1991, Microsoft has been using encryption to help users protect their content. While certain types of passwords (even in the latest versions of Office) can be broken in an instant, some passwords can be extremely tough to crack. In this article we’ll explain the differences between the many types of protection one can use in the different versions of Microsoft Office tools, and explore what it takes to break such protection.

(more…)