Беше 2019 г. Нашата лаборатория получи устройство QUANTUM FIREBALL Plus KA с капацитет от 9.1 GB, което не е съвсем обичайно за нашето време. Според собственика на устройството повредата е възникнала през 2004 г. поради повреда в захранването, което отнесло твърдия диск и други компоненти на компютъра със себе си. След това имаше посещения в различни услуги с опити за ремонт на устройството и възстановяване на данни, които бяха неуспешни. В някои случаи обещаваха, че ще е евтино, но така и не решиха проблема, в други беше твърде скъпо и клиентът не искаше да възстанови данните, но в крайна сметка дискът премина през много сервизи. Той беше загубен няколко пъти, но благодарение на факта, че собственикът се погрижи предварително да запише информация от различни стикери на устройството, той успя да осигури връщането на твърдия му диск от някои сервизни центрове. Разходките не минаха без следа, на оригиналната платка на контролера останаха множество следи от запояване, а липсата на SMD елементи също се усети визуално (гледайки напред, ще кажа, че това е най-малкият проблем на това устройство).
Ориз. 1 HDD Quantum Fireball Plus KA 9,1GB
Първото нещо, което трябваше да направим, беше да потърсим в архива на донора такъв древен брат близнак на този диск с работеща контролна платка. Когато това търсене беше завършено, стана възможно да се извършат обширни диагностични мерки. След като проверихме намотките на двигателя за късо съединение и се уверихме, че няма късо съединение, монтираме платката от донорното задвижване към задвижването на пациента. Прилагаме мощност и чуваме нормалния звук на въртене на вала, преминаване на тест за калибриране със зареждане на фърмуера и след няколко секунди устройството съобщава чрез регистри, че е готово да отговори на команди от интерфейса.
Ориз. 2 DRD DSC индикатора показват готовност за получаване на команди.
Архивираме всички копия на фърмуерните модули. Проверяваме целостта на модулите на фърмуера. Няма проблеми с модулите за четене, но анализът на отчетите показва, че има някои странности.
Ориз. 3. Зонова маса.
Обръщаме внимание на таблицата за зонално разпределение и отбелязваме, че броят на цилиндрите е 13845.
Ориз. 4 P-списък (първичен списък – списък на дефектите, въведени по време на производствения цикъл).
Обръщаме внимание на твърде малкия брой дефекти и тяхното местоположение. Разглеждаме модула за регистриране на фабричните дефекти (60h) и откриваме, че той е празен и не съдържа нито един запис. Въз основа на това можем да предположим, че в някой от предишните сервизни центрове може да са извършени някои манипулации със сервизната зона на устройството и случайно или умишлено е написан чужд модул или списъкът с дефекти в оригинала единият беше изчистен. За да тестваме това предположение, създаваме задача в Data Extractor с активирани опции „създаване на копие сектор по сектор“ и „създаване на виртуален преводач“.
Ориз. 5 Параметри на задачата.
След като създадем задачата, разглеждаме записите в таблицата на дяловете в сектор нула (LBA 0)
Ориз. 6 Главен зареждащ запис и таблица на дяловете.
При отместване 0x1BE има единичен запис (16 байта). Типът файлова система на дяла е NTFS, отместване към началото на 0x3F (63) сектора, размер на дяла 0x011309A3 (18 024 867) сектора.
В секторния редактор отворете LBA 63.
Ориз. 7 NTFS зареждащ сектор
Според информацията в сектора за зареждане на NTFS дяла можем да кажем следното: размерът на сектора, приет в тома, е 512 байта (думата 0x0 (0) е записана при отместване 0200x512B), броят на секторите в клъстера е 8 (байт 0x0 е записан при отместване 0x08D), размерът на клъстера е 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.
Фиг. 8
Но данните, съдържащи се в този сектор, са напълно различни от MFT записа. Въпреки че това показва възможен неправилен превод поради неправилен списък с дефекти, това не доказва този факт. За допълнителна проверка ще прочетем диска по 10 000 сектора в двете посоки спрямо 6 291 519 сектора. И тогава ще търсим регулярни изрази в това, което четем.
Ориз. 9 Първи MFT запис
В сектор 6 291 551 намираме първия MFT запис. Неговата позиция се различава от изчислената с 32 сектора, след което непрекъснато следва група от 16 записа (от 0 до 15). Нека въведем позицията на сектор 6 в таблицата за преместване и да се придвижим напред с 291 сектора.
Фиг. 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 Списък с потребителски файлове (получено е съгласие от клиента за публикуване на тази екранна снимка)
За да установите изместване на точки в отделни файлове, можете да извършите допълнителна работа и, ако знаете структурата на файла, да намерите включвания на данни, които не са свързани с него. Но в тази задача не беше икономически осъществимо.
PS Бих искал да се обърна и към моите колеги, в чиито ръце беше този диск преди това. Моля, бъдете внимателни, когато работите с фърмуера на устройството и архивирайте сервизните данни, преди да промените нещо, и не умишлено влошавайте проблема, ако не сте успели да се споразумеете с клиента относно работата.
Източник: www.habr.com