Cómo recuperar datos antiguos de Btrfs sin clave tras el cifrado de Synology por C3RB3R

Primero, la conclusión

Si tu NAS Synology ha sido C3RB3R(extensión de archivo .L0CK3D, deja read-me3.txt nota de rescate) cifrado, no te des por vencido ni pagues el rescate. Siempre que tu recurso compartido esté en sistema de archivos Btrfsy aún no hayas realizado operaciones destructivas como defrag / balance / reparación forzada,una gran parte de los archivos se pueden recuperar sin la clave. La razón es contraintuitiva: C3RB3R reescribe los archivos «en el lugar», y la copia en escritura (CoW) de Btrfs conserva el contenido antiguo sobrescrito en el disco; el texto plano del archivo original queda oculto en esos bloques de datos antiguos no reclamados.

La comunidad de código abierto ya ha convertido este proceso de recuperación en un conjunto de herramientas:crt106/c3rb3r-btrfs-recovery(licencia MIT, solo lectura, únicamente para recuperar datos que tengas derecho a gestionar). Este artículo explica claramente su principio, la elección de ruta, los pasos de operación y los datos de casos reales. Si aún no has sido afectado, lee primeroel artículo anterior «NAS Synology ransomware: primero actualiza DSM, luego activa snapshots inmutables»—prevenir es mucho más importante que rescatar después.

I. Dos rutas de recuperación: elige bien primero

Para recuperar los archivos, el primer paso no es buscar herramientas, sino determinarsi el proceso de cifrado sigue activo. La diferencia de resultados entre estas dos rutas es enorme:

Ruta A: el proceso de cifrado sigue vivo (el mayor beneficio)

Si el incidente ocurrió hace poco y el NAS no se ha reiniciado, es muy probable que el proceso de cifrado (por ejemplo:/usr/bin/libgld -n 308, el archivo del programa puede haberse eliminado del disco) siga ejecutándose en memoria. Lo primero que hay que hacer es:

1. 用 kill -STOP <pid> congelarlo, no hacer kill, y mucho menos reiniciar.
2. Luego, siguiendo el método de los otros dos repositorios, extraer de la memoria del proceso laclave maestra de sesión—así se puedendescifrar todos los archivos, el beneficio es mucho mayor que la siguiente ruta Btrfs:
   • soimy/c3rb3r-rescue: preservación de evidencia, recuperación de claves desde RAM, copia y descifrado
   • Benjamin-zlt/c3rb3r-baremetal-rescue: congelar el cifrador en DSM sobre máquina física, exportar la memoria del proceso, extraer la clave de sesión, descifrado completo (ya existe un caso completo de descifrado de una segunda víctima independiente)

Ruta B: el proceso de cifrado ya terminó (el vacío que cubre este repositorio)

Si el NAS ya se ha reiniciado, o si han pasado más de diez horas desde el incidente, básicamente ya no se puede encontrar la clave en memoria (el autor de ese proyecto realizó un escaneo exhaustivo de memoria y el resultado fue cero). En este caso se sigue la ruta de recuperación de bloques de datos antiguos de Btrfsde este repositorio: no depende de la clave, solo se apoya en el texto plano antiguo que dejó el sistema de archivos.

Este artículo se centra en la ruta B. Ambas rutas pueden combinarse: primero se intenta obtener la clave y, si no se consigue, se pasa a Btrfs.

II. Principio: por qué se puede recuperar el texto plano sin clave

En una frase:C3RB3R solo sobrescribió unos pocos segmentos del archivo, y el contenido antiguo sobrescrito quedó conservado en bloques completos en Btrfs.

Cómo se cifra exactamente:

• Archivos pequeños: cifrado completo;
• Archivos de 1–5MB: solo se cifra el primer 1MiB;
• Archivos grandes: se cifran tres segmentos «cabeza, medio, cola», en total aproximadamente el 12%.

Btrfs es un sistema de archivos copy-on-write. Cuando un archivo se reescribe en el lugar, el nuevo contenido se escribe enuna nueva ubicación, ylos bloques de datos originales (extent) se conservan íntegros en el disco siempre que sigan siendo referenciados por «la parte no cifrada del archivo». Estos extents antiguos quedan como sujetalibros a ambos extremos del archivo, y el autor llama a este fenómeno «bookend extent»。

Lo que hace la herramienta de recuperación es: siguiendo el árbol de extents de Btrfs, mapear cada byte reescritode vuelta a su extent antiguo original, leerlo directamente del dispositivo de bloques en modo solo lectura y reconstruir los bytes originales. Mejor aún, en recursos compartidos con «sumas de verificación de datos» habilitadas, también se puede usar el checksum CRC32C propio de Btrfs para demostrar bloque por bloqueque el contenido recuperado es efectivamente correcto.

