Architettura del Wii

Un'analisi pratica di Rodrigo Copetti

Tradotto da Valerio Francesco Vallone

Versione classica - Ultimo aggiornamento: 20 novembre 2021

Lingue disponibili: 🇬🇧 - English, 🇮🇹 - Italiano, 👋 - Aggiungi una traduzione


Informazioni su questa versione

La versione classica è una versione alternativa a quella moderna. Il suo funzionamento non richiede Javascript, CSS all'avanguardia o HTML particolarmente complesso, pertanto è ideale per gli utenti con lettori ebook, browser internet legacy o per i lettori che utilizzano strumenti di accessibilità.

I contenuti sono identici. Tuttavia, i widget interattivi sono stati semplificati per poter funzionare anche in HTML puro e includono un collegamento all'articolo originale, nel caso in cui il lettore volesse provare la versione completa.

Come sempre, questo articolo è disponibile su Github per consentire ai lettori di segnalare errori e proporre modifiche. È inoltre presente un elenco di letture di approfondimento, per aiutare nella comprensione dei contenuti di questa serie di articoli. L'autore accetta donazioni per migliorare la qualità degli articoli già pubblicati e di quelli futuri.


Sommario

  1. Immagini di supporto
  2. Breve introduzione
  3. Una nuova generazione di controller
    1. Espansioni
  4. La CPU
    1. E la memoria?
    2. Retrocompatibilità
  5. La grafica
    1. Funzionalità
      1. Widescreen standardizzato
      2. Interazione con lo schermo
    2. Design aggiornati
    3. Segnale video
  6. Audio
  7. I/O
    1. Il coprocessore nascosto
    2. Come viene mantenuta la retrocompatibilità
  8. Il sistema operativo
    1. Il SO di Starlet
    2. Il SO di Broadway
    3. I pacchetti di aggiornamento
    4. Sequenza di boot
  9. I giochi
    1. Il formato fisico
    2. Lo sviluppo sulla console
    3. Il menu HOME
    4. La personalizzazione nei giochi
  10. Lotta alla pirateria e homebrew
    1. Protezione anticopia
    2. La crittografia del sistema
      1. Crittografia condivisa
      2. Catena di fiducia
      3. La catena di Starlet
      4. Altre chiavi
    3. Come la crittografia è stata sconfitta
    4. L’alba degli homebrew
    5. La ricerca di un exploit permanente
    6. La risposta di Nintendo
  11. È tutto!
  12. Referencing
  13. Fonti / Continua a leggere
  14. Contributi
  15. Registro delle modifiche

Immagini di supporto

Modelli

Image
Le Wii
Rilasciato il 19/11/2006 negli Stati Uniti, il 02/12/2006 in Giappone e l'08/12/2006 in Europa

Scheda madre

Image
Scheda madre
La revisione "RVL-CPU-40"; per le revisioni precedenti veniva impiegato un processo di fabbricazione molto più complesso, mentre nelle revisioni successive sono stati rimossi buona parte dei componenti I/O del Gamecube.
La memoria NAND flash è posizionata sul retro
Image
Scheda madre con componenti importanti contrassegnati

Diagramma

Image
Diagramma dell'architettura principale
Dei bus dati più importanti sono indicate larghezza e velocità

Breve introduzione

Nonostante non potesse vantare una grafica all’ultimo grido come i suoi concorrenti, il Wii aveva dalla sua parte un sistema di controllo totalmente nuovo e software innovativi.

In questo articolo analizzeremo ogni aspetto della console: dal suo hardware, già noto, al trascurato sistema di sicurezza con i suoi principali difetti.

Nota: Alcuni capitoli si sovrappongono a parti dell’articolo precedente sul GameCube, quindi invece di ripetere le stesse informazioni inserirò un collegamento alla specifica parte dell’articolo.


Una nuova generazione di controller

Iniziamo da uno degli elementi più iconici di questa console: i suoi controller.

Il dispositivo principale è l’ormai classico telecomando Wii (noto in inglese come “Wii Remote” o “Wiimote”, come lo chiameremo da qui in avanti), un oggetto dalla forma simile a quella di un normale telecomando per TV che includeva diversi input:

