How to self-rescue after Synology is encrypted by C3RB3R: recover old Btrfs data blocks without a key

Let’s start with the conclusion

If your Synology NAS is C3RB3R(file extension .L0CK3D, leaving read-me3.txt ransom note) encrypted, don’t rush to accept defeat, and don’t pay the ransom. As long as your share is Btrfs file system, and you haven’t performed destructive operations such as defrag / balance / forced repair,a large portion of the files can be recovered without a key. The reason is counterintuitive: C3RB3R rewrites files in place, while Btrfs copy-on-write (CoW) leaves the overwritten old content on disk; the plaintext of the original files is hidden in these old data blocks that have not been reclaimed.

The open-source community has already turned this recovery process into a set of tools:crt106/c3rb3r-btrfs-recovery(MIT license, read-only, only for recovering data you have the right to handle). This article explains its principles, route selection, step-by-step operations, and real case data clearly. If you haven’t been hit yet, please read firstthe previous article "Synology NAS Ransomware: Upgrade DSM First, Then Enable Immutable Snapshots"—prevention is far more important than post-incident recovery.

1. Two self-rescue routes, choose the right one first

Whether the files can be recovered: the first step is not to find tools, but to determinewhether the encryption process is still running. The returns of these two routes differ a lot:

Route A: The encryption process is still alive (greatest returns)

If it hasn’t been long since the incident, and the NAS has not been restarted, the encryption process (e.g.:/usr/bin/libgld -n 308, the program file may have been deleted from disk) is very likely still running in memory. The first thing to do at this point is:

1. 用 kill -STOP <pid> freeze it, do not kill, and even more so do not restart.
2. Then, following the methods of the other two repositories, from the process memory take thesession master keyout—this way you candecrypt all files, and the payoff is far greater than that of the Btrfs route below:
   • soimy/c3rb3r-rescue: evidence preservation, key recovery from RAM, copy and decryption
   • Benjamin-zlt/c3rb3r-baremetal-rescue: freeze the encryptor on a bare-metal DSM, export process memory, extract the session key, and fully decrypt (there is already a complete decryption case for a second independent victim)

Route B: the encryption process has exited (the gap filled by this repository)

If the NAS has already been restarted, or a dozen-plus hours have passed since the incident, the key is basically no longer findable in memory (the project author performed an exhaustive memory scan once, with a result of zero). In this case, use this repository's Btrfs old data block recoveryroute: it does not rely on the key and relies only on old plaintext left by the file system.

This article focuses on Route B. The two routes can be combined: first try to obtain the key, and if it cannot be obtained, then go with Btrfs.

II. Principle: why plaintext can still be recovered without the key

In one sentence:C3RB3R rewrote only several segments of the file, and the overwritten old content remained as whole blocks on Btrfs.

How exactly the encryption is done:

• Small files: encrypted as a whole;
• Files of 1–5MB: only the first 1MiB is encrypted;
• Large files: the three segments "head, middle, and tail" are encrypted, totaling about 12%.

Btrfs is a copy-on-write file system. When a file is overwritten in place, the new content is written toNew location, whilethe original data block (extent) is kept entirely on disk as long as it is still referenced by the “unencrypted part” of the file. These old extents are sandwiched at both ends of the file like bookends, and the author calls this phenomenon “bookend extent”。

What the recovery tool does is: according to Btrfs’s extent tree, map every rewritten byteback to its original old extent, read it out directly from the block device in read-only mode, and stitch the original bytes back together. Even better, on a share with “Data Checksum” enabled, it can also use Btrfs’s built-in CRC32C checksum to prove block by blockthat the recovered content is indeed correct.

A concrete example makes it easier to understand: for a 100MB home video, C3RB3R only encrypted three segments at the beginning, middle, and end, about 12MB total, and nearly 88MB of remaining plaintext lies untouched in old extents; while a 50KB document, because it is smaller than 1MiB, is encrypted as a whole, so no old plaintext can be found on disk. Thereforethe larger the file, the more checksums are enabled, and the earlier it was written (earlier than the latest snapshot), the higher the recoverable proportion; conversely, massive numbers of small files and databases are in the worst situation.

