[SWITCH]ShofEL2,Fusée Gelée e Switch Linux :la modifica alla Nintendo Switch è servitaTempo di lettura : 6 min

Il leak del bootrom su Tegra X1, l’esecuzione di codice universale e Linux sul Nintendo Switch (e potenzialmente su qualsiasi piattaforma Tegra X1)ha creato una reazione a catena da parte di molti sviluppatori della scena hacking della console Nintendo Switch e forse anche l’abbandono di alcuni sviluppatori di talento come Plutoo.Il banale hardmod presentato ieri ha anticipato l’uscita di Fusée Gelée ,un bootrom exploit che funziona su tutte le versioni del firmware e tutte le console Nintendo switch che sono stati rilasciati finora (questo non si applicherà in futuro ai nuovi sistemi “Mariko” con SoC T214).Il Team fail0verflow ha spiegato sul blog ufficiale tutte le fasi che ha portato al rilascio e una premessa da leggere attentamente.Abbiamo tradotto l’intero articolo in italiano e qualche errore di traduzione è sempre presente.

Premessa

Il tutto è solo per gli sviluppatori . Non ci sono ancora payload avviabili che sarebbero interessanti per gli utenti finali. Inoltre, il tutto è piuttosto costoso e consigliamo quindi a tutti di aspettare. Tuttavia, il lavoro sul Custom Firmware Atmosphère è in pieno svolgimento.

Scegliere se rilasciare un exploit o meno è una scelta difficile. Viste le nostre esperienze con le console del passato, siamo stati cauti nel rilasciare dettagli o exploit di vulnerabilità per timore che vengano usati principalmente per la pirateria piuttosto che per l’homebrew. Detto questo, il 1 bug di bootrom di Tegra è così ovvio che molte persone lo hanno scoperto indipendentemente; nella migliore delle ipotesi, un rilascio da parte di altre squadre di homebrew è inevitabile, mentre nel peggiore dei casi, una certa squadra di modchip di pirateria potrebbe fare la prima mossa. 90 giorni fa, abbiamo iniziato il processo di divulgazione responsabile con Google, in quanto i chip Tegra vengono spesso utilizzati nei dispositivi Android. La scadenza per la divulgazione è ormai scaduta. Il bug verrà reso pubblico prima o poi, probabilmente prima, quindi potremmo anche rilasciare ora insieme alla nostra catena di avvio Linux e al kernel tree, per rendere molto chiaro che lo facciamo per divertimento e homebrew,

… è quello che stavamo progettando di dire, ma poi qualcuno ha pubblicato il bug 0days due giorni prima che la nostra finestra di divulgazione di 90 giorni scadesse il 25 aprile. Oh bene. Sì, questo è lo stesso bug che è stato sfruttato da fusée gelée e che è stato trapelato da qualche altro gruppo (ma l’abbiamo trovato prima ).

Questo sarà un po ‘approssimativo dal momento che non avevamo il post su blog / repos pronti , ma senza ulteriori indugi, ecco lo scoop.

VIDEO

Di cosa si tratta comunque?

Il SoC Tegra X1 (noto anche come Tegra210) all’interno del Nintendo Switch contiene un bug sfruttabile che consente di prendere il controllo dell’esecuzione anticipata, ignorando tutti i controlli delle firme. Questo bug si trova in modalità RCM, che è una modalità di ripristino basata su USB, progettata per il flashing iniziale dei dispositivi Tegra e il ripristino dei dispositivi briccati. Normalmente, la modalità RCM consente solo il caricamento delle immagini firmate, ma grazie al bug è possibile eseguire codice arbitrario.

Ciò significa che per ottenere l’esecuzione del codice sullo Switch è necessario fare due cose completamente indipendenti:

  1. Entrare in modalità RCM
  2. Eseguire l’exploit basato su USB

Ognuno può essere realizzato in diversi modi indipendenti. Si noti che questo è ciò che gli utenti di iPhone chiamerebbero un “jailbreak cablato”, in quanto deve essere eseguito su ogni avvio tramite USB.

