В двора беше 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 (първичен списък – списък на дефектите, въведени в процеса на производствения цикъл).
Обърнете внимание на твърде малкия брой дефекти и тяхната локализация. Преглеждаме модула за лог скриване на фабричните дефекти (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. Бих искал също да се обърна към колегите, които преди това са работили с този диск. Моля, внимавайте при работа с микропрограмите на устройството и резервирайте служебните данни, преди да промените нещо, както и не допускайте умишлено влошаване на проблема, ако не сте успели да се споразумеете с клиента за извършването на работите.
Източник: habr.com
