Ручная проверка работоспособности восстановления NTFS

Question

Мне нужен кто-нибудь, кто мог бы проверить на предмет здравомыслия мой процесс ручного восстановления NTFS, поскольку он завел меня в тупик.

Фон:

• У меня был внешний диск NTFS емкостью 1 ТБ (WD Elements), на котором в основном хранились фотографии.
• Каким-то образом он поврежден и отображается в Windows как необработанный диск.
• В системе Linux он появляется в каталогах /dev/disk/by-path(и by-idи by-uuidт. д.) и выглядит как /dev/sdb.
• EaseUS может найти (почти?) все мои фотографии там с помощью быстрого сканирования (а не трудоемкого глубокого сканирования)
• EaseUS находит около 70 ГБ файлов (в основном фотографии).
• Я думаю, что записи NTFS повреждены, т.е. это не механическая неисправность.
• Я хотел бы попробовать восстановиться сам, ради развлечения и выгоды.
• У меня нет другого диска достаточно большого размера, чтобы сделать полный образ поврежденного диска.

Мне необходимо проанализировать записи NTFS MFT $File, потому что:

• Я хотел бы вернуть исходные имена файлов и структуру каталогов.
• Если изображение не записано в смежных кластерах, я не смогу успешно восстановить его, просто просматривая сигнатуры файлов изображений.

План таков:

1. Создайте изображение части поврежденного диска.
2. Проанализируйте его, чтобы идентифицировать и прочитать записи MFT $File.
3. Используйте записи $File (и, в частности, их атрибут $Data) для определения последовательностей данных каждого файла.
4. Зная, что данные запускаются для файла, я могу извлечь байты файла из образа, который я создал с помощью ddrescue.
5. Промойте и повторяйте, пока не закончите.

Во-первых, звучит ли это как разумный план?

Что я наделал:

1. Нашел кучу записей $File
2. Проанализировал один, чтобы получить данные.
3. Считайте необработанные байты в месте, указанном в потоке данных.

Конкретно:

1. Используется ddrescueдля создания образа 100 ГБ (начиная с 0) поврежденного диска.
   1. Я полагаю, что почти все фактические данные, которые мне нужны, записаны в пределах первых 100 ГБ, поскольку общий объем интересных данных составляет 70 ГБ. Я могу повторить весь этот процесс для последующих частей по 100 ГБ, если это необходимо.
   2. Команда, которую я использовал для создания образа первых 100 ГБ, была ddrescue /dev/sdb ~/mydisk.img ~/mydisk.map --size=100G.
   3. ddrescueобнаружил ошибки ввода-вывода и сообщил, что удалось восстановить только около 99,57%.
   4. Начало образа (первые 20 МБ или около того) кажется пустым, так что это может быть причиной сбоя привода. Я пока это игнорирую.
2. Прочитал изображение размером 100 ГБ и обнаружил все вхождения строки ASCII «FILE», которая обозначает начало записи $File в MFT.
   1. Это также приводило к ложным срабатываниям, таким как слово «ПРОФИЛЬ» в середине произвольного файла.
   2. Поэтому я рассматриваю только те результаты, где расстояние между одним вхождением "FILE" и следующим <= 1024 байт, поскольку это максимальный размер записи MFT. Если между одним вхождением "FILE" и следующим 3 МБ, то вряд ли это будет запись $File.
3. Выполнить итерацию по предполагаемым записям $File (размер <= 1024 байт) и извлеченным атрибутам $Data.
4. Проанализировал его на предмет прогонов данных (игнорируя обсуждение резидентных и нерезидентных атрибутов, которое, как мне кажется, я понимаю, но оно не является частью моего вопроса).

Итак, я выполнил описанный выше процесс, выбрал одну из записей $File и определил ее прогоны данных. Вот атрибут $Data (заголовок и содержимое):

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

Подробная информация о запуске данных находится в первой половине последней строки, непосредственно перед FF FF FF FFконцом маркера атрибута:

• Длина байта:32
• номер прогона кластера: FB 03(прямой порядок байтов) = 1019 кластеров в прогоне
• Начальный номер кластера: ED C8 11= 1165549 — первый кластер в прогоне
• следующий 00указывает на то, что больше нет запусков.

Теперь, учитывая, что на сектор приходится 512 байт, а на кластер — 128 секторов, я прочитал (1019 * 128 * 512) байт из образа объемом 100 ГБ, начиная с (1165549 * 128 * 512).

