Home News Il team Fail0verflow esce allo scoperto, rivelato ShofEL2, l’exploit per Tegra...

[Scena Switch] Il team Fail0verflow esce allo scoperto, rivelato ShofEL2, l’exploit per Tegra X1 e Nintendo Switch

379
0

La scena Switch sta vivendo uno dei momenti più importanti della sua “breve” storia, e a poco più di un anno dal lancio della console Nintendo.

Tutto sembrerebbe essere iniziato ieri, quando un utente anonimo ha pubblicato sul Pastebin il BootRom del SoC Tegra X1. Si tratta di uno dei più importanti exploit scoperti fino ad oggi, che dovrebbe permetterci di prendere il controllo anticipato dell’intero sistema.

Appare ovvio come questo tipo di exploit possa in breve tempo portare all’esecuzione di codice arbitrario, e alla pirateria, forse per questo il team Fail0verflow non ha voluto divulgarlo, almeno fino ad oggi, in quanto anche il team Xecuter potrebbe rilasciare a breve un modchip.

L’articolo del team Fail0verflow

Benvenuti in ShofEL2 e Switch Linux, lo stack di avvio di fail0verflow per la non modifica, l’esecuzione di codice universale e Linux su Nintendo Switch (e potenzialmente su qualsiasi piattaforma Tegra X1).

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 sulle vulnerabilità per timore che vengano usati principalmente per la pirateria piuttosto che per l’avvio di homebrew.

Detto questo, il primo bug nel bootrom di Tegra era così ovvio che molte persone lo hanno scoperto in modo indipendente, e nella migliore delle ipotesi, un rilascio da parte di altre squadre di homebrew era quasi inevitabile, mentre nel peggiore dei casi, una certa squadra di modchip potrebbe fare la prima mossa.

90 giorni fa, abbiamo iniziato un 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 fare, ma poi qualcuno ha pubblicato il bug due giorni prima della scadenza dei 90 giorni. Oh bene. Sì, questo è lo stesso bug che è stato sfruttato in fusée gelée e che è stato fatto trapelare da qualche altro gruppo (ma l’abbiamo trovato prima noi).

Di cosa si tratta comunque?

Il SoC Tegra X1 (noto anche come Tegra210) all’interno del Nintendo Switch contiene al suo interno un bug 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 USB, progettata per il flashing iniziale dei dispositivi Tegra e il ripristino dei dispositivi in ​​brick. Normalmente, la modalità RCM consente solo il caricamento delle immagini firmate, ma grazie al bug è possibile eseguire codice arbitrario.

Questo significa che per ottenere l’esecuzione del codice sulla Switch è necessario eseguire prima due operazioni completamente indipendenti:

  • Entrare in modalità RCM.
  • Eseguire l’exploit USB.

Queste due operazioni possono essere eseguite in diversi modi. Si noti che questo è ciò che gli utenti di iPhone chiamerebbero un “jailbreak tethered”, in quanto deve essere eseguito ad ogni nuovo avvio tramite USB.

Poiché questo bug si trova nella ROM di avvio, non può essere riparato senza una revisione hardware. Nintendo può correggere i bug di boot della ROM solo durante il processo di produzione.

Poiché è molto facile da usare, consente l’estrazione di tutti i dispositivi e i segreti, inclusa la ROM di avvio e tutte le chiavi di crittografia.

Può anche essere usato come dispositivo o dispositivo (ad es. Fusibili bruciati), 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.

Potrete scegliere di eseguire il dual-boot di Linux (tramite l’exploit USB) e il sistema operativo Switch (tramite il normale boot) impunemente, per sempre, se non si va a modificare la memoria interna (ad esempio, puoi archiviare il filesystem di Linux abbiamo una seconda partizione della scheda SD o un’altra scheda SD).

Accesso alla modalità RCM

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

  • Da prima dell’esecuzione del codice in modalità kernel sul sistema, utilizzando un exploit WebKit e un kernel exploit come entry-point.
  • Se l’eMMC viene rimosso, Tegra entrerà in modalità RCM all’avvio.
  • Se si tengono premuti i pulsanti Volume su, Home e Accensione sullo Switch (senza collegare i joy-con) allo stesso tempo.

