Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave

Ishte viti 2019. Laboratori ynë mori një makinë QUANTUM FIREBALL Plus KA me një kapacitet 9.1 GB, gjë që nuk është aq e zakonshme për kohën tonë. Sipas pronarit të diskut, dështimi ndodhi në vitin 2004 për shkak të dështimit të furnizimit me energji elektrike, i cili mori me vete hard diskun dhe komponentët e tjerë të PC. Më pas pati vizita në shërbime të ndryshme me përpjekje për të riparuar diskun dhe për të rivendosur të dhënat, të cilat ishin të pasuksesshme. Në disa raste ata premtuan se do të ishte i lirë, por nuk e zgjidhën kurrë problemin, në të tjera ishte shumë i shtrenjtë dhe klienti nuk donte të rivendoste të dhënat, por në fund disku kaloi nëpër shumë qendra shërbimi. Ai humbi disa herë, por falë faktit që pronari u kujdes që paraprakisht të regjistronte informacione nga ngjitëse të ndryshme në disk, ai arriti të sigurojë që hard disku i tij të kthehej nga disa qendra shërbimi. Shëtitjet nuk kaluan pa gjurmë, gjurmët e shumta të saldimit mbetën në tabelën origjinale të kontrolluesit, dhe mungesa e elementeve SMD u ndje edhe vizualisht (duke parë përpara, do të them se ky është problemi më i vogël i kësaj disku).

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 1 HDD Quantum Fireball Plus KA 9,1 GB

Gjëja e parë që duhej të bënim ishte të kërkonim në arkivin e donatorëve për një vëlla binjak kaq të lashtë të kësaj disku me një bord kontrollues funksional. Kur kjo kërkim u përfundua, u bë e mundur kryerja e masave të gjera diagnostikuese. Pasi të kemi kontrolluar mbështjelljet e motorit për një qark të shkurtër dhe të sigurohemi që nuk ka qark të shkurtër, ne instalojmë tabelën nga disku i dhuruesit në makinën e pacientit. Ne aplikojmë energji dhe dëgjojmë tingullin normal të boshtit që rrotullohet lart, duke kaluar një test kalibrimi me ngarkimin e firmuerit dhe pas disa sekondash disku raporton nga regjistrat se është gati t'u përgjigjet komandave nga ndërfaqja.

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 2 Treguesit DRD DSC tregojnë gatishmërinë për të marrë komanda.

Ne rezervojmë të gjitha kopjet e moduleve të firmuerit. Ne kontrollojmë integritetin e moduleve të firmuerit. Nuk ka probleme me leximin e moduleve, por analiza e raporteve tregon se ka disa çudira.

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 3. Tabela e zonave.

Ne i kushtojmë vëmendje tabelës së shpërndarjes zonale dhe vërejmë se numri i cilindrave është 13845.

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 4 P-lista (lista primare – lista e defekteve të paraqitura gjatë ciklit të prodhimit).

Ne tërheqim vëmendjen për numrin shumë të vogël të defekteve dhe vendndodhjen e tyre. Ne shikojmë modulin e fshehjes së regjistrit të defektit në fabrikë (60h) dhe zbulojmë se ai është bosh dhe nuk përmban asnjë hyrje të vetme. Bazuar në këtë, mund të supozojmë se në një nga qendrat e mëparshme të shërbimit, mund të jenë bërë disa manipulime me zonën e shërbimit të diskut, dhe aksidentalisht ose qëllimisht është shkruar një modul i huaj, ose lista e defekteve në origjinal. njëra u pastrua. Për të testuar këtë supozim, ne krijojmë një detyrë në Data Extractor me opsionet "krijo kopje sektor pas sektori" dhe "krijo përkthyes virtual" të aktivizuara.

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 5 Parametrat e detyrës.

Pasi kemi krijuar detyrën, ne shikojmë hyrjet në tabelën e ndarjes në sektorin zero (LBA 0)

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 6 Regjistrimi kryesor i nisjes dhe tabela e ndarjes.

Në offset 0x1BE ka një hyrje të vetme (16 bajt). Lloji i sistemit të skedarëve në ndarje është NTFS, i zhvendosur në fillim të sektorëve 0x3F (63), madhësia e ndarjes 0x011309A3 (18) sektorë.
Në redaktorin e sektorit, hapni LBA 63.

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 7 Sektori i nisjes NTFS

Sipas informacionit në sektorin e nisjes së ndarjes NTFS, mund të themi si më poshtë: madhësia e sektorit të pranuar në vëllim është 512 bajt (fjala 0x0 (0) shkruhet në kompensim 0200x512B), numri i sektorëve në grup është 8 (byte 0x0 është shkruar në zhvendosje 0x08D), madhësia e grupit është 512x8=4096 bytes, rekordi i parë MFT ndodhet në një zhvendosje prej 6 sektorësh nga fillimi i diskut (në një zhvendosje prej 291x519 fjalë katërfishtë 0x30 0 00C 00 00 (00) numri i grupit të parë MFT. Numri i sektorit llogaritet me formulën: Numri i grupit * numri i sektorëve në grup + kompensimi në fillim të seksionit 00* 0+00= 00).
Le të kalojmë në sektorin 6.

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Fig. 8

Por të dhënat që përmban ky sektor janë krejtësisht të ndryshme nga të dhënat e MFT. Edhe pse kjo tregon një përkthim të pasaktë të mundshëm për shkak të një liste të gabuar defektesh, nuk e vërteton këtë fakt. Për të kontrolluar më tej, ne do të lexojmë diskun nga 10 sektorë në të dy drejtimet në krahasim me 000 sektorë. Dhe pastaj do të kërkojmë shprehje të rregullta në atë që lexojmë.

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 9 Regjistrimi i parë MFT