Il telecomando funziona grazie a un Broadcom BCM2042, un chip che include tutti i componenti necessari affinché possa essere utilizzato come dispositivo Bluetooth indipendente (CPU, RAM, ROM e, ovviamente, un modulo Bluetooth). Benché il Wiimote sia programmato per essere identificato come dispositivo di input secondo il protocollo “Bluetooth HID”, i dati vengono scambiati tramite un metodo non standard (probabilmente per impedire che possa essere utilizzato su sistemi diversi dal Wii).

Infine, nel Wiimote è presente una EEPROM da 16 KB, per memorizzare i dati dell’utente, e un piccolo altoparlante in grado di riprodurre solo suoni a bassa qualità (ADPCM 3 kHz a 4 bit o PCM 1,5 kHz a 8 bit).

Espansioni

Nintendo includeva nella confezione un altro controller da impugnare nella mano opposta, il Nunchuk, costituito da un suo accelerometro, una levetta analogica e due pulsanti. Il Nunchuck si collega al Wiimote tramite una porta proprietaria a 6 pin.

Image
Un Nunchuck e un Wiimote

Sono stati prodotti altri accessori in grado di collegarsi a questa porta, ciascuno con input di diverso tipo.


La CPU

Dopo il successo di Gekko, possiamo ipotizzare che IBM abbia rimarchiato lo stesso design come “750CL”, affinché potesse essere utilizzato da altri produttori. Quando Nintendo chiese una nuova CPU da utilizzare per la futura console, nota ancora con il nome in codice “Revolution” (da cui il prefisso RVL presente sulle schede madri), IBM si accordò con l’azienda giapponese per utilizzare un 750CL con il doppio della velocità di clock rispetto a Gekko. Questa CPU, nota come Broadway, opera a una frequenza di 729 MHz.

Dopo aver riesaminato Gekko, credo che le novità nella nuova CPU siano piuttosto limitate. Tuttavia, questa familiarità poteva rappresentare un vantaggio: gli sviluppatori GameCube potevano iniziare a sviluppare nuovi giochi per Wii fin da subito, grazie all’esperienza accumulata con Gekko. Inoltre, il raddoppio della velocità di clock di Broadway gli permetteva di aggiungere funzionalità ai software e incrementarne la qualità.

E la memoria?

Contrariamente a quanto ci si aspetterebbe considerando la somiglianza della CPU, la vecchia struttura di memoria del GameCube è stata riprogettata e migliorata con le modifiche seguenti:

Retrocompatibilità

Arrivati a questo punto, possiamo dire che questa console è una versione potenziata del GameCube, tanto che il Wii eredita la compatibilità con i giochi della generazione precedente. Per rendere il Wii pienamente retrocompatibile, si è reso necessario includere nel sistema tutte le vecchie porte esterne: quelle dei controller del GameCube e quelle delle schede memoria. Ecco però la prima limitazione: la nuova mappa della memoria non è compatibile con quella vecchia. Per questo motivo, è stato implementato nel software un semplice strato di “emulazione” (ulteriori informazioni nei capitoli “I/O” e “Sistema operativo”).

Gli accessori del GameCube che utilizzavano la porta seriale e la porta ad alta velocità non possono essere utilizzati con il Wii, data l’assenza di tali porte.

Le revisioni hardware degli anni seguenti hanno purtroppo visto la rimozione delle porte del GameCube.


La grafica

Il nuovo pacchetto grafico è denominato Hollywood. Esegue gli stessi compiti che eseguiva Flipper nel GameCube, ma beneficiando del doppio della velocità di clock (243 MHz). Questo aumento di velocità permette di elaborare un numero maggiore di geometrie ed effetti a parità di unità di tempo.

Funzionalità

Il motore 3D è ancora quello di Flipper, ora denominato GX. Invece di riepilogare di nuovo la sua pipeline, ci limiteremo a esaminare alcune variazioni interessanti che gli sviluppatori dovevano considerare:

Widescreen standardizzato

Image
Modalità 4:3
Image
Modalità 16:9 prodotta dall’encoder video
Image
Modalità 16:9 visualizzata su una TV widescreen
Super Mario Galaxy (2007)

I giochi per GameCube non disponevano di un vero e proprio supporto agli schermi in 16:9, una novità rispetto al classico formato 4:3. Nonostante ciò, Flipper era comunque in grado di gestire queste situazioni e alcuni giochi permettevano di attivare una modalità 16:9, per quanto fosse comunque considerata come una funzionalità esclusiva.

