The Information Systems and Computer Applications examination covers material that is usually taught in an introductory college-level business information systems course.

Forense en discos SSD by Joel Sevilleja

Estaba haciendo el otro día mis pinitos con django , cuando por una negligencia, borré una aplicación que ya tenía terminada. La web no era compleja, tenía pocas líneas de código y creía que la podría volver a tener en menos de un día, pero sin embargo, vi la ocasión como una oportunidad para aprender a hacer una recuperación de datos en un disco SSD.

La configuración del disco de este equipo es la siguiente: particionado GPT con varias particiones formateadas conext4 (nada de LVM). Mi experiencia previa en este tipo de casos siempre ha sido utilizar las herramientas más conocidas en entornos GNU/Linux: sleuthkitautopsytestdisk y photorec (éstas dos últimas suelen venir en el mismo paquete), ddgrep

Volviendo al caso, nada más darme cuenta de lo que había hecho intenté mantener la calma y seguir lo que suele ser mi procedimiento estándar: montar la partición en la que estaba el proyecto como sólo lectura y crear una imagen de la partición con la herramienta ‘dd‘, de manera que las nuevas interacciones con el disco no sobreescriban ningún dato.

Creada la imagen, mi primera opción fue testdisk, un software de análisis forense y recuperación de datos que me ha dado muy buenos resultados en el pasado. No obstante, en esta ocasión me decía que la partición estaba corrupta, por lo que no podía recuperar el contenido del disco. A día de hoy, desconozco si fue por un error mío en las múltiples opciones que ofrece testdisk, o si bien por el contrario esta herramienta no se lleva bien con discos SSD o con particiones GPT.

Tras un primer intento fallido, probé suerte con sleuthkit y autopsy. En esta ocasión, todo iba como la seda. Tras establecer los parámetros iniciales del caso, empecé a “jugar” con las opciones de autopsy:

No obstante, parecía que el procedimiento iba para rato, ya que la imagen de disco tenía cierto tamaño y estaba almacenada en un disco duro externo USB. Como no me apetecía estar delante del PC sin hacer nada un viernes de madrugada, cancelé los procesos de sleuthkit y me puse a utilizar photorec.

Con photorec la cosa cambió: en cuestión de segundos, estaba recuperando multitud de ficheros, algunos de ellos borrados hacía meses. Como iba para rato, pero había podido comprobar que estaba haciendo su tarea, decidí dejar el proceso ejecutándose y continuar la mañana siguiente. Cual fue mi sorpresa al día siguiente al ver quephotorec había encontrado unos cuantos miles de ficheros de tipo texto (extensiones txt, java (en este equipo nunca he programado en Java), html, py…).

Dado el gran número de ficheros, nada mejor que un poco de grep y unas cuantas expresiones regulares para encontrar el directorio y los ficheros que me interesaban. Al ser código en python, empleé sentencias que serían únicas de python, como import, nombres de variables que recordaba, tags html…

Al cabo de unas cuentas horas, pese a que parecía que había recuperado casi la totalidad del proyecto y que si faltaba algo podría recodificarlo, había una cosa extraña: el número de ficheros que tenía ahora del proyecto era más del triple del número de ficheros que tenía originalmente. Tras ojear los ficheros para poder cambiarles el nombre por el original (photorec tiene una pega: cambia el nombre del fichero por caracteres alfanuméricos, e incluso hay veces que no detecta correctamente la extensión del fichero), vi que muchos ficheros se correspondían con el mismo y que muchos otros no estaban completos.

Descarté en seguida que se tratara de copias de seguridad: no había considerado que fuese necesario crear una copia de seguridad para un proyecto como éste. Además, ¿qué sería de la vida sin pequeñas emociones? (N.d.E.: niños, no hagáis caso a este insensato)

Mirando los ficheros detenidamente, pude ver como los ficheros se correspondían a versiones viejas de los mismos, como si cuando hubiese hecho un cambio y lo hubiese guardado en disco, se creara un nuevo fichero y se borrase el viejo, almacenándose cada uno en secciones diferentes del disco. También había unos cuantos ficheros parciales, en los que se veían funciones del código pero no todas las que coexistían en el mismo fichero.

Tras indagar un poco, pude discernir entre “versiones”, realizar varias pruebas en la aplicación y ver que líneas tenía que añadir, borrar o modificar para tener la aplicación tal y como la tenía antes. No obstante, se me planteaban nuevas cuestiones. ¿Guarda eclipse varias versiones del mismo fichero? ¿Es cosa del Sistema Operativo? ¿Es por utilizar un disco SSD?

Como muchos lectores ya se habrán imaginado, el causante de este comportamiento es la forma en la que el disco SSD almacena los datos. Sin embargo, me gustaría dejar los detalles técnicos para una próxima entrega, más técnica y menos teórica que la actual.

Comments are closed.