Camino de sufrimiento o la larga historia de un intento de recuperar datos.

Era el año 2019. En nuestro laboratorio recibimos un dispositivo de almacenamiento QUANTUM FIREBALL Plus KA, bastante inusual para su tiempo, con una capacidad de 9.1GB. Según el dueño del dispositivo, la falla ocurrió en el lejano 2004, debido a un bloque de alimentación que falló y arrastró consigo el disco duro y otros componentes del PC. Posteriormente, hubo intentos de reparación en varios servicios para restaurar los datos, los cuales no tuvieron éxito. En algunos lugares prometieron precios bajos, pero no resolvieron el problema, en otros el costo fue demasiado alto y el cliente decidió no recuperar los datos, pero al final el disco pasó por muchos centros de servicio. Se perdió en varias ocasiones, pero gracias a que el propietario se preocupó por registrar la información de las diversas etiquetas en el dispositivo, pudo asegurarse de que su disco duro fuera devuelto de algunos centros de servicio. Las travesías no fueron en vano, la placa del controlador original presentaba múltiples marcas de soldadura, y además se notaba a simple vista la falta de elementos SMD (para adelantarme, diré que este era el menor de los problemas de este dispositivo).

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 1 HDD Quantum Fireball Plus KA 9.1GB

Lo primero que se tuvo que hacer fue buscar en el archivo de donantes un hermano gemelo tan antiguo de este dispositivo, pero con una placa de controlador funcional. Una vez completada esta búsqueda, fue posible llevar a cabo extensas actividades de diagnóstico. Tras comprobar que no había cortocircuitos en los devanados del motor, instalamos la placa del dispositivo donante en el dispositivo paciente. Conectamos la alimentación y oímos el sonido normal de arranque del eje, completando la prueba de calibración con la carga del firmware, y después de unos segundos, el dispositivo informa a través de los registros que está listo para recibir comandos desde la interfaz.

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 2 Los indicadores DRD DSC indican que está listo para recibir comandos.

Reservamos todas las copias de los módulos de firmware. Realizamos una verificación de la integridad de los módulos de firmware. No se presentan problemas al leer los módulos, pero el análisis de los informes muestra algunas irregularidades.

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 3. Tabla de zonas.

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

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 4 P-list (lista primaria – lista de defectos registrados durante el ciclo de producción).

Llamamos la atención sobre la cantidad demasiado baja de defectos y su localización. Revisamos el módulo de registro oculto de defectos de fábrica (60h) y descubrimos que está vacío y no contiene ninguna entrada. Basándonos en esto, podemos suponer que en alguno de los centros de servicio previos, se realizaron ciertas manipulaciones en la zona de servicio del disco, y accidental o intencionadamente se grabó un módulo ajeno, o se limpió la lista de defectos de la original. Para verificar esta suposición, creamos una tarea en Data Extractor con las opciones activadas de "creación de copia sectorial" y "creación de traductor virtual."

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 5 Parámetros de la tarea.

Al crear la tarea, revisamos las entradas en la tabla de particiones en el sector cero (LBA 0).

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 6 Registro de arranque principal y tabla de particiones.

En el desplazamiento 0x1BE se encuentra la única entrada (16 bytes). El tipo de sistema de archivos en la partición es NTFS, el desplazamiento hasta el principio es de 0x3F (63) sectores, el tamaño de la partición es de 0x011309A3 (18 024 867) sectores.
En el editor de sectores abrimos LBA 63.

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 7 Sector de arranque NTFS.

Según la información en el sector de arranque NTFS de la partición, se puede decir lo siguiente: el tamaño de sector registrado en el volumen es de 512 bytes (en el desplazamiento 0x0B se ha escrito la palabra 0x0200 (512)), el número de sectores en un clúster es igual a 8 (en el desplazamiento 0x0D se ha escrito el byte 0x08), el tamaño del clúster es de 512x8=4096 bytes, la primera entrada MFT está ubicada a un desplazamiento de 6 291 519 sectores desde el principio del disco (en el desplazamiento 0x30 se encuentra la palabra cuádruple 0x00 00 00 00 00 0C 00 00 (786 432) número del primer clúster MFT. El número de sector se calcula con la fórmula: Número de clúster * Número de sectores en el clúster + Desplazamiento hasta el inicio de la partición 786 432 * 8 + 63 = 6 291 519).
Procedemos al sector 6 291 519.

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 8

