Tools & conceptsTechnicalUpdated October 17, 2026 · Data Recovery Cases Editorial Team

Encryption and Ransomware Recovery Tools

No single tool covers encryption and ransomware recovery end to end — identification, native platform utilities, key-escrow sources, imaging, constrained password recovery, ransomware identification, decryptors and output validation each answer a different part of the problem. Lawful encryption and ransomware are also two different technical problems: one depends on the owner’s own key material, the other on a key the attacker holds.

Tool roles across two different recovery problems

Encryption-identification tools look for BitLocker, LUKS, APFS encryption and VeraCrypt signatures, configuration and metadata. Their result is evidence, not a guaranteed diagnosis: high-entropy or RAW-looking data is also consistent with compressed or already-random content, a wrong partition offset or a damaged filesystem, and a missing or damaged header can make a genuinely encrypted volume look like noise. See Encryption Key Hierarchies and Recovery Metadata.
Native platform utilities — manage-bde and repair-bde for BitLocker, cryptsetup for LUKS, Disk Utility and diskutil for FileVault/APFS — are command families, not single tools. Within one family, some operations only report metadata, some unlock, some export decrypted data to a separate target and some change the source; the operations table below separates them.
Key and escrow sources are not software in the usual sense, and they are not interchangeable passwords: a BitLocker recovery password in a Microsoft account, Entra ID or AD DS, a key package, an MDM-escrowed personal recovery key, a LUKS header backup or an organization’s key-management system each satisfy a different dependency. A header backup may not match the volume’s current state (keyslots or passphrases changed after it was taken), and preserving metadata does not by itself unlock anything.
Imaging tools preserve the encrypted source, partition boundaries and encryption metadata where that is appropriate and possible; see What a Disk Image Preserves. What to preserve first depends on the system’s state. If plaintext is available now — an unlocked volume or a running NAS whose unlock after a restart is not confirmed — the choice between exporting that plaintext, a lower-level acquisition or a shutdown depends on source health, consistency and whether the volume can be unlocked again; there is no universal rule to keep it running or to power it off first (Remote NAS Recovery vs. Member-Level Reconstruction, Self-Encrypting Drives and Controller Encryption in RAID and NAS). For repair attempts and decryptor experiments the rule does not change: the original stays preserved and the work runs on a copy.
Password-recovery tools are appropriate only for the owner’s own data and only as a bounded feasibility check: a remembered partial password, known patterns, character substitutions or an old password list. Without such constraints, a strong password is usually not a realistic search target, and no tool should be framed as universal “cracking.” Never send passwords, recovery keys or key files to a website or to the editors.
Ransomware identification services, such as No More Ransom’s Crypto Sheriff and ID Ransomware, attempt to match a ransom note, a sample encrypted file or the attacker’s contact details against known families. A match is not guaranteed to be the exact variant, and identification does not mean a decryptor exists.
Verified decryptor repositories — No More Ransom, and tools published directly by security vendors, CERTs or law-enforcement agencies — are the only sources that should supply an actual decryptor.
Malware and incident-response tools cover disk and memory acquisition, log analysis and family identification as a specialist, forensic role, distinct from ordinary data recovery.
File-validation tools confirm that decrypted or exported output is actually usable — verifying archives, checking image/document/media integrity, and validating databases or virtual-machine filesystems rather than trusting a tool’s own success message; see How to Validate Recovered Data.

Same command family, different operations

Naming a utility says little until the specific operation is clear. The question to ask of each step is what it reads, what it writes, and where its output lands.

Scroll horizontally to see the full table →

Operation classes inside native encryption utilities. Examples are product-specific; check the documentation for the exact version in use.
Operation	Examples	Reads / writes	Output	Limitation
Query / inspect	`manage-bde` status; `cryptsetup luksDump`; Disk Utility disk information	Reads volume and header metadata	A report: encryption type, protectors or keyslots, identifiers	Does not unlock or repair. `luksDump` with its volume-key option exports a secret that can decrypt the container without a passphrase.
Unlock	`manage-bde` unlock; opening a LUKS mapping; unlocking an APFS volume	Needs a valid credential; mounting the unlocked filesystem read-write can change it	Access to plaintext through the platform	Requires an intact key path; a wrong or stale credential gives nothing.
Export / salvage	`repair-bde`	Reads the damaged source; writes decrypted contents to a separate output volume or image	A new decrypted copy	The output volume is completely overwritten; corrupted metadata also requires the matching key package.
Change / repair	`manage-bde` protectors, off, ForceRecovery; `cryptsetup` reencrypt, luksHeaderRestore; Disk Utility First Aid, Erase	Writes to the source volume or its metadata	A modified source	Not an inspection step: it can remove protectors, replace keyslots or rewrite data in place.