Un ejemplo concreto ayuda a entenderlo mejor: un video familiar de 100MB, C3RB3R solo cifró el encabezado, la parte central y la cola, unos 12MB en total, y los casi 88MB restantes de texto plano quedan intactos en el extent antiguo; en cambio, un documento de 50KB, al ser menor de 1MiB, se cifra por completo, así que en el disco ya no se encuentra el texto plano antiguo. Por esocuanto más grande sea el archivo, más checksums tenga activados y más temprano se haya escrito (antes del snapshot más reciente), mayor será la proporción recuperable; a la inversa, los miles de archivos pequeños y las bases de datos son los que están en peor situación.

Un punto fácil de malinterpretar:que un recurso compartido NoCOW sin «checksum de datos» marcado tampoco significa que no haya salvación. Siempre que los datos se hayan escrito antes delúltimo snapshotde ese subvolumen (aunque el snapshot se haya borrado después), al sobrescribir se seguirá usando copy-on-write, así que los datos antiguos anteriores al snapshot igualmente se pueden recuperar.

III. Qué es esta herramienta

crt106/c3rb3r-btrfs-recovery En esencia es una habilidad de AI Agent (SKILL.md), para usarse con agentes como Claude Code, Codex, Cursor que admiten el mecanismo de habilidades. Organiza el flujo completo de una recuperación real, las herramientas de solo lectura y los métodos de verificación en una guía genérica. Hay tres principios de diseño centrales:

• Solo lectura: en el lado del NAS solo se hacen consultas ioctl, lectura de archivos y lectura de dispositivos de bloque, los resultados se escriben en un disco fuera del NAS, nunca se dejan archivos en el volumen de datos y nunca se reescribe nada;
• Verificable: cada bloque recuperado se puede contrastar con el checksum de Btrfs, distinguiendo entre «recuperación exacta» y «decodificación especulativa»;
• Reversible: al sustituir localmente bytes candidatos se genera una *.c3rbak copia de seguridad, con rollback a nivel de byte.

IV. Pasos detallados (ruta de recuperación Btrfs)

Paso 0: primero respetar las líneas rojas (este paso es más importante que la recuperación en sí)

Antes de tocar nada, estas cosasno se deben hacer bajo ningún concepto：

• No eliminar ni sobrescribir ningún .L0CK3D archivo, ni vaciar la papelera de reciclaje.Los bloques de datos antiguos se mantienen precisamente porque estos archivos cifrados los «retienen» y evitan que el sistema de archivos los reclame: en cuanto borras, el texto plano antiguo puede sobrescribirse de inmediato y perderse definitivamente;
• No hacer defrag, balance,btrfs check --repair, ya que reescriben datos y destruyen directamente los bloques antiguos;
• No pagar el rescate, y tampoco ejecutes "descifradores" de origen desconocido (muchos son una segunda estafa);
• corta la alimentación o la red del NAS cuanto antes para preservar la escena y reducir las escrituras.

Paso 1: instalación

con 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

