Pl/17 błędów Microsoftu popełnionych w systemie zabezpieczeń Xboksa

autor oryginału: Michael Steil , na język polski przetłumaczył DrJolo

Polskie tłumaczenie artykułu jest we wczesnej wersji alfa. Jeżeli któryś z akapitów mógłbyś przetłumaczyć lepiej, wprowadź odpowiednie poprawki po konfrontacji z oryginałem.

Wprowadzenie

Xbox to konsola do gier, wyprodukowana przez Microsoft Corporation pod koniec 2001 roku będąca konkurencją dla Sony Playstation 2 oraz Nintendo GameCube. Microsoft chciał zapobiec uruchamianiu na Xboksie skopiowanych gier, nieoficjalnych aplikacji oraz alternatywnych systemów operacyjnych. W celu realizacji powyższych założeń zaprojektowano i wdrożono system zabezpieczenia.

Artykuł ten dotyczy systemu zabezpieczeń Xboksa oraz błędów popełnionycych przez Microsoft. Nie wyjaśnia on podstawowych zagadnień takich jak przepełnienie buforu, oraz nie wyjaśnia, jak zbudować efektywny system zabezpieczenia. Jednak wyjaśnia, jak tego nie robić. Artykuł ten opisuje, jak łatwo popełnić ogromne pomyłki oraz jak łatwo ludzie zdają się przeceniać swoje umiejętności. Zatem artykuł ten opisuje także, jak uniknąć najczęściej popełnianych pomyłek.

Dla każdego zagadnienia dotyczącego zabezpieczenia artykuł ten najpierw wyjaśni projekt z punktu widzenia Microsoftu, a następnie opisze próby hakerów w celu złamania zabezpieczeń. Jeśli czytelnik znajdzie błędy w projekcie, będzie to dowodem, że Microsoft posiada słabych programistów. Jeśli, z drugiej strony, czytelnik nie znajdzie błędów, będzie to dowodem na to, że zaprojektowanie systemu zabezpieczenia jest w rzeczy samej trudnym zadaniem.

Sprzętowe wyposażenie Xboksa

Ponieważ Microsoft miał niewiele czasu na rozwój Xboksa, wykorzystał sprzęt zgodny z ogólnie dostępnym sprzętem PC wraz z własną technologią Windows i DirectX jako podstawy działania konsoli. Xbox zawiera procesor Pentium III Celeron mobile 733 MHz, 64 MB pamięci RAM, układ graficzny GeForce 3 MX z wyjściem telewizyjnym, dysk twardy o pojemności 10 GB na złączu IDE, napęd DVD na złączu IDE, kartę sieciową Fast Ethernet, a także kontroler USB dla gamepadów. Działa pod kontrolą uproszczonego jądra systemu Windows 2000, a gry zawierają statycznie zlinkowane przystosowane wersje Win32, libc oraz DirectX.

Chociaż brzmi to nieco bardziej jak komputer PC, to jednak, dla przykładu porównując z konsolą GameCube wraz z dedykowanym procesorem PowerPC, dedykowanym napędem optycznym oraz dedykowanymi złączami gamepadów, należy zauważyć, że ze sprzętowego punktu widzenia, wszystkie własności Xboksa są zgodne z komputerem PC: posiada magistrale LPC, PCI oraz AGP, posiada napędy IDE, posiada mostek północny oraz południowy, oraz zawiera wszystkie znane opcje platformy PC takie jak kontroler przerwań "PIC", czasomierz "PIT" oraz bramkę A20. nVidia sprzedała nieznacznie zmodyfikowany mostek południowy oraz północny z innym wbudowanym rdzeniem graficznym znanym na rynku PC jako chipset "nForce" w latach 2001-2002.

Przyczyny powstania systemu zabezpieczeń

Xbox będąc komputerem PC z tanim oraz, jak na owe czasu, mocnym CPU, powinien z łatwością zainstalować Linuksa. Nawet dziś mały i cichy zestaw PC 733 MHz z wyjściem telewizyjnym za 149 USD/EUR jest nadal atrakcyjny. Nie jest to jednak jedyna rzecz, której Microsoft chciał zapobiec. To są trzy sposoby użycia, które powinny być niemożliwe:

• Linux: Produkcja każdego zestawu Xboksa jest dotowana przez Microsoft, w celu maksymalnego obniżenia ceny zestawu, a zarabianie pieniędzy opiera się na sprzedaży gier, zatem użytkownicy nie powinni mieć możliwości kupna Xboksa bez zamiaru kupna jakiejkolwiek gry. Microsoft najwyraźniej przeczuwał, że umożliwienie wykorzystania Xboksa jako komputer z systemem Linux, byłoby dla korporacji zbyt kosztowne.
• nielicencjonowane programy własnej produkcji: Microsoft chce monopolu na oprogramowanie dla platformy Xbox. Nikt nie powinien mieć możliwości publikowania nielicencjonowanego oprogramowania, ponieważ Microsoft chce zarobić pieniądze na grach, aby zamortyzować straty poniesione na sprzedaży sprzętu. Nie chce także, aby ktokolwiek wydał przeglądarkę stron www inną niż Internet Explorer, oraz odtwarzacz multimediów inny niż Windows Media Player.
• Kopie gier: Z oczywistych względów było również istotne dla Microsoftu, aby nie było możliwości uruchamiania na Xboksie skopiowanych gier.

Microsoft podjął decyzję o zaprojektowaniu pojedynczego systemu zabezpieczenia, którego zadaniem było uniemożliwić uruchomienie na Xboksie Linuksa, nielicencjonowanego oprogramowania domowej roboty oraz kopii gier. Sposób osiągnięcia tego celu polegał po prostu na zablokowaniu uruchomienia wszelkiego oprogramowania, które nie jest zapisane na właściwym (originalnym) medium lub nie jest autorstwa Microsoftu.

Z jednej strony ten pomysł czyni system zabezpieczenia prostszym, w wyniku czego istnieje mniej potencjalnych słabych punktów. Jednak z drugiej strony 3 razy więcej atakujących ma jeden system zabezpieczenia do złamania. Chociaż społeczność Open Source wraz ze społecznością skupioną wokół Linuksa, deweloperzy hobbyści, firmy produkujące gry, a także krakerzy mają niewiele wspólnych interesów, mogli połączyć swój wysiłek i wspólnie złamać system zabezpieczeń Xboksa.

Wśród trzech konsol w swojej generacji, Xbox, Playstation 2 oraz GameCube, Xbox jest pierwszym, którego system zabezpieczeń został złamany, najprostszym do zmodyfikowania przez hobbystów, zawierającym najwięcej obejść systemu zabezpieczeń, jest także tym zawierającym najmocniejsze sztuczki. Wszystko to stało się możliwe ponieważ zabezpieczenie Xboksa jest najsłabsze spośród trzech wymienionych powyżej, oraz z powodu społeczności Open Source, deweloperów hobbystów oraz krakerów, którzy łamali Xboksa, podczas gdy społeczność Open Source nie atakowała Playstation 2, jako że Linux uzyskał oficjalne wsparcie od Sony. W wyniku tego łączna liczba hakerów była mniejsza, co dało Sony więcej czasu.

Pomysł Systemu Zabezpieczeń

Aby wyłącznie licencjonowany i autentyczny kod mógł być uruchamiany, koniecznym jest wykorzystanie łańcucha zaufania w rodzaju TCPA/Palladium, który sięga od uruchomienia systemu do właściwego uruchomienia gry. Pierwsze ogniwo łączy CPU oraz kod w pamięci ROM, który zawiera jądro Windows. Drugie ogniwo łączy jądro Windows z grą.

Jest kilka powodów, dla których system operacyjny zapisany jest w pamięci ROM (256 KB) zamiast na twardym dysku, tak jak to ma miejsce w przypadku komputerów osobistych. Po pierwsze, pozwala to skrócić czas uruchomienia systemu, jako że jądro systemu może być uruchamiane w czasie, gdy twardy dysk dopiero rozpędza swoje talerze. Po drugie, znacznie trudniej nadpisać pamięć ROM, niż zmodyfikować dane na twardym dysku, a to zmniejsza liczbę ogniw w łańcuchu zaufania, przez co pozwala uzyskać kompromis, jeśli chodzi o weryfikację jądra systemu.

Zabezpieczenie bootowania

Włączony do zasilania procesor x86 (lub kompatybilny) rozpoczyna wykonywanie instrukcji z adresu 0xFFFFFFF0 w przestrzeni adresowej, którą zazwyczaj jest pamięć flash. W przypadku Xboksa nie jest to dobry pomysł, gdyż pamięć flash może być:

• wymieniona, poprzez usunięcie chipa, dopasowanie podstawki oraz instalację zastępczego chipa.

• ominięta poprzez dodanie nadrzędnego flash-chipa do szyny LPC. Implementacja tej opcji jest konieczna. Gdy podczas produkcji pusty chip pamięci flash jest instalowany na płycie, podłączany jest także do płyty nadrzędny chip LPC ROM, z którego system jest uruchamiany, który następnie programuje wewnętrzną pamięć flash. Ta procedura jest znacznie tańsza od programowania chipów pamięci flash.

• przeprogramowana, gdyż pamięć flash może być wielokrotnie zapisywana. Istnieje możliwość użycia pamięci ROM zamiast flash, jednak pamięć ROM jest znacznie droższa od pamięci flash.

Zatem sprzęt nie może być bootowany z pamięci flash.

Z perspektywy Microsoftu

Istnieje możliwość zablokowania obu dróg ataku, poprzez użycie pamięci ROM zamiast flash. Nie byłoby żadnej możliwości przeprogramowania jej, oraz możnaby wyłączyć opcję nadrzędności LPC w chipsecie, gdyż nie byłaby ona już potrzebna w procesie produkcji.

Ukryty ROM

Istnieje rozwiązanie pośrednie pomiędzy pamięcią flash i ROM, które łączy zalety obu rozwiązań. To dość stara sztuczka, której używano w poprzednich konsolach do gier, takich jak Nintendo 64: zastosowano niewielki niepodmienialny kod startowy zawarty w pamięci ROM zawierający cyfrowy odcisk oprogramowania firmware (np. jądra Windows) w pamięci flash. "Wewnętrzny" ROM sprawdza czy zawartość pamięci flash jest autentyczna. Jeżeli tak, zawartość pamięci jest wykonywana.

W tej sytuacji będzie kolejny link w łańcuchu zaufania. Pamięci ROM można jednak zaufać (jeżeli chip jest niepodmienialny), oraz jeżeli dodatkowo jest niedostępna dla odczytu. W tej sytuacji osoba rozpracowująca system mogłaby nie mieć nawet żadnej wskazówki, jak działa weryfikacja.

Lokalizacia pamięci ROM

Ale gdzie pamięć ROM mogłaby być umieszczona? Nie może to być osobny chip, gdyż wówczas mógłby być z łatwością podmieniony. Pamięć ROM mogłaby być włączona w inny chip. Jednostka CPU byłaby idealna, gdyż w takiej sytuacji zawartość ROM nie byłaby przesyłana poprzez żadną z widocznych magistral. Jednak w tej sytuacji nie byłoby możliwe użycie tanich ogólnie dostępnych procesorów Celeron. Włączenie pamięci w każdy inny chip uczyni go niepodmienialnym, jednak dane będą transmitowane przez magistralę. Dobrym kompromisem wydaje się być umieszczenie pamięci ROM w mostku południowym Southbridge ("MCPX"), gdyż jest on podłączony poprzez bardzo szybką magistralę HyperTransport, którą bardzo trudno podłuchiwać. Były pracownik Microsoftu potwierdził, iż deweloperzy myśleli, że nikt nie będzie miał możliwości podłuchania magistrali HyperTransport.

Algorytm weryfikacji

Ukryty ROM przechowywany w mostku południowym powinien sprawdzić jądro Windows w zewnętrznej pamięci flash zanim zostanie ono uruchomione. Jednym z pomysłów jest suma kontrolna (hash) zawartości pamięci flash używając algorytmu MD5 albo SHA-1, jednak to by oznaczało, że suma kontrolna jądra musi być także przechowywana w ukrytej pamięci ROM, co uczyniłoby niemożliwym instalację zaktualizowanych wersji jądra w przyszłych Xboksach bez dodatkowej aktualizacji pamięci ROM - tzn. byłoby to bardzo kosztowne rozwiązanie.

Algorytm podpisu cyfrowego taki jak RSA byłby lepszy: możnaby wówczas zaktualizować jądro bez konieczności zmiany pamięci ROM, jednak implementacja RSA zajmuje dość dużo miejsca w pamięci, a wbudowana pamięć ROM w mostku południowym jest kosztowna. Byłoby idealnie jeśli implementacja algorytmu zmieściłaby się w 512 bajtach, co wyklucza RSA.

Drugi blok ładujący ("2bl")

Rozwiązaniem tego problemu jest powtórnie wprowadzenie kolejnego ogniwa w łańcuchu zaufania: ROM wykonuje sumę kontrolną małego bloku ładującego ("2bl", "drugiego bloku ładującego") zawartego w pamięci flash, który może pozostać niezmieniony. Następnie zadaniem tego bloku ładującego jest sprawdzić pozostałą zawartość pamięci flash. Ponieważ drugi blok ładujący może być dowolnego rozmiaru, nie ma ku temu żadnych ograniczeń.

Zatem ostateczny łańcuch zaufania wygląda następująco: CPU uruchamia blok ładujący z ukrytej pamięci ROM zawartej wewnątrz mostka południowego, która nie może ulec zmianie. Ukryty ROM sprawdza drugi blok ładujący w pamięci flash używając algorytmu symy kontrolnej. Jeżeli jest on autentyczny, wówczas zostaje uruchomiony. Drugi blok ładujący sprawdza jądro, i jeżeli jest autentyczne, wówczas zostaje uruchomione.

Teraz drugi blok ładujący oraz jądro Windows mogłyby być przechowywane w pamięci flash w postaci jawnej, co jest bardzo złym pomysłem: Atakujący mógłby natychmiast zobaczyć, w jaki sposób drugi blok ładujący sprawdza integralność jądra, a także przeanalizować złożoność jądra w celu znalezienia potencjalnych exploitów. Zaszyfrowanie całej zawartości flash nie rozwiąże potencjalnych słabych punktów, jednak da nam to trochę czasu, dopóki hakerzy nie zrozumieją szczegółów deszyfrowania zawartości flash.

Klucz deszyfrujący mógłby być przechowywany w ukrytej pamięci ROM, oraz kod weryfikujący drugiego bloku ładującego 2bl musiałby także deszyfrować zawartość flash w pamięci RAM podczas odczytu.

Inicjacja pamięci RAM

Deszyfrowanie zawartości flash w pamięci RAM jest wyzwaniem, jeśli znajdujemy się w pierwszych kilkuset bajtach kodu wykonywanego tuż po uruchomieniu. Na tym etapie pamięć RAM może nie zachowywać się jeszcze stabilnie. Powodem tego jest zakupienie przez Microsoft tanich chipów RAM; zakupiono po prostu wszystko, co Samsung mógł zaoferować, by obniżyć cenę, nawet wadliwe egzemplarze, np. chipy, które były niestabilne, gdy taktowano je najwyższą dostępną w specyfikacji częstotliwością.

Xbox powinien zatem najpierw znaleźć najwyższą szybkość taktowania, dla której pamięć RAM może pracować stabilnie, a dopiero później uruchomić system oraz gry przy tej częstotliwości. Jest to powodem, dla którego część gier nie działa na jednych Xboksach tak płynnie, jak na innych egzemplarzach. Zatem blok ładujący w ukrytej pamięci ROM musi wykonać test pamięci RAM. Jeśli pamięć nie przejdzie testu, częstotliwość taktowania pamięci RAM jest zmniejszana. Następnie wykonywany jest kolejny identyczny test pamięci. Jeżeli znowu zakończy się niepowodzeniem, taktowanie pamięci RAM jest ponownie zmniejszane. I tak w kółko, dopóki test nie zakończy się sukcesem albo dopóki nie będzie możliwości dalszego obniżenia częstotliwości taktowania RAM.

Problem polega na tym, że jest niemożliwe wykonanie złożonej inicjacji pamięci RAM, deszyfrowania oraz sumy kontrolnej danych w 512 bajtach. Taki kod musiałby zajmować przynajmniej 2 KB, co było by znacznie droższe, jeśli chcemy go umieścić w mostku południowym.

Kod wykonujący inicjację RAM, która zajmuje największą część tego, co kod ładujący ma do wykonania, moglibyśmy umieścić w pamięci flash, a następnie wywoływać go z ukrytej pamięci ROM. Ale to byłby cios dla bezpieczeństwa, gdyż haker mógłby z łatwością podejrzeć nieszyfrowany kod w pamięci flash, zmodyfikować go oraz uzyskać kontrolę nad sprzętem tuż po uruchomieniu.

Deweloperzy w Microsoft mieli wspaniały pomysł, jak rozwiązać ten problem. Zaprojektowali interpreter dla maszyny wirtualnej, który może dokonywać odczytu i zapisu pamięci, ma dostęp do przestrzeni konfiguracyjnej PCI, wykonywać obliczenia "AND" oraz "OR", skoki warunkowe itp. Kod instrukcji posiada jeden bajt dla intrukcji oraz dwa 32-bitowe operandy. Może używać natychmiastowych wartości także jako akumulator.

Interpreter dla maszyny wirtualnej przechowywany jest w ukrytej pamięci ROM, natomiast jego kod (tzw. "xkod") w pamięci flash. Ten kod dokonuje inicjacji pamięci (plus dodatkową inicjację sprzętu, która nie byłaby konieczna). Ten program nie może być zaszyfrowany, gdyż ponownie brak na to miejsca w ukrytej pamięci ROM. Jednak skoro wirtualna maszyna nie jest znana hakerowi, szyfrowanie nie powinno być aż tak istotne. Nie można również na nim przeprowadzić sumy kontrolnej, gdyż to uniemożliwiłoby zmianę xkodu dla późniejszych wersji sprzętu Xboksa. Dlatego musimy być pewni, czy haker wie, jak działa wirtualna maszyna, gdyż wówczas nie będzie możliwe wykonanie niczego złośliwego z xkodem.

Maszyna wirtualna

Jest kilka sposobów, na które haker mógłby umieścić exploita w xkodzie, do którego z definicji nie ma zaufania, ponieważ przechowywany jest w "zewnętrznej" pamięci flash. Microsoft dołączył pewien kod, by upewnić się, że nie ma żadnych możliwych exploitów.

Odczyt ukrytej pamięci ROM

Xkod może czytać pamięć oraz ma dostęp do portów we/wy. W ten sposób haker mógłby umieścić xkod w pamięci flash, która zrzuci ukryty ROM, który musi być zmapowany gdzieś do przestrzeni adresowej, do powolnej szyny np. LPC albo I2C, albo zapisze go do pamięci CMOS lub EEPROM, tak by móc ją odczytać później.

Interpreter xkodu musi mieć pewność, że xkod nie może odczytać ukrytej pamięci ROM, która zlokalizowana jest w górnej części 512 bajtów przestrzeni adresowej. Najprostszą drogą osiągnięcia tego celu jest zamaskowanie adresu podczas odczytu z pamięci:

   and ebx, 0FFFFFFFh  ; kasuje górne 4 bity
   mov edi, [ebx]       ; read from memory location op1 into di
   jmp next_instruction

W ten sposób xkod może być jedynie dostępny z dolnej części 256 MB, co nie stanowi problemu, gdyż mamy jedynie 64 MB pamięci RAM, a zmapowane do pamięci porty we/wy mogą być zmapowane do tego przedziału poprzez użycie cykli konfiguracji PCI.

Wyłączenie ukrytej pamięci ROM

Xkod nie może również wyłączyć ukrytej pamięci ROM, albo w przeciwnym wypadku CPU, podczas wykonywania interpretera xkodu, mógłby "skoczyć" z ukrytej pamięci ROM do leżącej poniżej pamięci flash, która również jest zmapowana do górnego końca przestrzeni adresowej. Opcja wyłączenia jest ważna, gdyż, jak tylko drugi blok ładujący przejmie kontrolę, ukryty ROM musi zostać wyłączony, albo w przeciwnym wypadku haker przeciw grze, która spowoduje możliwość wykonania dowolnego kodu, mógłby zrzucić i odczytać zawartość ukrytej pamięci ROM, umożliwiając przeciwko niej kolejny atak.

Ukryty ROM może być wyłączony poprzez zapisanie wartości z bitem #1 ustawionym do przestrzeni konfiguracji PCI urządzenia 0:1:0, rejestr 0x80. W ten sposób interpreter xkodu zawsze kasuje ten bit w sytuacji zapisu do tego rejestru przestrzeni konfiguracyjnej PCI:

   cmp ebx, 80000880h         ; ISA Bridge, MCPX wyłączony?
   jnz short not_mcpx_disable ; nie
   and ecx, not 2             ; wyczyść  bit 1
not_mcpx_disable:
   mov eax, ebx
   mov dx, 0CF8h
   out dx, eax                ; adres konfiguracji PCI
   add dl, 4
   mov eax, ecx
   out dx, eax                ; dane konfiguracji PCI
   jmp short next_instruction

Szyfrowanie oraz suma kontrolna

Do deszyfrowania drugiego bloku ładującego Microsoft wybrał algorytm RC4, którego implementacja zajmuje małą objętość i może zmieścić się z powodzeniem w 150 bajtach. Używa 16-bajtowego klucza, który także przechowywany jest w ukrytej pamięci ROM. Inżynierowie Microsoftu zdecydowali o użyciu RC4 również jako sumy kontrolnej, tak aby żaden dodatkowy algorytm nie musiałbyć implementowany do tego celu w pamięci. Algorytmy różnicowego deszyfrowania kierują odszyfrowane dane do generatora strumienia klucza deszyfrującego. Zatem, jeśli jeden bajt zaszyfrowanego kodu został zmieniony, wszystkie następne bajty będą deszyfrowane nieprawidłowo aż do ostatniego bajtu. W ten sposób jest możliwe przetestowanie jedynie ostatnich kilku bajtów. Jeżeli zostały deszyfrowane prawidłowo, wówczas zaszyfrowany kod był autentyczny. (Jeżeli zaczynasz coś podejrzewać, czytaj dalej!)

W praktyce ukryty ROM w Xboksie porównuje wartości ostatnich 32 bitów ze stałą wartością 0x7854794A. Jeżeli jest niewłaściwa, Xbox musi wykonać kod zatrzymania systemu.

Kod zatrzymujący konsolę

Jak do tej pory, kod w ukrytej pamięci ROM wykonuje następujące rzeczy:

• wprowadza do trybu chronionego, oraz ustawia deskryptory segmentów, tak abyśmy mieli dostęp do całej 32-bitowej przestrzeni adresowej.
• interpretuje xkod.
• deszyfruje oraz liczy sumę kontrolną drugiego bloku ładującego, przechowuje go w pamięci RAM
• jeżeli suma jest prawidłowa, wykonuje skok do drugiego bloku ładującego w pamięci RAM, w przeciwnym wypadku zatrzymuje działanie konsoli.

Istnieje tutaj kolejna możliwość ataku: haker mógłby celowo spowodować niezgodność sumy kontrolnej. Jeżeli Xbox się wówczas zatrzyma i mruga swoimi kontrolkami by zasygnalizować błąd, haker mógłby podłączyć urządzenie do zrzucenia ukrytej pamięci ROM w czasie, gdy CPU jest wyłączone, a magistrala nie używana. Chociaż HyperTransport jest szybka magistralą, byłoby znacznie prościej podłączyć urządzenie, które aktywnie żada danych z mostku południowego niż podsłuchiwać tę magistralę, kiedy procesor żąda od niej danych.

Jednym z rozwiązań byłoby wyłączenie Xboksa w sytuacji problemowej zamiast wstrzymania. Układ zasilania posiada taką funkcjonalność. Jednak niewłaściwa pamięć flash niekoniecznie oznacza, że nastąpił atak. To może być także awaria, a w takiej sytuacji konsola powinna wykorzystać kontrolne diody LED by wskazać kod błędu.

Zatem powinniśmy pozostawić Xboksa włączonego, jednak wyłączając ukryty ROM, tak aby nie mógł być później odczytany. Jest tu jednak pewien problem: musimy wykonać to wewnątrz ukrytej pamięci ROM. Jeśli zatem wyłączymy ROM, nie będziemy mogli użyć po tej operacji intrukcji "hlt", gdyż CPU "opadnie" do pamięci flash - gdzie haker mógłby umieścić swój kod. Z drugiej strony, jeśli zatrzymamy CPU, nie będziemy mogli później wyłączyć ukrytej pamięci ROM.

Nie możemy umieścić kodu wyłączenia ROM i wstrzymania CPU w pamięci RAM i skoczyć do tego miejsca, gdyż pamięć RAM może być niestabilna. Może być nawet zmodyfikowana przez hakera (np. poprzez kontroler pamięci używając xkodów) tak, że ukryty ROM nie będzie wyłączony. Nie możemy także umieścić kodu wyłączenia ROM i wstrzymania CPU w pamięci flash, gdyż znowu, haker mógłby po prostu wstawić spreparowany kod, by skierować tam cały system.

Inżynierowie w Microsoft użyli jeszcze jednej "wspaniałej" sztuczki: wykonali skok do samego końca przestrzeni adresowej (która jest "przykryta" ukrytą pamięcią ROM) i wyłączyli ukryty ROM w ostatniej instrukcji wewnątrz przestrzeni adresowej. To uproszczona wersja tego pomysłu:

FFFFFFF1    mov eax, 80000880h
FFFFFFF6    mov dx, 0CF8h
FFFFFFF9    out dx, eax
FFFFFFFB    add dl, 4
FFFFFFFC    mov al, 2
FFFFFFFE    out dx, al

Po wykonaniu ostatniej instrukcji, licznik programu (EIP) będzie przepełniony do 00000000, co zgodnie z dokumentacją CPU spowoduje wyjątek. Ponieważ nie zdefiniowano obsługi wyjątku, spowoduje to podwójny błąd, co efektywnie zatrzyma konsolę.

Z perspektywy hakera

To tyle, jeśli chodzi o teorię. Projekt wyglądał bardzo dobrze, jednakże kompromis pomiędzy kosztami a bezpieczeństwem, na jaki się zdecydowano, mógłby przyprawić wielu ludzi o ból głowy. Pozwólmy teraz rzucić okiem na Xboksa z punktu widzenia hakerów.

Było wiadome, że chipset Xboksa jest zmodyfikowaną wersją chipsetu nForce wyprodukowanego przez nVidia. Wiedzieliśmy zatem, że był to standardowy IDE, USB, była wewnętrzna magistrala PCI itd. Dwóch hakerów z Wielkiej Brytanii, Luke oraz Andy, sprawdzili dysk twardy i dowiedzieli się, że używa on zwyczajnego schematu partycji oraz systemu plików podobnego do FAT. Dowiedzieli się, że na twardym dysku nie ma jądra systemu. Jest jednak panel kontrolny Xboksa na czwartej partycji - główny program, który umożliwia zmianę ustawień, odtwarzanie płyt Audio-CD oraz zarządzanie save'ami gier, uruchamiany, jeżeli nie ma żadnej gry w napędzie DVD.

Wydobywanie ukrytej pamięci ROM

Andrew "bunnie" Huang, później doktorant MIT, rozłożył swojego Xboksa na części, odpiłował i odlutował pamięć flash, wydobył jej zawartość, opublikował ją na swojej stronie www i odbył rozmowę telefoniczną z jednym z prawników Microsoftu.

Obraz pamięci flash był oczywiście zaszyfrowany, jednak był tam również kod binarny x86 w górnych 512 bajtach! Naturalnie nie powinno być żadnego kodu w górnych 512 bajtach, jako że są one przysłonięte przez ukryty ROM, który zawiera właściwy kod startowy konsoli oraz kod deszyfrujący pamięć flash.

Bunnie zauważył, że owy kod był interpreterem dla tablic w pamięci flash wraz z funkcją deszyfrującą podobną do RC4. Przepisał zatem krypto-kod w języku C oraz wypróbował go na porcji danych - jednak dane wynikowe okazały się losowe. Gdzieś zatem tkwił błąd. Interpreter nie miał także wiele sensu. Kod używał opkodów, które były nieznane dla interpretera.

W celu odnalezienia, gdzie tkwił błąd, bunnie przepisał górną część pamięci flash przy pomocy własnego kodu, a następnie całkowicie wymazał górne 512 bajtów. Jednak Xbox nadal startował! Było zatem oczywiste dla bunniego, że ten region pamięci jest przesłaniany przez jakiś wewnętrzny kod. Jak się później okazało, kod w górnych 512 bajtach obrazu flash musiał być bardzo starą wersją ukrytego kodu ROM, który w niezamierzony sposób został dołączony do obrazu przez narzędzia budujące. Wygląda na to, że nikt nie spojrzał na ostateczny obraz przed dostarczeniem konsoli na półki sklepów. Ten błąd był nieomal fatalny, i Microsoft miał dużo szczęścia, że nie dołączyli tam aktualnej wersji pamięci ROM.

Jednak nie zrobiło to żadnej wielkiej różnicy, jako że bunnie podsłuchał magistrale i dokonał zrzutu całej zawartości ROM, włączając klucz RC4 z magistrali HyperTransport. Użył do tego celu specjalnie zbudowanego sniffera. Po tym wszystkim pracował nad swoją pracą doktorską dotyczącą obliczeń wysokiej wydajności używając wspaniałego wyposażenia laboratoriów MIT.

Gdy opublikował swoje spostrzeżenia, inni ludzie zauważyli dość szybko, że test autentyczności właściwie niczego nie wykonywał. Kombinacja deszyfrowania i sumy kontrolnej z szyfrem, który kierował spowrotem odszyfrowane dane do strumienia klucza jest dobrym rozwiązaniem, ale niestety RC4 nie jest tym szyfrem. Odszyfrowuje on bajty danych niezależnie, tak że, jeśli jeden bajt jest nieprawidłowy, wszystkie następujące po nim bajty będą nadal odszyfrowywane prawidłowo. Zatem sprawdzanie ostatnich czterech bajtów nie dawało żadnego efektu - to nie była suma kontrolna.

Okazało się, że szyfr użyty w poprzedniej wersji ukrytego kodu ROM znalezionego w pamięci flash wykorzystywał algorytm RC5. W przeciwieństwie do RC4, RC5 kieruje odszyfrowany strumień spowrotem do strumienia klucza. Najwyraźniej inżynierowie Microsoft zrezygnowali z RC5 na rzecz RC4 nie rozumiejąc, że RC4 nie może być wykorzystany jako suma kontrolna. Teoria bunniego, dlaczego zrezygnowali z RC5 była następująca: prace nad RC5 były ciągle w toku, i najwyraźniej Microsoft jeszcze nie posiadał gotowej implementacji, skorzystali zatem z najbliższego pokrewnego algorytmu - RC4.