In realtà, l’encoder video produce sempre fotogrammi conformi agli standard PAL o NTSC; questa modalità widescreen, quindi, funziona disegnando un frame buffer interno più ampio e lasciando che l’encoder video lo ridimensioni per adattarlo a un segnale 480i o 576i. A valle, la TV 16:9 avrebbe adattato il flusso video per ottenere un’immagine finale con un rapporto d’aspetto più o meno corretto. Non si tratta di una tecnica nuova: il widescreen anamorfico è impiegato da tempo nella proiezione cinematografica dei film.

Tornando al Wii, la console ha standardizzato questa funzionalità permettendo di attivare una modalità “panoramica” dalle impostazioni del sistema, usata anche per migliorare i panorami in molti giochi (battuta pessima, lo ammetto).

Interazione con lo schermo

Image
Super Mario Galaxy (2007)
Il giocatore può raccogliere le astroschegge puntandole con il Wiimote

L’innovativo sistema di controllo rendeva possibili nuovi tipi di interazioni all’interno dei giochi per Wii. Dal momento che il Wiimote consentiva agli utenti di puntare lo schermo, alcuni giochi come Super Mario Galaxy o The Legend of Zelda: Twilight Princess sfruttavano questa funzionalità per far interagire il giocatore con lo scenario.

Nell’articolo intitolato Miti da debuggare: il Wii è più complesso da emulare rispetto al GameCube?, gli sviluppatori dell’emulatore Dolphin svelano che giochi come Super Mario Galaxy e altri sparatutto in prima persona utilizzano uno z-buffer integrato per identificare gli oggetti ai quali il Wiimote punta e/o verificare la distanza di tali oggetti dal cursore del Wiimote.

Non si tratta di una funzionalità nuova in assoluto, bensì di un nuovo modo di utilizzare funzionalità già esistenti. I giochi per GameCube non usavano un controller multiuso con una funzione di puntamento integrata. Ora, invece, i giocatori avrebbero potuto controllare il proprio personaggio e puntare lo schermo contemporaneamente.

Design aggiornati

Grazie ai megahertz aggiuntivi di Broadway e Hollywood e a design all’avanguardia, nei giochi per GameCube è stato possibile migliorare i modelli dei personaggi. Anche se non si è trattato di un salto generazionale pari a quello dei cicli di console precedenti, il miglioramento è stato comunque sensibile e apprezzato.

Image Image Image Il modello interattivo è disponibile nella versione moderna
Sonic DX (2003) per GameCube
1985 triangoli
Image Image Image Il modello interattivo è disponibile nella versione moderna
Super Smash Bros Brawl (2008) per Wii
3644 triangoli

Segnale video

Sorpresa: il Wii non usa più l’ormai classica porta Multi Out, ma una sua variante denominata AV Multi Out (poca fantasia da quelle parti…), con una forma leggermente diversa. Il connettore supporta tutti i segnali usati in precedenza, con l’aggiunta dello spazio colori YPbPr (conosciuto anche come segnale “component”). Inoltre, nella porta sono presenti alcune linee dati utilizzate dal sistema per identificare il tipo di cavo inserito.

Purtroppo, questo design eredita le stesse limitazioni che caratterizzavano il GameCube. Niente S-Video sui sistemi PAL, così come niente RGB sui sistemi NTSC. Inoltre, l’RGB può trasmettere solo segnali interlacciati, quindi niente segnali progressivi. Come rovescio della medaglia, finalmente Nintendo decise di commercializzare un cavo SCART (acquistabile separatamente) in grado di sfruttare i pin RGB (ignorati, come forse ricorderete, sin dai tempi dello SNES).


Audio

Il Wii monta lo stesso DSP Macronix presente nel GameCube, quindi potete fare riferimento a quell’articolo per un’analisi dettagliata.

Rispetto al GameCube, l’unico cambiamento principale è rappresentato dal fatto che è possibile utilizzare MEM1 o MEM2 come buffer audio, data la scomparsa della memoria ARAM.


I/O

Il sottosistema I/O del Wii è una vera rivoluzione (per restare in tema con il suo nome in codice). Le interfacce sono ora controllate da un unico modulo deputato anche alla sicurezza della console: Starlet.

