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.

[pensiero]...Meglio tacere col rischio di sembrare stupidi che parlare, fugando ogni dubbio...[/pensiero]

...AAAA ...AAAAAMMM ...AMACABANANA!!!
...
...
...
D'OH!!!


Seriamente ragazzi, tanta stima per chi ha ideato questa tecnica, ma soprattutto per chi ha capito qualcosa della spiegazione

Complimenti aurora per la spiegazione e per il tuo lavoro sul progetto ReiNand!! Spero, con il tempo, che il procedimento possa semplificarsi e che nascano delle guide in italiano ad hoc per chi come me non sa nemmeno da che parte iniziare a smanettare 😂 Comunque bravissima ancora!! Veramente!!

Spiegazione fantastica! Ma il menuhax sarà accessibile dopo aver inserito l' ARM9LoaderHax?

Brava Aurora, ottima spiegazione, anche se poco comprensibile dai più nabbi come me XD

Il menuhax non serve più, il "cfw" parte senza ulteriori exploit (tutto ciò che serve a un CFW è girare sull'ARM9, proprio ciò che consente l'exploit). E in tempi rapidissimi anche.

Salve a tutti.
innanzitutto ringrazio per aver appreso questo metodo con questo post.
mi sono poi informato e seguendo una guida, presente in italiano su un altro forum che ha praticamente tradotto questa, e sono riuscito a farlo girare sul mio n3ds.
pensavo che si potrebbe portare la guida anche qui per aggiungerla alle altre già presenti nel forum.

Chiedo qui, perchè aprire un'altra discussione sull'argomento mi pare ridondante ...
Avendo installato RxTools sul mio 3DSXL (emuNAND 11.0 - sysNAND 9.2), conviene passare a questo A9LH+Luma3DS?
In caso affermativo, c'è un modo per fare il tutto senza perdere dati e cose simili?

Sì, conviene.
Seguendo la guida di Plaitec la tua emunand si trasforma in sysnand (quindi non perdi nulla).
Hai un tempo di boot più veloce
Potrai fare i prossimi aggiornamenti direttamente dalle impostazioni, senza preoccupazioni di emunand, sysnand ecc.
Inoltre l'emunand sparisce e recuperi un po' di spazio sulla sd.
Se fai tutti i backup della guida, sarà molto molto difficile brickare e/o ritrovarsi con una console non hackabile (anche in futuro).
3ds Plailect/Guide Wiki · GitHub

Grazie per i chiarimenti. Appena ho un po' di tempo, mi leggo tutto per bene e mi metterò all'opera
Edit: Ok, mi sa che ho fatto un po' casino ... Avevo emuNAND con rxTool alla 11.0. Seguendo la guida dal principio, mi dice di fare backup di tutto e quindi installare la RedNAND (che di conseguenza, sovrascrive la emuNAND e qui credo anche di aver "perso" tutto mi pare ...), però poi arrivando al punto 4, mi dice che va bene anche se ho la emuNAND e quindi diciamo che ho fatto il casino per niente? Ad ogni modo, per sicurezza ho già fatto backup di: sysNAND, SD ed emuNAND tramite emuNANDTool

Sì, l'EmuNAND andava comunque benissimo. Come è scritto in questa pagina della guida, se avevi già un'EmuNAND (o una RedNAND) potevi partire direttamente dal punto 4.

Visto che è un processo lungo (e rischioso se non si segue esattamente la guida), il mio consiglio è di leggere bene tutte le pagine prima ancora di toccare il 3DS.

Bene, ho seguito tutti i passi e credo di esserci riuscito. Il SYS prima del 11.0.0.33 indica che l'hax é installato?
Inoltre, c'é un modo per togliere il menuhax (schermata viola che ti fa scegliere tra rxtools e homebrew) quando avvio l'homebrew launcher?
C'é qualche file di quelli usati nella guida che posso togliere dalla SD? Perché attualmente é messa un casino
Edit: Stranamente, all'ultima pagina, non mi si apriva l'immagine che mostrava il contenuto della SD dopo aver effettuato il tutto ...