Architektura Wii

Myślę, że liczba funkcji oferowanych przez tę konsolę czyniła ją bardzo atrakcyjną dla hakerów, ponieważ złamanie systemu bezpieczeństwa pozwoliłoby twórcom homebrew na zdobycie możliwości konsoli bez konieczności przechodzenia przez kontrole Nintendo. Tak czy inaczej, Wii skończyło z fantastyczną biblioteką Homebrew.

Ochrona przed kopiowaniem

Zacznijmy od pospolitej ofiary: Napędu dyskowego.

Dyski Wii zawierają wyżej wspomniany obszar 'burst cutting', który jest niedostępny dla konwencjonalnych czytników. Tak więc w przypadku braku tego sterownik zawsze odmówi przeczytania treści.

Napęd dysków nie pozwoli nikomu przejść przez ten ekran, dopóki nie zostanie włożony prawidłowy dysk.

Deweloperzy Modchipa odkryli, że napęd zawiera interfejs debugowania o nazwie 'Serial Writer' , chociaż ten port jest zablokowany do momentu wprowadzenia tajnego klucza. Jednak znalezienie klucza było kwestią czasu. Gdy to się stało, modderzy byli w stanie wyłączyć ochronę przed kopiowaniem, a następnie opracowali modchip, który zautomatyzował ten proces.

Matsushita opublikowało kolejne wersje tego napędu, blokujące interfejs debugowania, jednak odkryto inne wady czytnika, aby ponownie go włączyć.

Warto wspomnieć, że główną zaletą modchipów było zwykłe piractwo, ponieważ zawartość dysku jest nadal zaszyfrowana, więc do uruchomienia niestandardowego kodu potrzeba było więcej badań i narzędzi.

Z drugiej strony, GameCube homebrew był już możliwy do wykonania, wykorzystując poprzednie wykryte exploity na poprzedniku.

Szyfrowanie systemu

Jest to prawdopodobnie najbardziej złożona sekcja tej konsoli, ale jej nieustające badania otworzyły drzwi wielu utalentowanym programistom i niesamowitym programom.

Wewnętrzne zabezpieczania Wii były zaprojektowane wokół kilku szyfrów kryptograficznych (AES, RSA, ECC, SHA-1 i HMAC). Aby wyjaśnienia były łatwe do zrozumienia, przyjrzyjmy się każdej grupie z osobna:

Współdzielone szyfrowanie

Komunikacja między wieloma komponentami (NAND, dyskiem z grą i kartą SD) jest szyfrowana, aby uniknąć manipulacji. Nintendo wybrało system klucza symetrycznego, aby ją chronić , co oznacza, że Wii używa tego samego klucza do szyfrowania i odszyfrowywania swoich danych.

Starlet ma trzy klucze AES 128-bitowe przechowywane w swojej pamięci OTP , które są zapisywane raz podczas produkcji:

• Klucz Wspólny: Globalny klucz generowany przez Nintendo, który można znaleźć na wszystkich Wii. Służy do odszyfrowywania pierwszej warstwy szyfrowania używanej w kanałach i grach na dyskach (od teraz będę się do nich odnosić jako tytuły).
• Klucz SD: Ten służy do szyfrowania/odszyfrowywania danych przesyłanych na kartę SD i tylko menu systemowe może wykonywać te transfery.
  • Nintendo przechowywało kopię tego klucza w systemie IOS bez wyraźnego powodu.
• Klucz NAND: Ten klucz jest generowany losowo podczas procesu produkcyjnego (co oznacza, że jest unikalny dla każdego Wii) i służy do ochrony chipa NAND.

Dzięki temu widzimy, że Starlet odpowiada za szyfrowanie/odszyfrowywanie sensownych treści, dlatego ten procesor jest jedynym, który ma dostęp do poufnych danych.

Łańcuch zaufania

