Archive for the ‘General’ category

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.


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.


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.


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.

For us, this year has been extremely replete with all sorts of developments in desktop, mobile and cloud forensics. We are proud with our achievements and want to share with you. Let’s have a quick look at what we’ve achieved in the year 2019.

Mobile Forensics: iOS File System Imaging

We started this year by updating Elcomsoft iOS Forensic Toolkit, and by a twist of a fate it became our most developed tool in 2019. The developments went through a number of iterations. The release of unc0ver and Electra jailbreaks enabled Elcomsoft iOS Forensic Toolkit to support physical acquisition for iOS 11.4 and 11.4.1 devices, allowing it to produce file system extraction via jailbreak.

In the meanwhile, we updated Elcomsoft Phone Viewer with support for file system images produced by GrayKey, a popular forensic solution for iOS physical extraction. Analysing GrayKey output with Elcomsoft Phone Viewer became faster and more convenient.

Later in February, Elcomsoft iOS Forensic Toolkit received a major update, adding support for physical acquisition of Apple devices running iOS 12. The tool became capable of extracting the content of the file system and decrypting passwords and authentication credentials stored in the iOS keychain. For the first time, iOS Forensic Toolkit made use of a rootless jailbreak with significantly smaller footprint compared to traditional jailbreaks.

Not long ago, Elcomsoft iOS Forensic Toolkit 5.20 was updated with file system extraction support for select Apple devices running all versions of iOS from iOS 12 to iOS 13.3. Making use of the new future-proof bootrom exploit built into the checkra1n jailbreak, EIFT is able to extract the full file system image, decrypt passwords and authentication credentials stored in the iOS keychain. And finally, the sensational version 5.21 raised a storm of headlines talking about iOS Forensic Toolkit as the ‘New Apple iOS 13.3 Security Threat’. Why? We made the tool support the extraction of iOS keychain from locked and disabled devices in the BPU-mode (Before-first-unlock). The extraction is available on Apple devices built with A7 through A11 generation SoC via the checkra1n jailbreak.

Mobile Forensics: Logical Acquisition

Later on, Elcomsoft Phone Viewer was further updated to recover and display Restrictions and Screen Time passwords when analysing iOS local backups. In addition, version 4.60 became capable of decrypting and displaying conversation histories in Signal, one of the world’s most secure messaging apps. Experts became able to decrypt and analyse Signal communication histories when analysing the results of iOS file system acquisition.

Desktop Forensics and Trainings

In 2019 we’ve also updated Advanced PDF Password Recovery with a new Device Manager, and added support for NVIDIA CUDA 10 and OpenCL graphic cards to Advanced Office Password Recovery. Advanced Intuit Password Recovery added support for Quicken and QuickBooks 2018-2019 covering the changes in data formats and encryption of newest Intuit applications. In addition, the tool enabled GPU acceleration on the latest generation of NVIDIA boards via CUDA 10.

We are proud to say that the many changes we implemented in Elcomsoft Distributed Password Recovery are based on the users’ feedback we received by email and in person, during and after the training sessions. We had several trainings this year in the UK, Northern Ireland and Canada. “Fantastic. Time well spent on the training and on software that will be very useful on cases in the future”, commented Computer Forensic Examiner.

Cloud Forensics

We learned how to extract and decrypt Apple Health data from the cloud – something that Apple won’t provide to the law enforcement when serving legal requests. Health data can serve as essential evidence during investigations. The updated Elcomsoft Phone Viewer can show Apple Health data extracted with Elcomsoft Phone Breaker or available in iOS local backups and file system images.

Very soon Elcomsoft Phone Breaker 9.20 expanded the list of supported data categories, adding iOS Screen Time and Voice Memos. Screen Time passwords and some additional information can be extracted from iCloud along with other synchronized data, while Voice Memos can be extracted from local and cloud backups and iCloud synchronized data.

Skype anyone? In December, Elcomsoft Phone Viewer and Elcomsoft Phone Breaker were updated to extract and display Skype conversation histories.

Desktop Forensics: Disk Encryption

Elcomsoft System Recovery received a major update with enhanced full-disk encryption support. The update made it easy to process full-disk encryption by simply booting from a flash drive. The tool automatically detects full-disk encryption, extracting and saving information required to brute-force passwords to encrypted volumes. In addition, the tool became capable of saving the system’s hibernation file to the flash drive for subsequent extraction of decryption keys for accessing encrypted volumes.

Cloud Forensics: iOS 13 & Authentication Tokens

Elcomsoft Phone Breaker 9.15 added the ability to download iCloud backups created with iPhone and iPad devices running iOS 13 and iPadOS. In addition, the tool became able to extract fully-featured iCloud authentication tokens from macOS computers.

Following this, Elcomsoft Phone Breaker 9.30 delivered a new iCloud downloading engine and low-level access to iCloud Drive data. Thanks to the new iCloud engine, the tool became capable of downloading backups produced by devices running all versions of iOS up to iOS 13.2. While advanced iCloud Drive structure analysis allows users to enable deep, low-level analysis of iCloud Drive secure containers.

Cloud Forensics: Google

Elcomsoft Cloud Explorer 2.20 boosted the number of data types available for acquisition, allowing experts to additionally download a bunch of new types of data. This includes data sources in the Visited tree, Web pages opened on Android devices, requests to Google Assistant in Voice search, Google Lens in Search history, Google Play Books and Google Play Movies & TV.

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…)

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…)

What can and what cannot be done with an iOS device using Touch ID/Face ID authentication as opposed to knowing the passcode? The differences are huge. For the sake of simplicity, we’ll only cover iOS 12 and 13. If you just want a quick summary, scroll down to the end of the article for a table.


