A laptop was fully end-to-end encrypted using VeraCrypt, and it was partially decrypted when the process stopped. This left the drive in two states at once. Once chkdsk was run over the entire disk, the situation got much worse.
This is a scenario, not a case study. It illustrates a common failure type that we address on a regular basis, and how it is approached, written from the technical side (versus as part of a single customer project). Please visit our documented case files here.
If a user initiates in-place decryption of a volume which has been fully encrypted using software such as VeraCrypt (or Microsoft's BitLocker) and then the process fails for some reason (e.g., loss of power, machine crash, faulty disk), the volume will no longer mount to show unencrypted data, and cannot be unlocked again as an encrypted volume.
Removing encryption in place is not just a change to your metadata. You have to read every sector on the volume, decrypt each sector, and write that back out as plaintext, working from one end of the disk to the other. Depending on how big your hard drive is, this can take several hours.
When you do this type of operation, your volume exists in two different states until you finish. Any sectors you’ve finished processing exist as plaintext. Any sectors you haven’t processed yet remain in their encrypted state. There’s also header information recording what position you’ve reached.
If the process stops part-way through and the boundary marker between the two states is lost or inconsistent, neither method can be used. In the case of the entire volume being treated as encrypted, the decrypted portion of the volume results in garbage. Conversely, when the entire volume is treated as if it were plaintext (i.e., as if it had never been encrypted), the resulting output is garbage from the encrypted section of the volume.
Encrypted and plaintext data are entirely different at the byte level. Ciphertext looks like complete randomness (i.e., no structure), whereas a file system’s plaintext has a very defined structure. It contains recognisable header information and repeating patterns as well as large numbers of consecutive zero bytes.
Scanning for the exact point where the statistical characteristics of the image change indicates the location of the boundary. In most cases, this is exactly at the sector level. The volume can now be assembled in two sections. The first section is the plaintext area, which is used without modification. The second area is the ciphertext, which is decrypted with the decryption key.
It should be noted that the decryption key is still required for the encrypted section of the volume; this technique addresses the boundary issue and not the actual encryption method used.
Do not resume the decryption. If you restart the process on a volume with an unreliable progress indicator, it may decrypt previously decrypted areas, resulting in those previously decrypted areas being re-encrypted. There will be no way to recover them by reversing that operation.
Not by attacking the cipher (no one does). What we do is attack the password. We use professional, GPU-accelerated password recovery systems that draw on whatever you remember to help find your password. These types of attacks work when your password is reused, if your password is relatively short, or if you partially recall your password. They will not work if you choose to use a long, truly random passphrase.
Two states at once. The data has gone back to being plaintext up to the point where it stopped decrypting; after that, it is still ciphertext. That can be restored with your password, but no file system understands this format, so when you try to view your volume, Windows displays it as being damaged.
It does its job. When faced with file entries that reference parts of a drive that appear to be nonsensical (as they are still encrypted), chkdsk will discard these entries in order to create consistency for the file system. It deletes the map of the file structure on entirely reasonable grounds.
No, you should not resume it on a drive that is also failing. To resume, you would have to write to/read from an entire volume continually for hours. This is precisely the type of activity that a disk with bad sectors should never have to perform. Therefore, we recommend that you image the drive prior to attempting to resume.
Yes. The impact while in transit resulted in reallocated sectors on the hard drive, and it was likely this failure that caused the decryption process to stall. Typically, if you experience an issue related to the encryption after some form of physical shock or other mechanical damage, it indicates that something physically went wrong with the disk.
£800 plus VAT fixed price, quoted after a free 48-hour diagnosis period. It requires your password or recovery key. If neither genuinely exists any more, we advise you of this at the end of our 48-hour diagnostic period and there is no cost.
An in-place conversion will touch each sector on the volume. An in-place conversion is one of the more risky types of maintenance you can perform on a regular basis; therefore, having a current backup of the data on your computer will make this task a non-event.
A laptop running on battery power, an unattended computer that automatically goes to sleep, or a scheduled restart of your computer will all stop this procedure. Simply plug in the unit and allow it to complete.