Modchipy

Skoro klucz szyfrujący był znany oraz efektywnie nie było żadnej sumy kontrolnej dla drugiego bloku ładującego, stało się możliwe "łatanie" tego kodu. Ludzie dodali swój kod do drugiego bloku ładującego by wprowadzić poprawki do jądra po odszyfrowaniu (i dekompresji), by akceptował programy nawet, jeśli znajdowały się na niewłaściwym nośniku (DVD-R zamiast oryginalnej płyty DVD) lub jeżeli podpis RSA programu był niewłaściwy (np. w przypadku napisanego przez siebie oprogramowania).

Pojawiły się modchipy. Niektóre z nich całkowicie zastępowały kość pamięci flash, inne jedynie poprawiały kilka bajtów i kierowały większość odczytów prosto do oryginalnej kości flash. Wszystkie te modchipy musiały być wlutowane równolegle do oryginalnej kości flash wykorzystując 31 kontaktów.

Inni ludzie zauważyli, gdy brakuje kości flash, Xbox żąda odczytu z nieistniejącej kości ROM podłączonej do szeregowej magistrali LPC. Miało to miejsce ze względu na proces produkcji. Jak już zostało wyjaśnione wcześniej, kość flash jest programowana będąc już na płycie głównej podczas pierwszego uruchomienia przy wykorzystaniu zewnętrznej kości LPC ROM. Twórcy modchipów wkrótce opracowali kości, które wymagały 9 kontaktów i były podłączane do magistrali LPC. Wystarczyło połączyć z masą linię danych D0, aby Xbox "myślał", że pamięć flash jest pusta.

Wiele z tych "tanich modów" ukazało się jako pojedyncze kości szeregowej pamięci flash. Mogły być dzięki temu zainstalowane w czasie nie przekraczającym 60 sekund, szczególnie później, gdy część firm zaczęło dostarczać kości wykorzystujące kontakty typu "pogo". Dzięki temu przy montażu nie trzeba było używać lutownicy.

Kilka grup napisało aplikacje w rodzaju menu startowego, co umożliwiło kopiowanie gier na dysk twardy oraz późniejsze uruchamianie ich bezpośrednio z dysku twardego. Pojawiły się poprawione wersje jądra Xbox wspierające większe twarde dyski. Możliwe było łatwe uruchamianie na Xboksie kopii z płyt DVD-R lub z twardego dysku, jak również aplikacji domowej roboty, napisanych przy wykorzystaniu oficjalnego pakietu Xbox Software Development Kit.

Tylne furtki

Projekt Xbox-Linux pracował nad dwoma sposobami uruchomienia Linuksa: uruchomić jądro Linuksa z napędu CD/DVD tak, jakby był grą, lub uruchomić go bezpośrednio z pamięci flash (lub HD/DVD) wykorzystując blok ładujący Linuksa w pamięci flash, tak aby Xbox zachowywał się jak PC. W drugim przypadku Xbox-Linux pracował na podmienionym kodzie firmware.

Nie byłoby żadnego problemu w zapisaniu zamiennego firmware'u, który przejąłby wykonanie zamiast drugiego bloku łądującego. Możliwe było całkowite zastąpienie drugiego bloku ładującego, jak również jego zaszyfrowanie przy użyciu dobrze znanego klucza z ukrytej pamięci ROM. Jednak deweloperzy firmware'u nie czuli się komfortowo na myśl o użyciu tego tajnego klucza w ich kodzie na licencji GPL. Pozostali hakerzy czuli się podobnie, w wyniku czego szukali błędów i tylnych furtek w ukrytym kodzie ROM. Miało to na celu odnaleznienie sposobu zaimplementowania zastępczego firmware'u bez konieczności wykorzystania szyfrowania.

Tylna furtka visora

Haker o ksywie visor, który nigdy nie ujawnił swojego prawdziwego nazwiska, zastanawiał się czy przejście do adresu 00000000 w sytuacji niewłaściwej "sumy kontrolnej" drugiego bloku ładującego naprawdę powoduje podwójny błąd i zatrzymuje procesor. Użył xkodów, by napisać instrukcję assemblera wykonującą "jmp 0xFFFF0000" do lokalizacji 00000000 w pamięci RAM oraz zmienił ostatnie cztery bajty w drugim bloku ładującym, chcąc wymusić na ukrytym kodzie ROM uruchomienie kodu zatrzymującego konsolę. Xbox na szczęście kontynuował wykonanie instrukcji spod adresu 00000000 i wykonał skok do pamięci flash.

Gdy dodawał te instrukcje do istniejących xkodów, mógł być pewnym, że RAM został prawidłowo zainicjowany i pracował stabilnie. Nie było już zatem konieczności szyfrowania bloku ładującego Xbox Linux firmware przy wykorzystaniu tajnego klucza. To wystarczyło aby dodać instrukcję zapisu pamięci na sam koniec xkodów i upewnić się, że deszyfrowanie drugiego bloku ładującego się nie powiedzie - co stanie się automatycznie, jeżeli zamiana firmware'u nie zawiera samego kodu drugiego bloku ładującego.

Zatem dlaczego nie nastąpił podwójny błąd? Hakerzy z grupy Xbox Linux zapytali o to pracowników AMD, którzy wyjaśnili to następująco: procesory AMD zgłaszają wyjątek w sytuacji przepełnienia EIP, jednak procesory Intela nie.

Przyczyny takiego zachowania procesorów Intela sięgają lat 70-tych. Wykonanie poleceń przez procesory x86 rozpoczyna się od górnego końca przestrzeni adresowej (minus 16 bajtów). Jednak kilku producentów komputerów chciało mieć swoje pamięci ROM w dolnym końcu przestrzeni adresowej, np. w lokalizacji 0. W związku z tym Intel zaimplementował instrukcję o kodzie 0xFFFF, której efekt jest taki sam, jak podczas próby odczytu z adresu nie podłączonego do żadnego chipa, jako No-Operation ("nop") bez zgłoszenia wyjątku przez CPU w sytuacji, gdy kończy się przestrzeń adresowa i wykonywany jest skok do jej początku. W ten sposób, CPU mógł wykonać "nop" swojego wykonania do górnego początku, więc ostatecznie wykonuje kod z adresu 0.

AMD nie zaimplementował takiego zachowania, gdyż nie było to już konieczne w czasie, gdy AMD wchodził na rynek x86 ze swoimi własnymi projektami. Ponadto podejrzewano, że takie zachowanie CPU stanowiło lukę bezpieczeństwa, której usunięcie nie powodowało znaczącej niekompatybilności.

Jednak dlaczego Microsoft popełnił ten błąd? Można to wyjaśnić na podstawie historii Xboksa: AMD zaoferował projekt oraz wykonanie zarówno jednostki CPU, jak i płyty głównej (wraz z chipsetem), natomiast nVidia miała, zgodnie z umową, opracować jednostkę graficzną. Pierwsze systemy dla deweloperów, nawet na zewnątrz Microsoftu, bazowały na procesorze Athlon. Później jednak pojawił się Intel i zaoferował swoje procesory za niższą cenę, wraz z gruntowną zmianą projektu istniejącego chipsetu AMD, tak by współpracował z ich procesorami. W konsekwencji, nVidia zakupiła licencję chipsetu AMD tak, by nazwa AMD zniknęła. To również oznacza, że chipset nVidia nForce jest w zasadzie technologią AMD, zbliżoną do chipsetu AMD-760.

W związku z tym Microsoft zamienił procesory AMD na jednostki Intela. Jednak najwyraźniej zapomnieli przetestować swój kod zabezpieczający z nowym sprzętem, bądź przeczytać dokumentację Intela.

Obejście MISTa

Niedługo po odkryciu visora znaleziono kolejny słaby punkt w ukrytym kodzie ROM - atakując kod, który sprawdza, czy xkod chce wyłączyć ukryty ROM. Spójrzmy ponownie na kod:

   cmp ebx, 80000880h         ; mostek ISA, MCPX wyłączone?
   jnz short not_mcpx_disable ; nie
   and ecx, not 2             ; clear  bit 1
not_mcpx_disable:
   mov eax, ebx
   mov dx, 0CF8h
   out dx, eax                ; adres konfiguracji PCI
   add dl, 4
   mov eax, ecx
   out dx, eax                ; dane konfiguracji PCI
   jmp short next_instruction

Adres konfiguracji PCI przechowywany jest w rejestrze EBX na początku. Ten adres ma być wysłany do portu wejścia/wyjścia 0x0CF8, oraz 32 bity ma być wysłane do portu we/wy 0x0CFC. Adres kodowany jest następująco:

0-7    reg
8-10   func
11-15  device
16-23  bus
24-30  reserved
31     always 1

Sposób ataku jest dość oczywisty: w adresie zarezerwowanych jest 7 bitów, a kod testuje każdą pojedynczą wartość. Co się stanie, jeżeli zaczniemy pisać pod alias tego samego adresu, wykorzystując adres z jedynie kilkoma zmienionymi bitami na pozycji do 24 do 30? Podczas gdy instrukcja

POKEPCI(80000880h, 2)

będzie wykonana, instrukcja

POKEPCI(C0000880h, 2)

nie. A jednak druga instrukcja również zadziała, gdyż kotroler magistrali PCI po prostu ignoruje nieużywane bity.

Ta instrukcja wyłącza ukryty ROM tak, że interpreter wyłącza się, kiedy wysyłana jest wartość do portu 0x0CFC, a jednostka CPU "spada" do pamięci flash. Możemy umieścić "lądowisko" w pamięci flash wypełniając wszystkie górne 512 bajtów instrukcjami "nop", i wstawiając skok do początku pamięci flash w ostatniej instrukcji, tak, że nie musimy się martwić, gdzie właściwie ląduje CPU, oraz uniezależniliśmy się od trudnych do odtworzenia efektów caching'u.

Trudno znaleźć inną przyczynę tego błędu niż niedbalstwo. Musi być zatem cechą charakterystyczną, by nie czytać dokumentacji wystarczająco uważnie, jak również nie patrzeć na problem z perspektywy hakera wystarczająco wnikliwie. Jakby na to nie spojrzeć, ten kod mógł być napisany nie mając na myśli ataku, jednak ułatwił proces łamania dając hakerom wskazówkę, jak zaatakować.

Kolejny atak konfiguracji PCI

Istnieje inna sekwencja instrukcji xkodu, która, nie będąc zauważona przez interpreter, także może wyłączyć pamięć ROM. Interpreter posiada możliwość zapisu bajtów do portów we/wy, jest zatem możliwe umieścić razem kod wyłączający ukryty ROM używając 8-bitowych zapisów we/wy :

