Odzyskiwanie danych z HDD w DMDE — i czemu SSD to inna maszyna

Odzyskiwanie danych nie zaczyna się od programu. Zaczyna się od decyzji: nie zapisuję już nic na tym dysku.

DMDE (DM Disk Editor) jest dobrym narzędziem do pracy na HDD, gdy system plików się rozsypał, partycja zniknęła, albo katalogi wróciły puste po „naprawie”. Nie jest laboratorium do wymiany głowic i nie cofa TRIM-u na SSD.

Ten wpis opisuje, co DMDE faktycznie widzi na talerzu, czego nie widzi w NAND, i w którym momencie kończy się odzyskiwanie programowe.

Wiedziałeś? Skasowany plik na NTFS zwykle nie jest wymazany. Znika rekord w katalogu i bity alokacji. Klastry z danymi zostają, dopóki ktoś ich nie nadpisze — albo dopóki nie odpalisz chkdsk /f „żeby naprawić”.

Co jest w HDD, zanim włączysz DMDE

Dysk talerzowy to mechanika plus translator firmware.

Na zewnątrz system widzi adresy LBA: kolejne sektory, zwykle po 512 albo 4096 bajtów. W środku są talerze, ramiona, głowice i strefa serwisowa (service area) — niewidoczna w normalnym LBA. Tam siedzą moduły firmware, translator, listy defektów.

Gdy translator żyje, DMDE czyta to, co kontroler wystawia jako kolejne LBA. Gdy pada elektronika, głowice albo strefa serwisowa, system często pokazuje 0 bajtów pojemności. Wtedy skan katalogów nic nie da. Potrzebny jest serwis z dawcą PCB/głowic, nie kolejny program.

HDD ma jeszcze jedną cechę, która ratuje odzyskiwanie logiczne: kasowanie w systemie plików nie czyści magnetycznego śladu. Dopóki sektor nie zostanie nadpisany, w obrazie dysku da się go znaleźć.

Typowe stany, w których DMDE na HDD ma sens:

• usunięte pliki i sformatowana partycja (szybki format)
• uszkodzony lub nadpisany boot sektor / VBR
• zniknięta tablica partycji
• uszkodzony $MFT na NTFS, z zachowanymi kopiami i resztą klastrów
• część bad sectorów, jeśli dysk jeszcze czyta większość powierzchni

Typowe stany, w których DMDE nie wystarczy:

• stuki głowic, „click of death”
• dysk widziany jako 0 MB / 0 sektorów
• silne uszkodzenie powierzchni (Pending / Reallocated rosną przy każdym odczycie)
• RAID złożony „naprawą” w Windows, która nadpisała metadane

Praca zawsze na kopii. Źródło w trybie tylko do odczytu. Obraz: ddrescue albo inny imager, który pomija i loguje błędy, zamiast urwać się na pierwszym bad sectorze. Potem DMDE otwiera plik obrazu, nie produkcyjny wolumen.

Wiedziałeś? Jedno odpalenie Windows na uszkodzonym NTFS potrafi nadpisać $MFT i journal. „Sprawdzanie dysku” to nie diagnostyka. To zapis.

SSD nie jest szybkim HDD

SSD nie ma talerzy. Ma kości NAND, kontroler i FTL (flash translation layer).

NAND zapisuje stronami (pages), a kasuje blokami (erase blocks). Nie da się nadpisać strony w miejscu. Kontroler zapisuje nową wersję gdzie indziej i aktualizuje mapę: LBA → fizyczna strona. Stara strona zostaje jako garbage, aż garbage collection skasuje cały blok.

Do tego dochodzą:

• wear leveling — dane fizycznie wędrują, nawet gdy LBA stoi w miejscu
• over-provisioning — zapas bloków poza widoczną pojemnością
• TRIM / UNMAP — system mówi kontrolerowi: te LBA są wolne; kontroler może je natychmiast unieważnić i później skasować
• często sprzętowe szyfrowanie (SED / TCG Opal, albo BitLocker z kluczami w kontrolerze)

Dla odzyskiwania wynika z tego twardy wniosek: to, co widzisz jako sektor 1000, nie jest „miejscem na chipie”. Jest wpisem w mapie FTL. Jeśli mapa, TRIM albo GC usunęły mapowanie, w LBA jest zero albo nieczytelny stan. Magnetycznego cienia nie ma.

Wiedziałeś? Po TRIM-ie wiele SSD na odczycie wolnego LBA zwraca zera od razu. To nie „puste miejsce, które da się zeskanować sygnaturami”. To kontroler, który już nie wyda starej strony.

Co ma znaczenie w labie:

• HDD — warstwa magnetyczna; LBA przez translator firmware; skasowane klastry zwykle zostają do nadpisania; bad sector często da się pominąć i czytać dalej. Szyfrowanie zwykle siedzi w OS (BitLocker na wolumenie).
• SSD — komórki NAND; LBA przez FTL; TRIM i GC mogą skasować dane w minutach; uszkodzone bloki są wyłączane i bywa, że pada cały mapping. Szyfrowanie często jest też w kontrolerze: surowy dump bez klucza jest bezużyteczny.

Dlatego ten sam scenariusz — „sformatowałem partycję, chcę pliki” — na HDD w DMDE bywa rutyną, a na SSD bywa już po sprawie, jeśli system zdążył wysłać TRIM i kontroler go wykonał.

Na nowszym Windows TRIM na SSD jest domyślny. Im dłużej włączony komputer po skasowaniu, tym mniejsza szansa na odzysk programowy.

Czym jest DMDE, a czym nie jest