instalación manual: copia skills/c3rb3r-btrfs-recovery/ todo el directorio al directorio de skills del agent (por ejemplo, el de Claude Code ~/.claude/skills/）。

Paso 2: autocomprobación del entorno preflight

en cualquier dispositivoejecuta primero este paso, que dará OK / WARN / FAIL elemento por elemento junto con recomendaciones de tratamiento:

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"

aquí mkjob.py se encarga de empaquetar la lista de herramientas y rutas, entregarla por la entrada estándar de SSH al NAS para su ejecución,sin dejar archivos en el volumen de datos。

Pasos 3~6: determinar la generación → validación de un solo archivo → inspección exhaustiva → validación de exportación

en este paso se recomienda entregar directamente la situación al agent, que lo ejecutará automáticamente según SKILL.md; también se pueden ejecutar los scripts manualmente. El flujo es:

1. Determinar la generación de ataque G_ATTACK: los formatos de cifrado difieren ligeramente entre generaciones, alinear primero;
2. Validar con un solo archivo usando un original conocido: toma un archivo con el mismo nombre cuya versión original aún conserves localmente y compáralo, confirma que la lógica de recuperación es correcta y luego procede en lote;
3. Censo completo survey: escanear todo el volumen, marcar qué bytes de cada archivo fueron sobrescritos y si se pueden recuperar desde el extent antiguo;
4. Exportación en streaming + verificación múltiple: reensamblar los bytes recuperados, verificar localmente con decodificación multiproceso, comparar contra los originales conocidos, seleccionar el mejor candidato y finalmente generar el informe.

Puntos a vigilar de cerca durante la operación:preflight Si cualquier elemento muestra FAIL (por ejemplo, si se detecta que es un volumen ext4, o que no se encuentra Python 3 en el NAS), no continúes y procede según la sugerencia que indique;G_ATTACK el álgebra es la base de todas las coincidencias posteriores, un juicio erróneo hará que todo el lote no coincida; la validación de un solo archivo debe hacerse conun archivo que confirmes que tu original local es correcto, y solo después de que la validación pase procede con el lote, no uses una copia sospechosa de estar dañada para verificar.

Resumen de división de tareas de los scripts

Paso 7: entender el informe

El informe de recuperación clasifica los resultados en tres categorías, no las confundas:

• Recuperación exacta y confirmada por checksum: la más fiable, Btrfs CRC32C coincide bloque a bloque;
• Decodificación exitosa tras inferencia: reconstrucción lógica exitosa, pero sin respaldo de checksum, se recomienda conservar para verificación;
• Fallo: esta parte está realmente perdida.

V. Compatibilidad: ¿funciona en tu entorno?

El proyecto ya ha sido Synology DSM 7.2.1(SHR,cachedev, Python 3.8) verificado en hardware real. Para otros entornos, ejecuta primero preflight, que dará recomendaciones punto por punto. Casos conocidos de adaptación/pendientes de verificación:

• DSM 6, OMV, Unraid, dispositivos sin Python 3, extraer los discos y conectarlos a un equipo Linux para procesamiento offline — la documentación incluye guías personalizadas y manejo de errores para cada caso;
• No aplicable a ext4(la mayoría de volúmenes QNAP, volúmenes antiguos de Synology),ZFS requiere otro conjunto de herramientas。

VI. Caso real: qué se recuperó exactamente

El primer caso publicado por el autor, con los siguientes resultados de recuperación:

resumen en una frase:archivos grandes, recursos compartidos con checksum habilitado, datos antiguos previos al snapshot: alta tasa de recuperación; archivos pequeños cifrados como archivo completo, bases de datos, contenido escrito solo después del snapshot: prácticamente sin posibilidad.

Siete, qué no se puede recuperar, y algunas advertencias

• archivos pequeños de menos de 1MiBCifrado por completo, no hay texto plano antiguo recuperable en el disco;
• archivos de base de datos(como SQLite/PostgreSQL, que reescriben frecuentemente el archivo completo) suelen reescribirse en bloques enteros, y los bloques antiguos ya fueron sobrescritos;
• datos escritos en un recurso compartido NoCOW después del último snapshot, al sobrescribirse no pasaron por CoW, los bloques antiguos no existen;
• la herramienta en sí es de solo lectura, perocualquier operación de recuperación tiene riesgos: primero preserve la evidencia, valide primero con originales conocidos en muestras pequeñas, y luego opere en lote;
• esta no es una solución de «restaurar todos los archivos con un clic», es recuperar al máximo el texto plano antiguo que quedó por suerte en el sistema de archivos,cuánto se pueda recuperar depende de la cantidad de escritura y el tiempo— cuanto más lleno el volumen y más tiempo haya pasado desde el incidente, más bloques antiguos habrán sido sobrescritos.

Los tres repositorios pueden usarse en combinación:soimy/c3rb3r-rescue 和 Benjamin-zlt/c3rb3r-baremetal-rescue se encarga de «obtener la clave desde la memoria mientras el proceso sigue vivo», este repositorio se encarga de «cuando la clave ya no está, recurrir a los bloques de datos antiguos de Btrfs».

VIII. Varios malentendidos comunes

• «Basta con borrar la nota de rescate y cambiar el nombre»: el contenido del archivo ya ha sido cifrado y reescrito, cambiar el nombre no altera los datos; borrarla .L0CK3D en cambio hará que los bloques de datos antiguos pierdan sus referencias y sean reclamados más rápido por el sistema de archivos, lo que puede hacer que incluso lo que antes se podía recuperar ya no se pueda recuperar.
• «He activado snapshots, seguro que puedo restaurar»: los snapshots salvan lo añadido y modificado después del punto del snapshot, pero en este caso el proceso de cifrado reescribe directamente los archivos de la «versión actual», y el snapshot no cubre los archivos actuales ya reescritos; precisamente esta solución aprovecha los «bloques antiguos previos al snapshot», y sin snapshot los bloques antiguos también pueden perdurar por CoW, no tomes el snapshot como única esperanza.
• «Pagar a alguien para que descifre es más cómodo»: muchos «servicios de descifrado» de origen desconocido son estafas secundarias, que ni recuperan los datos ni evitan la filtración de privacidad; la solución de este artículo es de solo lectura, gratuita y autoverificable, priorízala.
• «El volumen antiguo de Synology con ext4, QNAP también puede usarlo»: no aplica. ext4 no tiene copy-on-write, los bloques antiguos no se conservan, se necesita un enfoque completamente distinto.

Descargo de responsabilidad

Este proyecto se proporciona «tal cual»,solo para recuperar datos sobre los que tú mismo tengas derecho a disponer. La herramienta en sí es de solo lectura, pero cualquier operación de recuperación conlleva riesgos: primero preserva las pruebas, valida primero con una muestra pequeña usando originales conocidos y luego opera en lote. El autor no asume responsabilidad por la pérdida de datos. Este artículo es solo una recopilación y explicación de dicho proyecto de código abierto, y no constituye ningún compromiso de servicio técnico profesional; antes de ponerte manos a la obra, asegúrate de leer primero el SKILL.md y el directorio references del repositorio.