OUTB(0xcf8), 0x80
OUTB(0xcf9), 0x08
OUTB(0xcfa), 0x00
OUTB(0xcfb), 0x80
OUTB(0xcfc), 0x02

Ten rodzaj obejścia nie był do tej pory opublikowany. Odkryto go niedługo po ataku MIST'a. Jednak trzymano w sekrecie na wypadek, gdyby Microsoft załatał błąd odkryty przez MISTa. W późniejszym czasie inżynierowie z Microsoft zaimplementowali poprawkę, która uniemożliwiła wszystkie obejścia bazujące na wyłączeniu ukrytego ROMu. Będzie to będzie opisane później.

Więcej pomysłów

Było znacznie więcej pomysłów, jednak kilka z nich zostało zrealizowanych, dopóki działała inna istniejąca tylna furtka. Jednym z możliwych pomysłów jest oparcie ataku na caching'u...

Zabezpieczenie bootowania, podejście drugie

Gdy bunnie złamał ukryty ROM, Microsoft zareagował aktualizując ROM. Tysiące świeżo wyprodukowanych mostków południowych wyrzucono na śmietnik. Wyprodukowano nowe. Społeczność hakerów nazwała te konsole jako Xboksy "wersja 1.1".

Z perspektywy Microsoftu

Microsoft już zrozumiał, że RC4 nie może być użyte jako suma kontrolna. Zaimplementowali więc dla tego zadania dodatkowy algorytm, który miał być uruchomiony tuż po odszyfrowaniu. Jako że zostało tylko kilka nieużywanych bajtów, algorytm sumy kontrolnej musiał być maleńki - zatem użyto "Maleńkiego Algorytmu Szyfrującego" (w skrócie "TEA" od angielskich słów "Tiny Encryption Algorithm"). Każdy algorytm szyfrowania musi być zmodyfikowany, aby wykorzystać go jako sumę kontrolną. Wydawało się, że TEA był dobrym wyborem, gdyż był rzeczywiście niewielki. Kiedy byli na tym etapie, zmienili także klucz RC4 w ukrytej pamięci ROM, tak aby hakerzy nie mieli możliwości odszyfrowania drugiego bloku ładującego oraz jądra bez odczytania nowej ukrytej pamięci ROM.

Z perspektywy hakera

Wydobycie ukrytej pamięci ROM zostało przeprowadzone tym razem przez członków projektu Xbox Linux w zaledwie kilka dni po tym, jak już dostali nowe Xboksy 1.1 w swoje ręce, i jedynie dwa tygodnie po czasie, gdy po raz pierwszy się ukazały.

A20 Hack

Do dziś Microsoft nie wie, jak tego dokonaliśmy. Jednak możemy to teraz zdradzić, skoro nadchodzi właśnie Xboks 360 i najprawdopodobniej nie będzie już nowych wersji Xboksa.

Na początek nieco historii komputera PC. Jednostka 8086/8088, pierwszy CPU w linii x86, miał być bardzo kompatybilny z 8080, co było wielkim sukcesem na rynku CP/M. Zatem model pamięci był podobny do 8080, co dawało dostęp jedynie do 64 KB poprzez podzielenie pamięci na 64-kilobajtowe bloki. Intel zadecydował, że 8086/8088 może mieć maksymalnie 1 MB pamięci RAM, co oznaczało 16 "segmentów" po 64 KB każdy. Jednak zamiast zrobić to w ten sposób, postanowili, że 64-kilobajtowe segmenty będą na siebie zachodzić, w wyniku czego otrzymali 65536 tych segmentów zaczynających się co 16 bajtów.

Adres był zatem określony poprzez segment i offset. Segment mógł być podzielony na 16 części, oraz musiał być dodany offset, aby uzyskać właściwy adres pamięci. Dla przykładu: 0x0040:0x006C byłby 0x40*0x10+0x6C=0x46C. Interesującym skutkiem tej metody była możliwość zaadresowania pamięci powyżej 1 MB: segment 0xFFFF zaczyna się pod efektywnym adresem 0xFFFF0. Powinien zatem zawierać 16 bajtów zamiast 64 KB. Zatem adres 0xFFFF:0x0010 byłby w pierszym megabajcie, natomiast 0xFFFF:0xFFFF byłby w pierszym megabajcie plus około 64 KB.

Procesor 8086/8088 nie mógł zaadresować więcej niż 1 MB pamięci, ponieważ posiadał jedynie 20 linii adresowych, więc adresy powyżej 0xFFFF:0x000F były zrzucone do niższych 64 KB. Procesor 286 zachowywał się jednak inaczej. Posiadał on 24 linie adresowe. Był zatem możliwy dostęp do owych około 64 KB pamięci więcej korzystając z tej sztuczki, co później za przykładem MS-DOS obelżywie nazwano "high memory".

Niestety znalazły się niektóre aplikacje dla 8086/8088, które się zawieszały, gdyż wymagały z pewnych powodów "spadku" do niższego obszaru pamięci. Intel tego nie zauważył, jednak IBM, gdy projektował IBM AT, oraz gdy było za późno na zmianę zachowania 286, poprawili się poprzez wprowadzenie bramki A20 ("A20#"). Nieużywany pin we/wy w kontrolerze klawiatury został przypisany do 20-ej linii adresowej, tak by oprogramowanie mogło "sciągnąć" 20-tą linię adresową do zera, emulując w ten sposób zachowanie 8086/8088.

W późniejszym czasie ta opcja została przeniesiona do jednostek CPU. Wszystkie Pentiumy i Athlony ją posiadają - Xbox także. Jeżeli A20# posiada ma stan niski, 20-ty bit wszystkich adresów bedzie miał wartość 0. Przykładowo, adres 1 MB będzie odpowiadał adresowi 0 MB, i jeżeli CPU zażąda dostępu do "wierzchołka" pamięci RAM, w rzeczywistości uzyska dostęp do pamięci, która jest 1 MB niżej od "wierzchołka".

Mając to na uwadze, atak Xboksa jest dość prosty: jeżeli podłączymy pin A20# jednostki CPU do masy, Xbox nie wystartuje z adresu FFFFFFF0, tylko z FFEFFFF0 - co nie jest objęte przez ukryty ROM, tylko zwykłą pamięć flash, ponieważ flash posiada lustrzane odbicie powyżej górnych 16 megabajtów. Więc dzięki podłączeniu pojedynczego pinu, ukryty ROM jest w całości pominięty.

Co w tym jest najpiękniejsze, to fakt, że ukryty ROM jest nadal włączony. Więc mogliśmy z łatwością zrzucić zawartość ROM poprzez jedną z wolnych magistral (użyliśmy I2C), poprzez umieszczenie niewielkiej aplikacji w pamięci flash.

Suma kontrolna TEA

Po przeczytaniu książki Bruce Schneier'a dotyczącej kryptografii, dowiedzieliśmy się, że TEA był rzeczywiście złym wyborem na sumę kontrolną. Autor książki pisze, że TEA nie można używać jako suma kontrolna, gdyż nie jest bezpieczny, jeśli użyć go w ten sposób. Jeżeli zamienisz miejscami bity 16-ty oraz 31-szy słowa 32-bitowego, suma kontrolna będzia identyczna. Mogliśmy z łatwością dodać skok w drugim bloku ładującym, tak, że zmiana nie została zauważona. Ten zmodyfikowany skok doprowadził nas prosto do pamięci flash.

Dlaczego zatem popełnili ten błąd? Bez wątpienia inżynierowie nie wiedzieli nic o kryptografii - znowu! - i po prostu dodali kod nie rozumiejąc go oraz bez pofatygowania się o przeczytanie najbardziej podstawowego podręcznika na ten temat. Prawdopodobnym wytłumaczeniem, dlaczego zdecydowali się na TEA, mogło być, że przeszukali Internet wg słowa kluczowego "tiny" (od słów "tiny" encryption algorithm) - i znaleźli TEA.

Tylna furtka visora oraz obejście MIST'a

Tylna furtka visora nadal istniała, zatem znowu, aby zastąpić Linuksem oryginalny firmware, deweloperzy Projektu Xbox Linux nie musieli zawieszać kodu szyfrującego. Mogli po prostu użyć tej furtki. Microsoft oczywiśie opracował zaktualizowany kod ROM zbyt szybko, tuż po tym, jak bunnie zrzucił oraz ludzie przekonali się, że RC4 nie był prawidłową sumą kontrolną, jednak przed odkryciem tylnej furtki przez visora.

Obejście MISTa zostało odkryte po odkryciu visora - jednak nie działało ono na Xboksie w wersji 1.1. Nie dlatego, że poprawili kod porównujący - w zasadzie to nie poprawili -, jednak dlatego, że zmienili logikę adresowania: Jeżeli miałeś dostęp do górnych 512 bajtów przestrzeni adresowej i ukryty ROM był wyłączony, Xbox po prostu zawieszał się, uniemożliwiając aliasowy "spadek" do niższej pamięci. W ten sposób uniemożliwili obydwa ataki: zapis do aliasu oraz użycie 5 instrukcji OUTB.

Microsoft bez wątpienia odkrył słaby punkt wyłączania pamięci, zamykając w ten sposób przynajmniej jedną tylną furtkę. Jednak drugą pozostawił nadal otwartą, a w zasadzie nie zupełnie zamknął tę drugą. Było zbyt kosztowne wyrzucić mostki południowe w wersji 1.1 ponownie do kosza dla kolejnego uaktualnienia, zatem Microsoft ciągle używa tych chipów w dzisiejszych Xboksach.

Dzisiaj

W późniejszych wersjach Xboksa, Microsoft usunął część pinów magistrali LPC, przez co zaprojektowanie modchipa było trudniejsze. Jednak nie usunęli magistrali LPC w całości, gdyż potrzebowali jej w procesie produkcji.

W ostatniej wersji sprzętu Xboksa (v1.6), ostatecznie zamienili pamięć flash na prawdziwy ROM - i nawet zintegrowali ROM z koderem obrazu. Magistrala LPC nie była już więcej potrzebna w produkcji, gdyż kości ROM były już zaprogramowane. Więc dziś obrazu jądra nie da się wymienić lub skasować przez ponowny zapis z powodu brakującej magistrali LPC. Wydaje się także niemożliwe podłączenie nadrzędnej pamięci ROM.