Nota che il pulsante Home del Joy-Con non funzionerà qui in quanto scollegato dalla console. Il SoC Tegra riceve l’input per la pressione del pulsante Home sulla connessione del Pin 10 (il pin più arretrato), posto all’interno del Joy-Con destro.

In tal caso è possibile utilizzare un pezzo di filo per creare un ponte, ad esempio una semplice vite sulla guida (più semplice) o con i pin 10 e 7 (oppure 1) insieme (10 e 9 non funzioneranno).

Volendo è possibile utilizzare un connettore USB (che ha lo stesso pitch pin dei connettori Joy-Con) o utilizzarlo come tassello per il connettore. Quest’ultimo è anche utile, perché i rail Joy-Con sono UART e usiamo la console per coreboot, u-boot e Linux.

Esecuzione dell’exploit USB-based

L’exploit USB richiede un host USB. L’exploit richiede anche un trasferimento molto lento, che sfortunatamente alcuni non sono soddisfatti, in tal caso è possibile utilizzare 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.

Questo potrebbe anche essere eseguito da un telefono Android (almeno quelli con controller xHCI), sebbene sia anche un esercizio per il lettore. Punti bonus per il dispositivo Tegra. Come un altro Switch.

Linux su Switch boot chain

Il nostro boot chain è al 99% open source, basato sul boot chain del Pixel C (perché chi vuole usare il fork del kernel L4T di Nvidia e bootloader proprietari?). Sembra questo:

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

L’unico componente closed-source, che è opzionale, è il codice di allenamento della memoria DDR4 Tegra210. Per ragioni sconosciute, questo è rilasciato come un blob binario per Pixel C, che viene copiato in memoria e saltato dentro. 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

Assicuratevi di ottenere un file tegra_mtc.bin con questo SHA256:

edb32e3f9ed15b55e780e8a01ef927a3b8a1f25b34a6f95467041d8953777d21

Sebbene questo blob contenga tabelle codificate e un entry-point “do everything” per Pixel C, è possibile passare a uno dei DDR4 più popolari al mondo sullo switch. Senza questo blob, lo stack funzionerà ancora, ma la memoria verrà eseguita a ~200Mhz, il che inutile dire prestazioni piuttosto invalidanti.

Il processo di avvio ha questo aspetto:

  1. Il Tegra avvia la Boot Rom 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, utilizzando un comando RCM.
  3. L’exploit viene attivato, causando il salto della ROM in cbfs.bin.
  4. Il codice host passa quindi alla modalità server CBFS, servendo dinamicamente coreboot.rom tramite la pipe USB RCM a Tegra.
  5. cbfs.bin utilizza questo server CBFS per richiedere il primo 28KiB di coreboot, che è il bootblock 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 la SDRAM (alla velocità di avvio fissa di base) e altre periferiche.
  8. ROMstage scarica quindi l’intera ROM coreboot nella SDRAM (utilizzando ancora le routine USB della modalità ROM di avvio RCM) e passa a CBFS con RAM.
  9. Il romstage carica ora 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 il training 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. Utilizzando imx_usb_loader dal lato del PC, puoi caricare payload arbitrari in U-Boot, come un kernel Linux e il suo initramfs, ed eseguirli.

Il codice

Dai un’occhiata ai nostri repository Git:

Spiacenti, non dovremmo avere una guida per l’uso di questo prodotto, né dovrebbero, molto probabilmente, 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 di Git è piuttosto brutta, non abbiamo ancora avuto la possibilità di ripulirla.

Prossimamente

Correggere quanto più possibile la relazione sull’exploit, la storia sul porting di Linux (sì, c’è di più rispetto a un semplice driver di pannello), stato upstreaming, DDR4 e altro. Siamo piuttosto cattivi nello scrivere blogpost.

Ci sono molti bug di avvio della ROM, molti dei quali sono stati trovati da più persone.