Jakoś tak siedząc i leniwie rozmyślając o wnętrznościach systemu, doszedłem nagle do dość interesującego wniosku. Po kolei, to mniej więcej szło tak:

• BitLocker szyfruje każdy sektor dysku, więc odczytanie danych poprzez dostęp offline (sięgając do dysku wyłączonego komputera) nie jest w normalnych warunkach możliwe.
• Plik DMP (zawierający zrzut pamięci podczas Blue Screena) tworzony jest w bardzo specjalny sposób:

• System wczytuje sterowniki dysku twardego dwukrotnie – raz do normalnej pracy a drugi raz, z przedrostkiem dump_ tylko po to, aby ich użyć w czasie BSOD. Dzięki temu, te drugie nie są w normalnej pracy używane, co zwiększa szansę, że pozostaną nienaruszone przez crash systemu.
• System zapamiętuje mapę sektorów dysku, w których leży pagefile.sys i też trzyma ją tylko na wypadek wystąpienia BSOD. Dzięki temu, w chwili awarii, dostęp do pliku wymiany możliwy jest z pominięciem wszystkich normalnych warstw stosu systemu plików i można coś zapisać na poziomie konkretnych sektorów. Oczywistą wadą jest to, że jakakolwiek modyfikacja położenia pagefile.sys dezaktualizuje taką mapę i wtedy "dłubanie" bezpośrednio po sektorach ma pełne prawo zakończyć się katastrofą. Między innymi dlatego, na żywym systemie z pagefile.sys nie można nic zrobić, z defragmentacją włącznie, mimo że dla innych otwartych plików nie jest ona wielkim problemem.
• W momencie wystąpienia BSOD, system weryfikuje sumy kontrolne dla "zapasowych" sterowników oraz dla mapy sektorów i zaczyna zrzut pamięci. W efekcie, zrzut tworzony jest wewnątrz pagefile.sys a nie jako plik na dysku. Do pliku zostanie skopiowany przez SMSS i WerFault.exe dopiero po restarcie, gdy system będzie nieco stabilniejszy niż w czasie crashu.

I tu pojawiła się mi się piłeczka taka, jaka pojawiała się Pomysłowemu Dobromirowi. Przecież to rozwiązanie oznacza, że dane w pagefile.sys zapisywane są z pominięciem całego stosu! A więc i bez pośrednictwa fvevol.sys, który dla każdej innej informacji zapisywanej na dysku zajmuje się jej zaszyfrowaniem. Czy to oznacza, że zawartość RAM zapisywana jest w czasie BSOD bez szyfrowania?

Takie pytania sprawiają, że można zmienić plany na sobotni wieczór. Po szybkich konsultacjach z Paulą Januszkiewicz zadziałaliśmy dwutorowo. Paula doświadczalnie zaczęła badać co z zawartości pamięci RAM fizycznie znajdzie się w dumpie leżącym na dysku chronionym BitLockerem a ja zacząłem zabawę z WinDbg.

Wyniki pozwalają spać spokojnie. Ani bezpośrednie doświadczenia ani próby zrozumienia co w systemie się dzieje nie dają powodów do niepokoju. Jednym z elementów BitLockera jest sterownik dumpfve.sys wczytywany również drugi raz jako dump_dumpfve.sys Sterownik ten nawet w chwili totalnej katastrofy, jaką zwykle jest BSOD zadba, aby wszystko zostało zaszyfrowane. Korzyści są oczywiste: dane są skutecznie chronione. A konsekwencje mniej pozytywne? Zwiększa się ilość elementów, od których zależy poprawne zapisanie zrzutu pamięci, co może oznaczać, że zwiększy się również ilość przypadków, gdy system nie podejmie się jego wykonania aby nie uszkodzić danych na dysku.

Prawdę mówiąc, takie podejście mnie uspokaja. W zrzucanej na dysk pamięci są przecież klucze szyfrujące i dostanie się do nich mocno naraziłoby bezpieczeństwo całego rozwiązania. W każdym razie BitLocker po raz kolejny się obronił i po raz kolejny jasno pokazał, że ludzie, którzy go zaprojektowali, przemyśleli sobie naprawdę wiele scenariuszy.

Na koniec będzie zagadka i zadanie domowe:

• Zagadka: dumpfve.sys wczytywany jest dwukrotnie. Do czego służy kopia w dump_dumpfve.sys już wiadomo. A jego oryginalna postać? Nagród nie przewiduję, ale gratulacje – już tak.
• Zadanie domowe: Jak w analogicznej sytuacji (zrzut pamięci na zaszyfrowany dysk) zachowają się inne niż BitLocker rozwiązania szyfrujące? Ktoś używa i ma ochotę sprawdzić czy jest równie bezpiecznie?

Autor: Grzegorz Tworek [MVP]