LE PROTEZIONI NELLE CONSOLES - NINTENDO SWITCH

​

Dopo lo scarso successo e la prematura uscita di scena di Wii U, Nintendo ritenta la fortuna con la prima console ibrida di sempre ! Nella sua duplice funzione "da salotto" e "portatile" e con nome in codice NX (il quale lascia ancora dubbi sul suo reale significato) e product code HAC (dal significato ancora più oscuro), debutta dunque nel Marzo 2017 Nintendo Switch:

​

Il suo product code è HAC-CPU-01 e, come da tradizione N, anche lei vuole essere una innovatrice nel mondo dei videogiochi e lo è vista la sua capacità di essere giocata fino alla massima risoluzione di 1080p 60fps a casa o in versione 720p in modalità "da asporto"; inoltre è dotata dell'innovativo sistema "double face" dei Joy-Con che possono essere utilizzati da soli o in combo. Da notare infine come per la prima volta la casa di Kyoto preferisca utilizzare un System on a Chip (SoC) non proprietario, il Nvidia Tegra X1, rapido e con bassi consumi vista la necessità di poterla utilizzare "on-the-fly" quando non si è a casa.

UNITA'DI SVILUPPO

Esistono 2 tipi di Switch per sviluppatori/devs:

• SDEV
• EDEV

• 
  
  La versione SDEV è la vera versione di sviluppo con debugger e possibilità di espansione della memoria (fino a 3GB in più) e della capacità della NAND ! Il prezzo si aggira attorno ai 1500$.
  
• 
  
  La versione EDEV è molto simile alla Switch retail, non sembra avere funzioni di debug ma può essere acquistata con un quantitativo di spazio NAND variabile (costo tra gli 800 ed i 1000$ a seconda della dimensione della NAND).
  

PROTEZIONI

FORMATO DELLA CARTUCCIA PROPRIETARIO

La Switch presenta un nuovo formato di piccole cartucce i cui chip utilizzano un protocollo di comunicazione in parte criptato come accadeva per le console "sorelle maggiori".

Nello spoiler alcune cartucce a confronto:

Spoiler

(da sinistra a destra abbiamo: N64-GBA-DS-3DS-PSvita-Switch)

CHAIN OF TRUST - CATENA DELL'AFFIDABILITA'

Per comprenderla è necessario conoscere un minimo la struttura del SoC Nvidia Tegra X1, che, come abbiamo detto, rappresenta il cuore della console (immagini trovate sul web):

Questo grande integrato al suo interno contiene tante cose (info studiabili nel dettaglio qui):


Il confronto di un chip Tegra X1 "reale" e quello del chip trovato all'interno della console conferma che si tratti di un Tegra X1 (potete notare la pressochè identica struttura):

ARM cortex-A53 - ARM cortex-A57 - Maxwell SMs?​

COSA CONTIENE IL SoC Tegra X1
- CPU Principale: chiamato anche CCPLEX;
- CPU boot: chiamata anche BPMP (Boot and Power Management Processor) ma anche COP (CO-Processor); l'architettura di questa CPU è ARM7TDMI;
- BootROM: contiene il codice che avvia il processo di boot (essendo integrata nel SoC non vi si puo'accedere dall'esterno);
- Una piccola RAM (IRAM);
- Vari controllers per periferiche come eMMC, NAND e flash SPI. Questi forniscono l'accesso al dispositivo di memoria fisico del boot che contiene BCT e bootloader;
- Controllers USB;
- Un controller per la gestione dell'alimentazione: chiamato PMC (Power Management Controller);
- Fusibili (eFuses): programmabili in fabbrica e read-only (integrati anche essi nel SoC).

eFUSES

Gli eFuses sono dei "fusibili" microscopici che possono essere "bruciati" in modo irreversibile attraverso quella che viene chiamata "suicide electromigration" (detta anche "silicide") e cioè, facendo passare corrente (elettroni) nella loro struttura questi si bruciano e non permettono più il passare della stessa. Ne esistono di diverse tipologie a seconda dei materiali utilizzati e delle caratteristiche fisiche:

Ora, ripristinare questi eFuses è praticamente impossibile per i comuni mortali anche se sarebbe tecnicamente possibile, se si riuscisse a trovare l'esatto punto dove si deve agire (stiamo parlando di dimensioni al di sotto di 1 micron!) ripristinadolo con submicroniche saldature tipo quelle effettuate in questa foto (che non ha nulla a che fare con gli eFuses, serve solo per rendere l'idea del "quanto sia tutto così piccolo là dentro"):

