Wie man sich nach einer C3RB3R-Verschlüsselung auf Synology selbst rettet: Wiederherstellung alter Btrfs-Datenblöcke ohne Schlüssel

Zuerst das Fazit

Wenn dein Synology NAS von C3RB3R(Dateiendung .L0CK3D, hinterlässt read-me3.txt Lösegeldforderung) verschlüsselt wurde, verzweifle nicht vorschnell und zahle kein Lösegeld. Solange deine Freigabe auf Btrfs-Dateisystembasiert und noch keine destruktiven Operationen wie defrag / balance / erzwungene Reparatur durchgeführt wurden,kann ein großer Teil der Dateien ohne Schlüssel wiederhergestellt werden. Der Grund ist kontraintuitiv: C3RB3R überschreibt Dateien „in-place", und Btrfs' Copy-on-Write (CoW) behält den überschriebenen alten Inhalt auf der Platte – der Klartext der Originaldateien verbirgt sich in diesen nicht freigegebenen alten Datenblöcken.

Die Open-Source-Community hat diesen Wiederherstellungsprozess bereits in ein Werkzeug gefasst:crt106/c3rb3r-btrfs-recovery(MIT-Lizenz, read-only, nur zur Wiederherstellung von Daten, über die du verfügungsberechtigt bist). Dieser Artikel erläutert das Prinzip, die Auswahl des Vorgehens, die schrittweise Durchführung und echte Falldaten. Falls du noch nicht betroffen bist, lies zuerstden vorherigen Artikel „Synology NAS von Ransomware befallen: Erst DSM aktualisieren, dann unveränderliche Snapshots aktivieren"– Vorbeugen ist weit wichtiger als nachträgliche Rettung.

1. Zwei Selbstrettungswege – zuerst die richtige Wahl treffen

Ob die Dateien zurückgeholt werden können, hängt im ersten Schritt nicht von den Tools ab, sondern von der Einschätzung,ob der Verschlüsselungsprozess noch läuft. Die beiden Wege unterscheiden sich stark im Nutzen:

Weg A: Der Verschlüsselungsprozess läuft noch (größter Nutzen)

Wenn der Vorfall noch nicht lange zurückliegt und das NAS nicht neu gestartet wurde, läuft der Verschlüsselungsprozess (z. B.:/usr/bin/libgld -n 308, die Programmdatei wurde möglicherweise bereits von der Festplatte gelöscht) sehr wahrscheinlich noch im Speicher. Die erste Maßnahme ist dann:

1. 用 kill -STOP <pid> ihn einfrieren, nicht killen und erst recht nicht neu starten.
2. Dann nach der Methode der beiden anderen Repositories aus dem Prozessspeicher denSession-Master-Keyextrahieren – so lassen sichalle Dateien entschlüsseln, der Nutzen ist deutlich größer als bei der folgenden Btrfs-Route:
   • soimy/c3rb3r-rescue: Beweissicherung, Wiederherstellung des Schlüssels aus dem RAM, Kopieren und Entschlüsseln
   • Benjamin-zlt/c3rb3r-baremetal-rescue: Auf einem physischen DSM den Verschlüsseler einfrieren, Prozessspeicher exportieren, Sitzungsschlüssel extrahieren, vollständige Entschlüsselung (es gibt bereits einen vollständigen Entschlüsselungsfall eines zweiten unabhängigen Opfers)

Route B: Der Verschlüsselungsprozess wurde bereits beendet (die Lücke, die dieses Repository schließt)

Wenn NAS bereits neu gestartet wurde, oder der Vorfall bereits über zehn Stunden zurückliegt, sind im Speicher grundsätzlich keine Schlüssel mehr zu finden (der Autor dieses Projekts hat einen erschöpfenden Speicherscan durchgeführt, das Ergebnis war null). Dann geht man die in diesem Repository beschriebene Btrfs-Wiederherstellung alter DatenblöckeRoute: unabhängig vom Schlüssel, nur gestützt auf die alten Klartextdaten, die das Dateisystem hinterlassen hat.

Dieser Artikel konzentriert sich auf Route B. Beide Routen lassen sich kombinieren: zuerst versuchen, den Schlüssel zu erhalten, und falls das nicht gelingt, auf Btrfs wechseln.

II. Prinzip: Warum man auch ohne Schlüssel den Klartext wiederherstellen kann

In einem Satz:C3RB3R hat nur einige Abschnitte der Dateien überschrieben, und der überschriebene alte Inhalt ist auf Btrfs als ganzer Block erhalten geblieben.

Wie genau verschlüsselt wird:

