Bilo je leto 2019. Naš laboratorij je prejel pogon QUANTUM FIREBALL Plus KA s kapaciteto 9.1 GB, kar za naš čas ni ravno običajno. Po besedah lastnika diska je do okvare prišlo že leta 2004 zaradi okvare napajalnika, ki je s seboj odnesel trdi disk in druge komponente osebnega računalnika. Sledili so obiski različnih servisov s poskusi popravila pogona in obnovitve podatkov, ki pa so bili neuspešni. Ponekod so obljubljali, da bo poceni, pa nikoli niso rešili problema, ponekod je bilo predrago in stranka ni želela obnoviti podatkov, na koncu pa je šel disk skozi številne servise. Večkrat se je izgubil, a zaradi dejstva, da je lastnik vnaprej poskrbel za snemanje podatkov z različnih nalepk na pogonu, mu je uspelo zagotoviti, da so njegov trdi disk vrnili iz nekaterih servisnih centrov. Sprehodi niso minili brez sledi, na prvotni krmilni plošči je ostalo več sledi spajkanja, vizualno pa je bilo čutiti tudi pomanjkanje elementov SMD (če pogledam naprej, bom rekel, da je to najmanjša težava tega pogona).
riž. 1 trdi disk Quantum Fireball Plus KA 9,1 GB
Najprej smo morali v arhivu donatorjev poiskati tako starodavnega brata dvojčka tega pogona z delujočo krmilno ploščo. Ko je bilo to iskanje končano, je bilo mogoče izvesti obsežne diagnostične ukrepe. Ko preverimo navitja motorja glede kratkega stika in se prepričamo, da ni kratkega stika, namestimo ploščo iz pogona donatorja na pogon bolnika. Priklopimo moč in slišimo običajen zvok gredi, ki se vrti, opravi kalibracijski test z nalaganjem vdelane programske opreme in po nekaj sekundah pogon poroča z registri, da je pripravljen odgovoriti na ukaze iz vmesnika.
riž. 2 indikatorja DRD DSC označujeta pripravljenost za sprejem ukazov.
Varnostno kopiramo vse kopije modulov vdelane programske opreme. Preverimo celovitost modulov vdelane programske opreme. Pri branju modulov ni težav, vendar analiza poročil kaže, da obstajajo nekatere nenavadnosti.
riž. 3. Conska miza.
Pozorni smo na consko razdelilno tabelo in upoštevamo, da je število jeklenk 13845.
riž. 4 P-seznam (primarni seznam – seznam napak, uvedenih med proizvodnim ciklom).
Opozarjamo na premajhno število napak in njihovo lokacijo. Pogledamo modul dnevnika skrivanja tovarniških napak (60h) in ugotovimo, da je prazen in ne vsebuje niti enega vnosa. Na podlagi tega lahko domnevamo, da so bile v enem od prejšnjih servisnih centrov morda opravljene nekatere manipulacije s servisnim območjem pogona in je bil pomotoma ali namerno zapisan tuji modul ali seznam napak v izvirniku ena je bila očiščena. Za preizkus te predpostavke ustvarimo nalogo v Data Extractorju z omogočenima možnostma »ustvari kopijo sektorja za sektorjem« in »ustvari virtualni prevajalnik«.
riž. 5 Parametri naloge.
Ko ustvarimo nalogo, pogledamo vnose v particijsko tabelo v sektorju nič (LBA 0)
riž. 6 Glavni zagonski zapis in particijska tabela.
Pri odmiku 0x1BE je en sam vnos (16 bajtov). Vrsta datotečnega sistema na particiji je NTFS, zamik na začetku 0x3F (63) sektorjev, velikost particije 0x011309A3 (18) sektorjev.
V urejevalniku sektorjev odprite LBA 63.
riž. 7 zagonski sektor NTFS
Glede na informacije v zagonskem sektorju particije NTFS lahko rečemo naslednje: velikost sektorja, sprejeta v nosilcu, je 512 bajtov (beseda 0x0 (0) je zapisana pri odmiku 0200x512B), število sektorjev v gruči je 8 (bajt 0x0 je zapisan pri odmiku 0x08D), velikost gruče je 512x8=4096 bajtov, prvi zapis MFT se nahaja pri odmiku 6 sektorjev od začetka diska (pri odmiku 291x519 štirikratna beseda 0x30 0 00 00 00 00C 00 0 (00) številka prve gruče MFT Številka sektorja se izračuna po formuli: Številka gruče * število sektorjev v gruči + odmik na začetek sekcije 00* 786+432= 786).
Pojdimo na sektor 6.
Sl. 8
Toda podatki v tem sektorju so popolnoma drugačni od zapisa MFT. Čeprav to kaže na možen nepravilen prevod zaradi napačnega seznama napak, tega dejstva ne dokazuje. Za nadaljnje preverjanje bomo prebrali disk po 10 sektorjih v obe smeri glede na 000 sektorjev. In potem bomo iskali regularne izraze v tem, kar beremo.
riž. 9 Prvi MFT posnetek
V sektorju 6 najdemo prvi zapis MFT. Njegov položaj se od izračunanega razlikuje za 291 sektorjev, nato pa neprekinjeno sledi skupina 551 zapisov (od 32 do 16). V tabelo premikov vnesemo položaj sektorja 0 in se pomaknemo naprej za 15 sektorjev.
Sl. 10
Položaj zapisa št. 16 bi moral biti na odmiku 12, vendar tam najdemo ničle namesto zapisa MFT. Izvedimo podobno iskanje v okolici.
riž. 11 Vnos MFT 0x00000011 (17)
Zaznan je velik fragment MFT, ki se začne z zapisom številka 17 z dolžino 53 zapisov) s premikom 646 sektorjev. Za položaj 17 vstavite premik za +12 sektorjev v tabeli premikov.
Po določitvi položaja fragmentov MFT v prostoru lahko sklepamo, da to ni videti kot naključna okvara in snemanje fragmentov MFT pri nepravilnih odmikih. Različica z nepravilnim prevajalcem se lahko šteje za potrjeno.
Za nadaljnjo lokalizacijo točk premika bomo nastavili največji možni premik. Da bi to naredili, določimo, koliko je premaknjena končna oznaka particije NTFS (kopija zagonskega sektorja). Na sliki 7 je pri odmiku 0x28 štiribeseda vrednost velikosti particije 0x00 00 00 00 01 13 09 A2 (18) sektorjev. Njeni dolžini prištejmo odmik same particije od začetka diska in dobimo odmik končnega NTFS markerja 024 866 18 + 024 = 866 63 18. Kot je bilo pričakovano, zahtevane kopije zagonskega sektorja ni bilo. Pri iskanju okolice je bil najden z naraščajočim premikom +024 sektorjev glede na zadnji fragment MFT.
riž. 12 Kopija zagonskega sektorja NTFS
Drugo kopijo zagonskega sektorja pri odmiku 18 ignoriramo, ker ni povezana z našo particijo. Na podlagi predhodnih aktivnosti je bilo ugotovljeno, da so znotraj odseka vključeni 041 sektorji, ki so se »pojavili« v oddaji, kar je razširilo podatke.
Izvedemo popolno branje pogona, ki pusti 34 neprebranih sektorjev. Na žalost je nemogoče zanesljivo zagotoviti, da gre pri vseh za napake, odstranjene s P-liste, vendar je pri nadaljnji analizi priporočljivo upoštevati njihov položaj, saj bo v nekaterih primerih možno zanesljivo določiti točke prestavljanja z natančnost sektorja in ne datoteke.
riž. 13 Statistika branja diska.
Naša naslednja naloga bo ugotoviti približne lokacije premikov (na točnost datoteke, v kateri so se zgodili). Za to bomo pregledali vse zapise MFT in zgradili verige lokacij datotek (fragmentov datotek).
riž. 14 Verige lokacije datotek ali njihovih fragmentov.
Nato se premikamo od datoteke do datoteke in iščemo trenutek, ko bodo namesto pričakovane glave datoteke drugi podatki in želena glava bo najdena z določenim pozitivnim premikom. In ko izpopolnimo točke premikov, izpolnimo tabelo. Rezultat polnjenja bo več kot 99% datotek brez poškodb.
riž. 15 Seznam uporabniških datotek (od stranke je bilo prejeto soglasje za objavo tega posnetka zaslona)
Za ugotavljanje premikov točk v posameznih datotekah lahko opravite dodatna dela in ob poznavanju strukture datoteke poiščete vključke podatkov, ki z njo niso povezani. Toda v tej nalogi to ni bilo ekonomsko izvedljivo.
PS Rad bi se obrnil tudi na svoje kolege, v katerih rokah je bil prej ta disk. Prosimo, bodite previdni pri delu z vdelano programsko opremo naprave in varnostno kopirajte servisne podatke, preden karkoli spremenite, in namerno ne poslabšajte težave, če se s stranko niste mogli dogovoriti o delu.
Vir: www.habr.com