A 2019-es évben jártunk. A laboratóriumunkba érkezett egy nem mindennapi adattároló, a QUANTUM FIREBALL Plus KA, 9,1 GB kapacitással. A tároló tulajdonosának elmondása szerint a meghibásodás 2004 táján következett be, miután a tápegység tönkrement, ami magával rántotta a merevlemezt és más PC komponenseket. Ezt követően különféle szervizekbe járt a tároló javítási és adatmentési próbálkozások céljából, amelyek nem bizonyultak sikeresnek. Valahol olcsón ígérték, de végül nem oldották meg a problémát, máshol túl drágán kínálták a megoldást, ezért a kliens végül nem akarta helyreállítani az adatokat, de végül a merevlemez számos szervizközpont útját bejárta. Többször is elveszett, de a tulajdonosnak köszönhetően, aki előrelátóan gondoskodott az adattárolón lévő különféle matricák információinak rögzítéséről, sikerült elérnie, hogy a merevlemeze vissza legyen adva néhány szervizközpontból. Ez a kóborlás nem múlt el nyomtalanul, az eredeti vezérlőlapján számos forrasztás nyomai maradtak, valamint vizuálisan is érzékelhető volt az SMD elemek hiánya (az előreugróban megjegyzem, hogy ez a tároló legkisebb problémája).
1. ábra: HDD Quantum Fireball Plus KA 9,1 GB
Első lépésként dolgoznunk kellett a donorarchívumban ennek a tárolónak a régi, ikertestvérének a hibátlan vezérlőlapjának felkutatásán. Miután a küldetés teljesítve lett, lehetővé vált a részletes diagnosztikai tevékenységek elvégzése. Ellenőriztük a motortekercseket rövidzárlat szempontjából, és megbizonyosodtunk arról, hogy ilyen nincs, majd a donor tárolóról áthelyeztük a lapkát a beteg tárolóra. Áramot adtunk rá, és hallottuk a normális rotorforgás hangját, a kalibrációs teszt sikeres volt a mikroprogram betöltésével, és néhány másodperc múlva a tároló a regiszterekben arról számolt be, hogy kész válaszolni az interfész parancsaira.
2. ábra: A DRD DSC jelzőfények a parancsok fogadásának készenlétét jelzik.
Minden mikroprogram-modul másolatát lementjük. Ellenőrizzük a mikroprogram-modulok integritását. A modulok olvasásával nincs probléma, de a jelentések elemzése furcsaságokat mutat.
3. ábra: Zóna táblázat.
Figyelembe vesszük a zónabeosztás táblázatát, és észrevesszük, hogy a hengerek száma 13845.
4. ábra P-list (elsődleges lista – a gyártási ciklus során felmerült hibák listája).
Felhívjuk a figyelmet a túl alacsony hiba számra és azok lokalizációjára. Megvizsgáljuk a gyári hibák rejtett naplózási modulját (60h), és észleljük, hogy az üres és nem tartalmaz egyetlen bejegyzést sem. Ebből feltételezhetjük, hogy valamelyik korábbi szervizközpontban esetleg manipulálták a tároló kezelői zónáját, és véletlenül vagy szándékosan feljegyeztek egy idegen modult, vagy törölték az eredeti hibalistát. Ennek a feltételezésnek a ellenőrzéséhez létrehozunk egy feladatot a Data Extractorban, a "szektor-specifikus másolat készítése" és "virtuális fordító készítése" opciókkal.
5. ábra A feladat paraméterei.
A feladat létrehozása után megvizsgáljuk a bejegyzéseket a nulla szektor (LBA 0) partíció táblázatában.
6. ábra Fő betöltési bejegyzés és partíció tábla.
A 0x1BE eltolásnál található egyetlen bejegyzés (16 bájt). A partíció fájlrendszer típusa – NTFS, az eltolás a kezdethez 0x3F (63) szektor, a partíció mérete 0x011309A3 (18 024 867) szektor.
A szektor szerkesztőjében megnyitjuk az LBA 63-at.
7. ábra NTFS boot szektor
Az NTFS boot szektor információi alapján a következőket állapíthatjuk meg: a kötetben alkalmazott szektor mérete 512 bájt (az eltolás 0x0B-nál a 0x0200 (512) szót rögzítették), a clusterben lévő szektorok száma 8 (az eltolás 0x0D-nál a 0x08 bájtot rögzítették), a cluster mérete 512x8=4096 bájt, az első MFT bejegyzés elhelyezkedik a lemez elejétől 6 291 519 szektor távolságra (az eltolás 0x30-nál a 0x00 00 00 00 00 0C 00 00 (786 432) az első MFT cluster száma. A szektor száma az alábbi képlet alapján számítható: cluster száma * a clusterben lévő szektorok száma + az eltolás a partíció kezdetéhez 786 432* 8+63= 6 291 519).
Átmegyünk a 6 291 519. szektorba.
8. ábra
De a 6 291 519. szektorban található adatok egyáltalán nem hasonlítanak az MFT bejegyzésre. Ez arra utal, hogy esetleg hibás fordítás történt a nem megfelelő hibalista miatt, de ezt a tényt nem bizonyítja. További ellenőrzés céljából a lemez olvasását végezzük 10 000 szektorban mindkét irányban a 6 291 519. szektortól. Ezután szöveges keresést végzünk az olvasott adatokban.
9. ábra Az első MFT bejegyzés
A 6 291 551-es szektorban felfedezzük az első MFT bejegyzést. A helyzete a számítotthoz képest 32 szektorral tér el, és ezután folyamatosan egy 16 bejegyzésből álló csoport következik (0-tól 15-ig). Írjuk be a helyzeti eltérés táblázatába a 6 291 519-es szektor helyzetét, előre tolt 32 szektorral.
Ábra. 10
A 16. bejegyzés helyzete a 12 551 431-es eltoláson kell, hogy legyen, de ott nullákat találunk az MFT bejegyzés helyett. Hasonló keresést végezünk a környező területeken.
Ábra. 11 MFT bejegyzés 0x00000011 (17)
Megtalálunk egy nagy MFT töredéket, amely a 17. számú bejegyzéssel kezdődik, 53 646 bejegyzéssel) és 17 szektorral eltolva. A 12 155 431-es pozícióhoz 17 szektort adva rögzítjük az eltolást a táblában.
Az MFT töredékek helyének meghatározásával arra a következtetésre juthatunk, hogy ez nem tűnik véletlenszerű hibának, és az MFT töredékek nem megfelelő eltolások szerint lettek rögzítve. A nem megfelelő transzlátorról szóló verziót megerősítettnek lehet tekinteni.
A további eltolások lokalizálásához meg kell határozni a maximálisan lehetséges eltolást. Ehhez állapítsuk meg, hogy mennyire van eltolva az NTFS partíció végső jelzője (a boot szektor másolata). A 7. ábrán az 0x28-ás eltolásnál a négy szavas érték a partíció mérete 0x00 00 00 00 01 13 09 A2 (18 024 866) szektor. Az eltolás kezdeti hossza 18 024 866 + 63 = 18 024 929. Várhatóan itt nem találtuk meg a szükséges boot szektor másolatát. A környező területek keresése során az egyre növekvő +12 szektorral az utolsó MFT töredékhez képest lett felfedezve.
Ábra. 12 Az NTFS boot szektor másolata
A 18 041 006-os eltoláson található másik boot szektor másolatát figyelmen kívül hagyjuk, mivel az nem kapcsolódik a mi partíciónkhoz. Az előző intézkedések alapján megállapítottuk, hogy a partíción belül vannak „felbukkant” nyomok a 61 szektoros transzlációkból, amelyek széthúzták az adatokat.
Teljes leolvasást végzünk az adathordozón, amelynek eredményeként 34 olvasatlan szektor marad. Sajnos nem lehet megbízhatóan garantálni, hogy ezek mind hibák a P-listából, de a további elemzés során érdemes figyelembe venni a helyüket, mivel bizonyos esetekben megbízhatóan meghatározhatjuk az eltolások pontjait szektor pontossággal, nem pedig fájl szinten.
Ábra. 13 A lemez olvasási statisztikája.
A következő feladatunk az elmozdulási helyek megállapítása lesz (a fájl pontos helyével). Ehhez beolvassuk az összes MFT bejegyzést, és felépítjük a fájlok (fájlfragmentumok) helyezési láncát.
14. ábra A fájlok, vagy azok fragmentumai helyezési láncai.
Ezután, fájlról fájlra haladva, keressük, hogy melyik ponttól kezdve a várt fájlfejléc helyett más adatokat találunk, míg a megfelelő fejléc egy pozitív elmozdulással jelenik meg. A pontos elmozdulási pontok meghatározásával kitöltjük a táblázatot. Ennek kitöltése több mint 99%-os hibátlan fájlokat eredményez.
15. ábra A felhasználói fájlok listája (a képernyőkép közzétételére a kliens beleegyezését kaptuk)
A pontszerű elmozdulások meghatározása érdekében egyes fájlokban további munkákat lehet végezni, és a fájl struktúrájának ismeretében olyan adatbefecskendezéseket találni, amelyek nem kapcsolódnak hozzá. Azonban a feladat szempontjából ez nem volt gazdaságilag ésszerű.
P.S. Szeretném felhívni a figyelmet azokra a kollégákra, akiknek a kezében ez a lemez korábban volt. Kérlek, legyetek óvatosak a készülékek firmware-jével való munka során, és készítsétek el a szolgáltatási adatokat, mielőtt bármit megváltoztatnátok, valamint ne súlyosbítsátok szándékosan a problémát, ha nem sikerült megállapodnotok a klienssel a munka elvégzéséről.
Forrás: habr.com
