Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor

Era anul 2019. În laboratorul nostru a sosit un dispozitiv de stocare QUANTUM FIREBALL Plus KA, neobișnuit pentru vremea noastră, cu o capacitate de 9.1GB. Potrivit proprietarului, defecțiunea a avut loc în anul 2004 din cauza unei surse de alimentare defecte, care a afectat și hard disk-ul și alte componente ale PC-ului. Ulterior, a existat o călătorie prin diverse servicii în încercarea de a repara dispozitivul și a recupera datele, dar fără succes. Undeva promiteau să fie ieftin, dar nu au rezolvat problema, iar în altă parte costurile erau prea mari, iar clientul nu a dorit să recupereze datele, dar, în final, discul a trecut prin numeroase centre de service. A fost pierdut de mai multe ori, dar datorită faptului că proprietarul a avut grijă să noteze informațiile de pe diverse etichete de pe dispozitiv, a reușit să obțină întoarcerea hard disk-ului său din unele centre de service. Călătoriile nu au fost fără urmări, pe placa originală a controlerului au rămas multiple urme de lipire și, de asemenea, s-a resimțit vizibil lipsa elementelor SMD (o să spun dinainte că aceasta este cea mai mică problemă a acestui dispozitiv).

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 1 HDD Quantum Fireball Plus KA 9,1GB

Primul pas a fost să lucrez la căutarea unui frate geamăn atât de vechi din arhiva de donație, care să aibă placa de control funcțională. Odată ce această misiune a fost finalizată, a fost posibil să se efectueze activități diagnostice extinse. Verificând bobinajul motorului pentru scurtcircuit și asigurându-ne că nu există, instalăm placa de pe dispozitivul-donator pe dispozitivul-pacient. Alimentăm și auzim un sunet normal de rotire a axului, trecerea testului de calibrare cu încărcarea firmware-ului, iar după câteva secunde dispozitivul raportează prin registre că este gata să răspundă la comenzi din partea interfeței.

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 2 Indicile DRD DSC indică pregătirea de a primi comenzi.

Rezervăm toate copiile modulelor firmware-ului. Efectuăm verificarea integrității modulelor firmware-ului. Nu apar probleme în citirea modulelor, dar analiza rapoartelor arată că există unele ciudățenii.

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 3. Tabelul zonelor.

Subliniem tabelul de distribuție a zonelor, observând că numărul cilindrilor este 13845.

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 4 Lista P (lista principal – lista defectelor, incluse în procesul ciclului de producție).

Atenție la numărul foarte mic de defecte și localizarea acestora. Verificăm modulul de jurnalizare a defectelor de fabricație (60h) și descoperim că este gol și nu conține nicio înregistrare. Pe baza acestei constatări, putem presupune că în unele dintre centrele de servicii anterioare, s-ar fi putut efectua anumite manevre cu zona de servicii a unității de stocare, și fie accidental, fie intenționat, a fost înregistrat un modul străin, ori lista defectelor din original a fost ștearsă. Pentru a verifica această suspiciune, creăm o sarcină în Data Extractor cu opțiunile „crearea unei copii sectoriale” și „crearea unui translator virtual” activate.

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 5 Parametrii sarcinii.

După ce am creat sarcina, verificăm înregistrările din tabela secțiunilor în sectorul zero (LBA 0).

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 6 Înregistrarea principală de încărcare și tabela secțiunilor.

La offsetul 0x1BE se află singura înregistrare (16 octeți). Tipul sistemului de fișiere pe partiție este NTFS, offsetul până la început este 0x3F (63) sectoare, dimensiunea partiției este 0x011309A3 (18 024 867) sectoare.
În editorul sectorului deschidem LBA 63.

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 7 Sectorul de încărcare NTFS.

Conform informațiilor din sectorul de încărcare NTFS al partiției, se poate spune următoarele: dimensiunea sectorului, acceptată în volum, este de 512 octeți (la offsetul 0x0B este scris cuvântul 0x0200 (512)), numărul de sectoare pe cluster este 8 (la offsetul 0x0D este scris un octet 0x08), dimensiunea clusterului este 512x8=4096 octeți, prima înregistrare MFT este situată la offsetul 6 291 519 sectoare de la începutul discului (la offsetul 0x30 este scris un cuvânt de 4 ori 0x00 00 00 00 00 0C 00 00 (786 432) numărul primului cluster MFT. Numărul sectorului se calculează conform formulei: Numărul clusterului * numărul de sectoare pe cluster + offsetul până la începutul partiției 786 432* 8+63= 6 291 519).
Trecem la sectorul 6 291 519.

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 8