Tytuły zawierają kolejną warstwę zabezpieczeń, RSA-2048. Jest to szyfr asymetryczny, co oznacza, że potrzebujemy jednego klucza do zaszyfrowania zawartości i drugiego do jej odszyfrowania. W skrócie, pozwala to Nintendo na szyfrowanie tytułów za pomocą nieujawnionego klucza (zwanego 'kluczem prywatnym'), podczas gdy Wii odszyfrowuje je za pomocą 'klucza publicznego', który jest przechowywany w konsoli. Gdyby hakerzy zdobyli klucz publiczny, nie wystarczyłoby złamać systemu bezpieczeństwa, ponieważ nadal oczekuje się, że dane będą szyfrowane za pomocą klucza prywatnego, o którym wie tylko Nintendo.

Ponadto RSA jest wykorzystywany nie tylko do szyfrowania treści, ale również do sprawdzania integralności tego szyfrowania. Widzisz, Nintendo używa wielu kluczy, które są używane do podpisywania (szyfrowania) już zaszyfrowanych danych, tworząc łańcuch szyfrowania, którego jedynym celem jest upewnienie się, że:

• Każdy użyty klucz został autoryzowany przez Nintendo.
• Dane nie zostały zmienione i ponownie zaszyfrowane bez autoryzacji.

Podam przykład, jak to działa:

1. Nintendo tworzy klucz o nazwie x.
2. Nintendo programuje Starlet, aby ufała treściom podpisanym tylko kluczem x.
3. Jeśli Starlet stwierdzi, że będzie musiała odszyfrować tytuł kluczem y, zadziała tylko wtedy, gdy y zostanie podpisany kluczem x.

Nazywa się to Łańcuchem zaufania. Poza Wii technika ta jest powszechnie stosowana do ochrony większości naszej komunikacji na całym świecie (na przykład przeglądarki internetowe korzystające z protokołu HTTPS polegają na 'certyfikatach głównych' w celu weryfikacji autentyczności nieznanych certyfikatów).

Łańcuch Starlet'a

OTP Starlet przechowuje klucze publiczne (co oznacza, że dla naszych celów może tylko odszyfrować i zweryfikować podpis treści). Jego łańcuch zaufania składa się z następujących kluczy :

• Klucz Główny: Podpisuje klucz organu certyfikacji.
  • Starlet musi tylko przechowywać ten (publiczny) klucz, reszta może zostać odszyfrowana (i następnie zaufana), jeśli została podpisana tym kluczem.
• Klucz Organu Certyfikacji (CA): Podpisuje klucze XS i CP.
• Klucz XS: Ten klucz podpisuje 'tickety', rodzaj danych, który zawiera listę kluczy AES potrzebnych do odszyfrowania tytułów (zwanych 'kluczami tytułów').
• Klucz CP: Po odszyfrowaniu tytułu przy użyciu odpowiedniego klucza tytułu, klucz CP jest używany do podpisywania metadanych tytułu (tzw. 'TMD').
  • Chociaż nie podpisuje treści per se, metadane zawierają skrót SHA-1, którego Starlet używa do weryfikacji integralności tych danych.

Jak widać, wszystko to pozwala Nintendo być wyłącznym dystrybutorem treści, co może być dobre dla studiów gier zaniepokojonych piractwem.

Więcej kluczy

Ten system zawiera również parę kluczy prywatnych i publicznych ECC. Kryptografia Krzywych Eliptycznych (ECC) to kolejny algorytm podobny do RSA. W tym przypadku służy tylko do podpisywania treści przesyłanych za pośrednictwem karty SD. To właśnie uniemożliwia wykorzystanie zawartości skopiowanej z jednego Wii na innym.

Klucz ECC jest podpisany przez jeszcze inny klucz publiczny RSA o nazwie MS, co pozwoli Starlet zaufać kluczowi ECC.