• Kleine Dateien: vollständige Verschlüsselung;
• Dateien von 1–5MB: nur die ersten 1MiB werden verschlüsselt;
• Große Dateien: „Kopf, Mitte, Ende“ werden in drei Segmenten verschlüsselt, insgesamt etwa 12%.

Btrfs ist ein Copy-on-Write-Dateisystem. Wenn eine Datei in-place überschrieben wird, werden die neuen Inhalte aneine neue Positiongeschrieben, währenddie ursprünglichen Datenblöcke (extent) vollständig auf dem Datenträger erhalten bleiben, solange sie noch von den „nicht verschlüsselten Teilen“ der Datei referenziert werden. Diese alten extents klammern die Datei an beiden Enden wie Buchstützen ein, und der Autor nennt dieses Phänomen „bookend extent“。

Was das Wiederherstellungstool tut, ist: entlang des Btrfs-extent-Baums jedes überschriebene Byteauf seinen ursprünglichen alten extent zurückzuführen, direkt vom Blockgerät schreibgeschützt auszulesen und zu den Originalbytes zusammenzusetzen. Noch besser: Auf Freigaben mit aktivierter „Datenprüfsumme“ lässt sich mit der Btrfs-eigenen CRC32C-Prüfsumme Block für Block nachweisen, dass die wiederhergestellten Inhalte tatsächlich korrekt sind.

Ein konkretes Beispiel macht es verständlicher: Bei einem 100MB großen Heimvideo verschlüsselt C3RB3R nur drei Segmente am Anfang, in der Mitte und am Ende von etwa 12MB; die restlichen knapp 88MB Klartext liegen unverändert im alten extent. Ein 50KB großes Dokument hingegen wird, weil es kleiner als 1MiB ist, vollständig verschlüsselt, sodass auf der Platte kein alter Klartext mehr zu finden ist. DaherJe größer die Datei, je häufiger die Prüfsumme aktiviert ist und je früher geschrieben wurde (früher als der letzte snapshot), desto höher ist die Quote des Wiederherstellbaren; umgekehrt sind massenhaft kleine Dateien und Datenbanken am schlechtesten dran.

Ein leicht misszuverstehender Punkt:Ein NoCOW-Sharing ohne aktivierte „Datenprüfsumme" bedeutet ebenfalls nicht, dass nichts zu retten ist. Solange die Daten früher geschrieben wurden als derletzte snapshotdes Subvolumes (auch wenn der snapshot später gelöscht wurde), wird beim Überschreiben weiterhin Copy-on-Write verwendet – daher lassen sich alte Daten von vor dem snapshot trotzdem retten.

Drei, was dieses Tool ist

crt106/c3rb3r-btrfs-recovery Im Wesentlichen ist es eine AI-Agent-Skill (SKILL.md), die für Agents wie Claude Code, Codex, Cursor usw. gedacht ist, die den Skill-Mechanismus unterstützen. Es fasst den vollständigen Ablauf einer echten Wiederherstellung, Read-only-Tools und Verifikationsmethoden zu einer allgemeinen Anleitung zusammen. Die Kern-Designprinzipien sind drei:

• Read-only: Auf der NAS-Seite werden nur ioctl-Abfragen, Dateilesen und Blockgerätelesen durchgeführt; die Ergebnisse werden auf eine Platte außerhalb der NAS geschrieben, es werden niemals Dateien auf dem Datenvolume abgelegt und niemals irgendwelche Dinge umgeschrieben;
• Verifizierbar: Jeder wiederhergestellte Block kann mit der Btrfs-Prüfsumme abgeglichen werden, um zwischen „exakter Wiederherstellung" und „spekulativer Dekodierung" zu unterscheiden;
• Rückrollbar: Beim lokalen Austausch von Kandidatenbytes wird ein *.c3rbak Backup erzeugt, byte-genaues Rollback.

Vier, detaillierte Schritte (Btrfs-Wiederherstellungsroute)

Schritt 0: Zuerst die roten Linien einhalten (dieser Schritt ist wichtiger als die Wiederherstellung selbst)

Bevor irgendetwas verändert wird, sollten diese Dingeauf keinen Fall getan werden：

• Keine .L0CK3D Dateien löschen oder überschreiben, und auch den Papierkorb nicht leeren.Die alten Datenblöcke werden gerade durch diese verschlüsselten Dateien „festgehalten" und deshalb nicht vom Dateisystem freigegeben – sobald du etwas löschst, können die alten Klartextdaten sofort überschrieben werden und sind dann wirklich weg;
• Kein defrag, balance,btrfs check --repair, diese würden Daten neu schreiben und die alten Blöcke direkt zerstören;
• Kein Lösegeld zahlenund führen Sie auch keine „Decryptor“ unbekannter Herkunft aus (viele davon sind Sekundärbetrug);
• Schalten Sie das NAS so schnell wie möglich stromlos oder trennen Sie es vom Netz, um den Zustand zu sichern und Schreibvorgänge zu reduzieren.

