Caminando por la agonía o la larga historia de un intento de recuperación de datos

Era 2019. Nuestro laboratorio recibió una unidad QUANTUM FIREBALL Plus KA con una capacidad de 9.1 GB, lo que no es del todo común en nuestro tiempo. Según el propietario del disco, el fallo se produjo en 2004 debido a un fallo en el suministro eléctrico, que se llevó consigo el disco duro y otros componentes del PC. Luego hubo visitas a varios servicios con intentos de reparar el disco y restaurar datos, que no tuvieron éxito. En algunos casos prometieron que sería barato, pero nunca solucionaron el problema, en otros era demasiado caro y el cliente no quería restaurar los datos, pero al final el disco pasó por muchos centros de servicio. Se perdió varias veces, pero gracias a que el propietario se encargó de registrar previamente la información de varias pegatinas en el disco, logró que su disco duro fuera devuelto en algunos centros de servicio. Los paseos no transcurrieron sin dejar rastro, quedaron múltiples rastros de soldadura en la placa del controlador original y la falta de elementos SMD también se sintió visualmente (de cara al futuro, diré que este es el menor de los problemas de esta unidad).

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 1 HDD Quantum Fireball Plus KA 9,1GB

Lo primero que tuvimos que hacer fue buscar en el archivo de donantes un hermano gemelo tan antiguo de esta unidad con una placa controladora que funcionara. Una vez completada esta búsqueda, fue posible llevar a cabo amplias medidas de diagnóstico. Después de verificar si hay un cortocircuito en los devanados del motor y asegurarnos de que no haya cortocircuito, instalamos la placa desde el variador donante al variador del paciente. Aplicamos energía y escuchamos el sonido normal del eje girando, pasando una prueba de calibración con la carga del firmware, y después de unos segundos la unidad informa mediante registros que está lista para responder a los comandos de la interfaz.

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 2 indicadores DRD DSC indican que está listo para recibir comandos.

Realizamos copias de seguridad de todas las copias de los módulos de firmware. Comprobamos la integridad de los módulos de firmware. No hay problemas con la lectura de los módulos, pero el análisis de los informes muestra que existen algunas rarezas.

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 3. Tabla de zonas.

Prestamos atención a la tabla de distribución zonal y observamos que el número de cilindros es 13845.

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 4 Lista P (lista primaria – lista de defectos introducidos durante el ciclo de producción).

Llamamos la atención sobre el número demasiado pequeño de defectos y su ubicación. Observamos el módulo de registro de ocultación de defectos de fábrica (60h) y encontramos que está vacío y no contiene una sola entrada. En base a esto, podemos suponer que en uno de los centros de servicio anteriores es posible que se hayan realizado algunas manipulaciones con el área de servicio del disco, y accidental o intencionalmente se escribió un módulo extraño, o la lista de defectos en el original. uno fue absuelto. Para probar esta suposición, creamos una tarea en Data Extractor con las opciones "crear copia sector por sector" y "crear traductor virtual" habilitadas.

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 5 parámetros de tarea.

Una vez creada la tarea, miramos las entradas en la tabla de particiones en el sector cero (LBA 0)

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 6 Registro de arranque maestro y tabla de particiones.

En el desplazamiento 0x1BE hay una única entrada (16 bytes). El tipo de sistema de archivos en la partición es NTFS, desplazado al comienzo de los sectores 0x3F (63), tamaño de partición 0x011309A3 (18) sectores.
En el editor de sectores, abra LBA 63.

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 7 sector de arranque NTFS

Según la información del sector de arranque de la partición NTFS, podemos decir lo siguiente: el tamaño del sector aceptado en el volumen es 512 bytes (la palabra 0x0 (0) está escrita en el desplazamiento 0200x512B), el número de sectores en el clúster es 8 (el byte 0x0 está escrito en el desplazamiento 0x08D), el tamaño del clúster es 512x8=4096 bytes, el primer registro MFT está ubicado en un desplazamiento de 6 sectores desde el principio del disco (en un desplazamiento de 291x519 palabra cuádruple 0x30 0 00 00 00 00C 00 0 (00) número del primer grupo MFT. El número de sector se calcula mediante la fórmula: Número de grupo * número de sectores en el grupo + desplazamiento al comienzo de la sección 00* 786+432= 786).
Pasemos al sector 6.

Caminando por la agonía o la larga historia de un intento de recuperación de datos
La figura. 8

