Como se recuperar após o Synology ser criptografado pelo C3RB3R: recuperar blocos de dados antigos do Btrfs sem chave

Primeiro, a conclusão

Se o seu NAS Synology foi C3RB3R(extensão de ficheiro .L0CK3D, deixar read-me3.txt nota de resgate) encriptado, não desista já nem pague o resgate. Desde que a sua partilha seja sistema de ficheiros Btrfse ainda não tenha feito operações destrutivas como defrag / balance / reparação forçada,uma grande parte dos ficheiros pode ser recuperada sem chave. A razão é contra-intuitiva: o C3RB3R reescreve os ficheiros «no local», e o copy-on-write (CoW) do Btrfs mantém o conteúdo antigo reescrito no disco, pelo que o texto simples do ficheiro original está escondido nesses blocos de dados antigos não recuperados.

A comunidade open source já transformou este processo de recuperação num conjunto de ferramentas:crt106/c3rb3r-btrfs-recovery(licença MIT, apenas leitura, apenas para recuperar dados que tem o direito de tratar). Este artigo explica claramente o seu princípio, a escolha de rota, os passos de operação e dados de casos reais. Se ainda não foi afetado, leia primeiroo artigo anterior «NAS Synology ransomware: primeiro atualizar o DSM, depois ativar snapshots imutáveis»— prevenir é muito mais importante do que recuperar depois.

1. Duas rotas de autorresgate: escolha a certa primeiro

Se dá para recuperar os arquivos, o primeiro passo não é procurar ferramentas, mas determinarse o processo de criptografia ainda está ativo. As duas rotas têm ganhos muito diferentes:

Rota A: o processo de criptografia ainda está vivo (maior ganho)

Se o incidente foi recente e o NAS não foi reiniciado, o processo de criptografia (ex.:/usr/bin/libgld -n 308, os arquivos do programa podem já ter sido apagados do disco) provavelmente ainda está rodando na memória. A primeira coisa a fazer é:

1. 用 kill -STOP <pid> congelá-lo, não usar kill, e muito menos reiniciar.
2. Depois, siga o método dos outros dois repositórios para extrair da memória do processo achave mestra de sessão— assim é possíveldescriptografar todos os arquivos, o retorno é muito maior do que a rota Btrfs abaixo:
   • soimy/c3rb3r-rescue: preservação de evidências, recuperação de chaves da RAM, cópia e descriptografia
   • Benjamin-zlt/c3rb3r-baremetal-rescue: congelar o encryptor no DSM em bare-metal, exportar a memória do processo, extrair a chave de sessão, descriptografia completa (já há um caso completo de descriptografia de uma segunda vítima independente)

Rota B: o processo de criptografia já foi encerrado (a lacuna que este repositório preenche)

Se o NAS já foi reiniciado, ou se já se passaram mais de dez horas desde o incidente, basicamente não há mais chaves na memória (o autor do projeto fez uma varredura exaustiva da memória uma vez, e o resultado foi zero). Nesse caso, siga a rota de recuperação de blocos de dados antigos do Btrfsdeste repositório: sem depender de chaves, apenas contando com o texto claro antigo deixado pelo sistema de arquivos.

Este artigo foca na rota B. As duas rotas podem ser combinadas: primeiro tente obter a chave; se não conseguir, siga para o Btrfs.

II. Princípio: por que é possível recuperar o texto claro mesmo sem chave

Em uma frase:O C3RB3R só reescreveu alguns trechos dos arquivos, e o conteúdo antigo sobrescrito permaneceu intacto em blocos inteiros no Btrfs.

Como a criptografia é feita especificamente:

• Arquivos pequenos: criptografia integral;
• Arquivos de 1–5MB: apenas os primeiros 1MiB são criptografados;
• Arquivos grandes: criptografa três segmentos «início, meio e fim», totalizando cerca de 12%.

Btrfs é um sistema de arquivos copy-on-write. Quando um arquivo é sobrescrito no local, o novo conteúdo é escrito emuma nova posição, eos blocos de dados originais (extent), desde que ainda sejam referenciados pela «parte não criptografada do arquivo», são mantidos inteiros no disco. Esses extents antigos ficam como marcadores de livro nas duas extremidades do arquivo, e o autor chama esse fenômeno de «bookend extent»。

O que a ferramenta de recuperação faz é: percorrer a árvore de extents do Btrfs e mapear cada byte sobrescritode volta ao seu extent antigo original, lendo diretamente do dispositivo de bloco em modo somente leitura e remontando os bytes originais. Melhor ainda: em compartilhamentos com «checksum de dados» habilitado, é possível usar o checksum CRC32C nativo do Btrfs para provar bloco a blocoque o conteúdo recuperado está realmente correto.

