Architettura Wii

La moltitudine di funzionalità offerte hanno reso il Wii molto attraente per la scena dell'hacking. La violazione del sistema di sicurezza avrebbe permesso agli sviluppatori homebrew di sfruttare tutte le potenzialità della console senza dover sottostare al controllo di Nintendo. Effettivamente, il Wii finì per offrire una ricchissima libreria di software homebrew.

Protezione anticopia

Iniziamo dai soliti sospetti: l'unità disco.

Come abbiamo visto, i dischi per Wii presentavano una "burst cutting area" inaccessibile dai lettori normali. In mancanza di questa zona, il disco non veniva letto.

La console non si schioda da questa schermata finché non viene inserito un disco valido.

Gli sviluppatori di modchip scoprirono che l'unità disco conteneva un'interfaccia di debug chiamata "Serial Writer" , una porta accessibile solo inserendo una chiave segreta. Era solo una questione di tempo prima che la chiave fosse scoperta. I modder poterono quindi disabilitare la protezione anticopia e, successivamente, sviluppare un modchip in grado di automatizzare la procedura.

Matsushita rilasciò ulteriori revisioni dell'unità disco in cui l'interfaccia di debug era offuscata; tuttavia, altre falle permisero di abilitare nuovamente quest'interfaccia.

Vale la pena sottolineare come lo scopo principale del modchip era la pura pirateria; poiché il contenuto del disco rimaneva comunque criptato, furono necessarie ulteriori ricerche prima di poter eseguire codice personalizzato.

Al contrario, gli homebrew per GameCube potevano essere eseguiti fin da subito grazie agli exploit precedenti scoperti sulla vecchia console.

La crittografia del sistema

Quello della crittografia è probabilmente l'aspetto più complesso della console e, contemporaneamente, ciò che ha messo in risalto l'abilità di molti sviluppatori, tra un'incessante attività di ricerca e lo sviluppo di programmi sorprendenti.

La sicurezza interna del Wii ruotava attorno a pochi algoritmi crittografici (AES, RSA, ECC, SHA-1 e HMAC). Esaminiamo ciascun gruppo separatamente, per non complicare la spiegazione:

Crittografia condivisa

Per proteggere il sistema dalle manipolazioni, le comunicazioni tra più componenti (NAND, disco di gioco e scheda SD) sono crittografate. La scelta di Nintendo è ricaduta su un sistema a chiavi simmetriche : ciò significa che il Wii usa la stessa chiave sia per criptare che per decriptare i dati.

Nella memoria OTP di Starlet sono conservate tre chiavi AES a 128 bit , scritte in hardware durante la fabbricazione:

