Architektura Wii

Myslím, že díky nepřebernému množství funkcí, která tato konzole nabízela, se Wii stalo velice atraktivním pro hackery, neboť prolomení bezpečnostních mechanismů umožňovalo nelicencovaným vývojářům využít veškerý jeho potenciál i bez vědomí Nintenda. Ve výsledku se Wii může těšit z fantastické knihovny homebrew aplikací.

Ochrana proti kopírování

Začneme nejčastější obětí: diskovou mechanikou.

Wii disky na sobě mají výše zmíněnou „burst cutting" oblast, ke které se běžnými čtečkami disků nelze dostat. Pokud mechanika nenajde tento ochranný prvek, odmítne čtení zbylých dat na disku.

Disková mechanika vás nepustí dál, dokud do ní nevložíte platný disk.

Tvůrci modchipů zjistili, že mechanika obsahovala ladicí rozhraní s názvem „Serial Writer" , nicméně přístup k němu je zablokovaný, dokud není zadán tajný klíč. Přesto byla jen otázka času, kdy bude klíč objeven. Jakmile k tomu došlo, moddeři byli schopni vypnout ochranu proti kopírování a následně vyvinuli modchip, který tento proces zautomatizoval.

Matsushita vydala další revize této mechaniky, která ladící rozhraní skryla, přesto byly v mechanice objeveny další chyby, které rozhraní znovu povolily.

Stojí za zmínku, že hlavním přínosem modchipů bylo prosté pirátství, protože obsah disku je šifrován, takže ke spuštění vlastního kódu bylo stále zapotřebí více výzkumu a nástrojů.

GameCube homebrew bylo možné spustit pomocí dříve objevených exploitů, kterými trpěla konzole-předchůdce.

Šifrování systému

Toto je nejspíše nejkomplexnější aspekt této konzole, nicméně její nikdy neutichající výzkum otevřel dveře mnoha talentovaným vývojářům a úžasným programům.

Zabezpečení Wii bylo navrženo kolem několika kryptografických metod (AES, RSA, ECC, SHA-1 a HMAC). Abychom se ve vysvětlování neztratili, podíváme se na každý aspekt zvlášť:

Sdílené šifrování

Komunikace mezi mnoha komponenty (NAND, herním diskem a SD kartou) byla šifrována, aby nedošlo k nedovolenému zásahu. Nintendo k ochraně zvolilo symetrický klíč , což znamená, že Wii používá stejný klíč k zašifrování a dešifrování svých dat.

Starlet obsahuje tři 128bitové AES klíče uložené v OTP paměti , které jsou do něj permanentně uloženy během výroby:

• Common key: globální klíč vygenerovaný Nintendem se nachází na všech Wii. Používá se k dešifrování první vrstvy šifrování kanálů a her na discích (odteď je budeme označovat souhrnným názvem tituly).
• SD Key: tento je použit pro šifrování/dešifrování dat přenášených na SD kartu, a pouze System Menu může provádět tyto přenosy.
  • Z nějakého důvodu Nintendo vložilo kopii tohoto klíče dovnitř IOSu.
• NAND Key: tento klíč je náhodně generován během výrobního procesu (což znamená, že je unikátní pro každé Wii) a používá se k ochraně NAND čipu.

Díky tomu můžeme vidět, že Starlet má na starosti šifrování/dešifrování citlivého obsahu, proto je toto CPU jediným procesorem, který má přístup k důvěrným datům.

Řetěz důvěry

Tituly obsahují další bezpečnostní vrstvu, RSA-2048. Toto je asymetrický klíč, což znamená, že potřebujeme jeden klíč k šifrování obsahu a jiný k jeho dešifrování. Jednoduše to znamená, že Nintendo šifruje tituly pomocí neznámého klíče (private key) a Wii je dešifruje pomocí veřejného klíče (public key), jenž je uložen v konzoli. Pokud by hackeři získali veřejný klíč, nestačilo by to k prolomení bezpečnostního systému, protože se stále očekává, že data jsou šifrována pomocí neznámého klíče, který zná pouze Nintendo.

Kromě toho se RSA nepoužívá pouze pro šifrování obsahu, ale také pro kontrolu integrity tohoto šifrování. Ono Nintendo totiž používá několik klíčů k podpisu (zašifrování) již zašifrovaných dat, což dohromady tvoří řetěz šifer s jediným cílem zajistit, že:

• každý použitý klíč byl schválen Nintendem.
• data nebyla pozměněna a přešifrována bez oprávnění.

Udvedu příklad toho, jak to funguje:

1. Nintendo vytvoří klíč x.
2. Nintendo naprogramuje Starlet tak, aby věřil pouze datům, která jsou podepsaná klíčem x.
3. Pokud má Starlet dešifrovat titul pomocí klíče y, uskuteční tak pouze tehdy, jestli y byl podepsán klíčem x.