Poiché questo bug si trova nella ROM di avvio, non può essere riparato senza una revisione hardware, il che significa che tutte le unità Switch esistenti oggi sono vulnerabili, per sempre. Nintendo può correggere gli errori di Boot ROM solo durante il processo di produzione. Poiché la vulnerabilità si verifica molto presto nel processo di avvio, consente l’ estrazione di tutti i dati e i segreti del dispositivo , inclusa la ROM di avvio e tutte le chiavi di crittografia. Può anche essere usato per sbriccare qualsiasi dispositivo Tegra purché non abbia subito danni all’hardware o abbia subito modifiche irreversibili (ad es. Fusibili saltati). E poiché si tratta di un bug in fase di avvio che non richiede il contatto con la memoria eMMC integrata, il suo utilizzo è completamente inosservabile al software esistente. Puoi eseguire il dual-boot di Linux (tramite l’exploit USB) e il sistema operativo Switch (tramite il normale boot) impunemente, per sempre, se non provi a modificare la memoria interna (ad esempio, puoi archiviare il filesystem di Linux su una seconda partizione della scheda SD o un’altra scheda SD).

Accesso alla modalità RCM

Nello Switch, la modalità RCM può essere inserita in più modi:

  1. Da precedente esecuzione del codice in modalità kernel sul sistema, ad esempio utilizzando un WebKit exploit e un kernel exploit come punti di ingresso
  2. Se l’eMMC viene rimosso, Tegra entrerà in modalità RCM all’avvio
  3. Se si tengono premuti i pulsanti Volume su, Home e Accensione sullo Switch (non con joy-cons) allo stesso tempo.

Nota che il pulsante home del Joy-Con non funzionerà qui. Forse ti starai chiedendo il pulsante HOME del Nintendo Switch stesso. A quanto pare, quello che Tegra chiama il pulsante Home è in realtà collegato al Pin 10 (il piedino più arretrato) sul connettore Joy-Con sul lato destro. Puoi semplicemente utilizzare un semplice pezzo di filo per colmarlo, ad esempio una vite sulla guida (più semplice) o i pin 10 e 7 (o 1) insieme (10 e 9 non funzioneranno). Puoi anche stampare in 3D un piccolo jig per farlo facilmente, usando l’interno di un connettore Micro USB (che ha lo stesso pin pitch dei connettori Joy-Con), o usa un Joy-Con smontato per il connettore. Quest’ultimo è anche utile, perché i rail Joy-Con sono UART e utilizziamo la porta joy-con con la mano destra come console per coreboot, u-boot e Linux.

Esecuzione dell’exploit basato su USB

L’exploit USB richiede un host USB. L’exploit richiede anche l’utilizzo di trasferimenti di controllo molto lunghi, che sfortunatamente alcuni sistemi operativi non sono soddisfatti. È possibile utilizzare vanilla Linux su un PC con un controller xHCI (USB 3.0 o qualsiasi porta USB sui sistemi più recenti) o un PC con un controller EHCI (USB 2.0) e questa patch del kernel.

Ciò potrebbe anche essere eseguito da un telefono Android (almeno quelli con controller xHCI), sebbene il porting dell’exploit su Android venga lasciato come un esercizio per il lettore. Punti bonus per farlo da un altro dispositivo Tegra. Come un altro Nintendo Switch

Linux su Switch catena di avvio

La nostra catena di avvio è al 99% open source, basata sulla catena di avvio di Pixel C (perché chi vuole utilizzare il fork del kernel L4T e i bootloader proprietari di Nvidia?). Sembra questo:

BootROM Exploit → loader coreboot → coreboot → firmware affidabile ARM → coreboot → u-boot → Linux

L’unico componente closed-source, che è opzionale, è il codice della memoria DDR4 Tegra210. Per ragioni sconosciute, questo è rilasciato come un blob binario per Pixel C, che viene copiato in memoria e inserito all’interno. Questo blob può essere ottenuto dall’immagine di fabbrica di Pixel C come segue:

./build/util/cbfstool/cbfstool bootloader-dragon-google_smaug.7900.97.0.img extract -n fallback/tegra_mtc -f tegra_mtc.bin

Assicurati di ottenere un tegra_mtc.bin con questo SHA256:

