Comment se sauver après que le Synology a été chiffré par C3RB3R : récupérer les anciens blocs de données Btrfs sans clé

Commençons par la conclusion

Si votre NAS Synology a été C3RB3R(extension de fichier .L0CK3D, laissant read-me3.txt une note de rançon) chiffré, ne vous résignez pas trop vite et ne payez pas la rançon. Tant que vos partages sont en système de fichiers Btrfset que vous n'avez pas effectué d'opérations destructrices comme defrag / balance / réparation forcée,une grande partie des fichiers peut être récupérée sans clé. La raison est contre-intuitive : C3RB3R réécrit les fichiers « sur place », et le copy-on-write (CoW) de Btrfs conserve les anciennes données réécrites sur le disque ; le texte en clair des fichiers originaux se cache dans ces anciens blocs de données non récupérés.

La communauté open source a déjà transformé ce processus de récupération en une boîte à outils :crt106/c3rb3r-btrfs-recovery(licence MIT, lecture seule, uniquement pour récupérer des données que vous avez le droit de traiter). Cet article explique clairement son principe, le choix de la méthode, les opérations étape par étape et des données de cas réels. Si vous n'avez pas encore été touché, lisez d'abordl'article précédent « NAS Synology rançonné : mettez d'abord à niveau DSM, puis activez les snapshots immuables »— prévenir est bien plus important que de récupérer après coup.

I. Deux voies de sauvetage, choisissez d'abord la bonne

Pour récupérer les fichiers, la première étape n'est pas de chercher un outil, mais de déterminersi le processus de chiffrement est toujours actif. Les gains de ces deux voies diffèrent beaucoup :

Voie A : le processus de chiffrement est toujours en vie (gain maximal)

Si l'incident est récent et que le NAS n'a pas été redémarré, le processus de chiffrement (ex. :/usr/bin/libgld -n 308, le fichier du programme peut avoir été supprimé du disque) est très probablement encore en cours d'exécution en mémoire. La première chose à faire est alors :

1. 用 kill -STOP <pid> le geler, ne pas le kill, et encore moins redémarrer.
2. Ensuite, suivez la méthode des deux autres dépôts pour extraire de la mémoire du processus laclé maîtresse de session— cela permet dedéchiffrer tous les fichiers, le gain est bien supérieur à la voie Btrfs ci-dessous :
   • soimy/c3rb3r-rescue: préservation des preuves, récupération de la clé depuis la RAM, copie et déchiffrement
   • Benjamin-zlt/c3rb3r-baremetal-rescue: sur un DSM en machine physique, geler le chiffreur, exporter la mémoire du processus, extraire la clé de session, déchiffrement complet (un cas complet de déchiffrement pour une deuxième victime indépendante existe déjà)

Voie B : le processus de chiffrement s'est déjà terminé (la lacune comblée par ce dépôt)

Si le NAS a déjà été redémarré, ou si l'incident remonte à plus de dix heures, la clé est pratiquement introuvable en mémoire (l'auteur du projet a effectué un scan mémoire exhaustif, résultat nul). On emprunte alors la voie récupération des anciens blocs de données Btrfsde ce dépôt : sans dépendre de la clé, en s'appuyant uniquement sur les anciennes données en clair laissées par le système de fichiers.

Cet article se concentre sur la voie B. Les deux voies peuvent être combinées : tenter d'abord d'obtenir la clé, et si cela échoue, passer à Btrfs.

II. Principe : pourquoi on peut retrouver le clair sans clé

En une phrase :C3RB3R n'a réécrit que quelques segments du fichier, et le contenu ancien écrasé est resté intact par blocs entiers sur Btrfs.

Comment le chiffrement est effectué concrètement :

• Petits fichiers : chiffrement intégral ;
• Fichiers de 1–5MB : seuls les premiers 1MiB sont chiffrés ;
• Gros fichiers : chiffrement de trois segments « tête, milieu, queue », soit environ 12 % au total.

Btrfs est un système de fichiers copy-on-write. Lorsqu'un fichier est réécrit sur place, le nouveau contenu est écrit àun nouvel emplacement, tandis queles blocs de données d'origine (extent) sont conservés intégralement sur le disque tant qu'ils sont encore référencés par la « partie non chiffrée du fichier ». Ces anciens extents encadrent le fichier comme des serre-livres, et l'auteur appelle ce phénomène « bookend extent »。

Ce que fait l'outil de récupération : en suivant l'arbre des extents de Btrfs, il mappe chaque octet réécritvers son ancien extent d'origine, le lit directement en lecture seule depuis le périphérique de blocs, et reconstitue les octets d'origine. Plus fort encore, sur un partage où la « somme de contrôle des données » est activée, on peut utiliser la somme de contrôle CRC32C intégrée à Btrfs pour prouver bloc par blocque le contenu récupéré est effectivement correct.

