Как спасти Synology после шифрования C3RB3R: восстановление старых блоков данных Btrfs без ключа

Сначала вывод

Если ваш NAS Synology был C3RB3R(расширение файлов .L0CK3D, оставьте read-me3.txt записку о выкупе) зашифрован, не спешите сдаваться и не платите выкуп. Если ваши общие ресурсы находятся на файловой системе Btrfs, и вы ещё не выполняли defrag / balance / принудительное восстановление и другие разрушительные операции,значительную часть файлов можно восстановить без ключа. Причина противоречит интуиции: C3RB3R «перезаписывает» файлы на месте, а copy-on-write (CoW) в Btrfs сохраняет перезаписанное старое содержимое на диске — открытый текст исходных файлов скрыт в этих невостребованных старых блоках данных.

Открытое сообщество уже оформило этот процесс восстановления в набор инструментов:crt106/c3rb3r-btrfs-recovery(лицензия MIT, только чтение, только для восстановления данных, которыми вы вправе распоряжаться). В этой статье подробно описаны его принцип, выбор маршрута, пошаговые операции и данные реальных случаев. Если вы ещё не пострадали, сначала прочитайтепредыдущую статью «NAS Synology под атакой вымогателей: сначала обновите DSM, затем включите неизменяемые snapshot»— предотвратить гораздо важнее, чем спасать после факта.

I. Два пути спасения — сначала выбрать правильный

Можно ли вернуть файлы — первый шаг не поиск инструментов, а оценкажив ли ещё процесс шифрования. Эти два пути сильно различаются по выгоде:

Путь A: процесс шифрования ещё жив (максимальная выгода)

Если с момента инцидента прошло немного времени и NAS не перезагружался, процесс шифрования (например:/usr/bin/libgld -n 308, файлы программы могли быть удалены с диска) вполне вероятно всё ещё работает в памяти. Первое, что нужно сделать:

1. 用 kill -STOP <pid> заморозить его, не kill и тем более не перезагружать.
2. Затем по методам из двух других репозиториев извлечь из памяти процессаглавный ключ сессии— так можнорасшифровать все файлы, выгода намного больше, чем у маршрута Btrfs ниже:
   • soimy/c3rb3r-rescue: сохранение доказательств, восстановление ключей из RAM, копирование и расшифровка
   • Benjamin-zlt/c3rb3r-baremetal-rescue: на физической машине DSM заморозить шифратор, экспортировать память процесса, извлечь сессионные ключи, полная расшифровка (уже есть полный случай расшифровки у второго независимого пострадавшего)

Маршрут B: процесс шифрования уже завершился (пробел, восполняемый этим репозиторием)

Если NAS уже был перезагружен, или с момента инцидента прошло уже более десяти часов, в памяти ключи практически не найти (автор проекта провёл однократное исчерпывающее сканирование памяти, результат — ноль). В этом случае используется маршрут восстановления старых блоков данных Btrfsиз этого репозитория: без зависимости от ключей, только за счёт старых открытых текстов, оставленных файловой системой.

Данная статья посвящена маршруту B. Два маршрута можно комбинировать: сначала попытаться получить ключи, если не удалось — перейти к Btrfs.

II. Принцип: почему открытый текст можно восстановить и без ключей

Одной фразой:C3RB3R перезаписал лишь несколько фрагментов файла, а перезаписанное старое содержимое целиком сохранилось на Btrfs.

Как именно происходит шифрование:

• Мелкие файлы: шифруются целиком;
• Файлы 1–5MB: шифруются только первые 1MiB;
• Крупные файлы: шифруются три сегмента — «начало, середина, конец», в сумме около 12%.

Btrfs — это файловая система с копированием при записи. Когда файл перезаписывается на месте, новое содержимое записывается вновое место, аисходные блоки данных (extent) сохраняются на диске целиком, пока на них ещё ссылается «незашифрованная часть» файла. Эти старые extent, словно закладки, зажаты с двух концов файла; автор называет это явление «bookend extent»。