Il coprocessore nascosto

Starlet non è altro che una CPU ARM926EJ-S collegata alla maggior parte dei componenti interni della console. Localizzata all’interno di Hollywood, opera a 243 MHz (come Hollywood) e dispone di RAM e ROM proprie. È quindi possibile considerare Starlet come un computer indipendente in esecuzione parallela rispetto alla CPU principale.

La CPU è simile a quella utilizzata nel Nintendo DS, salvo per due aggiunte particolari:

Come detto, si tratta miglioramenti “particolari” in quanto non sono mai stati sfruttati dal Wii. Nonostante ciò, Nintendo ha comunque scelto di utilizzare questa CPU per Starlet. Anche il primo iPhone (2G) includeva una CPU ARM con Jazelle, e anche in questo caso la funzionalità è rimasta inutilizzata.

La risposta alla domanda sul perché Jazelle non sia mai stato utilizzato, anche dopo alcune iterazioni, è che si scoprì che veniva eseguito meglio in software. In seguito, ARM sostituì Jazelle con “Thumb-2EE”. Attualmente (nel giugno 2021), entrambe queste unità sono state gradualmente eliminate.

Image Image
I/O esterne del Wii
Il piccolo slot scuro sul lato frontale è un lettore di schede SD

A questa “CPU I/O” è assegnato il compito di gestire l’accesso tra i vari dispositivi I/O e Broadway; nel fare ciò, si occupa anche della sicurezza della console, decidendo se consentire o negare i vari accessi. Si tratta di un compito particolarmente importante nei casi in cui coinvolge l’accesso, ad esempio, alla NAND, che contiene i dati del sistema operativo principale e dell’utente.

Il chip utilizza alcune tecnologie ARM come l’Advanced Microcontroller Bus Architecture (AMBA), un protocollo che semplifica la comunicazione tra dispositivi attraverso un set di bus specializzati.

Nintendo ha scelto di collegare i dispositivi I/O in modo da utilizzare due bus AMBA:

Come viene mantenuta la retrocompatibilità

Image
Un Wii con dispositivi del GameCube collegati

Nonostante il sistema I/O originale sia stato modificato radicalmente, il Wii è pienamente retrocompatibile con i giochi per GameCube. Starlet viene infatti riprogrammato quando si esegue un gioco per GameCube, rimandando virtualmente i dispositivi di I/O secondo la stessa configurazione del GameCube originale.

Inoltre, nel chip real-time clock chip è presente della ROM aggiuntiva che contiene i font bitmap (sia per l’alfabeto latino che per il giapponese) utilizzati nei giochi per GameCube, e una SRAM per salvare le impostazioni relative all’IPL.


Il sistema operativo

Nel Wii sono presenti due sistemi operativi: uno viene eseguito su Broadway (la CPU principale), mentre l’altro viene eseguito su Starlet (la CPU I/O). Entrambi risiedono in una memoria NAND da 512 MB e possono essere aggiornati.

Il SO di Starlet

Come se Starlet non fosse già interessante sul lato hardware, lo è anche (e soprattutto) per quanto riguarda il software. Il SO di Starlet, infatti, non solo ha un accesso completo a ogni singolo componente della console, ma è il primo codice a essere eseguito quando viene premuto il pulsante di accensione.

Starlet contiene un SO noto in maniera non ufficiale come Input/Output Operating System, o “IOS” (da non confondere con iOS di Apple). IOS è un sistema operativo praticamente completo, che include:

Con tutto questo a sua disposizione, il compito principale di IOS è quello di alleggerire il carico di lavoro sulla CPU principale occupandosi dell’I/O e della sicurezza. Gli sviluppatori, quindi, non dovevano preoccuparsi di questi aspetti. Per assolvere il suo compito, Starlet si riserva tra 12 e 16 MB di RAM GDDR3, mentre il resto viene utilizzato da Broadway e da GX.

Broadway e Starlet dialogano tra loro utilizzando un protocollo Inter-Process Communication, o “IPC”: in parole povere, le due CPU condividono due registri ciascuna. Una CPU può scrivere nei registri dell’altra (con dati che possono rappresentare un comando o un valore) e, come risposta, la CPU ricevente può eseguire una funzione.