Un exemple concret facilite la compréhension : pour une vidéo familiale de 100MB, C3RB3R ne chiffre que les trois segments de tête, milieu et queue, soit environ 12MB, et près de 88MB de texte en clair restent intacts dans l'ancien extent ; en revanche, un document de 50KB, étant inférieur à 1MiB, est chiffré dans son intégralité, et l'ancien texte en clair est introuvable sur le disque. Doncplus le fichier est volumineux, plus la vérification des sommes de contrôle est activée, plus l'écriture est ancienne (antérieure au dernier snapshot), plus la proportion récupérable est élevée; à l'inverse, les masses de petits fichiers et les bases de données sont dans la situation la plus défavorable.

Un point facile à mal interpréter :un partage NoCOW sans « somme de contrôle des données » cochée ne signifie pas non plus qu'il est irrécupérable. Tant que les données ont été écrites avant ledernier snapshotde ce sous-volume (même si le snapshot a été supprimé par la suite), l'écrasement passe toujours par le copy-on-write — les anciennes données antérieures au snapshot restent donc récupérables.

III. Ce qu'est cet outil

crt106/c3rb3r-btrfs-recovery est essentiellement une compétence d'AI Agent (SKILL.md), destinée aux agents supportant le mécanisme de compétences tels que Claude Code, Codex, Cursor. Il organise le processus complet d'une restauration réelle, les outils en lecture seule et les méthodes de vérification en un guide générique. Trois principes de conception fondamentaux :

• lecture seule: côté NAS, uniquement des requêtes ioctl, de la lecture de fichiers et de la lecture de périphériques blocs, les résultats étant écrits sur un disque extérieur au NAS, sans jamais déposer de fichiers sur le volume de données ni modifier quoi que ce soit ;
• Vérifiable: chaque bloc récupéré peut être comparé aux sommes de contrôle Btrfs, ce qui permet de distinguer la « récupération exacte » du « décodage spéculatif » ;
• Réversible: lors du remplacement local d'octets candidats, génération de *.c3rbak sauvegardes, avec rollback au niveau des octets.

IV. Étapes détaillées (voie de récupération Btrfs)

Étape 0 : établir d'abord les lignes rouges (cette étape est plus importante que la récupération elle-même)

Avant de toucher quoi que ce soit, ces quelques chosesne doivent absolument pas être faites：

• Ne supprimez ni n'écrasez aucun .L0CK3D fichier, et ne videz pas la corbeille.Les anciens blocs de données ne sont préservés de la récupération par le système de fichiers que parce que ces fichiers chiffrés les « retiennent » — si vous supprimez, l'ancien texte en clair peut être immédiatement écrasé, et il sera vraiment perdu ;
• Ne faites pas de defrag, balance,btrfs check --repair, ces opérations réécrivent les données et détruisent directement les anciens blocs ;
• Ne payez pas la rançon, et n'exécutez pas non plus de « déchiffreur » d'origine inconnue (beaucoup sont des secondes arnaques) ;
• coupez rapidement l'alimentation ou le réseau du NAS pour préserver la scène et réduire les écritures.

Étape 1 : installation

avec le CLI skills :

# 安装到当前项目
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

installation manuelle : copiez skills/c3rb3r-btrfs-recovery/ tout le répertoire dans le répertoire de compétences de l'agent (par exemple celui de Claude Code ~/.claude/skills/）。

Étape 2 : auto-vérification de l'environnement preflight

sur n'importe quel appareilexécutez d'abord cette étape, il donnera item par item OK / WARN / FAIL et des suggestions de traitement :

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"

ici mkjob.py se charge d'empaqueter la liste des outils et des chemins, de la transmettre via l'entrée standard SSH au NAS pour exécution,sans déposer de fichiers sur le volume de données。

Étapes 3~6 : déterminer la génération → vérification sur fichier unique → recensement complet → vérification de l'export

Pour cette étape, il est recommandé de confier directement la situation à l'agent, qui l'exécutera automatiquement selon SKILL.md ; vous pouvez aussi lancer le script manuellement. Le processus est :

1. Déterminer la génération d'attaque G_ATTACK: les formats de chiffrement diffèrent légèrement selon les générations, aligner d'abord ;
2. Valider sur un seul fichier avec un original connu: prendre un fichier de même nom dont vous conservez encore la version originale en local pour comparer, confirmer que la logique de récupération est correcte, puis passer au traitement par lots ;
3. Recensement complet survey: scanner tout le volume, identifier pour chaque fichier quels octets ont été réécrits et si une récupération depuis les anciens extents est possible ;
4. Export en flux + validation multiple: réassembler les octets récupérés, valider par décodage multiprocessus en local, comparer avec les originaux connus, sélectionner les meilleurs candidats, puis produire le rapport.

Points à surveiller impérativement lors de la mise en pratique :preflight Si un élément renvoie FAIL (par exemple un volume ext4 détecté, ou Python 3 introuvable sur le NAS), ne pas continuer et suivre la recommandation fournie ;G_ATTACK La génération est la référence pour toutes les correspondances ultérieures, une erreur de jugement fera échouer tout le lot ; la validation sur un seul fichier doit impérativement utiliserun fichier dont vous confirmez que la version originale locale est intactepour comparer, ne passer au traitement par lots qu'après validation réussie, ne pas vérifier avec une copie suspectée d'être corrompue.