Ostatnim kluczem używanym przez tę konsolę jest klucz HMAC, który korzysta z innego algorytmu łączącego hashe SHA-1 i HMAC. Podczas procesu uruchamiania Starlet sprawdza, czy NAND nie został zmieniony przez sprzęt innej firmy. Aby to zrobić, oblicza hash SHA-1 pamięci NAND i porównuje go z hashem zakodowanym, aby sprawdzić, czy pasują. Oprócz tego zapisany skrót jest podpisany przy użyciu klucza HMAC, aby upewnić się, że jest autentyczny.

Na koniec klucz HMAC jest przechowywany w SEEPROM (poza Starlet), a nie w OTP.

Obserwacje

Po tym wszystkim warto wspomnieć, że gdy system uruchamia gry GameCube, żadna z wymienionych metod szyfrowania nie jest używana. Zamiast tego Starlet sprawdzi tylko, czy gra uzyskuje dostęp tylko do wyznaczonych lokalizacji pamięci. Dzieje się tak, ponieważ 1/4 pamięci RAM GDDR3 jest przydzielona do symulacji starego ARAM.

Upadek szyfrowania

Zacznijmy od kluczy AES, algorytm może być trudny do złamania, ale jeśli klucze zostaną w jakiś sposób wyodrębnione (zwłaszcza wspólny klucz), ta warstwa bezpieczeństwa zostanie natychmiast anulowana. Dlatego głównym wyzwaniem jest jak je wyodrębnić.

Diagram bezpieczeństwa Starlet.

Więc, grupa hakerów o nazwie Team Twiizers odkryła, że brak podpisów w trybie GameCube może być obiecującą powierzchnią do ataku . Nie tylko odkryli, że 3/4 z tego RAM GDDR3 nie zostaje wyczyszczone po uruchomieniu programu GC, ale również odkryli, że poprzez pomostowanie niektórych punktów adresowych na płycie głównej (przy użyciu pary pęset), mogą zamienić wybrane banki RAM GDDR3, umożliwiając im dostęp do obszarów ograniczonych. I oto znaleziono tam klucze AES.

Nie zapominajmy, że pozwala to odszyfrować tylko 'pierwszą warstwę' bezpieczeństwa, ale aby uruchomić niepodpisane programy (Homebrew), RSA również musi zostać złamany. Niestety może to być obliczeniowo niemożliwe... Chyba że istnieją wady w jego realizacji. Cóż, Team Twizzers nie poprzestali na tym, więc zaczęli analizować sposób kodowania IOS, skupiając się na jego funkcjach weryfikacji podpisów.

Weryfikacja podpisu RSA, bez wchodzenia w szczegóły, polega na porównaniu skrótu obliczonej operacji RSA z odszyfrowanym podpisem. Po kilku manipulacjach grupa odkryła coś zabawnego: Nintendo zaimplementowało tę funkcję za pomocą strncmp (porównanie 'ciągu' w C).

Dla osób nieznających C, strncmp jest procedurą używaną do sprawdzania, czy dwa łańcuchy są równe. Ta kompozycja zawiera: dwa łańcuchy i jedną liczbę całkowitą, ta ostatnia określa liczbę znaków do porównania. Następnie, strncmp zaczyna porównywać każdy znak aż do osiągnięcia końca dowolnego ciągu (lub licznika znaków). Łańcuchy w C to po prostu ciąg znaków zakończony znakiem \0, co oznacza, że strncmp przestaje porównywać, gdy dowolny łańcuch osiągnie \0. Dlatego też, tworząc tytuł Wii w taki sposób, aby jego hash zawierał na początku \0, obliczenia RSA Starleta spowodują, że porównane zostaną bardzo krótkie hashe (lub nawet puste) ze znacznymi szansami na kolizję (różne dane, które dają tę samą wartość hash). Ostatecznie, przy użyciu możliwej ilości brute-forceowania, umożliwiło to porównanie i zwrócenie równość... Tytuł jest podpisany!

Jakby tego było mało, ta luka została wykryta w wielu wersjach IOS - a nawet w procedurach znalezionych na boot1 i boot2!

Świt Homebrew