repair-bde is a recovery and export operation, not a metadata viewer and not an in-place repair of the source: Microsoft’s reference states that it attempts to reconstruct critical parts of a damaged BitLocker drive and salvage recoverable data, given a valid recovery password or recovery key, and warns that the contents of the output volume are completely deleted and overwritten by the decrypted contents. It also needs a key package when the BitLocker metadata is corrupt, and cannot repair a drive that failed during encryption or decryption. Choosing it only makes sense once the source is preserved, the credentials and key package are in hand, and the output target is a separate, expendable destination.

Change operations are product-specific and documented as such: Microsoft lists ForceRecovery as deleting all TPM-related key protectors (manage-bde reference); the cryptsetup pages state that luksHeaderRestore replaces all keyslots so that only the backup’s passphrases work afterward (luksHeaderRestore) and that reencrypt works on the device in place (reencrypt); Apple describes First Aid as checking for and fixing formatting and directory-structure errors (Repair a storage device). For the platform detail, see BitLocker Key Protectors and Damaged-Volume Recovery, LUKS Headers, Keyslots and Volume-Key Recovery and FileVault, APFS Encryption and Hardware-Bound Keys; drive- and controller-level encryption is a separate layer covered in Self-Encrypting Drives and Controller Encryption in RAID and NAS.

What an identification upload discloses

Identification services need real material from the incident. Crypto Sheriff asks for up to two encrypted files of no more than 1 MB each, or the ransom-note file, plus any email, URL, onion or bitcoin address from the demand, and submission is tied to its linked data-provisioning terms. ID Ransomware asks for a ransom note and/or a sample encrypted file, states that unmatched uploads may be shared with trusted malware analysts, and says it cannot guarantee that files are kept fully confidential.

A ransom note can carry victim identifiers, and an encrypted sample is still a copy of the organization’s or person’s file. Before uploading, check what the service requires and how it handles submissions, and follow the data owner’s policy.
Choose the least sensitive sample the service accepts — never medical, legal or other private documents just because they were encrypted.
Treat the result as a candidate family to confirm, not a verdict: a named service does not guarantee an exact variant match or an available decryptor.

A decryptor is version-specific evidence, not a universal fix

A working decryptor exists only for specific families and variants, for example where researchers found an implementation flaw or obtained a leaked or seized key — it is not a general-purpose ransomware-breaking tool, and it can fail entirely against a different version of the same family. No More Ransom lists per-tool scope (for example, specific versions or file extensions), tells users to read each tool’s how-to guide and remove the malware first, and states that it offers no guaranteed decryption.

Confirm provenance (the repository or publisher’s own page) and that the exact family, variant and stated preconditions match the case.
Run it only against a working copy, with the original encrypted files preserved unchanged.
Validate the output file by file. A decryptor’s “success” message is not content validation; partly decrypted or still-damaged files can look finished.

Do not run unknown decryptors against the only copy

Ransomware victims are themselves a common target for secondary scams. Use only trusted sources such as No More Ransom, a recognized vendor, a CERT or law-enforcement channel, and always test against a copy before running anything against the only surviving set of encrypted files.

An active infection or a business incident may require coordinated preservation, isolation and reporting decisions that depend on the environment, legal obligations and who is responsible for the response. This page covers classes of recovery tools, not an incident-response playbook; it does not prescribe a universal shutdown, reboot or memory-capture sequence. See Ransomware Encryption Patterns and Recovery Paths for how the encryption pattern shapes the realistic recovery paths.

Technical references: Microsoft repair-bde — output overwrite, key package · cryptsetup luksDump — header dump, volume-key warning · No More Ransom Crypto Sheriff — what is submitted · ID Ransomware — sample handling. Pages checked October 2026 (Microsoft reference for Windows 10/11 and Server 2016–2025; cryptsetup 2.9 manual); behavior can differ in other versions.