Ito ay 2019. Nakatanggap ang aming laboratoryo ng QUANTUM FIREBALL Plus KA drive na may kapasidad na 9.1GB, na hindi pangkaraniwan sa ating panahon. Ayon sa may-ari ng drive, ang pagkabigo ay nangyari noong 2004 dahil sa isang nabigong supply ng kuryente, na kinuha ang hard drive at iba pang mga bahagi ng PC kasama nito. Pagkatapos ay may mga pagbisita sa iba't ibang mga serbisyo na may mga pagtatangka na ayusin ang drive at ibalik ang data, na hindi matagumpay. Sa ilang mga kaso ipinangako nila na ito ay magiging mura, ngunit hindi nila nalutas ang problema, sa iba ito ay masyadong mahal at ang kliyente ay hindi nais na ibalik ang data, ngunit sa huli ang disk ay dumaan sa maraming mga sentro ng serbisyo. Ilang beses itong nawala, ngunit salamat sa katotohanan na inalagaan ng may-ari ang pag-record ng impormasyon mula sa iba't ibang mga sticker sa drive nang maaga, pinamamahalaan niyang tiyakin na ang kanyang hard drive ay naibalik mula sa ilang mga service center. Ang mga paglalakad ay hindi pumasa nang walang bakas, maraming mga bakas ng paghihinang ang nanatili sa orihinal na controller board, at ang kakulangan ng mga elemento ng SMD ay nakikita din (sa pagtingin sa unahan, sasabihin ko na ito ang pinakamaliit sa mga problema ng drive na ito).
kanin. 1 HDD Quantum Fireball Plus KA 9,1GB
Ang unang bagay na kailangan naming gawin ay maghanap sa archive ng donor para sa isang sinaunang kambal na kapatid ng drive na ito na may gumaganang controller board. Kapag nakumpleto ang paghahanap na ito, naging posible na magsagawa ng malawak na mga hakbang sa diagnostic. Pagkatapos suriin ang mga windings ng motor para sa isang maikling circuit at siguraduhin na walang maikling circuit, ini-install namin ang board mula sa donor drive sa drive ng pasyente. Nag-aaplay kami ng kapangyarihan at naririnig ang normal na tunog ng pag-ikot ng baras, na pumasa sa isang pagsubok sa pagkakalibrate kasama ang paglo-load ng firmware, at pagkatapos ng ilang segundo ang drive ay nag-uulat sa pamamagitan ng mga rehistro na handa na itong tumugon sa mga utos mula sa interface.
kanin. Ang 2 DRD DSC indicator ay nagpapahiwatig ng kahandaang tumanggap ng mga utos.
Bina-back up namin ang lahat ng kopya ng mga module ng firmware. Sinusuri namin ang integridad ng mga module ng firmware. Walang mga problema sa pagbabasa ng mga module, ngunit ang pagsusuri sa mga ulat ay nagpapakita na mayroong ilang mga kakaiba.
kanin. 3. Zone table.
Binibigyang-pansin namin ang talahanayan ng pamamahagi ng zonal at tandaan na ang bilang ng mga cylinder ay 13845.
kanin. 4 P-list (pangunahing listahan - listahan ng mga depekto na ipinakilala sa panahon ng ikot ng produksyon).
Binibigyang pansin namin ang napakaliit na bilang ng mga depekto at ang kanilang lokasyon. Tinitingnan namin ang factory defect hiding log module (60h) at nalaman na ito ay walang laman at hindi naglalaman ng isang entry. Batay dito, maaari nating ipagpalagay na sa isa sa mga nakaraang sentro ng serbisyo, ang ilang mga manipulasyon ay maaaring ginawa sa lugar ng serbisyo ng drive, at hindi sinasadya o sinasadya ang isang dayuhang module ay nakasulat, o ang listahan ng mga depekto sa orihinal. ang isa ay nalinis. Upang subukan ang pagpapalagay na ito, gumawa kami ng isang gawain sa Data Extractor na may naka-enable na opsyon na "lumikha ng sektor-by-sector na kopya" at "lumikha ng virtual na tagasalin."
kanin. 5 Mga parameter ng gawain.
Ang pagkakaroon ng paggawa ng gawain, tinitingnan namin ang mga entry sa partition table sa sector zero (LBA 0)
kanin. 6 Master boot record at partition table.
Sa offset 0x1BE mayroong isang entry (16 bytes). Ang uri ng file system sa partition ay NTFS, offset sa simula ng 0x3F (63) na sektor, laki ng partition 0x011309A3 (18) na sektor.
Sa editor ng sektor, buksan ang LBA 63.
kanin. 7 NTFS boot sector
Ayon sa impormasyon sa boot sector ng NTFS partition, masasabi natin ang sumusunod: ang laki ng sektor na tinanggap sa volume ay 512 bytes (word 0x0 (0) ay nakasulat sa offset 0200x512B), ang bilang ng mga sektor sa cluster ay 8 (byte 0x0 ay nakasulat sa offset 0x08D), ang laki ng kumpol ay 512x8=4096 bytes, ang unang tala ng MFT ay matatagpuan sa offset na 6 na sektor mula sa simula ng disk (sa offset na 291x519 quadruple word 0x30 0 00 00 00 00C 00 0 (00) na numero ng unang MFT cluster. Ang numero ng sektor ay kinakalkula sa pamamagitan ng formula: Cluster number * bilang ng mga sektor sa cluster + offset sa simula ng partition 00* 786+432= 786).
Lumipat tayo sa sektor 6.
Fig. 8
Ngunit ang data na nakapaloob sa sektor na ito ay ganap na naiiba sa talaan ng MFT. Bagama't nagpapahiwatig ito ng posibleng maling pagsasalin dahil sa maling listahan ng depekto, hindi nito pinatutunayan ang katotohanang ito. Upang higit pang suriin, babasahin namin ang disk ng 10 sektor sa parehong direksyon na may kaugnayan sa 000 na sektor. At pagkatapos ay maghahanap tayo ng mga regular na ekspresyon sa ating binabasa.
kanin. 9 Unang MFT recording
Sa sektor 6 makikita natin ang unang tala ng MFT. Ang posisyon nito ay naiiba sa kinakalkula ng 291 sektor, at pagkatapos ay isang grupo ng 551 na talaan (mula 32 hanggang 16) ang patuloy na sumusunod. Ipasok natin ang posisyon ng sektor 0 sa talahanayan ng shift at sumulong ng 15 sektor.
Fig. 10
Ang posisyon ng record No. 16 ay dapat nasa offset na 12, ngunit makikita namin ang mga zero doon sa halip na ang MFT record. Magsagawa tayo ng katulad na paghahanap sa nakapaligid na lugar.
kanin. 11 MFT entry 0x00000011 (17)
Isang malaking fragment ng MFT ang nakita, simula sa record number 17 na may haba na 53 records) na may shift na 646 sektor. Para sa posisyong 17, maglagay ng shift ng +12 sektor sa talahanayan ng shift.
Ang pagkakaroon ng pagtukoy sa posisyon ng mga fragment ng MFT sa espasyo, maaari nating tapusin na hindi ito mukhang isang random na pagkabigo at pag-record ng mga fragment ng MFT sa mga maling offset. Ang isang bersyon na may maling tagasalin ay maaaring ituring na nakumpirma.
Para mas ma-localize ang mga shift point, itatakda namin ang maximum na posibleng displacement. Upang gawin ito, tinutukoy namin kung magkano ang dulo ng marker ng partisyon ng NTFS (kopya ng sektor ng boot) ay inilipat. Sa Figure 7, sa offset na 0x28, ang quadword ay ang halaga ng laki ng partition ng 0x00 00 00 00 01 13 09 A2 (18) na sektor. Idagdag natin ang offset ng partition mismo mula sa simula ng disk hanggang sa haba nito, at makuha natin ang offset ng dulo na marker ng NTFS 024 + 866= 18. Gaya ng inaasahan, wala doon ang kinakailangang kopya ng boot sector. Kapag naghahanap sa nakapaligid na lugar, ito ay natagpuan na may pagtaas ng shift ng +024 sektor na nauugnay sa huling fragment ng MFT.
kanin. 12 Kopya ng NTFS boot sector
Hindi namin pinapansin ang ibang kopya ng boot sector sa offset na 18, dahil hindi ito nauugnay sa aming partition. Batay sa mga nakaraang aktibidad, ito ay itinatag na sa loob ng seksyon ay may mga inklusyon ng 041 sektor na "nag-pop up" sa broadcast, na nagpalawak ng data.
Nagsasagawa kami ng buong pagbabasa ng drive, na nag-iiwan ng 34 na hindi pa nababasang sektor. Sa kasamaang palad, imposibleng mapagkakatiwalaan na garantiya na ang lahat ng mga ito ay mga depekto na tinanggal mula sa P-list, ngunit sa karagdagang pagsusuri ay ipinapayong isaalang-alang ang kanilang posisyon, dahil sa ilang mga kaso posible na mapagkakatiwalaan na matukoy ang mga shift point na may isang katumpakan ng sektor, at hindi ang file.
kanin. 13 Mga istatistika sa pagbabasa ng disk.
Ang aming susunod na gawain ay itatag ang tinatayang mga lokasyon ng mga paglilipat (sa katumpakan ng file kung saan nangyari ang mga ito). Upang gawin ito, i-scan namin ang lahat ng mga tala ng MFT at bubuo ng mga chain ng mga lokasyon ng file (mga fragment ng file).
kanin. 14 Mga kadena ng lokasyon ng mga file o ang kanilang mga fragment.
Susunod, ang paglipat mula sa file patungo sa file, hinahanap namin ang sandali kung saan magkakaroon ng iba pang data sa halip na ang inaasahang header ng file, at ang nais na header ay makikita na may tiyak na positibong pagbabago. At habang pinipino namin ang mga shift point, pinupunan namin ang talahanayan. Ang resulta ng pagpuno nito ay higit sa 99% ng mga file na walang pinsala.
kanin. 15 Listahan ng mga file ng user (natanggap ang pahintulot mula sa kliyente na i-publish ang screenshot na ito)
Upang magtatag ng mga pagbabago sa punto sa mga indibidwal na file, maaari kang magsagawa ng karagdagang trabaho at, kung alam mo ang istraktura ng file, maghanap ng mga pagsasama ng data na hindi nauugnay dito. Ngunit sa gawaing ito ay hindi ito magagawa sa ekonomiya.
PS Gusto ko ring tugunan ang aking mga kasamahan, kung kaninong mga kamay ang disc na ito dati. Mangyaring mag-ingat kapag nagtatrabaho sa firmware ng device at nag-back up ng data ng serbisyo bago baguhin ang anuman, at huwag sadyang magpalala ng problema kung hindi ka sumang-ayon sa kliyente sa trabaho.
Pinagmulan: www.habr.com