soimy/c3rb3r-rescue

This repository is an incident-response playbook and toolkit for C3RB3R / .L0CK3D ransomware on Synology DSM, the kind that renames files to .L0CK3D and drops read-me3.txt. It is written for victims and administrators (or an AI assistant working under their direction), and its central message is to preserve the scene before touching anything: the encryptor's memory may still hold the material needed to unlock per-file records. The README walks through stopping the process without killing it, isolating the NAS, capturing memory, checking independent ciphertext copies, and finally restoring in a clean environment (README, repository).

How recovery works

The analyzed malware derives encryption material per file and protects it with a session key, storing the protected record at the end of each file. If that session key can be extracted from the encryptor's memory, the footer records can be unlocked without the attacker's private key (README). A separate route needs no key at all: on Btrfs, copy-on-write may retain pre-overwrite data blocks, so files can sometimes be reconstructed if untouched ranges still point at older blocks. This depends on actual extent mappings, snapshots and later writes, not merely on a volume being Btrfs (Btrfs recovery guide).

Choosing a path

The README routes users by situation. If DSM runs in Proxmox VE and is still powered on, capture guest memory from the trusted host and search offline. If the machine is physical and the encryptor is still alive, stop and verify all threads, then save process memory before assessing whole-system capture (physical-machine guide). If the process is gone but the machine was not rebooted, preserve RAM and swap, but assume the key may not survive. If no key is available and the data volume is Btrfs, preserve snapshots and assess old-block recovery. After a reboot, previous process memory cannot be recovered; disks, dumps and snapshots still matter (README).

Evidence and limits

The repository reports its own case, where a memory-recovered key restored an approximately 49 GiB GitLab weekly backup matching its historical digest and an isolated restore recovered 80 projects (incident report). It also links an independent physical-machine report claiming roughly 84,500 recovered files with sample checking against known originals (case report), and community Btrfs tools that reconstruct files without a key; verification there varies between reports (community findings, Btrfs tools). These tools target one analyzed sample and format, so results are not universal. The project publishes one recovery candidate from its own case, but there is no evidence it decrypts another victim's files (key sharing).

Conditions to respect

The README warns not to reboot, power off, upgrade, reinstall or force-kill the encryptor before memory is preserved, not to delete ciphertext, snapshots or recycle-bin contents, and not to write recovered files back to the affected pool (README). Deeper command-level material lives in the skill references and tool-usage docs (tool usage, tool validation). No license is declared in the repository metadata, which matters if you intend to reuse the code beyond personal recovery. Success is not guaranteed; community reports include searches that found no key.