LE PROTEZIONI NELLE CONSOLES - NINTENDO Wii U

​

E'giunto il momento di trattare il successore della console "Riivoluzionaria" di casa Nintendo, una console nella quale l'azienda di Kyoto ha profuso molte energie innovative ma che il mercato probabilmente non ha saputo apprezzare come probabilmente meritava: la Wii U !

​

Con product code WUP-001 (o WUP-101 per la versione "black") la console è stata immessa nel mercato a Novembre 2012. Un pochino sotto tono come caratteristiche hardware se paragonata alle competitors dell'epoca, con il suo gamepad voleva essere qualcosa di ulteriormente innovativo rispetto alla Wii, con la quale resta retrocompatibile, ma per numerosi motivi (tra i quali ricordiamo lo scarso supporto di terze parti e l'impossibilità di utilizzare 2 gamepads contemporanemanete) divenne la console da salotto che rese meno a Nintendo con sole 13.5 Milioni di unità vendute nel suo relativamente breve periodo di vita conclusosi ad inizio 2017.

SISTEMI DI PROTEZIONE

FORMATO DISCO PROPRIETARIO

I dischi Wii U hanno una capacità di 25GBs, sono stati prodotti da Panasonic (una delle aziende fondatrici della Blu-ray Disc Association) ed utilizzano un formato proprietario simile al Blu-ray che nessuno finora ha mai indagato nel dettaglio come è invece accaduto per i dischi GameCube e Wii (vedere articoli specifici); i margini di questi dischi hanno qualcosa di diverso rispetto a tutti gli altri: sono smussati ed al tatto appaiono decisamente "lisci" se confrontati con i normali supporti:

Come sempre la scelta è stata dettata dal fatto di poter evitare la riproduzione di normali Blu-ray visto che secondo Satoru Iwata "...oramai tutti hanno un lettore Blu-ray" e per motivi legati ai costi di produzione e pagamenti di royalties per il supporto dello standard DVD-BD.

DRIVE OTTICO PROPRIETARIO

Ogni disco in formato proprietario richiede un lettore proprietario e quello delle Wii U sembra essere un RD-DKL034-ND prodotto sempre dalla Panasonic.


Nel dettaglio il drive ha una interfaccia SATA ma con pinout proprietario ed all'apparenza con connettore zif a 28 pins:

Solo ad Ottobre 2017 sono state pubblicate le specifiche reversate del lettore. I reversers sono stati in grado di effettuare i primi dumps grazie ad un collegamento dello stesso al PC inviando comandi proprietari scoperti nel corso dei loro studi.

Wii U CHAIN OF TRUST

La catena che permette alla Wii U di avviare in modo "sicuro" il suo sistema è composta di numerosi setps detti "stages" 3 dei quali non più esistenti (nello specifico gli stages 34, 35 e 36: il codice reversato fa supporre fossero utilizzati per avviare una recovery image via WiFi) che sono riassumibili come segue:

La console avvia il boot0 (di 16KBs, situato all'interno di una Mask ROM del chip chiamato "Latte", il quale contiene anche il processore dedicato alla sicurezza chiamato "Strabuck") che carica le keys contenute in una OTP e disabilita la OTP stessa; poi il boot0 decripta con le keys di cui sopra il boot1, che risiede in NAND (titolo 00050010-10000100), e lo carica.
Il boot0 di Wiiu è stato dumpato a fine 2012 dal team Fail Overf0w tramite apposito exploit come spiegato al 30c3 da Marcan (vedere specifico paragrafo) mentre il boot1 (che risiede in NAND) non è stato decodificato dal team perchè non è stato trovato alcun exploit in boot0 che permettesse di ottenere la key per decriptare il boot1; nel Giugno 2016 il dev derrek ha inviato un tweet dove dimostra di aver estratto tale key senza però renderla pubblica.

A questo punto dal boot1 viene caricato l'IOSU (che risiede in NAND) il quale poi avvia il Menu WiiU dal quale è possibile avviare o la boot ROM che avvia la sandbox (CafeOS) da dove viene eseguita la modalità vWii (e da qui titoli o giochi Wii) oppure titoli e/o giochi WiiU dal System Menu di WiiU.

Nintendo in questo IOSU ha studiato meccanismi di controllo e verifica dei dati in modo migliore rispetto a quanto fatto per gli IOS Wii in particolare controllando il codice dei titoli sia in fase di installazione sia in fase di avvio (questa seconda parte non veniva effettuata nella Wii).

Nello spoiler il decapping del chip AMD di Wii U e delle sue componenti Espresso e Latte:

Spoiler

CHIP AMD COME APPARE APRENDO LA CONSOLE:


CHIP AMD PRIVO DEL METAL SHIELD:


ESPRESSO (CPU) DECAPPATA:

maggiori informazioni qui

LATTE (GPU) DECAPPATA:

maggiori informazioni qui

MEMORIE

• SLC
• MLC
• SLCCMPT
• OTP
• OTP_PPC
• SEEPROM

• 
  Partizione di sistema WiiU - 512Mb
  
• 
  Partizione di storage WiiU - 8 o 32GBs a seconda del tipo di console
  
• 
  Partizione di sistema vWii - 512Mb
  
• 
  Si trova nel chip Starbuck ed è grande 8 volte quella della Wii: 1KB suddiviso in 8 blocchi da 128 bytes (invece di un singolo blocco da 128 bytes). Il blocco 0 appartiene alla vWii (tutti gli altri blocchi sono disabilitati in modalità vWii, quindi la vWii puo'vedere solo le keys che le interessano, che sono le stesse della Wii).
  Ecco il blocco 0 (blocco Wii):
  
  in ordine di colore abbiamo: Hash del boot1 - Wii common key - console ID (oscurato) - private key - NAND HMAC (overlappato con la private key) - NAND key (oscurata) - RNG key - sconosciuti
  
  Di seguito i blocchi da 1 a 6 (blocchi WiiU):
  
  
  Ed infine l'ultimo blocco, il blocco 7, appartenente al boot1:
  
  
• 
  Si trova nel chip Espresso ed è utilizzata sia in modalità WiiU che vWii, ma è possibile leggerla solo all'esecuzione della boot ROM perchè viene successivamente disabilitata:
  
  
• 
  Tale memoria, contenuta nel chip "Latte", è simile (se non identica) ad una 93C66 da 4K (il doppio della SEEPROM dell'Hollywood Wii) organizzata in blocchi da 256x16 bytes.
  Alcuni suoi valori sono scritti di fabbrica e non vengono mai modificati mentre alcuni vengono periodicamente aggiornati.
  I suoi contenuti sono i seguenti:
  
  
  

KEYS IMPORTANTI

La Wii U possiede numerose keys AES le più significative delle quali sono:

• ESPRESSO KEYS
• STARBUCK KEYS
• DISC KEY
• RSA TICKET SIGNATURE
• DATI MEMORIZZATI CRIPTATI

• 
  
  vWii ANCAST KEY
  
  (estratta il giorno 11 - leakata il 5 Giugno 2014)
  SHA1: ce3641b2660253f5a7e789db297be2c1585b3054
  - Si trova nella OTP Espresso.
  - Utilizzata per decriptare il System Menu vWii ed i NANDlaoders (1-512 e 1-513) al momento del caricamento. - Viene disabilitata dalla boot ROM fino al reset successivo.
  
  
  
  Wii U ANCAST KEY
  
  (estratta il giorno 11- leakata il 5 Giugno 2014)
  SHA1: 2ba6f692ddbf0b3cd267e9374fa7dd849e80f8ab
  - Si trova nella OTP Espresso
  - Utilizzata per decriptare il kernel Cafe OS al momento del caricamento.
  - Viene disabilitata dalla boot ROM fino al reset successivo.
  
• 
  
  Wii U COMMON KEY
  
  (estratta il giorno 30 - rilasciata il 13 Gennaio 2015 da zecoxao - interessante commento di Marcan in merito)
  SHA1: 6a0b87fc98b306ae3366f0e0a88d0b06a2813313
  - Si trova nella OTP dello Starbuck
  - Utilizzata per decriptare la key specifica per ogni applicazione WiiU (ciò è fatto al momento dell'installazione per firmware i titoli installabili mentre è fatto al momento del caricamento per i giochi su disco). Il Cafe OS ed i binari per lo Starbuck sono criptati sia con questa key che con la loro ancast key.
  
  
  
  vWii COMMON KEY
  
  (estratta il giorno 30 - rilasciata da Hykem il 17 Gennaio 2016)
  SHA1: 2b30b703c6676c8124c7347b30c7972ffeae2b39
  - Si trova nella OTP dello Starbuck
  - Utilizzata per decriptare la title key per gli aggiornamenti della modalità vWii (questa key è utilizzata soltanto al momento dell'installazione quindi la modalità vWii non necessita dell'accesso al suo valore). Il System Menu ed i NANDloaders sono criptati sia con essa che con lavWii ancast.
  
  
  
  Wii U ANCAST KEY
  
  SHA1: d8b4970a7ed12e1002a0c4bf89bee171740d268b
  - Si trova nella OTP dello Starbuck
  - Utilizzata per decriptare i binari per lo Starbuck (Wii U IOS e cafe2wii - rilasciata da Hykem il 17 Gennaio 2016). Questa key, a differenza delle keys Espresso, è abilitata in modo permanente (tranne che in modalità vWii), dato che il boot0 dello Starbuck viene eseguito al momento dell'avvio e che i binari per lo Strabuck sono parsati e decriptati dall'IOSU stesso quando viene caricato.
  
  
  
  BOOT 1 KEY
  
  (presumibile SHA1 rilasciata da derrek tra il 19 ed il 20 Giugno 2016)
  Probabile SHA1: 56DD59752E6AF1E55FC2EE7074ABE2D2C9E70A10
  - Si trova nella OTP dello Starbuck
  - Utilizzata dal boot0 per decriptare il boot1. Solo questa key è disabilitata selettivamente dal boot0 in uno speciale registro della OTP e non è più disponibile dopo il boot. Hanno provato ad estrarla con vari metodi, anche con alcuni side-channel attacks ma senza riuscirci. Il dev Derrek sembra avercela fatta ma non l'ha diffusa.
  
• 
  Ogni disco contiene una key AES necessaria per decriptare il proprio contenuto; questa key viene richiesta dal lettore al disco attraverso uno specifico comando proprietario ed è diversa dalla key contenuta nel ticket del disco.
  
• 
  Ogni ticket proveniente da un titolo eShop contiene una firma generata con algoritmo RSA effettuata con le (sconosciute) keys private Nintendo ed al calcolo di questa firma digitale contribuisce anche l'ID della console quindi ogni ticket è univoco e non puo'essere utilizzato da un'altra console (a meno che non si applichi una patch alle firme) !
  
  Ogni ticket contenuto in un disco originale contiene una firma RSA effettuata con le (sconosciute) keys private Nintendo. Questo ticket invece NON è console-specifico (vedere "metodo Brazil" più avanti per sapere cosa questo comporti) !
  
• 
  I dati salvati in NAND, SD e periferiche USB collegate vengono criptati ed ogni supporto di memorizzazione ha la sua specifica Key; tali Keys sono diverse da console a console.
  

SISTEMI PER ESEGUIRE CODICE ARBITRARIO

Anche con la Wii U il team che ha permesso di raggiungere l'accesso più intimo all'interno della console è stato il Team Twiizers oramai noto e consolidato come Team Fail0verflow:

Chi sono costoro ?
Nel 2012, al 29esimo Communication Chaos Congress (29C3) il team ha richiesto la partecipazione per 28 membri quindi sappiamo indicativamente chi fa parte di questo capace gruppo di individui:

Spoiler

marcan
iZsh
saurik
jix + 2 friends
bushing
mha
drmr
blasty
tmbinc + 2 friends
sven
Travis Goodspeed
planetbeing + 1 friend
pytey + 1 friend
zf
bunnie + 1 friend
c1

Prima di questa manifestazione il team ha messo le mani sulla Wii U e durante la stessa non ha rivelato molto sulla console.
E'però soltanto durante il 30C3 che alcuni membri hanno svelato gran parte dei trucchi utilizzati per arrivare là dove Nintendo voleva che nessuno arrivasse.
Cercherò di raccontarvi una breve cronostoria degli accadimenti:

Tutto ha avuto inizio con il video della lettura del Team in particolare dall'accoppiata Marcan/Sven con l'aggiunta di Comex:


La discussione inizia con Sven che descrive le differenze tra la vecchia Wii e la nuova WiiU paragonando la seconda ad una sorta di evoluzione della prima.
DIFFERENZE HARDWARE

Spoiler

Dal punto di vista HARDWARE le differenze sono le seguenti:


Nella successiva immagine più dettagliata presa dall'articolo pubblicato dal team f0f il giorno 2 Gennaio 2014 sul sito del team:

subito notiamo l'aggiunta di;
- un chip, chiamato Espresso, che rimpiazza il vecchio Broadway a 729MHz, il quale ha al suo interno 3 cores a 1.243GHz
- una GPU chiamata GX2 che si aggiunge alla vecchia GX il tutto rinchiuso in un "chip" chiamato Latte (il vecchio veniva chiamato Hollywood)
- inoltre notiamo la comparsa di un chip ARM (DRH) che ha al suo interno un proprio sistema operativo che gestisce la comunicazione tra WiiU e Gamepad (nel gamepad c'è un chip analgo chiamato DRC)
- la sicurezza è gestita invece dallo "Starbucks" (processore ARM296EJ-S), lo stesso che possiamo trovare sulla Wii (chiamato dal team "Starlet")

DIFFERENZE SOFTWARE

Spoiler

Dal punto di vista SOFTWARE invece vediamo che le differenze sono le seguenti:

- Il software gira sul "puro metallo" in Wii tramite dei mini-OS (gli IOS), mentre in WiiU abbiamo il nuovo sistema operativo Cafè OS;
- IOS WiiU (chiamato IOSU) completamente riscritto;
- la firma RSA Wii era controllata solo in fase di installazione, in WiiU ora è controllata all'avvio di quello che è installato;
- il chip Espresso avvia solo codice criptato e firmato quindi deve esserci una Boot ROM speciale all'interno dell'Espresso, che il team f0f chiama in gergo "Ancast" (perchè "la principessa è sempre in un altro castello!" - citazione di super mario !! :)

Se avete letto lo spoiler, dal reverse engineering Sven ci spiega che ora in vWii tutto passa appunto per una nuova bootrom, assente nella Wii !

Vediamo dunque le differenze tra la catena dell'affidabilità Wii e quella della nuova modalità vWii di WiiU:

Il quadratino rosso rappresenta appunto la nuova BootROM mancante nella Wii.


Cosa ha scoperto il team durante il suo reversing:
- La firma e l'hash dell'immagine (che, ricordiamolo, viene chiamata Ancast) viene verificata prima che venga decriptata
- poi l'immagine viene decriptata in toto in memoria
- subito prima dell'entry point in memoria dell'immagine decriptata appare una istruzione (vedi sotto)

Tra i punti 2 e 3 dell'immagine soprastante (porzione in alto a sinistra) il team ci informa che passa del tempo per la decodifica a causa sia dell'algoritmo utilizzato che della quantità di alcuni megabytes dell'immagine da decriptare; questo determina un problema "classico" nell'analisi e ricerca dei bugs/exploit, cioè il problema del ToC/ToU (Time of Check/Time of Use) ovvero, nello specifico, del fatto che il momento temporale in cui avviene la decodifica dei dati è diverso e successivo (tempo relativamente lungo) dal momento in cui avviene l'effettivo utilizzo dei dati decodificati: questo fatto configura l'hack non come un exploit ma come un vero e proprio sfruttamento di un "design flaw" o difetto di progettazione poichè è possibile utilizzare la bootROM a nostro uso e consumo addirittura utilizzandola come strumento che ci permetta di decriptare ciò di cui abbiamo bisogno [files binari della modalità vWii ad eccezione dei dati criptati WiiU - oppure per riattivare i 3 cores 2 dei quali vengono disattivati dalla boot rom stessa al momento dell'avvio del codice decriptato rendendo quindi la sua presenza (della bootrom) inutile a questo punto [è in questo momento che il team ha dumpato la bootrom (all'ottavo giorno di studio), con pubblicazione del relativo hash a dimostrazione del effettivo avvenuto dump].

Questo sistema rende necessario il reboot della console di conseguenza il team ha trovato un modo per comunicare direttamente via seriale (come avevano già fatto con lo slot per le memory card della Wii) con un agent eseguito sulla conosle che ha permesso l'invio di comandi tramite script pyton eseguito sul PC.

Ma che interfaccia hanno utilizzato per collegarsi alla console ? 3 possibili soluzioni (parte inferiore dell'immagine sopra):
-- LOLSERIAL: direttamente dal cavo della barra sensore per gli wiimotes, metodo lento
-- GHETTOHCI: anche esso lento;
-- GPIOGECKO: più veloce ! In pratica sono stati utilizzati i collegamenti del USB Gecko (usato solo come interfaccia hardware per comodità) per collegarsi direttamente sulla scheda madre.

In questo modo il team ha scoperto che l'istruzione che viene eseguita subito prima di eseguire l'immagine decrittata Ancast (mtspr scr, 3) disabilita la bootrom e, nonostante i tentativi effettuati dal team, non è stato possibile sovrascriverla.

Ora il microfono passa a Marcan che spiega il funzionamento dettagliato della bootrom (vedi spiegazione dettagliata a fondo post):


e ci spiega l'hack con dump della stessa inviando un comando di soft reset in un preciso momento in cui la bootrom è in esecuzione in memoria;

però a questo punto è comunque troppo tardi per ricavare le keys dalla memoria quindi si passa a cercare un nuovo hack, l'hardware reset hack !


Inviando questo reset hardware in uno specifico momento/modo il PPC inizia a comportarsi in modo strano [definito "ubriaco" dal team con tanto di filmino di un gatto che si comporta in modo strano]; tra questi comportamenti imprevedibili c'è anche l'esecuzione di codice creato ad hoc, che ha permesso di estrarre le keys di vWIi e WiiU ! Quindi "drunk is enough" ! [dumpate il giorno 11 con relativa hash del file che le contiene postata nel loro sito]

SPIEGAZIONE DEL FUNZIONAMENTO BOOT ROM E RESET HACKS

Spoiler

(dal minuto 20:54 al minuto 37:48 della videopresentazione)
Boot ROM, eseguita dal Power PC, utilizza un multi memory manager; abbiamo dunque differenti tipi di memoria ognuna che inizia ad un indirizzo differente
RAM (chip fisico) CPU L2 CACHE (che puo'essere o non puo'essere mappata come la RAM). Il PPC puo'operare in 2 modalità: REAL MODE (che corrisponde all'indirizzo fisico) ed in TRANSLATED MODE

All'inizio abbiamo l'Immagine binaria del System Menu (Ancast cripata) all'indirizzo 0x01330000 e da qui, all'indirizzo 0 della stessa, c'è l'header dell'immagine Ancast, mentre all'address 100 c'è il cyphertext. All'indirizzo 0x00000000 c'è ivece il Power PC reset vector.

PPC in REAL MODE:
- carica la Boot ROM (16Kb - memorizzata nell'Espresso) all'address 0x00000000 (in questa modalità la cache è OFF);
- appena caricata la Boot ROM azzera l'MMU, la cache, i registri e tutto il resto (nulla di interessante); poi mappa se stessa (la Boot ROM) utilizzando una caratteristica dei PPC chiamata "Block Address Translation" [BATs]; in pratica prende un blocco di memoria da una parte e lo mappa da un'altra parte (semplice) e si automappa nella TRANSLATED MODE;
- inoltre mappa altre 2 sezioni:
0x16c00000 (mappata come 0x00020000) - di cui non si conosce il significato, non si sa perchè venga mappata
0xe0000000 (mappata come se stessa come 0xe00000000)
- In translated mode abilita anche le cahces L1 ed L2 - ed in real mode al posto della Boot ROM all'address 0x00000000 (che prima era qui contenuta) viene caricato il Reset Vector, questo perchè la Boot ROM funziona solo se non è abilitato l'accesso alla cache;
- a questo punto la Boot ROM (che, ricordiamolo, è in esecuzione in Translated Mode), effettua il lock della cache L1 (16Kb) sia in real che in translated mode all'indirizzo e0000000: qui poi vengono copiati stack e dati;
- subito dopo parte del codice della Boot ROM (circa 12Kb) viene copiata nella cache L2 e mappata in translated mode all'indirizzo 0x016c0000 (fisico) 0x00020000 (translated);
- ora scarica la cache L1 ed L2 (ma NON la RAM);
- adesso va alla locazione 0x00020000 (dove c'è parte del codice ROM copiato) per copiare le keys AES dall'OTP (ancora accessibile) all'indirizzo 0xe0000000 e subito dopo disabilita l'accesso all'OTP e setta un DMA buffer in 0xe0000000 (dove coesistono anche stack, dati e keys AES);
- a questo punto inizia un ping pong di dati dal buffer DMA alla RAM 0x01330000 dove viene hashato e decodificato il ciphertext che diventa plaintext (e si trova in RAM);
- ora salta alla Boot ROM presente in 0x0000000 (translated mode);
- ora pulisce 0x00020000 e flusha L2;
- poi wipa e unlockka la cache L1;
- unmappa 0x00020000 e 0xe0000000
- ed infine mappa il payload in translated mode (ancast header + plaintext) all'indirizzo 0x1330000 (translated mode - prima era in RAM)
- ora disabilita, invalida e riabilita L1 ed L2
- poi esegue, all'indirizzo 0x013300fc, l'istruzione mtspr scr, 3 che disabilita la Boot ROM
- ora salta dove in translated mode (0x01330000) c'è il payload e lo esegue;

Tutto questo è un furbo trucco di Nintendo necessario per far rimanere isolata l'esecuzione del codice ROM !

Ma c'è una falla !

Quella dei reset ! Con l'hack del reset (soft e hard, entrambi controllati dallo Starbuck) inviati in momenti particolari di tutto il percorso di cui sopra hanno ottenuto il dump della Boot ROM (soft reset inviato nel momento in cui vengono disabilitate, invalidate e riabilitate la chache L1 ed L2 - giorno 8 ) e l'esecuzione di codice creato da loro (hard reset inviato in un modo specifico ha permesso di dumpare le keys dell'espresso lette dalla OTP e copiate in memoria)

In questo momento l'Espresso è stato sconfitto in vWii mode, ora tocca allo Starbuck in WiiU mode !

La Wii ha un boot0, boot1 e boot2, la vWii no, viene avviata direttamente dalla modalità WiiU ! Ma cosa succede se abilitiamo la lettura del boot0 in modalità vWii che NON ha il boot0 ? Appare un boot0 "wild"! Il WiiU Boot0 ! Dumpato il giorno 14 con realtiva hash postata dal team sul loro sito - "All your boot0 are belong to us", altra famosa citazione videoludica basata su un errore di traduzione del famoso gioco Zero Wing!

40 minuti sono passati quasi in un lampo dall'inizio della presentazione (a parte la spegazione di Marcan ); seguono considerazioni di hacking più "generico" da parte di Comex che potete saltare oppure leggere nello spoiler sottostante:

Spoiler

Quando viene il suo turno, Comex spiega come hanno sconfitto il WiiU mode ! Inizia con il descrivere in generale come hackerare "qualsiasi embedded device" (con embedded si intendono piattaforme hardware tipo le consoles o lettori mp3, ecc con elettroniche che comunicano tra loro tramite microprocessori).

1 - usare il browser e vedere se c'è qualcosa di già documentato (es. vecchi bugs degli webkit Nintendo) ed usare proprio il browser per cercare di trovare un bug che permetta un exploit ! Vi ricorda nulla ?

Riassume dunque le differenze tra Cafe OS e Wii; dice che il Cafe OS ha un sistema di dynamic linking mentre la Wii static linking come il GameCube.


2 - un metodo per cercare di sconfiggere il WiiU mode è stato quello di giocare con l'IOSU e "rendere inutilizzabile la propria console finchè qualcuno non ve la presta durante il chaos congress"

(il discorso di Comex non è stato molto dettagliato purtroppo...)

Torna di nuovo a parlare Marcan che ci informa che la "missing thing" (vedi ultima foto nello spoiler sopra) in vWii è la key che utilizza il boot0 per decriptare il boot1 in Wii ! Ci speiga dunque che ora, avendo le keys, è possibile decriptare il Cafe2Wii software, ovvero la sandbox che permette l'esecuzione di vWii sotto WiiU. Tale programma altri non è che un file .elf "non-stripped" (grande regalo da parte di Nintendo !!!) ovvero che contiene tantissime informazioni e stringhe di debug utili per il reverse engineering !!! In tali stringhe si evidenzia come Nintendo utilizzi CygWin (ultima immagine a sinistra)


Ci informa poi che la sandbox è un "sacchetto" pieno di cosucce carine da dove possiamo:
- riconfigurare parzialmente il bus verso il WiiU mode;
- riabilitare metà della memoria extra MEM1 (ma questo fa si che lo Starbucks non funzioni più correttamente);
- testare le GPIOs della WiiU ed altre cosine.
Ma questo non è abbastanza perchè il nuovo hardware WiiU è spento o limitato nella frequenza di clock ed altre funzioni sono disabilitate in questa sandbox; cosi come è sarebbe potuta essere utilizzata da Nintendo per rendere disponibile la creazione di homebrew tagliando fuori le parti realtive alle protezioni per evitare che si possa facilmente bucare il sistema un po'come faceva OtherOS per la PS3 ma Nintendo non si è mai dimostrata interessata agli homebrew.

Marcan si congeda dunque con l'epilogo:

- a questo punto dice che c'è una oggettiva difficoltà nel creare un ambiente homebrew salubre (niente pirateria) dato soprattutto lo scarso interesse negli homebrew stessi;
- arriva poi alla conclusione che forse si è arrivati ad un punto in cui gli homebrew nelle console "chiuse" non sono più interessanti per la maggior parte degli utenti anche a causa dei vari mediabox magari già integrati nelle TV (lo dimostrano le milioni di installazioni di HBC su Wii contro le sole 27.000 nella vWii).;
- parla infine del tentativo su GBATemp di abilitare i 3 cores in modalità vWii ma dice che purtroppo non ci sono individui che ne sappiano abbastanza da riuscire nell'impresa anche se ci mettono impegno (ed infatti il thread è fermo al Febbraio 2015).

Una cosa che il team non ha rivelato è che durante il congresso (giorno 30 dall'inizio dello studio sulla Wii U) hanno estratto anche la Espresso Wii U Ancast Key e la Starbuck Wii U Common Key!


SCUSE

Spoiler

Mi scuso anticipatamente per le semplificazioni ma riassumere in poche parole una presentazione di questo tipo non è cosa facile e dubito di esserci riuscito al meglio.

UNITA'DI SVILUPPO

• V1-V2
• V3
• WUT-002
• WIS-001/003

• 
  
  vedi il controller
  
  Spoiler

  
• 
  
  
• 
  
  
• 
  Non sono vere unità di sviluppo ma unità "kiosk" da esposizione nei negozi o nei centri commerciali; possono avere o non avere un hard disk interno (nella console con HDD, NOA-SNOWCAP-01, le porte USB frontali sono bloccate, nelle altre, NOA-KOLIBRI-001, no):
  
  
  
  
  

EXPLOITS

Come abbiamo avuto modo di leggere la WiiU ha 2 sistemi operativi: è ancora in grado di avviare gli IOS sulla CPU ARM come faceva la vecchia Wii ma ha anche un sistema operativo che gira sul PowerPC e tale sistema è chiamato Cafe OS.

Fatta questa premessa vediamo i 4 livelli di exploit possibili nella WiiU:
1 - User Space: quello che si ottiene con l'exploit del browser; rappresenta il primissimo passo verso un accesso più profondo al sistema e richiede un RoP dato che il Cafe OS non permette l'esecuzione di programmi in memoria; tramite ROP si ottiene dunque la capacità di avviare codice in memoria accedendo cosi all'SDK del Cafe OS potendo lavorare all'interno del sistema con privilegi limitati, come quelli di un normale titolo/gioco, avendo in questo momento la possibilità di creare homebrew (vedi il piccolo "pong" che era stato creato mesi fa); L'SDK è una interfaccia che permette agli sviluppatori di avere accesso alle risorse (grafica, sonoro, controlli, file system); il Cafe OS si trova tra i giochi e l'hardware, dando ai titoli (prevalentemente giochi) l'accesso a queste risorse delegando a volte questo lavoro di "intermediario" al IOSU.
Ma in questo ambiente "poco privilegiato" non possiamo fare granchè a meno che non sia possibile trovare un exploit del:
2 - Cafe OS kernel: (kernel del OS che gira sul PowerPC della console) in questo modo si ottiene accesso a buona parte del sistema con ancora delle limitazioni (vedi i vari Loadiine, Dumpiine, ecc) a meno che non si ottenga un exploit del:
3 - IOSU module: con questo livello di accesso siamo finalmente arrivati all'IOSU (il sistema operativo che gira sul processore Arm della WiiU, responsabile tra le altre cose della sicurezza) ma non ancora a tutto l'hardware della console; l'IOSU è infatti a sua volta suddiviso in moduli, di conseguenza, exploitando un modulo IOSU, non abbiamo accesso a tutti i moduli (che possono essere paragonati ai drivers) che lo compongono ma soltanto a quello exploitato; è qui che è necessario l'ultimo exploit, quello del:
4 - IOSU kernel: exploitando il kernel del IOSU abbiamo finalmente accesso a tutto l'hardware della macchina.

VEDIAMOLI:​

• USER SPACE
• CAFE OS KERNEL
• IOSU MODULE
• IOSU KERNEL
• boot1

• 
  RenderArena use-after-free
  - Applicazione vulnerabile: Internet Browser
  - Sfruttabile nelle versioni di firmware: 2.0.0-5.1.0
  - Pubblicato in libwiiu: SI
  - Descrizione (in lingua originale): "an iframe is removed from its parent in a beforeload event and freed, but accessed for a vtable call later. Using Javascript, a vtable pointer is sprayed, occupying the frame's previous memory. A forged vtable referred to by the pointer is also sprayed. When WebKit attempts the virtual call, it goes to the forged vtable, which starts a ROP chain."
  - Scoperto da: Marionumber1, TheKit, Hykem, Relys e Mathew_Wi
  - Link: QUI
  
  JSStringJoiner heap overflow
  - Applicazione vulnerabile: Internet Browser
  - Sfruttabile nelle versioni di firmware: 5.1.1 - 5.3.1 (forse anche nelle precedenti)
  - Sfruttato pubblicamente in: libwiiu (solo versione 5.3.2)
  - Descrizione (in lingua originale): "when joining an array of strings, the lengths of the strings are summed to calculate the needed storage space. This summation is vulnerable to an integer overflow, which enables a heap overflow. As a result, a sprayed value from Javascript ends up as a vtable pointer, which can be used with a forged vtable to start a ROP chain. More information here."
  Scoperto da: Marionumber1, Hykem e Mathew_Wi
  - Link: QUI
  
  Stagefright ‘stsc’(?) MP4 atom integer overflow
  - Sfruttabile nelle versioni di firmware: 5.4.0-5.5.0 (forse anche in versioni precedenti)
  - Sfruttato pubblicamente: SI
  - Descrizione: Integer overflow documentato in libstagefright (MP4)
  - Scoperto da: zhuowei, Marionumber1 e Mathew_Wi
  
  Stagefright ‘tx3g’ MP4 atom integer overflow
  - Sfruttabile nelle versioni di firmware: 5.3.2-5.5.1 (forse anche in versioni precedenti)
  - Sfruttato pubblicamente: SI (wiiu_browserhax_fright)
  - Descrizione: Integer overflow documentato in libstagefright (MP4)
  - Scoperto da: yellow8
  
  
• 
  OSDriver race attack
  - Sfruttabile nelle versioni di firmware: 2.0.0 - 5.4.0
  - Sfruttato pubblicamente in: libwiiu
  - Descrizione (in lingua originale): "the Cafe OS kernel implements a structure called an OSDriver, which can hold a 0x1000-byte cross-process data area. Accessing this data area is done through the CopyToSaveArea() and CopyFromSaveArea() syscalls. However, no lock on the OSDriver is held during the copy, allowing the save area to be freed and reallocated while the copy is taking place. With all 3 PPC cores, it is possible to copy over an OSDriver structure, and create a save area that points at the syscall table, giving PPC user mode code access to it. More information here."
  - Scoperto da: libwiiu team (Marionumber1, TheKit, Hykem, comex, Relys e Mathew_Wi)
  - Link: QUI
  
  GX2 unchecked memory read/write
  - Sfruttabile nelle versioni di firmware: 2.0.0 - 5.5.1
  - Sfruttato pubblicamente in: libwiiu
  - Descrizione (in lingua originale): "The Wii U GPU (the GX2) has direct access to RAM for various operations. Using raw GPU commands it is possible to read/write memory in the PPC kernel heap, which is not blocked from GPU access. By redirecting the "next pointer" in the kernel heap into userspace it becomes possible to create a new OSDriver structure in userpsace and set it's save area to the kernel syscall table. From that point on, the OSDriver race attack can be reused."
  - Scoperto da: libwiiu team (Marionumber1, TheKit, Hykem, Mathew_Wi)
  - Link: QUI
  
  
• 
  ioctlvhax - ioctlv TOCTOU
  - Sfruttabile nelle versioni di firmware: 1.0.0 - 5.2.0
  - Sfruttato pubblicamente in: NO
  - Descrizione: "this flaw technically is in the kernel, but it can be used to exploit a usermode module. It allows changing an ioctlv vector buffer address entry after it has been validated by the kernel. Any module not checking the number of ioctlv vectors is vulnerable."
  - Scoperto da: naehrwert e plutoo
  - Link: QUI
  
  IOS-USB bad array index check (uhshax)
  - Sfruttabile nelle versioni di firmware: 1.0.0 - 5.5.2
  - Sfruttato pubblicamente: SI
  - Descrizione: "IOS-USB manages UHS (USB host stack) and exposes it via the node /dev/uhs/0. This node can be "talked" to from PPC userspace by issuing ioctl commands. The last two ioctl commands (0x12 and 0x13 in firmware versions 2.x.x, 0x13 and 0x14 in firmware versions 3.x.x and 4.x.x, 0x14 and 0x15 in firmware versions 5.x.x) are responsible for activating and deactivating (respectively) the root hubs which are managed in internal structures inside IOS-USB. The single parameter that is passed to these ioctl commands is the root hub number which should only be 0 or 1. IOS-USB uses this number directly as an index for the internal root hub structures' array, but it doesn't check it properly (if index <= 2, proceed normally). Passing the index value 2 results in an useless array index overflow, but passing a negative value allows to redirect the array into a userspace buffer we control. The ioctl command responsible for activating a root hub (0x12, 0x13 or 0x14) registers two new IOS-BSP entities (CtrlProp and CtrlChicken) that become tied to the root hub. Attempting to exploit this particular ioctl command always results in a uncontrollable memory write (the written data comes from IOS-BSP and cannot be changed). However, the ioctl command responsible for deactivating a root hub can be exploited by carefully crafting a buffer that mimicks a root hub structure. With it, we can eventually achieve a write-what-where primitive, overwrite the return address of the IOS-USB's thread responsible for handling the ioctl commands (__uhsBackgroundThread) and achieve ROP inside IOS-USB. This exploit can be used to build a ROP chain that calls the IOS_CreateThread system call and exploit the IOSU kernel. However, in firmware 5.5.1 a new check was added to the system call handler that verifies if the calling thread's stack pointer is valid. In order to sucessfully make use of this exploit chain in firmware 5.5.1 one must be sure to build a small enough ROP chain that allows calling a system call before the thread's stack pointer goes past the stack top address"
  - Scoperto da: Hykem
  - Link: QUI
  
  USB Descriptor Parsing Is Hard (UDPIH)
  - Sfruttabile in tutte le versioni di firmware
  - Sfruttato pubblicamente: SI
  - Descrizione: la Wii U non verifica che la lunghezza totale del descrittore di configurazione USB corrisponda alla lunghezza totale utilizzata per determinare la dimensione del buffer. Ciò consente di posizionare i descrittori di endpoint al di fuori del buffer allocato che verrà scambiato; questo permette una catena ROP con esecuzione di codice arbitrario a livello del kernel.
  Con questo exploit è possibile unbrikkare consoles brikkate ad esempio con un utilizzo errato di CBHC; la prima versione utilizzava un raspberry pi pico ma per chi non ne fosse in possesso l'autore ne ha implementato una versione da avviare attraverso una console Switch mandata in recovery mode da collegare alla Wii U in fase di boot; qui i dettagli. L'autore è lo stesso che nel 2021 ha scoperto l'exploit BluuBomb che permette di bucare la console simulando un controller Wii, un po'come avviene per l'exploit in grado di permettere la modifica sulla Wii Mini, sfruttando un bug nel IOS-PAD e ISO-KERNEL.
  - Scoperto da: GaryOderNichts
  - Link: QUI e QUI
  
• 
  IOS_CreateThread unchecked memset
  - Sfruttabile nelle versioni di firmware: 1.0.0 - 5.5.2
  - Sfruttato pubblicamente: SI (sorgenti di dimok e FIX94)
  - Descrizione: "The IOS_CreateThread system call fills the stack of a newly created thread without validating the passed stack address. In older firmware versions (pre 5.x.x) this memset was done using a null constant (0x00000000). Considering that every IOSU module can call this system call, compromising the IOSU userspace and calling IOS_CreateThread allowed to arbitrarily patch the IOSU kernel with NOP instructions (0x00000000 is interpreted as NOP in ARM) and, therefore, build a NOP sled in the IOSU kernel. In recent firmware versions (5.x.x) a constant was added to the unchecked memset (0xFA5A5A5A), sucessfully rendering it useless. However, if a new thread is created as "detached" (detached state set to true), the top 0x24 bytes of the thread's stack are memset back to null. By creating several new detached threads and aligning their stacks carefully, it becomes possible to build a NOP sled again"
  - Scoperto da: naehrwert ed Hykem (ognuno in modo indipendente dall'altro)
  
• 
  boot1hax
  E'infine notizia del 14.01.2018 quella del boot1 code execution pubblicata dal reverser hexkyz; grazie alle ricerche di derrek, plutoo, yellow8, naehrwert e shuffle2, questo ragazzo è riuscito a dimostrare questo bug fino a quel momento solo teorico che permette l'esecuzione di codice prima che la OTP venga protetta; è riuscito dunque a leggere anche quella piccola parte di OTP finora inaccessibile scoprendo che... quei 2 blocchi non vengono mai utilizzati ed il lock di tale regione potrebbe essere servito come sistema di sicurezza aggiuntivo per futuri eventuali aggiornamenti della console visto che sono uguali per tutte le console. Questo exploit potrebbe permettere l'esecuzione di un dual boot, è estremamente facile da patchare ed è stato rilasciato proprio successivamente alla data di fine commercializzazione della console per evitare che venisse corretto da un update "in itinere" !
  
  isfshax
  Il 10 Aprile 2021 il dev rw-r-r-0644 ha scoperto una falla nel boot1, nello specifico nel modo in cui gestisce la profondità delle cartelle indentate; l'exploit porta all'esecuzione di codice arbitrario in vold boot rendendo non più necessario l'utilizzo di un titolo originale DS !
  

APPLICAZIONE DEGLI EXPLOIT

• browserhax
• Indexiine
• IOSUhax
• Contenthax/Haxchi
• Contenthax 2.0/FailST
• CBHC
• AROMA/Tiramisu
• SIGN_PATCHER
• MOCHA
• REDNAND

• 
  Sfruttamento di un bug nel browser internet della console da parte del coder yellow8 che permette l'esecuzione di codice in user mode semplicemente visitando con il browser della console un indirizzo appositamente codificato per sfruttare la vulnerabilità. Riadattato nel tempo per renderlo compatibile alle varie versioni di firmware della Wii U.
  
• 
  Il coder JumpCallPop sfrutta l'exploit JSTypeHax sostituendolo alla pagina iniziale del browser permettendo l'avvio di codice arbitrario tra cui MOCHA, Haxchi o altro; la procedura di installazione va eseguita 1 sola volta dopodichè basterà avviare il browser per eseguire l'homebrew desiderato da copiare in SD:/wiiu/apps/homebrew_launcher. Testato e funzionante dal fw 5.5.2 al 5.5.4. Se qualcosa dovesse andare storto nella sua installazione ci si taglierebbe completamente fuori da una possibile sofmod in quanto si andrebbe a rendere non più funzionale il browser web, attualmente unico punto di accesso ad una catena di exploit funzionanti (Indexiine compreso); in questo malaugurato caso la WiiU continuerà comunque a funzionare avviando titoli originali ma non disporrà più di un web browser funzionante.
  
• 
  Custom firmware creato da Smealum che non rilasciò i sorgenti finchè il team "wiiudevs" (composto sostanzialmente da dimok, kanye_west, wj44, FIX94 e Maschell) non riuscì ad ottenere l'IOSU kernel exploit. Si tratta di un completo hack del fw.img della Wii U con accesso tramite console a riga di comando e patches per il bypass delle firme già codificate. Il fw.img patchato con l'IOSUhax andava copiato nella scheda SD e da lì avviato.
  
• 
  Questo exploit è reso possibile grazie al fatto che, all'avvio di un titolo, la console non verifica i dati già installati all'interno della cartella \content; questo permette di aggiungere a tale cartella dati arbitrari da poter richiamare con codice specifico. Da questo "difetto" è nato Haxchi, che va appunto a modificare i dati dell'header di una ROM originale NDS per far eseguire alla console il codice desiderato.
  
• 
  Questo exploit, scoperto dai devs Maschell e rw-r-r-0644, sfrutta il mancato controllo sul file title.fst presente nella cartella /code, che rappresenta una copia del File System Table dell'installazione del titolo.
  
• 
  Cold Boot HaxChi (CBHC) sfrutta, in modo identico al contenhax, il mancato controllo di eventuali modifiche al file /slc/vol/system/config/system.xml il quale contiene all'interno una stringa con il primo titolo da avviare quando si accende la console (che normalmente è il System Menu); cambiando questa stringa con il valore del titolo di un gioco NDS patchato con Haxchi si può ottenere quello che si chiama un "Coldboot Hax" e cioè un hack che non ha bisogno di nulla per avviarsi, basta accendere la console perchè è già integrato nel sistema.
  
• 
  L'exploit isfshax porta all'annuncio pubblico di "Aroma", un ambiente di sviluppo per homebrews creato dal dev Maschell in grado di utilizzare un nuovo formato chiamato .WUHB con il quale includere in un unico file tutto il necessario per eseguire un programma non ufficiale e renderlo disponibile direttamente dalla dashboard ! Aroma puà essere installato all'interno del canale "Salute e Sicurezza" bypassando la necessità del browser exploit per eseguirlo e dal suo menu se ne può impostare l'avvio in cold boot !
  
  Nel tempo questo sistema si è trasformato sfruttando FailST ed Aroma ha preso il nome ti Tiramisu che è stato ufficialmente rilasciato il 1 Gennaio 2022.
  
• 
  Homebrew da avviare previo IOSU kernel exploit per bypassare diversi sistemi di sicurezza della console tra cui la verifica delle firme digitali e la regione. Reso sostanzialmente obsoleto dall'avvento di MOCHA.
  
• 
  Il primo custom firmware "al volo" per Wii U che non encessita più di un file fw.img patchato perchè applica le patches direttamente al fw.img direttamente in memoria ! Inoltre è migliore delle semplici sign_paches perchè prevede anche una console ftp ed una console a linea di comando (wupserver) per comunicare con la console da PC come l'IOSUHax. Permette inoltre di dumpare tutte le memorie interne di Wii U.
  
• 
  Il reindirizzamento della memoria interna della Wii U su scheda SD è stato il primo approccio per evitare di brikkare in caso di errori o "smanettamenti" non previsti ma fu presto abbandonato quando fu disponibile un metodo più stabile e privo di rischi di brick per avviare homebrew (es. sign_patcher o haxchi); accedere infatti alla scheda SD da dove la NAND reindirizzata risiedeva determinava troppo spesso la corruzione della stessa e visto che ricrearla o ripristinarla da un dump era operazione lunga questo sistema venne abbandonato da diversi utenti (la frequente corruzione potrebbe essere dovuta sia al cattivo codice di gestione del IOSUHax ma anche dalla scarsa qualità di alcune schede SD).
  

DECRIPTARE ED INSTALLARE TITOLI eShop

Il ticket ottenuto scaricando un gioco originale eShop contiene la key AES che, decriptata con la Wii U Starbuck Common Key, produce la key necessaria a decriptare il medesimo titolo. Ottenendo l'accesso ai tickets della console (cartella /vol/system_slc/rights/ticket/apps/) attraverso l'IOSU exploit si possono estrarre le keys criptate, scaricare il titolo dai server Nintendo (NUS) in forma criptata e decriptarlo tramite queste keys criptate. Tali keys possono essere utilizzate anche per installare il titolo nella console ma essendo la firma RSA del ticket generata per console specifica tale titolo non potrà essere installato nè avviato in consoles diversa da quelle di provenienza se non si sono prima attivate le patches alle firme.

DECRIPTARE ED INSTALLARE TITOLI DISCO (alias: METODO "BRAZIL")

Il ticket contenuto all'interno di un disco originale (cartella /vol/storage_odd_tickets/) contiene la key AES che, decriptata con la Wii U Starbuck Common Key, produce la key necessaria a decriptare il medesimo titolo scaricato in formato digitale dal NUS. Il ticket contiene inoltre la firma RSA originale NON specifica per console di conseguenza utilizzandolo si possono installare ed avviare giochi nella console senza alcun bisogno di patches, come se fossero stati acquistati in originale !
All'inizio, utilizzando il tool CDecrypt di Crediar, la decodifica non avveniva con successo a causa di un piccolo bug nel programma quindi si pensava che questa procedura non funzionasse; un gruppo di brasiliani ebbe in qualche modo l'intuizione di modificare 1 solo byte all'interno del ticket per correggere il piccolo bug del programma di Crediar... risultato ? METODO BRAZIL ! Il sistema fu poi "affinato" grazie al sottoscritto e successivamente Crediar corresse tale bug.
Il ticket è necessario per installare il titolo nella console ma tale forma di "riciclo" dello stesso a scopi pirateschi non era stata prevista da Nintendo.
Prima della possibilità di utilizzare l' IOSUhax per dumpare i dischi WUD in forma criptata con allegata la key AES per decriptarli era necessario collegare il drive ad un PC ed inviare comandi proprietari sia per dumpare i dati che per ottenere la key.

HACKING DEL GAMEPAD

Anche il GamePad della console è stato oggetto delle attenzioni degli hackers i quali sono stati in grado sia di:
- dumparne direttamente il firmware via hardware (ad opera del reverser Brandon Wilson)
- reversarne le funzioni e renderlo utilizzabile sul PC (sviluppatori del emulatore Dolphin; probabilmente trattasi di boot0, delroth e shuffle2); cliccare lo spoiler per vederli (manca boot0 e shuffle2 assomiglia tanto a plutoo...)

Spoiler

MODALITA' vWii

La Wii U ha una retrocompatibilità hardware con la Wii di conseguenza tutto ciò che è stato sviluppato per la Wii è stato riadattato (compreso il cIOS d2x di Davebaol) per la modalità Wii virtuale chiamata vWii; gli unici homebrew che non è stato possibile riadattare sono quelli che agivano sul System Menu (quindi Priiloader, temi, ecc) in quanto, come dicevamo all'inizio, questo è criptato (file \slccmpt01\title\00000001\00000002\content\00000023.app). E'possibile decriptarlo dato che la vWii ancast key necessaria per la sua decodifica è stata diffusa ma nessuno si è ancora ufficialmente cimentato nell'opera; inoltre con tutta probabilità per avviare un System Menu modificato e ricriptato servono le patches perchè pare esistere un controllo sulla sua integrità all'avvio.

E'invece possibile modificare la skin del System Menu (contenuta nel file /slccmpt01/title/00000001/00000002/content/00000022.app per le consoles EUR).

E'possibile eseguire una softmod alla modalità vWii senza dover utilizzare un gioco originale; il metodo si chiama WUPHAX ed è stato sviluppato dal coder FIX94. Utilizza l'accesso diretto dello IOSU alle cartelle della modalità vWii senza dover avviare la modalità vWii !

Si possono inoltre risolvere varie forme di brick agendo da IOSU nelle cartelle della vWii senza dover accedere affatto alla modalità vWii !

Se invece volete eseguire la softmod in maniera "classica" per installare HBC utilizzando uno dei 6 giochi originali supportati questa è la guida (il Team Fail0verflow riuscì in questa impresa già il giorno successivo all'uscita della console !).

VIRTUAL CONSOLE HACK/INJECT

I titoli Virtual Console permettono l'avvio di giochi delle vecchie consoles Nintendo (e non solo) attraverso emulatori proprietari. Questi giochi contengono proprio le ROMs dei vecchi titoli. Se volete estrarle per eventualmente sostituirne o modificarne il contenuto qui potete trovare una guida.

I giochi Virtual Console Wii invece utilizzano le ISO dei giochi Wii riconvertite in un formato di files multipli con estensione .NFS, criptati con una key che si trova all'interno del file \code\htk.bin (specifica per ogni gioco vWii) ed hanno i files rvlt.tmd e rvlt.tik corrispondenti ai files tmd.bin e ticket.bin di un disco Wii originale (basta rinominarli). Vengono eseguiti utilizzando il file \code\fw.img che corrisponde all'IOS255. Esiste un tool per la loro riconversione che si chiama nfs2iso2nfs. Una guida sull'argomento si può trovare qui.

CONCLUSIONI

Nell'occasione dell'hacking di Wii U Marcan ha spiegato come sia riuscito, assieme agli altri membri del Team Fail0verflow, ad eseguire codice sul chip Espresso in modo relativamente dettagliato ma ha anche parlato per la prima volta di come, appena uscita la console, era motivato al tentativo di hacking della stessa ma, una volta riuscito, ha perso interesse anche perchè la console era nuova sul mercato e rilasciare subito un exploit poteva danneggiare la casa produttrice. Il Team è da sempre contro la pirateria infatti le informazioni rilasciate furono utili soltanto ai veri hard-coders per cercare di eseguire codice sulla macchina al solo scopo di poter creare librerie e quant'altro per poter lanciare homebrews ! E'inutile dire che il lavoro di ricerca exploit è complicato ma lo è altrettanto creare un "ambiente di sviluppo" non ufficiale con tanto di documentazione dettagliata per homebrew cosa che, a quanto pare, il team non ha avuto voglia di portare avanti; le informazioni infatti sono state rilasciate solo per "veri esperti", come basi dalle quali partire. Nel caso Wii U tutto fu preso in mano dal reverser/coder Smealum il quale per primo creò l'IOSUhax ma non rese pubblico nulla finchè altri devs non riuscirono ad arrivare ad un IOSU exploit. Dalle spalle di questi giganti fa infine capolino il team "wiiudevs" il quale rese applicative tutte le informazioni rilasciate dagli altri reversers.

Nintendo ha davvero imparato dai propri errori stavolta ? In sostanza possiamo dire di si dal punto di vista software vista la discreta solidità della catena dell'affidabilità però abbiamo ora a che fare con qualcosa di nuovo... finora le consoles erano state sottoposte ad hacking di livello software mentre con il passaggio dalla settima all'ottava generazione di consoles sono iniziati a diventare di dominio pubblico dei nuovi exploit, quelli hardware (es. reset hacks per Wii U), che fino ad allora erano appannaggio di super-reversers/devs che avevano a disposizione costose attrezzature ed affinate conoscenze; come abbiamo potuto leggere con il decapping o i tricking utilizzati per dumpare alcune vecchie bootrom (ottenute anche anni dopo la loro uscita in commercio) questi sistemi hanno iniziato a farsi largo tra i veterani della scena del console hacking (il team fail0verflow ha a disposizione addirittura un microscopio a scansione elettronica!) prendendo alla sprovvista le case produttrici di consoles perchè mentre prima erano necessari addirittura anni per venire a capo di protezioni software oggi in alcuni casi queste possono essere bypassate agendo a livello ancora più basso, quello dei chips ! Questa accelerata non fa altro che esporre al pubblico ludibrio le "magagne" software più rapidamente rendendo possibile un hacking già dai primi giorni di rilascio al pubblico dei nuovi prodotti... è un bene ? Certamente no perchè, come ha sostenuto Marcan, non è assolutamente vero che l'hacking di una console aumenta il fatturato dei produttori poichè questi ultimi spesso vendono con lievissimo margine le macchine da gioco (o addirittura in perdita) mentre traggono guadagnano sui giochi e con le royalties dei titoli di terze parti (ed ultimamente anche con gli accounts online a pagamento) quindi la pirateria è sicuramente dannosissima per queste aziende !


Se vi è piaciuta questa la trattazione Wii U restate in attesa del prossimo capitolo della serie... presente o passato ?

 

… l'errore é voluuto... wii... detta anche RVL-001 o Revolution... Riivolution... compris ?

 

Quello dell'usb certamente si perché quando kayne west e dimok ci lavoravano ricordo che l'usb non funzionava per problemi di corruzione; da li parte una rop chain. Trovi la discusdione nel forum di wiiubu.

 

Hai ragione. Correggo e metto si per l'usb module e ? per il kernel. L'altro exploit module valido fino a 5.2.0 non credo sia pubblico.

 

E'tutto spiegato in dettaglio nel forum linkato sopra dove è nato il codice per eseguire sia l'exploit del modulo usb sia la rop chain per ottenere il kIOSU.

Aggiunte immagini e poche info sulle unità di sviluppo.

 

https://www.reboot.ms/forum/threads/le-protezioni-nelle-consoles-raccolta.7383/

Le cose comunque passano di generazione in generazione quindi mi aspetto di vedere nuovi devs all'orizzonte con i "vecchi" comunque sempre pronti a dire la loro.