SynologyがC3RB3Rで暗号化された後の自己復旧方法：鍵なしでBtrfsの旧データブロックを復元する

結論から言うと

もしあなたの Synology NAS が C3RB3R（ファイル拡張子 .L0CK3D、残して read-me3.txt 身代金要求文）で暗号化された場合でも、すぐに諦めたり身代金を払ったりしないでください。あなたの共有が Btrfs ファイルシステム、かつ defrag / balance / 強制修復といった破壊的操作をまだ行っていない場合、大部分のファイルは鍵なしで取り戻せます。理由は直感に反します：C3RB3R はファイルを in-place で書き換え、Btrfs の copy-on-write（CoW）は書き換えられた旧内容をディスク上に残すため、元ファイルの平文はこれらの回収されていない旧データブロックの中に隠れています。

オープンソースコミュニティは、この復元フローを一連のツールにしています：crt106/c3rb3r-btrfs-recovery（MIT ライセンス、読み取り専用、あなたが処分権限を持つデータの復元にのみ使用）。本記事では、その原理、ルート選択、ステップごとの操作、実際の事例データを明確に説明します。まだ被害に遭っていない場合は、まず次を読んでください前回の「Synology NAS がランサムウェア被害：まず DSM をアップグレードし、次に不変 snapshot を有効化」——防ぐことは事後救済よりはるかに重要です。

一、2 つの自己復旧ルートを、まず正しく選ぶ

ファイルを取り戻せるかどうかは、最初のステップがツールを探すことではなく、判断することにあります暗号化プロセスがまだ存在するかどうか。この 2 つのルートでは得られる結果が大きく異なります：

ルート A：暗号化プロセスがまだ生きている（効果が最大）

もしインシデント発生から間もなく、NAS が 再起動されていない場合、暗号化プロセス（例：/usr/bin/libgld -n 308、プログラムファイルはすでにディスクから削除されている可能性がある）は依然としてメモリ内で動作している可能性が高いです。このとき最初にやるべきことは：

1. 用 kill -STOP <pid> それを凍結する、kill しないでください。ましてや再起動もしないでください。
2. 次に、他の2つのリポジトリの方法に従って、プロセスのメモリからセッションマスターキーを取り出します——これによりすべてのファイルを復号できます、得られる効果は下記の Btrfs ルートよりはるかに大きい：
   • soimy/c3rb3r-rescue：証拠保全、RAM から鍵を復元、コピーして復号
   • Benjamin-zlt/c3rb3r-baremetal-rescue：物理マシンの DSM 上で暗号化器を凍結し、プロセスメモリをエクスポートし、セッションキーを抽出し、全量復号（すでに2人目の独立した被害者での完全復号事例がある）

ルート B：暗号化プロセスがすでに終了している（本リポジトリが補うギャップ）

もし NAS すでに再起動されている、またはインシデント発生からすでに十数時間が経過している場合、メモリ内には基本的に鍵はもう見つからない（当該プロジェクトの作者が一度網羅的なメモリスキャンを行い、結果はゼロだった）。この場合は本リポジトリの Btrfs 旧データブロック復元ルート：鍵に依存せず、ファイルシステムに残された旧平文だけに頼る。

本記事ではルート B を重点的に解説する。2つのルートは組み合わせられる：まず鍵の取得を試し、取得できなければ Btrfs に進む。

二、原理：なぜ鍵がなくても平文を復元できるのか

一言で言うと：C3RB3R はファイルのいくつかの区間だけを書き換え、書き換えられた旧内容は Btrfs 上にブロック全体としてそのまま残っている。

具体的な暗号化方法：

• 小さいファイル：全体を暗号化；
• 1–5MB のファイル：先頭 1MiB のみを暗号化；
• 大きいファイル：「先頭、中間、末尾」の3区間を暗号化し、合計約 12%。

Btrfs はコピーオンライトファイルシステムである。ファイルがインプレースで書き換えられる場合、新しい内容は書き込まれ新しい位置、一方で元のデータブロック（extent）は、ファイル内の「暗号化されていない部分」からまだ参照されている限り、丸ごとディスク上に残る。これらの古い extent はブックエンドのようにファイルの両端を挟み込み、著者はこの現象を 「bookend extent」。

復元ツールが行うことは、Btrfs の extent ツリーに従って、書き換えられた各バイトを元の古い extent にマッピングし直すこと、ブロックデバイスから読み取り専用で直接読み出し、元のバイト列に再構成する。さらに優れているのは、「データチェックサム」が有効な共有上では、Btrfs 標準の CRC32C チェックサムでブロックごとに復元された内容が確かに正しいことを証明できる。