Инструмент восстановления делает следующее: по дереву extent в Btrfs он сопоставляет каждый перезаписанный байтего исходному старому extent, читает напрямую с блочного устройства только для чтения и собирает обратно исходные байты. Что ещё лучше, на общем ресурсе с включённой «проверкой контрольных сумм данных» можно с помощью встроенной в Btrfs контрольной суммы CRC32C поблочно доказать,что восстановленное содержимое действительно верно.

Лучше понять поможет конкретный пример: у домашнего видео размером 100MB C3RB3R зашифровал только три сегмента — начало, середину и конец — примерно 12MB, а остальные почти 88MB открытого текста остались нетронутыми в старом extent; а документ размером 50KB, поскольку он меньше 1MiB, был зашифрован целиком, и старого открытого текста на диске уже не найти. Поэтомучем больше файл, чем чаще включена контрольная сумма и чем раньше была запись (раньше последнего snapshot), тем выше доля восстановимого; и наоборот, масса мелких файлов и базы данных находятся в наихудшем положении.

Один легко неправильно понимаемый момент:NoCOW-ресурс без отмеченной «контрольной суммы данных» тоже не означает, что спасти ничего нельзя. Если данные были записаны раньше, чемпоследний snapshotэтого subvolume (даже если snapshot потом удалили), при перезаписи всё равно сработает copy-on-write — поэтому старые данные, существовавшие до snapshot, всё равно можно восстановить.

III. Что это за инструмент

crt106/c3rb3r-btrfs-recovery По сути это навык AI Agent (SKILL.md), предназначенный для агентов вроде Claude Code, Codex, Cursor, поддерживающих механизм навыков. Он обобщает полный процесс одного реального восстановления, инструменты только для чтения и методы проверки в универсальное руководство. Есть три ключевых принципа дизайна:

• Только чтение: на стороне NAS выполняются только ioctl-запросы, чтение файлов и чтение блочных устройств, результаты записываются на диск вне NAS, и ни в коем случае не создаются файлы на томе данных и ничего не перезаписывается;
• Проверяемость: каждый восстановленный блок можно сверить с контрольной суммой Btrfs, различая «точное восстановление» и «предположительное декодирование»;
• Возможность отката: при локальной замене байтов-кандидатов создаётся *.c3rbak резервная копия, откат на уровне байтов.

