Is it possible to tell if hard drive is encrypted?
We have two types of encryption here, "file based encryption" and "full disk encryption". There are documented forensics methods and software (e.g. EnCase) that help us detect the schemes and programs used to encrypt the disk.
I'm going to take a list of popular tools and standards and see if they leave any traces with which we can determine that they've been used:
- Bitlocker
Bitlocker is a full disk encryption standard available on windows operating system from Windows 7 onwards; this tool uses AES256 to encrypt the disk. A disk encrypted by bitlocker is different than a normal NTFS disk. The signature of "-FVE-FS-" can be found at the beginning of bitlocker encrypted volumes.
These volumes can also be identified by a GUID:- for BitLocker: 4967d63b-2e29-4ad8-8399-f6a339e3d00
- for BitLocker ToGo: 4967d63b-2e29-4ad8-8399-f6a339e3d01
- DiskCryptor/TrueCrypt/VeraCrypt
DiskCryptor is based on TrueCrypt. For both DiskCryptor and TrueCrypt we can detect their presence with the following criteria:- size of file or collection of clusters object is a multiple of 512,
- minimum size of object is 19KB, although by default is minimum 5MB,
- contains no specific file signature throughout the entire object, and
- has a high Shannon entropy or passes Chi-squared distribution test. Note that since there's no specific signature or header left behind we can't tell for sure if TrueCrypt (or its siblings) were used, by combination of several methods we can try to make better guess about its presence.
- FileVault
Filevault is Bitlocker's equivalent on Mac and offers full disk encryption. The signature of "encrdsa" or hex value of "65 6E 63 72 63 64 73 61" can be found at the beginning of FileVault encrypted volumes. - cryptsetup with LUKS
Linux Unified Key Setup is a disk encryption specification and can be used in cryptsetup on Linux which is a common tool for storage media volumes encryption. It is optional and users can choose not to use this format but if used we can detect its presence with "LUKS\xba\xbe" signature at the beginning of the volumes. - Check Point Full Disk Encryption
At sector offset 90 of the VBR, the product identifier "Protect" can be found. Hex value "50 72 6F 74 65 63 74" - GuardianEdge Encryption Plus/Anywhere/Hard Disk Encryption and Symantec Endpoint Encryption
At sector offset 6 MBR, the product identifier "PCGM" can be found. Hex value "50 43 47 4D" - McAfee Safeboot/Endpoint Encryption
At sector offset 3 MBR, the product identifier "Safeboot" can be found. Hex value "53 61 66 65 42 6F 6F 74" - Sophos Safeguard Enterprise and Safeguard Easy
For Safeguard Enterprise, at sector offset 119 of the MBR, the product identifier "SGM400" can be found. Hex value "53 47 4D 34 30 30 3A" - Symantec PGP Whole disk Encryption
At sector offset 3 MBR, the product identifier "ëH|PGPGUARD" can be found. Hex value "EB 48 90 50 47 50 47 55 41 52 44"
Measuring File Randomness To Detect Encryption
Methods discussed earlier may not be feasible for every disk/file encryption scheme since not all of them have specific properties that we can exploit to detect them. One other method is to measure the randomness of files and the closer they are to random, the more certain we are that encryption is used.
To do this we can use a Python script named file_entropy.py. The closer the entropy value is to 8.0, the higher the entropy.
We can extend this further and draw plots to visualize the distribution of bytes. (calculate-file-entropy)
One other pointer to detect encryption is that no known file signature will be spotted in the volume. (No jpg, no office documents, no known file types) And since compression methods (e.g. gzip, rar and zip) have known signatures we can differentiate them from encryption for the most part.
Sum up
- Use known signatures to detect encryption (if possible)
- Use special characteristics (minimum file size, high entropy, absence of any special file signature, etc.) to detect encryption
- Rule out compressed files using their signature
So going back to the main question, "Is it that easy to tell?", this falls under forensics methods, we may be dealing with steganography techniques. In a normal case where user isn't trying to fool us, it is somehow easy to tell encryption is in place but in real world scenarios where user's may try to hide things and deceive us they may just pipe /dev/urandom to a file! It's not gonna be easy.
While you can't tell for certain, you can tell within a certain range of confidence.
Encrypted data looks like white noise: each bit has exactly a 50% probability of being set, regardless of the rest of the bits; there is no correlation between any given bit and any of the others. It's purely random.
It turns out that this high quality of randomness isn't particularly common in a hard drive's normal lifecycle. In general there's some pattern or another. Either a residual pattern from the manufacturing process, or a pattern from the filesystem setup, or a pattern from current or previously-deleted files. So if a disk contains pure white noise, then the most likely explanation is that either someone did a "secure erase" on the drive, or it contains encrypted information.
As an exception, one common unencrypted form of data that often looks a lot like noise is compressed data. The higher the compression ratio, the more it will resemble encrypted data. Still, compressed data usually has tell-tale markers so a more careful examination can generally rule that out.
If the data is filled with randomness then that means that it is encrypted. Is it that easy to tell?
No. If I am going to throw out, or give away, a hard disk I would remove personal data from it by running a program like shred which replaces the contents with random data. Thus the presence of random data proves nothing.
You might then reformat that disk with some file system or other, which would make the first part of the disk look normal, and the rest random. That still doesn't prove if the random part is encrypted, or just left-over from the cleanup operation.
I'm a little surprised that most encryption products leave signatures lying around as described by Silverfox. That seems to lend the user open to brute-force decryption as described here:
