ARM9LoaderHax Opzioni

[Aurora Wright]

Da una settimana circa è praticabile per gli "utenti comuni" (senza hardmod per avere accesso alla NAND del 3DS dal computer) l'utilizzo di un nuovo metodo per avviare codice non firmato sul processore ARM9 (il massimo livello di privilegi) su 3DS. Per fare questo vengono sfruttate una serie di sviste di Nintendo.
Piccolo write-up:
"Su ogni 3DS c'è un software nella BootROM (che è un po' il bootloader del 3ds, la prima cosa che parte. tuttora non sappiamo cosa ci sia dentro, si auto-disattiva subito appena fatto il proprio lavoro). Questo programma carica il kernel (in realtà i kernel sono due, ma per semplicità parlerò solo di quello per l'ARM9, quello per il processore principale - ARM11 - parte dopo e non ha alcuna importanza in questo exploit). Sul 3DS, il kernel è in due partizioni uguali della memoria interna, chiamate "FIRM0" e "FIRM1". Ce ne sono due perché se una è corrotta, l'altra fa da backup . Fa così: carica il kernel da FIRM0. Controlla che sia integro. Se è integro, lo avvia, sennò lo carica da FIRM1 (se poi anche questo non è valido, schermo blu). Un primo problemino è che non azzera la memoria prima di fare questo, ce lo mette sopra.

Ogni console ha una piccola memoria non riscrivibile da 256 byte (microscopica) chiamata OTP, diversa per ogni console. Separata dalla memoria interna (NAND). (Si è sicuri che la bootrom la utilizzi per calcolare in qualche modo quelle chiavi di criptazione/decriptazione che sono diverse da console a console). Un altro utilizzo di questi 256 bytes lo fa il kernel del New 3DS. Fa questo: parte, fa una formula matematica (hash) su quei bytes e ne esce un numero (che cambia da console a console quindi). Quel numero viene usato come chiave per decriptare un piccolo spazio nella NAND, che contiene alcune chiavi. Poi prende una di queste chiavi, e ci decripta il resto del kernel, e lo avvia. (il primo pezzo di kernel che fa questo si chiama "arm9loader" giustamente, perché decripta e carica il resto)

Il problema è questo con il kernel del New 3DS: l'arm9loader non controlla che il resto del kernel sia stato decriptato correttamente...
Se c'è un'altra key a caso, decripta in "della roba sensa senso" e la avvia!
Quindi hanno avuto questa idea: metti un FIRM0 più grosso che alla fine ha del codice scritto da te. la bootrom lo carica, verifica che ovviamente NON è integro, ci mette il FIRM1 sopra che è più piccolo. Il FIRM1 dev'essere originale della Nintendo. La bootrom lo accetta e lo avvia. Parte l'arm9loader. Calcola dall'otp la chiave per decriptare l'altra chiave dalla NAND, e con questa poi decripta il resto del kernel e lo avvia. Hanno (con il bruteforce, cioè con programmi che hanno provato ogni singola chiave fino a ottenere il risultato voluto) trovato una chiave che decriptava il kernel in modo tale che all'inizio del "kernel decriptato in dati casuali" ci fosse un'istruzione che effettuava un "salto" nel mezzo del nostro codice (dopo il FIRM1). (Ricordate? C'è ancora un pezzo del FIRM0 dopo il FIRM1, con il nostro codice!) Basta avere l'OTP per criptare quella chiave correttamente per la tua console (facendo l'inverso di quello che fa la console per ricavarla).

L'OTP ormai viene disattivato permanentemente (fino al riavvio della console) quando il kernel finisce di usarlo. PERO' Nintendo fino al 3.0 si è scordata di disattivarlo, e appena usavi un exploit per prendere il controllo dell'ARM9, lo potevi salvare. Quindi fai il downgrade al 2.1, lo salvi, e poi ritorni ripristinando la NAND (si può fare anche sul New 3DS, "convertendo" la NAND in quella di un Old).

Con questo metodo hai il controllo della console immediatamente all'avvio. Va anche sull'Old 3DS, dato che il kernel del New funziona quanto basta per arrivare al punto di far scattare l'exploit."

L'exploit è stato implementato pubblicamente dall'italiano delebile, dopo essere stato scoperto da plutoo.
La guida per avere il nuovo hack sulla propria console è qui (viene usato Luma3DS come CFW): https://github.com/Plailect/Guide/wiki/Get-Started
I vantaggi sono: è possibile usare la SysNAND aggiornandola al 10.5 al posto della emuNAND, la percentuale di avvio è pari al 100% per la natura dell'exploit, tempi di avvio zero, usando la SysNAND è poi possibile installare i propri giochi GBA o DSi solo sulla SysNAND senza dover fare una doppia installazione emu-sysNAND.

Messaggio modificato da Aurora Wright il Tuesday 17 May 2016 - 21:24