Po tym pozostało tylko jedno: uczynić exploita trwałym i zaimplementować 'przyjazne dla użytkownika' narzędzie, aby mógł bezproblemowo uruchamiać niestandardowe programy.

Uruchamianie aplikacji innych firm początkowo odbywało się przy użyciu sfałszowanego zapisu gry.

Do tej pory exploity te wymagały użycia dodatkowego sprzętu, więc nie każdy użytkownik mógł z niego skorzystać... Dopóki Team Twizzers nie odkryli kolejnego exploita: Przepełnienia bufora gry.

Mam na myśli słynną The Legend of Zelda: Twilight Princess (nawiasem mówiąc, grę firmy Nintendo). TT odkryli, że plik zapisu gry może zostać zmodyfikowany, aby przepełnić liczbę znaków używanych do nazwania konia gracza. Tak więc, gdy gracz spróbuje odczytać przepełnioną nazwę, wywoła to reakcję łańcuchową kończącą się wykonaniem dowolnego kodu. Można to wykorzystać do uruchomienia, powiedzmy, programu ładującego.

Ponieważ podpisy można było teraz sfałszować, ten spreparowany plik zapisu można było łatwo rozpowszechniać w sieci, aby inne osoby mogły z niego korzystać. W rezultacie społeczność homebrew mogła teraz uruchamiać swoje niestandardowe oprogramowanie.

Stan stały

Podczas dalszej inżynierii wstecznej IOS odkryto, że sygnatury są sprawdzane tylko podczas instalacji tytułów, a nie podczas ich wykonywania.

Tak więc TT ponownie zabłysnęli. Ostrożnie stworzyli kanał do zainstalowania, który mógł załadować dowolne programy z karty SD. Gdyby kanał ten został zainstalowany przed podjęciem przez Nintendo działań mających na celu złagodzenie problemów związanych z bezpieczeństwem, wówczas Wii na stałe cieszyłaby się homebrew (niezależnie od łatania przez Nintendo ich błędów z podpisami w przyszłości, co uczynili).

Kanał Homebrew był tego wynikiem, ten tytuł pozwolił każdemu użytkownikowi na odpalenie programów homebrew, które mogły korzystać z pełnej kontroli nad tym systemem (z wszystkimi tego konsekwencjami).

Odpowiedź Nintendo

Z oczywistych powodów Nintendo wydała wiele aktualizacji systemowych, które naprawiły exploit z podpisami w wielu wersjach IOS, oraz zajęli się również wadliwymi etapami rozruchu, wypuszczając nowe wersje sprzętowe.

Przybędzie ich wiele.

W systemie tym wykryto jednak inne zasadnicze wady:

• Broadway może ponownie uruchomić Starlet z dowolną wersją IOS bez dodatkowych uprawnień, pozwalając na wykorzystanie wersji niezpatchowanych.
• Ukryte API IOS nadal mogą być używane bez specjalnych uprawnień, umożliwiając jeszcze większą nieupoważnioną kontrolę sprzętu.
• Napęd dysków może otrzymać polecenia odczytu konwencjonalnych DVD, a niektóre IOS zawierają ukryte wywołania tych poleceń. Było to szczególnie niepokojące z powodu piractwa.

Więc, podsumowując, po tym wszystkim jedyne co pozostało to zabawa w kotka i myszkę. W ciągu następnych miesięcy odkryto kolejne różne exploity, które następnie Nintendo próbowało patchować jeden po drugim. Ta 'zabawa' trwała aż do końca życia konsoli i nie wydano już żadnych aktualizacji. Możemy założyć, że tutaj wygrała mysz.

Na chwilę pisania tego artykułu, luki tu wspomniane zostały załatane, ale również zastąpione obecnie działającymi.

Myślę, że nie ma żadnych sporów o wpływ, jaki scena hakerska wywarła na ten system, i kto może zapomnieć o ogromnej ilości homebrew która była udostępniona (istniał nawet 'sklep' homebrew, który był szybszy i oferował więcej wolności niż oficjalny Kanał Sklepowy Wii).