Hardware and RAID configuration
4 x 2-TB SATA hard drives.
The shared volume suddenly became inaccessible.
- The tracing data does not contain any signature of known objects like boot sector,
MFT file-record, super block, inode... Even the signature of popular file types such
as JPG, PDF, ZIP, MS Office documents are not found.
- The only noticeable sign is that data in all 4 drives is highly random. This suggests
some kind of encryption or compression was implemented.
- Further analysis confirms that LUKS (Linux Unified Key Setup)
is used to encrypt the entire volume.
- The RAID configuration is quickly determined thanks to the location and structure of the LUKS header and its key material slots.
- Like other encryption projects, it is crucial to know both the password and the encryption algorithm.
- Two passwords are given and the customer is not quite sure which one is correct. It is also possible that none will work!
- The encryption algorithm can be retrieved from the LUKS header. In this case it uses the
AES encryption with mode
is a mode of block cipher in which each block is xor'ed with the previous ciphertext block before being encrypted.
The first block is xor'ed with the initialization vector (iv).
In this particular cbc-essiv mode, the iv is the encrypted sector number (with key is the
sha256-hash of the master key).
- The process to recover the master key from the user's password is as follow:
- The derived key in the LUKS header is used to validate the master key. It is fortunate that one of the given passwords is correct.
- Since File Scavenger® does not natively support disk encryption, it has to be modified to accept a new filter. The output data from the read operation is decrypted before being returned to the caller.
- After being decrypted, it is just a typical Ext4 volume and File Scavenger® fully supports this file system.
- It is a complete recovery.
- Over 1 TB of data of mostly family photos and videos is restored. The directory structure is also reconstructed.