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

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

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

Рис. 1 HDD Quantum Fireball Plus KA 9,1Гб
Первым делом пришлось потрудиться с поиском в донорском архиве столь древнего брата-близнеца этого накопителя с исправной платой контроллера. Когда этот квест был пройден, то стало возможным произвести развернутые диагностические мероприятия. Проверив обмотки двигателя на короткое замыкание и убедившись в его отсутствии, устанавливаем плату с накопителя – донора на накопитель – пациент. Подаем питание и слышим нормальный звук раскрутки вала, прохождение калибровочного теста с загрузкой микропрограммы, и через несколько секунд накопитель по регистрам рапортует о готовности реагировать на команды со стороны интерфейса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 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

Рис. 8

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

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

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

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

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

Рис. 10

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

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

Рис. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

Let’s block ads! (Why?)

Читайте также:

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

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