Sei sicuro che K1 sia vulnerabile? Ho fatto una rapida ricerca e tutto quello che ho trovato è stato che "NVIDIA Tegra X2, che è stata lanciata nel 2016, e successivamente i sistemi Tegra su un chip (SOC) come Xavier, non sono interessati da questo problema." dal avviso di sicurezza di Nvidia a>, ma nessuna conferma esplicita. Supponendo che, andiamo avanti.
Sulla scrittura di fail0verflow del loro exploit Tegra RCM ShofEL2 e su come usarlo sullo Switch Nintendo , ha detto che il metodo preferibile per mettere lo switch in modalità RCM è premere Volume-Up, power, e il "pulsante home" tutto in una volta (gli altri metodi stanno facendo il backup del bootloader / rimuovendo fisicamente il flash e riavviandolo in RCM da Software). Hanno detto che il pulsante home non era il tasto home sul Joy-Con, ma piuttosto il 10 th pin sul connettore Joy-Con destro (quel pin e il ground sono dove sarebbe connesso se era un pulsante, comunque). Secondo Wikipedia (e fail0verflow nel post del blog che ho collegato in precedenza), la maggior parte dei dispositivi Tegra funziona su Android. In quanto tale, credo che questo pin 10 th sia connesso allo stesso pin GPIO della CPU a cui è collegato il pin di casa su un Android alimentato da Tegra. Quindi prova, spegni il tablet e premi il pulsante di accensione mentre tieni premuto il tasto Home in basso e alza volume. Se sembra ancora spento, collegalo al computer. Quando collego il mio switch al mio sistema Linux mentre è in modalità RCM, il comando lsusb
lo elenca come "NVIDIA Corp." (È elencato come 'Nintendo, Co. Ltd.' quando lo Switch viene normalmente avviato nel sistema operativo Switch.) Se si utilizza Windows, provare a controllare Gestione periferiche. Puoi utilizzarlo per verificare di aver portato il tablet in modalità RCM.
Questo vale per qualsiasi cosa, non solo per i Tegra: anche se pezzi di codice condividono una vulnerabilità, le differenze più piccole possono far sì che un exploit scritto per uno non funzioni per l'altro (questo è particolarmente vero per cose di basso livello come un BootROM ). D'altra parte, nel file readme nel repository ShofEL2 di fail0verflow, hanno detto che l'exploit ' probabilmente funziona su Ouya ', che è un dispositivo Android con Tegra 3 (e il Tegra K1 è probabilmente più simile all'X1 rispetto al Tegra 3 sia all'X1).
Non so se hai in mente un payload; in caso contrario, è possibile utilizzare probabilmente un'immagine del kernel esistente creata per il dispositivo. (Anche se non lo fai alla fine, può essere utile assicurarsi che l'exploit abbia funzionato prima di investire il tuo tempo nella creazione del tuo kernel.) Il seguente si applica solo se usi un'immagine del kernel Android: Se usi sfruttare per avviare il kernel predefinito con la cmdline predefinita, verrà (probabilmente) avviato normalmente. Per assicurarti che l'exploit abbia funzionato, prova a passare un parametro init=
non valido o qualcos'altro per causarne il panico. (Non so se i kernel di Android sono generalmente compilati con CONFIG_VT=y
, e se non lo fai non vedrai un messaggio di panico, altrimenti prova a eseguire un semplice eseguibile che crea un file su una scheda SD, per esempio.)
Fammi sapere quali risultati hai, sono anche interessato a portare questo exploit. (Possiedo solo uno Switch, ma stavo pensando di acquistare un RT di Microsoft Surface Tegra 3 e provare l'exploit su questo. Surface RT utilizza UEFI Secure Boot per garantire che l'utente finale utilizzi solo Windows RT.)
Trovo davvero divertente che questa vulnerabilità sia esistita da molto tempo (almeno dal lancio di X1) e nessuno se ne è accorto fino allo Switch (e quando lo hanno fatto, tre gruppi separati l'hanno scoperto intorno allo stesso tempo).