Il sistema di aggiornamento di IOS è un po’ complesso: le versioni aggiornate di IOS non sono installate sovrascrivendo le precedenti, ma vengono memorizzate in un altro slot (l’area della NAND riservata a IOS è infatti divisa in “slot”). Ciò avviene solamente per motivi di compatibilità: in questo modo, i software per Wii sviluppati per una versione di IOS precedente possono continuare a utilizzare la versione di IOS per cui sono stati sviluppati.

Nintendo rilasciava spesso aggiornamenti di IOS per migliorare il supporto hardware (ciò si rendeva necessario quando veniva messo in commercio un nuovo accessorio). Solo in un caso gli aggiornamenti di IOS sostituivano le versioni precedenti: quando in una determinata versione veniva scoperta una vulnerabilità sfruttabile. Le motivazioni, quindi, erano puramente legate alla sicurezza.

Quando viene inserito un gioco per GameCube, Starlet avvia invece un MIOS. Si tratta di una variante di IOS che chiede a Starlet di emulare l’IPL originale.

Il SO di Broadway

Questo sistema operativo è conosciuto più comunemente come menu Wii e viene eseguito sulla CPU PowerPC principale (Broadway).

Image
Il menu Wii con svariati canali installati
Image
Il menu utilizzato per modificare le impostazioni
Image
La bacheca contiene le lettere raggruppate per data

Se confrontato con IOS, non definirei “completo” questo SO: si tratta più di un programma che consente all’utente di eseguire le operazioni seguenti:

Come per IOS, anche il menu Wii è stato aggiornato numerose volte. Alcuni aggiornamenti correggevano falle di sicurezza, mentre altri aggiungevano nuove funzioni. Tra queste, una delle più importanti è stata la possibilità di memorizzare i canali nelle schede SD.

Ogni programma in esecuzione su Broadway (compreso il menu Wii) richiede una versione specifica di IOS per funzionare. Quando viene avviato un gioco o un canale, Starlet si riavvia utilizzando la versione dichiarata di IOS richiesta.

I pacchetti di aggiornamento

Per gli aggiornamenti, Nintendo utilizza la dicitura Aggiornamenti di sistema. Ciascun pacchetto di aggiornamento contiene entrambi i SO e le varie versioni sono numerate con numeri ordinali; l’ultima versione nota è la 4.3E, rilasciata nel giugno 2010.

I pacchetti di aggiornamento del sistema possono essere scaricati dai server di Nintendo o installati dai dischi di gioco. Gli utenti possono verificare manualmente la disponibilità di aggiornamenti tramite il menu Wii. Se un gioco richiede una versione specifica di IOS non installata nella console, qualora il disco di gioco contenga i pacchetti necessari l’aggiornamento viene forzato.

Sequenza di boot

Finora abbiamo esaminato i due sistemi operativi, caratteristici per diversità, presenti nella console ed eseguiti simultaneamente. Ma le cose non sono semplici come potrebbero sembrare: infatti, i due SO devono essere coordinati con particolare attenzione durante la sequenza di avvio della console per poter funzionare correttamente in seguito.

La sequenza di boot della console è quindi la seguente:

  1. L’utente preme il tasto ON sulla console.
  2. Fase Boot0: Starlet esegue un programma a livello hardware contenuto nella Mask ROM integrata (da 1,5 KB).
    • In breve: Starlet decritta e verifica l’integrità dei primi 96 KB della NAND, quindi ne calcola l’hash e lo confronta con un hash salvato nella memoria OTP integrata in Starlet stesso. Se i due hash non coincidono, la console entra in un loop infinito.
  3. Fase Boot1: Starlet esegue un piccolo programma contenuto nei 96 KB di NAND appena decrittati.
    • Il programma chiede a Starlet di inizializzare (pulire) la RAM GDDR3 da 64 MB, per poi decrittare e verificare il resto della NAND.
  4. Fase Boot2: Starlet carica l’IOS iniziale (richiesto per eseguire il menu Wii), quindi avvia Broadway.
  5. Broadway avvia il menu Wii. Da questo momento, l’utente prende il controllo.

I giochi

Anche se la grafica dei nuovi giochi non era propriamente rivoluzionaria, gli utenti potevano comunque godere di nuove funzionalità in grado di sorprenderli. Merito dei nuovi dispositivi e servizi resi disponibili da Nintendo sin dal lancio della console: dai nuovi controller, fino a un’infrastruttura online standardizzata (WiiConnect24) che permetteva di giocare su internet gratis.