Pero los datos contenidos en este sector no se parecen en nada a una entrada MFT. Esto, aunque indica una posible traducción incorrecta debido a una lista de defectos errónea, no prueba este hecho. Para una verificación adicional, realizaremos la lectura del disco de 10 000 sectores en ambas direcciones en relación con el sector 6 291 519. Y luego realizaremos la búsqueda de expresiones regulares en lo leído.

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 9 Primera entrada MFT

En el sector 6 291 551 encontramos el primer registro MFT. Su posición difiere de la calculada en 32 sectores, y a continuación sigue un grupo de 16 registros (del 0 al 15). Anotaremos en la tabla de desplazamientos que la posición del sector 6 291 519 se debe mover hacia adelante 32 sectores.

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 10

La posición del registro n.º 16 debería estar en el desplazamiento 12 551 431, pero allí encontramos ceros, en lugar del registro MFT. Realizaremos una búsqueda similar en las cercanías.

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 11 Registro MFT 0x00000011 (17)

Se detecta un gran fragmento de MFT, que comienza con el registro número 17 y tiene una longitud de 53 646 registros, con un desplazamiento de 17 sectores. Para la posición 12 155 431, agregaremos un desplazamiento de +17 sectores en la tabla de desplazamientos.
Al determinar la posición de los fragmentos de MFT en el espacio, podemos concluir que esto no parece un fallo aleatorio, sino que los registros de fragmentos de MFT tienen desplazamientos incorrectos. La versión con el traductor incorrecto puede considerarse confirmada.
Para la posterior localización de los puntos de desplazamiento, estableceremos el desplazamiento máximo posible. Para ello, determinaremos cuánto se ha desplazado el marcador final de la partición NTFS (copia del sector de arranque). En la figura 7, en el desplazamiento 0x28, la palabra doble es el valor del tamaño de la partición 0x00 00 00 00 01 13 09 A2 (18 024 866) sectores. Sumaremos el desplazamiento de la partición desde el inicio del disco a su longitud, obteniendo el desplazamiento del marcador final NTFS: 18 024 866 + 63 = 18 024 929. Como era de esperar, no se encontró la copia necesaria del sector de arranque. Al buscar en las cercanías, fue descubierto con un desplazamiento creciente de +12 sectores respecto al último fragmento de MFT.

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 12 Copia del sector de arranque NTFS

Ignoramos otra copia del sector de arranque en el desplazamiento 18 041 006, ya que no tiene relación con nuestra partición. Con base en las actividades anteriores se ha determinado que dentro de la partición hay embebidos de 61 sectores que ‘emergieron’ en la traducción, lo que ha desplazado los datos.
Realizamos una lectura completa del dispositivo, cuyo resultado son 34 sectores no leídos. Lamentablemente, no se puede garantizar de manera fiable que todos ellos sean defectos eliminados de la P-list, pero en un análisis posterior es deseable tener en cuenta su posición, ya que en algunos casos se podrán determinar con precisión los puntos de desplazamiento hasta el sector, y no hasta el archivo.

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 13 Estadísticas de lectura del disco.

La siguiente tarea será establecer ubicaciones aproximadas de desplazamiento (con precisión al archivo en el que ocurrieron). Para ello, escanearemos todas las entradas del MFT y construiremos cadenas de ubicación de archivos (fragmentos de archivos).

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 14 Cadenas de ubicación de archivos, o sus fragmentos.

A continuación, moviéndonos de archivo a archivo, buscamos desde qué momento, en lugar del encabezado de archivo esperado, habrá otros datos, y el encabezado necesario se encontrará con algún desplazamiento positivo. A medida que afinamos los puntos de desplazamiento, completamos la tabla. El resultado de su llenado será más del 99% de archivos sin daños.

Camino de sufrimiento o la larga historia de un intento de recuperar datos.
Fig. 15 Lista de archivos personalizados (se obtuvo el consentimiento del cliente para publicar esta captura de pantalla)

Para establecer desplazamientos puntuales en archivos individuales, se pueden realizar trabajos adicionales y, conociendo la estructura del archivo, encontrar incrustaciones de datos que no le pertenecen. Pero en esta tarea no era económicamente viable.

P.D. Me gustaría también dirigirme a los colegas que tuvieron este disco anteriormente. Por favor, sean cuidadosos al trabajar con el microprograma de los dispositivos y respalden los datos de servicio antes de hacer cualquier cambio, y no contribuyan intencionalmente a agravar el problema si no han logrado llegar a un acuerdo con el cliente sobre la realización de trabajos.

Publicación anterior: Ahorrando en cerillas o recuperación de datos de un HDD Seagate ST3000NC002-1DY166 que chirría

Fuente: habr.com

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster