1. A breve aggiorneremo la piattaforma di Reboot per risolvere alcuni problemi con i plug-in, quindi chiediamo ancora un po' di pazienza, Lo staff di Reboot

LE PROTEZIONI NELLE CONSOLES - NINTENDO Wii

Discussione in 'Discussione generale Wii' iniziata da student, 1 Set 2017.

  1. student

    student Staff Livello 41 Staff

    Iscritto:
    30 Ago 2015
    Messaggi:
    4.081
    Like ricevuti:
    4.207
    [​IMG]
    Dopo aver fatto un salto cronologico in avanti con il DSi per completare il discorso DS, oggi torniamo un pochino indietro nel tempo e parliamo del successore "da salotto" del GameCube, la console Nintendo Wii !

    Questo gioiello esce in commercio nel 2006 e rappresenta il miglior prodotto non portatile in termini di performance di vendite assolute (+101 milioni di unità sparse per il mondo) per la nostra amata azienda giapponese che inizia per N ! Rispetto alle sue competitors dell'epoca, XBOX 360 e PS3, risulta inoltre sempre la migliore in termini di milioni di unità vendute.
    [​IMG]

    In fase progettuale il suo nome iniziale fu "N5" che sta per "quinta console casalinga prodotta da N" per poi passare a quello di "Revolution" (product code RVL-001); la console porta infatti con sè una grandissima rivoluzione videoludica: il controller Wiimote con tutti i suoi "milluplici" accessori (vari esempi nello spoiler):
    [​IMG]
    oggetto che ha seriamente Riivoluzionato il modo di giocare in casa e che sfrutta sia il sistema di puntamento infrarossi che la connettività bluetooth !

    Inoltre la console dispone di uno slot SD e... di porte USB mantenendo la retrocompatibilità con i dischi GameCube (almeno fino all'uscita dell'hardware revision chaiamta RVL-101 dove vennero rimosse alcune componenti che resero la console non più retrocompatibile).

    Inoltre è la prima console Nintendo a fare uso del WiFi per la connettività ad internet e l'accesso gratuito al servizio Wi-Fi Connection (WFC), connessione in grado di collegarsi anche alle sorelline portatili DS e DSi che potevano essere addirittura utilizzate come controller.

    Preparatevi perchè, dopo un inizio che probabilmente vi sarà già in gran parte noto riguardo i dischi proprietari, ci sarà MOLTO da divertirsi !


    SISTEMI DI PROTEZIONE


    FORMATO DISCO PROPRIETARIO

    I dischi Wii sono DVD di 12 cm con capacità di 4.7 GBs (single layer) e 8.5 GBs (dual layer); vengono chiamati "WOD" che sta per "Wii Optical Discs" e furono prodotti dalla Panasonic. Sul finire del 2006 ci fu un accordo tra Nintendo e SNIC (Sonic Solutions) per una versione della console capace di leggere anche i normali DVD da rilasciare nell'anno successivo ma questo progetto non vide mai la luce del sole. Esistono, come per il GameCube, alcuni drives per PC in grado di leggere correttamente questi dischi dotati di uno specifico microcontrollore Hitachi (vedi spoiler sottostante):
    LG GH20NS15
    Optiarc DVD RW AD-7203A
    PHILIPS DVD+RW SDVD8441 PA48 IDE (GC only)
    GDR-3120L (dentro alcune vecchie xbox360)
    HL-DT-STDVD-ROM GDR8082N0L03
    HL-DT-STDVD-ROM GDR8082N0007
    HL-DT-STDVD-ROM GDR8082N0010
    HL-DT-STDVD-ROM GDR8082N0C07
    HL-DT-STDVD-ROM GDR8082N0120
    HL-DT-STDVD-ROM GDR8082N0106
    HL-DT-STDVD-ROM GDR8161B0042
    HL-DT-STDVD-ROM GDR8161B0043
    HL-DT-STDVD-ROM GDR8161B0100
    HL-DT-STDVD-ROM GDR8161B0102
    HL-DT-STDVD-ROM GDR8162B0015
    HL-DT-STDVD-ROM GDR8162B0018
    HL-DT-STDVD-ROM GDR8163B0D20
    HL-DT-STDVD-ROM GDR8163B0B26
    HL-DT-STDVD-ROM GDR8163B0L23
    HL-DT-STDVD-ROM GDR8164B0B07
    HL-DT-STDVD-ROM GDR8164B0L06
    HL-DT-STDVD-ROM GDR8164B0B10
    HL-DT-STDVD-ROM GDRH10NB0B10
    HL-DT-STDVD-ROM GDRH10NB0F03


    STANDARD QUASI-DVD

    Come per il GameCube i dati di questi dischi sono memorizzati secondo uno standard molto simile a quello dei DVD ma con alcune differenze proprietarie:

    1 - la sezione dati di questi dischi utilizza un metodo di scrambling diverso dallo standard descritto nel documento ECMA DVD Specifications producendo dunque un "offuscamento" dei dati memorizzati;
    2 - il Data Frame Layout è diverso da quello standard;

    Questi 2 stratagemmi proteggono dalla copia "brutale" effettuata dagli utenti comuni ma con hardware professionale sarebbe ancora possibile riprodurre una copia 1:1. Ecco che entra in scena la vera protezione "fisica" di questi straordinari supporti.


    LA PROTEZIONE DA COPIA BCA... PROPRIETARIA !

    [​IMG]
    Come per il GameCube anche i dischi Wii hanno la Burst Cutting Area (BCA). Leggere lo spoiler sottostante per ulteriori info (praticamente identiche al GameCube):
    La BCA è quell'area di un qualsiasi disco, visibile ad occhio nudo, compresa tra il raggio 22.3±0.4 mm ed il raggio 23.5±0.5 mm che puo'opzionalmente contenere informazioni incise tramite hardware dedicato (un laser YAG) e leggibile da normali laser dei lettori a cui tuttavia non tutti i lettori DVD sono in grado di accedere perchè necessitano di una circuiteria dedicata. Quest'area di 188 bytes nei dischi Wii contiene 2 parti:
    - una encrypted table di 124 bytes utilizzata nella protezione (leggere poco più sotto)
    - 64 bytes non criptati
    I dati della encrypted table vengono decriptati direttamente dal firmware del lettore ottico ed una volta in chiaro si ottiene una cosa a mio avviso strabiliante: 6 valori precisi che, se analizzati nel modo giusto, scopriamo rappresentare la posizione fisica nel disco di qualcosa... e se andiamo a curiosare proprio in quelle posizioni cosa troviamo ? Altrettante "incisure" scritte presumibilmente con lo stesso metodo del BCA però questa volta all'interno dell'area dei dati ! Questi piccoli "tagli" sono chiaramente visibili se il disco è tenuto davanti a una forte sorgente luminosa come potete vedere nell'immagine qui sotto (presa da un disco Wii: funziona nello stesso modo) con relativo ingrandimento di dettaglio su una di queste 6 "tacche" (un'altra è visibile in alto a sinistra nella porzione di immagine non zoomata):
    [​IMG]
    Il sistema è stato reversato da tmbinc, reverser di grande talento in grado di produrre questo mirabolante articolo dove vengono spiegati i minimi dettagli della protezione; ricordo che questo mostro di bravura lo ritroveremo nelle file del team Twiizers che fu di grande impatto nella "scena" per quanto riguarda l'hacking Wii !


    REGION CHECK

    All'interno delle immagini .ISO dei giochi Wii la regione è codificata in 2 offsets:
    [​IMG]
    All'offset 0x003 abbiamo l'ID del gioco che contiene la lettera della regione:
    44 - D (GER)
    45 - E (USA)
    46 - F (FRA)
    49 - I (ITA)
    50 - P (PAL)
    4A - J (JAP)
    4B - K (KOR)
    52 - R (RUS)
    53 - S (SPA)
    54 - T (TWN)
    55 - U (AUS)

    All'offset 0x4E003 del disco è invece memorizzato il country code/codice regione:
    00 - JAP
    01 - USA
    02 - PAL
    04 - KOR


    LETTORE ANTIMOD

    [​IMG]
    Il lettore della Wii ha subito varie modifiche nel corso degli anni. A seconda delle caratteristiche del controller e delle revisioni dell'hardware era o meno possibile installare specifici modchip per bypassare alcune protezioni (vedi più avanti).
    Ecco la lista dei controller chip identificati all'interno dei lettori ottici Wii:
    GC2-D2A
    GC2-DMS
    GC2-D2B
    GC2-D2C
    GC2-D2C2
    GC2-D2E
    GC2-D3
    GC2-D3-2
    GC2-D4
    GC2R-D2A
    Per ulteriori dettagli e per comprendere il metodo per capire se siano o meno antimod leggere la sezione dedicata più in basso. Per scoprire con che probabilità la vostra console ha un lettore antimod andate qui (il sito si basa sul seriale della console).


    WII CHAIN OF TRUST

    La catena dell'affidabilità prevede che le manovre necessarie per "accendere" l'hardware ed il sistema operativo della Wii siano "sicure"; tale processo di avvio inizia dal boot0, porzione di codice che risiede dentro ad un chip chiamato Hollywood e che NON puo'essere scritta, ma solo letta. Il boot0 carica il boot1, che si trova all'inizio dei blocchi della NAND Wii; il boot1 carica allora il boot2 che si trova in una porzione di NAND indipendente dal file system. Il boot2 carica infine l'IOS del System Menu il quale carica il primo file del System Menu che rappresenta l'interfaccia grafica del desktop Wii a cui tutti siamo abituati:
    [​IMG]

    Vediamo questa catena nel dettaglio:


    • BOOT 0
      - Dove si trova: dentro al chip Starlet (a quanto pare chiamato "Viper" dai programmatori Nintendo) in una "Mask ROM" Macronix di 4Kb che a sua volta è contenuta nel chip Hollywood; (non si conosce l'esatta locazione dello Starlet all'interno dell'Hollywood ma qui sotto potete vedere una sua foto in cui è privo della copertura metallica, la freccina indica la SEEPROM, vedere oltre per la sua spiegazione):
      [​IMG]
      ('il membro del Team Twiizers sven pensa che uno dei due chip qui sopra sia lo starlet forse insieme alla GPU (probabilmente quello quadrato) mentre l'altro, quello rettangolare, è il DSP).
      Il chip di cui sopra decappato dall'allora flylogic (attuale IOActive) appare così:
      [​IMG]
      Il codice del boot0 è stato dumpato direttamente dalla memoria utilizzando un boot2 modificato, con una funzione scritta in C (dal coder chiamato tmbinc... a volte ritornano :wink: ), che appunto dumpa la memoria, nella quale, al momento dell'esecuzione del boot2, boot0 è ancora presente e quindi leggibile e copiabile.
      - Dimensioni: 1.300 bytes (1.3 Kb - di 4 Kb complessivi disponibili nella Mask ROM)
      - Funzioni principali: contiene il codice per leggere le prime 48 pagine della NAND, le decripta con una chiave AES fissa, genera le hashes utilizzando l'algoritmo SHA1 e compara queste hashes con un valore letto dalla dalla memoria OTP (una memoria di 1Kb, programmabile una sola volta, che risiede all'interno dell'Hollywood): se il valore non corrisponde la console non parte. Se il valore delle hashes nella OTP è di tutti 0000 il sistema parte lo stesso ma questo valore sembra sia presente soltanto nelle console degli sviluppatori ed eventualmente durante il processo di produzione.
      In sostanza quindi il boot0 ha relazioni con:
      - OTP storage area (da cui "pesca" le hashes del boot1 per poi compararle con il boot1 stesso - scritta in fase di produzione, risiede nel chip Hollywood);
      - Controller NAND (per leggere il boot1 criptato)
      - motore AES (per decriptare il boot1)
      - SRAM (dove viene copiato il boot1 decriptato)
      - motore SHA (per autenticare il boot1)
      - Versioni: sembra ne esistano 2, identificabili a seconda che si abbia un chip marchiato HOLLYWOOD oppure HOLLYWOOD AA:
      [​IMG]
      bushing sospetta una ulteriore versione del chip, la HOLLYWOOD A ma questa revision del chip Hollywood non è mai stata trovata all'interno delle consoles esplorate.
      Ecco un suo recente deccaping ad opera di Marcan (gennaio 2016):
      [​IMG]
      (Marcan si chiede dove sia l'OTP... che non sia effettivamente qui dentro ?)

    • BOOT 1
      - Dove si trova: nei primissimi bytes della NAND - da 0x0 a 0x4A7F (indicativamente poichè ne esistono varie versioni) - è criptato con l'algoritmo AES utilizzando una chiave fissa. Dal boot0 viene generato un hash utilizzando l'algoritmo SHA1 e questo viene poi verificato con il valore salvato nella OTP. Il boot1 quindi puo'essere modificato in fase di produzione e le nuove Wii possono montare una nuova versione del boot1 ma non è possibile aggiornarlo o modificarlo una volta uscite dalla fabbrica.
      - Dimensioni: circa 19.071 bytes (di 96Kb effettivamente disponibili).
      - Funzioni principali: inizializza la RAM DDR dopodichè carica il boot2, lo decripta e lo verifica tramite algoritmo RSA.
      - Versioni: al momento sembra ne esistano solo 5 che sostanzialmente differiscono tra loro per il modo in cui gestiscono la DDR. Nel tardo 2008 Nintendo ha rilasciato una versione del boot1 (boot1c) che non permette di modificare il boot2 senza ottenere un brick (consoles nelle quali il BootMii puo'essere installato soltanto come IOS). Il boot1 contiene una funzione di verifica che è in grado di capire se il boot2 viene downgradato (confrontando la versione scritta nel file .TMD con quella presente nella SEEPROM (riprogrammabile dunque, diversa dalla OTP, ed anche essa risiede nell'Hollywood; le sue dimensioni sono di 2Kb e comunica con interfaccia seriale) e se lo trova INFERIORE la Wii non parte ed il boot1 invia il codice di errore 10).
      Nella immagine sopra potete vedere la posizione della SEEPROM (freccina viola) mentre qui sotto il suo "decapping":
      [​IMG]
      Sfortunatamente il boot1 non ha un vero e proprio numero di versione identificabile codificato all'interno (come nel caso del boot2) nè tantomeno una data di rilascio scrtta internamente, dunque le varie versioni sono state chiamate come segue a seconda del momento temporale in cui sono uscite a partire dalla lettera a (in rosso le versioni che NON permettono di installare BootMii come boot2):

      boot1a: dimensione: 0x42c0 - hash: B3C32B962C7CD8ABE33D15B9B8B1DB197544 presente nelle Wii più vecchie; non comune
      boot1b: dimensione: 0x4320 - hash: EF3EF781968D56DF5679A6F92E13F78BBDDFDF versione più comune dal momento del lancio della console sul mercato
      boot1c: dimensione: 0x4400 - hash: D22C8A486C631DDF5ADB3196ECBC66878CC8D prima versione con il bug strncmp corretto; apparentemente vista per la prima volta nel 2008
      boot1d: dimensione: 0x4840 - hash: F793068A09E80986E2A023C0C23F06140ED16974 ?

      un modo per capire INDICATIVAMENTE la versione del boot1 sembra essere quello di leggere il "date code" sul chip Hollywood come indicato in figura:
      [​IMG]
      se questo risulta essere inferiore a 0830 (che corrisponde alla 30esima settimana del 2008) allora ci sono buone possibilità che la Wii contenga un boot1a o boot1b (entrambi vulnerabili).

    • BOOT2
      - Dove si trova: è localizzato nella NAND tra gli offset 0x21000 e 0x108000 ed è salvato come un .WAD ma leggermente modificato nella struttura.
      - Dimensioni: circa 1.1 Mb
      - Funzioni principali: lancia il System Menu in fase di boot; decide inoltre se lanciare il System Menu oppure il MIOS a seconda di un valore di registro che, se impostato (operazione fatta da BC - BC significa probabilmente "Backward Compatibility" ed e'un programma caricato nella NAND della wii che serve a lanciare i giochi gamecube), rallenta la velocità di clock del chip Hollywood: se il boot2 trova la velocità abbassata lancia MIOS, altrimenti lancia il System Menu. [Inserendo un gioco GameCube il percorso è il seguente: System Menu (trova un gioco gamecube) :arrowright: BC rallenta la velocità di clock :arrowright: boot2 trova il clock ridotto :arrowright: MIOS/gc mode].
      - Versioni: la versione del boot2 è reperibile in chiaro all'offset 0x21EE0 del file NAND.BIN come mostrato in questa immagine; al momento sembrano esistere boot2v1 (tuttavia mai trovata), boot2v2, boot2v3 e boot2v4.

      Il boot2 puo'essere modificato (installandoci BootMii) se abbiamo una Wii con boot1 affetto dal bug strncmp (versione a e b) secondo questo percorso: boot2, come tutti gli IOS con numerazione precedente la 30, e'costituito da 3 "porzioni" (se vogliamo essere tecnici le 3 parti sono: l'intestazione o header, un loader (per la terza porzione che serve solo a caricare questa terza parte in memoria) e la terza porzione che e’in formato ELF; questa terza parte contiene il codice vero e proprio del boot2, che e’scritto come il codice degli altri IOS Wii. Dal boot2 viene poi caricato l'IOS del System Menu che varia a seconda della versione del firmware.

    • Contenuto dell'OTP:

      boot1 hash: 0x100 (20 bytes) [fondamentale valore per capire che versione di boot1 si ha installata]
      Common key (AES): 0x114 (16 bytes)
      Console ID: 0x124 (4 bytes)
      ECC Private Key: 0x128 (30 bytes)
      NAND HMAC: 0x144 (20 bytes)
      NAND AES key: 0x158 (16 bytes)
      PRNG seed (AES): 0x168 (16 bytes)


      Contenuto principale della SEEPROM:

      La SEEPROM contiene i seguenti importanti dati:
      ng_key_id: 0x208 (4 bytes)
      ng_sig: 0x20C (60 bytes)
      boot2version

    • IOS
      L'IOS, termine che forse significa "InputOutpuSystem" è un sistema operativo che viene eseguito dallo Starlet (coprocessore che si trova dentro al chip Hollywood). Le caratteristiche degli IOS sono molteplici, cercherò di riassumerle al meglio.

      - I vari IOS contengono i "servizi" o "moduli" (open/close/read/write/ecc.) utilizzati dalla Wii per avere accesso alle periferiche di sistema.
      - Ogni IOS è "a se stante" e tutti quanti sono indipendenti gli uni dagli altri e non vengono MAI utilizzati a meno che un programma non ne richieda lo specifico utilizzo; questo fa si che l'installazione, o le patch, degli IOS sia relativamente senza rischi (a patto che questi non siano gli IOS utilizzati dal System Menù!!!) poichè se si dovessero corrompere possono sempre essere reinstallati senza che nel complesso il sistema venga danneggiato; inoltre quando sono in esecuzione sono INDIPENDENTI dal System Menù (il pulsante "Home" premuto all'interno del gioco produce una schermata "come quella" del System Menù ma in realtà è codificata dentro al gioco); in sostanza non è il System Menù che sta alla base del sistema: quando un gioco viene infatti lanciato il System Menu viene CHIUSO e quando si esce dal gioco questo richiama il System Menu.
      - Gli IOS risiedono nella NAND ed il numero di IOS va da 0 a 255 a seconda dello slot occupato nella memoria (viene chiamato "IOS Number"); probabilmente il numero degli IOS utilizzati nei videogames o negli applicativi .WAD rappresenta la versione delle SDK che Nintendo fornisce agli sviluppatori per produrre i giochi/programmi (es. se viene fornita l'SDK v58 esisterà un IOS58.
      Come funzionava lo sviluppo di un gioco con gli IOS ?
      il processo funzionava cosi: gli sviluppatori mandavano a Nintendo le specifiche del suo gioco e Nintendo inviava loro l'SDK relativo con tanto di TMD, ovvero di file che indicava quale era l'IOS da utilizzare.
      - Ogni IOS ha un "IOS Version Number" che è scritto nel file tmd contenuto all'interno dell'IOS stesso.
      - Ogni IOS Version Number puo'essere a sua volta convertito nel valore chiamato "Minor" convertendo il Version Number stesso in esadecimale, separando al centro, con un punto, il valore ottenuto e riconvertendo le 2 parti di nuovo in decimale; es. v6687[decimale] :arrowright: 1A1F[esadecimale] :arrowright: 1A.1F :arrowright: 26.31.
      - Puo'essere esguito UN SOLO IOS ALLA VOLTA !
      - Un IOSmothballed è sinonimo di IOS stub = un IOS che non contiene funzioni, ha solamente il modulo kernel mentre mancano tutti gli altri moduli tipici di un IOS funzionante; gli IOS stub possono essere rimossi e rimpiazzati con altri IOS.
      - Non si puo'effettuare un downgrade di un IOS senza PRIMA aver cancellato la versione più recente (mentre l'upgrade si puo'fare anche senza cancellare).
      - Il solo ed unico momento in cui un IOS non è in esecuzione nella Wii è durante la modalità GameCube dove al posto dell'IOS è eseguito il MIOS, oppure quando Bootmii è in esecuzione dove al posto di un IOS è eseguito "mini".

      Un elenco di tutti gli IOS rilasciati da Nintendo lo potete trovare qui.

    • SYSTEM MENU
      [​IMG]

      Alla fine della sequenza di boot appare la scritta "premere A" durante l'Health Screen: questa è la prima cosa che l'utente finale "vede" dopo l'accensione della console (ovviamente in Wii non modificate) ed anche essa fa parte del System Menu.

      - Dove si trova: Il System Menu è contenuto all'interno della NAND nella cartella /00000001/00000002
      - Dimensioni: variano a seconda della versione, indicativamente tra i 42 ed i 45 megabytes.
      -
      Funzioni principali: La sua funzione principale è quella di avviare i giochi da dischi ufficiali certificati Nintendo, lanciare canali, Wiiware e Virtual Console sempre certificati Nintendo.
      Svolge un ruolo di primo piano durante lo startup, lo spegnimento e durante le transizioni di stato del sistema; appena avviato, la funzione main() del System Menu va a leggere i seguenti files:
      /title/00000001/00000002/data/setting.txt
      /title/00000001/00000002/data/state.dat
      /shared/sys2/NANDBOOTINFO
      /title/00000001/00000002/data/cache.dat
      a seconda di cio'che viene letto dalla funzione main() (e probabilmente da altri valori flag impostati in memoria) il System Menu puo'eseguire le seguenti operazioni:

      - Bloccarsi (brick! Recuperabile solo se si ha BootMii installato come boot2 o priiloader)
      - Lanciare un titolo disco direttamente da cache.dat
      - Spegnere il sistema dalla modalità GameCube
      - Espellere un disco e poi spegnere la console (se è stato premuto il tasto Eject)
      - Andare in modalita' "idle" (Abilita il WC24, arresta il PPC)
      - Avviare una applicazione NAND dal WC24
      - Entrare in modalita' "Recovery" (detta anche "IRD mode")
      - Mostrare l' "Health" / "Warning" screen ed avviare la console normalmente

      - Versioni ed IOS di appoggio:
      System Menu 1.0 :arrowright: utilizza IOS9
      System Menu 2.0 :arrowright: utilizza IOS11 v10
      System Menu 2.1 :arrowright: utilizza IOS11 v10
      System Menu 2.2 :arrowright: utilizza IOS20 v12
      System Menu 3.0 :arrowright: utilizza IOS30 v1039
      System Menu 3.1 :arrowright: utilizza IOS30 v1039
      System Menu 3.2 :arrowright: utilizza IOS30 v1039
      System Menu 3.3 :arrowright: utilizza IOS30 v2576
      System Menu 3.4 :arrowright: utilizza IOS50 v4889
      System Menu 3.5 :arrowright: utilizza IOS52 v5661 (apparentemente rilasciato soltanto per le wii Coreane)
      System Menu 4.0 :arrowright: utilizza IOS60 v6174
      System Menu 4.1 :arrowright: utilizza IOS60 v6174
      System Menu 4.2 :arrowright: utilizza IOS70 v6687
      System Menu 4.3 :arrowright: utilizza IOS80 v6943

      Per sapere nel dettaglio quali sono le differenze tra i vari System Menu potete andare qui mentre per vedere quali sono stati tutti i titoli modificati in ogni nuova versione del firmware andate qui.

      Per avviare il System Menu il boot2 legge il file .TMD del System Menu (che è un file chiamato tmd.xxx dove xxx = versione del firmware/System Menu, vedi piu'in basso), da questo file legge su quale IOS si appoggia e carica questo IOS. Tale IOS appena caricato a sua volta carica il System Menu in memoria leggendolo dalla NAND ed infine accende il PPC e lo manda in esecuzione.

      Non è dunque il System Menu "alla base del sistema": quando un gioco o un applicativo viene infatti lanciato il System Menu viene CHIUSO e quando si esce dal gioco questo richiama il System Menu (il pulsante "Home" premuto all'interno di in gioco/applicazione produce una schermata "come quella" del System Menu ma in realtà è codificata dentro al gioco e di fatto NON è il System Menu !!!)

      Quando viene avviato un canale, viene letto il TMD dello stesso (sia esso su disco o presente su NAND), l'IOS del System Menu ricarica (IOS_Reload) questo nuovo IOS e quest'ultimo carica il gioco dalla NAND (oppure il disco) in RAM; viene ora avviato il PPC.

      In fase di avvio, il boot2 puo'decidere se lanciare il System Menu oppure MIOS a seconda di un valore di registro che, se impostato (operazione fatta da BC - BC significa probabilmente "Backward Compatibility" ed è un programma caricato nella NAND della Wii che serve a lanciare i giochi gamecube), rallenta la velocità di clock del chip Hollywood: se boot2 trova la velocità abbassata lancia MIOS, altrimenti lancia il System Menu.

      Inserendo un gioco GameCube nella Wii il percorso è invece il seguente: System Menu (trova un gioco gamecube) :arrowright: BC rallenta la velocità di clock :arrowright: boot2 trova il clock ridotto :arrowright: avvio MIOS/gc mode.

      In sostanza la sequenza di boot "canonica" è questa: boot0 :arrowright: boot1 :arrowright: boot2 :arrowright: IOS relativo al system menu installato (IOS30, IOS50, IOS60 oppure IOS70 a seconda della versione del System Menu) :arrowright: primo file dol del System Menu.



    DATI CRIPTATI E KEYs

    PROGRAMMI
    Tutti i programmi Wii (Channels, Gioci, WiiWares, titoli di sistema) prendono il nome di "titles"; ogni titolo ha:
    - un suo TitleID univoco che lo identifica;
    - un file Title MetaData (TMD) che firma e descrive il contenuto del pacchetto di installazione del titolo (al suo interno contiene le SHA-1 hashes del contenuto, i dati sui permessi, il group ID e le informazioni sul region locking);
    - un eTicket che rappresenta la licenza specifica (che puo'essere anche specifica per singola console), necessaria per utilizzare il titolo; contiene la key AES criptata utilizzata per decriptare i dati del titolo durante l'installazione - tale key viene decriptata con la Common Key; puo'contenere una "scadenza temporale" per l'esecuzione del titolo installato.

    Sia TMD che eTicket sono firmati con una key RSA-2048 proprietaria Nintendo.

    GIOCHI SU DISCO
    I dati memorizzati sui DVD proprietari sono suddivisi in partizioni (di update e di gioco) e sono criptati con una key AESassieme ad una key presente nell eTicket; ogni blocco viene inoltre "hashato" attraverso SHA-1 ed esiste un hash tree che fa capo ad un "master hash" per la corretta verifica del contenuto; la firma risiede nel file TMD mentre la key di criptazione.


    La Wii contiene dunque diverse keys che possiamo suddividere in 2 categorie:


    • Le KEYs AES utilizzano l'algoritmo AES-128-CBC, servono a "nascondere" i dati e sono contenute all'interno della console ed alcune sono condivise tra le consoles. Le più famose sono:

      - Common Key: chiave condivisa, dumpata attraverso il Twiizer Attack (vedi più avanti), è utilizzata per criptare la key AES dei titoli installati; tali dati criptati sono salvati in un file ticket. E'memorizzata nella OTP.
      - SD Key: chiave condivisa, è utilizzata dal System Menu per criptare ogni dato scritto nella SD, savegames inclusi. E'memorizzata anche essa nella OTP.
      - NAND Key: diversa per ogni console, è utilizzata per criptare il contenuto della NAND; è con tutta probabilità generata durante il processo di costruzione della console. Anche lei è salvata nella OTP.


    • Le KEYs RSA invece sono diverse dalle keys AES perchè utilizzano una cifratura di tipo asimmetrico e quindi non hanno "segreti condivisi" quindi non possono essere estratte dalla Wii perchè non le contiene; l'unica cosa che la Wii contiene sono le keys pubbliche, utilizzate per verificare l'autenticità dei dati criptati con questo algoritmo. Le principali sono:

      - CP (Content Protection?): utilizzata per firmware i files .tmd. Il suo bypass è stato possibile grazie alla scoperta del Trucha Bug (vedi più avanti).
      - XS (Access?): firma i tickets che contengono le keys di ogni titolo
      - CA: firma sia la key XS che la key CP
      - MS (Master?): firma il certificato della chiave pubblica ECC della Wii; questo certificato è poi attaccato ai salvataggi di gioco nella SD.
      - Root: firma la key CA



    PROTEZIONI DEI GIOCHI SINGOLI

    Alcuni giochi hanno un problema di esecuzione che spesso si traduce in un errore che parla di una fantomatica "metafortress" oppure semplicemente si bloccano, di solito all'inizio dell'esecuzione di un video. Questi giochi sono protetti dalla protezione chiamata METAFORTRESS prodotta dalla software house Metaforic (acquisita dalla inside security nel 2014). In pratica questa protezione è in grado di capire se il codice originale è stato modificato dando dunque problemi che spesso si verificano DURANTE l'esecuzione del gioco (il quale nella maggior parte dei casi parte ma poi si blocca sempre negli stessi identici punti). Per evitare questo problema l'importante è NON APPLICARE alcuna modifica al gioco all'interno del Backup Loader il che significa lasciare le opzioni di default del gioco stesso (lingua, regione, fix, video e quant'altro - alcune le potete leggere nella copertina del gioco stesso); inoltre NON SI DEVONO ABILITARE I CHEATS nel loader altrimenti anche questo porta la protezione a percepire delle modifiche. I giochi che presentano questo tipo di protezione sono:

    Arthur and the Revenge of Maltazard - NTSC
    Driver: San Francisco - all regions
    Hollywood Squares - PAL
    Kirby - all regions
    My Fitness Coach: Club (A.K.A. Fit in Six)
    Racket Sports Party
    The Amazing Race - PAL
    We Dare - PAL
    Smurfs Dance Party - all regions
    Tin Tin - all regions?
    Tony Hawk: Shred
    U-Sing 2
    Your Shape
    Prince of Persia - The Forgotten Sands

    Alcuni titoli (UbiSoft in particolare, come TinTin o Prince of Persia) hanno una ulteriore protezione che capisce se c'è in memoria un loader che ha avviato il gioco e, se lo trova, nel momento del controllo, lo blocca; questo è un grosso limite perchè questa protezione aggiuntiva è protetta dalla Metafortress rendendo decisamente difficile il suo superamento (ogni patch della protezione aggiuntiva è vista come modifica da metafortress che quindi blocca il gioco); per ora il metodo sicuro per avviare questi backup è avere una Wii con lettore che supporta i DVD-backup oppure sistemi come il Wode che trasformano una periferica esterna in un drive per Wii: in questo modo infatti la protezione ulteriore non percepirà un loader perchè il gioco viene avviato dal canale disco ufficiale.

    Questo genere di protezione è decisamente avanzata e permette di proteggere ogni singolo gioco in maniera unica in modo tale che, una volta capito il suo funzionamento, questo valga solo ed esclusivamente per il gioco in questione ma non possa essere applicato ad altri rendendo il suo superamento scarsamente prevedibile e quindi decisamente time-consuming per chi cerca di aggirarlo (il coder Crediar ad esempio ci è riuscito con Kirby ma la patch utilizzata è costituita da un numero spropositato di patches per disabilitarla; probabilmente lo ha fatto come proof-of-concept e non credo si sia ripetuto anche sugli altri giochi).

    Riassumendo, i giochi con la sola metafortress possono essere avviati disabilitando tutte le modifiche/patch (cheats, region, ecc); i giochi che invece trovano il loader in memoria (protezione tipica di UbiSoft che non ha nulla a che fare con metafortress) possono essere avviati con delle modifiche al loader in modo tale che il gioco protetto non lo riconosca più; i giochi che hanno entrambe le protezioni invece sono tosti perchè se si patcha il gioco per bypassare la protezione si attiva la metafortress.

    NOTA: questa protezione (Metafortress) è utilizzata anche in alcuni giochi DS.

    Ringraziamento speciale:
    Ringrazio il coder DAVEBAOL (autore del cIOS d2x, vedere più in basso) per le spiegazioni in merito.


    UNITA'DI SVILUPPO

    [​IMG]

    A quanto pare esistono pochissime immagini o informazioni su questa unità per sviluppatori chiamata RVH-T; con tutta probabilità offriva possibilità di debugging e probabilmente non era in grado di avviare i giochi retail.


    SISTEMI PER ESEGUIRE CODICE ARBITRARIO


    HARDMOD

    Le prime modifiche alla console furono di tipo hardware e furono rappresentate dai famosissimi "modchip" e cioè dei chip che si interponevano tra il lettore ottico e le sue connessione con la console. Ne esistono/esistevano una quantità quasi spropositata e si distinguevano 2 grandi categorie: quelli che richiedevano la saldatura manuale (nella foto: CycloWiz):
    [​IMG]

    e quelli più recenti "solderless" i quali si incastravano a pennello con delle clips nei punti chiave, solitamente sopra il chip del drive ottico (in foto: D2cKey, Argon, D2Pro e Wasabi):
    [​IMG]

    La problematica maggiore di questi chips era la compatibilità; alcuni giochi infatti richiedevano una velocità di circa 6x per andare correttamente mentre questi chips fornivano al massimo una velocità 3x.
    Inoltre il rilascio del System Menu 3.0 fu in grado di provocare il brick di un piccolo numero di consoles modchippate.
    Ovviamente la rincorsa gatto-topo richiese l'update dei chips ogni volta che Nintendo modificava l'hardware del proprio drive ottico, questo fino all'uscita della versione chiamata "D2E" (vedi più in alto per l'elenco completo); fino a questa revision infatti i modchip potevano funzionare anche se big N provò a nascondere i pins sotto una resina epossidica che poteva comunque essere rimossa anche se con rischio di danneggiare l'hardware:
    [​IMG]
    Dura fu la vita dei modchip con l'avvento della revision chiamata "D3" del drive ottico: da questo momento in poi il chip del controller non era più sulla PCB; questo costrinse gli sviluppatori di modchip ad escogitare uno stratagemma per inserire il loro chip tra la console ed il drive ottico passando per il flat cable di quest'ultimo ed utilizzando la modalità DVD del lettore, modalità non disponibile "ufficialmente" per evitare che la console potesse leggere i normali DVD (in foto: Wasabi DX):
    [​IMG]
    La mossa successiva di Nintendo fu semplice e brillante: rimuovere il supporto per normali DVD direttamente dal firmware del lettore ottico e lo fece con la revision chiamata "D3-2" ! Questi ultimi ed i successivi sono i lettori definiti "antimodifica".
    La contromossa "hacker" fu allora quella di sostituire il PCB del drive ottico con quello di un lettore D3 o più vecchio; per ovviare anche a questo stratagemma l'ultima mossa hardware di Nintendo fu infine quella di ridisegnare totalmente il PCB del lettore con la versione chiamata "D4", più piccola della precedente e con connessioni differenti che rendevano lo "swap" delle schede PCB impossibile da effettuare.
    L'ultima risorsa per giocare ai backups fu fornita con i "sostituti" del drive ottico, periferiche in grado di emulare il drive reale e dunque caricare i giochi direttamente da USB o SD, come ad esempio il WODE Jukebox (Wii Optical Drive Emulator), che potete vedere in foto:
    [​IMG]
    Inoltre un sistema per aggiungere un drive DVD esterno USB è possibile con i cIOS di Hermes ed il Loader uLoader; questo homebrew però non permette la lettura dei dischi originali a causa del formato proprietario, i backups vanno dunque masterizzati nel DVD in formato .ISO.
    Nello spoiler sottostante potete vedere una immagine ricavata da wikipedia dove sono elencati tutti i modchip e le relative compatibilità con i drives ottici:
    [​IMG]
    L'ultimo colpo di coda in difesa dei suoi software venne infine sferzato dalla azienda di Kyoto iniziando ad utilizzare nei suoi titoli il controllo sui dati BCA (vedi sopra) fino ad allora procedura mai effettuata dal gioco stesso come ad esempio nel titolo New Super Mario Bros Wii; il gioco andava patchato per essere avviato con i modchips.


    SAVEMII / SAVEMIIFRII

    [​IMG]
    Hardware creato dal Team Twiizers dopo aver scoperto, tramite debugging, l'esistenza della Recovery Menu della Wii; tramite questo hardware veniva triggerata tale modalità. Si scoprì poi che questo menu "segreto" poteva essere avviato anche in un secondo modo: collegando un controller GC alla quarta porta sulla console e premendo il D-Pad ripetutamente in tutte le direzioni (Savemiifiii). Era utile nel caso di brick per aver installato titoli di regioni differenti (funzionava solo per i semi-brick, cioè i bricks che non dipendevano da IOS e/o dal System Menu ma solo da titoli installati).
    Un diagramma di flusso sul troubleshooting hardware Wii scritto dal Team Twiizers puo'essere visionato qui.

    BOOTDISCS


    FREELOADER

    [​IMG]
    Il primo (e forse l'unico?) disco di avvio prodotto dalla oramai famosa (per le modifiche) Datel era Freeloader il quale permetteva il bypass delle restrizioni regionali (sia Wii che in modalità GC). Si inseriva il disco, lo si avviava dalla dashboard e si sostituiva con il disco di gioco. Una minima quantità di giochi Wii non erano compatibili mentre la compatibilità era ulteriormente ridotta se si trattava di giochi GameCube. E'compatibile con i modchip. NON permette l'avvio dei backups ! Non funziona più dalla versione di fw 3.4.



    SOFTMOD

    I principali autori della softmod a questa fantastica console Nintendo sono quelli del Team Twiizers (futuro Team Fail0verflow), i quali, se ricordate le precedenti "lezioni di protezioni delle consoles", da singoli reversers/devs si sono nel tempo "aggregati" in un gruppo... e che gruppo !
    Vediamo ora gli hacks più famosi da loro prodotti ma non solo !


    • TWIIZER ATTACK

      Questo attacco è stato eseguito nel 2008 propri dal "Team Twiizers":
      [​IMG]
      in particolare dal compianto Bushing (a destra nella foto: morto nel 2016 per attacco di cuore), Marcan (a sinistra) e Sven (al centro). Utilizzando un paio di pinzette (tweezer in inglese) per creare un ponte tra i pin della RAM Wii, i membri del team Twiizers sono riusciti, in modalità GameCube che utilizza soltanto 16 dei 64MBs della RAM Wii, a dumpare anche la parte non accessibile della restante memoria ed i dati sono stati salvati attraverso la porta del controller. Gli altri membri noti del team sono Segher, tmbinc (questi 2 li ricordate, vero?), boot0, drmr, bLAStY e dhewg (forse anche Cotis ed Adhs). In questa intervista a Bushing salvata da webarchive si parla di questo hack. L'hack fu fixato con la release del firmware 3.3 (poco utile visto che era un "one time hack" e cioè una volta scoperta la Common Key, che è uguale per tutte le consoles, fixarlo non avrebbe mitigato la diffusione di tale key sul web).

    • TRUCHA BUG

      Bug scoperto dal Team Twiizers, che non ha MAI rilasciato il codice di exploit, ma successivamente scoperta anche da coder xt5 (grazie alla divulgazione della Common Key che ha permesso lo studio degli IOS) il quale ha creato il Trucha Signer, che sfrutta questo bug per creare dei files di installazione (.WAD) per gli IOS anche senza firma vailda (la prima, complessa procedura è disponibile qui). Il bug consiste nel fatto che il boot1, il boot2 e gli IOS non gestivano correttamente la firma RSA permettendo di bypassarla. Il nome probabilmente deriva dal Messicano "stai attento". Ecco il video che descrive in dettaglio il bug (tra i minuti 0:50 e 3:15):

      Il bug fu fixato una prima volta in alcuni IOS nel fimrware 3.3 e definitivamente (vedi IOS16 più avanti) dalla versione firmware 4.0.

    • STM EXPLOIT

      Scoperto da tempo per caso dal Team Twiizer e sfruttato nel HackMii Installer già da mesi in forma decisamente offuscata, fu rilasciato solo ad inizio 2010 da parte del Team Twiizers dopo aver ricevuto una mail da un "anonimo hacker" che dimostrava l'aver reversato il loro obfuscation code.

      Il bug è presente all'interno del modulo STM degli IOS per una "dimenticanza" nel codice dello stesso da parte del programmatore originale. Nel link scritto poche righe sopra troverete anche una spiegazione dettagliata di come funziona e di come sarebbero dovute essere le contromisure di Nintendo una volta scovato (ma che non sono state messe in pratica - parola di Marcan :wink:).

    • TWILIGHT HACK

      [​IMG]
      Sfruttando un mancato controllo nella lunghezza di un campo personalizzabile nel gioco (nome del cavallo) The Legend of Zelda: Twilight Princess il Team Twiizers, nel 2008, ha sfruttato un buffer overflow per creare un exploit. Questo hack funziona soltanto fino a fw 3.3 (v0.1beta1) e fino a fw 3.4 (v01beta2); il fix prevede che il System Menu cancelli il salvataggio incriminato non appena lo trova.

    • DVDX

      [​IMG]
      Il Team Twiizers ha creato questo "hidden channel" che rende possibile, nelle consoles con lettore non antimod, utilizzare i normali DVD senza bisogno di una hardmod ! Fu successivamente integrato in HBC. Il bug consiste nel modificare un bit nel file .tmd (nel campo "access rights" all'offset 0x1D8) del IOS che si vuole abbia accesso ai comandi per leggere i normali DVD.

    • BOOTMII

      [​IMG]
      [​IMG]
      Questo tool è una vera e propria interfaccia di avvio e ripristino della console !

      Per capire a fondo questo "tool" rileggete la parte relativa al boot 2 più in lato.

      L'installer di Bootmii in pratica cosa fa: va a modificare la SECONDA porzione, il loader, e la “trasforma” in 2 porzioni, ovvero un loader “taroccato” che servira’a caricare il codice ELF del bootmii ed il codice ELF del boot2. Quindi alla fine avremo un nuovo boot2 composta da HEADER-LOADER-BOOTMII-BOOT2 che è una cosa fantastica perchè LASCIA INTATTO IL BOOT2 originale (quindi non lo va assolutamente a sostituire) mentre il loader “taroccato” ci permette di scegliere se caricare il nostro codice (virtualmente qualunque cosa) ad esempio il bootmii oppure di far fare alla wii il suo percorso classico, ovvero, dopo il boot1, lanciare il boot2 originale.

      La modifica di questa parte del boot2 era resa possibile da un bug presente nel boot1 risolto purtroppo nelle versioni piu’recenti (boot1a e boot1b vulnerabili, boot1c e successive NON vulnerabili). Nelle versioni boot2v2 e boot2v3 il BootMii fa credere al boot1 che i blocchi dove è installato il boot2 (di solito i blocchi 1 e 2) siano danneggiati e così il boot1 lo va a cercare nei blocchi "non-bad", nel nostro caso 3 e 4 dove invece si è installato il "corpo" del BootMii (i blocchi 6 e 7 contengono invece rispettivamente copia di sicurezza del blocco2 e del blocco1).
      Nella versione boot2v4 invece il BootMii viene scritto direttamente nei blocchi 1 e 2 perchè la versione ufficiale di boot2v4 controlla dove è installato l'ultimo boot2 valido (sia esso originale che taroccato) e si installa direttamente sopra di esso, probabilmente ignorando gli altri blocchi, e visto che il BootMii nelle versioni boot2v2 e boot2v3 si installa nei blocchi 3 e 4, l'update ufficiale Nintendo li sovrascriverà con la nuova versione boot2v4 e quindi, reinstallando successivamente BootMii, questo troverà come utilizzabili i blocchi 1 e 2. In sostanza BootMii controlla in che blocchi è scritto il boot2 originale (ad esempio potrebbe essere anche nei blocchi 1 e 3 nel caso ci siano veramente dei bad blocks nel blocco 2) e si va a scrivere negli altri 2 blocchi liberi aggirando il boot1 facendogli credere che quelli attualmente utilizzati dal boot2 ufficiale siano bad blocks (grazie a zoomx per avermi spinto ad approfondire questa parte tecnica).

      Precisazione:
      non è vero che, non potendo installare il bootmi in boot2, il boot2 non sia modificabile... il boot2 è sempre modificabile ma è la correzione (di fabbrica) del boot1 a non poter permettere l'installazione di bootmii in boot2 perchè con il nuovo boot1 viene a mancare il bug di verifica di eventuali modifiche sul boot2 quindi se lo modificassimo (e si puo'fare) otterremo un bel brick perchè il boot1 si accorge che il boot2 non è originale mentre con il vecchio boot1 la verifica poteva essere elusa via software. Bootmii prevede dunque la verifica di tale "elusione" e se non la trova possibile NON va a modificare il boot2 altrimenti produrrebbe un bel brick (errore viola :arrowright: installazione come IOS):


      Sarebbe possibile una modifica "ufficiale" del boot2 solo conoscendo le chiavi di criptazione private di Nintendo, ancor oggi purtroppo non disponibili.

    • HackMii INSTALLER

      [​IMG]
      Questo tool all-in-one permette di installare il BootMii in boot2 (o come IOS), installa:
      - The Homebrew Channel
      - DVDX
      - BootMii in boot2 oppure come IOS
      Necessita di un exploit per essere avviato da SD (es. un salvataggio modificato).
      L'installer è stato più volte aggiornato per superare le contromisure dei nuovi firmwares Nintendo nello specifico la cancellazione dei titoli che creava. In particolare con l'avvento delle consoles con seriale LU64******* l'installer non funzionava più ed il team non riuscì subito a capire cosa fosse successo; in breve le nuove Wii avevano un hardware diverso rispetto all'originale (studiato per risparmiare sui costi di produzione, per sopperire alla carenza di componenti andati fuori produzione, per fixare bugs ed explois): secondo le ipotesi di bushing il nuovo hardware aveva timings diversi per i quali Nintendo ha dovuto riscrivere gli IOS i quali restano comunque compatibili con le vecchie Wii ma installando i vecchi IOS nelle nuove console tale IOS non funziona correttamente (questo porta a problemi di brick nel downgrade, vedi più in basso). Link.

    • THE HOMEBREW CHANNEL

      [​IMG]
      Il vero, unico, inimitabile canale dal quale avviare tutti gli homebrews sviluppati per Wii (compresi gli amati/odiati "USB Loaders") ! Si installa dall'interno del HackMii Installer. Ecco un thread con le statistiche di utilizzo a livello globale di questo homebrew direttamente scritto da un membro del Team Twiizer a metà del 2010: quasi 600.000 installazioni singole !! Le ultimissime releases furono per fixare un problema nel riconoscimento degli Wiimote costruiti più recentemente e... il supporto alla modalità vWii di WiiU (Dicembre 2012) con un IOS exploit del coder tueidj :smile: ! I sorgenti furono rilasciati solo nel Novembre 2016

    • BANNERBOMB

      [​IMG]
      A Maggio 2009 il coder Comex rilascia un exploit per avviare codice non firmato aprendo il menu di gestione della scheda SD. Esistono 2 versioni:
      v1 - per firmwares da 3.0 a 4.1
      v2 - per firmwares 4.2

      Link.


    • INDIANA PWNS

      [​IMG]
      Altro exploit del salvataggio di un gioco originale: LEGO Indiana Jones. Buffer overfow scovato da "roto" ed exploit sviluppato dal Team Twiizers nell'estate del 2009. Funziona anche con l'ultimo firmware 4.3. Link.

    • SMASH STACK

      [​IMG]
      Exploit del salvataggio del gioco originale Super Smash Bros. Brawl scoperto ad Agosto 2009 dal coder Comex. Funziona anche con l'ultimo firmware 4.3. Link.

    • YU-GI-OWNED

      [​IMG]
      Ispirato da Team Twiizers il coder ichfly scopre ad Ottobre 2010 un bug nel gioco originale Yu-Gi-Oh 5D's Wheelie Breakers. Link. Il port alle versioni NTSC USA e JAP prende il nome di Yu-Gi-Vah ed è stato creato dal coder WiiCrazy. Funziona anche con l'ultimo firmware 4.3. Link.

    • ERI HaKawai

      [​IMG]
      Nel 2011 il coder delroth crea un exploit del salvataggio del gioco originale Tales of Symphonia: Dawn of the New World. versione PAL, portato poi anche alla versione NTSC da giantpune. Funziona anche con l'ultimo firmware 4.3. Link.

    • BATHAXX

      [​IMG]
      LEGO Batman è il nuovo bersaglio del Team Twiizers e del coder lewurm nel Gennaio 2011. Funziona anche con l'ultimo firmware 4.3. Link.

    • RETURN OF THE JODI

      [​IMG]
      Di nuovo il Team Twiizers assieme a roto, nel Febbraio 2011, rilasciano un exploit nel gioco originale Lego Star Wars: The Complete Saga a pochi giorni dal rilascio di Bathaxx. Funziona anche con l'ultimo firmware 4.3. Link.

    • LETTERBOMB

      [​IMG]
      L'ultimo sforzo del Team Twiizers nella scena Wii risal all'Agosto 2011. Questo exploit permette di avviare homebrews sfruttando un bug nella gestione dei messaggi ricevuti nella messageboard Wii; attraverso un messaggio cretao ad hoc il sistema fa avviare il boot.dol dalla scheda SD. Link. Unico modo per avviare homebrew su firmware 4.3 senza avere un gioco originale ! Funziona SOLO con firmware 4.3 ! Richiede accesso al sito https://please.hackmii.com/ per generare l'exploit basandosi sul MAC Address della Wii.


    • MAILBOXBOMB

      [​IMG]
      Il coder Giantpune rilascia, dopo il letterbomb del Team Twiizers, un nuovo exploit per la messageboard Wii. A differenza del precedente questo tool è un programma da avviare da linea di comando quindi non richiede l'accesso ad internet e funziona con tutte le versioni del System Menu da 3.0 a 4.3 ! Link.

    • PRE-PRIILOADER

      [​IMG]
      PREloader è una versione “discontinued” dal suo ideatore (Crediar) perchè non più motivato e perchè stanco di ricevere continue richieste di nuove implementazioni al suo software del quale, al momento di questa purtroppo triste decisione, ha rilasciato i codici sorgenti.
      Priioader nasce dunque da questi codici sorgenti ad opera di altri programmatori (uno dei quali è DacoTaco.
      L'applicativo "Priiloader" rinomina uno dei files del System Menu (il primo che viene eseguito) e si sostituisce ad esso mantenendo però copia dell'originale per ogni eventualità (es. disinstallazione di Priiloader) [es. nei menu 4.1E il file /00000001/00000002/content/0000007f.app viene rinominato in 1000007f.app e Priiloader diventa 0000007f.app].
      Questo "homebrew" permette di applicare diverse patches (es. region free) che saranno avviate in automatico, se selezionate, all'avvio della Wii.
      Se avete letto con attenzione la parte relativa alla sequenza di boot capirete come, se utilizzate uno “stubbed” IOS per avviare il System Menu, il sistema andrà in crash e nemmeno il pre-priiloader potranno aiutarvi, poichè si collocano SUBITO DOPO l’IOS utilizzato e quindi non verranno mai avviati se l'IOS non funziona !

    • SENEEK e neek2o

      [​IMG]
      Questi homebrew permettevano di utilizzare la SD o l'USB per emulare un dump della propria nand invece di utilizzare la NAND reale ! Piuttosto lente come soluzioni se paragonate alla vera memoria interna della Wii ma comunque a prova di brick e soprattutto funzionanti SENZA dover utilizzare un USB loader ! Sneek fu creato da Crediar mentre neek20 fu una riedizione di sneek ad opera di un team di sviluppatori. Tutti permettono di bypassare anche le protezioni più complesse dei giochi :smile:


    cIOS

    I cIOS (Custom IOS) sono degli IOS che derivano da versioni ufficiali Nintendo appositamente modificate (patchate) per ripristinare bugs o per eseguire funzioni non ufficiali.
    Se un cIOS ha problemi di coding (mal programmazione/bugs) l'applicazione che lo utilizza puo'crashare (come ad esempio il Waninkoko CIOSX rev19 ed installazione dell'IOS38 patched con hack di forzatura di utilizzo IOS249 da parte del System Menu applicato con priiloader = brick risolvibile togliendo la forzatura di utilizzo IOS249).




    • Creato dal Team Twiizers è l'IOS di BootMii (vedi sopra) o di PatchMii (bushing).
      Se non è possibile installare BootMii come boot2 allora questo puo'essere installato come IOS ed il Team Twiizers ha deciso di infilarlo proprio nello slot 254.
      PatchMii usa questo IOS temporaneamente.
      Dal firmware 3.4 Nintendo inserisce un IOS254 fasullo per sovrascrivere eventuali modifiche in tale posizione (contromisura nata contro PatchMii)

    • Creato da Wanker (alias Waninkoko) e di solito installato negli slot 249 o 250;
      Era il cIOS più diffuso perchè permette l'avvio della maggior parte dei backups prima dell'avvento del cIOS d2x.
      L'installer del cIOS di Waninkoko funziona cosi:
      1) si seleziona un ISO truchato con il quale eseguire le successive operazioni (di solito è il 36; questo passo è necessario per avere i permessi di scrittura sulla NAND);
      2) la prima cosa che poi viene chiesta è: sotto quale nome (slot) installare il nuovo IOS custom (cIOS) [IOS249 il più gettonato];
      3) la seconda è quale IOS ORIGINALE prendere come base (dal server ufficiale della nintendo) [IOS38 ed IOS57 i più gettonati];
      4) Il programma scarica dunque tale IOS originale selezionato al punto2;
      5) Mentre installa l'IOS scaricato al punto3 nello slot selezionato al punto1, applica le patches;

      Curiosa e divertente la "diatriba" scaturita tra Marcan e Waninkoko in merito a "chi è capace a fare cosa": la potete leggere QUI.

    • IOS202 (utilizzato da MPlayer CE o WiiMC)
      IOS222 (utilizzato dagli usb loaders)
      IOS223 (per giochi con microfono come Guitar Hero e Rock Band)
      IOS224 (utilizzato da uloader?)
      che sarebbe meglio installare utilizzando gli IOS ufficiali come segue:
      IOS202 - installare con base originale IOS60
      IOS222 - installare con base originale IOS38
      IOS223 - installare con base originale IOS37 (come detto sopra, alcuni giochi partono solo con questo - la V4 si basa su IOS38 merged 37)
      Con questi cIOS e l'USB Loader chiamado uLoader era possibile collegare un DVD esterno alle porte USB anche nelle consoles antimod ! Grazie a matvigl @matvigl per la precisazione !!

    • [​IMG]
      Creato dall'italianissimo coder davebaol rappresenta l'evoluzione del cIOS di Wanker.
      E'senza dubbio il cIOS più famoso ed utilizzato perchè corregge molti problemi della versione di Waninkoko.
      Esiste in 2 versioni, normale e "alternativa" a seconda delle esigenze; potete leggere le differenze qui.

    • Questo IOS viene installato dal vecchio programma FS Dumper di Waninkoko. Sostanzialmente contiene solamente il file TITLE.TMD (nella cartella CONTENT) ed ha una cartella DATA completamente vuota: è infatti in IOS "fasullo", che non esiste, con i privilegi di super utente (fakesigned ovviamente) creato quando il programma lancia il comando ES_Identify() con quel TMD (anche il Title ID è sostanzialmente fake).
      Viene inoltre creato ed utilizzato anche da Any Title Deleter e NON viene MAI rimosso ! Questo è un male perchè, anche riportando "vergine" una console con le varie metodiche, questo rimane (e Nintendo può scovarlo) !! Non credo che Any Title Deleter possa rimuoverlo visto che lo utilizza... (non voglio provare perchè non posso prevedere cosa possa succedere).
      p.s. Grazie ad alcuni test eseguiti all'epoca da robilyn @robilyn , l'IOS0 sembra venire installato anche dal homebrew SysCheck.

    • Questo particolare IOS è stato trovato all'interno del "Pink Fish Disc" o "Gay Fish Disc", un disco trovato all'interno di una console inviata per una riparazione ai centri Nintendo e tornata al proprietario senza che venisse rimosso.
      [​IMG]
      Questo non è un cIOS, ma un vero IOS firmato Nintendo e... con ancora il trucha bug presente ! Essendo in IOS firmato Nintendo era installabile senza patches anche nelle consoles aggiornate fino a 3.4 (perchè tale IOS non era installato) finchè il System Menu 4.0 non rese stub anche questo.


    AHBPROT ed IOS58

    L'IOS58 non ha nessuna funziona strana, è semplicemente l'unico IOS ufficiale con supporto USB 2.0, SENZA BUG O FUNZIONI diverse dagli altri (se non appunto l'USB 2.0), ecco il perchè il team Twiizers lo ha scelto come base per il suo Homebrew Channel dalla versione 0.8 dell' HackMii Installer in avanti.
    AHBPROT è invece una funzione degli IOS che serve ad impostare dei valori in un registro, tramite apposito exploit (sfruttato nell'IOS58 in questo caso); questo permette l'accesso all'hardware direttamente dal PPC senza dunque dover ricorrere ai moduli degli IOS per gestire le periferiche (gli IOS girano sul processore Starlet, mentre il PPC è il processore principale della Wii) - diciamo che è una specie di "funzione attivabile da dentro un IOS"; in pratica l'IOS conferisce al PPC, tramite il settaggio di alcuni bit attraverso la funzione HW_AHBPROT, i diritti di accesso hardware (forse ad ogni bit di questo registro corrisponde 1 singola componente hardware, quindi impostarlo tutto a FFFFFFFF dovrebbe conferire l'accesso a tutto). Serve quindi SEMPRE un exploit nell'IOS per attivare questa comunicazione diretta del PPC con l'hardware; una volta trovato questo exploit (il tema Twiizers lo ha trovato ma non lo ha reso pubblico) si agisce o sul TMD dell'applicazione (patchando il bit 0 del TMD, che puo'attivare i bit di questo registro) oppure direttamente sui bits del registro stesso gestito da HW_AHBPROT dentro allo Starlet.


    Attivando questi bit del registro in una applicazione (es HBC o priiloder), qualunque applicazione avviata all'interno della stessa (a patto che non venga ricaricato l'IOS utilizzato) potra'godere dei privilegi di accesso; ecco perchè si deve inserire no_ios_relaod al file meta.xml degli homebrew per averla !

    Qual'è l grosso limite ? Che gli IOS hanno i loro moduli già belli e pronti per l'accesso alle varie componenti (usb, wif, bluetooth, ecc) via processore ARM, mentre con l'accesso diretto ognuno si deve programmare i suoi, chiamiamoli cosi, moduli, per gestire l'hardware dal PPC... insomma AHBPROT è molto fico per chi è molto fico in programmazione di processori, per gli altri è una cosa in più da doversi studiare e soprattutto implementare... ecco perchè in bootmii non c'è il supporto per gli Wiimote... il Team Twiizers avrebbe dovuto codificare tutta la gestione del bluetooth e non l'ha fatto perchè si possono usare MOLTO piu'facilmente i tasti della console risparmiando ai programmatori la gran noia di riscrivere il protocollo bluetooth tutto daccapo (lunga perdita di tempo per una cosa abbastanza inutile visto che si possono usare i tasti della console).


    Per la cronaca AHB è un protocollo di comunicazione standard che permette la comunicazione dati tra processori ARM ed altre periferiche.


    IOS_Reload

    Dopo una chiacchierata su IRC mi è stato detto essere possibile che, durante una partita, un gioco possa eventualmente richiamare un altro IOS... dicono non essere una funzione documentata ma che in teoria è possibile... agli sviluppatori però non è concessa la funzione "IOS_Reload" ma possono richiamare durante il gioco le loro cose in modo simile alla funzione IOS_Reload... fino ad ora questo non è stato MAI documentato anche se potrebbe essere utilizzato contro la pirateria anche se nessuno ha saputo farmi un esempio tangibile dove questo accade (a meno che non si consideri il gioco Prince of Persia che controlla se un cIOS è in esecuzione [non se è installato dunque] cercando di caricare i suoi moduli: se riesce a caricarli allora capisce che c'è un cIOS ed il gioco non parte).



    DOWNGRADE

    Una cosa interessante: ogni volta che aggiorniamo ad un nuovo System Menu viene installato il suo nuovo IOS e viene stubbato (reso inutilizzabile) l'IOS del System Menu precedente. Volendo è possibile eliminare gli IOS del System Menu stubbati e rimpiazzarli con versioni precedenti non stubbate senza che la Wii subisca alterazioni di funzionamento; avere vecchie versioni di IOS del System Menu buone (non stubbate) puo'essere utile se inavvertitamente si cambia System Menu ad esempio installando per errore una versione più vecchia con un WAD manager: se l'IOS è stubbato ci sarà un brick, altrimenti avrete fatto un downgrade !

    E'anche possibile forzare un System Menu ad utilizzare un IOS piu'vecchio senza brikkare A PATTO CHE il vecchio IOS non contenga funzioni modificate rispetto a quello più recente (es. L'IOS70 puo'funzionare con il System Menu 4.3); nello specifico le consoles più recenti a partire dal seriale LU64******* non gradiscono il downgrade degli IOS con versioni più datate potendo generare un brick se si downgradano; cio'non avviene per le consoles più vecchie che sono in grado di accettare sia le versioni degli IOS più datate che quelle più recenti. Le consoles a rischio sono tutte quelle che avevano preinstallato il firmware 4.0 e le ultime uscite con preinstallato il firmware 3.4 (data di produzione compresa tra Novembre 2008 e Marzo 2009).



    SE PROPRIO DESIDERO UNA WII QUALE E'MEGLIO PRENDERE ?

    Premettiamo con il dire che TUTTE LE WII sono softmoddabili, quindi qualsiasi Wii troviate (ad eccezione della Wii Mini) potrete usufruire della possibilità di eseguire i backup dei giochi e di far funzionare i programmi homebrew.

    Diciamo che se volete soltanto usufruire dei backup dei giochi allora non esiste nessuna Wii meglio di un'altra. In questo modo potete anche utilizzare alcuni programmi homebrew che non necessitano di modifiche alla NAND della Wii.

    Se invece vi interessano anche altre funzioni continuate a leggere le caratteristiche che deve avere la Wii che tutti vorrebbero :smile:

    1) Seriale INFERIORE ad LEH278;
    perchè permette di usare i backup dei giochi direttamente da una copia fisica in formato DVD e permette inoltre, tramite applicazioni homebrew, di godere anche della visione di film in DVD e di usare il DVD come una memoria di massa su cui immagazzinare dati (immagini, mp3, ecc) per poi poterli leggere tramite apposito programma sempre homebrew (il migliore è senza dubbio WiiMC):
    [​IMG]

    Nel caso di seriale maggiore di LEH278 i backup possono essere letti soltanto da penne o hard disk USB oppure da memory card SD e NON si puo'utilizzare il lettore DVD della Wii per leggere film o files su DVD. Una soluzione a questo problema sembra essere la modifica hardware chiamata WODE. Un'altra soluzione è quella di farsi montare un vecchio DVD drive originale Wii al prezzo di circa 80 euro mano d'opera compresa (preso magari da una Wii defunta).

    2) Una wii prodotta PRIMA del tardo 2008, indicativamente con firmware inferiore a 3.3E;
    questo perchè molte di queste Wii permettono l'installazione di BootMii direttamente nel Boot2, software che permette il recupero della NAND e l'eventuale sua reinstallazione in caso di brick, ovvero di console non più utilizzabile a causa di errori che possono essere prodotti da software non ufficiale (ma a quanto pare anche da aggiornamenti ufficiali nintendo che vanno a riscrivere il boot2; pochi casi su migliaia ma è successo !). Se questa installazione nel boot2 non fosse possibile a causa di Wii troppo recenti si puo'comunque installare il Bootmii ma non come boot2, bensì come IOS; in questo caso, se doveste "brikkare" in modo serio (danni al System Menu o al suo IOS), per lanciare BootMii è necessario anche un ulteriore programma chiamato Priiloader che permette al BootMii di essere lanciato.

    Un utente di un vecchio forum (wiitaly) ha detto di avere avuto tra le mani 2 Wii con firmware, 3.3E, una con Bootmii installabile come Boot2 ed un'altra no. Indicativamente il seriale LEH246 ha un firmware 3.4E e BootMii NON installabile come boot2 ma soltanto come IOS. Dalle notizie trovate in giro per i forum possiamo comunque dire che, indicativamente, tra i seriali LEH106 ed LEH231 ci sono possibilità di poter avere BootMii su boot2 con probabilità che salgono andando verso LEH106 ed inferiori e che calano spostandosi verso LEH231 e superiori. In sostanza pero', attualmente, non esiste un modo esatto per sapere se BootMii puo'essere installato come Boot2 se non quello di provare ad installarlo (non correte nessun rischio nel fare questo tentativo).
    In definitiva SOLAMENTE le Wii con boot1a o boot1b permettono l'installazione di BootMii come boot2 (purtroppo dall'esterno è impossibile conoscere questa informazione; in generale più il seriale è basso più probabilita'ci sono di avere un boot1 che permette l'installazione di BootMii come boot2); SOLTANTO in queste Wii "vulnerabili", anche se aggiornate il boot2 con quello ufficiale Nintendo (perdendo momentaneamente il BootMii) potrete sempre reinstallarlo quando volete, perchè il boot1, per essere accettato dal sistema, PUO'ESSERE MODIFICATO SOLO IN FABBRICA e quindi una Wii che di fabbrica ha un boot1 "permissivo" accetterà sempre BootMii come boot2 !



    HACKERATA DOPO QUASI 7 ANNI !

    [​IMG]
    Tra fine 2012 ed inizio 2013 Nintendo decise di mettere in commercio a prezzo ribassato una versione ridotta all'osso (dal punto di vista hardware) della sua Wii, la Wii MINI !
    Mancando una qualsiasi connessione di rete e lo slot SD (unici sistemi per eseguire un exploit) fu impossibile per gli hackers, oramai piuttosto disinteressati a questa console, trovare un exploit per eseguire codice arbitrario. Qualcuno provò a saldare uno slot SD sulle piazzole oramai non più popolate ma il sistema non lo ha comunque riconosciuto.

    Si è dovuto attendere fino a Settembre 2019 quando il dev Fullmetal5 rese pubblico l'exploit scovato anche su questa console attraverso un bug nello stack bluetooth prodotto dalla broadcom; l'exploit creato prende il nome di bluebomb ed è possibile sfruttarlo utilizzando un sistema linux ed inviando comandi bluetooth manuali da shell caricando un payload che permette l'avvio di HackMii iInstaller.



    CONCLUSIONI

    In questa lunga carrellata abbiamo visto come inizino a svilupparsi exploits utilizzando periferiche di accesso esterne (la SD) ed exploitando i salvataggi di gioco ! Questi ultimi sono i più difficili da patchare perchè nella maggior parte dei casi richiedono il rilascio di una nuova versione del gioco quindi una sua ristampa quindi costi di produzione aumentati (non conviene) anche se in alcuni casi possono essere prese contromisure dal firmware (vedi Twilight Hack). La lotta tra i reversers e Nintendo inizia a farsi laboriosa a causa dei frequenti updates e la rincorsa a trovare nuovi exploits fa muovere la scena con nuovi personaggi in cerca di fama e vecchi personaggi che tendono ad aggregarsi tra loro in team e scoprono nuovi bugs ma tendono a non rilasciare a meno che il bug non venga prima fixato. Rimangono anche i "soliti" freelance (es. Crediar) che invece fanno tutto da soli e sembrano essere attivi anche nella "release scene" (forse per questo non si aggregano).

    Se vi è piaciuta questa rassegna tenetevi pronti per la prossima console: il 3DS ! :wink:
     
    #1
    Ultima modifica: 4 Ott 2019
    A aspirina, zSenpaiz, Lucarelli e 15 altri utenti piace questo elemento.
  2. iostream

    iostream Phoenix Wright

    Iscritto:
    13 Ago 2016
    Messaggi:
    4.895
    Like ricevuti:
    1.619
    Quello che so io è la prossima? Altro articolo lungo come questo allora.​
     
    #2
    Ultima modifica di un moderatore: 3 Set 2017
  3. Worf

    Worf Livello 20

    Iscritto:
    18 Gen 2016
    Messaggi:
    1.024
    Like ricevuti:
    269
    Domanda per student, i giochi con la protezione avanzata non furono superati con l'introduzione dell'emunand?
     
    #3
  4. darkangel84

    darkangel84 Livello 1

    Iscritto:
    9 Mar 2016
    Messaggi:
    8
    Like ricevuti:
    13
    La Wii è stata una bella console alla fine dei conti.. anche per il lato hacking!

    Comunque student avevi ragione.. questa è bello lungo come postXD
     
    #4
    A student piace questo elemento.
  5. student

    student Staff Livello 41 Staff

    Iscritto:
    30 Ago 2015
    Messaggi:
    4.081
    Like ricevuti:
    4.207
    Hai ragione non ho parlato di sneek. In realtà non l'ho mai usato quindi non saprei. Vedrò di aggiungere anche quello all'articolo :wink:

    Si iostream, la prossima è vostra.
     
    #5
    A jtagger73 e iostream piace questo messaggio.
  6. Coolguy

    Coolguy Livello 14

    Iscritto:
    1 Feb 2015
    Messaggi:
    548
    Like ricevuti:
    87
    complimenti. impeccabile come sempre!!
     
    #6
    A student e iostream piace questo messaggio.
  7. IPorK

    IPorK Livello 3

    Iscritto:
    3 Feb 2016
    Messaggi:
    45
    Like ricevuti:
    22
    wow sensa neanche saperlo il seriale della mia wii e inferiore a LEH278 (LEF500) Comunque come al solito complimenti per la serie! A quando le console playstation?
     
    #7
    A iostream e student piace questo messaggio.
  8. iostream

    iostream Phoenix Wright

    Iscritto:
    13 Ago 2016
    Messaggi:
    4.895
    Like ricevuti:
    1.619
    Ci stavo pensando io all'articolo su PlayStation, magari faccio uno stub e poi io e @student (student se non riuscite a leggere) lo miglioriamo. Dovrei chiedere a lui.…
     
    #8
    A IPorK piace questo elemento.
  9. student

    student Staff Livello 41 Staff

    Iscritto:
    30 Ago 2015
    Messaggi:
    4.081
    Like ricevuti:
    4.207
    Aggiunte info su sneek ed altri piccoli aggiustamenti/dimenticanze.

    La playstation, se verrà, sarà decisamente dopo :smile: sony si inserisce già "tardi" nel mondo delle consoles.

    EDIT: iostream @iostream evitiamo di spoilerare, se devi chiedere cose in argomento fallo in PM, grazie :wink:
     
    #9
    A IPorK piace questo elemento.
  10. iostream

    iostream Phoenix Wright

    Iscritto:
    13 Ago 2016
    Messaggi:
    4.895
    Like ricevuti:
    1.619
    Vero, devo far rimanere l'effetto suspense
     
    #10
    A IPorK e student piace questo messaggio.
  11. matvigl

    matvigl Staff NonninoWii Staff

    Iscritto:
    21 Dic 2014
    Messaggi:
    2.696
    Like ricevuti:
    816
    Bella guida come sempre student
    di sei dimenticato una cosa, per chi aveva il lettore antimod poteva far leggere i dvd masterizzati tramite un drive dvd esterno con il loader uLoader, che permetteva anche di poter avviare i wiiware e vc
    gli unici giochi con la protezione se ricordo bene erano Le Avventure di Tin Tin e Driver San Francisco
    che si doveva usare sneek
    come da video su WiiU
     
    #11
  12. student

    student Staff Livello 41 Staff

    Iscritto:
    30 Ago 2015
    Messaggi:
    4.081
    Like ricevuti:
    4.207
    Azz hai ragione ! Con i famosi ios di hermes ! Aggiungo subito alla apposita sezione !
     
    #12
  13. Nila

    Nila Livello 7

    Iscritto:
    7 Ago 2015
    Messaggi:
    150
    Like ricevuti:
    87
    Io modificai la feci con indiana pwns! Bei tempi! Comunque la console più innovativa di sempre! Complimenti, ho letteralmente divorato con interesse (come sempre) questa rubrica!
     
    #13
    A student piace questo elemento.
  14. iostream

    iostream Phoenix Wright

    Iscritto:
    13 Ago 2016
    Messaggi:
    4.895
    Like ricevuti:
    1.619
    Secondo me tutte le console Nintendo sono innovative per il tempo in cui sono state rilasciate, secondo me
     
    #14
    A student piace questo elemento.
  15. zoomx

    zoomx Livello 19

    Iscritto:
    12 Set 2015
    Messaggi:
    892
    Like ricevuti:
    339
    Per me l'uscita di sneek fu utilissima in quanto mi permise di utilizzare firmware e canali JAP che non esistevano per le altre regioni e a sperimentare sia con firmware esistenti (il mio) che con firmware sintetizzati scaricando gli opportuni files dal NUS.
    Ad esempio bastava il WAD del system menù e il suo IOS per far partire la console.

    L'altro aspetto divertente fu l'uso di tali firmware con l'emulatore Dolphin su PC.

    L'homebrew più usato per me fu il lettore multimediale.

    Per la playstation 1 ho trovato un firmware per un mod-chip basato su Arduino. Nei commenti viene spiegata bene la funzione del chip, la protezione originale e i successivi aggiornamenti.
     
    #15
    A student piace questo elemento.
Sto caricando...

Condividi questa Pagina