Cuando lo simple salva el día: «dd» en Forense Digital y CSIRT
“No hay herramienta mágica. Solo técnica, rigor y trazabilidad.”
— Mantra de todo investigador forense que ha estado en el campo.
🌐 Introducción: cuando la herramienta minimalista se convierte en el arma definitiva
En el ámbito del análisis forense digital y la respuesta ante incidentes (CSIRT), existe una tendencia natural hacia la complejidad: frameworks, plataformas integradas, dashboards, automatizaciones y reportes visuales. Todo eso está bien…
Hasta que el caso no te da tiempo para eso.
A veces estás frente a un disco degradado, un servidor en modo rescate, un endpoint comprometido sin GUI o un entorno aislado por seguridad. En esas condiciones, no hay EnCase, FTK ni autopsia gráfica que te salve. Lo que tienes es un shell, un root prompt… y conocimiento.
Y ahí entra dd: una de las herramientas más antiguas de Unix (1974), pero también una de las más poderosas cuando se usa con criterio forense.
Su simplicidad es su fuerza. No necesita interfaz: necesita precisión.
🧩 El principio forense detrás de “dd”: bit a bit, sin interpretación
A diferencia de las herramientas de copia de archivos, dd no entiende de ficheros, ni sistemas de archivos, ni permisos. Solo lee y escribe bloques de datos binarios, exactamente como están grabados en el medio original.
Cuando usas:
dd if=/dev/sdb1 of=/home/caine/Desktop/Adquisiciones/01/evidencia01.dd bs=64
le estás diciendo a dd:
“Lee el dispositivo
/dev/sdb1en bloques de 64 bytes y crea una imagen exacta llamadaevidencia01.dd”.
Esa copia incluye:
- Archivos visibles y borrados.
- Espacios no asignados.
- Sectores dañados (si no abortas ante ellos).
- Metadatos residuales.
En otras palabras: una réplica bit a bit, con todo lo que un perito podría necesitar analizar en una etapa posterior.
🚀 Mejorando la operación: velocidad, control y resiliencia
1️⃣ Monitoreo con pv (Pipe Viewer)
Una de las desventajas clásicas de dd es su silencio: por defecto no muestra progreso.
La solución: pv, que permite visualizar en tiempo real la velocidad, el avance y el tiempo estimado.
dd if=/dev/sdb1 bs=4096 | pv | dd of=/home/caine/Desktop/Adquisiciones/01/evidencia02.dd
Aquí, pv actúa como un “visor intermedio”, sin modificar los datos. Perfecto para entornos donde necesitas documentar el tiempo de adquisición o evaluar el rendimiento del medio fuente.
2️⃣ Robustez ante errores: conv=noerror,sync
Cuando el medio tiene sectores dañados —por ejemplo, un disco con sectores ilegibles o un pendrive corrupto— lo peor que puede pasar es que la adquisición se detenga a la mitad.
Con esta variante:
dd if=/dev/sdb1 bs=64 | pv | dd of=/home/caine/Desktop/Adquisiciones/01/evidencia03.dd conv=noerror,sync
le estás ordenando a dd:
noerror→ no te detengas ante errores de lectura.sync→ rellena los bloques dañados con ceros para mantener la estructura.
Eso significa que, aunque algunos sectores no sean legibles, la imagen sigue siendo completa y coherente, permitiendo análisis parciales o recuperación de datos intactos.
🔒 La verificación: hashes, la huella digital de la evidencia
La adquisición no termina al copiar: termina cuando valida su integridad.
El uso de sha256sum (o cualquier otro algoritmo de hash seguro) permite comparar el original y la imagen resultante:
sha256sum /dev/sdb1 /home/caine/Desktop/Adquisiciones/01/evidencia01.dd
Resultado típico:
f30f42213d89ada72379a7d0b409f0e3d0087564de2f2d897cedfd0625d9ae7 /dev/sdb1
f30f42213d89ada72379a7d0b409f0e3d0087564de2f2d897cedfd0625d9ae7 /home/caine/Desktop/Adquisiciones/01/evidencia01.dd
Si las huellas coinciden, tienes prueba matemática de que la imagen es idéntica al original.
Eso es verificabilidad: el núcleo de la ciencia forense digital.
🧠 Más allá del comando: metodología CSIRT y trazabilidad
Un CSIRT maduro no se mide solo por sus herramientas, sino por su capacidad de documentar y defender su procedimiento técnico ante auditorías, litigios o revisiones externas.
Por eso, dd encaja perfectamente en la filosofía KISS (Keep It Simple, Secure & Scientific):
- Simple, porque su funcionamiento es lineal y reproducible.
- Secure, porque minimiza dependencias y automatismos.
- Scientific, porque cada paso puede ser repetido y verificado por otro perito.
Usado dentro de una política formal de respuesta a incidentes, dd debe ir acompañado de:
- Registro de comandos exactos usados (
bash historyo bitácora manual). - Identificación de operador, fecha y medio de destino.
- Hashes antes y después.
- Hash del archivo de log del proceso.
- Control de acceso físico y lógico a la evidencia.
Este enfoque convierte una copia binaria en una adquisición forense certificable.
🧰 Casos de uso reales donde dd salva el día
- Análisis de ransomware: copiar discos comprometidos antes de ejecutar herramientas de descifrado o limpieza.
- Incidentes en entornos sin GUI: servidores Linux, routers, sistemas embebidos.
- Discos parcialmente dañados: rescate de información de discos que no montan en sistemas operativos convencionales.
- Contenedores cifrados o imágenes en red: crear “snapshots” bit a bit antes de intentar romper cifrados o analizar sectores.
Y sí, muchos profesionales aún combinan dd con herramientas más modernas como dc3dd, dcfldd o Guymager, pero en la base, el principio sigue siendo el mismo: copiar sin alterar.
⚙️ Consejos prácticos para un uso profesional
- Usa bloques grandes (
bs=4096obs=1M) para acelerar el proceso. - Ejecuta
syncantes y después de cada copia para vaciar cachés. - Si la evidencia es crítica, crea dos imágenes verificadas en medios distintos.
- No montes nunca el disco origen en modo escritura.
- Registra timestamp, hashes, y logs en un cuaderno forense o sistema SIEM.
🧩 Epílogo: el bisturí del cirujano digital
En un mundo lleno de suites forenses con botones brillantes, “dd” sigue siendo el bisturí del cirujano digital.
No deslumbra, no automatiza, no se vende como solución mágica… pero cuando todo lo demás falla, “dd” funciona.
Y cuando lo usas con método, lo simple salva el día.