aprire lo spoiler sottostante per vedere da dove sia stata ottenuta:

Spoiler

Per che cosa sono utilizzati gli eFuses nella Switch ? Per evitare il downgrade del firmware; il sistema infatti si aspetta di trovare un certo numero di eFuses bruciati a seconda della versione di firmware che viene avviata: se il numero di eFuses bruciati è inferiore a quello atteso, la console provvede a portarlo ad un numero adeguato alla versione di firmware; se al contrario la console trova un numero superiore di eFuses bruciati rispetto a quello atteso si blocca.
Se volete conoscere le corrispondenze tra versioni di firmware ed eFuses bruciati nelle consoles retail aprite lo spoiler sottostante:

Spoiler

FW - eFUSES BRUCIATI

1.0.0 - 1
2.0.0-2.3.0 - 2
3.0.0 - 3
3.0.1-3.0.2 - 4
4.0.0-4.1.0 - 5
5.0.0-5.1.0 - 6
6.0.0-6.1.0 - 7
6.2.0 - 8
7.0.0-8.0.1 - 9
8.1.0 - 10
9.0.0 - 11
9.1.0-9.2.0 - 12
10.0.0-10.2.0 - 13
11.0.0-11.0.1 - 14

Nvidia TESTBOARDS

Il reverser plutoo al 34C3 ha rivelato di aver effettuato dei test sulla CPU Tegra X1 attraverso una tesboard acquistabile direttamente da Nvidia per circa 700$ che porta il nome di Jetson TX1 Devkit:

Tra le scoperte ottenute abbiamo:

- un microkernel chiamato "Horizon";
- tutti i drivers in userspace prendono il nome di "services";
- uno speciale driver GPU, tipo quello per linux ma piuttosto modificato con specifiche API per comunicarvi [NVN API];

MODELLO DI SICUREZZA ED EXPLOITS

Il modello di sicurezza si basa su diversi livelli ognuno dei quali "sandboxato" con specifici privilegi e permessi. Rendendo le cose ultrasemplici una sandbox è un ambiente limitato in cui una applicazione lavora e non puo'uscire da esso (salvo eventuali exploits)


Il primo "buco" (fixato più volte nei fw 2.1.0, 3.0.0, 3.0.1...) è stato trovato nel webkit browser che ha permesso lo sviluppo del pegasus exploit a metà del 2017. Dumpando la memoria del browser dal file sdk.elf hanno ricavato i nomi delle syscall (comodo per chi fa reversing).


Plutoo ha poi rinvenuto in un servizio chiamato pl:u (quando si dice il destino... ) un bug (fixato dal fw 3.0.0 in poi) che si manifesta quando si inserisce come valore per il servizio un valore troppo grande: questo provoca un "Array out of bounds read" e cioè il sistema va a leggere dati oltre la sandbox e nello specifico questo ha permesso il dump del servizio chiamato "ns" portando quindi alla seguente fase di "escalation" alla ricerca di privilegi di più profondo livello (in verde il progredire della "scalata" dei sistemi di sicurezza):




A questo punto si inserisce il smhax (fixato dal fw 3.0.1 in poi), exploit dell'importante servizio "sm" Service Manager: in parole semplici saltando l'invio di un parametro il servizio gli assegna di default il valore 0 il che significa poter accedere a tutti i servizi portando a questo risultato:


Ora, studiando i vari servizi, è stato trovato un bug nel servizio "ldr": inviando infatti il comando "ldr:ro cmd 0" il servizio va in crash permettendo così il dump dei vari binari di sistema permettendo di studiarli.

Il passo successivo, il dump del kernel, viene spiegato dal reverser derrek sempre durante il 34C3, il quale racconta che, non essendo riusciti a trovare un modo "dal basso" (cioè partendo dalla "Game/Application" zone) hanno provato un approccio dall'altro lato e cioè dalla sequenza di Boot (vedere paragrafo successivo) che è ampiamente documentata visto che si tratta di un processore "consumer" prodotto da Nvidia (fatta eccezione per alcune patches).

Derrek spiega che esiste una recovery mode che viene triggerata se viene rimossa la eMMC ma che tutti i comandi utilizzati in questa modalità devono essere firmati con una key RSA privata di Nintendo (a lei rilasciata da Nvidia) che non è ovviamente di pubblico dominio.
La eMMC puo'però essere facilmente dumpata.

Per estrarre il keyblob (vedi paragrafo successivo) hanno dovuto trovare un sistema per eseguire codice sul Pkg1Ldr perchè è l'unico ad avere accesso a tale blob di keys; analizzando i dati nel bus della eMMC, grazie ad un glitch hardware inviato durante durante la verifica SHA2 hash della RSA key, sono riusciti nell'intento:

Il setup hardware di tale glitch ha richiesto circa 1 mese di sviluppo:

ed ha portato a:


Ottenendo i binari, compresi quelli del kernel, plutoo spiega le sue caratteristiche:

e soprattutto spiega il Hmm hax (fixato dal fw 3.0.2 in poi):

in sostanza, nonostante le misure a protezione del kernel, i programmatori Nintendo hanno accidentalmente mappato l'eseguibile dello stesso in userspace il che permette di poter utilizzare funzioni del kernel direttamente da qui e soprattutto questo permette di superare la ASLR

Spoiler: ASLR

La ASLR (Address Space Layout Randomization e cioè la "casualizzazione" dello spazio degli indirizzi) è una misura di protezione contro buffer overrun ed exploit che consiste nel rendere (parzialmente) casuale l'indirizzo delle funzioni di libreria e delle più importanti aree di memoria.

Una parte del kernel "attaccabile" si è rivelata essere la SMMU (System Memory Management Unit) delle cui pagetables il kernel ha il controllo; questa unità è protetta da modifiche ma... esiste, nelle 3000 pagine di documentazione ufficiale Nvidia, un sistema per disabilitarla ! Anzi, nel testo c'è proprio scritto "bypass the SMMU":

Con questo bypass il kernel non puo'utilizzare l'isolamento per il driver della GPU e questa è una caratteristica hardware che non è fixabile ! I devs ringraziano dunque Nvidia per questa "feature" non senza mostrare compiacimento mentre informano la platea del fatto (nella foto plutoo):


Nonostante questo regalo i devs hanno comunque trovato un altro metodo per il bypass chiamato mchammer (fixato dal fw 2.0.0 in poi):

utilizzando questo exploit, che prevede di sfruttare il fatto che se ci sono più di 40 "handles" nel processo che le gestisce queste finiscono in un'area della memoria non protetta, sono riusciti a mappare il kernel all'interno del loro processo contenuto in tale area potendo cosi modificarlo a piacimento permettendo cheats, backdoors, ecc:


Il dev naehwert ha spiegato invece come funzioni la TrustZone dei processori ARMv8 attraverso il SecureMonitor (chiamato sia da Nvidia che da Nintendo EL3) e perchè sia possibile ignorarlo completamente visto che nell'implementazione Nintendo non monitora nulla:


Le funzioni della TrustZone sono le seguenti:

Il Tegra SE (Security Engine) ha invece queste caratteristiche:

ed il suo sistema di crittografia è strutturato in questo modo:


Lo sleep mode invece viene utilizzato per preservare il sistema dall'eccessivo utilizzo di corrente:

e durante questa modalità ci sono queste funzioni attive:


Quando la console viene "risvegliata" dallo sleep mode accade invece questo:


Nonostante tutte queste interessanti ed efficaci misure di sicurezza, come abbiamo detto in precedenza, il kernel mappa purtroppo (per Nintendo) molte importanti cosucce in userspace quindi "giocando" un pochino in tale modalità possiamo ottenere l'esecuzione di codice EL3 direttamente dalla usermode rendendo così la TrustZone una "UntrustZone":


Nonostante non fosse necessario grazie a questa UntrustZone il dev SciresM è riuscito ad ottenere i permessi di esecuzione all'interno della vera TrustZone:


Dopo un così approfondito studio del sistema i devs hanno reso disponibili un debugger dedicato (nxdbg) e delle specifiche librerie (libnx) dedicate allo sviluppo di homebrew ! Il supporto audio è arrivato poco dopo mentre l'accelerazione hardware è arrivata a fine estate 2018.

Il primo homebrew ad essere stato ufficialmente rilasciato è stato un emulatore SNES seguito a ruota dall'emulatore per Doom e l'immancabile "Hello World". Una pagina dedicata a questi programmi fatti in casa è disponibile qui.

Un Homebrew Launcher è stato sviluppato grazie anche alla collaborazione del team Reswitched (notizia di Dicembre 2017), rilasciato al pubblico inizialmente solo per la versione di firmware 3.0.0.

Agli inizi di Marzo 2018 sempre SciresM ha pubblicato informazioni su Exosphere, una implementazione custom della TrustZone con dimostrazione di esecuzione di codice all'avvio della console ed i primi screenshots del suo custom firmware chiamato Atmosphere-NX:


Quasi contemporaneamente i devs Plutoo e Neahweart hanno pubblicato questi sorgenti di una presumibile ulteriore custom TrustZone con descrizione "Nintendo Switch Something".

In sostanza il bug trovato nella bootrom della console (chiamato Fusée Gelée e qui spiegato dal dev Kate Temkin [ktemkin] che ne è scopritrice indipendente dagli altri teams/devs) è un bug di tutti i dispositivi che montano lo stesso chip della Switch di conseguenza gli sviluppatori hanno prima contattato NVIDIA e, per conoscenza, Nintendo, spiegando nei dettagli l'exploit per dar loro il tempo di porvi rimedio; in tutta risposta è arrivata, all'inizio dell'estate 2018, una nuova revisione del SoC Tegra (il nome in codice delle Switch con questo nuovo SoC è "Mariko", il SoC originale con il bug invece è "Erista") con lo specifico bug corretto ma TUTTE le consoles prodotte prima di tale nuova revisione saranno sempre vulnerabili; cambieranno le modalità di esecuzione del custom firmware a seconda del fw originale della console: più sarà alto più potranno essere complesse le procedure per eseguire l'exploit via software con possibile necessità di una piccola hard mod (cortocircuitare 2 pins del connettore del joycon destro) per mandare la console in modalità recovery [APX Mode o RCM Mode].
Il 23 Aprile 2018 è stato leakato il dump di una bootROM Tegra X1, che, a detta del "leaker", è qualcosa di abbastanza complicato da ottenere attraverso glitch hardware (probabilmente del devkit Jetson e non di quello di una Switch, che ha delle specifiche patches rispetto a quello "standard Nvidia"): questo non fa molta differenza perchè il bug è presente in tutte le bootROM Tegra X1 quindi il suo rilascio ha permesso a diversi devs di scoprire il piuttosto semplice bug reversando il codice della ROM determinando una serie di rilasci a "cascata" nella scena Switch tra cui spiccano la possibilità di avviare Linux (rilasciata dal team f0f), screenshot di un emulatore Game Cube e screenshots di un presumibile porting Android per la console.
Il full responsible disclosure riguardante il bug della bootROM di Kate Temkin è stato pubblicato lo stesso giorno. L'hardware + software (SXOS) in produzione da parte del team XECUTER (che a partire da inizio 2018 ha iniziato a diffondere la notizia della sua esistenza) si basa proprio sullo sfruttamento di questa falla ma, al contrario del responsible disclosure utilizzato dai devs della scena, gli sviluppatori di XECUTER sembrano non badare a certe "sottigliezze" ed hanno addirittura copiato parti di codice di Atmosphere mirando diritti al guadagno; dopo mesi di mancati aggiornamenti dovuti con tutta probabilità a gravi ripercussioni legali sul team stesso il 30 Marzo 2021 sono stati rilasciati su gbatemp dal dev Reacher17 i cracks delle versioni SXOS 2.9.5 e 3.1.0.

LA SEQUENZA DI BOOT

La prima cosa avviata dalla console tramite il CPU boot (BPMP) è la bootROM (il suo dump è stato annunciato il 15.10.2017); questa stabilisce quale sia la memoria fisica da cui leggere i dati e non effettua alcun tipo di crittografia simmetrica.

Una volta impostate le keys, i primi dati letti dalla NAND eMMC da parte della bootROM si chiamano BCT (Boot Configuration Table) e rappresentano i primi titoli installati nella console nella partizione di boot 0:
Offset: 0x000000 dimensione: 0x4000 Title 0100000000000819 BCT
Offset: 0x004000 dimensione: 0x4000 Title 010000000000081A BCT
Offset: 0x008000 dimensione: 0x4000 Title 0100000000000819 BCT
Offset: 0x00C000 dimensione: 0x4000 Title 010000000000081A BCT
Il BCT indica come configurare la memoria di boot, la SDRAm, dove caricare il bootloader in memoria ed il suo entry point.
Il bootloader (chiamato anche "package1") è il successivo titolo che viene caricato e che si trova nella NAND eMMC della console sempre nella partizione di boot 0.
La bootROM carica ora il bootloader in IRAM e salta al suo entry point: il codice è ancora eseguito dalla CPU boot.

