☰

Comprobación manual de integridad de la recuperación NTFS

tag-icon • tag-icon ntfs hard-drive-recovery file-recovery
Comprobación manual de integridad de la recuperación NTFS

Necesito que alguien, por favor, revise mi proceso de recuperación manual de NTFS hasta ahora porque me ha llevado a una pared de ladrillos.

Fondo:

  • Tenía un disco externo NTFS de 1 TB (WD Elements) que contenía principalmente fotografías.
  • De alguna manera, está dañado y aparece como un disco sin formato en Windows.
  • Aparece en un sistema Linux en los directorios /dev/disk/by-path(y by-id, by-uuidetc.) y aparece como /dev/sdb.
  • EaseUS puede encontrar (¿casi?) todas mis fotos allí con un escaneo rápido (no el escaneo profundo y pesado)
  • EaseUS encuentra alrededor de 70 GB de archivos (en su mayoría fotografías).
  • Creo que los registros NTFS están dañados, es decir, no se trata de un fallo mecánico.
  • Me gustaría intentar recuperarme por diversión y ganancias.
  • No tengo otra unidad lo suficientemente grande como para crear una imagen completa de la unidad dañada.

Necesito analizar los registros NTFS MFT $File porque:

  • Me gustaría recuperar los nombres de archivos y la estructura de directorios originales.
  • Si una imagen no está escrita en grupos contiguos, no la recuperaré con éxito simplemente buscando firmas de archivos de imágenes.

El plan es:

  1. Imagen de una parte del disco dañado.
  2. Analícelo para identificar y leer registros MFT $File.
  3. Utilice los registros $File (y específicamente su atributo $Data) para determinar las ejecuciones de datos de cada archivo.
  4. Al conocer los datos que se ejecutan para un archivo, puedo seleccionar los bytes de un archivo de la imagen que creé usando ddrescue.
  5. Enjuague y repita hasta que termine.

En primer lugar, ¿parece un plan razonable?

Qué he hecho:

  1. Encontré un montón de registros de $File
  2. Analizado uno para obtener las ejecuciones de datos.
  3. Lea los bytes sin procesar en la ubicación especificada por la ejecución de datos.

Específicamente:

  1. Se utiliza ddrescuepara crear imágenes de 100 GB (comenzando en 0) del disco dañado.
    1. Me imagino que casi todos los datos reales que necesito se escriben dentro de los primeros 100 GB, ya que el volumen total de datos interesantes es de 70 GB. Puedo repetir todo este proceso en porciones posteriores de 100 GB si es necesario.
    2. El comando que utilicé para crear imágenes de los primeros 100 GB fue ddrescue /dev/sdb ~/mydisk.img ~/mydisk.map --size=100G.
    3. ddrescueencontró errores de E/S e informó que solo se recuperó alrededor del 99,57%.
    4. El inicio de la imagen (los primeros 20 MB aproximadamente) parece vacío, por lo que este podría ser el motivo del fallo de la unidad. Lo estoy ignorando por ahora.
  2. Lea la imagen de 100 GB y localice todas las instancias de la cadena ASCII "FILE" que denota el inicio de un registro $File en el MFT.
    1. Esto también ha provocado falsos positivos, como la palabra "PERFIL" en medio de un archivo arbitrario.
    2. Por lo tanto, solo estoy considerando resultados donde la distancia entre una aparición de "ARCHIVO" y la siguiente es <= 1024 bytes, ya que ese es el tamaño máximo de registro MFT. Si hay 3 MB entre una aparición de "FILE" y la siguiente, es poco probable que sea un registro $File.
  3. Itere sobre los registros $File presuntos (tamaño <= 1024 bytes) y los atributos $Data extraídos.
  4. Lo analicé en busca de ejecuciones de datos (ignorando la discusión sobre atributos residentes versus no residentes que creo que entiendo pero no es parte de mi pregunta).

Así que realicé el proceso anterior, seleccioné uno de los registros de $File e identifiqué sus ejecuciones de datos. Aquí está el atributo $Data (encabezado y contenido):

80 00 00 00 48 00 00 00  01 00 00 00 00 00 01 00
00 00 00 00 00 00 00 00  FA 03 00 00 00 00 00 00
40 00 00 00 00 00 00 00  00 B0 3F 00 00 00 00 00
F4 AC 3F 00 00 00 00 00  F4 AC 3F 00 00 00 00 00
32 FB 03 ED C8 11 00 00  FF FF FF FF 82 79 47 11

Los detalles de la ejecución de datos son la primera mitad de la última fila, justo antes del FF FF FF FFfinal del marcador de atributo:

  • byte de longitud:32
  • número de ejecución del clúster: FB 03(little endian) = 1019 clústeres en la ejecución
  • número de inicio del clúster: ED C8 11= 1165549 es el primer clúster de la ejecución
  • el siguiente 00indica que no hay más carreras.