One easily misunderstood point:A NoCOW share with “Data Checksum” unchecked does not mean it is hopeless either. As long as the data write time is earlier than the subvolume’slast snapshot(even if the snapshot was later deleted), overwriting still uses copy-on-write—so old data from before the snapshot can still be recovered.

III. What is this tool

crt106/c3rb3r-btrfs-recovery is essentially an AI Agent skill (SKILL.md), for agents such as Claude Code, Codex, and Cursor that support the skill mechanism. It organizes the complete workflow, read-only tools, and verification methods of a real recovery into a general guide. There are three core design principles:

• Read-only: On the NAS side, it only performs ioctl queries, reads files, and reads block devices; results are written to a disk outside the NAS. It never writes files onto the data volume and never modifies anything;
• Verifiable: every recovered block can be compared against Btrfs checksums, distinguishing “exact recovery” from “speculative decoding”;
• Rollback-capable: when replacing candidate bytes locally, generate *.c3rbak a backup, byte-level rollback.

IV. Detailed steps (Btrfs recovery path)

Step 0: Guard the red lines first (this step is more important than recovery itself)

Before touching anything, these thingsmust absolutely not be done：

• Do not delete or overwrite any .L0CK3D files, and do not empty the recycle bin.The old data blocks are not reclaimed by the filesystem precisely because these ciphertext files “anchor” them—once you delete them, the old plaintext may be overwritten immediately, and then it is truly gone;
• Do not run defrag, balance,btrfs check --repair, as these will rewrite data and directly destroy old blocks;
• Do not pay the ransom, and do not run “decryptors” of unknown origin (many are secondary scams);
• Power off or disconnect the NAS as soon as possible to preserve the scene and reduce writes.

Step 1: Installation

Use skills CLI:

# 安装到当前项目
npx skills add crt106/c3rb3r-btrfs-recovery

# 全局安装，或指定 agent
npx skills add crt106/c3rb3r-btrfs-recovery -g
npx skills add crt106/c3rb3r-btrfs-recovery -a claude-code

Manual installation: copy skills/c3rb3r-btrfs-recovery/ the entire directory to the agent's skills directory (such as Claude Code's ~/.claude/skills/）。

Step 2: Environment self-check preflight

On any devicerun this step first, it will provide OK / WARN / FAIL and handling suggestions item by item:

cd skills/c3rb3r-btrfs-recovery/scripts
python mkjob.py -- preflight /volume1/某个文件.jpg.L0CK3D > job.sh
{ printf '%sn' "$SUDO_PW"; cat job.sh; } | ssh admin@NAS "sudo -S -p '' sh -s"

This part mkjob.py is responsible for packaging the tool and path list, and passing them to NAS for execution via SSH standard input,without writing files to the data volume。

Steps 3–6: determine generation → single-file verification → full survey → export verification

For this step, it is recommended to hand the situation directly to the agent; it will automatically execute according to SKILL.md. You can also run the script manually. The process is:

1. Determine the attack generation G_ATTACK: encryption formats differ slightly across generations; align them first;
2. Use a known original file for single-file verification: compare against a same-named file for which you still have the original locally, confirm the recovery logic is correct, then batch process;
3. Full survey: scan the entire volume, mark which bytes of each file have been overwritten and whether they can be recovered from old extents;
4. Streaming export + multiple verification: reassemble the recovered bytes, perform local multi-process decoding verification, compare against known originals, select the best candidate, and finally produce a report.

Several points to watch closely during hands-on operation:preflight If any item shows FAIL (for example, if it is found to be an ext4 volume, or Python 3 cannot be found on the NAS), do not continue yet; handle it according to its suggestions;G_ATTACK The generation is the baseline for all subsequent matching; a wrong judgment will cause the entire batch to mismatch; single-file verification must usefiles whose local originals you have confirmed are correctfor comparison; only after verification passes should you proceed with batch processing, and do not use suspected corrupted copies for verification.

