Paweł Goleń, blog

Jeśli czegoś nie rozumiesz - statystyka

Gdzieś naprawdę dawno temu przeczytałem, że jeśli naukowcy czegoś nie rozumieją, używają statystyki by problem opisać, pomierzyć i zaszufladkować. Podejście to można wykorzystać również w tym wypadku i wykorzystać fakt, iż dane losowe charakteryzują się dużą entropią. Pisałem o tym między innymi przy okazji analizy malware, pisał o tym również stosunkowo niedawno Gynvael. Mój program (skrypt właściwie) do wizualizacji entropii plików nie ma takich ładnych kolorów, ale do celów demonstracyjnych powinien wystarczyć.

Wykresy entropii dla różnych plików

Na początek jak wygląda wykres entropii dla pliku, który zawiera kontener TrueCrypt. Jak widać przez cały plik entropia jest wysoka i na mniej więcej jednym poziomie.

Dla porównania analogiczny wykres dla dość dużego pliku PDF, który zawiera sporo grafiki. Jak widać w pliku wyróżnić można kilka obszarów o widocznie różnej entropii, początek pliku pod tym względem przypomina wykres dla wolumenu TrueCrypt, dalsze części pliku mają widocznie inną charakterystykę.

Równie ciekawie wygląda wykres dla pliku ISO, w tym przypadku jest to Darik's Boot And Nuke. Poza wyraźnie niższą entropią na samym początku pliku, w pozostałej części entropia jest wysoka. Wynika to (najprawdopodobniej) z faktu, że w tym miejscu obrazu ISO znajdują się skompresowane dane.

Dla porównania jeszcze plik (pdb) o wyraźnie innej charakterystyce.

Co z tego wynika

Czy na podstawie powyższych wykresów można jednoznacznie stwierdzić, który z nich prezentuje entropię dla pliku TC? Można się tego domyślać, choć rozróżnienie kontenera TC od obrazu iso zawierającego skompresowane dane może być trudne. Jeśli wiadomo, gdzie jest początek, a gdzie koniec pliku, mniejsza entropia nagłówka lub stopki pliku może być istotną przesłanką. Gorzej, jeśli takiej informacji nie ma.

Jak to wygląda na dysku

Najpierw wykresy

Skoro wiadomo już jak mniej więcej wygląda wykres entropii dla pliku, można popatrzeć jak analogiczny wykres będzie wyglądał dla całego dysku. W tym wypadku dysk jest niewielki, ma rozmiar 64 MiB i został założony na nim system plików NTFS. W rzeczywistości jest to "dysk w pliku" montowany w systemie Windows za pomocą (bardzo dobrego) narzędzia ImDisk.

Oczywiście to nie jest "pusty", znajdują się na nim w tej chwili różne dane, pliki graficzne, pliki tekstowe, PDF oraz archiwum. Po usunięciu części plików (by zrobić miejsce) na dysku tym stworzony został kontener TC, co (wyraźnie?) widać na poniższym wykresie.

Porównując powyższe dwa wykresy można przypuszczać, że plik został utworzony w (co najmniej) dwóch częściach, pierwsza na początku dysku, druga pod jego koniec.

Później surowe dane

Wykres jest fajny, ale do ewentualnego odzyskania pliku TC potrzeba jest bardziej precyzyjnych informacji na temat tego, w jakich obszarach dysku znajdują się dane o poziomie entropii, która sugeruje, że może w tym miejscu być zapisany szukany kontener. Pewnym ułatwieniem może być uwzględnienie klastra jako podstawowej jednostki alokacji. Rozmiar klastra może być różny, jednak dobrym punktem wyjścia mogą być wartości podane w The Default Cluster Size for the NTFS and FAT File Systems. Oczywiście może okazać się, że informacja ta jest nieścisła. Według tej rozpiski rozmiar klastra powinien wynosić 512 bitów, w rzeczywistości to 4906:

CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 0 - 16382
Total Sector Range: 0 - 131070

Jako punkt wejścia dla dalszej analizy posłużą dane zawierające informacje o numerze klastra oraz entropii danych w nim zawartej. Na tej podstawie postaram się znaleźć obszary dysku, które charakteryzują się odpowiednio wysoką entropią, przy czym "odpowiednio wysoka entropia" jest oczywiście kwestią umowną, czyli jej wartość zostanie dopasowana empirycznie.

Przykładowa wartość 5 najdłuższych ciągłych fragmentów dla wartości entropii co najmniej 7.8:

3493 [(1026, 4519)]
601 [(15261, 15862)]
551 [(14708, 15259)]
183 [(8798, 8981)]
135 [(8661, 8796)]

I analogiczna lista dla 7.94:

3493 [(1026, 4519)]
601 [(15261, 15862)]
551 [(14708, 15259)]
38 [(8756, 8794)]
37 [(8407, 8444)]