Ahora, considerando que hay 512 bytes por sector y 128 sectores por clúster, leo (1019 * 128 * 512) bytes de la imagen de 100 GB a partir de (1165549 * 128 * 512).

Desafortunadamente, eso me dejó con un archivo de 66,8 MB en su mayoría 0x00, aunque hacia el final había algunos datos. Estoy bastante seguro de que tengo algo mal y encontré algunos datos por accidente (aunque resulta que termino en un marcador de fin de archivo JPG (DD F9).

¿Es razonable mi enfoque para toda esta tarea y acabo de cometer un pequeño error en alguna parte?

¿O he entendido mal algo fundamental sobre NTFS y esta es una idea completamente equivocada?

Respuesta1

En primer lugar, ¿parece un plan razonable?

No. Quiero decir, no analicé en profundidad su método para las ejecuciones de decodificación, pero los clústeres de inicio son relativos al inicio del sistema de archivos (= inicio del volumen/partición cuando hablamos de NTFS). Entonces, cualquier entrada de MFT que apunte a un número de clúster, apunta al número de clúster en relación con el inicio de la partición, no en relación con su parte arbitraria de 100 MB del volumen.

Además, MFT es "autorreferenciado", por lo que lo primero que debe intentar es encontrar el inicio de MFT del que luego pueda derivar.todoEntradas MFT. Si no puede encontrar el inicio de MFT, intente ubicar el espejo de MFT.

Entonces, para decodificar correctamente una entrada MFT y obtener los datos a los que hace referencia, necesitamos:

  • Desplazamiento al inicio de la partición.
  • Tamaño de clúster correcto

Entonces, si decodificamos el clúster inicial, podemos hacer: (nº de clúster * sectores/clúster) + partición compensada

¿Cómo determinaste 128 sectores por grupo? ¡Esto no me parece nada correcto! Vea los valores predeterminados aquí:https://www.disktuna.com/default-cluster-sizes-for-fat-exfat-and-ntfs/.

Respuesta2

No es profesional exponer un disco dañado a la carga de lectura que describió. El primer requisito es duplicar esa unidad a una estable y saludable para evitar la pérdida de sectores adicionales y ya no tener sectores ilegibles. El hecho de que los sectores ilegibles no se puedan copiar es triste, pero la clave es evitar que usted o un programa de recuperación manejen los errores de lectura.

Es muy posible que sus intentos de recuperación ya hayan causado daños adicionales en esa unidad.

Como las estructuras de metadatos y los datos no están necesariamente dispuestos de manera lineal, no se puede compensar la falta de poseer al menos una unidad que sea lo suficientemente grande leyendo posteriormente porciones de 100 GB en algún lugar del almacenamiento libre en otro lugar. Necesitas acceso aleatorio. Desafortunadamente, en su caso, una vez que una estructura apunta a su siguiente segmento de 100 GB, debe vaciar su área de almacenamiento de 100 GB.

Si ya está analizando estructuras en su lenguaje de programación preferido, no es necesario ejecutar comandos Unix como dd para el trabajo de copia. ddrescue es necesario solo una vez al comienzo de su intento de recuperación.

Si solo desea aprender los aspectos internos de NTFS, está bien y es algo interesante, pero ya puede aprenderlo en un almacenamiento como memorias USB. No son necesarios grandes viajes.

Piense por qué Easeus no recuperó los metadatos deseados, como nombres de archivos y estructuras de carpetas.

Respuesta3

Pensé que las unidades eran lineales comenzando en el byte 0 del sector 0 del grupo 0 y llegando hasta el final de la unidad física.

Si y no. Las direcciones de almacenamiento son lineales, comenzando con el byte 0. Las direcciones de sector también son lineales.

Las direcciones de los clústeres son lineales y comienzan con el número de clúster cero, pero solo en relación con su partición respectiva. No hay un etiquetado de clúster para todo el disco, solo un etiquetado de clúster para toda la partición que comienza desde cero.

¿Estás diciendo que, si uso una herramienta como ddrescue para leer los bytes 0 - 1000000, no debería esperar haber leído los metadatos NTFS que describen el diseño?

Los metadatos NTFS involucran no solo el sector de arranque sino también la tabla de archivos maestros y otros archivos. Al leer 1 MByte desde el inicio de la unidad, solo leerá una fracción de la tabla de archivos maestros, siempre que se encuentre allí. Su posición no es fija y es probable que cambie tras la desfragmentación.

Utilice la estrategia para experimentar y aprender sobre su sistema de archivos aquí: https://forum.cgsecurity.org/phpBB3/viewtopic.php?p=31304#p31304

Al intentar descifrar NTFS, es mucho mejor que ya conozca el resultado previsto. Es una especie de proceso de descifrado, como un "ataque de texto sin formato conocido", en el que se conoce todo el texto sin formato.

Alguien acaba de rechazar mis respuestas. Si ese fuera usted, explique el motivo. ¿Hay algún error en alguna parte? ¡Me gustaría saber! Gracias.

información relacionada