Był rok 2019. Do naszej laboratorium trafił dość nietypowy jak na nasze czasy nośnik QUANTUM FIREBALL Plus KA o pojemności 9,1 GB. Z informacji właściciela wynika, że awaria miała miejsce w dalekim 2004 roku z powodu uszkodzonego zasilacza, który pociągnął za sobą twardy dysk i inne komponenty PC. Następnie były wędrówki po różnych serwisach w próbach naprawy nośnika i odzyskania danych, które nie przyniosły sukcesu. Gdzieś obiecywano tanio, ale problemu nie rozwiązano, gdzieś było zbyt drogo i klient nie chciał odzyskiwać danych, ale w końcu dysk przeszedł przez wiele centrów serwisowych. Wielokrotnie gubiono go, ale dzięki temu, że właściciel wcześniej zadbał o zapisanie informacji z różnych naklejek na nośniku, udało mu się uzyskać, aby jego twardy dysk został zwrócony z niektórych centrów serwisowych. Wędrówki nie były bez śladów, na oryginalnej płycie kontrolera pozostało wiele śladów lutowania, a także wizualnie odczuwano brak elementów SMD (z przekątnej powiem, że to najmniejszy z problemów tego nośnika).
Rys. 1 HDD Quantum Fireball Plus KA 9,1GB
Na początku konieczne było poszukiwanie w archiwum donorów tak starego brata-bliźniaka tego nośnika z sprawną płytą kontrolera. Kiedy ta misja została zakończona, możliwe było przeprowadzenie szczegółowych prac diagnostycznych. Sprawdzając uzwojenia silnika pod kątem zwarcia i upewniając się, że go nie ma, montujemy płytę z nośnika-donora na nośnik-pacjenta. Podłączamy zasilanie i słyszymy normalny dźwięk rozkręcania wału, przechodzenie testu kalibracyjnego z załadowaniem mikrokodu, a po kilku sekundach nośnik raportuje w rejestrach gotowość do reagowania na polecenia z interfejsu.
Rys. 2 Wskaźniki DRD DSC oznaczają gotowość do przyjmowania poleceń.
Rezerwujemy wszystkie kopie modułów mikrokodu. Przeprowadzamy kontrolę integralności modułów mikrokodu. Nie ma problemów z odczytem modułów, ale analiza raportów pokazuje, że występują pewne dziwności.
Rys. 3. Tabela stref.
Zwracamy uwagę na tabelę rozdzielenia strefowego, zauważając, że liczba cylindrów wynosi 13845.
Rys. 4 Lista P (primary list – lista wad zgłoszonych podczas cyklu produkcyjnego).
Zwracamy uwagę na zbyt małą liczbę wad i ich lokalizację. Przeglądamy moduł logu ukrywania fabrycznych wad (60h) i stwierdzamy, że jest pusty i nie zawiera żadnych zapisów. Na tej podstawie możemy przypuszczać, że w jednym z wcześniejszych serwisów mogły być wprowadzane pewne manipulacje z obszarem serwisowym dysku, a przypadkowo lub celowo zapisano obcy moduł lub wyczyszczono listę wad w oryginalnym. Aby zweryfikować to przypuszczenie, tworzymy zadanie w Data Extractor z włączonymi opcjami „utworzenie kopii sektorowej” i „utworzenie wirtualnego translatora”.
Rys. 5 Parametry zadania.
Tworząc zadanie, przeglądamy zapisy w tabeli partycji w zerowym sektorze (LBA 0).
Rys. 6 Główna tabela rozruchowa i tabela partycji.
Na przesunięciu 0x1BE znajduje się jedyny zapis (16 bajtów). Typ systemu plików w partycji – NTFS, przesunięcie do początku 0x3F (63) sektora, rozmiar partycji 0x011309A3 (18 024 867) sektorów.
W edytorze sektorów otwieramy LBA 63.
Rys. 7 Sektor rozruchowy NTFS.
Z informacji w sektorze rozruchowym NTFS partycji można powiedzieć, że rozmiar sektora przyjęty w woluminie to 512 bajtów (na przesunięciu 0x0B zapisano słowo 0x0200 (512)), liczba sektorów w klastrze wynosi 8 (na przesunięciu 0x0D zapisano bajt 0x08), rozmiar klastra wynosi 512x8=4096 bajtów, pierwszy zapis MFT znajduje się na przesunięciu 6 291 519 sektorów od początku dysku (na przesunięciu 0x30 zapisane jest słowo 0x00 00 00 00 00 0C 00 00 (786 432) numer pierwszego klastra MFT. Numer sektora oblicza się według wzoru: Numer klastra * liczba sektorów w klastrze + przesunięcie do początku partycji 786 432* 8+63= 6 291 519).
Przechodzimy do sektora 6 291 519.
Rys. 8
Jednak dane zawarte w tym sektorze zupełnie nie przypominają zapisu MFT. Chociaż wskazuje to na możliwą niepoprawną translację z powodu błędnej listy wad, nie dowodzi to tego faktu. W celu dalszej weryfikacji przeprowadzimy odczyt dysku w odległości 10 000 sektorów w obu kierunkach względem sektora 6 291 519. Następnie przeprowadzimy wyszukiwanie wyrażeń regularnych w odczytanym.
Rys. 9 Pierwszy zapis MFT
W sektorze 6 291 551 odkrywamy pierwszy wpis MFT. Jego położenie różni się od obliczonego o 32 sektory, a następnie nieprzerwanie występuje grupa 16 wpisów (od 0 do 15). Zapiszemy w tabeli przesunięć położenie sektora 6 291 519 przesunięte do przodu o 32 sektory.
Rys. 10
Położenie wpisu nr 16 powinno wynosić według przesunięcia 12 551 431, ale tam odkrywamy zera, zamiast wpisu MFT. Przeprowadzimy podobne wyszukiwanie w okolicy.
Rys. 11 Wpis MFT 0x00000011 (17)
Odkryto duży fragment MFT, zaczynający się od wpisu nr 17 o długości 53 646 wpisów, z przesunięciem 17 sektorów. Dla pozycji 12 155 431 w tabeli przesunięć wstawimy przesunięcie +17 sektorów.
Określając położenie fragmentów MFT w przestrzeni, możemy stwierdzić, że nie przypomina to przypadkowej awarii, a zapis fragmentów MFT z niepoprawnymi przesunięciami. Wersja z niepoprawnym translatorzem może być uznana za potwierdzoną.
Aby kontynuować lokalizację punktów przesunięć, ustalimy maksymalne możliwe przesunięcie. W tym celu określimy, jak mocno przesunięty jest końcowy wskaźnik partycji NTFS (kopiowany sektor rozruchowy). Na rysunku 7 według przesunięcia 0x28 czteroznakowy wyraz — to wartość rozmiaru partycji 0x00 00 00 00 01 13 09 A2 (18 024 866) sektorów. Dodamy przesunięcie samej partycji od początku dysku do jej długości, co da nam przesunięcie końcowego wskaźnika NTFS 18 024 866 + 63= 18 024 929. Oczekiwano, że tam nie ma potrzebnej kopii sektora rozruchowego. Podczas wyszukiwania w okolicy został on znaleziony z narastającym przesunięciem +12 sektorów w odniesieniu do ostatniego fragmentu MFT.
Rys. 12 Kopia sektora rozruchowego NTFS
Drugą kopię sektora rozruchowego według przesunięcia 18 041 006 ignorujemy, ponieważ nie ma ona związku z naszą partycją. Na podstawie wcześniejszych działań ustalono, że wewnątrz partycji znajdują się wtrącenia z "powstałych" w transmisji 61 sektorów, które rozprzestrzeniły dane.
Przeprowadzamy pełne odczytanie nośnika, którego wynikiem pozostaje 34 nieprzeczytane sektory. Niestety, nie ma możliwości wiarygodnego zagwarantowania, że wszystkie są defektami usuniętymi z listy P-list, ale podczas dalszej analizy warto uwzględnić ich położenie, ponieważ w niektórych przypadkach będzie można wiarygodnie określać punkty przesunięcia z dokładnością do sektora, a nie do pliku.
Rys. 13 Statystyka odczytu dysku.
Naszym kolejnym zadaniem będzie ustalenie przybliżonych miejsc przesunięć (z dokładnością do pliku, w którym wystąpiły). W tym celu przeprowadzimy skanowanie wszystkich wpisów MFT i zbudujemy łańcuchy lokalizacji plików (fragmentów plików).
Rys. 14 Łańcuchy lokalizacji plików lub ich fragmentów.
Następnie, przechodząc od pliku do pliku, poszukujemy momentu, w którym zamiast oczekiwanego nagłówka pliku wystąpią inne dane, a właściwy nagłówek zostanie znaleziony z pewnym pozytywnym przesunięciem. A w miarę precyzowania punktów przesunięć wypełniamy tabelę. Wynikiem jej wypełnienia będzie ponad 99% plików bez uszkodzeń.
Rys. 15 Lista plików użytkowników (od klienta otrzymano zgodę na publikację tego zrzutu ekranu)
Aby ustalić punktowe przesunięcia w poszczególnych plikach, można przeprowadzić dodatkowe prace i przy znajomości struktury pliku znaleźć wtrącenia danych, które się do niego nie odnoszą. Jednak w danym zadaniu nie było to ekonomicznie uzasadnione.
P.S. Chciałbym również zwrócić się do kolegów, którzy wcześniej go używali. Proszę, bądźcie ostrożni podczas pracy z mikrokodami urządzeń i rezerwujcie dane serwisowe, zanim cokolwiek zmienicie, a także nie dopuśćcie do celowego pogarszania problemu, jeśli nie udało się uzgodnić z klientem wykonania prac.
Źródło: habr.com