DMDE to edytor dysku i odzyskiwarka warstwy logicznej: partycje, systemy plików, sygnatury.

Potrafi:

• otworzyć dysk fizyczny albo obraz
• szukać wolumenów i partycji, gdy tablica jest zła
• zrobić skan NTFS / FAT / exFAT / ext / HFS+ i złożyć drzewo z metadanych
• pokazać surowe sektory, gdy chcesz sprawdzić, czy boot sektor to śmieć, czy jeszcze superblok
• pracować na RAID-zie złożonym programowo (gdy znasz kolejność i stripe)

Nie potrafi:

• naprawić głowic i silnika
• odczytać NAND z pominięciem martwego kontrolera SSD
• „cofnąć TRIM”
• odszyfrować SED bez klucza
• zagwarantować komplet plików

Darmowa edycja ma limity na odzysk. Do labów i większych drzew katalogów potrzebna jest licencja. To nie jest ocena produktu — to ograniczenie, które trzeba znać, zanim obiecasz komuś wynik.

Procedura na HDD (skrót, który da się powtórzyć)

1. Zapis na źródle = koniec części danych. Wyłącz wolumen. Nie instaluj DMDE na tym dysku.
2. Identyfikacja. Model, interfejs, SMART (Reallocated, Pending, CRC). Notatka: czas, host, jak podłączony.
3. Obraz. Źródło read-only (mostek USB z przełącznikiem, hdparm -r1, albo port tylko do odczytu). Imager z logiem błędów. Drugi nośnik na obraz — nigdy ten sam HDD.
4. DMDE na obrazie. Najpierw podgląd partycji. Jeśli widać NTFS i $MFT — pełny skan może być zbędny. Jeśli partycji nie ma: szukanie wolumenów, potem skan.
5. Rekonstrukcja. Oglądasz drzewo, sygnatury, rozmiary. Kopiujesz wybrane pliki na trzeci dysk. Nie „naprawiasz” źródła zapisem boot sektora, dopóki nie masz obrazu.
6. Weryfikacja. Hash plików, które da się policzyć. Lista tego, czego nie ma. Hipoteza („kasowanie”) oddzielona od faktu („w obrazie nie ma klastrów”).

Szerszy szablon intake → kopia → analiza jest w arkuszu forensics. Tutaj chodzi o warstwę dysku, nie o zeznanie biegłego.

Wiedziałeś? DMDE pokazuje czasem pliki z poprawną nazwą i zerową zawartością. To nie sukces. To metadane bez klastrów — na HDD po nadpisaniu, na SSD po TRIM.

Czego nie robić:

• nie odpalaj chkdsk, TestDisk „write”, ani naprawy startowej Windows na jedynej kopii
• nie defragmentuj i nie „oczyszczaj dysku”
• nie kopiuj drzewa z zamontowanego, sypiącego się wolumenu — czytasz uszkodzone sektory w pętli i pogarszasz Pending
• nie składaj RAID-u w menedżerze dysków „na próbę”

Jeśli SMART Pending rośnie w czasie skanu, skan skracasz albo wracasz do obrazu z ddrescue i mapy błędów. Narzędzie nie ma prawa zjeść reszty powierzchni.

SSD: kiedy DMDE jeszcze ma szansę

Są wąskie okna:

• dysk w trybie USB-pendrive bez TRIM (rzadkość na wewnętrznych NVMe)
• skasowanie, po którym natychmiast odcięto zasilanie i nie było GC
• uszkodzony system plików bez TRIM (np. dziwny RAID, niektóre zewnętrzne obudowy)
• logiczny bałagan (partycja, tablica) przy żywym FTL — wtedy DMDE zachowuje się jak na HDD, bo LBA jeszcze mapuje stare strony

Nie ma okna, gdy:

• Windows, macOS albo Linux zdążył wydać TRIM na wolne bloki
• kontroler robi hardware crypto i nie ma klucza
• dysk widentyfikował się jako 0 B albo „not initialized” po padzie FTL
• ktoś „wyczyścił” go w menedżerze (secure erase / sanitize) — na SSD to naprawdę kasuje bloki

Wiedziałeś? Secure Erase na HDD często oznacza nadpisanie LBA. Sanitize na SSD oznacza kasowanie komórek NAND. Po sanitize nie ma warstwy „może jeszcze sygnatura JPEG w unallocated”.

Jeśli nośnik to NVMe po nagłej śmierci kontrolera, kolejnym krokiem jest serwis z odczytem chip-off albo wymianą kontrolera — poza zakresem DMDE i poza zakresem tego wpisu.

Co zapisuję po skanie

Minimum, zanim ktoś usłyszy „udało się” albo „nie da się”:

• model, SN, interfejs, czy to obraz czy live
• typ FS i czy widać metadane (np. $MFT / superblok)
• ile plików z zawartością, ile samych nazw
• czy były błędy odczytu i czy rosły
• hipoteza: kasowanie logiczne / format / mechanika / TRIM
• czego nie sprawdziłem (np. nie otwierałem NAND)

Bez tego raport z DMDE jest zrzutem drzewa katalogów. Drzewo bez klastrów nie jest odzyskanymi danymi.

Podsumowanie

Na HDD DMDE jest narzędziem do warstwy logicznej na kopii. Działa, bo kasowanie i format zwykle zostawiają talerz w spokoju.

Na SSD ta sama ikona „Kosz” idzie przez FTL i TRIM. Konstrukcja nośnika jest inna, więc inny jest też koniec historii: albo LBA jeszcze wskazuje stare strony, albo kontroler już ich nie odda.

Różnica nie jest w „jakości programu”. Jest w tym, czy pod LBA w ogóle leży jeszcze treść.