A laptop encrypted end to end with VeraCrypt, part-way through being decrypted when it stopped. That leaves a drive in two states at once — and then chkdsk was run across the whole thing, which is where it went from awkward to serious.
A business user with their entire system drive encrypted. After a knock in transit the laptop worked normally for a few days, then Windows began reporting registry corruption.
Sensibly, the client decided to decrypt the drive so the files could be copied somewhere safe. The in-place decryption ran for several hours, the laptop got hot, and the process did not finish. On reboot the drive appeared briefly in Windows — and at that point the client ran chkdsk. The drive then disappeared entirely and never came back.
Worth saying clearly, because a good deal of misleading material exists on this.
A VeraCrypt volume cannot be opened without its password. The key that encrypts the data is itself protected by a key derived from your password through a deliberately slow function repeated hundreds of thousands of times — a design whose entire purpose is to make guessing impractical. There is no analysis of headers that reveals a key, no technique that reads encrypted sectors, and no laboratory anywhere that opens a correctly configured volume without the credentials.
This job was possible because the client had the password. They had, after all, been part-way through using it to decrypt the drive. Without it the work would have ended at the free diagnostic with nothing to charge for.
In-place decryption works through the volume progressively, reading each region, writing it back as plaintext, and advancing a marker recording how far it has reached.
Stop it halfway and the drive holds two different things at once. Everything before the marker is ordinary readable data. Everything after it is still ciphertext. The boundary sits wherever the process happened to stop.
That state is entirely recoverable and it is not something a file system can make sense of. Windows sees a volume whose first portion looks like a valid structure and whose remainder looks like noise.
Which is precisely what chkdsk was then asked to repair.
chkdsk exists to make a file system internally consistent, and it does that by discarding what it cannot reconcile.
Presented with a partly decrypted volume, it read the apparently valid structures at the start, followed their references into regions that made no sense — because those regions were still encrypted — and concluded, correctly by its own logic, that those records were corrupt. So it deleted them and rewrote the structures to match what it could verify.
The damage therefore was not to the encrypted data. It was to the metadata describing where everything lived, removed on entirely sensible-looking grounds. That is why the drive disappeared afterwards rather than merely being awkward.
The drive was imaged read-only first, and it did have physical trouble from the knock — reallocated sectors requiring graduated passes to get a complete image.
The decryption boundary was then located by statistical analysis, which is a more reliable method than looking for a marker that may itself have been damaged.
Encrypted data is, by design, indistinguishable from random: every byte value occurs with roughly equal frequency and the measured entropy sits at essentially the theoretical maximum. Ordinary file-system content does not behave that way at all — it contains structure, repetition, runs of zeroes in unused space, recognisable headers, text. Scanning the image and measuring that character across it shows exactly where one region ends and the other begins, to within a very small window.
Below the boundary, the file system was rebuilt from surviving structures and their backup copies. Above it, the still-encrypted region was decrypted using the client’s password and volume header, then rebuilt the same way. The two halves were reassembled into one coherent volume.
About 95%. The missing portion was material whose records chkdsk had discarded and whose contents could not be matched back by carving — largely small files, where signature carving is least reliable because there is little content to identify and the file may sit entirely within a single cluster.
Both mistakes here were reasonable ones. Decrypting to rescue the data was sound thinking. Running chkdsk on a volume showing errors is what everyone is told to do. The trouble is that neither is safe on a volume in a half-converted state, and nothing in the tooling warns you.
So: if a decryption stops partway, leave the drive exactly as it is and run nothing against it. Encrypted-drive work is £800 +VAT flat. Bring the password if you have it; where you do not, we will tell you honestly what the odds look like before you commit to anything.
Post it or bring it in. Either way the diagnostic costs nothing and commits you to nothing, and you get one figure in writing before a single screw is turned.
Nothing can begin until the device is on the bench, which makes this the only step that needs anything from you. Pack it properly, put your details in with it, and send it over. What follows is a free diagnostic and a written figure, in that order.
Posting it? Use something tracked and insured — whatever is on the drive is worth considerably more than the postage. Bringing it in? Weekdays, 9am to 5:30pm, and it still wants packing as above for the journey.
Tell us what the device is, what it is doing, and anything already tried — an engineer will come back with a realistic view of the odds and a price band, before you commit to posting anything.
We’ll get back to you soon. Anything pressing, call 0161 871 0788.
Not by attacking the cipher — that is not something anyone does. What we can attack is the password, using professional GPU-accelerated password recovery guided by whatever you remember. That works on short, reused or partly-recalled passwords and does not work against a long random passphrase. We will tell you at the free diagnostic which of those you are likely dealing with.
Two states at once. Everything before the point it reached is plaintext; everything after is still ciphertext. That is recoverable with the password, but no file system understands it, which is why Windows reports the volume as damaged.
Because it does exactly what it is designed to do. Faced with file records pointing into regions that look like nonsense — because they are still encrypted — it discards those records to make the file system consistent. It deletes the map on entirely reasonable grounds.
Not on a drive that is also failing. Resuming means hours of sustained reading and writing across the whole volume, which is the last thing a disk with bad sectors should be asked to do. Image it first.
Yes — the knock in transit had caused reallocated sectors, and that was probably why the decryption stalled in the first place. Encryption failures after a physical event are usually the physical event showing itself.
£800 plus VAT flat, quoted after a free 48-hour diagnostic, and we need the password or recovery key. Where those genuinely no longer exist we say so at the diagnostic and there is nothing to pay.
Kick off with an instant online quote, or ring us and talk it through first. Either way you’ll know a clear, fixed price before any work starts.