Um exemplo concreto ajuda a entender melhor: um vídeo caseiro de 100MB, o C3RB3R criptografou apenas os três segmentos de cabeçalho, meio e cauda, cerca de 12MB, e os quase 88MB restantes de texto claro ficam intactos no extent antigo; já um documento de 50KB, por ser menor que 1MiB e ter sido criptografado integralmente, não deixa texto claro antigo no disco. Portantoquanto maior o arquivo, mais com checksum ativado e mais cedo a gravação (anterior ao snapshot mais recente), maior a proporção recuperável; inversamente, grande quantidade de arquivos pequenos e bancos de dados estão na pior situação.

Um ponto facilmente mal interpretado:um compartilhamento NoCOW sem「data checksum」marcado também não significa que não há salvação. Desde que os dados tenham sido gravados antes doúltimo snapshotdesse subvolume (mesmo que o snapshot tenha sido excluído depois), a sobrescrita ainda passa por copy-on-write — portanto os dados antigos anteriores ao snapshot ainda podem ser recuperados.

III. O que é esta ferramenta

crt106/c3rb3r-btrfs-recovery é essencialmente uma habilidade de AI Agent (SKILL.md), para uso por agents como Claude Code, Codex, Cursor que suportam mecanismo de habilidades. Ela organiza o fluxo completo de uma recuperação real, ferramentas somente leitura e métodos de verificação em um guia genérico. Há três princípios de design centrais:

• somente leitura: no lado do NAS apenas se fazem consultas ioctl, leitura de arquivos e leitura de block devices, com resultados gravados em disco fora do NAS, jamais gravando arquivos no volume de dados e jamais reescrevendo qualquer coisa;
• Verificável: cada bloco recuperado pode ser comparado com o checksum do Btrfs, distinguindo «recuperação exata» de «descodificação especulativa»;
• Reversível: ao substituir localmente bytes candidatos, é gerado *.c3rbak backup, rollback ao nível do byte.

IV. Passos detalhados (rota de recuperação Btrfs)

Passo 0: primeiro salvaguardar a linha vermelha (este passo é mais importante do que a própria recuperação)

Antes de mexer em qualquer coisa, estas coisasabsolutamente não fazer：

• Não apagar nem sobrescrever qualquer .L0CK3D ficheiro, nem esvaziar a reciclagem.Os blocos de dados antigos são precisamente «segurados» por estes ficheiros cifrados para não serem recuperados pelo sistema de ficheiros — se apagar, o texto simples antigo pode ser imediatamente sobrescrito e desaparecer de vez;
• Não fazer defrag, balance,btrfs check --repair, estes reescrevem os dados e destroem diretamente os blocos antigos;
• Não pagar resgate, e também não execute “decrypters” de origem desconhecida (muitos são golpes secundários);
• o quanto antes, desligue o NAS da energia ou da rede para preservar a cena e evitar gravações;

Passo 1: instalação

com o 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

