Надворі стояв 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 (primary list – список дефектів, внесених у процесі виробничого циклу).
Звертаємо увагу на занадто малу кількість дефектів та їх локалізацію. Переглядаємо модуль лог приховування заводських дефектів (60h) і виявляємо, що він порожній і не містить жодного запису. На підставі цього можемо припускати, що в якомусь із попередніх сервісних центрів, можливо, робилися деякі маніпуляції зі службовою зоною накопичувача, і випадково чи навмисно було записано чужий модуль, чи підчищено список дефектів в оригінальному. Для перевірки цього припущення створюємо завдання Data Extractor з включеними опціями «створення посекторної копії» і «створення віртуального транслятора».
Мал. 5 Параметри завдання.
Створивши завдання, переглядаємо записи у таблиці розділів у нульовому секторі (LBA 0)
Мал. 6 Головний завантажувальний запис та таблиця розділів.
За зміщенням 0x1BE знаходиться єдиний запис (16 байт). Тип файлової системи на розділі - NTFS, зміщення до початку 0x3F (63) сектора, розмір розділу 0x011309A3 (18) секторів.
У редакторі сектора відкриваємо 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) номер першого кластера M. кількість секторів у кластері + зміщення на початок розділу 786 432* 8+63= 6 291 519).
Переходимо до сектора 6.
Рис. 8
Але дані, що містяться в цьому секторі, абсолютно не схожі на запис MFT. Це хоч і вказує на можливу неправильну трансляцію через некоректний дефект-лист, але не доводить цей факт. Для подальшої перевірки проведемо читання диска по 10 000 секторів в обох напрямках щодо 6 секторів. І потім проведемо пошук регулярних виразів у прочитаному.
Мал. 9 Перший запис MFT
У секторі 6 виявляємо перший запис MFT. Її положення від розрахункового відрізняється на 291 сектори, і далі безперервно слідує група з 551 записів (від 32 до 16). Впишемо в таблицю зрушень положення сектора 0 зрушити вперед на 15 сектори.
Рис. 10
Положення запису №16 має бути зі зміщенням 12 551 431, але там виявляємо нулі замість запису MFT. Проведемо аналогічний пошук на околицях.
Мал. 11 Запис MFT 0x00000011 (17)
Виявляється великий фрагмент MFT, що починається з запису під номером 17 довжиною 53 записів) зі зсувом в 646 секторів. Для позиції 17 поставимо зсув +12 секторів в таблицю зрушень.
Визначивши положення фрагментів MFT у просторі можемо зробити висновок, що це не схоже на випадковий збій та запис фрагментів MFT по некоректним зміщенням. Версію з некоректним транслятором можна вважати підтвердженою.
Для подальшої локалізації точок зрушень встановимо максимально можливе усунення. Для цього визначимо, наскільки зрушений кінцевий маркер розділу NTFS (копія завантажувального сектора). На малюнку 7 зі зміщенням 0x28 четверне слово – це значення розміру розділу 0x00 00 00 00 01 13 09 A2 (18 024 866) секторів. Додамо зміщення самого розділу від початку диска до його довжини отримаємо зміщення кінцевого маркера NTFS 18 + 024 = 866. Очікувано там не виявилося потрібної копії завантажувального сектора. При пошуку в околицях він був виявлений з наростаючим зрушенням +63 секторів по відношенню до останнього фрагменту MFT.
Мал. 12 Копія завантажувального сектора NTFS
Іншу копію завантажувального сектора зі зміщення 18 ігноруємо, оскільки вона не має відношення до нашого розділу. На підставі попередніх заходів встановлено, що всередині розділу є вкраплення з «спливлих» у трансляції 041 сектора, які розсунули дані.
Виконуємо повне читання накопичувача, результатом якого залишається 34 непрочитані сектори. На жаль, достовірно гарантувати, що всі вони є дефектами, видаленими з P-list неможливо, але при подальшому аналізі бажано враховувати їхнє положення, оскільки в деяких випадках можна буде визначати точки зсуву з точністю до сектора, а не до файлу.
Мал. 13 Статистика читання диска.
Наступним завданням буде встановити орієнтовні місця зрушень (з точністю до файлу, в якому вони виникли). Для цього проведемо сканування всіх записів MFT та побудуємо ланцюжки розташування файлів (фрагментів файлів).
Мал. 14 Ланцюжки розташування файлів або їх фрагментів.
Далі, рухаючись від файлу до файлу, шукаємо, з якого моменту замість очікуваного заголовка файлу будуть інші дані, а необхідний заголовок виявиться з якимось позитивним зрушенням. І з уточненням точок зрушень заповнюємо таблицю. Результатом її заповнення буде понад 99% без пошкоджень.
Мал. 15 Список файлів користувача (від клієнта отримано згоду на публікацію цього скріншота)
Для встановлення точкових зрушень в окремих файлах можна провести додаткові роботи і при знанні структури файлу знайти вкраплення даних, що не належать до нього. Але в цьому завдання це було економічно доцільно.
PS Хотілося б також звернутися до колег, у чиїх руках цей диск побував раніше. Будь ласка, будьте уважні при роботі з мікропрограмою пристроїв і резервуйте службові дані перед тим, як щось змінити, а також не допускайте навмисного погіршення проблеми, якщо вам не вдалося домовитися з клієнтом про виконання робіт.
Джерело: habr.com