IV. Подробные шаги (маршрут восстановления 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, он автоматически выполнит её по SKILL.md; можно также запустить скрипт вручную. Процесс таков:

1. Определить поколение атаки G_ATTACK: форматы шифрования разных поколений немного различаются, сначала выровнять;
2. Проверить на одном файле с известным оригиналом: возьмите файл с тем же именем, оригинал которого у вас ещё есть локально, и сверьте его, убедитесь, что логика восстановления верна, и только потом переходите к пакетной обработке;
3. Полный обзор survey: просканировать весь том, отметить, какие байты в каждом файле были перезаписаны и можно ли их восстановить из старых extent;
4. Потоковый экспорт + многократная проверка: собрать восстановленные байты обратно, выполнить локальную многопроцессную проверку декодирования, сверить с известными оригиналами, выбрать лучшего кандидата и в конце выдать отчёт.

Несколько моментов, за которыми нужно внимательно следить при практической работе:preflight Если на любом этапе появляется FAIL (например, обнаружен том ext4 или на NAS не найден Python 3), сначала не продолжайте, действуйте согласно предложенным рекомендациям;G_ATTACK Поколение — это база для всех последующих сопоставлений, ошибка в определении приведёт к тому, что весь пакет не сойдётся; проверку на одном файле обязательно нужно выполнять сфайлом, для которого вы подтвердили, что локальный оригинал не повреждён, и только после успешной проверки переходите к пакетной обработке, не используйте для проверки подозрительно повреждённые копии.

Обзор разделения задач по скриптам

Шаг 7: разбор отчёта

Отчёт о восстановлении делит результаты на три категории, не путайте их:

• Точное восстановление, подтверждённое контрольной суммой: наиболее надёжно, Btrfs CRC32C совпадает поблочно;
• Предположительное восстановление, декодирование прошло успешно: логически собрано успешно, но без подтверждения контрольной суммой, рекомендуется сохранить для проверки;
• Неудача: эта часть действительно утеряна.

V. Совместимость: применимо ли в вашей среде

Проект уже Synology DSM 7.2.1(SHR,cachedev, Python 3.8) проверен на реальном устройстве. Для других сред сначала запустите preflight, он выдаст рекомендации по каждому пункту. Известные случаи совместимости/ожидающие проверки:

• DSM 6, OMV, Unraid, устройства без Python 3, извлечение дисков и подключение к Linux-компьютеру для офлайн-обработки — в документации есть отдельные инструкции и обработка ошибок;
• не применимо к ext4(большинство томов QNAP, старые тома Synology),ZFS требует другого набора инструментов。

VI. Реальные случаи: что именно удалось восстановить

Первый опубликованный автором случай, результаты восстановления следующие:

итог в одном предложении:крупные файлы, разделяемые ресурсы с включёнными контрольными суммами, старые данные до snapshot — высокий процент восстановления; небольшие файлы, зашифрованные целиком, базы данных, содержимое, записанное только после snapshot, — практически без шансов.

семь, что не удаётся восстановить, и несколько напоминаний

• небольшие файлы менее 1MiBПолностью зашифровано, на диске нет старых открытых данных, которые можно восстановить;
• файлы базы данных(такие как SQLite/PostgreSQL с частой перезаписью целых файлов) обычно перезаписываются целыми блоками, старые блоки давно перезаписаны;
• данные, записанные в NoCOW-ресурсе после последнего snapshot, при перезаписи не использовался CoW, старые блоки отсутствуют;
• сам инструмент работает только на чтение, нолюбая операция восстановления несёт риски: сначала сохраните доказательства, сначала проверьте на небольшой выборке с известными оригиналами, затем выполняйте массовые операции;
• это не решение «восстановить все файлы одной кнопкой», оно максимально извлекает старые открытые данные, случайно сохранившиеся в файловой системе,сколько удастся извлечь, зависит от объёма записей и времени— чем полнее том и чем больше времени прошло, тем больше старых блоков перезаписано.

Три репозитория можно использовать в комбинации:soimy/c3rb3r-rescue 和 Benjamin-zlt/c3rb3r-baremetal-rescue отвечает за «извлечение ключа из памяти, пока процесс ещё жив», данный репозиторий отвечает за «извлечение ключа, когда он утерян, с опорой на старые блоки данных Btrfs».

VIII. Несколько распространённых заблуждений

• «Удалить записку о выкупе и переименовать файл — и всё заработает»: содержимое файла уже зашифровано и перезаписано, переименование не меняет данные; удаление .L0CK3D наоборот лишает старые блоки данных ссылок и ускоряет их переработку файловой системой, из-за чего можно потерять даже то, что ещё можно было спасти.
• «У меня включены snapshot, значит точно восстановлю»: snapshot спасают только новые и изменённые данные после момента создания snapshot, а здесь процесс шифрования напрямую перезаписывает «текущую версию» файлов, и snapshot не покрывают уже перезаписанные текущие файлы; данное решение как раз использует «старые блоки до snapshot», а без snapshot старые блоки тоже могут сохраниться благодаря CoW — не стоит полагаться только на snapshot.
• «Заплатить специалистам за расшифровку — проще»: множество «услуг расшифровки» из неизвестных источников — это повторное мошенничество: и данные не вернёшь, и приватность утечёшь; решение из этой статьи работает только на чтение, бесплатно и поддаётся самопроверке — начинайте с него.
• «Старые тома Synology на ext4, а также QNAP тоже подойдут»: не подходит. В ext4 нет copy-on-write, старые блоки не сохраняются, нужен совершенно иной подход.

Отказ от ответственности

Данный проект предоставляется «как есть»,только для восстановления данных, которыми вы вправе распоряжаться. Сам инструмент работает только на чтение, но любая операция восстановления сопряжена с риском: сначала сохраните доказательства, проверьте на небольшом образце с известными оригиналами, затем выполняйте массовые операции. Автор не несёт ответственности за потерю данных. Эта статья — лишь整理 и описание данного open-source решения и не является обещанием каких-либо профессиональных технических услуг; прежде чем действовать, обязательно прочитайте SKILL.md и каталог references в репозитории.