Call us — 01223 655015
Mon–Fri · 9am–5:30pm · No fix, no fee
Start a free diagnostic →
// case file · SSD · NVMe 512 GB · BitLocker

Encrypted, and the key was still in memory.

A BitLocker-encrypted 512 GB Gen 3 NVMe drive requiring recovery. The volume key was recovered from the host machine's memory using Passware, and the drive decrypted from there.

← All case files · from £300 + VAT

// the brief

What arrived, and what it was doing.

BitLocker recovery divides sharply. With the recovery key or password, it is an ordinary job and the encryption adds almost nothing to the work. Without either, there is no route in — AES with a correctly generated key has no shortcut, no back door and no vendor override.

There is a narrow third case, and this was one of them. While a BitLocker volume is mounted, the key used to decrypt it exists in the host machine's memory, because the system needs it to read the disk. If that memory can be captured, the key can sometimes be recovered from it.

// diagnosis

What had actually failed.

The drive was a 512 GB Gen 3 NVMe module with BitLocker protection in place. The approach taken was to work from the host system's memory rather than from a recovery key.

This is a genuinely different route from anything that could be described as breaking the encryption. Nothing about AES was attacked. The key was located where the operating system had legitimately placed it in order to do its own work.

This route is narrow and it closes. It depends on the volume having been mounted and the machine's memory being available in a usable state. Once a machine has been powered down and left, that opportunity is gone. If a BitLocker volume matters and the machine is still running, say so on the first call.

// the work

What was done, and in what order.

StageMethodResult
AssessmentEncryption confirmed, recovery key unavailable Standard decryption route not open, so the memory-based approach was assessed. Alternative route
Key extractionVolume key recovered from memory using Passware The key located where the running system had placed it, rather than derived or attacked. Key obtained
ImagingNVMe module imaged sector by sector Encrypted volume imaged as it sat, with decryption applied afterwards to the image. Imaged
DecryptionVolume decrypted and file system rebuilt Data extracted from the decrypted image and verified before delivery. Recovered
// outcome

What came back.

The volume was decrypted and the data recovered.

It is worth being precise about what this job does and does not demonstrate. It does not mean BitLocker can be broken. It means that a key held in a running system's memory is in a different position from a key that exists only in a recovery document nobody kept.

// the transferable bit

What generalises from this job.

01 / CHECK THE OBVIOUS PLACES FIRST

The key usually exists

account.microsoft.com/devices/recoverykey for personal machines, Azure AD or Intune for work machines. These resolve the overwhelming majority of BitLocker cases at no cost.

02 / A RUNNING MACHINE IS DIFFERENT

Do not power it down

If a BitLocker volume is mounted and you have lost the key, the state of that machine matters. Ring before shutting it down.

03 / NOBODY BREAKS THE CIPHER

Including us

Every legitimate BitLocker recovery involves finding the key somewhere. Any firm claiming to defeat the encryption itself is describing something that does not exist.