Jednak modchipy są nadal możliwe. Oczywiście, że piny LPC zostały usunięte, jednak magistrala nadal istnieje. Jeżeli znajdziesz kontakty LPC na płycie, możesz podłączyć nadrzędny ROM zupełnie tak jak dawniej. Modchipy są jedynie nieco trudniejsze do zainstalowania. To dlatego, że układ Southbridge nadal posiada funkcjonalność nadrzędności LPC, gdyż nie było do tej pory jego nowych wersji - jak zwykle z powodów finansowych.

Zabezpieczenie jądra Xbox

Rzućmy ponownie okiem na łańcuch zaufania:

• CPU rozpoczyna wykonanie kodu zapisanego w ukrytej pamięci ROM.
• ukryty ROM odszyfrowuje i sprawdza drugi blok ładujący.
• drugi blok ładujący odszyfrowuje i sprawdza jądro Windows.
• jądro Windows sprawdza prawidłowość bitów nośnika oraz cyfrowy podpis RSA gry.

Ostatni krok wykonywany jest w całości programowo, zatem wszystkie ataki były w zasadzie standardowe. Część ludzi próbowała złamać klucz RSA do podpisu gry - to nie żart! Jednak co jest bardziej prawdopodobne: udany atak na 2048-bitowy klucz RSA, czy znalezienie błędu w kodzie zabezpieczenia Microsoftu? Po doświadczeniach z pierwszymi ogniwami łańcucha zaufania, Projekt Xbox Linux skupił się na znalezieniu błędów w oprogramowaniu.

Nie znaleźliśmy żadnego błędu w implementacji RSA. Została "zapożyczona" prosto z Windows 2000 i wygląda zupełnie wporządku. Jednak rozumie się samo przez się, że zawsze istnieją inne ogniwa w łańcuchu zaufania: każdy program odczytuje dane, a dane mogą spowodować ryzyko dla bezpieczeństwa, jeśli niewłaściwie się z nimi obchodzimy.

Exploity gier

Jakie dane odczytuje gra? Grafikę, dźwięk, film... - jednak nie możemy ich podmienić, ponieważ nie jest łatwo stworzyć autentyczną płytę DVD dla Xboksa, a Xbox nie uruchomi kopii oryginałów z nośnika DVD-R itp.

Jednak większość gier może załadować zapisany stan gry, a te mogą być z łatwością modyfikowane: kości pamięci Xboksa to mniej lub bardziej standardowe urządzenia pamięci masowej USB ("klucze USB", pendrive), zatem istnieje możliwość użycia większości flashdisków USB z Xboksem, oraz po prostu umieścić na nich zmodyfikowany stan gry.

Wiele gier dla Xboksa jest wrażliwych na przepełnienie buforu w sterownikach plików ze stanem gry. Często było to tak proste, jak zwiększenie długości ciągu znaków takich jak imię gracza. Wówczas gra zapisywałaby ponownie swój stos razem z naszymi danymi oraz ewentualnie wykonywała skok do kodu, który dołączyliśmy do pliku ze stanem gry.

Zadaniem użytkownika było po prostu skopiować spreparowany plik stanu gry z pamięci USB na dysk twardy, uruchomić grę i załadować stan gry. Jednak po przepełnieniu buforu bylibyśmy w trybie użytkownika - a nie na Xboksie, jako że wszytkie gry na Xboksie uruchamiane są w trybie jądra. Przyczyną tego jest prawdopodobnie niewielki wzrost wydajności, albo, co jest mniej prawdopodobne, prostsze środowisko gry. Jednak Microsoft próbował uczynić środowisko tak podobne do środowiska Windows/DirectX, jak to tylko było możliwe. Zatem tryb użytkownika mógł w rzeczywistości uczynić środowisko "prostszym" dla wielu deweloperów Windows/DirectX.

Teraz, skoro posiadamy pełną kontrolę nad sprzętem, możemy ponownie zapisać kość pamięci flash. Domyślnie jest ona zabezpieczona przed zapisem. Jednakże wyłączenie zabezpieczenia jest tak proste jak zlutowanie prostego mostku na płycie głównej. Tak czy inaczej, ten mostek musi być zamknięty podczas pierwszego programowania pamięci flash w procesie produkcji. Istnieje możliwość permanentnej modyfikacji Xboksa przy użyciu jedynie pamięci USB, jednej z kilku gier (np. 007 Agent Under Fire, MechAssault, Splinter Cell, ...) oraz cyny lutowniczej, jeżeli tylko zainstalowany był modchip. Choć wczesne Xboksy posiadały 1-megabajtową kość flash, to tylko 256 KB było wykorzystane. Była zatem możliwa instalacja kilku obrazów ROM w pamięci flash do których był dostęp za pomocą przełącznika.

Jednak Projekt Xbox Linux nie udostępnił bezmyślnie informacji o tym obejściu. Pierwszy exploit w postaci pliku ze stanem gry został ukończony w styczniu 2003 roku. Później wiele energii zostało zainwestowane w poszukiwania sposoby uwolnienia Xboksa dla domorosłych deweloperów oraz dla Linuksa, nie zezwalając na kopiowanie gier. Kontaktowaliśmy się z Microsoft, jednak bez rezultatu. Firma zignorowała ten problem.

W końcu w lipcu informacja o obejściu została opublikowana w niepełnej formie wraz z blokadą nielinuksowego użycia. Było oczywiste, że spowolni to jedynie szukanie "obejścia w obejściu", więc ewentualnie, ludzie mogliby mieć możliwość użycia tej słabości dla kopiowania gier. Jednak od kiedy Microsoft nie wykazał żadnego zainteresowania w poszukiwaniu rozwiązania tego problemu, nie było innej opcji, jak tylko pełne ujawnienie. Propozycją Projektu Xbox Linux była wspólna praca z Microsoft, by bez rozgłosu "załatać" dziury w systemie zabezpieczenia, oraz, w zamian za to, opracowanie metody uruchomienia na Xboksie Linuksa i własnego oprogramowania.

Exploity panelu kontrolnego

Problemem obejścia za pomocą stanu gry było, że, jeżeli nie chciałeś zapisywać pamięci flash, musiałeś włączać grę oraz ładować stan gry za każdym razem, gdy chciałeś uruchomić niepodpisany kod. Z drugiej strony, mając dzięki temu pełną kontrolę nad sprzętem, mieliśmy również dostęp do twardego dysku bez otwierania obudowy Xboksa. W ten sposób, pojawiło się zainteresowanie, by bliżej przyjrzeć się zawartości twardego dysku w celu odnalezienia słabych punktów.

Panel kontrolny jest głównym programem na twardym dysku. Jest wykonywany za każdym razem, gdy Xbox jest włączany bez gry w napędzie DVD. Panel kontrolny może być nawet głównym powodem, dla którego Xbox sprzedawany jest wraz z twardym dyskiem. Podczas gdy menu ustawień oraz zarządzanie stanami gier na konsoli Nintendo GameCube mieści się w 2 megabajtach pamięci ROM, Panel kontrolny Xboksa, który jest w przybliżeniu porównywalny w działaniu, zajmuje ponad 100 MB. Zatem pierwszy pomysł podłączenia twardego dysku mógł być zainicjowany niemożnością kompresji Panelu kontrolnego do typowych rozmiarów pamięci ROM. Mogli również podjąć decyzję, by wykorzystać maksymalnie dysk twardy, i znaleźć dla niego dodatkowe zastosowanie.

Panel kontrolny ładuje swoje pliki z danymi, takimi jak muzyka i grafika, z twardego dysku. Z pomocą exploitu stanu gry, możemy teraz podmienić jego zawartość bez konieczności otwierania Xboksa. Oczywiście plik wykonywalny Panelu kontrolnego jest cyfrowo podpisany i - z tego powodu - nie może być podmieniony. Także wszystkie pliki z danymi mają swoje cyfrowe "odciski" (sumy kontrolne) zapisane w pliku wykonywalnym panelu. Tzn. wszystkie pliki za wyjątkiem dwóch: plików z czcionkami.

Konsekwentnie istniał słaby punkt dotyczący liczb całkowitych typu integer w algorytmach zajmujących się czcionkami, tak że moglismy uruchomić własny kod poprzez zastąpienie plików z czcionkami. W połączeniu z eksploitem stanów gry było to łatwe niczym skopiowanie pliku ze stanem gry oraz uruchomienie jej, która uruchamiała skrypt modyfikujący czcionki.

Teraz wraz z każdym uruchomieniem Xboksa Panel kontrolny wiesza się z powodu błędnych plików czcionek oraz uruchamia nasz kod załączony w tych plikach. Nasz kod ponownie ładuje Panel z oryginalnymi czcionkami, omija go, oraz uruchamia. Obejście Panelu kontrolnego oznacza dwie rzeczy: modyfikując jedną pozycję menu by czytała "XBOX LINUX" zamiast "XBOX LIVE" oraz uruchomienie bloku ładującego Linuksa zamiast aplikacji ustawień Xbox Live, oraz modyfikacja jądra by akceptowała aplikacje podpisane kluczem RSA Microsoftu, jak również te podpisane naszym kluczem RSA zarówno z dysku twardego jak i napędu CD/DVD. Nazwaliśmy to "MechInstaller", gdyż bazowało na exploicie stanu gry "MechAssault".

Tylko akceptacja kodu podpisanego oryginalnym albo naszym kluczem, utrzymanie naszego klucza w sekrecie, oraz ponownie daleko posuniętego zaciemniania istoty rzeczy, oznaczało, że nikt nie mógł z łatwością nadużyć tego rozwiązania dla skopiowanych gier.

To obejście pokazuje kilka faktów: Hakerzy mają fantazję, kombinacja słabych punktów może prowadzić do całkowitej kompromitacji systemu zabezpieczeń, potężny uprzywilejowany kod nie powinien zawierać żadnych dziur, a kod zabezpieczający powinien naprawdę uwzględniać wszystkie przypadki.

Aha, jest jeszcze jeden słaby punkt, zmienne całkowite w kodzie odtwarzacza audio. Atak został opracowany niezależnie od ataku bazującego na czcionkach, był jednak słabszy, ponieważ wymagał od użytkownika uruchomić odtwarzacz audio za każdym razem, by uruchomić Linuksa.

Poprawki Microsoftu

Historia reakcji Microsoftu na słaby punkt czcionek jest wspaniałą lekcją, jak tego nie robić.

