Att gå genom plågor eller en lång historia om ett försök till dataräddning

Det var år 2019 och en något ovanlig lagringsenhet, QUANTUM FIREBALL Plus KA med en kapacitet på 9.1 GB, kom in i vårt laboratorium. Enligt innehavaren inträffade felet på grund av ett trasigt nätaggregat som skadade hårddisken och andra komponenter i datorn år 2004. Därefter började en rad försök att reparera enheten och återställa data, men dessa försök var utan framgång. Någonstans lovade de en billig lösning men lyckades inte lösa problemet, andra ställen ville ha för mycket och kunden valde att inte återställa data. Slutligen hade disken genomgått många servicecenter. Den försvann flera gånger, men tack vare att ägaren i förväg hade skrivit ner information från olika etiketter på enheten lyckades han se till att hans hårddisk återlämnades från vissa servicecenter. Allt detta lämnade spår, den originala kontrollerplattan hade flera lödfogar och det var också visuellt brist på SMD-komponenter (för att förhandsinformera så är detta den minsta av problemen med denna lagringsenhet).

Fig. 1 HDD Quantum Fireball Plus KA 9,1GB

Först var vi tvungna att leta efter en så gammal nykompis med en fungerande kontrollerplatta i donorarkivet. När detta äventyr var slutfört blev det möjligt att genomföra detaljerade diagnostiska tester. Efter att ha kontrollerat motorns lindningar för kortslutning och försäkrat oss om att det inte fanns någon, installerade vi donorens platta på patientens lagringsenhet. Vi ansluter ström och hör ett normalt ljud av axelrotation, genomgår kalibreringstestet med laddning av firmware, och efter några sekunder rapporterar lagringsenheten via register att den är redo att ta emot kommandon från gränssnittet.

Fig. 2 DRD DSC-indikatorerna visar beredskap att ta emot kommandon.

Vi reserverar alla kopior av firmwaremodulerna. Vi utför integritetskontroll av firmwaremodulerna. Inga problem uppstår vid läsning av modulerna, men analys av rapporterna visar att det finns vissa konstigheter.

Fig. 3. Zontabell.

Vi uppmärksammar zondistributions tabellen och noterar att antalet cylindrar är 13845.

Figur 4 P-list (primär lista – lista över defekter som registrerats under produktionscykeln).

Vi noterar det mycket lilla antalet defekter och deras lokalisering. Vi granskar modulen för att dölja fabriksdefekter (60h) och upptäcker att den är tom och saknar några poster. Baserat på detta kan vi anta att det i något av de tidigare servicecentren möjligtvis har gjorts vissa manipulationer med tjänstområdet på enheten, och antingen av misstag eller avsiktligt registrerades en annan modul, eller att defektlistan i originalet rensades. För att kontrollera denna hypotes skapar vi en uppgift i Data Extractor med aktiverade alternativ "skapa sektorspecifik kopia" och "skapa virtuell översättare".

Figur 5 Uppgifters inställningar.

När vi har skapat uppgiften granskar vi posterna i sektortabellen i den nollsektorn (LBA 0)

Figur 6 Huvudstartpost och sektortabell.

Vid offset 0x1BE finns en enda post (16 byte). Filsystemstypen på partitionen är NTFS, offset till början är 0x3F (63) sektorer, partitionens storlek är 0x011309A3 (18 024 867) sektorer.
I sektorredigeraren öppnar vi LBA 63.

Figur 7 Startsektor NTFS

Enligt informationen i startsektorn NTFS för partitionen kan följande sägas: sektorstorleken som antagits i volymen är 512 byte (vid offset 0x0B är ordet 0x0200 (512) registrerat), antalet sektorer per kluster är 8 (vid offset 0x0D är byte 0x08 registrerat), klusterstorleken är 512x8=4096 byte, den första MFT-posten ligger vid offset 6 291 519 sektorer från diskens början (vid offset 0x30 är det fyrdubbla ordet 0x00 00 00 00 00 0C 00 00 (786 432) nummer för den första klustret MFT. Sektorns nummer beräknas med formeln: Kluster nummer * antalet sektorer per kluster + offset till partitionens början 786 432* 8+63= 6 291 519).
Vi går till sektor 6 291 519.

Figur 8

