To był rok 2019. Nasze laboratorium otrzymało dysk QUANTUM FIREBALL Plus KA o pojemności 9.1 GB, co jak na nasze czasy nie jest zbyt częste. Według właściciela dysku awaria miała miejsce w 2004 roku na skutek awarii zasilacza, która zabrała ze sobą dysk twardy i inne podzespoły komputera. Potem były wizyty w różnych serwisach z próbami naprawy dysku i przywrócenia danych, które zakończyły się niepowodzeniem. W niektórych przypadkach obiecywali, że będzie tanio, ale nigdy nie rozwiązali problemu, w innych było za drogo i klient nie chciał przywracać danych, ale ostatecznie dysk przeszedł przez wiele serwisów. Kilkakrotnie zaginął, ale dzięki temu, że właściciel zadbał o wcześniejsze zapisanie informacji z różnych naklejek na dysku, udało mu się zapewnić zwrot dysku twardego z niektórych serwisów. Spacery nie minęły bez śladu, na oryginalnej płycie kontrolera pozostały liczne ślady lutowania, a brak elementów SMD też był odczuwalny wizualnie (patrząc w przyszłość powiem, że to najmniejszy z problemów tego napędu).
Ryż. 1 dysk twardy Quantum Fireball Plus KA 9,1 GB
Pierwszą rzeczą, którą musieliśmy zrobić, było wyszukanie w archiwum dawcy takiego starożytnego brata bliźniaka tego napędu z działającą płytą kontrolera. Po zakończeniu tego zadania możliwe stało się przeprowadzenie szeroko zakrojonych działań diagnostycznych. Po sprawdzeniu uzwojeń silnika pod kątem zwarcia i upewnieniu się, że nie ma zwarcia, montujemy płytkę od napędu dawcy do napędu pacjenta. Załączamy zasilanie i słyszymy normalny dźwięk rozkręcającego się wału, przechodzimy próbę kalibracyjną z wgraniem oprogramowania i po kilku sekundach napęd melduje po rejestrach, że jest gotowy do reagowania na polecenia z interfejsu.
Ryż. 2 wskaźniki DRD DSC sygnalizują gotowość do odbioru poleceń.
Wykonujemy kopie zapasowe wszystkich kopii modułów oprogramowania sprzętowego. Sprawdzamy integralność modułów oprogramowania układowego. Z odczytaniem modułów nie ma problemów, jednak analiza raportów pokazuje, że są pewne dziwactwa.
Ryż. 3. Tabela stref.
Zwracamy uwagę na tabelę dystrybucji strefowej i zauważamy, że liczba cylindrów wynosi 13845.
Ryż. 4 P-lista (lista pierwotna – lista wad wprowadzonych w cyklu produkcyjnym).
Zwracamy uwagę na zbyt małą liczbę usterek i ich lokalizację. Patrzymy na wadę fabryczną ukrywającą moduł dziennika (60h) i stwierdzamy, że jest on pusty i nie zawiera ani jednego wpisu. Na tej podstawie możemy założyć, że w jednym z poprzednich centrów serwisowych mogły zostać dokonane pewne manipulacje w obszarze serwisowym napędu i przypadkowo lub celowo został napisany obcy moduł lub lista usterek w oryginale jeden został oczyszczony. Aby przetestować to założenie, tworzymy zadanie w Data Extractorze z włączoną opcją „utwórz kopię sektor po sektorze” i „utwórz wirtualnego tłumacza”.
Ryż. 5 Parametry zadania.
Po utworzeniu zadania przeglądamy wpisy w tablicy partycji w sektorze zerowym (LBA 0)
Ryż. 6 Główny rekord rozruchowy i tablica partycji.
Przy przesunięciu 0x1BE znajduje się pojedynczy wpis (16 bajtów). Typ systemu plików na partycji to NTFS, przesunięty na początek sektorów 0x3F (63), rozmiar partycji 0x011309A3 (18 024 867) sektorów.
W edytorze sektorów otwórz LBA 63.
Ryż. 7 Sektor rozruchowy NTFS
Na podstawie informacji znajdujących się w sektorze rozruchowym partycji NTFS można powiedzieć, co następuje: rozmiar sektora akceptowany w wolumenie wynosi 512 bajtów (słowo 0x0 (0) jest zapisane pod offsetem 0200x512B), liczba sektorów w klastrze wynosi 8 (bajt 0x0 jest zapisywany z przesunięciem 0x08D), rozmiar klastra wynosi 512x8=4096 bajtów, pierwszy rekord MFT znajduje się w przesunięciu 6 291 519 sektorów od początku dysku (przy przesunięciu 0x30 poczwórnego słowa 0x00 00 00 00 00 0C 00 00 (786 432) numer pierwszego klastra MFT Numer sektora oblicza się ze wzoru: Numer klastra * liczba sektorów w klastrze + przesunięcie do początku sekcji 786 432* 8+63= 6 291 519).
Przejdźmy do sektora 6 291 519.
Rys.. 8
Ale dane zawarte w tym sektorze są zupełnie inne niż rekord MFT. Chociaż wskazuje to na możliwe błędne tłumaczenie spowodowane błędną listą defektów, nie potwierdza tego faktu. Aby dokładniej sprawdzić, odczytamy dysk po 10 000 sektorów w obu kierunkach w porównaniu do 6 291 519 sektorów. A potem będziemy szukać wyrażeń regularnych w tym, co czytamy.
Ryż. 9 Pierwsze nagranie MFT
W sektorze 6 291 551 znajdujemy pierwszy rekord MFT. Jego pozycja różni się od obliczonej o 32 sektory, po czym w sposób ciągły następuje grupa 16 rekordów (od 0 do 15). Wprowadźmy pozycję sektora 6 291 519 do tabeli przesunięć i przejdźmy do przodu o 32 sektory.
Rys.. 10
Pozycja rekordu nr 16 powinna znajdować się pod offsetem 12 551 431, ale zamiast rekordu MFT znajdziemy tam zera. Przeprowadźmy podobne poszukiwania w najbliższej okolicy.
Ryż. 11 wpis MFT 0x00000011 (17)
Wykryto duży fragment MFT, zaczynając od rekordu nr 17 o długości 53 646 rekordów) z przesunięciem o 17 sektorów. Dla pozycji 12 155 431 wpisz w tabeli przesunięć przesunięcie o +17 sektorów.
Po ustaleniu położenia fragmentów MFT w przestrzeni możemy stwierdzić, że nie wygląda to na przypadkową awarię i zapis fragmentów MFT w nieprawidłowych przesunięciach. Wersję z nieprawidłowym tłumaczem można uznać za potwierdzoną.
Aby dokładniej zlokalizować punkty przesunięcia, ustawimy maksymalne możliwe przemieszczenie. Aby to zrobić, określamy, o ile przesunięty jest znacznik końcowy partycji NTFS (kopia sektora rozruchowego). Na rysunku 7, przy przesunięciu 0x28, słowo quad jest wartością rozmiaru partycji sektorów 0x00 00 00 00 01 13 09 A2 (18 024 866). Dodajmy przesunięcie samej partycji od początku dysku do jej długości i otrzymamy przesunięcie końcowego znacznika NTFS 18 024 866 + 63 = 18 024 929. Zgodnie z oczekiwaniami nie było wymaganej kopii sektora rozruchowego. Podczas przeszukiwania okolicy stwierdzono rosnące przesunięcie o +12 sektorów w stosunku do ostatniego fragmentu MFT.
Ryż. 12 Kopia sektora rozruchowego NTFS
Ignorujemy drugą kopię sektora rozruchowego pod offsetem 18 041 006, ponieważ nie jest ona powiązana z naszą partycją. Na podstawie wcześniejszych działań ustalono, że w obrębie sekcji znajdują się uwzględnienia 61 sektorów, które „pojawiły się” w transmisji, co rozszerzyło dane.
Wykonujemy pełny odczyt dysku, który pozostawia 34 nieprzeczytane sektory. Niestety nie da się wiarygodnie zagwarantować, że wszystkie są defektami usuniętymi z listy P, jednak w dalszej analizie wskazane jest uwzględnienie ich położenia, gdyż w niektórych przypadkach będzie można wiarygodnie określić punkty przesunięcia za pomocą dokładność sektora, a nie pliku.
Ryż. 13 Statystyki odczytu dysku.
Naszym kolejnym zadaniem będzie ustalenie przybliżonych lokalizacji przesunięć (z dokładnością do pliku, w którym one wystąpiły). W tym celu przeskanujemy wszystkie rekordy MFT i zbudujemy łańcuchy lokalizacji plików (fragmentów plików).
Ryż. 14 Łańcuchy lokalizacji plików lub ich fragmentów.
Następnie, przechodząc od pliku do pliku, szukamy momentu, w którym zamiast oczekiwanego nagłówka pliku pojawią się inne dane, a pożądany nagłówek zostanie odnaleziony z pewnym dodatnim przesunięciem. A gdy udoskonalimy punkty przesunięcia, wypełniamy tabelę. Efektem jego zapełnienia będzie ponad 99% plików bez uszkodzeń.
Ryż. 15 Lista plików użytkownika (otrzymano zgodę klienta na publikację tego zrzutu ekranu)
Aby ustalić przesunięcia punktowe w poszczególnych plikach, możesz wykonać dodatkową pracę i, jeśli znasz strukturę pliku, znaleźć wtrącenia danych, które nie są z nią powiązane. Ale w tym zadaniu nie było to ekonomicznie wykonalne.
PS Zwracam się także do moich kolegów, w których rękach znajdowała się wcześniej ta płyta. Proszę zachować ostrożność podczas pracy z oprogramowaniem sprzętowym urządzenia i wykonać kopię zapasową danych serwisowych przed jakąkolwiek zmianą i nie pogłębiać celowo problemu, jeśli nie udało się uzgodnić pracy z klientem.
Źródło: www.habr.com