Start systemu Windows Vista Start komputera typu PC od lat osiemdziesiątych wygląda cały czas tak samo. Cały czas wszystko tak naprawdę zaczyna się od pierwszego kroku procesora, który kierowany jest zawsze w tę samą stronę: pod adres FFFF:0000. Segmentowe adresowanie pamięci dostępne w trybie rzeczywistym procesorów x86 sprawia, że od adresu FFFF:0000 do końca dostępnej pamięci RAM jest tylko 16 bajtów. To niewiele, w związku z czym pod tym adresem znajduje się zwykle tylko instrukcja JMP kierująca procesor tam, gdzie naprawdę leży jego BIOS (tradycyjnie to F000:E05B). BIOS jest programem jak każdy inny i procesor go krok po kroku wykonuje. W ramach tego programu robiony jest POST (Power On Self Test) i procesor sprawdza, czy komputer jest w miarę kompletny i sprawny. Testy te zależą od tego, w jaki sposób komputer został zresetowany, więc i taką informację BIOS oczywiście ma. Jeżeli komputer wygląda na kompletny BIOS nakazuje procesorowi poszukać kart zawierających własny BIOS i uruchomienie tych rozszerzeń. W tym celu przeczesuje obszar pamięci od C800:0000 do F000:000 i jak znajdzie sygnaturę 55AA uruchamia to, co tam się znajduje. W obszarze tym swoje programy inicjujące mają na przykład karty rozszerzeń. Dzięki temu BIOS wie, jak obsłużyć daną kartę graficzną. Po prostu uruchamia jej kod i liczy, że to ona go swojej obsługi nauczy. Po tym wszystkim BIOS wczytuje (przy pomocy INT 19h) pierwszy sektor z urządzenia uznanego jako startowe do pamięci pod adres 0000:7C00 i przekazuje tam sterowanie uznając, że jego rola się skończyła. Jeżeli urządzeniem startowym jest dysk twardy również wczytywany jest jego pierwszy sektor, czyli tak zwany MBR (Master Boot Record). Tak oto, jak tylko komputer skończy inicjować sprzęt, wykonuje program zapisany w MBR. Dlatego MBR jest tak ważny i dlatego mówiąc o starcie systemu operacyjnego, właśnie MBR uznaje się za początek. Nowości w starcie Windows Vista Sektor tradycyjnie ma 512 bajtów, co wymaga od programistów dość zwięzłego podejścia, zwłaszcza, że ostatnie bajty zarezerwowane są na tablicę partycji. I tu zaczyna się nowe. W starszych systemach MBR ładował boot sektor aktywnej partycji, ten z kolei ładował NTLDR, który włączał tryb chroniony procesora, odczytywał boot.ini, uruchamiał ntdetect.com, który sprawdzał konfigurację sprzętu, a na końcu NTLDR uruchamiał ntoskrnl.exe i jakoś to dalej szło.
W Windows XP MBR mógł być dowolny pod warunkiem, że pozwalał na załadowanie boot rekordu z partycji systemowej. Co po drodze wyświetlał, gdzie sięgał, co inicjował, rozszyfrowywał lub uruchamiał nie miało znaczenia. Jeżeli tylko na końcu załadował boot record i oddał mu sterowanie, to system pozwalał się uruchomić. MBR mógł pytać o wybór systemu (tak robi na przykład LILO), mógł aktywować ukryte partycje (na przykład Partition Magic), rozszyfrowywać fragment dysku (na przykład SafeBoot), czy uruchamiać specjalne aplikacje do odzyskiwania danych (na przykład ThinkVantage Rescue and Recovery). W przypadku Windows Vista nie jest tak prosto. Choćby dlatego, że kod zapisany w MBR bardzo restrykcyjny (musi być zgodny ze specyfikacją TCG - Trustec Computing Group) Jeżeli ktoś koniecznie musi dodać własny kod i uruchamiać go przed startem systemu powinien omijać MBR. Proces startu Windows Vista zapewnia wsparcie dla takiego kodu, jednak uruchamiany jest on inaczej. Master Boot Recorder W Windows Vista MBR nie powinien być zmieniany. W szczególności, niezgodne będą MBR pochodzące z poprzednich wersji systemów Windows. Niezależnie od zgodności z Windows Vista, należy mieć świadomość, że uruchomienie systemu to nie wszystko. Nawet, jeżeli to się uda z alternatywnym Master Boot Recordem to kłopoty zaczną się przy szyfrowaniu (i rozszyfrowaniu) przy pomocy mechanizmów BitLocker. Próbując uruchomić system, BIOS wczytał MBR i oddał mu sterowanie. MBR, mając niewiele miejsca może wykonać tylko bardzo proste operacje. W przypadku Visty, MBR identyfikuje partycję startową (boot) i wczytuje z niej NTFS boot code. MBR powinien wczytać tylko pierwszy sektor partycji. Sektor taki ma 512 bajtów, a to może być za mało na wykonanie wszystkich operacji potrzebnych do uruchomienia systemu. Partycja zorganizowana jest jednak w taki sposób, że dane zapisywane są na niej od pierwszego sektora w cylindrze. Oznacza to, że nawet skoro boot record zajmuje zgodnie ze standardami tylko jeden sektor z cylindra, to pozostałe na pewno nie zostaną wykorzystane na dane. Dlatego bardzo dobrze nadają się one na zapisanie kodu, który może zostać wykonany w czasie startu systemu. Firma Microsoft oficjalnie informuje, że może tych sektorów używać dla swoich potrzeb i dlatego mimo, że istniały aplikacje chowające w nich jakieś dane, to od czasów systemów DOS nie jest to praktykowane. W rzeczywistości oznacza to rozszerzenie kodu ładującego z 512 bajtów do 8KB.
Rolą tego, co zapisane jest w NTFS boot code jest załadowanie i uruchomienie bootmgr. Plik ten znajduje się na partycji startowej (boot) i ma około 500KB. To dopiero on tak naprawdę uruchamia system operacyjny, wykonując wcześniej parę ważnych operacji. Ponieważ kod zapisany w NTFS boot code jest z konieczności mocno ograniczony, to nie umie on na przykład sięgnąć gdziekolwiek poza główny katalog dysku, nie umie nic zapisać na partycji NTFS i co ważne nie umie poradzić sobie z kompresją NTFS. Dlatego skompresowanie pliku bootmgr uniemożliwi start systemu. Z powodu prostoty NTFS boot code nie jest również obsługiwane żadne szyfrowanie pliku bootmgr. To właśnie z tego wynika potrzeba rozkładania chronionych BitLockerem danych na dwie partycje. Bootmgr musi być maksymalnie łatwy do odczytania, ponieważ używany jest do tego uproszczony kod. Po załadowaniu bootmgr, do niego właśnie przekazywane jest wykonanie i od tej pory to bootmgr odpowiada za to, co się dzieje dalej. Plik bootmgr Bootmgr potrafi już wykonać wiele operacji. Jest on z założenia niezależny od systemu operacyjnego i równie chętnie uruchomi Windows Vista, jak i Windows 2000 czy system Linux. Jedyne, co bootmgr musi wiedzieć, to informacje na temat tego, co ma do dyspozycji. W starszych systemach, w roli repozytorium informacji o dostępnych opcjach, występował plik boot.ini. Plik ten zawierał proste informacje tekstowe i był równie łatwy do świadomej edycji jak i nierozważnego popsucia. W przypadku Windows Vista zrezygnowano z prostego pliku tekstowego, zastępując go strukturą BCD. W środku BCD zorganizowane jest w hierarchiczną, drzewiastą strukturę i zapisywane w formie nie odbiegającej znacząco od danych przechowywanych w rejestrze systemu. BCD jest źródłem danych dla bootmgr i właśnie z niego odczytywane są informacje na temat tego jak ma się zachować komputer w czasie uruchamiania systemu. Ponieważ (w przeciwieństwie do MBR czy NTFS boot code) to, jak ma się zachować bootmgr, może mieć znaczenie dla końcowego użytkownika, struktury BCD dają się w miarę prosto edytować i przeglądać. Analizując szczegółowo zachowanie bootmgr, stwierdzić można, że inicjuje on kolejno: GDT (Global Descriptor Table) IDT (Interrupt Dispatch Table) Pamięć firmware
TPM - BitLocker Drive Encryption umożliwia zaszyfrowanie dysku komputera pracującego pod kontrolą Windows Vista i wykorzystuje do tego celu chip Trusted Platform Module jest to rozwiązanie sprzętowe Systemy plików Magistralę PCI Debugger Kartę graficzną Inicjuje sieć Wszystko to po to, żeby móc odczytać BCD. Jeżeli w BCD znajduje się więcej niż jedna pozycja, to bootmgr wyświetli użytkownikowi menu pozwalające na wybranie systemu do uruchomienia. Jeżeli pozycja jest tylko jedna wybór dokonywany jest automatycznie. Po dokonaniu wyboru bootmgr wczytuje wszystkie parametry wybranej pozycji z BCD, wśród których znajduje się między innymi położenie i nazwa programu, który odpowiadać będzie od tej pory za uruchomienie systemu. W przypadku Windows Vista jest to \Windows\system32\Winload.exe z partycji systemowej. O ile bootmgr można uznać za niezależny od systemu operacyjnego i zdolny do uruchomienia każdego systemu, o tyle Winload.exe jest fragmentem Windows Vista. Bootmgr potrafi zrozumieć i rozszyfrować dysk systemowy chroniony mechanizmami BitLocker. Jest to konieczne, ponieważ w standardowym scenariuszu plik Winload.exe jest zaszyfrowany. Aby przekazać do niego wykonanie dalszej części kodu, wszystkie operacje związane z pozyskaniem key protectors i otrzymaniem klucza VEK muszą być wykonane wcześniej. W efekcie to na bootmgr spoczywa obowiązek poproszenia użytkownika o klucz, pin, pamięć flash itp. Bootmgr potrafi porozumieć się z TPM, sprawdzić czy podany klucz jest prawidłowy i wykonać wszystkie operacje związane z rozszyfrowaniem dysków. Do pamięci ładowany jest plik w jawnej postaci i przez funkcję OslpMain przejmuje on kontrolę nad dalszymi losami systemu. Co potrafi plik Winload.exe Winload.exe po zainicjowaniu tych samych elementów, które inicjował bootmgr, a dodatkowo wykonuje następujące operacje: 1. Jeżeli włączono opcję logowania, zapisuje wszystkie swoje kroki do /Boot/boostat.dat na partycji startowej. Może się to przydać do śledzenia poważnych problemów ze startem systemu
2. Inicjuje wyświetlanie grafiki na ekranie 3. Odszukuje osloader.xml i pobiera z nich informację na temat tego, co ma wyświetlić na ekranie 4. Wyświetla startowy obrazek na ekranie - tu otwiera się pole do popisu dla tuningu optycznego. Osloader.xml może zawierać własne teksty i własne grafiki. Zasób taki nie jest bardzo trudny do zmienienia dedykowanymi narzędziami, za to pojawi się poważny problem, ponieważ plik jest podpisany cyfrowo. Zmiana choćby jednego bajta, nawet jak dotyczy to tylko obrazka na ekranie sprawi, że plik nie zostanie uznany za oryginalny i system nie uruchomi się. Mimo tego, można podmienić grafikę startową 5. Wyszukuje dostępne dyski 6. Ładuje gałąź rejestru HKEY_LOCAL_MACHINE 7. Po załadowaniu rejestru, następuje sprawdzenie integralności systemu 8. Po sprawdzeniu integralności ładuje do pamięci jądro systemu czyli ntoskrnl.exe oraz hal.dll, ale jeszcze nie przekazuje im kontroli 9. Ładuje potrzebne (opisane w załadowanej już gałęzi HKLM) sterowniki trybu boot. Domyślnie, Windows Vista sprawdza podpisy cyfrowe ładowanych sterowników; w przypadku działania debuggera Winload.exe powiadamia o niezgodności podpisu nie blokując startu systemu. Dla kilkunastu najważniejszych dla bezpieczeństwa sterowników weryfikacja musi przebiec poprawnie, niezależnie do tego, czy debugger jest aktywny, czy nie 10. Wczytywane są pliki wersji językowych (NLS) 11. Wyświetlany jest pasek postępu 12. Wczytywane są: a. parametry zgodności aplikacji b. parametry tabel ACPI c. plik errata.inf zawierający informacje o niepoprawnie wykrywanych urządzeniach PnP oraz PCI 13. Po udanym zakończeniu tych działań, Winload.exe zapisuje plik z logami, kończy zadania związane z obsługą mechanizmów BitLocker i przekazuje do załadowanego jądra systemu kontrolę Repozytorium informacji BCD Główną rolą bootmgr jest odczytanie BCD i uruchomienie tego, co mu BCD rozkaże. W normalnych warunkach jest to Winload.exe, jednak prosto można zmienić to zachowanie. W skrócie stwierdzić można, że BCD jest następcą pliku boot.ini. Aby samodzielnie edytować BCD należy mieć prawa administratora. Ponieważ najlepsze narzędzia obsługiwane są z commandline do takich operacji należy uruchomić cmd.exe z podniesionymi uprawnieniami.
Architektura BCD składa się z trzech poziomów: 1. BCD Store - jest jednostką najwyższego poziomu. W praktyce najczęściej BCD Store składa się wyłącznie z System BCD Store i jest równoważne całemu BCD. Fizycznie, BCD Store jest zestawem plików o formacie zgodnym z formatem gałęzi rejestru. Pliki BCD Store zapisane są w katalogu \boot partycji startowej. System BCD Store zawiera informacje o zainstalowanych systemach operacyjnych oraz o aplikacjach, które mogą być uruchamiane podczas startu systemu. 2. BCD Objects - BCD Store zawiera obiekty BCD Objects. Ich maksymalna ilość nie jest ograniczona i zazwyczaj w skład BCD Store wchodzi: o o obiekt Windows Boot Manager (jeden obiekt) - ułatwia mechanizmom bootmgr decyzję, kiedy i jaki obiekt Windows Boot Loader wybrać. W szczególności, w Windows Boot Manager zapisane są informacje na temat kolejności wyświetlania wpisów na liście systemów do wyboru, informację na temat tego, jaki czas bootmgr oczekiwać będzie na decyzję użytkownika oraz dane na temat tego, który system uruchomić, jeżeli w zadanym czasie użytkownik nie może się zdecydować Windows Boot Leader jeden lub wiele obiektów Inne typy obiektów, które czasem spotkać można w BCD Store to o o obiekt Windows ntldr - jest specjalnym obiektem wskazującym bootmgr, gdzie leży plik ntldr. Plik taki odpowiadał za załadowanie starszych wersji systemu. Stworzenie wpisu Windows Ntldr umożliwia na przykład dual boot pomiędzy Windows Vista a WindowsXP. Można to zrobić ręcznie, a można zdać się na program instalacyjny Windows, pamiętając jednak, że automatyczne rozwiązanie zadziała tylko wtedy, kiedy najpierw zostanie zainstalowany Windows XP, a dopiero po nim Windows Vista obiekt aplikacji - obiekt taki pozwala na uruchomienie dowolnej aplikacji zamiast uruchomienia systemu. Może to być program do backupu, aplikacja defragmentująca dyski twarde, program dający dostęp offline do plików itp. Przykładem aplikacji uruchamianej bezpośrednio przez bootmgr jest aplikacja testująca pamięć RAM. Aplikacja taka dostarczana jest z systemem Windows Vista. Można stworzyć własną aplikację uruchamianą zamiast systemu, jednak należy zdawać sobie sprawę, że napisanie takiego programu nie jest zadaniem prostym, bowiem żaden z istotnych mechanizmów Windows - nie ma dostępu do plików, rejestru, czy też Win32 3. BCD Elements Wszystkie opisane dotąd obiekty (Boot Manager, Boot Loader, Windows Ntldr i aplikacja) są obiektami typu aplikacyjnego. Poza tym typem, w BCD Store zapisane mogą być obiekty typów device oraz inheritable. Obiekty device opisują urządzenia, z których może zostać załadowany system, a których opis wykracza poza ramy pojedynczego BCD Element. Partycja dysku twardego jest w rozumieniu BCD bardzo prostym urządzeniem startowym, więc nie wymaga obiektu device. Przykładem urządzenia skomplikowanego (i używającego BCD device object) może być ramdisk stosowany do uruchamiania systemu przez sieć.
Obiekty inheritable są kontenerami przechowującymi wspólne cechy przeznaczone do dziedziczenia przez wiele innych obiektów równocześnie. Takie podejście pozwala na wprowadzanie zmian w jednym tylko obiekcie i korzystanie z nich we wszystkich innych (zwłaszcza typu application), które chcą te cechy dziedziczyć. Przykładem obiektu inheritable jest systemowa mapa uszkodzonej pamięci. Windows Vista potrafi pamięć taką omijać, więc warto o niej powiadomić wszystkie boot loadery. Robienie tego indywidualnie dla każdego wpisu byłoby nieefektywne a w nowych wpisach opcje te mogłyby zostać przeoczone. Dlatego lepiej ustawić jeden obiekt typu {badmemory} i liczyć na to, że wszystkie inne obiekty z informacji tej skorzystają. Każdy obiekt posiada własny, unikalny identyfikator GUID o długości 128 bitów oraz 32 bity opisu. Na ich podstawie bootmgr rozróżnia wpisy oraz jest w stanie rozpoznać typ obiektu. Samodzielna edycja BCD Edytować BCD możemy m.in. za pomocą: 1. Systemowej aplikacji bcdedit.exe - aplikacja ta daje pełną władzę nad BCD 2. Narzędzia msconfig - pozwala użytkownikowi skorzystać z GUI, ale tak naprawdę nie daje pełnej kontroli nad tym, co w BCD się dzieje Aplikacja bcdedit.exe obsługiwana jest z linii poleceń. Najważniejsze polecenia pracujące na obiektach to: Enum polecenie wyświetla listę zdefiniowanych obiektów. Domyślnie, dla wyświetlania używany jest kwantyfikator ACTIVE, jednak można pobrać obiekty należące do grup BOOTMGR, BOOTAPP, OSLOADER, INHERIT i innych. Wyświetlenie wszystkich obiektów możliwe jest przy użyciu kwantyfikatora ALL. Polecenie wyświetlające wszystkie obiekty z BCD będzie miało postać: bcdedit.exe /enum ALL Copy polecenie kopiuje wskazany obiekt, nadaje mu automatycznie nowy GUID i opis podany przez użytkownika w linii poleceń. Polecenie to jest dość wygodne do eksperymentowania ponieważ pozwala na przeprowadzenie testów, czy zmiany środowiska startowego bez naruszania oryginalnego obiektu w BCD. Przykładowa linia kopiująca domyślny wpis może brzmieć: bcdedit.exe /copy {default} /d wpis testowy Delete polecenie usuwa wskazany obiekt. Należy pamiętać, że usunięcie ostatniego wpisu typu Windows Boot Loader uniemożliwia start systemu. Na szczęście uruchomiony z płyty instalacyjnej proces recovery robi kopię istniejącego BCD, przywraca wpis i po restarcie system ożywa Create polecenie tworzy nowy wpis o zadanych parametrach
Wskazówki Przed eksperymentami warto zrobić export BCD. Może być nawet do pliku na tym samym dysku, na którym leży BCD System, który nie startuje, najlepiej naprawić z command Line Windows PE dostępnego z programu instalacyjnego Windows Vista (po uruchomieniu komputera z płyty DVD). Można wtedy wykonać import plików i naprawić popsuty BCD standardowym poleceniem bcdedit Program EasyBCD EasyBCD to aplikacja pozwalająca na zarządzanie w trybie graficznym programem rozruchowym systemu Windows Vista - Boot Configuration Data (BCD). Wśród najciekawszych opcji oferowanych przez program znajdziemy takie funkcje jak zmiana domyślnie uruchamianego systemu, zmiana czasu, po którym domyślny system na liście ma zostać uruchomiony (standardowo jest to 30 sekund), dodanie wpisów nowych systemów operacyjnych, zarówno którejś ze wcześniejszych edycji Windows jak i Maca,GNU/Linuksa czy nawet możliwość całkowitego zastąpienia BCD przez Gruba. Program pozwala także na zmianę domyślnych ustawień dotyczących startu samego systemu poprzez wyłączenie bądź włączenie DEP, PAE, czy też uruchamianie systemu w trybie Kernel-Debug. Możliwe jest również całkowite usunięcie BCD w przypadku usunięcia Visty i pozostawieniu na dysku Windowsa XP.
SYSTEMY OPERACYJNE WWW.EDUNET.TYCHY.PL
SYSTEMY OPERACYJNE WWW.EDUNET.TYCHY.PL
SYSTEMY OPERACYJNE WWW.EDUNET.TYCHY.PL