12. Analysis, acquisition
Encryption examination and recovery
An encrypted disk image is complete, verified evidence that cannot yet be read. The examination proceeds in three stages: identify what the encryption is, look for key material you already have (starting with memory), then pursue legitimate recovery sources. Password attacks come last, and only against copies. This section gives the method common to every platform; sections 13 to 15 give the Windows, Linux and macOS specifics, including the components of each product that must not be confused with one another.
Identify the encryption technology
Work on a working copy of the physical image. Examine the partition table and the first sectors of each volume:
- BitLocker volumes carry a recognisable signature in the volume header and a metadata structure identifying the volume, the protectors in use (TPM, PIN, password, recovery password, key file, domain escrow) and the recovery key identifier. Three copies of the metadata are stored on the volume, which matters when one is corrupt. The metadata can be read with tools such as the libbde utilities or the commercial suites without a key.
- LUKS volumes begin with a magic value and a header describing the cipher, the key derivation function and the key slots in use. The header can be dumped without a passphrase, and LUKS2 keeps a second copy of the header.
- VeraCrypt and TrueCrypt volumes have no signature by design. A partition or file that consists of high-entropy data from the first byte, with no recognisable header, is the usual indicator, together with the presence of the software, its configuration and its drive-letter history on the system volume. VeraCrypt keeps a backup of the volume header at the end of the volume.
- FileVault on macOS encrypts an APFS container; the container's structures identify it as encrypted.
- Self-encrypting drives encrypt in the drive's own controller and present plaintext when unlocked. A physical image taken through a locked drive is ciphertext; taken through an unlocked drive it is plaintext. Record which.
- Other full-disk or container products (enterprise endpoint encryption, third-party containers, encrypted archives and databases) are identified by their signatures, the installed software, and configuration and log files on the system volume.
Also measure entropy across the image. Regions of uniformly high entropy with no structure are encrypted, compressed or random; regions with structure are not. A plot of entropy against offset often reveals an encrypted container inside an otherwise ordinary volume, or the boundary of a hidden volume.
Key material in memory
If memory was captured while a volume was unlocked, the memory image may contain the key. Tools search memory for the characteristic structure of cipher key schedules (the expanded AES round keys are the usual target) rather than for the key itself; open-source utilities exist for this, and the commercial forensic decryption products (for example those from Passware and Elcomsoft) combine the search with the logic to apply a found key to a BitLocker, VeraCrypt or LUKS image. The memory image may also contain the encryption software's own structures, which identify mounted volumes, their paths and their state, and cached passwords or recovery keys in plaintext.
Record every candidate key found, its offset in the memory image and the tool and version that found it. A key that decrypts the volume is verified by the result: the decrypted volume presents a valid filesystem whose structures can be parsed. A key that does not is retained and noted; it may be for a different volume, or the volume may be damaged (below).
Legitimate recovery sources
If usable key material is not recovered from memory, or memory was not captured, work through the sources the organisation legitimately holds, in each case with authority and with the request and response recorded:
- Active Directory. BitLocker recovery passwords are commonly escrowed against the computer object. Search by the recovery key identifier recorded from the volume metadata.
- Microsoft Entra ID. Devices joined to Entra ID escrow BitLocker recovery keys against the device record.
- Enterprise key escrow maintained by the encryption product itself, and the administrative consoles of endpoint encryption products.
- Mobile device management systems, which frequently hold recovery keys for the devices they manage.
- Authorised corporate password vaults, with the vault administrator retrieving and recording the entry.
- Recovery keys printed, saved to a file, saved to a USB device or stored in a user's cloud account, any of which may be found on other seized media.
- Administrator-held credentials, including local administrator accounts and break-glass accounts.
- Keyfiles for products that support them, which may be on removable media or elsewhere on the system.
- Backups. A backup of the same data taken before encryption, or an unencrypted backup of an encrypted volume, may make decryption unnecessary for the material that matters.
Password recovery and cracking
Only after the sources above are exhausted, and only with authority, attempt password recovery. Extract the authentication material (the BitLocker metadata, the LUKS header, the VeraCrypt volume header) from a working copy and attack that extract on separate hardware. Never attack the original evidence, and never attack the working image in place. Attacks are run against the extract with dictionaries, rules and any candidate words obtained lawfully from the investigation (other recovered passwords, names, dates). Record the tool, version, attack configuration, duration and outcome, including the outcome "not recovered", which is a finding in its own right and must be reported as carefully as a success.
Be realistic in what you report. A strong passphrase with a modern key derivation function is not recoverable by brute force in any useful time, and a report that implies otherwise misleads the reader. State the limitation.
Failed decryption is not proof of a wrong key
When a key, password or recovery key is rejected, do not conclude that it is wrong. Consider, and test for, each of the following:
- The volume header or metadata is corrupted. Try the backup metadata (BitLocker's additional copies, the LUKS2 secondary header, VeraCrypt's backup header at the end of the volume).
- The volume offset is wrong: the partition table is damaged and the tool is looking at the wrong sector for the header (section 18).
- The image is incomplete in the header region: check the ddrescue map.
- The key is for a different volume, container or hidden volume.
- The wrong tool version, key derivation parameters or cipher were assumed.
Record each hypothesis tested and its result. A decryption that succeeds only after the header is reconstructed from a backup copy has produced a derived artefact (the decrypted volume) by a method that must be described, and the reconstruction of the header is a finding to report.
Working with the decrypted volume
Decrypt to a new file, never in place. The decrypted volume is a derived artefact: hash it, record the tool, version, key source and command, and treat it as a new working copy. The encrypted image remains the master. Another examiner given the encrypted image and the key must be able to produce a byte-identical decrypted volume, and the hash proves it.
Example. A workstation image contains a BitLocker system volume and a second partition of uniform high entropy with no signature. The memory image yields an AES key schedule at a recorded offset which decrypts the BitLocker volume; the hash of the decrypted volume is recorded and the decryption reproduced by a colleague from the same inputs. The second partition is not decrypted by any key found in memory. The system volume shows VeraCrypt installed and a drive letter history for a mounted volume. The report states, as observed facts, the entropy measurement, the VeraCrypt installation and the drive letter history; as interpretation, that the partition is probably a VeraCrypt volume; and, as a limitation, that it was not decrypted and its contents are unknown.