X

FAQ NTFS. Opis pracy i odzyskiwania danych z partycji NTFS.

07 Dec 2007 23:49 PRPrzemcio
  • #1 07 Dec 2007 23:49
    Przemcio
    VIP Zasłużony dla elektroda
    Helpful post? (+1)
    Witam.
    Myślę, że najwyższa pora spróbować przybliżyć działanie systemów plików z jakimi spotykamy się na co dzień.
    Na początek chyba najbardziej obecnie powszechny system plików NTFS.
    Ogłoszenie pozostawiam otwarte gdyż liczę na sporo konkretnych pytań dotyczących pracy i postępowania w czasie awarii.
    Mam nadzieję, że takie "interaktywne" ogłoszenie pozwoli na lepsze wyjaśnienie wszelkich pytań a co za tym idzie pozwoli na stworzenie możliwie najlepszego opisu.

    P.
  • #2 21 Jul 2008 09:17
    Removed
    Helpful post? (+1)
    No to może ja zacznę od pytania :)
    Takie podstawowe pytanie o logice dysku.
    Jak na podstawie MBR wyliczyć booty partycji,
    Chciałbym dokładny opis na co patrzeć w edytorze HEX (co za co odpowiedzialne) oraz informacje jak te informacje z HEX przeliczyć na konkretne LBA, w których jest boot i boot copy.
    Dysk ma bady 62-63 LBA, chce znaleźć boot copy.
    W załączniku 0-100 LBA.
  • #3 21 Jul 2008 09:31
    Removed
    Helpful post? (+2)
    FAQ NTFS. Opis pracy i odzyskiwania danych z partycji NTFS.

    Każdy dysk zaczyna się od MBR lba 0, który zawiera boot strap i partition table, a ostatni dwa bajty jest sygnatura AA55 systemowa.
    Najważniejszą rzeczą dla odbudowania logiki dysku jest właśnie partition table
    offset
    , którego 0x01BE. Na wpis dla każdej z partycji jest 16 bajt.
    Tak to wygląda :
    0x01BE-0x01CD,
    0x01CE-0x01DD,
    0x01DE-0x01ED,
    0x01EE-0x01FD.
    zobaczymy jeden konkretny wpis partition table (tablicy alokacji partycji).
    1 bajt jest bajtem flagi aktywności partycji, jeżeli mamy zawartość 80 partycja jest aktywna i możemy z niej bootować system, jeżeli 00 partycja jest nieaktywna.
    2 bajt to głowica początku partycji,
    3-4 bajty sektor/cylinder początku partycji - tu podane są cylindry i sektory, najwyższą liczbą może być FFFF = /cyl/1111111111/sec/111111, /cyl/1111111111=3FF=1023, /sec/111111=3F=63.
    5 bajt id partycji .
    6 bajt głowica końca partycji.
    7-8 bajty sektor/cylindr końca partycji.
    9-12 bajty offset początku partycji,
    13-16 bajty liczba sektorów partycji.
    Z tych wszystkich (dla odzyskiwania danych) najważniejsze 9-12 i 13-16 bajty ( w większości nowoczesne dyski, żeby nawet nie powiedzieć wszystkie pracują w LBA i znaczenie CHS (dla CHS max. jest 8,4 GB) dla LBA ignoruje się, oprócz jednego ze partycja musi zaczynać się od początku cylindra (głowica 0 lub 1 i sektor 1) i zakończyć się na końcu cylindra ( głowica max.-1, 255-1=254 i sektor x gdzie x to liczba sektorów na track fizycznego dysku).
    Teraz patrzymy na przykład kolegi Nirvanowca, co my tu mamy:
    0x01BE 00 01 01 00 07 FE BF C2 3F 00 00 00 C4 4E AD 00
    mamy primary nie aktywną partycję z sygnaturą 07 NTFS boot sektor offset 3f=63 LBA, liczba sektorów AD4EC4= 11357892 LBA
    0x01CE 00 00 81 C3 0F FE FF FF 03 4F AD 00 F8 50 B5 01
    extended sygnatura 0F , offset boot extended AD4F03= 11357955 LBA , liczba sektorów 1B550F8= 28659960 LBA .
    Teraz patrzymy w 63 sektor primary czyli w boot NTFS, tu widzimy ze po offsetu 0x7E00- 0x7FF0 (to jest nasz 63 lba) z pliku 0-100lba co podał kolega idą same zera. To może oznaczać ze atof trafił na bada lub sektor został wyzerowany. Teraz żeby odbudować partycję NTFS wystarczy odbudować boot NTFS używając do tego boot NTFS copy, który jest ulokowany na końcu partycji w ostatnim sektorze i to będzie sektor 11357954 LBA. Wykorzystując komendy tof/atof odczytujemy ten sektor i zawartość tego odczytanego sektora wgrywamy do sektora 63 LBA używając komendy MHDD ff. Jasnym powinno być to że przed wgraniem sektora należy sprawdzić same sektory i uszkodzone remapować ( a najpewniejszy sposób to jest praca z kopią dysku, wtedy ewentualne zniszczenia, które mogą powstać w skutek błędów użytkownika nie uszkodzą zawartości dysku oryginała).
  • #4 21 Jul 2008 09:37
    Removed
    Helpful post? (+2)
    W sektorze obliczonym przez Okzo czyli 11357954 LBA faktycznie znajduje się boot copy.
    Mogę go wgrać teraz przez MHDD komendę FF ale nie był bym sobą jak bym nie poprosił o dokładny opis bootu i na co w nim patrzeć, co można wyczytać z niego?

    W załączniku boot copy.
  • #5 21 Jul 2008 09:43
    Removed
    Helpful post? (+2)
    Dla odbudowania logiki dysku NTFS, w sektorze Boot NTFS najważniejszy będzie BIOS Parameter Block (BPB) na obrazku.
    FAQ NTFS. Opis pracy i odzyskiwania danych z partycji NTFS.
    sam BPB składa się z :

    offset(w bajtach)/rozmiar(w bajtach) :
    0/3 - komenda JMP
    3/8 - Nazwa firmy producenta i systemu operacyjnego( w tym przypadku NTFS )
    B/2 - Rozmiar sektora w bajtach
    D/1 - Liczba sektorów w klastrze
    E/7 - Zarezerwowane
    15/1 - Typ nośnika (dysk twardy dowolnej pojemności F8 )
    16/2 - Zarezerwowane
    18/2 - Liczba sektorów na tracku
    1A/2 - Liczba głowic
    1C/4 - hiden sectors (młodsze słowo hiden sectors ^1)
    20/4 - Zarezerwowane (starsze słowo hiden sectors ^1)
    24/2 - Zawiera liczba 0x80
    26/2 - Zawiera liczba 0x80
    28/4 - Młodsze słowo ilości sektorów partycji
    2C/4 - Starsze słowo ilości sektorów partycji
    30/4 - Młodsze słowo numeru pierwszego klastra $MFT
    34/4 - Starsze słowo numeru pierwszego klastra $MFT
    38/4 - Młodsze słowo numeru pierwszego klastra $MFTmirror
    3C/4 - Starsze słowo numeru pierwszego klastra $MFTmirror
    40/4 - Rozmiar zapisu MFT w klastrach
    44/4 - Rozmiar buforu index'ow w klastrach
    48/4 - Młodsze słowo numeru seryjnego dysku
    4C/4 - Starsze słowo numeru seryjnego dysku
    ^1 -1C/4 -hiden sectors i 20/4 - te bajty teraz wszędzie są opisywane jako zarezerwowane, ale moim zdaniem szybko rosnąca pojemność dysków nie pozostawia innego przeznaczenia dla nich, niż ukazane w nawiasach.
    Teraz kiedy mamy boot NTFS możemy przeanalizować BPB.
    patrzymy na przykładu kolegi boot'a.
    Ze wszystkich parametrów nas będą ciekawić najważniejsze:
    1. liczba sektorów w klastrze
    2. pierwsze klastry $MFT i $MFTmirror ( dla sprawdzenia parametrów BPB)

    1. Mamy 8 sektorów w klastrze ( będzie potrzebny żeby wyliczyć pierwszy sektor $MFT i $MFTmirror dla sprawdzenia)
    2. Pierwszy klaster $MFT 04h=4 sektor (4x8)+63= 95 -102
    Pierwszy klaster $MFTmirror 80000h=524288 sektor (524288x8)+63= 4194367 - 4194374

    Właśnie te obszary nie zaszkodziło by sprawdzić 95 -102 i 4194367 - 4194374 !
  • #6 21 Jul 2008 09:47
    Removed
    Helpful post? (+1)
    W załączniku MFT i MFTmirror
    MFT1 - MFT
    MFT2 - MFTmirror
  • #7 21 Jul 2008 09:51
    Removed
    Helpful post? (0)
    Cóż można powiedzieć, pierwsze zapisy MFT i MFTmirror są po swoich adresach, biorąc pod uwagę bardzo wielki odstęp 95 lba i 4194367 lba jakiekolwiek przesunięcie i błąd można wykluczyć.
    Pozostaje tylko wgrać boot copy na miejsce boot NTFS !
  • #8 21 Jul 2008 09:52
    Removed
    Helpful post? (+2)
    Pierwszym co wykonałem było wykonanie kopii 1:1 dzięki temu nie musiałem się obawiać uszkodzenia oryginału dysku, bo wszystkie działania były wykonane na kopii.
    Po wyliczeniu BOOTcopy, sprawdziłem dzięki wyliczeniu kolegi Okzo czy MFT i MFTmirror są na swoich miejscach, okazało się ze tak, wiec przystąpiłem do wgrania
    znalezionego BOOT COPY w miejsce BOOT czyli w LBA63 programem MHDD komenda FF i partycja została naprawiona, 100% danych odzyskanych.
    Potrzebne do wykonania tej operacji było:
    - MHDD
    - dowolny edytor HEX
    - inny nośnik sformatowany w Fat 32 (dyskietka lub drugi dysk) – na skopiowanie fragmentów dysku, które zgraliśmy dzięki MHDD i jego komendzie TOF lub ATOF.
    No i oczywiście pomoc z Forum, która bardzo często okazuje się bardziej skuteczniejsza niż stosowanie softu czasami bardzo kosztownego.
    Reasumując dane odzyskaliśmy praktycznie za darmo bez użycia jakichkolwiek programów odzyskujących dane.
    W załączniku 0-100 LBA po wgraniu BOOT.

    Chciałem jeszcze podziękować Koledze Okzo za dogłębne odpowiedzi na moje pytania oraz Koledze Przemcio za wspaniały pomysł tematu.
    Nie mam jak kliknąć pomógł, wiec po 100pkt wysyłam.

    Mam jeszcze jedną prośbę, prosił bym o jakiś opis MFT, co to właściwie jest oraz na co w nim patrzeć:?:

    W załączniku LBA 0-100 po naprawie logiki.
  • #9 21 Jul 2008 09:59
    Removed
    Positive voted Helpful post? (+7)
    FAQ NTFS. Opis pracy i odzyskiwania danych z partycji NTFS.
    MFT kolegi Nirvanowca będzie jak przykład!
    Każdy zapis zawiera nagłówek stałego formatu, dalej idzie spis atrybutów zmiennej długości.
    nagłówek MFT:
    offset(w bajtach)/rozmiar(w bajtach)
    0/4 - sygnatura MFT - "FILE"
    4/2 - offset masywu korygowania zapisu Update Sequence
    6/2 - rozmiar masywu zapisów Update Sequence
    8/8 - numer kolejności pliku transakcji($LogFile Sequence Number)
    10/2 - ostatni numer sektora w zapisu MFT
    12/2 - licznik linków
    14/2 - offset początku spisu atrybutów
    16/2 - flagi, zaznaczające stan zapisu MFT : zawartości
    00 - zapis nie wykorzystuje się
    01 - zapis wykorzystuje się i opisuje plik (file)
    02 - zapis nie wykorzystuje się i opisuje katalog (directory)
    03 - zapis wykorzystuje się i opisuje katalog (directory)

    18/4 - realny rozmiar zapisu MFT
    1C/4 - rozmiar pamięci zajętej zapisem MFT
    20/8 - numer (File Reference) bazowy zapis MFT
    28/2 - maksymalna zawartość identyfikatora atrybutu, powiększonego o 1
    2A/2 - Masyw korygowania zapisu MFT rozmiarem2*(N-1), gdzie N - zawartość rozmiaru masywu korygowania z pola z offset'em 0x06
    2C/4 - dla XP index danego zapisu (number of this MFT record)
    /2 - dla wszystkich numer kolejności aktualizacji (update sequence number)
    /2S-2 - dla wszystkich, masyw kolejności aktualizacji (update sequence number)

    Atrybuty: zgodnie z zawartością 14/2=0x0030 offset spisu atrybutów to 30h
    Atrybut składa się z nagłówka, w którym jest:
    offset(w bajtach)/rozmiar(w bajtach)
    0/4 - typ atrybutu n.p. 0x00000010=$10 $STANDARD_INFORMATION
    4/4 - rozmiar atrybutu w bajtach n.p. 0x00000060 60h i dodając tą zawartość wyliczamy offset kolejnego atrybutu 30h+60h=90h
    90h
    0/4 - typ atrybutu 0x00000030 $30 $FILE_NAME
    4/4 - rozmiar atrybutu 0x00000068 68h + 90h =F8
    F8H
    0/4 - typ atrybutu 0x00000080 $80 $DATA
    4/4 - rozmiar atrybutu 0x00000048 48h + F8 = 140H
    140H
    0/4 - typ atrybutu 0x000000B0 $B0 $BITMAP
    4/4 - rozmiar atrybutu 0x00000048 48 + 140 = 188H
    188H FF FF FF FF sygnatura końca spisu atrybutów

    Każdy z atrybutów rozpatrzymy osobno.. ale to trochę później, jak będę miał trochę czasu, opisze wszystkie zawartości i flagi.

    Adresy i rozmiar atrybutów nauczyliśmy się już wyliczać, teraz o samych atrybutach. Każdy atrybut zawiera nagłówek i ciało (body) obszar danych, adresy typu i rozmiar już opisany, dlatego zaczniemy od kolejnych zawartości nagłówka.
    offset(w bajtach)/rozmiar(w bajtach)
    0/4 - typ
    4/4 - rozmiar
    8/1 - flaga nierezydentnego atrybutu (00 rezydentny, 01 nierezydentny)
    9/1 - długość nazwy atrybutu (00 atrybut nie ma nazwy)
    A/2 - offset obszaru danych (body) atrybutu
    C/2 - flaga skompresowanego/zaszyfrowanego atrybutu
    E/2 - identyfikator atrybutu
    FAQ NTFS. Opis pracy i odzyskiwania danych z partycji NTFS.
    $STANDARD_INFORMATION
    18/8 - Data i czas utworzenia pliku
    20/8 - Data i czas ostatniej modyfikacji pliku
    28/8 - Data i czas ostatniej zmiany zapisu MFT tego pliku
    30/8 - Data i czas ostatniego zgłoszenia do pliku
    38/4 - Flagi dostępu
    3C/12 - Zarezerwowane
    --
    Data i czas: to liczba interwalów o długości 100ns od 1 stycznia 1601 roku, czasu UTC.
    Flagi dostępu: to zbiór osobnych bitów, połączonych przy pomocy operacji logiczniej (OR - LUB)
    Bity
    0x0001 - dla pliku lub folderu dozwolone tylko czytanie
    0x0002 - ukryty plik lub folder
    0x0004 - plik lub folder systemowy
    0x0020 - plik był zarchiwizowany
    0x0400 - dowiązanie symboliczne (Symbolic Link)
    0x0800 - plik lub folder skompresowany

    FAQ NTFS. Opis pracy i odzyskiwania danych z partycji NTFS.
    $FILE_NAME
    Ten atrybut zawsze jest rezydentny.
    Dla pliku lub folderu może być utworzono kilka takich atrybutów, zawierających imiona w rożnych przestrzeniach imion (Filename spaces).
    1.imiona w standardzie POSIX - mogą być dowolne znaki oprócz 0 i "/"
    2.imiona w standardzie o/s Mircrosoft Windows - ograniczenia MS WIN
    3.imiona w standardzie "8.3' o/s MS-DOS - ograniczenia MS-DOS

    offset(w bajtach)/rozmiar(w bajtach)
    18/8 - numer zapisu MFT dla folderu, zawierającego ten plik
    20/8 - Data i czas utworzenia pliku
    28/8 - Data i czas ostatniej modyfikacji pliku
    30/8 - Data i czas ostatniej zmiany zapisu MFT tego pliku
    38/8 - Data i czas ostatniego zgłoszenia do pliku
    40/8 - Rozmiar przestrzeni dyskowej wykorzystanej dla przechowywania pliku
    48/8 - Realna długość pliku
    50/8 - Flagi dostępu
    58/1 - Długość imienia pliku N
    59/1 - Kod przestrzeni imienia pliku
    5A/2*N - Imię pliku. To pole ma długość 2*N, gdzie N - długość imienia pliku z pola po offset'u 58h
    Informacja o dacie i czasie a także flagi dostępu dublują się, i są tak samo w $STANDARD_INFORMATION. Jeżeli flaga dostępu ma zawartość 0x1000000, to imię należy do folderu a nie do pliku.
    FAQ NTFS. Opis pracy i odzyskiwania danych z partycji NTFS.
    $DATA
    W zależności od wielkości pliku, może być rezydentny lub nierezydentny ( jeżeli wielkość pliku pozwala ulokować dane pliku w samym MFT, to ten atrybut nazywa się rezydentny, jeżeli dla danych pliku wydzielone są klastry przestrzeni partycji NTFS wówczas ten atrybut nazywa się nierezydentny).
    Rezydentny atrybut $DATA
    offset(w bajtach)/rozmiar(w bajtach)
    10/4 - Rozmiar bloku danych
    14/2 - Offset bloku danych
    16/2 - Flaga indeksowanego atrybutu
    Tu najważniejszym (dla odzyskiwania danych) można liczyć rozmiar i offset bloku danych. Wyliczając je możemy odzyskać dane rezydentnego atrybutu.
    Nierezydentny atrybut $DATA
    offset(w bajtach)/rozmiar(w bajtach)
    10/8 - Początkowy numer VCN (starting VCN)
    18/8 - Końcowy numer VCN (last VCN)
    20/2 - Offset spisu ekstentow Runlist (data runs)
    22/2 - Kod metody kompresowania( pakowania) atrybutu (compression unit size)
    24/4 - 00h
    28/8 - Rozmiar obszaru danych, zajętego przez plik na dysku (allocated size)
    30/8 - Realna długość pliku (real size)
    38/8 - Rozmiar inicjalizowanego obszaru pamięci dyskowej, wydzielonej dla przechowywania pliku

    Z tego najbardziej nas będzie ciekawił spis ekstentow ( odcinkow "fragmentow") runlist ( data runs). Każdy element runlist opisuje rozmiar i ulokowanie jednego ekstenta ( odcinka) pliku.
    A także metoda kompresowania, rozmiar obszaru danych, wydzielonego obszaru i realnie zajętego plikiem .
    Offset runlist wyliczamy z pola 20/2 tu mamy 0040h to oznacza ze runlist jest po offsecie 40h od początku atrybutu. Teraz co do samego runlist, w tym konkretnym pliku kolegi Nirvanowca mamy runlist 11 28 04 00 . Jak to odczytać?
    A tak: pierwszy bajt 11h w nim młodszy nibl 01h opisuje pole długości odcinku, a starszy nibl 01h rozmiar pola dla początkowego klastra. Z tego wynika ze nasz plik zaczyna się z klastra 04h i ma długość 28h klastrów. Sygnatura 00 oznacza ze to ostatni odcinek w runlist.
    Teraz przykład wielu odcinkowego opisu runlist np. mamy 04h - 427h, 946h - 1078h, 1786h - 2899h temu będzie odpowiadał taki run-list 12 23 04 04 22 32 07 46 09 22 13 11 86 17 00. tu widzimy ze pierwszy odcinek zawiera: młodszy nibl 02h to 0423h, starszy nibl 01h to 04h , to i jest nasz odcinek na dysku 04 - (0423h+04h) zaczyna się z 4 klastra i kończy się na 1063 klastrze i t.d.
    Teraz co do kodu metody kompresowania, tu mamy 00 to oznacza ze atrybut nie używa ani kompresji ani szyfrowania. Jeżeli kod byłby równy 4 to atrybut może być kompresowany lub zaszyfrowany.
    "Real size" tu jest równy 28000h = 163840bajt
    To samo i w przypadku "allocated size"..
Mouser  Search 4 million + Products
Browse Products