Det var 2019. Vores laboratorium modtog et QUANTUM FIREBALL Plus KA-drev med en kapacitet på 9.1 GB, hvilket ikke er helt typisk for vores tid. Ifølge ejeren af drevet opstod fejlen tilbage i 2004 på grund af en defekt strømforsyning, som tog harddisken og andre pc-komponenter med sig. Derefter var der besøg hos forskellige servicecentre med forsøg på at reparere drevet og gendanne data, hvilket ikke lykkedes. Et sted lovede de billigt, men løste aldrig problemet, et sted var det for dyrt, og klienten ønskede ikke at gendanne dataene, men til sidst gik drevet gennem mange servicecentre. Det gik tabt flere gange, men takket være det faktum, at ejeren sørgede for at registrere information fra forskellige klistermærker på drevet på forhånd, lykkedes det ham at få sin harddisk returneret fra nogle servicecentre. Turene gik ikke uden spor, på det originale controllerboard var der flere spor af lodning, og også en visuel mangel på SMD-elementer var mærkbar (fremadrettet vil jeg sige, at dette er det mindste af problemerne med dette drev).
Ris. 1 HDD Quantum Fireball Plus KA 9,1 GB
Det første vi skulle gøre var at søge i donorarkivet efter en så gammel tvillingebror til dette drev med et fungerende styrekort. Da denne søgen var afsluttet, blev det muligt at udføre detaljerede diagnostiske foranstaltninger. Efter at have kontrolleret motorviklingerne for kortslutning og sikret os, at der ikke var nogen, installerede vi kortet fra donordrevet på patientdrevet. Vi tilslutter strøm og hører den normale lyd af akslen, der drejer op, kalibreringstesten med indlæsning af firmwaren, og efter et par sekunder rapporterer drevet via registre, at det er klar til at reagere på kommandoer fra grænsefladen.
Fig. 2 DRD DSC-indikatorer angiver, om de er klar til at modtage kommandoer.
Vi sikkerhedskopierer alle kopier af firmwaremodulerne. Vi udfører en kontrol af firmwaremodulernes integritet. Der er ingen problemer med at læse modulerne, men analysen af rapporterne viser, at der er nogle mærkværdigheder.
Fig. 3. Tabel over zoner.
Vi er opmærksomme på zonefordelingstabellen og bemærker, at antallet af cylindre er 13845.
Fig. 4 P-liste (primær liste – en liste over defekter, der er opstået i løbet af produktionscyklussen).
Vi er opmærksomme på det lille antal defekter og deres lokalisering. Vi gennemgår modulloggen over skjulte fabriksdefekter (60 timer) og finder ud af, at den er tom og ikke indeholder en eneste post. Baseret på dette kan vi antage, at nogle manipulationer med drevets serviceområde sandsynligvis blev udført i et af de tidligere servicecentre, og at en andens modul ved et uheld eller forsætligt blev skrevet, eller at listen over defekter i originalen blev slettet. For at kontrollere denne antagelse opretter vi en opgave i Data Extractor med mulighederne "opret en sektor-for-sektor-kopi" og "opret en virtuel oversætter" aktiveret.
Fig. 5 Opgaveparametre.
Når vi har oprettet opgaven, ser vi posterne i partitionstabellen i nulsektoren (LBA 0)
Fig. 6 Master boot record og partitionstabel.
Ved offset 0x1BE er der en enkelt indgang (16 bytes). Filsystemtypen på partitionen er NTFS, offset til starten er 0x3F (63) sektor, partitionsstørrelsen er 0x011309A3 (18) sektorer.
I sektoreditoren skal du åbne LBA 63.
Figur 7 NTFS-opstartssektor
Ifølge oplysningerne i NTFS-partitionens boot-sektor kan følgende siges: Sektorstørrelsen, der er valgt i diskenheden, er 512 bytes (ordet 0x0 (0) skrives ved offset 0200x512B), antallet af sektorer i en klynge er 8 (byte 0x0 skrives ved offset 0x08D), klyngestørrelsen er 512x8 = 4096 bytes, den første MFT-post er placeret ved offset 6 sektorer fra starten af disken (ved offset 291x519 er det firdobbelte ord 0x30 0 00 00 00 00C 00 0 (00) nummeret på den første MFT-klynge. Sektornummeret beregnes ved hjælp af formlen: Klyngenummer * antal sektorer i en klynge + offset til starten af partitionen 00 * 786 + 432 = 786).
Går videre til sektor 6 291 519.
Fig. 8
Men dataene i denne sektor er fuldstændig forskellige fra MFT-posten. Selvom dette indikerer en mulig forkert oversættelse på grund af en forkert defektliste, beviser det ikke denne kendsgerning. For yderligere verifikation vil vi læse disken med 10 sektorer i begge retninger i forhold til sektor 000. Og derefter vil vi søge efter regulære udtryk i det, vi læser.
Fig. 9 Første MFT-post
I sektor 6 291 551 finder vi den første MFT-post. Dens position afviger fra den beregnede med 32 sektorer, og derefter følger en gruppe på 16 poster (fra 0 til 15) kontinuerligt. Vi skriver positionen for sektor 6 291 519 i forskydningstabellen og forskyder den fremad med 32 sektorer.
Fig. 10
Positionen for post #16 burde være ved offset 12, men vi finder nuller der i stedet for MFT-posten. Lad os lave en lignende søgning i det omkringliggende område.
Fig. 11 MFT-post 0x00000011 (17)
Et stort MFT-fragment findes, startende med postnummer 17 (53 poster langt) med en forskydning på 646 sektorer. For position 17 har vi placeret en forskydning på +12 sektorer i forskydningstabellen.
Efter at have bestemt MFT-fragmenternes position i rummet, kan vi konkludere, at dette ikke ligner en tilfældig fejl og optagelse af MFT-fragmenter ved forkerte forskydninger. Versionen med en forkert oversætter kan betragtes som bekræftet.
For yderligere lokalisering af skiftpunkter indstiller vi den maksimalt mulige forskydning. For at gøre dette bestemmer vi, hvor meget NTFS-partitionens slutmarkør (bootsektorkopi) er forskudt. I figur 7, ved forskydning 0x28, er quadwordet partitionsstørrelsesværdien 0x00 00 00 00 01 13 09 A2 (18 024 866) sektorer. Vi lægger forskydningen af selve partitionen fra starten af disken til dens længde for at få forskydningen af NTFS-slutmarkøren 18 024 866 + 63 = 18 024 929. Som forventet var den nødvendige bootsektorkopi ikke der. Ved søgning i nærheden blev den fundet med en stigende forskydning på +12 sektorer i forhold til det sidste MFT-fragment.
Fig. 12 Kopi af NTFS-opstartssektoren
Vi ignorerer en anden kopi af boot-sektoren ved offset 18 041 006, da den ikke har nogen relation til vores sektion. Baseret på tidligere aktiviteter blev det fastslået, at der inden for sektionen er inkluderinger fra de 61 sektorer, der "opstod" i oversættelsen, hvilket flyttede 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 disse er defekter, der er fjernet fra P-listen, men under yderligere analyse er det tilrådeligt at tage deres position i betragtning, da det i nogle tilfælde vil være muligt pålideligt at bestemme skiftpunkter med en nøjagtighed på op til en sektor og ikke op til en fil.
Fig. 13 Statistik over disklæsning.
Vores næste opgave bliver at fastslå omtrentlige placeringer af forskydninger (med nøjagtighed op til den fil, hvor de fandt sted). For at gøre dette vil vi scanne alle MFT-poster og opbygge filplaceringskæder (filfragmenter).
Fig. 14. Kæder af filplaceringer eller deres fragmenter.
Dernæst, når vi går fra fil til fil, leder vi efter det øjeblik, hvorfra der i stedet for den forventede filheader vil være andre data, og den ønskede header vil blive fundet med en positiv forskydning. Og når vi angiver forskydningspunkterne, udfylder vi tabellen. Resultatet af at udfylde den vil være over 99% af filerne uden skader.
Fig. 15 Liste over brugerfiler (klienten har givet samtykke til at offentliggøre dette skærmbillede)
For at fastslå punktforskydninger i individuelle filer kan der udføres yderligere arbejde, og givet filstrukturen kan der findes datainkluderinger, der ikke er relateret til den. Det var dog ikke økonomisk rentabelt i denne opgave.
P.S. Jeg vil også gerne henvende mig til kolleger, der har håndteret denne disk før. Vær forsigtig, når du arbejder med enhedernes firmware, og sikkerhedskopier servicedata, før du ændrer noget, og lad ikke problemet blive bevidst forværret, hvis du ikke har kunnet blive enig med klienten om det arbejde, der skal udføres.
Kilde: www.habr.com