具体例を挙げると理解しやすい：100MB の家庭用動画では、C3RB3R は先頭・中間・末尾の3区間、約12MBだけを暗号化し、残り約88MBの平文はそのまま古い extent に残っている。一方、50KB の文書は 1MiB 未満のため全体が暗号化され、ディスク上に古い平文は見つからない。したがってファイルが大きいほど、チェックサムが有効なほど、書き込みが早いほど（直近のスナップショットより前であるほど）、回収できる割合は高くなる；逆に、大量の小ファイルやデータベースは最も不利な状況にある。

誤解しやすい点：「データチェックサム」を有効にしていない NoCOW 共有も、救えないわけではない。データの書き込み時刻がそのサブボリュームの最後のスナップショットより前（たとえスナップショットが後で削除されても）、上書き時には依然としてコピーオンライトが行われる——そのためスナップショット前の古いデータも同様に回収できる。

三、このツールとは何か

crt106/c3rb3r-btrfs-recovery 本質的には AI Agent スキル（SKILL.md）、Claude Code、Codex、Cursor などのスキル機構をサポートする agent で使うためのもの。実際の復元1回分の完全なフロー、読み取り専用ツール、検証方法を汎用ガイドとしてまとめている。中心となる設計原則は3つ：

• 読み取り専用：NAS 側では ioctl クエリ、ファイル読み取り、ブロックデバイス読み取りのみを行い、結果は NAS 以外のディスクに書き込み、データボリューム上には決してファイルを残さず、決して何も書き換えない；
• 検証可能：復元された各ブロックを Btrfs チェックサムと照合でき、「正確な復元」と「推測デコード」を区別する；
• ロールバック可能：ローカルで候補バイトを差し替える際に生成 *.c3rbak バックアップ、バイトレベルのロールバック。

四、詳細手順（Btrfs 復元ルート）

ステップ0：まずレッドラインを守る（このステップは復元自体より重要）

何かを動かす前に、次の事項は絶対に行わないでください：

• いかなる .L0CK3D ファイルも削除・上書きしないでください。ゴミ箱も空にしないでください。古いデータブロックは、これらの暗号文ファイルに「引き留められて」いるからこそファイルシステムに回収されずに残っている——削除すると、古い平文は即座に上書きされ、本当に失われる可能性がある；
• defrag、balance、を実行しないでくださいbtrfs check --repair、これらはデータを書き換え、古いブロックを直接破壊します；
• 身代金を支払わないでください、出所不明の「復号ツール」も実行しないでください（多くは二次詐欺です）；
• できるだけ早く NAS の電源を切るかネットワークを切断して現場を保全し、書き込みを減らしてください。

ステップ1：インストール

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

手動インストール： skills/c3rb3r-btrfs-recovery/ ディレクトリ全体を agent のスキルディレクトリ（例：Claude Code の ~/.claude/skills/）。

ステップ2：環境セルフチェック preflight

どのデバイスでもまずこのステップを実行する、OK / WARN / FAIL と対処提案を項目ごとに表示します：

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"

ここでは mkjob.py ツールとパスのリストをパッケージ化し、SSH の標準入力経由で NAS に渡して実行させ、データボリューム上にファイルを残さない。

第3〜6ステップ：世代を確定 → 単一ファイル検証 → 全量調査 → エクスポート検証

このステップは、状況をそのまま agent に渡すことを推奨します。agent は SKILL.md に従って自動実行します；スクリプトを手動で実行することもできます。流れは：

1. 攻撃世代 G_ATTACK を確定する：世代ごとに暗号化形式が少し異なるため、まず揃える；
2. 既知の元ファイルで単一ファイル検証を行う：ローカルに原本が残っている同名ファイルを1つ使って照合し、復元ロジックが正しいことを確認してから一括処理に進む；
3. 全量調査 survey：ボリューム全体をスキャンし、各ファイルのどのバイトが書き換えられたか、古い extent から復元できるかを示す；
4. ストリーミングエクスポート + 多重検証：復元したバイトを組み戻し、ローカルでマルチプロセスデコード検証、既知の元ファイルとの照合、最良候補の選択を行い、最後にレポートを出力する。

実作業時に注視すべきポイント：preflight いずれかが FAIL になった場合（たとえば ext4 ボリュームだと判明した、または NAS 上で Python 3 が見つからないなど）は、まず続行せず、それが提示する推奨に従って対処する；G_ATTACK 世代は後続のすべてのマッチングの基準であり、誤判定するとバッチ全体が一致しなくなる；単一ファイル検証では必ずローカル原本に誤りがないとあなたが確認したファイルで照合し、検証に通ってから一括処理に進み、破損の疑いがあるコピーで検証しないこと。

