Хождение по мукам или долгая история одной попытки восстановления данных

На дворе стоял 2019 год. В нашу лабораторию поступил не совсем обычный для нашего времени накопитель QUANTUM FIREBALL Plus KA емкостью 9.1Гб. Со слов владельца накопителя отказ случился в далеком 2004 году по вине вышедшего из строя блока питания, который прихватил за собой жесткий диск и другие компоненты ПК. Далее были хождения по различным сервисам с попытками отремонтировать накопитель и восстановить данные, которые не увенчались успехом. Где-то обещали дешево, но так и не решили проблему, где-то слишком дорого и клиент не пожелал восстанавливать данные, но в итоге диск прошел путь через множество сервисных центров. Неоднократно терялся, но благодаря тому, что владелец заблаговременно позаботился о записи информации с различных наклеек на накопителе ему удалось добиться, чтобы именно его жесткий диск был возвращен из некоторых сервисных центров. Хождения не прошли бесследно, на оригинальной плате контроллера остались множественные следы пайки, а также визуально ощущался недостаток SMD элементов (забегая вперед скажу, что это наименьшая из проблем этого накопителя).

Рис. 1 HDD Quantum Fireball Plus KA 9,1Гб

Первым делом пришлось потрудиться с поиском в донорском архиве столь древнего брата-близнеца этого накопителя с исправной платой контроллера. Когда этот квест был пройден, то стало возможным произвести развернутые диагностические мероприятия. Проверив обмотки двигателя на короткое замыкание и убедившись в его отсутствии, устанавливаем плату с накопителя – донора на накопитель – пациент. Подаем питание и слышим нормальный звук раскрутки вала, прохождение калибровочного теста с загрузкой микропрограммы, и через несколько секунд накопитель по регистрам рапортует о готовности реагировать на команды со стороны интерфейса.

Рис. 2 Индикаторы DRD DSC означают готовность к принятию команд.

Резервируем все копии модулей микропрограммы. Выполняем проверку целостности модулей микропрограммы. С чтением модулей каких-либо проблем не возникает, но анализ отчетов показывает, что есть некоторые странности.

Рис. 3. Таблица зон.

Обращаем внимание на таблицу зонного распределения, замечаем, что количество цилиндров равно 13845.

Рис. 4 P-list (primary list – список дефектов, внесенных в процессе производственного цикла).

Обращаем внимание на слишком малое количество дефектов и их локализацию. Просматриваем модуль лог скрытия заводских дефектов (60h) и обнаруживаем, что он пуст и не содержит ни одной записи. На основании этого можем предполагать, что в каком-то из предыдущих сервисных центров, возможно, проделывались некие манипуляции со служебной зоной накопителя, и случайно или намеренно был записан чужой модуль, либо подчищен список дефектов в оригинальном. Для проверки этого предположения создаем задачу в Data Extractor с включенными опциями «создание посекторной копии» и «создание виртуального транслятора».

Рис. 5 Параметры задачи.

Создав задачу, просматриваем записи в таблице разделов в нулевом секторе (LBA 0)

Рис. 6 Главная загрузочная запись и таблица разделов.

По смещению 0x1BE находится единственная запись (16 байт). Тип файловой системы на разделе — NTFS, смещение до начала 0x3F (63) сектора, размер раздела 0x011309A3 (18 024 867) секторов.
В редакторе сектора открываем LBA 63.

Рис. 7 Загрузочный сектор NTFS

По информации в загрузочном секторе NTFS раздела можно сказать следующее: размер сектора, принятый в томе, 512 байт (по смещению 0x0B записано слово 0x0200 (512)), количество секторов в кластере равно 8 (по смещению 0x0D записан байт 0x08), размер кластера равен 512х8=4096 байт, первая запись MFT расположена по смещению 6 291 519 секторов от начала диска (по смещению 0x30 учетверенное слово 0x00 00 00 00 00 0C 00 00 (786 432) номер первого кластера MFT. Номер сектора вычисляется по формуле: Номер кластера * количество секторов в кластере + смещение до начала раздела 786 432* 8+63= 6 291 519).
Переходим к сектору 6 291 519.

Рис. 8

