На двора стоеше 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), размерът на кластер е 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 с дължина 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-списъка, но при по-нататъшен анализ е желателно да се вземе предвид тяхното положение, тъй като в някои случаи може да бъде надеждно да се определят точките на разместване с точност до сектор, а не до файл.
Рис. 13 Статистика на четенето на диска.
Следващата ни задача е да установим ориентировъчните места на сдвигите (с точност до файла, в който са възникнали). За целта ще сканираме всички записи в MFT и ще изградим вериги на местоположението на файловете (фрагментите на файловете).
Рис. 14 Вериги на местоположението на файловете или техните фрагменти.
След това, преминавайки от файл на файл, търсим от кой момент вместо очаквания заглавен файл ще има други данни, а нужният заглавен файл ще се открие с някакъв положителен сдвиг. И с течение на уточняването на точките на сдвиг запълваме таблицата. Резултатът от попълването ще бъде над 99% файлове без повреди.
Рис. 15 Списък на потребителските файлове (от клиента получено съгласие за публикуване на този екранен снимка)
За установяване на точкови сдвигове в отделни файлове могат да се проведат допълнителни работи и при познаване на структурата на файла може да се открият вкрапвания на данни, които не му принадлежат. Но в този случай това не беше икономически целесъобразно.
P.S. Бих искал също да се обърна към колегите, които преди това са работили с този диск. Моля, бъдете внимателни при работа с микропрограмите на устройствата и запазвайте служебните данни преди да направите каквито и да е промени, а също така не допускайте умишлено влошаване на проблема, ако не успеете да уговорите с клиента извършването на работа.
Източник: habr.com
