BitLocker vs DumpFile


Jakos tak siedzac i leniwie rozmyslajac o wnetrznosciach systemu, doszedlem nagle do dosc interesujacego wniosku. Po kolei, to mniej wiecej szlo tak:

  • BitLocker szyfruje kazdy sektor dysku, wiec odczytanie danych poprzez dostep offline (siegajac do dysku wylaczonego komputera) nie jest w normalnych warunkach mozliwe.
  • Plik DMP (zawierajacy zrzut pamieci 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 uzyc w czasie BSOD. Dzieki temu, te drugie nie sa w normalnej pracy uzywane, co zwieksza szanse, ze pozostana nienaruszone przez crash systemu.
  • System zapamietuje mape sektorów dysku, w których lezy pagefile.sys i tez trzyma ja tylko na wypadek wystapienia BSOD. Dzieki temu, w chwili awarii, dostep do pliku wymiany mozliwy jest z pominieciem wszystkich normalnych warstw stosu systemu plików i mozna cos zapisac na poziomie konkretnych sektorów. Oczywista wada jest to, ze jakakolwiek modyfikacja polozenia pagefile.sys dezaktualizuje taka mape i wtedy "dlubanie" bezposrednio po sektorach ma pelne prawo zakonczyc sie katastrofa. Miedzy innymi dlatego, na zywym systemie z pagefile.sys nie mozna nic zrobic, z defragmentacja wlacznie, mimo ze dla innych otwartych plików nie jest ona wielkim problemem.
  • W momencie wystapienia BSOD, system weryfikuje sumy kontrolne dla "zapasowych" sterowników oraz dla mapy sektorów i zaczyna zrzut pamieci. W efekcie, zrzut tworzony jest wewnatrz pagefile.sys a nie jako plik na dysku. Do pliku zostanie skopiowany przez SMSS i WerFault.exe dopiero po restarcie, gdy system bedzie nieco stabilniejszy niz w czasie crashu.

I tu pojawila sie mi sie pileczka taka, jaka pojawiala sie Pomyslowemu Dobromirowi. Przeciez to rozwiazanie oznacza, ze dane w pagefile.sys zapisywane sa z pominieciem calego stosu! A wiec i bez posrednictwa fvevol.sys, który dla kazdej innej informacji zapisywanej na dysku zajmuje sie jej zaszyfrowaniem. Czy to oznacza, ze zawartosc RAM zapisywana jest w czasie BSOD bez szyfrowania?

Takie pytania sprawiaja, ze mozna zmienic plany na sobotni wieczór. Po szybkich konsultacjach z Paula Januszkiewicz zadzialalismy dwutorowo. Paula doswiadczalnie zaczela badac co z zawartosci pamieci RAM fizycznie znajdzie sie w dumpie lezacym na dysku chronionym BitLockerem a ja zaczalem zabawe z WinDbg.

Wyniki pozwalaja spac spokojnie. Ani bezposrednie doswiadczenia ani próby zrozumienia co w systemie sie dzieje nie daja powodów do niepokoju. Jednym z elementów BitLockera jest sterownik dumpfve.sys wczytywany równiez drugi raz jako dump_dumpfve.sys Sterownik ten nawet w chwili totalnej katastrofy, jaka zwykle jest BSOD zadba, aby wszystko zostalo zaszyfrowane. Korzysci sa oczywiste: dane sa skutecznie chronione. A konsekwencje mniej pozytywne? Zwieksza sie ilosc elementów, od których zalezy poprawne zapisanie zrzutu pamieci, co moze oznaczac, ze zwiekszy sie równiez ilosc przypadków, gdy system nie podejmie sie jego wykonania aby nie uszkodzic danych na dysku.

dump01

Prawde mówiac, takie podejscie mnie uspokaja. W zrzucanej na dysk pamieci sa przeciez klucze szyfrujace i dostanie sie do nich mocno naraziloby bezpieczenstwo calego rozwiazania. W kazdym razie BitLocker po raz kolejny sie obronil i po raz kolejny jasno pokazal, ze ludzie, którzy go zaprojektowali, przemysleli sobie naprawde wiele scenariuszy.

Na koniec bedzie zagadka i zadanie domowe:

  • Zagadka: dumpfve.sys wczytywany jest dwukrotnie. Do czego sluzy kopia w dump_dumpfve.sys juz wiadomo. A jego oryginalna postac? Nagród nie przewiduje, ale gratulacje – juz tak.
  • Zadanie domowe: Jak w analogicznej sytuacji (zrzut pamieci na zaszyfrowany dysk) zachowaja sie inne niz BitLocker rozwiazania szyfrujace? Ktos uzywa i ma ochote sprawdzic czy jest równie bezpiecznie?

Autor: Grzegorz Tworek [MVP]

Comments (6)

  1. KoprowskiT says:

    @Komodo – gratki i ode mnie 🙂

    @Grzegorz – spróbuje odkopać, miałem gdzieś przed oczami kilkanaście miesięcy temu artykuł o tym… (choć tam chyba były tylko rozważania teoretyczne, a nie przykład praktycznego zastosowania…)

  2. A bo to w obecnych czasach potrzebne jest jakieś konkretne miejsce…? 😉

  3. Odpowiedź Komodo jest trafna. Gratujuję i Tobie (nie byłeś pierwszy, na facebooku Marcin Jurko też dobrze odpowiedział).

    A co do odpowiedzi Tobiasza… hmm… choć to teoretycznie możliwe, to nie kojarzę takiego zastosowania. Ale się przyjrzę 🙂

  4. KoprowskiT says:

    W pierwszej chwili pomyślałem, że własnie do zabezpieczenia przed np BSOD, bo w końcu jego nazwa to: Full Volume Encryption Crashdump Hibernate Filter Driver. Skoro jednak do tego celu głównie używa dump_dumpfve.sys to stawiałbym na pomost do współpracy między innymi dostawcami systemów szyfrowania (firmy trzecie), co mogłoby mieć związek z zadaniem domowym 🙂

  5. Komodo says:

    Jest wykorzystywany podczas hibernacji?

  6. mgrzeg says:

    To musial byc mily wieczor 🙂 Ciekaw jestem, gdzie organizujecie te 'undergroundowe' spotkania, chetnie bym kiedys wpadl na 'jointa' z windbg 😉

Skip to main content