2019 volt. Laboratóriumunk egy 9.1GB kapacitású QUANTUM FIREBALL Plus KA meghajtót kapott, ami korunkban nem egészen megszokott. A meghajtó tulajdonosa szerint a meghibásodás még 2004-ben történt egy meghibásodott tápegység miatt, amely magával vitte a merevlemezt és a többi PC-elemet is. Ezután számos szolgáltatást meglátogattak a meghajtó javítására és az adatok visszaállítására irányuló kísérletekkel, amelyek sikertelenek voltak. Egyes esetekben azt ígérték, hogy olcsó lesz, de soha nem oldották meg a problémát, máskor túl drága volt, és a kliens nem akarta visszaállítani az adatokat, de végül sok szervizen átment a lemez. Többször elveszett, de annak köszönhetően, hogy a tulajdonos előre gondoskodott arról, hogy a meghajtóra különböző matricákról információkat rögzítsen, sikerült elérnie, hogy néhány szervizből visszakerüljön merevlemeze. A séták nem múltak el nyomtalanul, az eredeti vezérlőtáblán többszörös forrasztási nyomok maradtak, és az SMD elemek hiánya vizuálisan is érezhető volt (előre tekintve elmondom, hogy ennek a meghajtónak ez a legkevesebb problémája).
Rizs. 1 HDD Quantum Fireball Plus KA 9,1 GB
Az első dolgunk volt, hogy az adományozó archívumában keressük ennek a meghajtónak egy ilyen ősi ikertestvérét egy működő vezérlőpanellel. Amikor ez a küldetés befejeződött, lehetővé vált kiterjedt diagnosztikai intézkedések végrehajtása. Miután ellenőriztük a motor tekercseinek rövidzárlatát és megbizonyosodtunk arról, hogy nincs-e rövidzárlat, a kártyát a donor hajtásról a beteghajtásra szereljük. Bekapcsoljuk a tápfeszültséget és halljuk a tengely felpörgésének normál hangját, átesünk egy kalibrációs teszten a firmware betöltésével, majd néhány másodperc múlva a hajtás regiszterekkel jelzi, hogy készen áll az interfész parancsaira.
Rizs. 2 DRD DSC jelzőfény jelzi, hogy készen áll a parancsok fogadására.
A firmware modulok összes másolatáról biztonsági másolatot készítünk. Ellenőrizzük a firmware modulok integritását. A modulok olvasásával nincs probléma, de a jelentések elemzése azt mutatja, hogy vannak furcsaságok.
Rizs. 3. Zóna táblázat.
Figyeljük a zónaelosztási táblázatot, és vegyük figyelembe, hogy a hengerek száma 13845.
Rizs. 4 P-lista (elsődleges lista – a gyártási ciklus során fellépő hibák listája).
Felhívjuk a figyelmet a túl kis számú hibákra és azok elhelyezkedésére. Megnézzük a gyári hibarejtő napló modult (60h), és azt találjuk, hogy üres és egyetlen bejegyzést sem tartalmaz. Ez alapján feltételezhetjük, hogy az előző szervizközpontok egyikében a meghajtó szervizterületével valamilyen manipulációt végeztek, és véletlenül vagy szándékosan idegen modult írtak, vagy az eredeti hibalistát. az egyiket kitisztították. Ennek a feltevésnek a teszteléséhez létrehozunk egy feladatot az Adatkivonatban, amelyben engedélyezve vannak a „szektoronkénti másolat létrehozása” és a „virtuális fordító létrehozása” opciók.
Rizs. 5 Feladat paraméterei.
A feladat létrehozása után megnézzük a partíciós tábla bejegyzéseit a nulladik szektorban (LBA 0)
Rizs. 6 Fő rendszerindító rekord és partíciós tábla.
A 0x1BE eltolásnál egyetlen bejegyzés található (16 bájt). A partíció fájlrendszerének típusa NTFS, eltolva a 0x3F (63) szektorok elejére, a partíció mérete 0x011309A3 (18 024 867).
A szektorszerkesztőben nyissa meg az LBA 63-at.
Rizs. 7 NTFS rendszerindító szektor
Az NTFS partíció boot szektorában található információk szerint a következőket mondhatjuk: a kötetben elfogadott szektorméret 512 bájt (a 0x0 (0) szót 0200x512B offsetre írjuk), a fürt szektorainak száma 8 (a 0x0 bájt 0x08D eltolásra van írva), a fürt mérete 512x8=4096 bájt, az első MFT rekord 6 291 519 szektornyi eltolásban található a lemez elejétől (0x30 négyszeres szó eltolása 0x00 00 00 00 00C 0 00 (00) az első MFT-klaszter száma.A szektorszám kiszámítása a következő képlettel történik: Klaszterszám * szektorok száma a klaszterben + eltolás a szekció elejéhez 786* 432+786= 432).
Térjünk át a 6 291 519 szektorra.
Fig. 8
De az ebben a szektorban található adatok teljesen eltérnek az MFT rekordtól. Ez ugyan egy hibás hibalista miatti esetleges hibás fordításra utal, de nem bizonyítja ezt a tényt. A további ellenőrzéshez a lemezt 10 000 szektorral olvassuk be mindkét irányban, 6 291 519 szektorhoz képest. És akkor keresni fogunk reguláris kifejezéseket az olvasottakban.
Rizs. 9 Első MFT felvétel
A 6 291 551 szektorban találjuk az első MFT rekordot. Pozíciója 32 szektorban tér el a számítotttól, majd egy 16 rekordból álló csoport (0-tól 15-ig) folyamatosan következik. Írjuk be a 6 291 519 szektor pozícióját a műszaktáblába, és lépjünk előre 32 szektorral.
Fig. 10
A 16. számú rekord pozíciója a 12 551 431 eltolásnál kell, hogy legyen, de ott az MFT rekord helyett nullákat találunk. Végezzünk el hasonló keresést a környéken.
Rizs. 11 MFT bejegyzés 0x00000011 (17)
A rendszer az MFT nagy töredékét észleli, a 17. számú rekordtól kezdve, 53 646 rekord hosszúsággal) 17 szektoros eltolással. A 12 155 431 pozícióhoz tegyen +17 szektor eltolódást a váltási táblázatba.
Az MFT-fragmensek térbeli helyzetének meghatározása után arra a következtetésre juthatunk, hogy ez nem tűnik véletlenszerű meghibásodásnak és az MFT-fragmensek helytelen eltolásokkal történő rögzítésének. A hibás fordítójú változat megerősítettnek tekinthető.
Az eltolási pontok további lokalizálásához beállítjuk a maximális lehetséges elmozdulást. Ehhez meghatározzuk, hogy az NTFS-partíció végjelzője (a rendszerindító szektor másolata) mennyivel tolódik el. A 7. ábrán 0x28 eltolásnál a négyszó a 0x00 00 00 00 01 13 09 A2 (18 024 866) szektorok partícióméretének értéke. Adjuk hozzá magának a partíciónak a lemez elejétől számított eltolását a hosszához, és megkapjuk az NTFS végjelző eltolását: 18 024 866 + 63= 18 024 929. Ahogy az várható volt, a rendszerindító szektor szükséges példánya nem volt ott. A környező terület keresése során +12 szektorral növekvő eltolódással találták az utolsó MFT-töredékhez képest.
Rizs. 12 Az NTFS rendszerindító szektor másolata
Figyelmen kívül hagyjuk a rendszerindító szektor másik példányát a 18 041 006 eltolásnál, mivel az nem kapcsolódik a partíciónkhoz. A korábbi tevékenységek alapján megállapítást nyert, hogy a szekción belül 61 szektor szerepeltetése „felbukkant” az adásban, ami bővítette az adatokat.
Elvégezzük a meghajtó teljes olvasását, amely 34 olvasatlan szektort hagy. Sajnos nem lehet megbízhatóan garantálni, hogy mindegyik a P-listáról eltávolított hiba, de a további elemzés során célszerű figyelembe venni a helyzetüket, mivel bizonyos esetekben a váltási pontok megbízhatóan meghatározhatók. a szektor pontossága, és nem a fájl.
Rizs. 13 Lemezolvasási statisztika.
Következő feladatunk a műszakok hozzávetőleges helyeinek megállapítása lesz (a fájl pontosságára, amelyben történtek). Ehhez az összes MFT rekordot átvizsgáljuk, és felállítjuk a fájlhelyek (fájltöredékek) láncait.
Rizs. 14 Fájlok vagy töredékeik helyének láncai.
Ezután fájlról fájlra haladva keressük azt a pillanatot, amikor a várt fájlfejléc helyett más adatok lesznek, és a kívánt fejléc bizonyos pozitív eltolódással meg fog találni. És ahogy finomítjuk a váltási pontokat, kitöltjük a táblázatot. A kitöltés eredménye a fájlok több mint 99%-a sérülésmentes lesz.
Rizs. 15 Felhasználói fájlok listája (az ügyfél beleegyezése érkezett a képernyőkép közzétételéhez)
Az egyes fájlok ponteltolódásainak megállapításához további munkát végezhet, és ha ismeri a fájl szerkezetét, megkeresheti a nem kapcsolódó adatok felvételeit. De ebben a feladatban ez gazdaságilag nem volt megvalósítható.
Ui. Szeretném megszólítani kollégáimat is, akiknek a kezében volt korábban ez a lemez. Kérjük, legyen óvatos, amikor az eszköz firmware-ével dolgozik, és készítsen biztonsági másolatot a szervizadatokról, mielőtt bármit megváltoztatna, és ne súlyosbítsa szándékosan a problémát, ha nem tudott megegyezni az ügyféllel a munkáról.
Forrás: will.com