V dvori je bil leto 2019. V naš laboratorij je prišel nekoliko nenavaden prenosni disk QUANTUM FIREBALL Plus KA s kapaciteto 9,1 GB. Po besedah lastnika se je okvara zgodila že leta 2004 zaradi okvare napajalnega bloka, ki je s seboj potegnil trdi disk in druge komponente PC-ja. Sledile so poti po različnih servisih z poskusi popravila diska in obnovitve podatkov, ki so bili neuspešni. Nekateri so obljubljali nizke cene, a težave niso rešili, drugi so zahtevali previsoke cene in stranka se je odločila, da ne bo obnovila podatkov. Disk je prešel skozi številne servisne centre. Večkrat se je izgubil, a zahvaljujoč temu, da je lastnik vnaprej poskrbel za zapis informacij z različnih nalepk na disku, mu je uspelo doseči, da je njegov trdi disk bil vrnjen iz nekaterih servisnih centrov. Ta pot se ni končala brez sledi, na originalni plošči krmilnika so ostali številni sledi spajkanja, prav tako pa je bil vizualno opazen pomanjkanje SMD elementov (morda najslabša težava tega diska).

Slika 1 HDD Quantum Fireball Plus KA 9,1 GB
Najprej je bilo potrebno poiskati donorskega brata dvojčka tega diska s delujočo ploščo krmilnika. Ko je bil ta iskalni izziv zaključen, smo lahko izvedli obsežne diagnostične postopke. Preverili smo navitja motorja na kratkostično povezavo in se prepričali, da je ta odsotna, nato pa namestimo ploščo z donorskega diska na disku - pacientu. Vključimo napajanje in slišimo normalen zvok vrtenja gredi ter uspešno opravljen kalibracijski test z nalaganjem programske opreme. Po nekaj sekundah disk poroča s registri, da je pripravljen sprejemati ukaze iz vmesnika.
Slika 2 Indikatorji DRD DSC pomenijo pripravljenost za sprejemanje ukazov.
Zavarujemo vse kopije modulov programske opreme. Izvajamo preverjanje celovitosti modulov programske opreme. Pri nalaganju modulov ni težav, vendar analiza poročil kaže na določene nenavadnosti.

Slika 3. Tabela con.
Opozarjamo na tabelo območnega razporeda in opažamo, da je število cilindrov enako 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
V sektoru 6 291 551 odkrijemo prvi zapis MFT. Njegova lega se od izračunane razlikuje za 32 sektorja, nato pa neprekinjeno sledi skupina 16 zapisov (od 0 do 15). V tabelo premikov bomo vpisali lego sektorja 6 291 519 in ga premaknili naprej za 32 sektorjev.

Sl. 10
Lega zapisa št. 16 bi morala biti po premiku 12 551 431, vendar tam odkrijemo ničle, namesto zapisa MFT. Izvedli bomo podoben iskanje v okolici.

Sl. 11 Zapis MFT 0x00000011 (17)
Odkrijemo velik fragment MFT, ki se začne z zapisom pod št. 17, dolžine 53 646 zapisov, s premikom za 17 sektorjev. Za lego 12 155 431 bomo v tabelo premikov zapisali premik +17 sektorjev.
Ko določimo lego fragmentov MFT v prostoru, lahko sklepamo, da to ne spominja na naključno napako in zapis fragmentov MFT po nepravilnih premikih. Različico z nepravilnim prevajalnikom lahko štejemo za potrjeno.
Za nadaljnjo lokalizacijo točk premikov bomo določili največje mogoče premikanje. Za to ugotovimo, koliko je premaknjen končni marker NTFS razdelka (kopija zagonskega sektorja). Na sliki 7, pri premiku 0x28, je četverno besedilo — to je vrednost velikosti razdelka 0x00 00 00 00 01 13 09 A2 (18 024 866) sektorjev. Dodali bomo premik samega razdelka od začetka diska k njegovi dolžini, kar nam daje premik končnega markerja NTFS 18 024 866 + 63 = 18 024 929. Očitno tam ni bilo potrebne kopije zagonskega sektorja. Pri iskanju v okolici je bil odkrito s postopnim premikom +12 sektorjev v primerjavi z zadnjim fragmentom MFT.

Sl. 12 Kopija zagonskega sektorja NTFS
Druge kopije zagonskega sektorja pri premiku 18 041 006 ignoriramo, saj niso povezane z našim razdelkom. Na podlagi prejšnjih postopkov je ugotovljeno, da znotraj razdelka obstajajo vpisi iz 'izbočenih' v prevodih 61 sektorjev, ki so razširili podatke.
Izvedemo popolno branje nosilca, pri čemer ostane 34 neprebranih sektorjev. Na žalost ni mogoče z gotovostjo jamčiti, da so vsi ti napake, odstranjene iz P-liste, vendar je pri nadaljnji analizi priporočljivo upoštevati njihovo lego, saj je v nekaterih primerih mogoče z gotovostjo določiti točke premikanja s točnostjo do sektorja in ne do datoteke.

Sl. 13 Statistika branja diska.
Naša naslednja naloga bo določitev približnih premikov (natančno do datoteke, v kateri so nastali). Za to bomo skenirali vse zapise MFT in zgradili verige lokacij datotek (fragmentov datotek).

Slika 14 Verige lokacij datotek ali njihovih fragmentov.
Nato, ko se premikamo od datoteke do datoteke, iščemo, od kdaj namesto pričakovanega konca datoteke pridejo drugi podatki, medtem ko se potrebni konec odkrije z nekim pozitivnim premikom. In med natančnim določanjem premikov izpolnjujemo tabelo. Rezultat izpolnitev bo več kot 99% datotek brez poškodb.

Slika 15 Seznam uporabniških datotek (dobili smo soglasje stranke za objavo tega zaslona)
Za določanje točnih premikov v posameznih datotekah lahko izvedemo dodatna dela in ob poznavanju strukture datoteke najdemo vdelane podatke, ki niso povezani z njo. Vendar pa to v tej nalogi ni bilo ekonomsko smiselno.
P.S. Rad bi se obrnil tudi na kolege, ki so prej imeli ta disk v rokah. Prosimo, bodite pozorni pri delu z mikrogrami naprav in rezervirajte službene podatke, preden karkoli spremenite, ter ne dovolite namernega poslabšanja težave, če se niste dogovorili s stranko o izvedbi dela.
Izvor: habr.com
