A ten tekst został napisany przez Okzo aby ludzie zrozumieli co to jest NTFS i jak wygląda praca z odzyskiem danych z niego oraz aby różne podpuchacze nie wsadzali ludziom kitu nasłuchawszy sie OER-owskich bzdur ->
NTFS
Zobaczymy, co dzieje się przy skasowaniu plików /dirX/file.xxx
1. Kasowanie pliku zaczyna się od odczytu pierwszego sektora systemu plików i praca z boot sektorem dla wyliczenia rozmiaru klastera i początkowego adresu MFT i rozmiaru MFT zapisu.
2. Odczyt z MFT pierwszego zapisu (plik $MFT) i obliczenie według tego zapisu wyjaśniając strukturę pozostałych zapisów MFT, informacja przechowywana jest w atrybutach $DATA
3. Dalej potrzebne jest odnalezienie katalogu dirX, dla tego musimy odczytać zapis MFT katalogu ROOT i przechodzimy po index'ie w atrybutach $INDEX_ROOT i $INDEX_ALLOCATION. Ze znalezionego elementu dirX bierzemy adres zapisu MFTxxx i odświeża się czas ostatniego zgłoszenia do folderu.
4. Pracujemy z atrybutem $INDEX_ROOT zapisu MFTxxx i szukamy w nim elementu file.xxx., wyjaśniamy, że adres MFT pliku jest pod zapisem MFTxxy.
5. Zapis wyklucza się z indexu, elementy węzła przesuwają się i zamieniają poprzedni element. Dla folderu odświeża się czas ostatniego zgłoszenia.
6. Zapis MFTxxy wyswobodzony zostaje przez zrzucenie flagi użytkowania. Tak samo opracowany jest atrybut $DATA pliku $BITMAP, i w nim zerujemy bit danego zapisu.
7. Obrabiamy nierezydentne atrybuty zapisu MFTxxy, klastery należące do niego uwalniają sie w bitowej mapie pliku \$Bitmap. W naszym konkretnym przykładzie to np. klastery xxx i xxxx.
8. W każdym z wymienionych etapów może być robiony zapis do dziennika systemu plików $LogFile i dziennika zmian \$Extend\$Usr\JRNL. Jeżeli w systemie są quoty, nowy rozmiar pliku quoty użytkownika wylicza się w pliku \$Extend\$Quota. Zwróćcie uwagę: przy kasowaniu plików w NTFS Windows nie kasuje odnośników, i związki pomiędzy zapisem MFT i klasterami zostają, związek pomiędzy nazwa pliku i zapisem MFT tez by pozostał, jeżeli zapis nie był by utracony w skutek sortowania.
Odzyskiwanie plików.
Odzyskiwanie skasowanych plików w NTFS jest łatwiejsze niż w większości pozostałych systemów plików. Przy kasowaniu pliku jego nazwa jest wykluczona z indexu foldera rodzicielskiego, wyswobadza się zapis MFT I zajęte przez niego klastery. Przy tym komponent Microsoft nie kasuje zawartości odnośników chociaż wykluczyć takiej możliwości w kolejnych wersjach Windows nie można. NTFS ma jedną wielką wadę: przy wykluczeniu nazw plików z indexu rodzicielskiego folderu index sortowany jest od nowa, i informacja o nazwie plików może być utracona. Chociaż taka wada może być po części kompensowana tym, że wszystkie zapisy MFT są trzymane w jednej tabeli, co ułatwia odnalezienie wszystkich wolnych zapisów. Oprócz tego każdy zapis jest w atrybutach $FILE_NAME z bazowym adresom rodzicielskiego folderu, a to oznacza ze przy odnalezieniu wolnego zapisu można wyliczyć jego całą ścieżkę dostępu, jeżeli tylko zapisy w rodzicielskich katalogach nie są powtórnie zajęte nowymi plikami lub folderami.
Druga czynność przy odzyskiwaniu – szukać dodatkowych atrybutów $DATA.
Żeby odzyskać wszystkie skasowane pliki w systemie plików NTFS, potrzebnie jest odnalezienie w MFT wolnych zapisów, już po odnalezieniu wolnych zapisów nazwa jest zapisana w atrybucie $FILE_NAME i adresie rodzicielskiego foldera. Odnośniki do klasterów ciągle istnieją, i jeżeli dane jeszcze nie byli nadpisane można je odzyskać bez trudu nawet przy mocnej fragmentacji skasowanych plików. Jeżeli znaczenie atrybutu było rezydentne dane nie będą nadpisywane do kolejnego wydzielenia tego zapisu MFT. Jeżeli dla przechowywania atrybutów pliku potrzebnie było więcej niż jeden zapis MFT dla pełnego odzyskania mogą być potrzebne pozostałe zapisy. W Windows dla zapisów MFT wykorzystywany jest algorytm zaznaczenia pierwszego wolnego zapisu, dla tego MFT zapisy z małymi numerami są przepisywane częściej niż z wielkimi. Przy odzyskiwaniu mogą być przydatne dane dziennika systemu plików lub dziennika zmian (dziennik zmian nie zawsze jest aktywny, ale w nim można odnaleźć czas skasowania lub redagowania pliku).
Teraz już można konstatować, ze z odzyskiwaniem w NTFS poradzi sobie byle jaki program z istniajacych na rynku, tylko trzeba przytrzymać się niektorych obowiązkowych szczegółów.
ext3: Ten system plików niczym prawie nie rożni się od ext2 za wyjątkiem niektorych szczegółów i tego ze jest "jurnaled filesystem"( data=writeback, data=ordered, data=journal). 3 tryby księgowania tego systemu plików
1. data=writeback - w tym trybie system plików nie prowadzi jakiegokolwiek księgowania.
2. data=ordered - tryb data=ordered księguje tylko metadane. W tym trybie bloki metadanych i dane zapisywane do wspólnego modułu (transaction), przed nagraniem nowych metadanych dane związane nagrywane są jako pierwsze.
3. data=jurnal - w tym trybie księguje się wszystko i metadane i dane, wszystkie nowe dane najpierw zapisywane są do księgi i tylko po tym zapisywane na swoich fizycznych miejscach na dysku.
Jak odzyskać dane skasowane w ext3, w takim przypadku ext2 w odróżnieniu od ext3 po prostu zaznacza odnośniki do bloków jako nieużywane a w ext3 odnośniki są zerowane. Także odzyskiwanie danych skasowanych w ext3 będzie możliwe tylko przez szukanie plików po „grep“ sygnaturach plików . Do tego jest najlepszym softem DataExtraktor BVG HRT DRE lub ACELAB, tryb raw recovery, dla odzyskiwania plików skasowanych w ext2 można użyć
soft r-studio czy stellar for linux i już wcześniej podane narzędzia profesjonalne i tp.
Teraz popatrzymy co dzieje sie przy formatowaniu dysku NTFS
NTFS formatowanie dysku :
Buduje się boot-sektor w formacie ntfs
Generuje się nowy seryjny numer dysku i zapisuje się w boot sektor, offset 48h
Oblicza się nowa suma kontrolna boot-sektor i zapisuje się offset 50h,
Buduje się nowy plik MFT, zawierający informacje o wszystkich plikach na dysku i zazwyczaj zapisuje się nadpisując stary plik MFT (wyjątków tu nie ma). We wszystkich przypadkach pierwsze ~24 zapisy (File Record) będą zniszczone bezpowrotnie.
W tych zapisach znajduje sie sam $MFT, $MFTMirr, folder root, /$LogFile - plik transakcji,/$BITMAP - mapa wolnej przestrzeni,/$Secure- deskryptory bezpieczeństwa i inne służbowe pliki
Inicializuje się $MFT:$DATA - ustala się nowa długość ($MFT:$30.AllocatedSize, $MFT:$30.RealSize, $MFT:$80.AllocatedSize, $MFT:$80.RealSize, $MFT:$80.CompressionSize, $MFT:$80.InitializedSize, $MFT:$80.LastVCN), data/czas zbudowania/ostatniej modyfikacji ($MFT:$10.FileCreationTime, $MFT:$10.FileAlertedTime, $MFT:$10.FileReadTime, $MFT:$30.FileCreationTime, $MFT:$30.FileAlertedTime, $MFT:$30.MFTChangeTime, $MFT:$30.FileReadTime) i najważniejsze, buduje się nowy spis odcinków (data-runs), bezpośrednio nadpisując stary, a to oznacza ze zbierać fragmentowany $MFT trzeba będzie po kawałkach
Buduje się nowy /$BITMAP-plik odpowiedzialny za podzielenie przestrzeni dyskowej (wolne i zajęte klastry) znowu nowa zawartość nadpisuje stara, ale to tez można odzyskać z chkdsk.
Buduje się nowy plik dziennika transakcji - /$LogFile,
Do nagłówka zapisu $MFT wprowadza się nowy LogFile Sequence Number w skrócie LSN;
$MFT naznaczany jest nowy numer kolejności aktualizacji (Update Sequence Number);
Buduje się lustro $MFTMirr, bezpowrotnie zacierająca stare (znajduje się po środku partycji NTFS ),
Budują się nowe /$Volume, /$AttrDef i inne pliki służbowe.
Przeprowadza się sprawdzenie powierzchni i wszystkie odnalezione uszkodzone klastry zapisywane do pliku /$BadClus;
Formuje się nowy folder root
Jeżeli do formatowania partycji istniał /System Volume Information-plik, to on po prostu odnawia się, w przeciwnym razie /System Volume Information buduje się tylko po restarcie komputera;
Jak widać po formacie zostają wszystkie dane, które były na dysku, tylko z wyjątkiem niektorych szczegółów samych metadanych zmiana których utrudnia odzyskiwanie , ale nie na tyle, żeby to było niemożliwe.
Przy tym klasyczna metoda zerowania za pomocą MHDD niszczy dane całkiem, nadpisując bezwzględnie każdy sektor zerami, softowe kasowanie można liczyć na dzień dzisiejszy za jeden z najbardziej dostępnych i najskuteczniejszych. Mozę nie jest najszybszy , ale używając odpowiednich metod można to przyspieszyć, przy tej samej skuteczności niszczenia danych.
Teraz trochę info, jak można odbudować sformatowana partycje NTFS bez jakichkolwiek narzędzi dodatkowych, tylko dowolny edytor dyskowy (może być i zwykły hex edytor w parze z MHDD, komendy atof i ff pomogą odczytać i zapisać sektory po edycji na dysk) lub DMDE, ktory zawiera wszystko. Jednym slowem darmowe odzyskiwanie danych ze sformatowanej partycji NTFS bez potrzeby kopiowania na inny nosnik (unformat NTFS recznie).
Naszym celem będzie ręczne odzyskiwanie danych całej sformatowanej partycji NTFS bez jakichkolwiek dodatkowych narzędzi dla odzyskiwania danych , wszystko co będzie potrzebne to dowolny edytor dyskowy z takich najlepszym jest DiskExplorer for NTFS no i chkdsk (słynny zabójca partycji może posłużyć do ich ratowania po formacie).
W trakcie formatowania przeprowadza się bezpowrotne zniszczenie większości kluczowych struktur metadanych - danych, które ręcznie odzyskiwać byłoby bardzo ciężko, tego właśnie i nie potrzeba . Cały sens jest w tym, żeby przywrócić partycji utracone zapisy systemu plików, a pozostała prace niech robi chkdsk .
Jedyna struktura danych bez której nie może pracować chkdsk jest atrybut $DATA pliku $MFT. Dlatego nam potrzebne jest odbudować poprzedni $MFT:$DATA i ulokować go zamiast ewentualnych zapisow . Jeżeli $MFT:$DATA nie jest fragmetowany, to można zrobić prosto powiększeniem jego długości. Jak to zrobić ?
Odpalamy DiskExplorer for NTFS wchodzimy na pierwszy sektor MFT(Goto -> Mft), klikamy na $MFT pliku i w atrybucie $DATA (80h) powiększamy znaczenia pola Allocated Size/Real Size/Compressed Size na potrzebna ilość równolegle korygując spis odcinków (run-list). Jak wyliczyć długość pliku MFT? Ona równa się różnicy pierwszego i ostatniego sektora, w których znajduje sie sygnatura FILE. Prawidłowa długość pliku MFT wyliczać nie ma potrzeby, wystarczy wziąć długość większa, niepotrzebna wyrzuci chkdsk (i lepiej brać więcej niż mniej)
DiskExplorer for NTFS nie pozwala redagować pola i dlatego potrzebne jest przełączenie w tryb hex editora i szukać offsety wszystkich wartości samodzielnie. Odnalezienie nagłówka atrybutu $DATA jest bardzo proste: na jego początku zawsze znajduje się kolejność 80 00 00 00 xx 00 00 00 01. W NTFS wersji 3.0 ona ulokowana z offsetem F8h od początku pola sektora. Pole Real Size we wszystkich wersjach NTFS ma offset 30h odnośnie nagłówka, a pole Allocated Size i Initialized Size po offsetom 28h/38h bajt, przy czym znaczenia Allocated Size musi być obowiązkowo wielokrotnością rozmiaru klastra . Najważniejszym jest, żeby przy formatowaniu był ten sam rozmiar klastra inaczej z tego co chcemy zrobić nic nie wyjdzie, jeżeli już wyszło tak, ze dysk został sformatowany z innym rozmiarem klastra, to nic innego nie pozostaje, jak sformatować z kluczem /A:x, gdzie x rozmiar klastra.
Teraz potrzebne jest wygenerowac nowy run-list. Zazwyczaj on bedzie wygladal tak 13 XX XX XX YY 00, gdzie XX XX XX - trzybajtowy rozmiar $MFT w klastrach, a YY – poczatkowy klaster. Klaster poczatkowy zawsze musi wskazywac na pierwszy klaster MFT, w przeciwnym razie chkdsk nie bedzie mogl pracowac. Jezeli nowy run-list ma wieksza dlugosc niz terazniejszy, potrzebne jest korygowanie dlugosci naglowka atrybutu (ulokowany po offsetu 04h od jego poczatku). Przeprowadzic taka nieciezka opieracja, odpalamy chkdsk z kluczem /F i poczekamy poki on przywroci nasze foldery i pliki. Jedyna rzecz, ktora nie odbuduje chkdsk to deskryptory bezpieczestwa (wszystkim folderom i plikom naznaczane domyslne prawa dostepu). Pliki zsylajace sie na nieistniajace foldery ulokowany beda do folderow Found xxx (to mozna powiedziec sa pliki wyciagniete z tamtego swiata).
Najgorzej jest z odzyskiwaniem danych z partycji, ktorej MFT mocno fragmetowany, jezeli poprzedni run-list przy formatowaniu bedzie zniszczony bezpowrotnie. Nic innego nie pozostaje, jak zbierac pliki recznie z kawalkow fragmentow. Brzmi to straszniej, niz wyglada. W odroznieniu od pozostalych plikow na dysku, plik $MFT posiada bardzo dobra signatura FILE, ktora jest na poczatku kazdego zapisu systemu plików. Wszystko, co będzie nam potrzebne, po kolei przeskanować partycje od pierwszego klastra do ostatniego i zapisać początek i koniec każdego fragmentu $MFT. Juz kiedy fragmenty beda wypisane, musimy z tego łańcucha wykluczyć $MFTMirr (jest ulokowany po środku partycji i zawiera kopie zapisów $MFT, $MFTMirr, $LogFile i $Volume, przy tym $MFTMirr ma odnośnik i na siebie samego). Wygląda run-list mniej więcej tak np. mamy 04h - 427h, 946h - 1078h, 1786 - 1113h temu będzie odpowiadał taki run-list 12 27 04 04 22 78 10 46 09 22 13 11 86 17 00.
To jest przedstawienie na czarno dlatego, ze nie znamy kolejności, w której były ulokowane odcinki w pliku. Co będzie, jeżeli porządek w pliku $MFT będzie inny? W samym MFT wszystkie zapisy maja odnośniki na kolejne zapisy po swoim porządkowym numerze przedstawiającym indeks masywu. Te odnośniki potrzebne dla odzyskiwania struktury folderów, uporządkowania hard-linków. Odnośniki na macierzysty folder dublowane w indeksach i odzyskują się bardzo prosto. Hard linki niszczą się bezpowrotnie (no tylko jeżeli spróbować zebrać $MFT odcinki w innym porządku). Największym problemem w takim przypadku są pliki, które same są bardzo mocno fragmentowane, a ich zapisy porozrzucane po rożnym fragmentach $MFT. Tu pozostaje tylko poprawne ustawienie fragmentów (zazwyczaj tych kombinacji jest nie tak dużo, ale to jest uzależnione od faktycznego rozmiaru klastra . Bywa ze niektórzy admini konfigurują sam ntfs zaczynając od rozmiaru klastra i ustawiając go równym 1 sektorowi. To jest jeden z największych błędów niedający jakiegokolwiek efektu jak ze względu oszczędzenia miejsca na dysku, a ze względu fragmentacji dający taki efekt, ze na jednej partycji niewielkiego rozmiaru może być do kilku tysięcy fragmentów pliku $MFT.) . W nowej wersji NTFS 3.1 (WIN XP ) numery zapisów $MFT chronione w jawnie po offsecie 2Ch od początku FILE zapisu).
A tak takie odzyskiwanie wygląda w praktyce ->
https://www.elektroda.pl/rtvforum/viewtopic.php?p=5166874#5166874
info :
https://www.elektroda.pl/rtvforum/topic891920.html
linki:
http://www.insidepro.com/rus/doc.shtml
http://www.linux-ntfs.org
proszę jednocześnie o nie pisanie samych 