instalação manual: coloque skills/c3rb3r-btrfs-recovery/ o diretório inteiro no diretório de skills do agent (como o do Claude Code ~/.claude/skills/）。

Passo 2: autoverificação de ambiente preflight

em qualquer dispositivoexecute primeiro esta etapa, ele fornecerá item por item OK / WARN / FAIL e sugestões de tratamento:

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"

aqui mkjob.py é responsável por empacotar a lista de ferramentas e caminhos e entregá-la ao NAS via entrada padrão do SSH,não grava arquivos nos dados。

Passos 3~6: determinar a geração → validação de arquivo único → varredura completa → validação de exportação

nesta etapa, recomenda-se passar a situação diretamente ao agent, que executará automaticamente conforme o SKILL.md; também é possível executar o script manualmente. O fluxo é:

1. Determinar a geração de ataque G_ATTACK: formatos de criptografia de diferentes gerações têm pequenas diferenças, alinhar primeiro;
2. Validar com um único arquivo usando um original conhecido: pegue um arquivo de mesmo nome cuja versão original você ainda tem localmente para comparar, confirme que a lógica de recuperação está correta e só então faça em lote;
3. Levantamento completo survey: escanear o volume inteiro, marcar quais bytes de cada arquivo foram sobrescritos e se é possível recuperá-los a partir de extents antigos;
4. Exportação em streaming + verificação múltipla: remontar os bytes recuperados, validar localmente com decodificação multiprocesso, comparar com os originais conhecidos, selecionar os melhores candidatos e, por fim, gerar o relatório.

Alguns pontos a ficar atento na operação prática:preflight Se qualquer item apresentar FAIL (por exemplo, detectar que é um volume ext4, ou não encontrar Python 3 no NAS), não continue; siga a sugestão fornecida;G_ATTACK A geração é a base para todas as correspondências seguintes; um erro de julgamento fará com que todo o lote não corresponda; a validação de arquivo único deve usarum arquivo que você confirmou ser a versão original local corretapara comparar; após a validação passar, só então libere o processamento em lote, não use cópias suspeitas de corrupção para validação.

Visão geral da divisão de tarefas dos scripts

Passo 7: entender o relatório

O relatório de recuperação classifica os resultados em três categorias, não as confunda:

• Recuperação exata e confirmada por checksum: a mais confiável, Btrfs CRC32C corresponde bloco a bloco;
• Decodificação bem-sucedida após inferência: remontagem lógica bem-sucedida, mas sem confirmação de checksum, recomenda-se manter para verificação;
• Falha: esta parte realmente se perdeu.

V. Compatibilidade: o seu ambiente pode ser usado

O projeto já foi Synology DSM 7.2.1(SHR,cachedev, Python 3.8) validado em máquina real. Para outros ambientes, execute primeiro preflight, ele dará sugestões item por item. Situações conhecidas de adaptação/a validar:

• DSM 6, OMV, Unraid, dispositivos sem Python 3, remover os discos e conectá-los a um computador Linux para processamento offline — a documentação contém orientações personalizadas e tratamento de erros para cada caso;
• não se aplica a ext4(a maioria dos volumes QNAP, volumes antigos Synology),ZFS requer outro conjunto de ferramentas。

VI. Caso real: o que foi realmente recuperado

O primeiro caso divulgado pelo autor, o resultado da recuperação é o seguinte:

resumo em uma frase:arquivos grandes, compartilhamentos com checksum ativado, dados antigos anteriores ao snapshot, alta taxa de recuperação; pequenos arquivos criptografados como arquivo inteiro, bancos de dados, conteúdo gravado somente após o snapshot, basicamente sem chance.

Sete, o que não é recuperável, e alguns alertas

• pequenos arquivos abaixo de 1MiBfoi totalmente criptografado, não há texto simples antigo no disco para recuperar;
• arquivos de banco de dados(como SQLite/PostgreSQL, que reescrevem frequentemente o arquivo inteiro) costumam ser reescritos em blocos inteiros, e os blocos antigos já foram sobrescritos;
• dados gravados em compartilhamentos NoCOW após o último snapshot, na sobrescrita não passaram por CoW, os blocos antigos não existem;
• a ferramenta em si é somente leitura, masqualquer operação de recuperação tem riscos: preserve primeiro as evidências, valide primeiro com pequenas amostras usando originais conhecidos, e só depois opere em lote;
• esta não é uma solução de "restaurar todos os arquivos com um clique", ela recupera ao máximo o texto simples antigo que restou por sorte no sistema de arquivos,quanto é possível recuperar depende do volume de gravação e do tempo— quanto mais cheio o volume e mais tempo desde o incidente, mais blocos antigos foram sobrescritos.

Os três repositórios podem ser usados em combinação:soimy/c3rb3r-rescue 和 Benjamin-zlt/c3rb3r-baremetal-rescue é responsável por "obter a chave da memória enquanto o processo ainda está ativo", este repositório é responsável por "quando a chave se foi, contar com os blocos de dados antigos do Btrfs".

VIII. Alguns equívocos comuns

• "Apagar a nota de resgate e mudar o nome já resolve": o conteúdo do arquivo já foi criptografado e reescrito, mudar o nome não altera os dados; apagar .L0CK3D pelo contrário, faz com que os blocos de dados antigos percam a referência e sejam coletados mais rapidamente pelo sistema de arquivos, podendo tornar irrecuperável o que antes seria possível recuperar.
• "Eu ativei o snapshot, com certeza consigo restaurar": o snapshot salva apenas as adições e alterações feitas após o momento do snapshot, mas neste caso o processo de criptografia reescreveu diretamente os arquivos da "versão atual", e o snapshot não cobre os arquivos atuais já reescritos; esta solução justamente utiliza os "blocos antigos anteriores ao snapshot", e mesmo sem snapshot os blocos antigos podem persistir devido ao CoW, não trate o snapshot como a única esperança.
• "Pagar alguém para descriptografar é mais prático": muitos "serviços de descriptografia" de origem desconhecida são golpes secundários, que além de não recuperar os dados ainda vazam a privacidade; a solução deste artigo é somente leitura, gratuita e autoverificável, priorize-a.
• "O volume antigo do Synology em ext4 e o QNAP também funcionam": não se aplica. O ext4 não possui copy-on-write, os blocos antigos não são preservados, sendo necessária uma abordagem completamente diferente.

Aviso legal

Este projeto é fornecido "no estado em que se encontra",destinado apenas à recuperação de dados sobre os quais você tem direito de dispor. A ferramenta em si é somente leitura, mas qualquer operação de recuperação envolve riscos: preserve primeiro as evidências, valide primeiro com uma pequena amostra usando originais conhecidos e só depois opere em lote. O autor não se responsabiliza por perda de dados. Este artigo é apenas uma organização e explicação desse projeto de código aberto e não constitui qualquer compromisso de serviço técnico profissional; antes de realmente agir, leia obrigatoriamente o SKILL.md e o diretório references no repositório.