1. po wydaniu MechInstaller, Microsoft poprawił słaby punkt buforu w panelu kontrolnym i rozprowadził tę nową wersję poprzez sieć Xbox Live oraz dostarczał ją z nowymi Xboksami.
2. dla hakerów nie było większego problemu. Mogli wgrać poprzednią wersję Panelu kontrolnego w nowym Xboksie uruchamiając po prostu Linuksa (korzystając z eksploita pliku ze stanem gry), i wykonując polecenie "dd" dla starego obrazu. Część użytkowników czuło, że wgranie poprzedniej wersji panelu na nowych Xboksach nie było piractwem, ponieważ, koniec końców, Microsoft zauktualizował dyski twarde użytkowników Xbox Live do nowej wersji bez pytania o zgodę.
3. jako następny krok, Microsoft dopisał stary panel do "czarnej listy" w nowym jądrze. Było nie możliwe zwyczajne "dd" obrazu starego panelu w nowych Xboksach.
4. nadal żadnego większego problemu dla hakerów: drugi plik wykonywalny na twardym dysku, "xonlinedash", który jest używany do konfiguracji Xbox Live, posiadał ten sam błąd. Było zatem możliwe skopiowanie starego "xonlinedash", zmiana nazwy pliku do "xboxdash" aby go zawiesić z powodu wadliwych czcionek.
5. Microsoft konsekwentnie dopisał do "czarnej listy" wrażliwe wersje "xonlinedash".
6. i znowu.. żadnego większego problemu dla hakerów: wszystkie gry Xbox Live rozprowadzane są z aplikacją "dashupdate", która dodaje funkcjonalność Xbox Live do panelu kontrolnego pierwszych Xboksów, które jej nie posiadały. Ta aplikacja aktualizująca posiada tę samą wadę czcionek, przez co może być uruchomiona z twardego dysku. Zatem można skopiować plik z każdej płyty DVD zawierającej grę Xbox Live, zmienić nazwę do "xboxdash" i pozwolić jej się "wysypać".
7. tego już Microsoft nie mógł dopisać do "czarnej listy". Xbox Live pozwala grom uruchomić aplikację aktualizującą przy każdym uruchomieniu, aby mieć pewność, że Xbox ma możliwość Xbox Live. Wyłączenie oryginalnego "dashupdate" uniemożliwiłoby działanie tych gier.

Wygraliśmy.

Popełnione błędy

Microsoft bez wątpienia popełnił wiele błędów. Jednak byłoby zbyt proste, by po prostu przypisać je wszystkie głupocie inżynierów. Znalazły się dobre (oraz inne) powody większości tych pomyłek, oraz jedna mogła nauczyć się wiele od innych.

Jest 17 typów popełnionych błedów. Kilka z nich zostało popełnione więcej niż raz. Pogrupowałem te 17 typów błędów w trzy kategorie: błedy projektu, implementacji oraz złych decyzji politycznych.

Projekt

#1: Bezpieczeńtwo kontra pieniądze

Bądź ostrożny przy kompromisach pomiędzy bezpieczeństwem a kosztami. Takie kompromisy żadko bywają rozsądne. Miej to na uwadze, że głównym przyczyną systemu zabezpieczenia jest zarabianie pieniędzy, albo unikanie strat. System zabezpieczenia nie może być "trochę lepszy" albo "trochę gorszy". Albo jest efektywny, albo nie. Oszczędzając na systemie zabezpieczenia, możesz z łatwością uczynić go nieefektywnym w całości. Nie tylko z powodu straty pieniędzy wydanych na system zabezpieczenia, ale także z powodu strat spowodowanych tym, że nie spełnia on swojego zadania.

Microsoft zdecydował się na wiele kompromisów.

• programowanie pamięci flash na płycie głównej jest tańsze od zaprogramowania jej przed instalacją na płycie, lecz haker może również nadpisać firmware za pomocą kości LPC ROM.
• kupowanie od Samsunga wszystkich kości RAM (nawet tych wadliwych) jest tańsze niż kupowanie jedynie tych, których parametry mieszczą się w specyfikacji, jednak uczyniło to inicjację RAM bardziej skomplikowaną, wykorzystując pamięć, która mogłaby być w przeciwnym wypadku wykorzystana przez doskonalszy kod zabezpieczający.
• umieszczenie ukrytej pamięci ROM wewnątrz mostku południowego zamiast w jednostce CPU, ponieważ mostek południowy był tak czy inaczej komponentem na specjalne zamówienie, natomiast zdobycie specjalnej jednostki CPU byłoby znacznie droższe, jednak klucze są transmitowane przez widoczną magistralę, jeżeli ukryta pamięć ROM znajduje się na zewnątrz jednostki CPU.
• zaoszczędzili rezygnując z aktualizacji mostku południowego Southbridge za drugim razem, co poprawiłoby algorytm sumy kontrolnej TEA oraz zlikwidowało tylną furtkę visora. To uniemożliwiłoby modchipy wirtualnie.

#2: Bezpieczeństwo vs. Szybkość

Nie rezygnuj z bezpieczeństwa dla szybkości. Chociaż może być prawdą, że product w działaniu musi być tak szybki, jak tylko jest to możliwe, aby był w stanie konkurować z podobnymi produktami na rynku. Zapamiętaj jednak, że komputery nie są wolniejsze bądź szybsze w procentach ale w wielokrotnościach! Poza tym możesz stracić więcej pieniędzy z powodu systemu zabezpieczenia, który nie działa, niż z powodu produktu, który jest o 10 procent wolniejszy niż mógłby być w innym wypadku.

Najprawdopodobniej dla zyskania na szybkości (jedna przestrzeń adresowa, brak strat TLB), Microsoft zdecydował się uruchomić cały kod w trybie jądra, nawet gry mające styczność z niezaufanymi danymi pochodzącymi z zewnątrz. To stworzyło możliwość przejęcia całkowitej kontroli nad konsolą w momencie, gdy gra zawiesiła się z powodu specjalnie spreparowanego savegame'a, włączając całkowitą kontrolę twardego dysku oraz możliwość uruchomienia alternatywnego systemu operacyjnego.

#3: Kombinacja słabych punktów

Bądź świadomy faktu, że kombinacja wad systemu zabezpieczenia może prowadzić do udanego ataku. Nie myśl, że potencjalna dziura w bezpieczeństwie (lub "jedynie" ryzyko bezpieczeństwa) nie może zostać wykorzystana, ponieważ tak wiele barier stoi na przeszkodzie. Hakerzy mogą złamać wszystkie owe bariery chroniące słaby punkt. Natomiast usunięcie ostatniego wadliwego ogniwa może ich powstrzymać.

MechInstaller jest wspaniałym tego przykładem. Było to możliwe jedynie z powodu kombinacji kilku słabych punktów bezpieczeństwa:

• proces uruchamiania konsoli jest wrażliwy na atak, mogliśmy zatem wykorzystać zmodyfikowane jądro w celu analizy gry.
• część gier nie jest wystarczająco ostrożna z plikami zapisu stanu gry, mogliśmy zatem uruchomić nasz własny kod.
• gry działają w trybie jądra, mamy zatem pełną kontrolę nad sprzętem.
• panel sterowania nie sprawdza integralności plików z czcionkami.
• panel sterowania posiada słaby punkt w kodzie czcionek.

Jeżeli zabrakłoby któregokolwiek z powyższych słabych punktów, wówczas MechInstaller nie byłby możliwy. Miej również na uwadze, że hakerzy mają wystarczająco dużo fantazji, by odnaleźć te kombinacje.

#4: Możliwości i zasoby hakerów

Zrozum, że hakerzy mają wspaniałe i olbrzymie zasoby. Hobbyści mogą używać zasobów z pracy lub z uczelni, profesjonalni hakerzy mogą być również bardzo dobrze wyposażeni. To duży błąd, nie doceniać ich. Zatem nie myśl nigdy, że jesteś bezpieczny, ponieważ kosztowałoby za wiele pracy lub pieniędzy, by znaleźć słaby punkt. Jeżeli istnieje słaby punkt, najprawdopodobniej zostanie on odkryty. Zrozum także, że hakerzy mogą posiadać wspaniałe zasoby ludzkie. Nie tylko jeśli chodzi o liczbę, ale także kwalifikacje.

Microsoft umieścił ukryty ROM w mostku południowym zamiast w jednostce CPU, co oznacza, że tajny klucz transmitowany jest widoczną magistralą. To bardzo szybka magistrala HyperTransport, która, w tamtych czasach, nie mogła być podłuchana przy użyciu żadnych logicznych analizatorów, na które mógł sobie pozwolić szary śmiertelnik. Jednak z pomocą zasobów MIT, wykorzystując całe swoje doświadczenie, bunnie mógł zbudować swój własny sprzęt, którym mógł podsłuchiwać magistralę.

#5: Przeszkody i zapory

Nie czyń niczego "trudniejszym dla hakerów". Uczyń to "niemożliwym dla hakerów", lub, jeśli sie nie da, nie dbaj o to. Z powodu ogromnej liczby i wspaniałych kwalifikacji hakerów, żadna zapora nie przyniesie efektu, bądź zwolni znacząco proces łamania. Zamiast tego w projekcie systemu zabezpieczenia możesz popełnić błąd #3, ponieważ myślisz, że jesteś bezpieczny, gdyż jest tak wiele przeszkód na drodze hakerów. Środki, które zainwestowałbyś w budowę zapór, przeznacz zamiast tego na budowę lub wzmocnienie prawdziwych przeszkód - prawdopodobnie w zupełnie innym miejscu.

Microsoft budował zapory w wielu różnych miejscach w systemie.

• stan gry mógł być zaakceptowany, jeżeli był podpisany, jednak klucz prywatny jest oczywiście przechowywany we wnętrzu gry, co nie jest żadną przeszkodą. Zamiast tego powinni upewnić się, że gra nie nie jest podatna na słabości buforu w swoim kontrolerze pliku ze stanem gry.
• Twardy dysk jest zabezpieczony hasłem ATA, innym dla każdego Xboksa oraz przechowywanym w pamięci EEPROM we wnętrzu Xboksa. Jednak atakujący może po prostu "na gorąco" odłączyć odbezpieczony dysk twardy od włączonego Xboksa i przepiąć go do włączonego PC. Zamiast tego powinni skierować tą energię w sprawdzenie, czy Panel kontrolny rzeczywiście wykonuje sumę kontrolną wszystkich danych, jakie odczytuje z twardego dysku.
• 512 bajtów kodu ładującego zostało umieszczone w zwyczajnym chipie, aby utrudnic podsłuchanie. Zamiast tego powinni się upewnić, że nie ma żadnych dziur w kodzie zabezpieczenia.