Но данные содержащиеся в этом секторе совершенно не похожи на запись MFT. Это хоть и указывает на возможную неправильную трансляцию из-за некорректного дефект-листа, но не доказывает этот факт. Для дальнейшей проверки проведем чтение диска по 10 000 секторов в обоих направлениях относительно 6 291 519 сектора. И после проведем поиск регулярных выражений в прочитанном.

Рис. 9 Первая запись MFT

В секторе 6 291 551 обнаруживаем первую запись MFT. Ее положение от расчетного отличается на 32 сектора, и далее непрерывно следует группа из 16 записей (от 0 до 15). Впишем в таблицу сдвигов положение сектора 6 291 519 сдвинуть вперед на 32 сектора.

Рис. 10

Положение записи №16 должно быть по смещению 12 551 431, но там обнаруживаем нули, вместо записи MFT. Проведем аналогичный поиск в окрестностях.

Рис. 11 Запись MFT 0x00000011 (17)

Обнаруживается крупный фрагмент MFT, начинающийся с записи под номером 17 протяженностью 53 646 записей) со сдвигом в 17 секторов. Для позиции 12 155 431 поставим сдвиг +17 секторов в таблицу сдвигов.
Определив положение фрагментов MFT в пространстве можем сделать вывод, что это не похоже на случайный сбой и запись фрагментов MFT по некорректным смещениям. Версию с некорректным транслятором можно считать подтвержденной.
Для дальнейшей локализации точек сдвигов установим максимально возможное смещение. Для этого определим, насколько сдвинут конечный маркер NTFS раздела (копия загрузочного сектора). На рисунке 7 по смещению 0x28 четверное слово — это значение размера раздела 0x00 00 00 00 01 13 09 A2 (18 024 866) секторов. Прибавим смещение самого раздела от начала диска к его длине получим смещение конечного маркера NTFS 18 024 866 + 63= 18 024 929. Ожидаемо там не оказалось нужной копии загрузочного сектора. При поиске в окрестностях он был обнаружен с нарастающим сдвигом в +12 секторов по отношению к последнему фрагменту MFT.

Рис. 12 Копия загрузочного сектора NTFS

Другую копию загрузочного сектора по смещению 18 041 006 игнорируем, так как она не имеет отношения к нашему разделу. На основании предыдущих мероприятий установлено, что внутри раздела имеются вкрапления из «всплывших» в трансляции 61 сектора, которые раздвинули данные.
Выполняем полное чтение накопителя, результатом которого остается 34 непрочитанных сектора. К сожалению, достоверно гарантировать, что все они являются дефектами, удаленными из P-list невозможно, но при дальнейшем анализе желательно учитывать их положение, так как в некоторых случаях можно будет достоверно определять точки сдвига с точностью до сектора, а не до файла.

Рис. 13 Статистика чтения диска.

Следующей нашей задачей будет установить ориентировочные места сдвигов (с точностью до файла, в котором они возникли). Для этого проведем сканирование всех записей MFT и построим цепочки расположения файлов (фрагментов файлов).

Рис. 14 Цепочки расположения файлов, либо их фрагментов.

Далее, двигаясь от файла к файлу, ищем, с какого момента вместо ожидаемого заголовка файла будут иные данные, а нужный заголовок обнаружится с неким положительным сдвигом. И по мере уточнения точек сдвигов заполняем таблицу. Результатом ее заполнения будет свыше 99% файлов без повреждений.

Рис. 15 Список пользовательских файлов (от клиента получено согласие на публикацию этого скриншота)

Для установления точечных сдвигов в отдельных файлах можно провести дополнительные работы и при знании структуры файла найти вкрапления данных, не относящихся к нему. Но в данной задаче это не было экономически целесообразно.

P.S. Хотелось бы также обратиться к коллегам, в чьих руках этот диск побывал ранее. Пожалуйста, будьте внимательны при работе с микропрограммой устройств и резервируйте служебные данные прежде, чем что-то изменить, а также не допускайте намеренного усугубления проблемы, если вам не удалось договориться с клиентом о выполнении работ.

Предыдущая публикация: Экономия на спичках или восстановление данных из скрежещущего HDD Seagate ST3000NC002-1DY166

Источник: habr.com