Në sektorin 6 gjejmë rekordin e parë MFT. Pozicioni i tij ndryshon nga ai i llogaritur me 291 sektorë, dhe më pas vijon vazhdimisht një grup prej 551 rekordesh (nga 32 në 16). Le të fusim pozicionin e sektorit 0 në tabelën e ndërrimit dhe të ecim përpara me 15 sektorë.

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Fig. 10

Pozicioni i rekordit nr. 16 duhet të jetë në kompensim 12, por ne gjejmë zero atje në vend të rekordit MFT. Le të bëjmë një kërkim të ngjashëm në zonën përreth.

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 11 hyrje MFT 0x00000011 (17)

Zbulohet një fragment i madh MFT, duke filluar me numrin e rekordit 17 me një gjatësi prej 53 rekorde) me një zhvendosje prej 646 sektorësh. Për pozicionin 17, vendosni një zhvendosje prej +12 sektorësh në tabelën e ndërrimit.
Pasi të kemi përcaktuar pozicionin e fragmenteve MFT në hapësirë, mund të konkludojmë se kjo nuk duket si një dështim i rastësishëm dhe regjistrim i fragmenteve MFT në zhvendosje të pasakta. Një version me një përkthyes të pasaktë mund të konsiderohet i konfirmuar.
Për të lokalizuar më tej pikat e zhvendosjes, ne do të vendosim zhvendosjen maksimale të mundshme. Për ta bërë këtë, ne përcaktojmë se sa është zhvendosur shënuesi fundor i ndarjes NTFS (kopja e sektorit të nisjes). Në Figurën 7, me kompensim 0x28, katërfjala është vlera e madhësisë së ndarjes së sektorëve 0x00 00 00 00 01 13 09 A2 (18). Le të shtojmë kompensimin e vetë ndarjes nga fillimi i diskut në gjatësinë e tij dhe marrim kompensimin e shënuesit NTFS fundor 024 + 866= 18. Siç pritej, kopja e kërkuar e sektorit të nisjes nuk ishte aty. Gjatë kërkimit të zonës përreth, u gjet me një zhvendosje në rritje prej +024 sektorësh në krahasim me fragmentin e fundit MFT.

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 12 Kopje e sektorit të nisjes NTFS

Ne e shpërfillim kopjen tjetër të sektorit të nisjes me kompensim 18, pasi nuk ka lidhje me ndarjen tonë. Në bazë të aktiviteteve të mëparshme, u konstatua se brenda seksionit janë përfshirë 041 sektorë që “shfaqen” në transmetim, gjë që zgjeroi të dhënat.
Ne kryejmë një lexim të plotë të diskut, i cili lë 34 sektorë të palexuar. Fatkeqësisht, është e pamundur të garantohet me besueshmëri se të gjitha ato janë defekte të hequra nga lista P, por në analizë të mëtejshme këshillohet të merret parasysh pozicioni i tyre, pasi në disa raste do të jetë e mundur të përcaktohen me besueshmëri pikat e zhvendosjes me një saktësi e sektorit dhe jo e skedarit.

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 13 Statistikat e leximit të diskut.

Detyra jonë e ardhshme do të jetë vendosja e vendndodhjeve të përafërta të ndërrimeve (në saktësinë e skedarit në të cilin ato kanë ndodhur). Për ta bërë këtë, ne do të skanojmë të gjitha regjistrimet MFT dhe do të ndërtojmë zinxhirë vendndodhjesh skedarësh (fragmente skedari).

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 14 Zinxhirët e vendndodhjes së skedarëve ose fragmenteve të tyre.

Më pas, duke lëvizur nga skedari në skedar, ne kërkojmë momentin në të cilin do të ketë të dhëna të tjera në vend të kokës së pritshme të skedarit dhe titulli i dëshiruar do të gjendet me një zhvendosje të caktuar pozitive. Dhe ndërsa përsosim pikat e ndërrimit, ne plotësojmë tabelën. Rezultati i plotësimit të tij do të jetë mbi 99% e skedarëve pa dëmtim.

Duke ecur nëpër agoni ose një histori të gjatë të një përpjekjeje për rikuperimin e të dhënave
Oriz. 15 Lista e skedarëve të përdoruesve (u pranua pëlqimi nga klienti për të publikuar këtë pamje të ekranit)

Për të vendosur ndërrime pikash në skedarë individualë, mund të kryeni punë shtesë dhe, nëse e dini strukturën e skedarit, të gjeni përfshirje të të dhënave që nuk lidhen me të. Por në këtë detyrë nuk ishte ekonomikisht e realizueshme.

PS Dëshiroj t'u drejtohem edhe kolegëve të mi, në duart e të cilëve më parë ishte ky disk. Jini të kujdesshëm kur punoni me firmuerin e pajisjes dhe bëni kopje rezervë të të dhënave të shërbimit përpara se të ndryshoni ndonjë gjë dhe mos e përkeqësoni qëllimisht problemin nëse nuk jeni në gjendje të pajtoheni me klientin për punën.

Publikimi i mëparshëm: Ruajtja e ndeshjeve ose rikuperimi i të dhënave nga një HDD bluarëse Seagate ST3000NC002-1DY166

Burimi: www.habr.com

Shto një koment