Home / Case Studies / Trust, Practice & Honest Limits
Trust, Practice & Honest Limits · case file

It Encrypted Itself After I Changed My Mind

He tried to encrypt an SSD, thought better of it, and it encrypted anyway. He began BitLocker on an external SSD of photos and videos, "interrupted the process by unplugging it", set a smaller password, "changed my mind about encrypting it and unplugged it" — then on reconnecting, "it encrypted anyway" He is unsure "if it got encrypted with the long password I set or the shorter one", and has supplied a list of password guesses. An interrupted BitLocker process that resumed and completed is recoverable if one of his passwords is correct — the encryption is sound, so the whole case turns on matching a password he very likely still holds, in some form, in his list.

SSD / NVMeEncryption / BitLocker
// case at a glance
MediaExternal SSD of photos and videos on which BitLocker encryption was started, interrupted, restarted with a different password, then completed automatically — the correct password uncertain, a list of remembered guesses provided.
Reported situationBitLocker begun on the SSD, then unplugged mid-process · a shorter password set on a second attempt · encryption abandoned in the owner's mind but resumed on reconnection · drive now fully encrypted · uncertainty over which password applies · a list of candidate passwords supplied.
Fault classA completed BitLocker volume with an uncertain but likely-known password — recovery contingent on identifying the correct password from the candidates, with the encryption itself intact and unbreakable without it.
Equipment usedDrive imaged under a hardware write-blocker before anything, all unlock attempts made against the image · BitLocker metadata read from a PC-3000 assisted image to confirm the encryption state and password-protection type · the supplied candidate passwords, and structured variations of them, tested against the image · targeted variation of near-miss candidates within the small, defined space his list allows · the volume unlocked and the filesystem read once the password matches, files validated by rendering.
// the decode

The decode

His confusion about which password applies is the whole question, and it is an answerable one. BitLocker completing with one password or another is not a mystery to the drive — the metadata records how the volume is protected, and each candidate can be tested against it. That he set a longer password, then a shorter one, and is unsure which "took" is exactly the kind of uncertainty that a structured search through his candidates resolves. The correct password exists; the task is finding which of his guesses, or a near variant, it is.

The encryption being sound is why the password is everything. A completed BitLocker volume cannot be opened without its password or recovery key — no laboratory brute-forces it in the general case, and it would be dishonest to imply the encryption can simply be bypassed. But this is not a general case of a wholly unknown password: he has a list of candidates he set himself, recently. That transforms an impossible problem into a tractable search within a small, defined space.

His password list is the asset that makes recovery realistic. A completely unknown password against BitLocker's deliberately slow key-derivation is not something to promise. A short list of passwords the owner remembers setting, plus systematic variations of them — capitalisation, a digit added, a character swapped, the kinds of near-misses people make — is a genuinely searchable space. The difference between those two situations is the difference between no and a real yes, and his providing the list puts this firmly in the second.

Everything is done on an image, which lets the search be exhaustive and safe. The drive is imaged first, and all password attempts run against the copy — so nothing risks the original, and the candidate list and its variations can be tested thoroughly without any consequence to the drive. Once a password matches, the volume unlocks and the photos and videos are read from the decrypted image.

The honest prognosis rests on the list, and is stated plainly. If the correct password is among his candidates or a close variation of one, the memories come back. If none matches and no variation succeeds — if the true password is genuinely not in what he remembers — then the sound encryption holds and the drive stays sealed. Which outcome applies is established by the search, and stated honestly, with no false assurance that a wholly forgotten password could be broken.

// on the bench

On the bench

The drive was imaged under a hardware write-blocker before anything, all unlock attempts made against the image. BitLocker metadata was read to confirm the encryption state and protection type, and the supplied candidate passwords, plus structured variations of them, tested against the image. Near-miss candidates were varied within the small defined space the list allowed, and once a password matched, the volume was unlocked and the filesystem read, the files validated by rendering.

// the outcome

The outcome

Encryption state confirmed, the candidate passwords and their variations tested against a preserved image, and the volume unlocked once a match was found. The diagnostic costs nothing and completes within two working days of arrival, and the quote is one fixed written figure with VAT already in it; if the data can't be brought back, no charge is made. The decode: the drive encrypting itself wasn't a fault — it resumed safely and locked with one of your passwords. Because you remember the candidates you set, matching the right one is a real, searchable task, and your memories come back with it.

A drive that encrypted with a password you're unsure of

Stop reconnecting and fiddling with the drive, and write down every password and variation you can remember setting — that list is what makes recovery possible, since a completed encryption can't be broken without the right password, but a known set of candidates is searchable. Don't accept any prompt to format the drive; the data is intact behind the encryption. Understand the honest limit: if the true password genuinely isn't among what you remember, sound encryption holds — but your remembered guesses are the real route in.

Sending this in from Swansea? Every case opens with the free diagnostic — completed within 2 working days of your media arriving — and one fixed written quote before any work: logical jobs run no fix, no fee; invasive drive-opening work takes 50% of the quote upfront; forensic-classed work is payable upfront in full. If the data is inside a laptop, PC, Mac or server, remove the hard drive or SSD and send us just the drive; we don’t provide an internal drive-removal service, and we don’t recover storage soldered to a motherboard (e.g. Apple Silicon Macs) — only drives that can be removed and sent to us. Post or courier tracked and insured to Bristol Data Recovery, Castlemead, Lower Castle Street, Bristol, BS1 3AG — full sending instructions and the shipping form are here.
Start a free diagnostic

Our case files are written up from genuine enquiries our lab has handled for customers across Swansea and South Wales, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery approach our engineers apply to that fault, using the equipment listed.

// related case files

More cases like this one

Browse all case studies →

Got a device with a story like this?

Free diagnostic, fixed quote, no fix no fee — start now or call the freephone.