La prima parte del bootloader (chiamata Stage 0) è in chiaro e serve per:
- avviare i dispositivi
- controllare la presenza di eventuali errori (es. se ci sono stati downgrades tramite il controllo degli eFuses)
- generare le keys
- decriptare ed eseguire la sua seconda parte

La seconda parte del bootloader (chiamata package1.1) viene decriptata e contiene 3 sezioni:

stage 0: contiene il binario per il warmboot;
stage 1: contiene l'NX bootloader che viene avviato dopo il primo bootloader del package 1;
stage 2: contiene il Secure Monitor (vedi TrustZone).

Il pacchetto successivo (package2) è installato nella partizione BCPKG2 e contiene il Kernel ed i moduli di sistema integrati. E'diviso in 4 sezioni ed ogni sezione è criptata con la stessa key (AES-CTR) utilizzata per criptarne il suo header e tale key è conosciuta solo dalla TrustZone. La sezione 0, una volta decriptata, rappresenta il binario del Kernel mentre la sezione 1 contiene i moduli di sistema. Le sezioni 2 e 3 non sono attualmente utilizzate (reserved for future use?).

GENERAZIONE DELLE KEYS nelle consoles RETAIL

Il processo di generazione delle keys è piuttosto complicato:

la bootROM tramite il bootloader imposta 2 keys nel keyslot del hardware security:
SBK - Secure Boot Key (salvata nel keyslot 0xE) - specifica per ogni console;
SSK - Secure Storage Key (salvata nel keyslot 0xF) - specifica per ogni consoles ma mai utilizzata nelle consoles Retail;
Queste chiavi sono generate a partire da valori slavati in speciali eFuses i quali vengono disabilitati dalla stessa bootROM non appena il bootloader (package1) ha finito di utilizzarli. In questa fase un processore TSEC (Tegra Security Co-processor) chiamato Falcon (FAst Logic CONtroller) viene inizializzato e da questo viene letto un valore console-specifico chiamato "device keyblob seed generation key" che è scritto appunto tramite i sopra citati eFuses; si ha accesso a questo valore soltanto utilizzando microcodice autenticato da Nvidia;
- questo valore è memorizzato nello slot 0xD del hardware security;
- dal fw 3.0.0: il keyblob seed constant 1 (probabilmente letto dall'area della partizione boot 0 chiamata "keyblob area") viene decriptato con tale valore memorizzato in 0xD (device keyblob seed generation key) generando la keyblob key seed 1;
- dal fw 3.0.0: tale keyblob key seed 1 viene decriptato con la key SBK ed il risultato è memorizzato in 0xA;
- il keyblob seed constant N (probabilmente letto dall'area della partizione boot 0 chiamata "keyblob area") viene decriptato con il solito device keyblob seed generation key per ottenere il keyblob key seed N;
- il keyblob key seed N viene decriptato con la key SBK ed il risultato è la keyblob key N che viene salvata in 0xD.
- vengono ora cancellate SBK ed SSK;
- il constant MAC key generator block (probabilmente letto dall'area della partizione boot 0 chiamata "keyblob area") viene decriptato con la keyblob key N per ottenere la keyblob MAC key N che viene salvata in 0xB;
- con la keyblob MAC key N viene eseguito l'algoritmo AES CMAC sul keyblob;
- a questo punto il CMAC ottenuto è confrontato con il valore CMAC salvato nella console: se il risultato combacia si prosegue altrimenti "panic";
- i dati del keyblob vengono ora decriptati con l'algoritmo AES-CTR utilizando la keyblob key N ed il valore CTR salvato nella console;
- la stage 2 key è caricata nello slot 0xB;
- la master static key encryption key è caricata nello slot 0xC;
- il keyblob decriptato viene cancellato
- la master static key key è generata dalla decriptazione del master static seed con la master static key encryption key ed il risultato è salvato in 0xC;
- dal fw 1.0.0 al 2.3.0: la master device key viene generata decriptando un constant block con il valore memorizzato in 0xD (che contiene il keyblob N's key 1) ed il risultato viene memorizzato nello stesso 0xD;
- dal fw 3.0.0: la master device key viene generata decriptando un constant block con il valore memorizzato in 0A (che contiene il keyblob 1's key 1) ed il risultato viene memorizzato nello stesso 0xD;
- dal fw 3.0.0: il keyslot 0xA viene cancellato.

Nelle consoles non retail il processo di generazione delle keys risulta un pochino più semplice; (aprire lo spoiler sottostante per leggerlo):

Spoiler

- Viene selezionato un master static seed;
- un blocco costante viene decriptato con la SBK per ottenere la stage 2 key e viene salvato in 0xB;
- un altro blocco costante viene decriptato con la SBK per ottenere un valore memorizzato in 0xC;
- un ulteriore blocco costante viene decriptato con la SSK per ottenere un valore memorizzato in 0xD;
- entrambe la SBK e la SSK vengono cancellate;
- il master static seed viene decriptato con il valore memorizzato nel keyslot 0xC;
- un altro constant block viene decriptato con il valore memorizzato nel keyslot 0xD e salvato nello stesso 0xD.

RIASSUMENDO
In pratica tutto questo elaborato processo è necessario al controllo di coerenza dei dati e per ottenere 5 keys:
1 - SecureBootKey (salvata nel keyslot 0xE)
2 - SecureStorageKey (salvata nel keyslot 0xF)
3 - stage 2 key (salvata nel keyslot 0xB),
4 - master static key (salvata nel keyslot 0xC),
5 - master device key (salvata nel keyslot 0xD).

CONSIDERAZIONI
- Le keys 0xC e 0xD vengono subito bloccate in lettura mentre la 0E è cancellata non appena viene decriptata la seconda parte del package1/bootloader.
- I keydata probabilmente sono identici in tutte le consoles ma ogni keyblob è univoco visto che viene generato in fabbrica partendo da una key specifica per singola console.
- La Keyblob key 1 è "speciale": oltre a decriptare il keyblob 1 viene anche utilizzata per generare la "master device key" decriptando un constant block.
- La key utilizzata per verificare il keyblob's MAC non è la keyblob key ma un valore da essa derivato: questa scelta è stata probabilmente compiuta per mitigare gli effetti di un eventuale side channel attack visto che il MAC è una parte inalterata del keyblob.
- il package1/bootloader ha memorizzate solamente le seed constants per il keyblob caricato dal firmware specifico: in questo modo la master device key puo'essere generata e non è dunque fissa.

VANTAGGI
1 - se la seconda parte del bootloader viene compromessa la prima parte puo'utilizzare una nuova static key nel keyblob. Se la stessa prima parte del bootloader viene exploitata per ottenere il keyblob, Nintendo puo'sempre sostituire il keyblob: il bootloader buggato non riuscirà cosi a decriptare il keyblob dato che il keyblob che "riconosce" sarà diverso da quello necessario.
2 - anche qualora un bug permettesse di utilizzare la SBK per generare le keys per il keyblob, le seed constants dei futuri keyblobs saranno sconosciute finchè Nintendo non rilascerà un update con i nuovi bootloaders in grado di utilizzarle di conseguenza ogni eventuale exploit andrebbe riadattato per ogni singola revisione del bootloader (sempre che il bug non venga addirittura patchato).
3 - un sistema per bypassare tutte queste protezioni è quello di dumpare gli eFuses della CPU Falcon di ogni singola console (che, come dicevamo prima, sono programmati in fabbrica e pare siano accessibili solo utilizzando microcodice firmato Nvidia) perchè da essi viene prodotta la "device keyblob seed generation key".

FIRMWARE 6.2.0

Nonostante l'impossibilità di fixare il bug in bootrom nelle consoles uscite prima di Giugno/Luglio 2018, con l'uscita dal firmware 6.2.0 Nintendo si è studiata un modo molto furbo che porta parte del meccanismo di generazione delle keys (una obfuscation a quanto pare) all'interno del processore TSEC il quale non è stato ancora violato ("package1_key_06, it's derived and erased fully within the encrypted TSEC payload") di conseguenza, fino a quando qualcuno non exploiterà anche questo ultimo baluardo a difesa della console non si potrà decriptare il package1 anche se, per il modo in cui è utilizzata, è possibile estrarre la TSEC_root_key e quindi è ancora possibile creare un custom firmwares ! In contemporanea big N ha forzato l'update del firmware della console in tutte quelle che erano attualmente collegate ai loro serves (quindi anche quelle hackerate ma che non erano state ancora bannate e non avevano bloccato l'accesso ai servers N) con il risultato che molti si sono ritrovati con il fw 6.2.0 senza aver eseguito alcun update "volontario". A dimostrazione del fatto che il sistema era ancora violabile dopo circa 48h dall'uscita del nuovo firmware sono uscite le prime hashes delle nuove keys e pochi giorni dopo anche le keys

FIRMWARE 9.0.0

Con l'uscita del firmware 9.0.0 (e successivi) è stato incluso l'aggiornamento del firmware di un chip presente sulla scheda madre della Switch chiamato internamente LOTUS3; questo controlla la comunicazione con lo slot delle cartucce di gioco ed ha anche lui degli eFuses ! Se si aggiornava a questa versione di firmware (e successivi) veniva modificato anche lo status dei suoi eFuses che NON permetteranno l'utilizzo di cartucce di gioco con firmware nferiore a 9.0.0.

Dalla versione 0.94 e successive il cfw Atmosphere si adoperò per proteggere le consoles leggendo lo status dei fuses del firmware della console e la versione del firmware che sarebbe stato avviato: se il firmware avviato era il 9.0.0 ed il numero di eFuses bruciati risultava inferiore a quelli che sarebbero dovuti essere bruciati nel fw 9.0.0 attivava l'opzione contenuta nel file BCT.ini chiamata "NOGC" (=NO Game Card) che veniva dunque settata ad 1 (cioè "attiva") disattivando lo slot delle game card per evitare che il suo firmware venisse aggiornato.

Se non si aveva interesse a perdere la possibilità di utilizzare lo slot delle cartucce su un firmware minore del 9.0.0 (ma di poterlo utilizzare normalmente su fw superiore o uguale al 9.0.0) questa misura di sicurezza non sarebbe servita a molto.

EASTER EGG

La console contiene di default un emulatore NES con titolo chiamato "flog" che, letto al contrario, è golf; il suo eseguibile ha infatti al suo interno la rom del gioco "golf" per NES, gioco concepito dal compiano Satoru Iwata, ideatore e guida di numerosi titoli di successo di casa N. Ma avviare il gioco non è così semplice: i programmatori hanno fatto si che il suo avvio sia dettato da specifiche condizioni: avere la console con data impostata l'11 Luglio (data della morte di Iwata) ed effettuare un movimento specifico con i Joy-Cons; tale movimento rappresenta il gesto "direct to you" che Iwata mostrava nelle presentazioni (vedi spoiler sottostante):

Spoiler

Immagine tratta da questo video.

Se volete sapere esattamente come avviarlo seguite questo video (attenzione! se la Switch è già stata collegata ad Internet potrete giocare a questo gioco solamente l'11 Luglio di ogni anno finchè qualcuno non riuscirà a bypassare questo controllo sulla data).

CONCLUSIONE

Anche se l'accesso a basso livello sembra essere ancora limitato ai pochi devs della scena, questa volta Nintendo sembra non aver imparato dalle lezioni del passato: persistere con l'utilizzare il WebKit nonostante il browser si sia dimostrato essere una grande porta di accesso per vari sistemi già da prima dell'uscita in commercio della console non è stato qualcosa di azzeccato.

Aver basato il sistema su di un SoC "noto" con possibilità di studiare le sue caratteristiche tecniche grazie ai documenti in circolazione ha di fatto facilitato il lavoro dei reversers.

In ogni caso, come già accaduto per 3dbrew, tutto ciò che viene scoperto è minuziosamente raccolto nel sito switchbrew; questo livello di dettaglio nella documentazione del sistema non si è purtroppo avuto con WiiU perchè i devs (in particolare dimok e FIX94) non avevano gran desiderio di dedicare tempo a documentare mentre i più attivi sul fronte Switch (specialmente plutoo e yellow8) sembrano essere di tutt'altra idea.

 

Con tutta probabilità si visto che gli eFuses sono interni al SoC e sono dunque inaccessibili/immodificabili. Quando modifichi il firmware vai a modificare solo alcuni dati scritti in NAND, è poi il sistema di sicurezza a gestire il "blown" degli eFuses. L'unico sistema sarebbe quello di aggirare il controllo che comunque avviene in un precocissimo stage di avvio della console quindi... la vedo dura... anche se ipoteticamente Nintendo potrebbe aver tralasciato qualcosa (bugs) prima del controllo...