• Chiave comune: una chiave globale generata da Nintendo e contenuta in tutti i Wii, utilizzata per decriptare il primo livello crittografico dei canali e dei giochi su disco (d'ora in avanti chiamati titoli per comodità).
• Chiave SD: la chiave utilizzata per criptare/decriptare i dati trasferiti sulla scheda SD; solo il menu Wii può trasferire tali dati.
  • Per motivi ancora incerti, Nintendo ha inserito una copia di questa chiave all'interno di IOS.
• Chiave NAND: una chiave generata casualmente durante la fabbricazione della console (quindi univoca per ogni Wii), utilizzata per proteggere il chip NAND.

Starlet è la sola CPU ad avere accesso ai dati riservati, ed è pertanto lei a occuparsi di criptare e decriptare i contenuti sensibili.

Catena di fiducia

I titoli contengono un ulteriore livello di sicurezza: RSA-2048. Si tratta di un algoritmo asimmetrico: sono necessarie una chiave per criptare un dato e una seconda chiave per decriptarlo. In questo modo, Nintendo è in grado di criptare i titoli utilizzando una chiave conosciuta solo dall'azienda stessa (ossia una "chiave privata"), mentre il Wii li decripta utilizzando una "chiave pubblica" memorizzata nella console. Anche se un hacker fosse entrato in possesso della chiave pubblica, questa non sarebbe bastata per violare il sistema di sicurezza, in quanto i dati dovevano comunque essere criptati utilizzando la chiave privata nota solo a Nintendo.

Inoltre, RSA non è utilizzato solo per criptare i dati, ma anche per controllare l'integrità della crittografia stessa. Nintendo utilizza più chiavi al solo scopo di firmare (ossia criptare) i dati già crittografati, generando quindi una catena crittografica per assicurarsi che:

• ogni singola chiave utilizzata sia stata autorizzata da Nintendo;
• i dati non siano stati alterati, quindi criptati nuovamente senza autorizzazione.

Il sistema funziona in questo modo:

1. Nintendo crea una chiave denominata x.
2. Nintendo programma Starlet in modo tale che la CPU si fidi solo dei contenuti firmati con la chiave x.
3. Se Starlet si ritrova a dover decriptare un titolo con una chiave y, procederà solo se y è stato firmato con la chiave x.

Questo meccanismo prende il nome di catena di fiducia. Oltre al Wii, è spesso utilizzato per proteggere gran parte delle telecomunicazioni in tutto il mondo (ad esempio: per verificare l'autenticità dei certificati sconosciuti, i browser che usano l'HTTPS sfruttano i "certificati radice").

Catena di Starlet

Le chiavi pubbliche sono conservate nella memoria OTP di Starlet (che quindi, per quello che interessa a noi, può solo decriptare e verificare le firme dei dati). La catena di fiducia è composta dalle chiavi seguenti :

• Chiave radice: firma la chiave CA.
  • Questa chiave (pubblica) è l'unico elemento che serve a Starlet; il resto può essere decriptato (e viene quindi considerato attendibile) se è stato firmato con questa chiave.
• La chiave dell'autorità di certificazione (CA): firma le chiavi XS e CP.
• La chiave XS: firma i "ticket", un tipo di dati che contiene un elenco di chiavi AES di cui il sistema ha bisogno per decriptare i titoli (denominate "chiavi dei titoli").
• La chiave CP: una volta decriptato un titolo con la relativa chiave del titolo, la chiave CP firma i metadati del titolo (i cosiddetti "TMD").
  • I metadati includono un hash SHA-1 (con cui non vengono firmati ulteriori dati) utilizzato da Starlet per verificare l'integrità del dati a cui si riferisce.

Le implicazioni sono evidenti: in questo modo, Nintendo è l'unico distributore di contenuti autorizzato. Un ottimo risultato per tutte le case di sviluppo preoccupate dalla pirateria.

Altre chiavi

Nel sistema è presente anche un paio di chiavi ECC pubbliche e private. La crittografia ellittica (in inglese "Elliptic Curve Cryptography", ECC) è un algoritmo simile all'RSA. Queste chiavi vengono utilizzate solo per firmare i dati in entrata e in uscita dalla scheda SD. In questo modo, i dati copiati nella scheda SD su un Wii non possono essere utilizzati su un secondo Wii.

La chiave ECC è firmata con l'ennesima chiave pubblica RSA, denominata MS: in questo modo, Starlet considera affidabile la chiave ECC.

L'ultima chiave utilizzata dal Wii è la chiave HMAC, che impiega un altro algoritmo che combina gli hash SHA-1 con HMAC. Durante la sequenza di boot, Starlet verifica che la NAND non sia stata alterata da hardware di terze parti. Per farlo, calcola l'hash SHA-1 della NAND e verifica che corrisponda a un hash memorizzato a livello hardware. Oltre a ciò, l'hash salvato viene firmato utilizzando la chiave HMAC per renderne certa l'autenticità.

Per finire: la chiave HMAC è memorizzata nella SEEPROM (al di fuori di Starlet), non nella memoria OTP.

Osservazioni

Dopo questa disamina, vale la pena sottolineare che quando il sistema esegue un gioco per GameCube, nessuno dei metodi crittografici appena descritti viene utilizzato. Starlet si limita a verificare che il gioco possa accedere solo alla memoria allocata ad esso. Questo perché 1/4 della RAM GDDR3 viene utilizzato per simulare la vecchia ARAM.

Come la crittografia è stata sconfitta

Iniziamo con le chiavi AES. Benché l'algoritmo fosse difficile da violare, se si fosse riusciti a estrarre le chiavi (soprattutto la chiave comune), lo strato di sicurezza corrispondente sarebbe subito venuto meno. La prima sfida, quindi, fu quella di trovare un modo per estrarre le chiavi.

Il diagramma della sicurezza di Starlet.

Un gruppo di hacker noto come Team Twiizers (un gioco di parole con "tweezer", la parola inglese che indica le normali pinzette) si rese conto che l'assenza di firme nella modalità GameCube poteva costituire una buona superficie di attacco . Il team scoprì non solo che tre-quarti della RAM GDDR3 non venivano ripuliti dopo l'esecuzione di un gioco per GameCube, ma anche che creando un ponte tra alcuni punti sulla scheda madre (utilizzando, guarda caso, proprio un paio di pinzette) era possibile invertire i banchi della RAM GDDR3 scelti, permettendo di accedere ad aree riservate della RAM. Sorpresa: in queste aree erano presenti anche le chiavi AES.

Meglio non correre troppo: in questo modo era possibile decriptare il "primo strato" del sistema di sicurezza, ma per eseguire programmi non firmati (homebrew) sarebbe stato necessario violare anche l'algoritmo RSA. Un'impresa potenzialmente impossibile, dal punto di vista della potenza di calcolo richiesta... a meno che l'algoritmo non fosse stato implementato male. Il Team Twiizers proseguì con le ricerche, iniziando quindi ad analizzare in che modo IOS fosse scritto e concentrandosi sulle funzioni di verifica delle firme.

Senza scendere troppo nel dettaglio, la verifica delle firme RSA funziona confrontando l'hash dell'operazione RSA eseguita con la firma decriptata. Dopo qualche smanettamento, il gruppo scoprì qualcosa di ridicolo nella sua banalità: Nintendo aveva implementato questa funzione utilizzando strncmp (in C, la funzione di confronto tra due stringhe).

Una spiegazione per chi non conosce il linguaggio C: strncmp è una routine utilizzata per verificare se due stringhe sono uguali. Questa funzione si serve di tre parametri: due stringhe e un intero, con quest'ultimo che indica il numero di caratteri da confrontare. Quando vengono inseriti, strncmp inizia a confrontare ogni carattere fino ad arrivare alla fine di una delle due stringhe (o quando il contatore di caratteri è raggiunto). In C, le stringhe sono una serie di caratteri terminati da un carattere \0: ciò significa che una volta raggiunto \0, strncmp smette di confrontare i caratteri. Quindi, scrivendo un titolo per Wii in modo tale da far sì che il suo hash contenga \0 sin dall'inizio, i calcoli RSA di Starlet finiranno per confrontare hash molto brevi (o addirittura vuoti) con notevoli possibilità di collisione (dati diversi che producono lo stesso valore di hash). In ultima analisi, utilizzando una quantità fattibile di attacchi brute-force, questo consentiva al confronto di restituire equal... Titolo è firmato!

Come se non bastasse, questa falla era presente non solo in diverse versioni di IOS, ma persino nelle routine delle fasi boot1 e boot2!

L'alba degli homebrew

A questo punto, mancava solo un tassello cruciale: rendere l'exploit permanente sviluppando uno strumento facile da usare per l'utente finale, per poter eseguire programmi custom su Wii senza grattacapi.

Inizialmente era possibile eseguire applicazioni di terze parti servendosi di un file di salvataggio modificato.

Gli exploit esaminati finora richiedevano l'uso di hardware aggiuntivo e non erano quindi alla portata di chiunque. Sarebbe stato ancora una volta il Team Twiizers a sbrogliare la matassa, scoprendo l'ennesimo exploit: un buffer overflow in gioco.

L'exploit fu scoperto nel famoso The Legend of Zelda: Twilight Princess (sviluppato dalla stessa Nintendo). Il team scoprì che all'interno del file di salvataggio del gioco era possibile modificare il numero dei caratteri utilizzati per il nome del cavallo del giocatore in modo tale da causare un overflow. Quando il gioco avrebbe provato a leggere questo nome, l'overflow avrebbe innescato una reazione a catena che sarebbe finita con la possibilità di eseguire codice arbitrario, che poteva quindi essere scritto in modo tale da far partire, ad esempio, un caricatore di programmi.

Poiché ormai si potevano creare firme contraffatte, il file di salvataggio modificato venne reso disponibile per chiunque tramite la rete. Ora la comunità homebrew poteva eseguire i propri software custom.

La ricerca di un exploit permanente

Durante l'analisi di IOS, si scoprì che le firme venivano controllate solo durante l'installazione dei titoli, e non durante la loro esecuzione.

Il Team Twiizers ne combinò un'altra delle sue. Con molta perizia, crearono un canale installabile in grado di caricare programmi arbitrari memorizzati nella scheda SD. Se il canale fosse stato installato prima della risoluzione dei problemi di sicurezza da parte di Nintendo, sarebbe quindi stato possibile eseguire permanentemente titoli homebrew sul Wii a prescindere dalla correzione delle falle di sicurezza nei processi di firma da parte di Nintendo (cosa che effettivamente avvenne).

Il risultato di questo sforzo fu il canale Homebrew, un titolo che consentiva a chiunque di avviare programmi homebrew che sfruttavano il controllo completo del sistema (con tutte le implicazioni del caso).

La risposta di Nintendo

Naturalmente, Nintendo rilasciò molti aggiornamenti di sistema per correggere gli exploit relativi alle firme presenti su diverse versioni di IOS, mentre la sequenza di boot fu modificata nelle revisioni successive dell'hardware.

Sì, erano piuttosto frequenti.

Tuttavia, il sistema continuava a presentare dei difetti di base:

• Broadway poteva riavviare Starlet facendogli eseguire qualsiasi versione di IOS senza permessi aggiuntivi: un comportamento che permetteva di sfruttare le vulnerabilità in versioni senza patch.
• Rimaneva possibile utilizzare le API nascoste di IOS senza ulteriori privilegi, consentendo un grado di controllo non autorizzato dell'hardware ancora maggiore.
• Era possibile inviare comandi affinché l'unità disco leggesse normali DVD, e alcune versioni di IOS contenevano chiamate nascoste che servivano proprio a mandare questo tipo di comandi. Il che, per Nintendo, era una possibilità particolarmente preoccupante per quanto riguardava la pirateria.

Alla fine, possiamo riassumere il resto della storia di questa console come un gioco a inseguimento. Ogni volta che venivano trovate nuove vulnerabilità, Nintendo si affrettava a rilasciare patch per provare a correggere i problemi riscontrati. Questa dinamica continuò fino alla fine del ciclo di vita della console, quando non vennero più rilasciati aggiornamenti di sistema. Alla fine, quindi, hanno vinto gli inseguiti.

Al momento della stesura di questo articolo, anche se le vulnerabilità qui descritte sono state già corrette, queste sono state sostituite da exploit ancora sfruttabili.

Il Wii rimarrà nella storia per i notevoli trascorsi della scena hacker sulla console, che includono una quantità immensa di titoli homebrew sviluppati appositamente per il sistema (grazie anche al "negozio" Homebrew, che non solo conteneva più titoli gratuiti rispetto al Canale Wii Shop, ma che poteva vantare addirittura una migliore velocità).