Let’s get it out of the way: everything that’s listed below applies exclusively to AFU (After First Unlock) devices. You cannot use biometrics to unlock an iOS device that’s been restarted or powered on; such devices are in the state known as BFU (Before First Unlock).

BFU, Before First Unlock: The iOS device was restarted or powered off; you powered it on but cannot unlock it because it’s protected with an unknown passcode.

AFU, After First Unlock: The iOS device was unlocked (with a passcode) at least once after it’s been last rebooted or powered on.

Screen Lock: Unlocking the Device

Touch ID or Face ID can be only used to unlock AFU devices. In order to unlock a BFU device, you’ll have to use the passcode. Even if you manage to bypass the lock screen (via an exploit), you won’t be able to access most device data as it will be encrypted. The decryption key is generated when the user first unlocks the device; the key is based on the passcode.


If you are working in the area of digital forensics, you might have wondered about one particular thing in the marketing of many forensic solutions. While most manufacturers are claiming that their tools are easy to use and to learn, those very same manufacturers offer training courses with prices often exceeding the cost of the actual tools. Are these trainings necessary at all if the tools are as easy to use as the marketing claims?

We believe so. A “digital” investigation is not something you can “fire and forget” by connecting a phone to a PC, running your favorite tool and pushing the button. Dealing with encrypted media, the most straightforward approach of brute-forcing your way is not always the best.


Full-disk encryption presents an immediate challenge to forensic experts. When acquiring computers with encrypted system volumes, the investigation cannot go forward without breaking the encryption first. Traditionally, experts would remove the hard drive(s), make disk images and work from there. We are offering a faster and easier way to access information required to break full-disk system encryption by booting from a flash drive and obtaining encryption metadata required to brute-force the original plain-text passwords to encrypted volumes. For non-system volumes, experts can quickly pull the system’s hibernation file to extract on-the-fly encryption keys later on with Elcomsoft Forensic Disk Decryptor.

What’s It All About?

It’s about an alternative forensic workflow for accessing evidence stored on computers protected with full-disk encryption. Once the system partition is encrypted, there is nothing one can do about it but break the encryption. Elcomsoft System Recovery helps launch password recovery attacks sooner compared to the traditional acquisition workflow, and offers a chance of mounting the encrypted volumes in a matter of minutes by extracting the system’s hibernation file that may contain on-the-fly encryption keys protecting the encrypted volumes.

This new workflow is especially handy when analyzing ultrabooks, laptops and 2-in-1 Windows tablet devices such as the Microsoft Surface range featuring non-removable, soldered storage or non-standard media. With just a few clicks (literally), experts can extract all information required to launch the attack on encrypted volumes.

Elcomsoft System Recovery offers unprecedented safety and compatibility. The use of a licensed Windows PE environment ensures full hardware compatibility and boot support for systems protected with Secure Startup. The tool mounts the user’s disks and storage media in strict read-only mode to ensure forensically sound extraction. (more…)

There has been a lot of noise regarding GrayKey news recently. GrayKey is an excellent appliance for iOS data extraction, and yes, it can help access more evidence. As always, the devil is in the detail.

A couple of quotes first, coming from the company who now partners with GrayShift to bundle their mobile forensic software (one of the best on the market, I would say) with GrayKey. They do support GrayKey-extracted data as well, and here is what they say:

“From the first iPhone extraction from GrayKey we were blown away with the amount of data they recovered”

“we’re seeing data we haven’t seen in years”

Actually, this is not exactly the case. Speaking of full file system acquisition, it’s been us who were the first on the market some 3 years ago, see Physical Acquisition for 64-bit Devices, iOS 9 Support.

Since then, we’ve been actively developing and updating iOS Forensic Toolkit, adding support for newer versions of iOS. We published a number of articles in our blog describing the benefits of file system extraction and what you can get: location data, cached mail, app-specific data, CPU and network usage data and much more.

Yes, we use the different approach, that requires jailbreaking (more on that later).


In our previous article Why SSDs Die a Sudden Death (and How to Deal with It) we talked about SSD endurance and how it’s not the only thing affecting real life reliability. In that article, we assumed that manufacturers’ specifications of certain SSD models remain similar for a given SSD model. In fact, this is not the case. Quite a few manufacturers play tricks with consumers, releasing a certain SSD model with top notch specifications only to downgrade them at some point during the production cycle (but certainly after receiving its share of glowing reviews). While some OEMs do note the change at least in the revision number, the rest will just quote the small print allowing them to “change specifications at any time without prior notice”. We’ve seen well known SSD manufacturers switching from reliable MLC NAND to planar TLC trash within the same model (and zero notice to potential buyers). How can you tell which NAND configuration your particular SSD drive employs and whether or not it lives up to your expectations? Read along to find out.


Many thanks to Roman Morozov, ACELab technical support specialist, for sharing his extensive knowledge and expertise and for all the time he spent ditching bugs in this article.

In our previous article Life after Trim: Using Factory Access Mode for Imaging SSD Drives we only mentioned reliability of SSD drives briefly. As you may know, NAND flash memory can sustain a limited number of write operations. Manufacturers of today’s consumer SSD drives usually guarantee about 150 to 1200 write cycles before the warranty runs out. This can lead to the conclusion that a NAND flash cell can sustain up to 1200 write cycles, and that an SSD drive can actually survive more than a thousand complete rewrites regardless of other conditions. This, however, is not fully correct. Certain usage conditions and certain types of load can wear SSD drives significantly faster compared to their declared endurance. In this article, we’ll look why a perfectly healthy SSD drive with 98-99% remaining life can die a sudden death. We’ll also give recommendations on tools and approaches that can get the data back even if the SSD drive is corrupted or does not appear in the system. (more…)