На двары стаяў 2019 год. У нашу лабараторыю паступіў не зусім звычайны для нашага часу назапашвальнік QUANTUM FIREBALL Plus KA ёмістасцю 9.1/2004Гб. Са слоў уладальніка назапашвальніка адмова здарылася ў далёкім XNUMX году па віне які выйшаў з ладу блока сілкавання, які прыхапіў за сабой цвёрдая кружэлка і іншыя кампаненты ПК. Далей былі хадні па розных сэрвісах са спробамі адрамантаваць назапашвальнік і аднавіць дадзеныя, якія не ўвянчаліся поспехам. Дзесьці абяцалі танна, але так і не вырашылі праблему, дзесьці занадта дорага і кліент не захацеў аднаўляць дадзеныя, але ў выніку дыск прайшоў шлях праз мноства сэрвісных цэнтраў. Неаднаразова губляўся, але дзякуючы таму, што ўладальнік загадзя паклапаціўся аб запісе інфармацыі з розных налепак на назапашвальніку яму ўдалося дабіцца, каб менавіта яго жорсткі дыск быў вернуты з некаторых сэрвісных цэнтраў. Хаджэнні не прайшлі бясследна, на арыгінальнай плаце кантролера засталіся множныя сляды паяння, а таксама візуальна адчуваўся недахоп 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 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) нумар першага кластара M. колькасць сектараў у кластары + зрушэнне да пачатку падзелу 786 432* 8+63= 6 291 519).
Пераходзім да сектара 6.
Мал. 8
Але дадзеныя якія змяшчаюцца ў гэтым сектары зусім не падобныя на запіс MFT. Гэта хоць і ўказвае на магчымую няправільную трансляцыю з-за некарэктнага дэфект-ліста, але не даказвае гэты факт. Для далейшай праверкі правядзем чытанне дыска па 10 000 сектараў у абодвух напрамках адносна 6 сектара. І пасля правядзём пошук рэгулярных выразаў у прачытаным.
Мал. 9 Першы запіс MFT
У сектары 6 выяўляем першы запіс MFT. Яе становішча ад разліковага адрозніваецца на 291 сектары, і далей бесперапынна ідзе група з 551 запісаў (ад 32 да 16). Упішам у табліцу зрухаў становішча сектара 0 15 6 ссунуць наперад на 291 сектары.
Мал. 10
Палажэнне запісу №16 павінна быць па зняцці 12, але там выяўляем нулі, замест запісу 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 = 18 024 929. Чакана там не аказалася патрэбнай копіі загрузнага сектара. Пры пошуку ў наваколлях ён быў знойдзены з нарастаючым зрухам у 12 сектараў у адносінах да апошняга фрагмента MFT.
Мал. 12 Копія загрузнага сектара NTFS
Іншую копію загрузнага сектара па зняцці 18 ігнаруем, так як яна не мае дачынення да нашага падзелу. На падставе папярэдніх мерапрыемстваў устаноўлена, што ўнутры раздзела ёсць украпванні з «усплылых» у трансляцыі 041 сектара, якія рассунулі дадзеныя.
Выконваем поўнае чытанне назапашвальніка, вынікам якога застаецца 34 непрачытаныя сектары. Нажаль, пэўна гарантаваць, што ўсе яны з'яўляюцца дэфектамі, выдаленымі з P-list немагчыма, але пры наступным аналізе пажадана ўлічваць іх становішча, бо ў некаторых выпадках можна будзе пэўна вызначаць кропкі зруху з дакладнасцю да сектара, а не да файла.
Мал. 13 Статыстыка чытання дыска.
Наступнай нашай задачай будзе ўсталяваць арыентыровачныя месцы зрухаў (з дакладнасцю да файла, у якім яны ўзніклі). Для гэтага правядзём сканаванне ўсіх запісаў MFT і пабудуем ланцужкі размяшчэння файлаў (фрагментаў файлаў).
Мал. 14 Ланцужкі размяшчэння файлаў, або іх фрагментаў.
Далей, рухаючыся ад файла да файла, шукаем, з якога моманту замест чаканага загалоўка файла будуць іншыя дадзеныя, а патрэбны загаловак выявіцца з нейкім дадатным зрухам. І па меры ўдакладнення кропак зрухаў запаўняем табліцу. Вынікам яе запаўнення будзе больш за 99% файлаў без пашкоджанняў.
Мал. 15 Спіс карыстацкіх файлаў (ад кліента атрымана згода на публікацыю гэтага скрыншота)
Для ўсталявання кропкавых зрухаў у асобных файлах можна правесці дадатковыя працы і пры веданні структуры файла знайсці ўкрапванні дадзеных, не якія адносяцца да яго. Але ў дадзенай задачы гэта не было эканамічна мэтазгодна.
PS Хацелася б таксама звярнуцца да калег, у чыіх руках гэты дыск пабываў раней. Калі ласка, будзьце ўважлівыя пры працы з мікрапраграмай прылад і рэзервуйце службовыя дадзеныя перш, чым нешта змяніць, а таксама не дапушчайце наўмыснага пагаршэння праблемы, калі вам не атрымалася дамовіцца з кліентам аб выкананні прац.
Крыніца: habr.com