Tomuto postupu se přezdívá Chain of trust (řetěz důvěry). Mimo Wii se tato technika běžně používá k ochraně většiny naší komunikace po celém světě (například webové prohlížeče používající HTTPS spoléhají na „root certifikáty", aby ověřily pravost neznámých certifikátů).

Řetěz Starletu

OTP paměť Starletu ukládá veřejné klíče (což znamená, že pro naše účely může pouze dešifrovat a ověřit podpis obsahu). Jeho řetěz důvěry se skládá z následujících klíčů :

• Root Key: podepisuje CA klíč.
  • Starlet potřebuje uložit pouze tento (veřejný) klíč, zbytek může být dešifrován (a následně důvěřován), za předpokladu, že je podepsán tímto klíčem.
• Certification Authority Key (CA): podepisuje XS a CP klíče.
• XS Key: tento klíč podepisuje „tikety" - typ dat, který obsahuje seznam AES klíčů (nazvaných 'title keys') potřebných k dešifrování titulů.
• CP Key: jakmile je titul dešifrován pomocí příslušného názvu klíče, CP klíč se používá k podpisu metadat titulu (nazývaná „TMD").
  • Ačkoli obsah sám o sobě nepodepisuje, metadata obsahují hash SHA-1, který Starlet používá k ověření integrity těchto dat.

Jak vidíte, toto všechno umožňuje Nintendu být jediným distributorem her, což je dobrá zpráva pro herní studia obávající se pirátství.

Další klíče

Tento systém také obsahuje jeden pár soukromých a veřejných ECC klíčů. Elliptic Curve Cryptography (ECC) je další šiforvací algoritmus podobný RSA. V tomto případě se používá pouze k podpisu obsahu přenášeného na SD kartu i z ní. To zabraňuje tomu, aby obsah přenesený z jednoho Wii bylo možné spustit v jiném.

Klíč ECC je podepsán dalším veřejným klíčem RSA s názvem MS, který umožňuje Starletu důvěřovat ECC.

Poslední klíč, který tato konzole používá, je HMAC klíč, který je založen na jiném algoritmu, jenž kombinuje hash SHA-1 a HMAC. Starlet během bootování kontroluje, že NAND nebyla pozměněna hardwarem třetích stran. Kvůli tomu spočítá hash SHA-1 celé NAND a porovná jej s natvrdo uloženým hashem pro kontrolu, zda se shodují. A ke všemu je tento natvrdo uložený hash podepsán HMAC klíčem, aby bylo zajištěno, že je autentický.

Poznámka na konec: klíč HMAC je uložen v SEEPROM (nacházející se mimo Starlet), ne v OTP.

Pozorování

Po tomhle všem stojí za zmínku, že když systém spouští GameCube hry, není použita žádná z uvedených šifrovacích metod. Namísto toho Starlet pouze ověří, že hra má přístup pouze k určité části paměti. Je to proto, že 1/4 z GDDR3 RAM je přiděleno k simulaci původní ARAM.

Prolomení šifrování

Začněme klíčem AES. Jeho algoritmus se dá jen těžko prolomit, ale pokud jsou klíče nějakým způsobem extrahovány (zejména společný klíč), tato vrstva bezpečnosti okamžitě padá. Hlavní výzvou je tedy jejich extrakce.

Schéma zabezpečení: Starlet.

Skupina hackerů s názvem Team Twiizers zjistila, že nedostatek šifrování v GameCube režimu může být skvělou příležitostí k prolomení . Nejenže zjistili, že 3/4 z té GDDR3 RAM nebyly po spuštění GC módu vymazány, ale že je také možné přemostění adresních bodů na základní desce pomocí pinzety. To umožnilo přístup do zakázané oblasti v paměti a následné přečtení těchto nevymazaných dat. A světe div se, v nevymazané části paměti byly nalezené AES klíče.

Nezapomínejme, že to umožňuje pouze dešifrovat „první vrstvu" zabezpečení, ale aby bylo možné spustit nepodepsané programy (homebrew), RSA musí být prolomeno také. Bohužel to může být výpočetně nemožné... Nejsou-li v jeho implementaci nedostatky. Členové Teamu Twiizers však nepolevili, takže začali prozkoumávat, jak byl IOS naprogramován, a zaměřili se na jeho funkci ověřování podpisů.

Ověření podpisů RSA, aniž bychom zacházeli do přílišných podrobností, funguje srovnáním hashe vypočítaného RSA s dešifrovaným podpisem. Tým po určitém vrtání zjistil naprostou šílenost: Nintendo implementovalo tuto funkci pomocí strncmp (porovnávání stringů v C).

Pro lidi, kteří programovat v C neumí, strncmp je rutina, která se používá k ověření, že jsou nějaké dva stringy identické. Tato metoda přijímá tři parametry: dva stringy a jeden integer, přičemž tento integer uvádí, kolik znaků ze stringu se má porovnat. Poté strncmp začne porovnávat každý znak, dokud není dosaženo konce stringu (nebo počtu znaků vymezeném integerem). Sringy v C jsou jen řetězce znaků ukončené znakem \0. To znamená, že strncmp přestane porovnávat, jakmile nějaký string dosáhne \0. Proto vytvořením Wii titulu, jehož hash na začátku obsahuje \0 dojde k tomu, že RSA výpočty Starletu budou porovnávat velmi krátké hashe (či dokonce prázdné) se značnou šancí na kolize (odlišná data, která vytvářejí stejnou hodnotu hashe). Stačí malý brute-forcing a rutina strncmp vrátí, že stringy jsou identické... Titul je podepsán!

Aby toho nebylo málo, tato vada byla objevena i v několika verzích IOSu -⁠⁠⁠⁠⁠⁠ a dokonce i v rutinách v boot1 a boot2!

Úsvit Homebrew

Poté zbývala jen jedna věc: vytvořit k exploitu trvalý přístup a vyvinout uživatelský přívětivý nástroj, pomocí kterého by se daly snadno spouštět vlastní programy.

Spuštění aplikací třetích stran bylo původně prováděno použitím hacknutého savu.

Doposud zneužití těchto chyb vyžadovalo použití zvláštního hardwaru, takže se k tomu nedostal každý... Dokud Team Twiizers nenalezl další zranitelnost: game buffer overflow (přetečení paměti).

Mám na mysli slavnou The Legend of Zelda: Twilight Princess (hra od samotného Nintenda, mimochodem). TT zjistil, že uložený save lze upravit tak, aby jméno hráčova koně mělo více znaků, než je dovoleno. Když se tedy hráč pokusí spustit hru s přetečeným jménem koně, spustí by řetězovou reakci ústící v arbitrary code execution. To by bylo možné použít ke spuštění, řekněme, loaderu programů.

Vzhledem k tomu, že podpisy již mohly být padělány, byl tento upravený save snadno distribuován na netu, aby jej mohli použít ostatní. V důsledku toho homebrew komunita nyní mohla spouštět svůj vlastní software.

Trvalý stav

Jak byl IOS podrobován reverznímu inženýrství, bylo objeveno, že podpisy se hlídají pouze při instalaci titulů, ne při jejich běhu.

TT to tedy znovu dokázal. Pečlivě vytvořili instalovatelný kanál, který uměl načítat libovolné programy z SD karty. Pokud by tento kanál byl nainstalován dříve, než Nintendo přijme opatření k opravení bezpečnostních děr, pak by se Wii mohlo z homebrew těšit nadobro (i kdyby Nintendo opravilo chyby v podepisování, k čemuž nakonec došlo).

Výsledkem byl Homebrew Channel, jenž umožňuje každému uživateli spouštět homebrew aplikace, které mají plnou kontrolu na celým systémem (s veškerými důsledky, které to s sebou nese).

Reakce Nintenda

Ze zřejmých důvodů Nintendo vydalo několik aktualizací systému, které opravily chyby v digitálních podpisech několika verzí IOS, a také se postaralo o chyby ve spouštěcím procesu konzole vydáním hardwarových revizí.

Tohleto se stávalo často.

V tomto systému však stále byly zjištěny zásadní nedostatky:

• Broadway může restartovat Starlet do jakékoliv verze IOS bez dalších oprávnění, což umožnilo využívat neopravené verze.
• Skryté IOS API mohou být stále používány bez zvláštních oprávnění, což umožnilo ovládat harware bez oprávnění ještě více.
• DVD mechanika může přijímat příkazy ke čtení běžných DVD a některé IOS obsahovaly skrytá volání k odesílání těchto příkazů. To bylo obzvlášť znepokojivé z důvodu pirátství.

Abych to nějak uzavřel, tak jediné, co zůstalo, byla vlastně hra na kočku a myš. V příštích několika měsících byly objeveny jiné exploity, které se Nintendo postupně pokoušelo záplatovat. Tato „hra" pokračovala, až dokud konzole nedosáhla konce své životnosti a žádné další aktualizace poté již nebyly vydány. Můžeme předpokládat, že myš to tentokrát vyhrála.

V době psaní tohoto článku již byly všechny uvedené exploity opraveny, ale také nahrazeny novými, fungujícími.

Domnívám se, že o dopadu hackerské scény na tento systém není pochyb, a kdo může zapomenout na obrovské množství homebrew, které bylo k dispozici (dokonce existuje i homebrew „appstore", který byl rychlejší a svobodnější než oficiální „Wii Shop Channel").