スクリプト分担一覧

第7ステップ：レポートを読み解く

復元レポートは結果を3つのカテゴリに分類します。混同しないでください：

• 正確に復元され、チェックサムで確認済み：最も信頼でき、Btrfs CRC32C がブロック単位で一致します；
• 推測後にデコード成功：論理的には再構築に成功していますが、チェックサムの裏付けがないため、確認待ちとして保持することを推奨します；
• 失敗：この部分は本当に失われています。

五、互換性：あなたの環境で使えるか

プロジェクトはすでに Synology DSM 7.2.1（SHR、cachedev、Python 3.8）上で実機検証済みです。その他の環境では先に実行してください preflight、各項目について提案を返します。既知の対応済み／検証待ちの状況：

• DSM 6、OMV、Unraid、Python 3 のないデバイス、ディスクを取り外して Linux マシンに接続しオフラインで処理するケース——ドキュメントにはそれぞれのカスタムガイドとエラー処理があります；
• ext4 には適用できません（多くの QNAP ボリューム、Synology の旧ボリューム）、ZFS は別のツールチェーンが必要です。

六、実例：実際に何を救い出せたか

作者が公開した最初の事例では、復元結果は次のとおりです：

一言でまとめると：大ファイル、チェックサム有効な共有、snapshot前の古いデータは復旧率が高い；ファイル全体が暗号化された小ファイル、データベース、snapshot後に書き込まれた内容はほぼ復旧不可能。

七、何が復旧できないか、およびいくつかの注意点

• 1MiB 以下の小ファイルファイル全体が暗号化され、ディスク上に回収できる旧平文が残っていない；
• データベースファイル（SQLite/PostgreSQL のようにファイル全体の書き換えが頻繁なもの）はブロック全体が書き換えられがちで、旧ブロックは早い段階で上書きされている；
• NoCOW 共有内で、最後のsnapshot後に書き込まれたデータ上書き時に CoW を経ていないため、旧ブロックは存在しない；
• ツール自体は読み取り専用だが、どの復旧操作にもリスクがある：まず証拠を保全し、既知の原本で小規模サンプルの検証を行ってから、一括操作を行うこと；
• これは「ワンクリックで全ファイルを復元する」ソリューションではなく、ファイルシステム内に偶然残った旧平文を可能な限り回収するもので、どれだけ回収できるかは書き込み量と時間に依存する——ボリュームが満杯に近いほど、インシデント発生から時間が経つほど、上書きされる旧ブロックが多くなる。

3つのリポジトリは組み合わせて使用できる：soimy/c3rb3r-rescue 和 Benjamin-zlt/c3rb3r-baremetal-rescue 「プロセスがまだ生きている間にメモリから鍵を取得する」を担当し、本リポジトリは「鍵がなくなった後に Btrfs の旧データブロックに頼る」を担当する。

八、よくある誤解

• 「ランサムノートを削除し、名前を変えれば使える」：ファイル内容はすでに暗号化されて書き換えられており、改名してもデータは変わらない；削除してしまうと .L0CK3D かえって旧データブロックが参照を失い、ファイルシステムによる回収が加速され、本来なら救えたものも救えなくなる可能性がある。
• 「snapshot を有効にしているから、必ず復元できる」：snapshot が救うのは snapshot 時点以降の追加と変更であり、今回は暗号化プロセスが「現在のバージョン」のファイルを直接書き換えるため、snapshot はすでに書き換えられた現在のファイルをカバーできない；本方案はまさに「snapshot 前の旧ブロック」を利用するもので、snapshot がない場合でも旧ブロックは CoW によって残存し得るので、snapshot だけを唯一の頼みにしてはいけない。
• 「有償で復号を依頼するほうが楽」：出所不明の「復号サービス」の多くは二次詐欺であり、データを取り戻せないうえにプライバシーも漏えいする；本文の方案は read-only、無料、自己検証可能なので、まずこれを優先する。
• 「ext4 の Synology 旧ボリュームや QNAP でも使える」：適用外。ext4 には copy-on-write がなく、旧ブロックは保持されないため、まったく異なるアプローチが必要である。

免責事項

本プロジェクトは「現状のまま」提供され、自分が処分権限を持つデータの復旧にのみ使用すること。ツール自体は read-only だが、いかなる復旧操作にもリスクがある：まず証拠を保全し、既知の原本で小規模サンプルの検証を行ってから一括操作すること。著者はデータ損失について責任を負わない。本文は当該オープンソース方案の整理と説明にすぎず、いかなる専門技術サービスの約束も構成しない；実際に作業する前には、必ずリポジトリ内の SKILL.md と references ディレクトリを読み終えること。