Însă datele conținute în acest sector nu seamănă deloc cu o înregistrare MFT. Deși acest lucru indică o posibilă transcriere incorectă din cauza unei liste de defecte incorecte, nu dovedește acest fapt. Pentru o verificare suplimentară, vom efectua citirea discului pe 10 000 sectoare în ambele direcții în raport cu sectorul 6 291 519. Apoi vom efectua o căutare a expresiilor regulate în datele citite.

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 9 Prima înregistrare MFT.

În sectorul 6 291 551 găsim prima înregistrare MFT. Poziția sa diferă de calculat cu 32 de sectoare, iar apoi urmează continuu un grup de 16 înregistrări (de la 0 la 15). Vom completa în tabelul de deplasări poziția sectorului 6 291 519 deplasându-l înainte cu 32 de sectoare.

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 10

Poziția înregistrării nr. 16 ar trebui să fie la deplasarea 12 551 431, dar acolo găsim zerouri în loc de înregistrarea MFT. Vom face o căutare similară în împrejurimi.

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 11 Înregistrarea MFT 0x00000011 (17)

Se identifică un fragment mare MFT, care începe cu înregistrarea numărul 17 având o lungime de 53 646 înregistrări) cu o deplasare de 17 sectoare. Pentru poziția 12 155 431 vom întocmi o deplasare de +17 sectoare în tabelul de deplasări.
Definind poziția fragmentelor MFT în spațiu, putem concluziona că acest lucru nu seamănă a fi o defecțiune aleatorie și înregistrarea fragmentelor MFT la deplasări incorecte. Versiunea cu translatorul incorrect poate fi considerată confirmată.
Pentru o mai bună localizare a punctelor de deplasare, vom stabili cea mai mare deplasare posibilă. Pentru aceasta, vom determina cât de mult este deplasat markerul final al partiției NTFS (copia sectorului de boot). În figura 7, la deplasarea 0x28, cuvântul cvadruplu - aceasta este valoarea dimensiunii partiției 0x00 00 00 00 01 13 09 A2 (18 024 866) sectoare. Vom adăuga deplasarea proprie a partiției de la începutul discului la lungimea sa, rezultând deplasarea markerului final NTFS 18 024 866 + 63 = 18 024 929. Așa cum era de așteptat, copia necesară a sectorului de boot nu a fost găsită. La căutarea în apropiere, acesta a fost găsit cu o deplasare crescută de +12 sectoare față de ultimul fragment MFT.

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 12 Copia sectorului de boot NTFS

O altă copie a sectorului de boot la deplasarea 18 041 006 este ignorată, deoarece nu are legătură cu partiția noastră. Pe baza activităților anterioare, s-a stabilit că în interiorul partiției există incluziuni din 'apărute' în traducerea a 61 de sectoare, care au dispersat datele.
Executăm o citire completă a unității, rezultatul fiind 34 de sectoare necitite. Din păcate, nu putem garanta cu certitudine că toate acestea sunt defecte eliminate din lista P-list, dar în cadrul unei analize ulterioare, este recomandabil să se țină cont de poziția lor, deoarece în unele cazuri poate fi posibil să se determine cu precizie punctele de deplasare la nivel de sector, nu doar la nivel de fișier.

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 13 Statistica citirii discului.

Următoarea noastră sarcină va fi să stabilim locurile estimative ale deplasărilor (cu precizie până la fișierul în care au apărut). Pentru aceasta, vom efectua o scanare a tuturor înregistrărilor MFT și vom construi lanțuri de locație a fișierelor (fragmentele fișierelor).

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 14 Lanțuri de locație a fișierelor sau a fragmentelor acestora.

Apoi, deplasându-ne de la fișier la fișier, căutăm începând cu ce moment în loc de antetul așteptat al fișierului vor apărea alte date, iar antetul dorit va fi găsit cu o anumită deplasare pozitivă. Iar pe măsură ce precizăm punctele de deplasare, completăm tabelul. Rezultatul completării acestuia va fi peste 99% din fișiere fără daune.

Dureri și suferințe sau o lungă poveste despre o încercare de recuperare a datelor
Fig. 15 Lista fișierelor utilizatorului (de la client s-a obținut consimțământul pentru publicarea acestei capturi de ecran)

Pentru a stabili deplasările punctuale în fișierele individuale, se pot efectua lucrări suplimentare și, având cunoștințe despre structura fișierului, pot fi găsite inserții de date care nu îi aparțin. Dar în această sarcină, acest lucru nu a fost economic viabil.

P.S. Aș dori să mă adresez și colegilor care au avut acest disc în mâinile lor anterior. Vă rog să fiți atenți când lucrați cu programul microdispozitivelor și să rezervați datele de serviciu înainte de a face orice modificare, precum și să nu permiteți agravarea intenționată a problemei, dacă nu ați reușit să conveniți cu clientul asupra realizării lucrărilor.

Publicația anterioară: Economisirea pe chibrituri sau recuperarea datelor din HDD-ul zgomotos Seagate ST3000NC002-1DY166

Sursa: habr.com

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster