Det var 2019. Vores laboratorium modtog et QUANTUM FIREBALL Plus KA-drev med en kapacitet på 9.1 GB, hvilket ikke er helt almindeligt for vores tid. Ifølge ejeren af drevet opstod fejlen tilbage i 2004 på grund af en svigtet strømforsyning, som tog harddisken og andre pc-komponenter med sig. Derefter var der besøg på forskellige tjenester med forsøg på at reparere drevet og gendanne data, som ikke lykkedes. I nogle tilfælde lovede de, at det ville være billigt, men de løste aldrig problemet, i andre var det for dyrt, og klienten ønskede ikke at gendanne dataene, men til sidst gik disken igennem mange servicecentre. Den gik tabt flere gange, men takket være, at ejeren på forhånd sørgede for at registrere oplysninger fra forskellige klistermærker på drevet, lykkedes det ham at sikre, at hans harddisk blev returneret fra nogle servicecentre. Gåturene gik ikke sporløst, flere spor af lodning forblev på det originale controllerkort, og manglen på SMD-elementer kunne også mærkes visuelt (hvis jeg ser fremad, vil jeg sige, at dette er det mindste af problemerne med dette drev).
Ris. 1 HDD Quantum Fireball Plus KA 9,1GB
Det første, vi skulle gøre, var at søge i donorarkivet efter sådan en gammel tvillingebror til dette drev med et fungerende controllerkort. Da denne søgen var afsluttet, blev det muligt at udføre omfattende diagnostiske foranstaltninger. Efter at have kontrolleret motorviklingerne for kortslutning og sikret, at der ikke er kortslutning, installerer vi kortet fra donordrevet til patientdrevet. Vi tilfører strøm og hører den normale lyd af akslen, der snurrer op, består en kalibreringstest med indlæsning af firmwaren, og efter et par sekunder rapporterer drevet via registre, at det er klar til at reagere på kommandoer fra interfacet.
Ris. 2 DRD DSC-indikatorer angiver parathed til at modtage kommandoer.
Vi sikkerhedskopierer alle kopier af firmwaremoduler. Vi kontrollerer integriteten af firmwaremodulerne. Der er ingen problemer med at læse moduler, men analyse af rapporterne viser, at der er nogle særheder.
Ris. 3. Zonetabel.
Vi er opmærksomme på zonefordelingstabellen og bemærker, at antallet af cylindre er 13845.
Ris. 4 P-liste (primær liste – liste over defekter introduceret under produktionscyklussen).
Vi gør opmærksom på det for få antal fejl og deres placering. Vi kigger på fabriksfejl skjuler log-modulet (60h) og finder ud af, at det er tomt og ikke indeholder en enkelt post. Baseret på dette kan vi antage, at der i et af de tidligere servicecentre kan være foretaget nogle manipulationer med drevets serviceområde, og ved et uheld eller med vilje blev et fremmedmodul skrevet, eller listen over defekter i originalen den ene blev ryddet. For at teste denne antagelse opretter vi en opgave i Data Extractor med mulighederne "opret sektor-for-sektor kopi" og "opret virtuel oversætter" aktiveret.
Ris. 5 Opgaveparametre.
Efter at have oprettet opgaven ser vi på posterne i partitionstabellen i sektor nul (LBA 0)
Ris. 6 Master boot record og partitionstabel.
Ved offset 0x1BE er der en enkelt indgang (16 bytes). Filsystemtypen på partitionen er NTFS, forskudt til begyndelsen af 0x3F (63) sektorer, partitionsstørrelse 0x011309A3 (18) sektorer.
Åbn LBA 63 i sektoreditoren.
Ris. 7 NTFS boot sektor
Ifølge oplysningerne i NTFS-partitionens boot-sektor kan vi sige følgende: Sektorstørrelsen, der accepteres i volumen, er 512 bytes (ord 0x0 (0) er skrevet med offset 0200x512B), antallet af sektorer i klyngen er 8 (byte 0x0 skrives ved offset 0x08D), klyngestørrelsen er 512x8=4096 bytes, den første MFT-record er placeret ved en offset på 6 sektorer fra begyndelsen af disken (ved en offset på 291x519 firdobbelt ord 0x30 0 00 ) 00 00C 00 00 (0) nummer på den første MFT-klynge Sektornummeret beregnes ved formlen: Klyngenummer * antal sektorer i klyngen + offset til begyndelsen af afsnittet 00* 00+786= 432).
Lad os gå videre til sektor 6.
Fig. 8
Men de data, der er indeholdt i denne sektor, er helt forskellige fra MFT-posten. Selvom dette indikerer en mulig forkert oversættelse på grund af en forkert defektliste, beviser det ikke dette faktum. For yderligere at kontrollere, vil vi læse disken med 10 sektorer i begge retninger i forhold til 000 sektorer. Og så vil vi søge efter regulære udtryk i det, vi læser.
Ris. 9 Første MFT-optagelse
I sektor 6 finder vi den første MFT-rekord. Dens position adskiller sig fra den beregnede med 291 sektorer, og derefter følger en gruppe på 551 poster (fra 32 til 16) kontinuerligt. Lad os indtaste positionen for sektor 0 i skiftetabellen og bevæge os fremad med 15 sektorer.
Fig. 10
Positionen for post nr. 16 skulle være på offset 12, men vi finder nuller der i stedet for MFT-posten. Lad os foretage en lignende søgning i det omkringliggende område.
Ris. 11 MFT-indgang 0x00000011 (17)
Et stort fragment af MFT detekteres, startende med rekordnummer 17 med en længde på 53 poster) med et skift på 646 sektorer. For position 17 skal du sætte et skift på +12 sektorer i skifttabellen.
Efter at have bestemt positionen af MFT-fragmenter i rummet, kan vi konkludere, at dette ikke ligner en tilfældig fejl og registrering af MFT-fragmenter ved forkerte forskydninger. En version med en forkert oversætter kan betragtes som bekræftet.
For yderligere at lokalisere skiftepunkterne vil vi indstille den maksimalt mulige forskydning. For at gøre dette bestemmer vi, hvor meget slutmarkøren for NTFS-partitionen (kopi af opstartssektoren) forskydes. I figur 7, ved offset 0x28, er quadword partitionsstørrelsesværdien for 0x00 00 00 00 01 13 09 A2 (18) sektorer. Lad os tilføje forskydningen af selve partitionen fra begyndelsen af disken til dens længde, og vi får forskydningen af slutningen af NTFS-markøren 024 + 866= 18. Som forventet var den nødvendige kopi af opstartssektoren der ikke. Ved søgning i det omkringliggende område blev det fundet med et stigende skift på +024 sektorer i forhold til det sidste MFT-fragment.
Ris. 12 Kopi af NTFS boot sektor
Vi ignorerer den anden kopi af boot-sektoren ved offset 18, da den ikke er relateret til vores partition. På baggrund af tidligere aktiviteter blev det konstateret, at der inden for afsnittet er inklusioner af 041 sektorer, der "poppede op" i udsendelsen, hvilket udvidede dataene.
Vi udfører en fuld læsning af drevet, hvilket efterlader 34 ulæste sektorer. Desværre er det umuligt pålideligt at garantere, at alle af dem er defekter fjernet fra P-listen, men i yderligere analyse er det tilrådeligt at tage hensyn til deres position, da det i nogle tilfælde vil være muligt pålideligt at bestemme skiftepunkterne med en nøjagtighed af sektoren, og ikke filen.
Ris. 13 Disklæsningsstatistikker.
Vores næste opgave bliver at fastlægge de omtrentlige placeringer af skift (til nøjagtigheden af den fil, hvor de fandt sted). For at gøre dette vil vi scanne alle MFT-poster og bygge kæder af filplaceringer (filfragmenter).
Ris. 14 Kæder af placering af filer eller deres fragmenter.
Dernæst, går vi fra fil til fil, ser vi efter det øjeblik, hvor der vil være andre data i stedet for den forventede filheader, og den ønskede header vil blive fundet med et vist positivt skift. Og mens vi finpudser skiftepunkterne, udfylder vi tabellen. Resultatet af at fylde det vil være over 99% af filerne uden skade.
Ris. 15 Liste over brugerfiler (samtykke blev modtaget fra klienten til at offentliggøre dette skærmbillede)
For at etablere punktforskydninger i individuelle filer, kan du udføre yderligere arbejde og, hvis du kender strukturen af filen, finde indeslutninger af data, der ikke er relateret til den. Men i denne opgave var det ikke økonomisk muligt.
PS Jeg vil også gerne henvende mig til mine kolleger, i hvis hænder denne disk tidligere var. Vær forsigtig, når du arbejder med enhedens firmware og sikkerhedskopierer servicedata, før du ændrer noget, og du må ikke bevidst forværre problemet, hvis du ikke var i stand til at blive enig med klienten om arbejdet.
Kilde: www.habr.com