Solución — M03: Recuperación de datos borrados
fls e icat, o si llevas un buen rato atascado.1. Verificar el hash
$ sha256sum evidencia_caso03.dd
be046074c7eaec76b130c3665eeeed534c341c09ea44599a43f31563c2a9c73c evidencia_caso03.ddCoincide con el valor del LEEME.md: la imagen no se ha corrompido en la descarga, se puede analizar con confianza.
2. Listar ficheros, incluidos los borrados
$ fls -r -d evidencia_caso03.dd
r/r * 16: Documentos/informe_ventas_q3.xlsx
r/r * 17: Documentos/credenciales_backup.txt
r/r * 18: Documentos/captura_pantalla.jpgTres ficheros marcados como borrados (r/r *), cada uno con su número de inodo. El sistema de archivos sigue conociendo su nombre y ruta original porque, como se explicó en el capítulo, borrar solo desvincula la entrada — no borra ni el inodo ni el contenido hasta que algo los reutiliza.
3. Recuperar el fichero de credenciales (inodo 17)
$ icat evidencia_caso03.dd 17
# backup temporal de acceso - BORRAR ANTES DEL VIERNES
usuario: svc_backup
pass: Tr0ub4dor&3_2026
host: backup-internal.localRespuesta: sí existió un fichero de credenciales de backup, y contenía un usuario (svc_backup), una contraseña en texto claro y un host interno — exactamente el tipo de hallazgo por el que merece la pena revisar also el módulo 1 (nunca deberían existir credenciales en texto plano, mucho menos borradas "a mano" en vez de rotadas).
4. Recuperar el informe de ventas (inodo 16)
$ icat evidencia_caso03.dd 16
[Contenido simulado de hoja de calculo - Informe de Ventas Q3 2026]
Region,Ventas,Objetivo
Norte,482100,450000
Sur,397250,420000
Este,510900,500000
Oeste,275400,300000
Total,1665650,1670000Respuesta: el informe sí existió y contenía cifras completas por región, contradiciendo directamente la afirmación del empleado de que nunca lo guardó.
5. El tercer fichero: no es texto
El inodo 18 no se abre como texto legible — para identificarlo, se inspecciona su cabecera en hexadecimal antes de intentar nada más:
$ icat evidencia_caso03.dd 18 | xxd | head -1
00000000: ffd8 ffe0 0010 4a46 4946 0001 0100 0001 ......JFIF......La cabecera FF D8 FF E0 coincide exactamente con la firma de JPEG de la tabla del módulo 3. Se recupera y se guarda con la extensión correcta:
$ icat evidencia_caso03.dd 18 > captura_pantalla_recuperada.jpg
file captura_pantalla_recuperada.jpg
captura_pantalla_recuperada.jpg: JPEG image data, JFIF standard 1.01, baseline, precision 8, 64x64, components 3Respuesta: es una imagen JPEG (una captura de pantalla), recuperada íntegra — el inodo seguía intacto porque ningún fichero nuevo había reutilizado ese espacio todavía, igual que con los otros dos.
Conclusión del caso
Los tres ficheros se recuperan completos y legibles porque la adquisición (módulo 2) se hizo con rapidez, antes de que el sistema reutilizara el espacio liberado por el borrado — el mismo principio del orden de volatilidad aplicado al disco que se explicó al principio del capítulo. El empleado borró deliberadamente tanto el informe como el fichero de credenciales; ninguno de los dos "nunca existió".