Pero los datos contenidos en este sector son completamente diferentes a los del registro del MFT. Aunque esto indica una posible traducción incorrecta debido a una lista de defectos incorrecta, no prueba este hecho. Para comprobarlo más a fondo, leeremos el disco en 10 sectores en ambas direcciones en relación con 000 sectores. Y luego buscaremos expresiones regulares en lo que leemos.

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 9 Primera grabación MFT

En el sector 6 encontramos el primer registro de MFT. Su posición difiere de la calculada en 291 sectores, y luego le sigue continuamente un grupo de 551 registros (de 32 a 16). Introduzcamos la posición del sector 0 en la tabla de cambios y avancemos 15 sectores.

Caminando por la agonía o la larga historia de un intento de recuperación de datos
La figura. 10

La posición del registro n.° 16 debería estar en el desplazamiento 12, pero allí encontramos ceros en lugar del registro MFT. Realicemos una búsqueda similar en los alrededores.

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 11 Entrada MFT 0x00000011 (17)

Se detecta un gran fragmento de MFT, comenzando con el registro número 17 con una longitud de 53 registros) con un desplazamiento de 646 sectores. Para la posición 17, coloque un desplazamiento de +12 sectores en la tabla de desplazamientos.
Habiendo determinado la posición de los fragmentos de MFT en el espacio, podemos concluir que esto no parece una falla aleatoria ni un registro de fragmentos de MFT con desplazamientos incorrectos. Una versión con un traductor incorrecto se puede considerar confirmada.
Para localizar aún más los puntos de cambio, estableceremos el desplazamiento máximo posible. Para hacer esto, determinamos cuánto se desplaza el marcador final de la partición NTFS (copia del sector de arranque). En la Figura 7, en el desplazamiento 0x28, la palabra cuádruple es el valor del tamaño de la partición de 0x00 00 00 00 01 13 09 A2 (18) sectores. Sumemos el desplazamiento de la partición desde el principio del disco a su longitud y obtenemos el desplazamiento del marcador NTFS final 024 866 18 + 024 = 866 63 18. Como era de esperar, la copia requerida del sector de arranque no estaba allí. Al buscar en el área circundante, se encontró con un desplazamiento creciente de +024 sectores en relación con el último fragmento de MFT.

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 12 Copia del sector de arranque NTFS

Ignoramos la otra copia del sector de arranque en el desplazamiento 18, ya que no está relacionada con nuestra partición. Con base en actividades anteriores, se estableció que dentro de la sección hay inclusiones de 041 sectores que “surgieron” en la transmisión, lo que amplió los datos.
Realizamos una lectura completa del disco, lo que deja 34 sectores sin leer. Desafortunadamente, es imposible garantizar de manera confiable que todos ellos sean defectos eliminados de la lista P, pero en un análisis más detallado es aconsejable tener en cuenta su posición, ya que en algunos casos será posible determinar de manera confiable los puntos de cambio con una precisión del sector, y no del archivo.

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 13 Estadísticas de lectura de disco.

Nuestra próxima tarea será establecer las ubicaciones aproximadas de los turnos (con la exactitud del archivo en el que ocurrieron). Para hacer esto, escanearemos todos los registros MFT y crearemos cadenas de ubicaciones de archivos (fragmentos de archivos).

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 14 Cadenas de ubicación de archivos o sus fragmentos.

A continuación, pasando de un archivo a otro, buscamos el momento en el que habrá otros datos en lugar del encabezado del archivo esperado, y el encabezado deseado se encontrará con un cierto desplazamiento positivo. Y a medida que refinamos los puntos de cambio, completamos la tabla. El resultado de rellenarlo será más del 99% de los archivos sin daños.

Caminando por la agonía o la larga historia de un intento de recuperación de datos
Arroz. 15 Lista de archivos de usuario (se recibió el consentimiento del cliente para publicar esta captura de pantalla)

Para establecer cambios de puntos en archivos individuales, puede realizar trabajo adicional y, si conoce la estructura del archivo, encontrar inclusiones de datos que no estén relacionados con él. Pero en esta tarea no era económicamente viable.

PD: También me gustaría dirigirme a mis colegas, en cuyas manos estuvo anteriormente este disco. Tenga cuidado al trabajar con el firmware del dispositivo y haga una copia de seguridad de los datos del servicio antes de cambiar algo, y no agrave deliberadamente el problema si no pudo ponerse de acuerdo con el cliente sobre el trabajo.

Publicación anterior: Guardar coincidencias o recuperar datos de un disco duro Seagate ST3000NC002-1DY166

Fuente: habr.com

Añadir un comentario