К сожалению, это оставило мне файл размером 66,8 МБ, состоящий в основном из 0x00, хотя ближе к концу были некоторые данные. Я почти уверен, что я что-то сделал не так, и я просто случайно нашел некоторые данные (хотя я действительно заканчиваю на маркере конца файла JPG (DD F9).

Разумный ли у меня подход к этой задаче и не допустил ли я где-то небольшую ошибку?

Или я неправильно понял что-то фундаментальное в NTFS и это совершенно неверная идея?

Answer 1

Во-первых, звучит ли это как разумный план?

Нет. Я имею в виду, что я не изучал подробно ваш метод декодирования запусков, но начальные кластеры относятся к началу файловой системы (= началу тома/раздела, когда мы говорим о NTFS). Поэтому любая запись MFT, которая указывает на номер кластера, указывает на номер кластера относительно начала раздела, а не относительно вашей произвольной части тома размером 100 МБ.

Кроме того, MFT является «самостоятельно ссылающейся», поэтому первое, что нужно попробовать, это найти начало MFT, из которого затем можно вывестивсеЗаписи MFT. Если вы не можете найти начало MFT, попробуйте найти зеркало MFT.

Итак, чтобы правильно расшифровать запись MFT и получить данные, на которые она ссылается, нам необходимо:

• Смещение к началу раздела.
• Правильный размер кластера

Итак, если мы декодируем начальный кластер, мы можем сделать: (номер кластера * секторы / кластер) + смещение раздела

Как вы определили 128 секторов на кластер? Это вообще не похоже на правду! Смотрите значения по умолчанию здесь:https://www.disktuna.com/default-cluster-sizes-for-fat-exfat-and-ntfs/.

Answer 2

Непрофессионально подвергать поврежденный диск нагрузке чтения, которую вы описали. Первое требование — дублировать этот диск на стабильный здоровый, чтобы избежать потери дополнительных секторов и больше не иметь нечитаемых секторов. Тот факт, что нечитаемые секторы не могут быть скопированы, печально, но ключ в том, чтобы избежать вас или программы восстановления для обработки ошибок чтения.

Ваши попытки восстановления вполне могли уже нанести дополнительный ущерб этому диску.

Поскольку структуры метаданных и данные не обязательно располагаются линейно, вы не можете компенсировать отсутствие хотя бы одного достаточно большого диска, последовательно считывая 100-гигабайтные срезы где-то в свободное дисковое хранилище в другом месте. Вам нужен произвольный доступ. К сожалению, в вашем случае, как только структура указывает на ваш следующий 100-гигабайтный срез, вам придется очистить область хранения 100 ГБ.

Если вы уже анализируете структуры на предпочитаемом вами языке программирования, нет необходимости запускать команды unix, такие как dd, для задания копирования. ddrescue требуется только один раз в начале попытки восстановления.

Если вы просто хотите изучить внутренности NTFS, это нормально и круто, но вы можете изучить это уже на хранилищах, таких как USB-накопители. Большие диски не нужны.

Пожалуйста, подумайте, по какой причине Easeus не восстановил нужные вам метаданные, такие как имена файлов и структуры папок.

Answer 3

Я думал, что диски линейны, начиная с байта 0 сектора 0 кластера 0 и до конца физического диска.

И да, и нет. Адреса хранения линейны, начинаются с байта 0. Адреса секторов также линейны.

Адреса кластеров линейны и начинаются с нулевого номера кластера, но только относительно соответствующего им раздела. Маркировка кластера на весь диск отсутствует, есть только маркировка кластера на весь раздел, начинающаяся с нуля.

Вы хотите сказать, что если я использую такой инструмент, как ddrescue, для чтения байтов 0 - 1000000, мне не следует ожидать, что я прочитаю метаданные NTFS, описывающие структуру?

Метаданные NTFS включают в себя не только загрузочный сектор, но и главную файловую таблицу и другие файлы. При чтении 1 Мбайта с начала диска вы прочтете только часть главной файловой таблицы, если она там находится. Ее положение не фиксировано и, скорее всего, изменится при дефрагментации.

Используйте эту стратегию для экспериментов и изучения своей файловой системы здесь: https://forum.cgsecurity.org/phpBB3/viewtopic.php?p=31304#p31304

При попытке расшифровать NTFS вы гораздо лучше знаете предполагаемый результат. Это своего рода процесс расшифровки, а не "атака с известным открытым текстом", где вы знаете весь открытый текст.

Кто-то только что поставил минус моим ответам. Если это вы, пожалуйста, объясните причину. Где-то ошибка? Я хотел бы знать! Спасибо.