edb32e3f9ed15b55e780e8a01ef927a3b8a1f25b34a6f95467041d8953777d21

Sebbene questo blob contenga tabelle codificate e un punto di accesso “do everything” per Pixel C, è possibile passare da un livello più in profondità all’albero delle chiamate e passare in tabelle personalizzate, che è ciò che fa il nostro coreboot patchato per configurare DDR4 sullo switch . Senza questo blob, lo stack funzionerà ancora, ma la memoria verrà eseguita a ~ 200Mhz, il che inutile con prestazioni piuttosto invalidanti.

Il processo di avvio ha questo aspetto:

  1. Il Tegra avvia la ROM di avvio sul core BPMP (arm7) ed entra in modalità RCM.
  2. Il codice di exploit USB basato su host mette un piccolo (~ 2.5K) caricatore (cbfs.bin) nella memoria SRAM, usando un comando RCM.
  3. L’exploit viene attivato, facendo in modo che la ROM salti in cbfs.bin.
  4. Il codice host passa quindi alla modalità server CBFS, servendo dinamicamente coreboot.rom tramite la USB RCM a Tegra.
  5. cbfs.bin usa questo server CBFS per richiedere il primo 28KiB di coreboot, che è il boot boot di coreboot, in SRAM, quindi vi salta sopra.
  6. Il bootblock coreboot inizializza le periferiche di base, quindi carica il romstage in SRAM utilizzando il servizio CBFS da USB e salta ad esso.
  7. Il romstage di coreboot inizializza SDRAM (alla velocità di avvio fissa di base) e altre periferiche.
  8. Il romstage scarica quindi l’intera ROM coreboot in SDRAM (utilizzando ancora le routine USB della modalità Boot ROM RCM) e passa a CBFS con RAM.
  9. Ora il romstage carica il ramstage (dalla RAM CBFS), avvia CCPLEX (Cortex-A57) e chiude il BPMP.
  10. Ora su CCPLEX (su EL3), il ramstage di coreboot esegue il resto dell’inizializzazione di base del sistema, incluso l’addestramento DDR4 se è disponibile il blob MTC.
  11. Il ramstage ora salta in ARM Trusted Firmware, che inizializza l’implementazione di TrustZone. Questo è necessario per fornire determinati servizi OS.
  12. Il firmware Trusted ARM ritorna alla ramstage coreboot, ora in esecuzione in modalità EL2.
  13. Il ramstage carica e salta al suo carico utile finale, U-Boot.
  14. U-Boot si avvia, inizializza un po ‘più di hardware e, per impostazione predefinita, passa alla modalità di download USB, con il proprio driver USB.
  15. Usando imx_usb_loader dal lato del PC, puoi caricare arbitrari payload U-Boot, come un kernel Linux e il suo initramfs, ed eseguirli.

Il codice

Dai un’occhiata ai nostri repository :

Spiacenti, non abbiamo una guida per l’utente medio per usarlo, né dovrebbero esserci, dal momento che molte cose sono molto approssimative. Se sei seriamente interessato allo sviluppo, dovresti essere in grado di capire da solo o porre domande su IRC.

La storia del Git è piuttosto brutta, perché non abbiamo ancora avuto la possibilità di pulire le cose. Per favore non fixare troppo.

Prossimamente

Riscontri corretti sull’exploit, storie di porting di Linux (sì, c’è di più rispetto a un driver di pannello ;-)), stato upstreaming, come bdshit folle DDR4 è, e altro ancora. Siamo piuttosto cattivi nello scrivere blogpost.

¹ Ci sono in realtà molti bug di Boot ROM, molti dei quali sono stati trovati da più persone.

Ulteriori informazioni e tutorial
fail0verflow e Gbatemp

hitech

Ti è piaciuta la notizia? Supporta theheroGAC su Patreon!

theheroGAC

Nato negli anni 80 con la passione dei videogiochi e delle console.Il mio primo home computer è l'Amiga 600 regalato a 10 anni.Amo aiutare le persone in difficoltà e scrivere notizie sulle console.Studio all'università e il sito Games And Consoles è la mia passione.Per gli amici mi potete chiamare Ciccio

Ti potrebbe anche interessare

Rispondi