Na tej podstawie wstępnie można wytypować trzy duże i ciągłe obszary, które mogą zawierać kontener TC, a na pewno zawierają dane o dużej entropii, są to zakresy (w nawiasach zakres):

• 1026, 4519 (0x402000, 0x11A8000)
• 15261, 15862 (0x3B9D000, 0x3DF7000)
• 14708, 15259 (0x3974000, 0x3B9C000)

Można się przyglądnąć granicom tych obszarów.

W przypadku początku pierwszego obszaru sprawa jest dość jasna, kończą się zera i zaczyna "coś":

Również zakończenie obszaru jest wyraźne, kończą się dane losowe, a zaczyna plik PHP:

Podobnie dobrze oddzielone jest rozpoczęcie i zakończenie kolejnego obszaru:

Ostatni wytypowany obszar natomiast zawiera charakterystyczny nagłówek (patrz sygnatury plików):

Nagłówek ten wskazuje, że plik ten jest archiwum 7z, nie jest więc raczej elementem kontenera TC.

Próba odzyskania danych

Na chwilę obecną wytypowane zostały dwa obszary dysku, w których prawdopodobnie znajduje się kontener TC, są to klastry:

• 1026 - 4519 (0x402000, 0x11A8000)
• 15261 - 15862 (0x3B9D000, 0x3DF7000)

Po odzyskaniu ich z obrazu dysku otrzymuje się dwa pliki o wielkościach 14 311 424 i 2 465 792 bajtów, co w sumie daje dokładnie 16 MiB, czyli odpowiada dokładnie wielkości szukanego kontenera TC.

Składanie w całość i montowanie

Jedną z interesujących cech wolumenu TrueCrypt jest to, że montowany plik nie musi być kompletny. W zasadzie do podmontowania jest sam nagłówek. Kontener zostanie podmontowany, sam system plików wewnątrz niego może być jednak uszkodzony (bo nie jest kompletny). W praktyce oznacza to, że wystarczy jedynie 65536 bajtów z początku kontenera, by go zamontować, reszta pliku nie jest potrzebna. Cecha ta może być również wykorzystana do poszukiwania wolumenu, "wystarczy" wygenerować wszystkie możliwe fragmenty tej wielkości (oczywiście wyrównane do granicy klastra) i próbować po kolei je montować.

Odzyskany kontener TrueCrypt składa się z dwóch fragmentów. Poskładanie ich w całość nie będzie wielkim problemem, wystarczy ustalić, która część zawiera nagłówek i umieścić ją na początku tworzonego (scalanego) pliku, a nagłówek (na początku) posiada ta część, która da się zamontować.

Zdecydowanie bardziej złożona byłaby kwestia poskładania kontenera z większej ilości kawałków. Zidentyfikowanie wszystkich elementów kontenera i ułożenie ich w odpowiedniej kolejności może być "trochę" problematyczne. Dla n kawałków istnieje (n-1)! możliwych ułożeń, przy czym w pierwszym kroku trzeba ustalić, który z plików jest ten pierwszy (zawiera nagłówek).

Podsumowanie

Okazuje się, że pliki TrueCrypt jednak mają pewne cechy charakterystyczne. Są to:

• duża entropia (losowość),
• brak innych cech charakterystycznych (np. nagłówków),

W przypadku uszkodzenia systemu plików, które powoduje utratę informacji o alokacji plików na dysku możliwe jest zidentyfikowanie potencjalnych miejsc, gdzie plik mógł być umieszczony, co pozwala na odzyskanie zaszyfrowanych danych. Identyfikacja ta może być oparta na analizie entropii w poszczególnych jednostkach alokacji. Skuteczność tej metody jest jednak mocno zależna od "tła", czyli tego co na dysku znajdowało się przed awarią. By lepiej to unaocznić, dwa wykresy:

W tym przypadku dysk, na którym znajdował się plik TC został wyczyszczony (jego wolne miejsce) przy pomocy narzędzia sdelete. Oznacza to nadpisanie wolnego miejsca (i nie zajętego na potrzeby NTFS) losowymi danymi.

Ostatni schemat pokazuje natomiast dysk, na którym znajduje się tylko kontener TC, ale który został wyczyszczony przy pomocy wspomnianego narzędzia sdelete...

Podsumowując: tym razem odzyskiwanie kontenera i zaszyfrowanych danych udało się, jednak w ogólnym przypadku wcale nie musi być to takie proste. Tu było kilka ułatwień:

• stosunkowo "czysty" dysk, początek i koniec fragmentów kontenera był łatwy do ustalenia,
• kontener nie był bardzo sfragmentowany (tylko dwie części pliku),

Co do zasady, to chyba jednak lepiej jest mieć backup :)