[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-105405":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":16,"stars30d":16,"stars90d":15,"forks30d":15,"starsTrendScore":17,"compositeScore":18,"rankGlobal":9,"rankLanguage":9,"license":9,"archived":19,"fork":19,"defaultBranch":20,"hasWiki":19,"hasPages":19,"topics":21,"createdAt":9,"pushedAt":9,"updatedAt":22,"readmeContent":23,"aiSummary":9,"trendingCount":15,"starSnapshotCount":15,"syncStatus":13,"lastSyncTime":24,"discoverSource":25},105405,"c3rb3r-rescue","soimy\u002Fc3rb3r-rescue","soimy","Evidence-based DSM ransomware recovery: preservation, RAM key recovery, copy decryption, and GitLab validation.",null,"Python",273,30,2,18,0,138,414,87.24,false,"main",[],"2026-11-01 00:16:00","# C3RB3R \u002F .L0CK3D ransomware rescue\n\nEnglish | [简体中文](README_CN.md)\n\n**NAS files renamed to `.L0CK3D`, with `read-me3.txt` appearing in folders? Preserve the scene first. Recovery may still be possible.**\n\nThis repository helps you or your AI assistant stop further damage, save memory, find recovery keys and restore copies. There are successful [PVE](docs\u002Fincident-report.md) and [community physical DSM](https:\u002F\u002Fgithub.com\u002Fsoimy\u002Fc3rb3r-rescue\u002Fissues\u002F14) cases. When no key can be found, some Btrfs files may still be recovered from old data blocks. **What survives depends on your system; there is no universal key.**\n\n> **Do not reboot, power off, upgrade, reinstall or `kill -9` the encryptor first.** Its memory may still hold recovery material. Do not delete ciphertext, snapshots or the recycle bin to free space, and do not write recovered files back to the affected storage pool.\n\n## What to do immediately\n\n1. **Stop encryption while preserving the process.** Identify the malicious process before using `sudo kill -STOP PID`, replacing `PID` with its verified process ID. Check that every thread is `T`; `D` means waiting for I\u002FO, not successfully stopped. Names can change: do not suspend or kill processes in bulk based on a name alone.\n2. **Contain access and synchronization.** Block NAS access to the Internet and other devices, checking both IPv4 and IPv6. Pause cloud and shared-folder synchronization to limit propagation. For remote work, first preserve a trusted console or restricted SSH connection so you retain access.\n3. **Save memory and the executable promptly.** Do not wait for a full inventory or vulnerability attribution. Use independent storage with enough space; verify the mount before writing. Keep large dumps out of `\u002Ftmp` and the affected data volume. Choose a capture route below.\n4. **Test a few independent ciphertext copies.** Look for intact copies of the same versions on computers, phones, in email or Git clones. Compare full SHA-256 digests or every byte before expanding recovery. Keep the original ciphertext throughout.\n5. **Restore service in a clean environment.** Recovering data does not make the compromised NAS trustworthy. Follow recovery with rebuilding, credential replacement and remediation of the entry point.\n\nIf you are unfamiliar with SSH or processes, give this page to an administrator or AI assistant using the prompt below. Do not reboot the affected system to prepare tools.\n\n## Choose your recovery route\n\n| Your situation | Next step |\n|---|---|\n| **DSM runs in PVE and is still powered on** | Preserve guest memory from the trusted host, then search offline. See [containment and PVE memory](skills\u002Fdsm-ransomware-rescue\u002Freferences\u002Fcontainment-memory.md) (Chinese). |\n| **Physical DSM, encryptor still alive** | Stop and verify all threads, save process memory first, then assess whole-system capture. Follow the [physical-machine guide](skills\u002Fdsm-ransomware-rescue\u002Freferences\u002Fphysical-memory.md). |\n| **Process gone, machine not rebooted** | Promptly preserve available RAM and actually used swap. Do not assume the key survives. Also check snapshots, other copies and the Btrfs route below. |\n| **No usable key, data volume is Btrfs** | Preserve existing snapshots and assess whether surviving file ranges still reference older data blocks. See [Btrfs recovery without keys](skills\u002Fdsm-ransomware-rescue\u002Freferences\u002Fbtrfs-recovery.md). |\n| **Already powered off or rebooted** | Restarting cannot recover the previous process memory. Preserve disks, existing dumps, snapshots and other copies; Btrfs recovery still needs assessment. |\n\n**“Never rebooted” does not mean “the key is still present”; “process exited” does not mean “all data is lost.”** Community reports include successes and searches with no key found. See [cases and verification limits](docs\u002Fcommunity-findings.md).\n\n## Why recovery can work\n\nThe analyzed program generates encryption material for each file, protects it with a **session key**, and stores the protected record at the end of the file. The session key may remain in the encryptor's memory. A matching key can unlock those records and allow file recovery without obtaining the attacker's private key.\n\n```mermaid\nflowchart LR\n    A[Save memory] --> B[Extract this session's key]\n    B --> C[Unlock file footer records]\n    C --> D[Recover copies and verify full contents]\n```\n\nA separate route needs no key: **Btrfs copy-on-write may retain data blocks from before the overwrite**. If untouched parts of a file still reference those blocks, reconstruction may be possible. Actual extent mappings, snapshots and subsequent writes determine whether this works; a Btrfs or NoCOW label alone is insufficient. See [crt106's explanation](https:\u002F\u002Fgithub.com\u002Fcrt106\u002Fc3rb3r-btrfs-recovery\u002Fblob\u002Fb831f3a0f718677b889f2998ff09a0b925baa56b\u002Fskills\u002Fc3rb3r-btrfs-recovery\u002Freferences\u002Fprinciples.md) and [our verification limits](skills\u002Fdsm-ransomware-rescue\u002Freferences\u002Fbtrfs-recovery.md).\n\n## Has it worked for anyone?\n\n- **This repository's PVE case:** a key recovered from memory restored an approximately 49 GiB GitLab weekly backup that matched its historical digest. An isolated restore recovered **80 projects**.\n- **[Benjamin-zlt's physical-machine case](https:\u002F\u002Fgithub.com\u002FBenjamin-zlt\u002Fc3rb3r-baremetal-rescue\u002Fblob\u002F906e81293153341f162ee1f176722d93ba1d8358\u002Fdocs\u002Fcase-report.md):** the author reports recovering about 84,500 files and checking a sample against known originals, using that machine's own key.\n- **[Community Btrfs tools](https:\u002F\u002Fgithub.com\u002Fcrt106\u002Fc3rb3r-btrfs-recovery):** an alternative that reconstructs files from older blocks without a key. Verification varies between reports; file counts do not mean every file was compared byte for byte.\n\nThese tools target an analyzed sample and format. [Other victims' reports](https:\u002F\u002Fgithub.com\u002Fsoimy\u002Fc3rb3r-rescue\u002Fissues\u002F14) have prompted physical-machine capture fixes and support for explicit session markers, but always test a few copies first. The repository also publishes [one recovery candidate from our case](docs\u002Fkey-sharing.md); there is currently no evidence that it decrypts another victim's files.\n\n## A prompt for your AI assistant\n\n> Read this repository's README and skills\u002Fdsm-ransomware-rescue\u002FSKILL.md. Help me respond to a suspected C3RB3R \u002F .L0CK3D incident. First establish the machine type, reboot history, encryptor state, management channel and independent destination storage. Within existing authorization, contain further damage and prioritize memory and executable preservation; do not kill a stopped encryptor. Validate candidate keys and full files on independent copies first. If no key is available, assess snapshots and Btrfs old-block recovery. Do not automatically reboot, execute malware or write to the affected volume. Clearly distinguish verified results from candidates.\n\nAdd your system version, physical\u002Fvirtual setup, discovery time, reboot history and available backups. **Do not publish passwords, memory dumps, keys or business files.**\n\n## When you need commands or deeper detail\n\n| Task | Guide |\n|---|---|\n| Capture physical-machine memory; inspect LiME dumps | [Physical-machine guide](skills\u002Fdsm-ransomware-rescue\u002Freferences\u002Fphysical-memory.md) |\n| Assess Btrfs recovery without a key | [Conditions, workflow and verification](skills\u002Fdsm-ransomware-rescue\u002Freferences\u002Fbtrfs-recovery.md) |\n| Set up analysis tools, inspect footers, decrypt copies | [Tool usage and maintenance](docs\u002Ftool-usage.md) |\n| Understand community successes, failures and scope | [Community findings](docs\u002Fcommunity-findings.md) |\n| Understand key reuse | [Key hierarchy and public candidate](docs\u002Fkey-sharing.md) |\n| Study algorithms, memory addresses and repeated encryption | [Reverse engineering and decryption](skills\u002Fdsm-ransomware-rescue\u002Freferences\u002Freverse-decrypt.md) (Chinese) |\n| Inventory files or restore GitLab | [Inventory and verification](skills\u002Fdsm-ransomware-rescue\u002Freferences\u002Finventory-verify.md) · [Isolated restore](skills\u002Fdsm-ransomware-rescue\u002Freferences\u002Fgitlab-restore.md) (Chinese) |\n| Read this incident's forensic records | [Incident report](docs\u002Fincident-report.md) · [Attack path](docs\u002Fattack-path.md) · [Evidence sealing](docs\u002Fevidence-seal.md) |\n| Check tests and tool limitations | [Tool validation](docs\u002Ftoolkit-validation.md) · [AI skill](skills\u002Fdsm-ransomware-rescue\u002FSKILL.md) (Chinese) |\n| Ask for help or contribute sanitized results | [Issues](https:\u002F\u002Fgithub.com\u002Fsoimy\u002Fc3rb3r-rescue\u002Fissues) |\n","2026-10-31 04:26:42","CREATED_QUERY"]