#6: Grupy hakerów

Nie używaj jednego systemu zabezpieczenia do różnych zastosowań. Tylko wówczas będzie bardziej efektywny. W przeciwnym wypadku hakerzy o różnych celach zaatakują go wspólnie. Zamiast tego spróbuj się dowiedzieć, kim tak naprawdę są twoi wrogowie i czego od ciebie chcą. Następnie zaprojektuj swój system zabezpieczenia tak, aby każda grupa otrzymała możliwie najwięcej z tego, czego oczekują. Nie będą wówczas ciebie atakować.

Istniały trzy założenia dla hakerów łamiących Xboksa: uruchomić Linuksa oraz używać Xboksa jako zwykły komputer, uruchomić własne oprogramowanie takie jak odtwarzacze mediów i emulatory, oraz uruchomić kopie gier. Chociaż społeczność Linuksa oraz własnego oprogramowania, jak również społeczności własnego oprogramowania oraz ludzi zainteresowanych uruchamianiem kopii gier, w niewielkim stopniu pokrywały się, były to w zasadzie trzy różne grupy. Ponieważ wszyscy zostali zablokowani przez to samo zabezpieczenie, pracowali wspólnie zarówno dosłownie, jak i efektywnie, korzystając nawzajem z efektów swojej pracy. Hakerzy od Linuksa nigdy nie zaatakowali Playstation. Kiedy grasz fair, ludzie cię nie zaatakują.

#7: Zabezpieczenie poprzez ściemnianie

Zabezpieczenie poprzez ściemnianie nie działa. Gruntownie sprawdzone algorytmy SHA-1 ora RSA działają (oczywiście pod warunkiem grutownie sprawdzonej implementacji).

Microsoft zaszyfrował ukryty ROM, jądro Windows, zawartość gier na płytach DVD (brak możliwości odczytania ich w standardowych napędach DVD) oraz zawartość twardego dysku używając różnych metod. W każdym z powyższych przypadków bez skutku. Zobacz także #5.

#8: Poprawki

Kiedy twój system zabezpieczenia został złamany, nie publikuj szybkich poprawek z dwóch powodów: twoje poprawki mogą być wadliwe i w zasadzie mogą nie rozwiązywać problemu, a jeszcze gorsze dziury mogą zostać odkryte niewiele później, które będziesz musiał znowu załatać - i rozprowadzić jeszcze jedną wersję. Zamiast tego za każdym razem, gdy zostanie odkryta dziura w zabezpieczeniu, przeprowadź audyt kompletnego systemu zabezpieczenia oraz poszukaj podobnych dziur, oraz również innych dziur w tej samej części systemu, bazując na wiedzy, którą zdobyłeś po udanym ataku.

Microsoft zaniechał poprawy problemu "sumy kontrolnej" w drugiej wersji ukrytego ROM'u, oraz nie załatał dziur visora, które odkryto jedynie kilka tygodni później. Po wyrzuceniu tysięcy świeżo wyprodukowanych mostków południowych Southbridge w wersji 1.0 - co było bardzo kosztowne - zdecydowali się nie aktualizować mostku po raz drugi. Innym przykładem jest odyseja Panelu kontrolnego: Zamiast dopisać do "czarnej listy" wrażliwe wykonywalne pliki, wydali w tym czasie trzy aktualizacje, z których żadna nie rozwiązywała problemu.

Implementacja

#9: Specyfikacje

Dowiedz się wszystkiego o komponentach, których używasz. Przeczytaj uważnie specyfikacje. Bądź bardzo ostrożny przy pracy z komponentami, które posiadają funkcjonalności "w spadku".

Microsoft nie dostrzegł w "spadkowej" funkcji A20# ryzyka dla systemu zabezpieczenia. Wygląda na to, że nie przeanalizowali wszystkich funkcji procesora Pentium III Celeron, gdyż w przeciwnym wypadku powinni to zauważyć. Najwyraźniej nie przeczytali również podręcznika programowania procesora Pentium, gdyż w przeciwnym wypadku zauważyliby, że procesory Intela nie zatrzymują się przy przejściu FFFFFFFF/00000000.

#10: Literatura

Przeczytaj (przynajmniej) podstawową literaturę. Jeżeli zajmujesz się kryptografią, to znaczy, że musisz przeczytać przynajmniej "Kryptografię stosowaną" Schneier'a.

Inżynierowie Microsoftu nie wiedzieli, że TEA nie może być używana jako suma kontrolna, oraz tego, że RC4 nie zasila odszyfrowanego strumienia spowrotem w strumień klucza.

#11: Profesjonaliści

Zdobądź doświadczonych profesjonalistów do pracy nad twoim systemem zabezpieczenia, zarówno nad projektem, jak i nad implementacją. Jeżeli jest to kwestia pieniędzy, zobacz #1.

Spoglądając na pomyłki #9 oraz #10, zdaje się wielce prawdopodobne, że przynajmniej kilku inżynierów z Microsoft nie posiada podstawowego doświadczenia w kryptografii lub w projektowaniu systemów zabezpieczenia. Wiemy także, że pracownicy będący na stażu opracowywali system zabezpieczenia Xboksa.

#12: Kompletność

Upewnij się, że twój kod zabezpieczający obejmuje wszystkie przypadki. Jeżeli nie, to nie dość, że stracisz czas implementując go, to dodatkowo możesz udzielić hakerom wskazówek: Jeżeli w jednym punkcie kodu znajduje się wiele sprawdzeń, wygląda to na kod, który jest związany z systemem zabezpieczenia oraz atakujący może sprawdzić, czy obejmuje wszystkie przypadki.

Microsoft popełnił ten błąd dwa razy: Interpreter xkodu sprawdza kod wyłączający konsolę w ukrytej pamięci ROM nieuwzględniając wszystkich przypadków. Także Panel kontrolny wykonuje sumę kontrolną wszystkich plików, które zamierza odczytać za wyjątkiem dwóch przypadków. To wskazało nam pomysł, gdzie zaatakować.

#13: Pozostałości

Spójrz na ostateczny produkt z punktu widzenia hakera. Wykonaj hexdump oraz deasembluj twoją ostateczną kompilację. Mogą tam pozostawać jakieś resztki!

Obraz pamięci flash Xboksa zawierał starą wersję ukrytej pamięci ROM, co dało nam nie tylko wskazówki odnośnie zawartości aktualnej pamięci ROM, ale również wgląd w to, co Microsoft zaplanował, oraz dlaczego popełniono kilka pomyłek.

#14: Ostateczny test

Sprawdź swój system zabezpieczenia, gdy ostateczne elementy sprzętu wraz z ostatecznymi komponentami oprogramowania znajdują się na swoim miejscu. Zmiana czegokolwiek może z powodzeniem stworzyć dziury zupełnie w innym miejscu. Kiedy cokolwiek zmieniasz, przemyśl system w całości, oraz sprawdź wszystkie założenia, które przyjąłeś.

Obejście visora stało się możliwe, gdyż Microsoft nie dostosował swojego systemu zabezpieczenia, który był zaprojektowany dla procesorów AMD, do procesorów Intela. "Suma kontrolna" w ukrytej pamięci ROM nie dawała żadnego efektu, gdyż zmienili algorytm RC5 na RC4 bez zastanowienia się nad konsekwencjami.

Polityka

#15: Kod źródłowy

Przechowuj źródła w bezpiecznym miejscu. Znajdź inżynierów, którym możesz zaufać.

Cały kod źródłowy Xboksa wyciekł, włączając źródła bibliotek i jądra. Grupy zainteresowane kopiami mogły z łatwością zmodyfikować go, by obsługiwał uruchamianie gier z dysku twardego, również by obsługiwał dyski twarde większe niż 137 GB, własne logo ładujące itp. Poprzednio uzyskiwano to poprzez łatki na wersję binarną.

#16: Wiele ludzi

Postaraj się o to, by wielu dobrych ludzi spojrzało na twój projekt oraz implementację. Utrzymanie kodu źródłowego w bezpieczeństwie oznacza posiadanie inżynierów, którym możesz zaufać, a nie usilne staranie, by żaden z twoich inżynierów nie ujrzał kodu źródłowego. Jak wykazano w punkcie #7, twój system nie może opierać się na utrzymaniu kodu źródłowego w tajemnicy. Dopóki nie zrobiłeś punktu #7 zupełnie niewłaściwie, dziura w systemie zabezpieczenia jest zazwyczaj znacznie gorsza niż wyciek kodu źródłowego.

Wszystko wskazuje na to, że aktualnie wielu ludzi widziało kod systemu zabezpieczenia Xboksa.

#17: Rozmawiaj

Poznaj swojego wroga - i rozmawiaj z nim. To nie terroryści, z którymi nie należy negocjować. Ich intencją nie jest skrzywdzić ciebie, ale osiągnąć własne cele. Niezależna realizacja ich własnych celów może skrzywdzić cię pośrednio, gdyż hakerzy mogą nie dbać o te same rzeczy, co ty. Szukaj kontaktu z hakerami, wiedz, co robią, i postaraj się, aby informowali ciebie o odkrytych słabych punktach systemu, zanim je opublikują. Spraw, by znali twoje stanowisko oraz dlaczego powinni je uszanować. Uszanuj także ich stanowisko. Zaoferuj im rozluźnienie systemu bezpieczeństwa dla ich dążeń w zamian za nieujawnianie swoich odkryć.

Microsoft odrzucił propozycję rozmowy na temat słabości save'ów oraz czcionek. Jeżeli bylibyśmy złymi hakerami, moglibyśmy opublikować obydwa w pełnej formie, umożliwiając natychmiast uruchamianie kopii na Xboksie bez konieczności użycia modchipa. Zamiast tego poszukaliśmy kontaktu z Microsoft: Woleliśmy zobaczyć tylną furtkę dla Linuksa w systemie zabezpieczeń Xboksa, zamiast rozwiązania bazującego na naszych odkryciach, które umożliwiłoby uruchamianie kopii. Ale skoro odrzucili naszą propozycję rozmowy, byliśmy zmuszeni opublikować exploity. Microsoft miał tyle szczęścia, że znacznie "zaciemniliśmy" nasze rozwiązania w celu spowolnienia ludzi zainteresowanych wykorzystaniem ich dla kopii gier.

Wniosek

System zabezpieczeń Xboksa zupełnie zawiódł.

Categories: Polish