Это был 2019 год. В нашу лабораторию поступил не совсем обычный для нашего времени накопитель QUANTUM FIREBALL Plus KA емкостью 9,1ГБ.
По словам владельца накопителя, поломка произошла еще в 2004 году из-за вышедшего из строя блока питания, унесшего с собой жесткий диск и другие комплектующие ПК.
Потом были посещения различных сервисов с попытками отремонтировать накопитель и восстановить данные, которые не увенчались успехом.
В каких-то случаях обещали, что будет дешево, но проблему так и не решили, в других — слишком дорого и клиент не хотел восстанавливать данные, но в итоге диск прошел через множество сервисных центров.
Он несколько раз терялся, но благодаря тому, что владелец заранее позаботился о записи информации с различных наклеек на накопитель, ему удалось добиться возврата его жесткого диска из некоторых сервисных центров.
Прогулки не прошли бесследно, на оригинальной плате контроллера остались множественные следы пайки, а также визуально чувствовалось отсутствие SMD-элементов (забегая вперед, скажу, что это наименьшая из проблем данного накопителя).
Рис.
1 жесткий диск Quantum Fireball Plus KA 9,1 ГБ Первым делом нам пришлось искать в донорском архиве столь древнего брата-близнеца этого накопителя с рабочей платой контроллера.
Когда этот квест был завершен, стало возможным проведение обширных диагностических мероприятий.
Проверив обмотки двигателя на короткое замыкание и убедившись в отсутствии короткого замыкания, устанавливаем плату с привода донора на привод пациента.
Подаем питание и слышим нормальный звук раскручивания вала, проходим калибровочный тест с загрузкой прошивки, и через несколько секунд привод регистрами сообщает, что готов реагировать на команды интерфейса.
Рис.
2 индикатора DRD DSC указывают на готовность к приему команд. Делаем резервные копии всех копий модулей прошивки.
Проверяем целостность модулей прошивки.
С чтением модулей проблем нет, но анализ отчетов показывает, что есть некоторые странности.
Рис.
3. Таблица зон.
Обращаем внимание на таблицу зонального распределения и отмечаем, что количество цилиндров равно 13845. 
Рис.
4 П-список (первичный список – список дефектов, возникших в ходе производственного цикла).
Обращаем внимание на слишком малое количество дефектов и их расположение.
Смотрим модуль журнала скрытия заводского дефекта (60h) и обнаруживаем, что он пуст и не содержит ни одной записи.
Исходя из этого, можно предположить, что в одном из предыдущих сервисных центров могли быть произведены какие-то манипуляции с служебной зоной накопителя, и случайно или намеренно был написан чужой модуль, либо список дефектов в исходный был очищен.
Чтобы проверить это предположение, мы создаем задачу в Data Extractor с включенными опциями «создать посекторную копию» и «создать виртуальный транслятор».
Рис.
5 Параметры задачи.
Создав задачу, смотрим записи таблицы разделов в нулевом секторе (LBA 0) 
Рис.
6 Основная загрузочная запись и таблица разделов.
По смещению 0x1BE находится одна запись (16 байт).
Тип файловой системы на разделе — NTFS, смещение начала секторов 0x3F (63), размер раздела 0x011309A3 (18 024 867) секторов.
В редакторе секторов откройте LBA 63. 
Рис.
7 загрузочный сектор NTFS По информации в загрузочном секторе NTFS-раздела можно сказать следующее: размер сектора, принятый в томе, равен 512 байт (слово 0x0200(512) записано по смещению 0x0B), количество секторов в кластере равно 8 (байт 0x08 записан по смещению 0x0D), размер кластера 512x8=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 длиной 53646 записей) со сдвигом на 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 непрочитанных сектора.
К сожалению, невозможно достоверно гарантировать, что все они являются дефектами, удаленными из П-списка, но при дальнейшем анализе целесообразно учитывать их положение, так как в ряде случаев можно будет достоверно определить точки сдвига с помощью точность сектора, а не файла.
Рис.
13 Статистика чтения диска.
Нашей следующей задачей будет установление примерных мест сдвигов (с точностью до файла, в котором они произошли).
Для этого мы просканируем все записи MFT и построим цепочки расположений файлов (фрагментов файлов).
Рис.
14 Цепочки расположения файлов или их фрагментов.
Далее, переходя от файла к файлу, ищем момент, в который вместо ожидаемого заголовка файла будут другие данные, и нужный заголовок будет найден с определенным положительным сдвигом.
И по мере уточнения точек переключения заполняем таблицу.
Результатом его заполнения будет более 99% файлов без повреждений.
Рис.
15 Список пользовательских файлов (от клиента получено согласие на публикацию этого скриншота) Для установления сдвигов точек в отдельных файлах можно провести дополнительную работу и, если известна структура файла, найти включения не связанных с ним данных.
Но в данной задаче это было экономически нецелесообразно.
P.S. Я также хотел бы обратиться к моим коллегам, в чьих руках ранее находился этот диск.
Пожалуйста, будьте внимательны при работе с прошивкой устройства и делайте резервное копирование сервисных данных, прежде чем что-либо менять, и не усугубляйте намеренно проблему, если вам не удалось договориться с клиентом о работе.
Следующая публикация: Самодиагностика жестких дисков и восстановление данных Предыдущая публикация: экономия на спичках или восстановление данных с притертого HDD Seagate ST3000NC002-1DY166 Теги: #Системное администрирование #Резервное копирование #Хранение данных #HDD #Восстановление данных #восстановление #жесткий диск #данные #fireball #информация #Quantum #переводчик
-
Google Analytics И Азербайджан
19 Oct, 24 -
Control, Trackbar, Но С Двумя Ползунками
19 Oct, 24
