Caso Forense disco dañado

Caso Forense disco dañado

Table of Contents

Contexto

Este caso es de una amiga que quería que le valorara el estado de su portátil(Lenovo IdeaPad 320) que llevaba años parado.

El ordenador enciende y carga el SO, pero presenta lentitud y se apaga de forma aleatoria.
Especificaciones técnicas:

  • 4GB RAM
  • SO Windows 10
  • SSD SK hynix 128GB
  • CPU intel i5

En el administrador de tareas veo que el valor de CPU apenas llega tiene carga en CPU, dado la escasa RAM que tiene si se aprecia un valor alto de RAM (pero sin llegar a saturar)y el trabajo de disco casi todo el rato al 100% (y casi lleno todo el espacio, apenas 10GB libres).

Análisis

Con los valores anteriores, a modo de brainstorming, en un primer lugar me hace pensar que tal vez la RAM está mandando a swapear y eso termine de saturar el disco.

Libero de procesos, deshabilito servicios innecesarios y desinstalo algunos programas no utilizados. Consigo descongestionar RAM, almacenamiento y ganar en velocidad de funcionamiento, pero el problema persiste; disco trabajando al 100% con cualquier mínima tarea, pantallazo azul y apagado.

No se generan valores altos de temperatura, de hecho apenas genera calor.

El memtest da PASS a la RAM.

Analizo el siguiente componente, el disco. Compruebo la salud del disco con el comando winsat disk, peor que vaya lento este proceso ya es una mala señal, llegándose a congelar el PC y finalmente pantallazo azul de nuevo con “CRITICAL_PROCESS_DIED” y posterior apagado.

Toca remangarse y pasar a posturas más forenses, con un USB liveCD de Linux Mint (Se que no es la herramienta más forense, pero es lo que tenía a mano ya que la uso para difundir la palabra de L.Torlvalds).

Lanzo smartctl -a /dev/sda, pese a que en la salida tenemos un:

SMART overall-health self-assessment test result: PASSED`

La salida muestra también sectores reasignados, lo que en un disco sano debería ser 0:

5 Reallocated_Sector_Ct
RAW_VALUE = 15

también mostraba errores de lectura no corregibles ATA Error Count: 57 del tipo UNC (Uncorrectable Error)

Lanzo una segunda pasada más profunda para confirmar:

sudo smartctl -t long /dev/sda

y en este caso se obtiene una salida diferente:

Self-test execution status:
The previous self-test completed having the read element of the test failed.
[...]
# 1 Extended offline
Completed: read failure
LBA_of_first_error = 3115376

Respecto al primer SMART cambian los valores:

  • Reallocated_Sector_Ct ha pasado de 15 a 16.
  • Raw_Read_Error_Rate ha pasado de 0 a 290.
  • El test SMART ha terminado con read failure.
  • Sigue habiendo 57 errores ATA UNC

Finalmente hay un diagnóstico: el disco duro se encuentra dañado a nivel físico(bloques), es una bomba de relojería que amenaza con encerrar todo su contenido dentro.

Actuación

Dada la situación toca salvar el contenido de la usuaria(a la que llamaremos usuariaanonima), antes del análisis ya intenté el copia y pega pero se apagaba a mitad. Ahora sé que es porque llegaba a esos bloques corruptos y se quedaba en bucle intentando leerlos.

Creamos puntos de montaje de windows y el backup. Uso:

rsync -aHAXv \
  --info=progress2 \
  --ignore-errors \
  --partial \
  "/mnt/windows/Users/usuariaanonima/" \
  "/media/veracrypt5/Backup_Lenovo/usuariaanonima/"

Lo cual genera muchos avisos de fallo, la mayoría por atributos windows

rsync_xal_set: lsetxattr(... "user.Zone.Identifier") failed:
Operation not supported (95)

y también algunos avisos más serios y que confirman la degracación del disco

rsync: [sender] read errors mapping "...videoanonimo.MP4":
Input/output error (5)

y también:

ERROR: ... failed verification -- update discarded.

La buena noticia, se transfirió casi por completo; la mala, tras comprobar el estado de la copia la gran mayoría de las fotos en la previsualización ya mostraban básicamnete bits gigantes en lugar de fotos, tal vez un pino en un lateral y el 80% restante de la foto un cuadro sólido de color marrón o directamente daban error al abrir.

Tocaba ser más quirúrgicos y hacer una copia idéntica del disco volcándolo a una imagen. Hubo que tirar de ddrescue

ddrescue \
-f \ # El mítico force
-n \ # No scraping, que no haga reintentos
-v \ # El mítico verbose
/dev/sda \
/media/veracrypt5/Lenovo320.img \
/media/veracrypt5/Lenovo320.log

Segunda pasada:

ddrescue \
-d \ # Directo a leer disco, nada de caché
-r1 \ #  Reintentos de lectura
-v \
/dev/sda \
/media/veracrypt5/Lenovo320.img \
/media/veracrypt5/Lenovo320.log

Finalizada la largatarea, obtenemos la salida:

rescued: 127968 MB
pct rescued: 99.94%
bad-sector: 3961 kB
bad areas: 7738
Finished

Montamos la imagen obtenida:

losetup -Pf --show /media/veracrypt5/Lenovo320.img
mkdir /mnt/imagen
mount -o ro /dev/loop1p3 /mnt/imagen

y comprobamos que el contenido de en este caso estaba perfectamente.

Finalmente entregamos a la usuaria el contenido junto a la recomendación de comprar un nuevo disco y ampliar la RAM.

Tags :
Share :