Il formato fisico

I giochi per Wii sono distribuiti su un disco di formato proprietario, il Wii Optical Disc (“disco ottico Wii”, un nome molto descrittivo). Si tratta di un formato progettato da Matsushita/Panasonic a partire dai normali DVD, con l’aggiunta di alcune peculiarità non standard come una burst cutting area lungo il bordo interno del disco, per impedire le copie non autorizzate.

Image
I giochi standard sono distribuiti fisicamente su un disco all’interno di una custodia
Image
I giochi più piccoli (Wiibrew) e i titoli delle console precedenti (Virtual Console) possono essere acquistati e scaricati nel Canale Wii Shop

I dischi di gioco per Wii possono contenere 4,7 GB (nel formato a strato singolo) o 8,54 GB (nel formato a doppio strato). Spesso contengono due partizioni: una per gli aggiornamenti del sistema, l’altra per l’effettivo software di gioco.

Alcuni dischi di gioco, come nel caso di Super Smash Bros Brawl, contenevano più partizioni con all’interno diversi giochi Virtual Console, eseguibili all’interno del gioco principale.

Lo sviluppo sulla console

Come sempre, Nintendo inviava agli sviluppatori un kit di sviluppo. Quello del Wii si chiamava NDEV e si presentava con le fattezze di un grosso mattone nero. NDEV offriva ulteriori opzioni di I/O e una dimensione della MEM2 raddoppiata (128 MB in totale), per scopi di debug.

La suite di software ufficiale si chiamava Revolution SDK e includeva vari strumenti utili durante lo sviluppo, come compilatori, debugger e framework (scritti prevalentemente in C/C++). Nintendo ha distribuito gli aggiornamenti tramite il sito web Warioworld.com (che ora reindirizza verso un altro sito di Nintendo), accessibile solo dagli sviluppatori verificati.

L’SDK ufficiale si basa su chiamate ad IOS per interagire con l’hardware di Wii; è per questo che gli aggiornamenti di IOS vanno spesso a braccetto con gli aggiornamenti dell’SDK.

Il menu HOME

Considerati tutti i progressi di questa console sul lato software, può sorprendere il fatto che i giochi vengono comunque eseguiti “bare metal”, ossia che hanno il controllo completo delle risorse hardware di Broadway (ma non di Starlet, motivo per cui è proprio questa CPU a occuparsi delle misure di sicurezza). Naturalmente, il codice di gioco deve comunque essere approvato da Nintendo prima che possa essere distribuito.

Image
Il menu Home visualizzato in partita
Image
Anche questa schermata doveva essere inclusa

Detto questo, alcune funzionalità che compaiono in molti giochi diversi sono stranamente simili. Ad esempio: ricordate il famoso menu HOME? Premendo il pulsante “HOME” sul WiiMote, una schermata sovrimpressa sul gioco permette all’utente di tornare al menu Wii senza dover riavviare la console. Ma dato che il SO non offre una simile funzionalità, com’era possibile che tutti i giochi offrissero la stessa interfaccia grafica?

La risposta è semplice: Nintendo includeva nell’SDK alcune librerie obbligatorie che dovevano essere incluse nei giochi. E guarda un po', una di queste si occupa di creare proprio quella schermata. È lo stesso motivo per cui solo le applicazioni homebrew utilizzano design originali per il menu HOME.

Il menu HOME ufficiale è uno dei circa 200 elementi che i giochi dovevano includere, come indicato nel documento Wii Programming Guidelines (le linee guida per la programmazione sulla console, fornite con l’SDK ufficiale). Tra gli elementi da includere vi era la schermata con il promemoria riguardante il laccetto da indossare (una semplice immagine BMP) visualizzata all’avvio del gioco, con cui l’utente poteva interagire solo nei modi consentiti da Nintendo.

La personalizzazione nei giochi

Image
Il Canale Mii permetteva di personalizzare il proprio “Mii”…
Image
… che sarebbe poi comparso nei vari giochi
Wii Music (2008)

Un’altra caratteristica da enfatizzare sono i Mii, degli avatar che gli utenti potevano creare nell’apposito Canale Mii.

Ma non finisce qui: i giochi potevano utilizzare i Mii creati per personalizzare l’esperienza di gioco.