Script division of labor overview

Step 7: Understand the report

The recovery report divides results into three categories; don't conflate them:

• Exact recovery and confirmed by checksum: Most reliable, Btrfs CRC32C matches block by block;
• Speculated then decoded successfully: Logical reassembly succeeded, but lacks checksum corroboration; recommend keeping it for verification;
• Failed: This part is truly gone.

V. Compatibility: Whether your environment can use it

The project has been Synology DSM 7.2.1(SHR,cachedev, Python 3.8) verified on real hardware. For other environments, please first run preflight, it will give recommendations item by item. Known adapted/to-be-verified cases:

• DSM 6, OMV, Unraid, devices without Python 3, removing the drive and connecting it to a Linux computer for offline processing—the documentation has customized guidance and error handling for each;
• Not applicable to ext4(most QNAP volumes, older Synology volumes),ZFS requires a different toolchain。

VI. Real cases: What was actually recovered

For the first case the author published, the recovery results are as follows:

In one sentence:Large files, shares with checksums enabled, and old data from before the snapshot have a high recovery rate; small files encrypted as whole files, databases, and content written only after the snapshot are basically hopeless.

VII. What cannot be recovered, and a few reminders

• Small files under 1MiBEncrypted as a whole, with no old plaintext left on the disk to recover;
• Database files(such as SQLite/PostgreSQL, which frequently rewrite entire files) are often rewritten in whole blocks, and the old blocks were overwritten long ago;
• Data written in NoCOW shares only after the last snapshotwhen overwritten, CoW was not used, so the old blocks do not exist;
• The tool itself is read-only, butany recovery operation carries riskplease preserve the evidence first, use known originals for small-sample verification first, and then perform batch operations;
• This is not a “one-click restore all files” solution; it is about recovering as much old plaintext as possible that happens to remain in the file system,how much can be recovered depends on the write volume and time——The fuller the volume and the longer the incident, the more old blocks are overwritten.

The three repositories can be used in combination:soimy/c3rb3r-rescue 和 Benjamin-zlt/c3rb3r-baremetal-rescue is responsible for “retrieving the key from memory while the process is still running”; this repository is responsible for “relying on old Btrfs data blocks after the key is gone”.

8. Several Common Misconceptions

• “Delete the ransom note and rename it, and it will work”: The file contents have already been encrypted and rewritten; renaming does not change the data; deleting .L0CK3D will instead cause the old data blocks to lose references and accelerate their reclamation by the file system, possibly making even data that could have been salvaged unrecoverable.
• “I enabled snapshots, so it can definitely be restored”: What snapshots save are additions and changes after the snapshot point, whereas here the encryption process directly rewrites the “current version” files; snapshots cannot cover the current files that have already been rewritten; this solution precisely leverages the “old blocks before the snapshot”, and when there are no snapshots, old blocks may also be retained due to CoW; do not treat snapshots as the only hope.
• “Paying someone to decrypt is easier”: Many “decryption services” from unknown sources are secondary scams; they not only fail to recover the data but also leak privacy; the solution in this article is read-only, free, and self-verifiable; prioritize it.
• “Old Synology volumes on ext4 and QNAP can also use it”: Not applicable. ext4 does not have copy-on-write; old blocks will not be retained, and a completely different approach is required.

Disclaimer

This project is provided “as is”,only for recovering data that you have the right to handle. The tool itself is read-only, but any recovery operation carries risks: first preserve evidence, first use known original files for small-sample verification, then perform batch operations. The author assumes no responsibility for data loss. This article is only a compilation and explanation of the open-source solution and does not constitute any professional technical service commitment; before actually taking action, be sure to first read SKILL.md and the references directory in the repository.