Aperçu de la répartition des scripts

Étape 7 : comprendre le rapport

Le rapport de récupération classe les résultats en trois catégories, à ne pas confondre :

• Récupération exacte confirmée par somme de contrôle: la plus fiable, le CRC32C Btrfs correspond bloc par bloc ;
• Décodage réussi après déduction: reconstruction logique réussie, mais sans corroboration par somme de contrôle, à conserver pour vérification ;
• Échec: cette partie est réellement perdue.

V. Compatibilité : votre environnement peut-il l'utiliser

Le projet a été Synology DSM 7.2.1(SHR,cachedev, Python 3.8) validé sur machine réelle. Pour les autres environnements, exécutez d'abord preflight, il donnera des recommandations point par point. Cas connus adaptés/à valider :

• DSM 6, OMV, Unraid, les appareils sans Python 3, le démontage des disques pour un traitement hors ligne sur un ordinateur Linux — la documentation contient les guides de démarrage personnalisés et la gestion des erreurs correspondants ;
• non applicable à ext4(la plupart des volumes QNAP, les anciens volumes Synology),ZFS nécessite une autre chaîne d'outils。

VI. Cas réel : qu'a-t-on réellement récupéré

Le premier cas publié par l'auteur, les résultats de récupération sont les suivants :

résumé en une phrase :gros fichiers, partages avec checksums activés, anciennes données antérieures au snapshot : taux de récupération élevé ; petits fichiers chiffrés en bloc, bases de données, contenus écrits seulement après le snapshot : quasiment aucune chance.

VII. Ce qui n'est pas récupérable, et quelques rappels

• petits fichiers de moins de 1 MiBChiffré dans son ensemble, aucune ancienne donnée en clair récupérable sur le disque ;
• Fichiers de base de données(comme SQLite/PostgreSQL, qui réécrivent fréquemment le fichier entier) sont souvent réécrits en bloc, les anciens blocs étant depuis longtemps écrasés ;
• Données écrites dans un partage NoCOW, après le dernier snapshot, lors de l'écrasement le CoW n'a pas été utilisé, les anciens blocs n'existent plus ;
• L'outil lui-même est en lecture seule, maistoute opération de récupération comporte des risques: veuillez d'abord préserver les preuves, valider d'abord sur un petit échantillon avec des originaux connus, puis procéder par lots ;
• Ce n'est pas une solution de « restauration en un clic de tous les fichiers », c'est une tentative de récupérer autant que possible les anciennes données en clair laissées par chance dans le système de fichiers,la quantité récupérable dépend du volume d'écriture et du temps— plus le volume est plein et plus l'incident est ancien, plus les anciens blocs écrasés sont nombreux.

Les trois dépôts peuvent être combinés :soimy/c3rb3r-rescue 和 Benjamin-zlt/c3rb3r-baremetal-rescue est responsable de « récupérer la clé depuis la mémoire lorsque le processus est encore actif », ce dépôt est responsable de « récupérer via les anciens blocs de données Btrfs lorsque la clé a disparu ».

VIII. Quelques idées fausses courantes

• « Il suffit de supprimer la lettre de rançon et de renommer le fichier pour pouvoir l'utiliser »: le contenu du fichier a déjà été chiffré et réécrit, le renommage ne change pas les données ; supprimer .L0CK3D fait au contraire perdre aux anciens blocs de données leur référence et accélère leur récupération par le système de fichiers, ce qui peut rendre irrécupérable ce qui aurait pu l'être.
• « J'ai activé les snapshot, je pourrai forcément restaurer »: les snapshot ne sauvent que les ajouts et modifications postérieurs au point de snapshot, or ici le processus de chiffrement réécrit directement les fichiers de la « version actuelle », et les snapshot ne couvrent pas les fichiers actuels déjà réécrits ; la présente solution exploite précisément les « anciens blocs d'avant le snapshot », et sans snapshot les anciens blocs peuvent aussi subsister grâce au CoW, ne faites pas du snapshot votre seul espoir.
• « Payer quelqu'un pour déchiffrer est plus simple »: beaucoup de « services de déchiffrement » d'origine inconnue sont des arnaques secondaires, qui ne récupèrent pas les données et exposent en plus votre vie privée ; la solution de cet article est en lecture seule, gratuite et auto-vérifiable, privilégiez-la.
• « Ça marche aussi sur les anciens volumes ext4 de Synology et sur QNAP »: non applicable. ext4 n'a pas de copy-on-write, les anciens blocs ne sont pas conservés, il faut une approche totalement différente.

Avertissement

Ce projet est fourni « en l'état »,uniquement pour récupérer des données que vous avez le droit de traiter. L'outil lui-même est en lecture seule, mais toute opération de récupération comporte des risques : préservez d'abord les preuves, validez d'abord sur un petit échantillon avec des originaux connus, puis procédez en masse. L'auteur décline toute responsabilité en cas de perte de données. Cet article n'est qu'une compilation et une explication de ce projet open source et ne constitue aucun engagement de service technique professionnel ; avant de passer à l'action, veuillez impérativement lire d'abord le SKILL.md et le répertoire references du dépôt.