Хабрахабр

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

На дворе стоял 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 Главная загрузочная запись и таблица разделов.

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

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

Номер сектора вычисляется по формуле: Номер кластера * количество секторов в кластере + смещение до начала раздела 786 432* 8+63= 6 291 519).
Переходим к сектору 6 291 519. По информации в загрузочном секторе 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.

Рис. 8

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

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

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

Рис. 10

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть