Det var 2019. Laboratoriet vårt mottok en QUANTUM FIREBALL Plus KA-stasjon med en kapasitet på 9.1 GB, noe som ikke er helt vanlig for vår tid. Ifølge eieren av stasjonen skjedde feilen tilbake i 2004 på grunn av en sviktet strømforsyning, som tok med seg harddisken og andre PC-komponenter. Deretter ble det besøk på ulike tjenester med forsøk på å reparere stasjonen og gjenopprette data, som ikke lyktes. I noen tilfeller lovet de at det ville være billig, men de løste aldri problemet, i andre var det for dyrt og klienten ønsket ikke å gjenopprette dataene, men til slutt gikk disken gjennom mange servicesentre. Den gikk tapt flere ganger, men takket være at eieren tok seg av å registrere informasjon fra ulike klistremerker på stasjonen på forhånd, klarte han å sørge for at harddisken hans ble returnert fra noen servicesentre. Turene gikk ikke uten spor, flere spor av lodding forble på det originale kontrollerkortet, og mangelen på SMD-elementer ble også følt visuelt (når jeg ser fremover, vil jeg si at dette er det minste av problemene med denne stasjonen).
Ris. 1 HDD Quantum Fireball Plus KA 9,1 GB
Det første vi måtte gjøre var å søke i giverarkivet etter en så eldgammel tvillingbror til denne stasjonen med et fungerende kontrollerkort. Da dette oppdraget var fullført, ble det mulig å gjennomføre omfattende diagnostiske tiltak. Etter å ha kontrollert motorviklingene for kortslutning og forsikret oss om at det ikke er kortslutning, installerer vi brettet fra donordrevet til pasientdrevet. Vi setter på strøm og hører den normale lyden av akselen som snurrer opp, passerer en kalibreringstest med lasting av fastvaren, og etter noen sekunder rapporterer stasjonen med registre at den er klar til å svare på kommandoer fra grensesnittet.
Ris. 2 DRD DSC-indikatorer indikerer klarhet til å motta kommandoer.
Vi sikkerhetskopierer alle kopier av fastvaremoduler. Vi sjekker integriteten til fastvaremodulene. Det er ingen problemer med å lese moduler, men analyse av rapportene viser at det er noen rariteter.
Ris. 3. Sonetabell.
Vi tar hensyn til sonefordelingstabellen og merker at antall sylindre er 13845.
Ris. 4 P-liste (primærliste – liste over feil introdusert i løpet av produksjonssyklusen).
Vi gjør oppmerksom på det for få antallet feil og deres plassering. Vi ser på loggmodulen for fabrikkfeil (60h) og finner at den er tom og ikke inneholder en eneste oppføring. Basert på dette kan vi anta at i et av de tidligere servicesentrene kan det ha blitt gjort noen manipulasjoner med stasjonens serviceområde, og ved et uhell eller med vilje ble en fremmedmodul skrevet, eller listen over defekter i originalen. en ble klarert. For å teste denne forutsetningen oppretter vi en oppgave i Data Extractor med alternativene "opprett sektor-for-sektor kopi" og "opprett virtuell oversetter" aktivert.
Ris. 5 Oppgaveparametere.
Etter å ha opprettet oppgaven, ser vi på oppføringene i partisjonstabellen i sektor null (LBA 0)
Ris. 6 Master boot record og partisjonstabell.
Ved offset 0x1BE er det en enkelt oppføring (16 byte). Filsystemtypen på partisjonen er NTFS, forskjøvet til begynnelsen av 0x3F (63) sektorer, partisjonsstørrelse 0x011309A3 (18) sektorer.
Åpne LBA 63 i sektoreditoren.
Ris. 7 NTFS oppstartssektor
I henhold til informasjonen i oppstartssektoren til NTFS-partisjonen kan vi si følgende: sektorstørrelsen som er akseptert i volumet er 512 byte (ord 0x0 (0) er skrevet med offset 0200x512B), antall sektorer i klyngen er 8 (byte 0x0 skrives ved offset 0x08D), klyngestørrelsen er 512x8=4096 byte, den første MFT-posten er plassert i en offset på 6 291 519 sektorer fra begynnelsen av disken (med en offset på 0x30 firedoblet ord 0x00 00 00 00 00C 0 00 (00 786) nummeret til den første MFT-klyngen Sektornummeret beregnes med formelen: Klyngenummer * antall sektorer i klyngen + offset til begynnelsen av seksjonen 432 786* 432+8= 63 6 291).
La oss gå videre til sektor 6 291 519.
Fig. 8
Men dataene i denne sektoren er helt forskjellige fra MFT-posten. Selv om dette indikerer en mulig feil oversettelse på grunn av en feil defektliste, beviser det ikke dette faktum. For ytterligere å sjekke, vil vi lese disken med 10 000 sektorer i begge retninger i forhold til 6 291 519 sektorer. Og så skal vi søke etter regulære uttrykk i det vi leser.
Ris. 9 Første MFT-opptak
I sektor 6 291 551 finner vi den første MFT-posten. Posisjonen er forskjellig fra den beregnede med 32 sektorer, og deretter følger en gruppe på 16 poster (fra 0 til 15) kontinuerlig. La oss legge inn posisjonen til sektor 6 291 519 i skifttabellen og gå fremover med 32 sektorer.
Fig. 10
Posisjonen til post nr. 16 skal være på offset 12, men vi finner null der i stedet for MFT-posten. La oss gjennomføre et lignende søk i området rundt.
Ris. 11 MFT-oppføring 0x00000011 (17)
Et stort fragment av MFT blir oppdaget, starter med rekord nummer 17 med en lengde på 53 646 poster) med en forskyvning på 17 sektorer. For posisjon 12, sett et skifte på +155 sektorer i skiftetabellen.
Etter å ha bestemt posisjonen til MFT-fragmenter i rommet, kan vi konkludere med at dette ikke ser ut som en tilfeldig feil og registrering av MFT-fragmenter ved feil forskyvninger. En versjon med feil oversetter kan anses som bekreftet.
For ytterligere å lokalisere skiftpunktene vil vi sette maksimalt mulig forskyvning. For å gjøre dette bestemmer vi hvor mye sluttmarkøren til NTFS-partisjonen (kopi av oppstartssektoren) forskyves. I figur 7, ved offset 0x28, er firordet partisjonsstørrelsesverdien til 0x00 00 00 00 01 13 09 A2 (18) sektorer. La oss legge til forskyvningen av selve partisjonen fra begynnelsen av disken til dens lengde, og vi får forskyvningen av slutten av NTFS-markøren 024 866 18 + 024= 866 63 18. Som forventet var den nødvendige kopien av oppstartssektoren ikke der. Ved søk i området rundt ble det funnet med en økende forskyvning på +024 sektorer i forhold til det siste MFT-fragmentet.
Ris. 12 Kopi av NTFS-oppstartssektoren
Vi ignorerer den andre kopien av oppstartssektoren ved offset 18, siden den ikke er relatert til partisjonen vår. Basert på tidligere aktiviteter ble det konstatert at det innenfor seksjonen er inkluderinger av 041 sektorer som «spratt opp» i sendingen, noe som utvidet dataene.
Vi utfører en fullstendig lesing av stasjonen, som etterlater 34 uleste sektorer. Dessverre er det umulig å pålitelig garantere at alle av dem er defekter fjernet fra P-listen, men i videre analyse er det tilrådelig å ta hensyn til deres posisjon, siden det i noen tilfeller vil være mulig å pålitelig bestemme skiftepunktene med en nøyaktighet av sektoren, og ikke filen.
Ris. 13 Disklesingsstatistikk.
Vår neste oppgave vil være å fastslå de omtrentlige plasseringene til skiftene (til nøyaktigheten til filen der de skjedde). For å gjøre dette vil vi skanne alle MFT-poster og bygge kjeder av filplasseringer (filfragmenter).
Ris. 14 Kjeder med plassering av filer eller fragmenter.
Deretter, ved å gå fra fil til fil, ser vi etter øyeblikket da det vil være andre data i stedet for den forventede filoverskriften, og den ønskede overskriften vil bli funnet med et visst positivt skift. Og mens vi finpusser skiftpoengene, fyller vi ut tabellen. Resultatet av å fylle det vil være over 99% av filene uten skade.
Ris. 15 Liste over brukerfiler (samtykke ble mottatt fra klienten til å publisere dette skjermbildet)
For å etablere punktforskyvninger i individuelle filer, kan du utføre tilleggsarbeid og, hvis du kjenner strukturen til filen, finne inkluderinger av data som ikke er relatert til den. Men i denne oppgaven var det ikke økonomisk gjennomførbart.
PS Jeg vil også henvende meg til mine kolleger, hvis hender denne platen var i tidligere. Vær forsiktig når du arbeider med enhetens fastvare og sikkerhetskopierer tjenestedata før du endrer noe, og ikke bevisst forverre problemet hvis du ikke var i stand til å bli enig med klienten om arbeidet.
Kilde: www.habr.com