Men de data som finns i denna sektor liknar överhuvudtaget inte en MFT-post. Detta indikerar visserligen en möjlig felaktig översättning på grund av den felaktiga defektlistan, men bevisar inte detta faktum. För ytterligare kontroll kommer vi att läsa disken i 10 000 sektorer i båda riktningarna relativt sektor 6 291 519. Och därefter kommer vi att göra sökningar av reguljära uttryck i det lästa.

Figur 9 Första MFT-posten

I sektor 6 291 551 hittar vi den första MFT-posten. Dess position avviker från beräknat med 32 sektorer, och därefter följer en grupp av 16 poster (från 0 till 15). Vi skriver i förskjutningstabellen positionen för sektor 6 291 519 för att flytta framåt med 32 sektorer.

Fig. 10

Positionen för post nr 16 bör vara med en förskjutning av 12 551 431, men där hittar vi nollor istället för MFT-poster. Vi gör en liknande sökning i omgivningarna.

Fig. 11 MFT-post 0x00000011 (17)

Ett stort MFT-fragment påträffas som börjar med posten nummer 17 med en längd av 53 646 poster) med en förskjutning på 17 sektorer. För positionen 12 155 431 sätter vi en förskjutning på +17 sektorer i förskjutningstabellen.
Genom att bestämma MFT-fragmentens position i utrymmet kan vi dra slutsatsen att detta inte verkar vara ett slumpmässigt fel och att inspelningen av MFT-fragment med felaktiga förskjutningar. Versionen med en felaktig översättare kan anses bekräftad.
För att vidare lokalisera förskjutningspunkterna ska vi ange den maximalt möjliga förskjutningen. För detta syfte bestämmer vi hur mycket den slutliga markören för NTFS-partitionen (kopian av startsektorn) har flyttats. På bild 7 med en förskjutning av 0x28 är fyrordet — detta är värdet på partitionsstorleken 0x00 00 00 00 01 13 09 A2 (18 024 866) sektorer. Vi lägger till förskjutningen av själva partitionen från skivans början till dess längd för att få den slutliga markörens NTFS-förskjutning 18 024 866 + 63= 18 024 929. Förväntat nog fanns inte den nödvändiga kopian av startsektorn där. Vid sökning i omgivningarna hittades den med en ökande förskjutning på +12 sektorer i förhållande till den senaste MFT-fragment.

Fig. 12 Kopia av NTFS-startsektorn

Den andra kopian av startsektorn vid förskjutning 18 041 006 ignorerar vi eftersom den inte har någon relation till vår partition. Baserat på tidigare åtgärder har det fastställts att det finns inslag av 'uppdykande' i översättningen av 61 sektorer inom partitionen, som har spridit ut data.
Vi utför en fullständig läsning av lagringsenheten, vilket resulterar i 34 olästa sektorer. Tyvärr kan vi inte med säkerhet garantera att alla dessa är defekter som tagits bort från P-listan, men vid vidare analys är det önskvärt att ta hänsyn till deras position, eftersom det i vissa fall går att exakt bestämma förskjutningspunkterna ner till sektor istället för till fil.

Fig. 13 Diskläsningsstatistik.

Vår nästa uppgift blir att fastställa de ungefärliga förskjutningspunkterna (med noggrannhet ner till filen där de uppstod). För detta kommer vi att skanna alla MFT-poster och bygga kedjor av filers placering (filfragment).

Fig. 14 Kedjor av filers placering, eller deras fragment.

Vidare, genom att gå från fil till fil, letar vi efter när andra data istället för den förväntade filrubriken visas, och den aktuella rubriken kommer att upptäckas med en viss positiv förskjutning. Och när vi preciserar förskjutningspunkterna fyller vi i tabellen. Resultatet av denna ifyllnad kommer att vara över 99 % av filerna utan skador.

Fig. 15 Lista över användarfiler (publikationen av denna skärmbild har godkänts av kunden)

För att fastställa punktförskjutningar i enskilda filer kan ytterligare arbete utföras och med kunskap om filstrukturen kan data som inte tillhör filen hittas. Men i denna uppgift var det inte ekonomiskt fördelaktigt.

P.S. Jag skulle också vilja be kollegor, som tidigare har haft denna disk i sina händer. Var vänlig var försiktig när ni arbetar med enhetens programvara och säkerhetskopiera tjänstedata innan ni gör några ändringar, och undvik att avsiktligt förvärra problemet om ni inte har kunnat nå en överenskommelse med kunden om att utföra arbetet.

Tidigare publikation: Att spara på tändstickor eller dataräddning från en skrapande HDD Seagate ST3000NC002-1DY166

Källa: habr.com