l0ck3d

Btrfs volume: community report on recovery without a key

A community report says that on Btrfs volumes, original data blocks of some encrypted files may still be on disk. This page explains the report, its verification limits, and the preconditions. It gives no steps for the original disks and promises no recovery result.

Content reviewed: 2026-10-30

This page summarizes a community report. It is not an official conclusion or a recovery promise. Synology has not confirmed the report, and this site has not reproduced it.

Conclusion first

  • The report says: on a Btrfs data volume, for files where only the first 1 MiB was encrypted, or files encrypted in segments, original data blocks may still be on disk, so they may be retrievable without the key.
  • Final statistics in the report: 17,893 of 24,142 encrypted files (about 74%) were recovered. Files where only the first 1 MiB or segments were encrypted recovered at higher rates. Small files that were fully encrypted (1 MiB and below) could almost not be recovered.
  • This does not mean your data can be recovered. Whether there is any chance depends on the file system type, the encryption method, free space, and whether writes to the volume have stopped.

What the report says (source text)

  • Environment: a physical "black Synology" (DSM on non-Synology hardware), not a virtual machine. Btrfs data volume, DSM 7.2.1, machine not rebooted for 23 days.
  • Timing: response began about 27 hours after the ransom note appeared. The encryption process was no longer running.
  • Memory: about 15.86 GiB total. The scan found no usable session key.
  • Classification by encryption method: 0x26 (only the first 1 MiB encrypted) 10,220 files; 0x25 (segmented encryption) 7,197 files; 0x24 (whole-file encryption) 6,725 files; 24,142 files in total.
  • Final results: 0x26 10,200 files fully recovered (about 99.8%); 0x25 7,071 files fully recovered (about 98.2%); 0x24 117 files fully recovered. 17,893 files in total, about 274 GiB.
  • The early figures "about 99.9%" and "about 99%" were interim numbers during processing. Use the final results above.
  • Verification level: format level only (file headers, full decoding, visual spot checks). Not compared with the SHA of the originals.

Source: c3rb3r-rescue issue #12. The report author's repository README marks the status as "completed"; the statistics above follow that README.

Why it may work (this site's summary)

Btrfs usually writes modified content to a new location when a file changes, and old data blocks are not released immediately. If encryption changed only part of a file, the unchanged parts still point to old data blocks. The report argues that as long as any part of an old data block is still referenced, the whole block is not freed, so the original content of the encrypted section may still be on disk.

  • This is the report author's reasoning (summarized by this site). A professional needs to verify it file by file on a copy.
  • If a whole file was encrypted, the old blocks are no longer referenced. They are usually freed or overwritten, so recovery is hard.
  • This applies only to Btrfs. The report says ext4 does not use copy-on-write, so overwrites usually replace data directly at the original location.

Risk warnings (read this section first)

The following actions reduce what can be recovered, or make the original disks lose their value as evidence.

  • Do not delete .L0CK3D files. After deletion, the original data blocks may lose their last reference, and then be freed or overwritten.
  • Do not run defragmentation, balance, space reclamation, or repair.
  • Do not write recovered results back to the same volume.
  • Do not run any recovery tool on the original disks, including the read-only workflow described in the report. This site does not provide steps for the original disks.
  • Continued writes to the volume (photo indexing, sync, downloads, recordings) overwrite old data blocks. Contact a trusted technical person as soon as possible so that writes can be stopped.
  • Community tools have not been audited by this site. Do not run unknown decryptors, or any program that calls itself an "L0CK3D decryptor."

Stop condition: if you cannot confirm the volume's file system type, or cannot guarantee that the original disks will not be written to again, stop. Do not operate on it yourself.

Self-check: could this method apply?

  1. Confirm the file system is Btrfs. You can view the volume information in DSM's Storage Manager. Only view it, and change nothing. The menu location depends on your DSM version. If the volume is ext4, this route basically does not apply.
  2. Check whether the encryption process is still running. If it is, first follow Machine still running. Do not operate according to this page.
  3. Check the distribution of encryption types among the encrypted files. This requires parsing the footers of encrypted files. Ordinary users cannot judge this themselves, so a professional should do it.
  4. Check whether a usable copy exists. A copy can be used to verify recovery results. Keep both the originals and the copies.

If Synology runs in a virtual machine

  • You can copy the virtual disk on the host and use the copy as the working object. Leave the original disk and the original files untouched.
  • Whether to shut down the VM before copying should be decided by a technician. If the encryption process is still running, powering off loses memory. If the process has already exited, a professional should still confirm before operating.
  • After copying, do all further work only on the copy.

Pending confirmation

  • Whether this method still works after a shutdown or power loss: the report did not verify this. This site marks it as pending.
  • Applicability to other DSM versions, other encryption variants, and other file systems: pending.
  • Whether Synology officially endorses this method: not confirmed.

Sources and limits