Lotta alla pirateria e homebrew

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.

Image
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:

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 entrasse in possesso della chiave pubblica, questa non basterebbe per violare il sistema di sicurezza, in quanto i dati devono comunque essere criptati utilizzando la chiave privata nota solo a Nintendo.

Inoltre, l’RSA non consente solo di criptare contenuti, ma anche di verificare l’integrità della protezione. Nintendo utilizza più chiavi al solo scopo di firmare (ossia criptare) i dati già crittografati, generando quindi una catena crittografica al solo scopo di assicurarsi che:

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”).

La 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:

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.

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.

Image
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 3/4 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 strcmp (in C, la funzione di confronto tra due stringhe).

Una spiegazione per chi non conosce il linguaggio C: strcmp è 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, strcmp inizia a confrontare ogni carattere fino ad arrivare alla fine di una delle due stringhe. In C, le stringhe sono una serie di caratteri terminati da un carattere \0: ciò significa che una volta raggiunto \0, strcmp smette di confrontare i caratteri. Quindi, scrivendo un titolo per Wii in modo tale da far sì che il suo hash contenga degli zero sin all’inizio, l’algoritmo RSA di Starlet darà in pasto a strcmp una stringa che inizia con \0. In questo modo, il risultato del confronto sarà sempre equal e così… avremo un 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.

Image
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.

Image Image
L’hack più accessibile del mondo.
Canale Homebrew non ufficiale (2008).

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 ha rilasciato molti aggiornamenti di sistema per correggere gli exploit relativi alle firme presenti su diverse versioni di IOS, mentre la sequenza di boot è stata modificata nelle revisioni successive dell’hardware.

Image
Sì, erano piuttosto frequenti

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

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à).


È tutto!

Buon 2020!

Questo articolo ha richiesto un bel po' di tempo. Credevo, forse ingenuamente, che dal momento che molti dei contenuti erano già stati scritti per il Gamecube, mi sarei limitato ad aggiungere qualche piccola sezione, un collegamento ogni tanto…

È venuto fuori un articolo molto più dettagliato di quanto avessi potuto immaginare. Spero che sia stato interessante.

Alla prossima!
Rodrigo


Contributi

Questo articolo fa parte della serie L'architettura delle console. Se l'hai trovato interessante, puoi effettuare una donazione. Il contributo sarà usato per finanziare l'acquisto di strumenti e risorse che mi aiuteranno a migliorare la qualità degli articoli pubblicati e futuri.

Donate with PayPal Become a Patreon

Un elenco degli strumenti che vorrei acquistare e degli acquisti per questo articolo è disponibile qui:

Interesting hardware to get (ordered by priority)

Acquired tools used

In alternativa, potete dare una mano suggerendo modifiche e/o aggiungendo una traduzione.


Referencing

This work is licensed under a Creative Commons Attribution 4.0 International License. You may use it for your work at no cost, even for commercial purposes. But I ask that you reference it properly. Please take a look at the following citation guidelines:

Article information

For any referencing style, you can use the following information:

For instance, using the IEEE style:

[1]R. Copetti, “Wii Architecture - A Practical Analysis”, Copetti.org, 2020. [Online]. Available: https://classic.copetti.org/writings/consoles/wii/. [Accessed: day- month- year].

and Harvard style:

Copetti, R., 2020. Wii Architecture - A Practical Analysis. [online] Copetti.org. Available at: https://classic.copetti.org/writings/consoles/wii/ [Accessed day month year].

Special use in multimedia (Youtube, etc)

I only ask that you include at least the author’s name, title of article and URL of article, using any style of choice.

You don’t have to include all the information in the same place if it’s not feasible. For instance, if you use the article’s imagery in a Youtube video, you should state either the author’s name or URL of article at the bottom of the image, and then include the complete reference in the video description.

Appreciated additions

If this article has significantly contributed to your work, I would appreciate it if you could dedicate an acknowledgement section, just like I do with the people and communities that helped me.

This is of course optional and beyond the requirements of the CC license, but I think it’s a nice detail that makes us, the random authors on the net, feel part of something bigger.


Fonti / Continua a leggere

Generale

CPU

Grafica

I/O

Sistema operativo

Giochi

Antipirateria

Fotografie

Altri contenuti

Bonus