Schritt 1: Installation

Mit der 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

Manuelle Installation: Kopieren Sie skills/c3rb3r-btrfs-recovery/ das gesamte Verzeichnis in das Skill-Verzeichnis des Agent (z. B. bei Claude Code ~/.claude/skills/）。

Schritt 2: Umgebungs-Selbstprüfung preflight

Auf jedem GerätFühren Sie zuerst diesen Schritt ausEr gibt Punkt für Punkt OK / WARN / FAIL und Handlungsempfehlungen aus:

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"

Hier mkjob.py ist dafür verantwortlich, die Werkzeug- und Pfadliste zu paketieren und sie über SSH-Standardeingabe an das NAS zur Ausführung zu übergeben,ohne Dateien auf dem Datenvolume abzulegen。

Schritte 3~6: Generation bestimmen → Einzeldatei-Verifikation → Vollständige Bestandsprüfung → Export-Verifikation

Für diesen Schritt wird empfohlen, die Situation direkt an den Agent zu übergeben; er führt sie gemäß SKILL.md automatisch aus; alternativ können Sie das Skript manuell ausführen. Der Ablauf ist:

1. Angriffsgeneration G_ATTACK bestimmen: Die Verschlüsselungsformate unterscheiden sich je nach Generation leicht, daher zuerst angleichen;
2. Einzeldateivalidierung mit bekannten Originalen durchführen: Nimm eine Datei mit gleichem Namen, deren Original du lokal noch hast, zum Abgleich, bestätige die korrekte Wiederherstellungslogik und dann erst im Batch;
3. Vollständige Bestandsaufnahme survey: Das gesamte Volume scannen und markieren, welche Bytes jeder Datei überschrieben wurden und ob sie aus alten extents wiederhergestellt werden können;
4. Streaming-Export + Mehrfachvalidierung: Die wiederhergestellten Bytes zusammensetzen, lokal mit Mehrprozess-Dekodierung validieren, gegen bekannte Originale abgleichen, den besten Kandidaten auswählen und abschließend einen Bericht erstellen.

Bei der praktischen Durchführung sind folgende Punkte besonders zu beachten:preflight Tritt bei irgendeinem Punkt FAIL auf (z. B. es wird ein ext4-Volume erkannt oder Python 3 ist auf dem NAS nicht auffindbar), nicht fortfahren, sondern gemäß den gegebenen Empfehlungen vorgehen;G_ATTACK Die Algebra ist die Referenz für alle nachfolgenden Abgleiche; eine Fehlbestimmung führt dazu, dass der gesamte Batch nicht übereinstimmt; die Einzeldateivalidierung muss unbedingt mitDateien abgeglichen werden, bei denen du bestätigt hast, dass das lokale Original fehlerfrei ist, und erst nach bestandener Validierung den Batch freigeben; keine vermutlich beschädigten Kopien zur Verifizierung verwenden.

Übersicht der Skriptaufgaben

Schritt 7: Den Bericht verstehen

Der Wiederherstellungsbericht teilt die Ergebnisse in drei Kategorien ein, die nicht vermischt werden sollten:

• Exakte Wiederherstellung, durch Prüfsumme bestätigt: Am zuverlässigsten, Btrfs CRC32C stimmt Block für Block überein;
• Vermutet und Dekodierung erfolgreich: Logisch erfolgreich zusammengesetzt, aber ohne Prüfsummen-Bestätigung, zur Überprüfung aufbewahren empfohlen;
• Fehlgeschlagen: Dieser Teil ist wirklich verloren.

Fünf, Kompatibilität: Ob deine Umgebung nutzbar ist

Das Projekt wurde bereits Synology DSM 7.2.1(SHR,cachedev, Python 3.8) auf echter Hardware verifiziert. Für andere Umgebungen bitte zuerst preflightausführen, es gibt punktuell Empfehlungen. Bekannte Anpassungen/zu verifizierende Fälle:

• DSM 6, OMV, Unraid, Geräte ohne Python 3, Festplatten ausbauen und an einen Linux-Rechner anschließen zur Offline-Verarbeitung — die Dokumentation enthält jeweils angepasste Anleitungen und Fehlerbehandlung;
• Nicht anwendbar auf ext4(die meisten QNAP-Volumes, ältere Synology-Volumes),ZFS benötigt eine andere Toolchain。

Sechs, echte Fälle: Was tatsächlich gerettet wurde

Der erste vom Autor veröffentlichte Fall, Wiederherstellungsergebnis wie folgt:

Kurz zusammengefasst:Große Dateien, Freigaben mit aktivierten Checksummen, alte Daten vor dem Snapshot: hohe Wiederherstellungsrate; als ganze Datei verschlüsselte kleine Dateien, Datenbanken, Inhalte, die erst nach dem Snapshot geschrieben wurden: praktisch aussichtslos.

Sieben: Was sich nicht wiederherstellen lässt, und einige Hinweise

• Kleine Dateien unter 1 MiBWurde vollständig verschlüsselt, auf dem Datenträger sind keine alten Klartextdaten mehr zu bergen;
• Datenbankdateien(wie SQLite/PostgreSQL, die häufig die gesamte Datei neu schreiben) werden oft als Ganzes neu geschrieben, alte Blöcke sind längst überschrieben;
• Daten in NoCOW-Freigaben, die erst nach dem letzten snapshot geschrieben wurden, beim Überschreiben wurde kein CoW verwendet, alte Blöcke existieren nicht;
• Das Tool selbst ist nur lesend, aberjede Wiederherstellungsoperation birgt Risiken: Bitte zuerst Beweise sichern, zuerst mit bekannten Originaldateien eine kleine Stichprobe verifizieren, dann in Batches arbeiten;
• Dies ist keine „Ein-Klick-Wiederherstellung aller Dateien“, es holt so viele im Dateisystem zufällig verbliebene alte Klartextdaten zurück wie möglich,wie viel geborgen werden kann, hängt von Schreibmenge und Zeit ab— je voller das Volume, je länger das Ereignis zurückliegt, desto mehr alte Blöcke wurden überschrieben.

Die drei Repositories können kombiniert verwendet werden:soimy/c3rb3r-rescue 和 Benjamin-zlt/c3rb3r-baremetal-rescue ist zuständig für „den Schlüssel aus dem Speicher holen, solange der Prozess noch läuft“, dieses Repository ist zuständig für „wenn der Schlüssel weg ist, auf alte Btrfs-Datenblöcke zurückgreifen“.

VIII. Einige häufige Missverständnisse

• „Löscht man die Erpresserbriefe und benennt die Dateien um, kann man sie wieder verwenden“: Der Dateiinhalt wurde durch Verschlüsselung überschrieben; eine Umbenennung ändert die Daten nicht; das Löschen .L0CK3D führt im Gegenteil dazu, dass alte Datenblöcke ihre Referenz verlieren und schneller vom Dateisystem freigegeben werden, wodurch möglicherweise auch das nicht mehr gerettet werden kann, was ursprünglich noch zu retten gewesen wäre.
• „Ich habe Snapshots aktiviert, also kann ich definitiv wiederherstellen“: Snapshots retten nur Neuerungen und Änderungen nach dem Snapshot-Zeitpunkt, aber hier hat der Verschlüsselungsprozess direkt die Dateien der „aktuellen Version“ überschrieben; Snapshots decken die bereits überschriebenen aktuellen Dateien nicht ab; dieses Schema nutzt gerade die „alten Blöcke vor dem Snapshot“, und ohne Snapshot können alte Blöcke aufgrund von CoW ebenfalls erhalten bleiben – verlassen Sie sich nicht auf Snapshots als einzige Hoffnung.
• „Bezahlen und jemanden mit der Entschlüsselung beauftragen ist einfacher“: Viele „Entschlüsselungsdienste“ unbekannter Herkunft sind Zweitbetrug: Man bekommt die Daten nicht zurück und gibt obendrein seine Privatsphäre preis; das Schema in diesem Artikel ist nur lesend, kostenlos und selbst überprüfbar – gehen Sie dem vorrangig nach.
• „Das funktioniert auch mit alten ext4-Volumes von Synology und mit QNAP“: Nicht anwendbar. ext4 hat kein Copy-on-Write; alte Blöcke werden nicht erhalten, und es ist ein völlig anderer Ansatz erforderlich.

Haftungsausschluss

Dieses Projekt wird „wie besehen“ bereitgestelltund dient nur der Wiederherstellung von Daten, über die Sie selbst verfügungsberechtigt sind. Das Tool selbst ist nur lesend, aber jede Wiederherstellungsoperation birgt Risiken: Sichern Sie zuerst die Beweise, verifizieren Sie zuerst mit bekannten Originaldateien anhand einer kleinen Stichprobe und führen Sie erst dann Batch-Operationen durch. Der Autor übernimmt keine Haftung für Datenverluste. Dieser Artikel ist lediglich eine Zusammenstellung und Erläuterung des Open-Source-Schemas und stellt keine Zusage für professionelle technische Dienstleistungen dar; bevor Sie tatsächlich Hand anlegen, lesen Sie bitte unbedingt zuerst die SKILL.md und das Verzeichnis references im Repository.