Fragmentacja plików, a potem ich ręczna defragmentacja.

[Groszexxx]

Zrobiłem Screena z forum, żeby go później zapisać do pliku graficznego i go podzielić na kawałki 

Waży 506 490 B. Policzmy ile to klastrów.  506 490 / 4096 (rozmiar klastra) = 123 z hakiem, dopełniamy więc do 124 klastrów. I faktycznie,  Fragger pokazuje nam dokładnie tak samo, plik jest w jednym fragmencie.

Podzielmy nasz plik na 3 fragmenty. 

Wyszukajmy nasz plik w MFT,

następnie zanalizujmy spis esktentów dataruns.

To samo widzimy w programie. 

Czas na naszą ręczną defragmentację. Wiemy gdzie znajdują się fragmenty naszego pliku i ile liczą sobie klastrów. Naszym celem jest połączenie tych trzech fragmentów w jeden. Spojrzałem na mapę alokacji klastrów na dysku i wybrałem 59898624. 

 

Drugi screen: 

31 
29 
43580   ->  275840

31 
29
fd3c00 -> 275840-181248= 94592

31 
2a 
498c0 - > 301248+94592=395840

 

O liczeniu esktentów dataruns pisałem już dawno w tym temacie: https://www.fixitpc.pl/topic/32832-ontrack-easyrecovery-6x/  dokładniej post 18. 

 

 

I to samo pokazuje Fragger

 

 

Czas na nasza defragmentacje. Tutaj sprawa jest prosta. Sprawdzamy mapę alokacji plików (zajętość poszczególnych klastrów dla plików, to zobaczenia np w DMDE, jeżeli byśmy mieli ręcznie sprawdzać zajętość klastrów to wtedy sprawdzamy to w metadanej o nazwie $Bitmap. Tutaj objaśnienia jak w Bitmap jest to zapisywane: https://whereismydata.wordpress.com/2009/06/01/forensics-what-is-the-bitmap/  

 

 

 

Dla testu dysponujemy niemalże całą pustą partycją. Ja sobie wybrałem klaster 4000. To do niego przeniesiemy zawartość trzech fragmentów.  Pamiętajmy, żeby kopiować zawsze wielokrotność 8 sektorów, bo tyle ma klaster, a system plików operuje tylko na klastrach. Potem musimy zmodyfikować nasz dataruns. Jak ręcznie znaleźć nagłowek MFT dla naszego pliku? Najprościej po nazwie wykorzystując hexeditor. Z tym, że nazwa jest zapisywane w pewien ściśle okreslony sposób: kod ascii dla danego znaku (dla uproszczenia przyjmijmy, że litery lub cyfry) + 00. I tak "Nowy dokument tekstowy.txt wygląda tak: 

Tutaj małe poszerzenie informacji: Lokalizujemy sekcję $Data w mft, która zaczyna się sygnaturą 800000, szukamy dwóch bajtów od 20 bajtu (liczonego od początku $Data), tu jest info gdzie znajduje się ekstentów dataruns. Na naszym screenie to 4000 (pamiętajmy o little endian, a więc czytamy od tyłu 00 40), także 40 bajt liczony od początku sekcji $data. Czas na naszą modyfikację. Wiemy, że plik mieści się w 124 klastrach, w hexach to: 7C , a klaster 4000 w hexach to FA0.  

Powstaje nam: 

 

Resztą - np. tablicą alokacji plików, zajmie się chkdsk.  Pamiętajmy, że w chwili obecnej plik wykorzystuje przestrzeń, która nie jest zaalokowana. Chkdsk to naprawi: 

 

Pomimo dwóch złowieszczych błędów na końcu - wszystko zostało zrekonstruowane i plik jest czytelny. Jest również w jednym kawałku i faktycznie w klastrze nr 4000:

Plik oczywiście jest czytelny i bez trudu można go otworzyć.

 

Wiemy już nie tylko co to jest defragmentacja, ale też to jak wygląda ona od środka. Mimo iż mamy 2018 rok, bez przerwy, w koło Macieja ludzie nie mają świadomości co ona daje, po co jest, traktując to jako jakiś magiczny rytuał, który ma uzdrowić wolno działający komputer. Wraz z pojawieniem się dysków SSD straciła na znaczeniu, domyślnie jest nawet wyłączona w windows 10 - podobnie jak wiele innych usług - np. indeksowania. Wielu ludz bez wiedzy powtarza jak mantrę, że defragmentacja na dyskach SSD jest bezcelowa i, że to tylko skraca żywotność dysku. To bzdura. Oczywiście jeśli patrzymy na to tylko z punktu widzenia wydajności - to faktycznie, nie ma ona znaczenia, ale ma ogromne znaczenie, gdy spojrzymy z punktu widzenia odzyskiwania danych. Pliki, które są w jednym kawałku - są bardzo proste do odzyskania - o czym też już kiedyś miałem przyjemność pisać w tym poście: