[PSVITA]HENkaku Ensō:i firmware compresi tra 3.61 e 3.65 sono ancora vulnerabili lo conferma Yifan Lu

Era il 29 Luglio 2017 quando HENkaku Ensō ha segnato definitivamente l’hack permanente sul firmware 3.60 PSVITA.Oggi lo sviluppatore  Yifan lu ha spiegato in un interessante e lungo write-up,le varie fasi prima di arrivare al vero hack.Noi di Games and Consoles abbiamo tradotto in italiano l’intero articolo,ricordo che qualche errore è sempre presente

HENkaku Ensō la spiegazione…..

Quando noi (molecule) abbiamo decodificato il firmware di Vita anni fa, una delle prime vulnerabilità che abbiamo trovato era nel bootloader. Era una vulnerabilità particolarmente interessante perché era in fase di avvio (prima che ASLR e alcune altre funzionalità di sicurezza fossero correttamente inizializzate) e perché consentiva di applicare una patch al kernel prima dell’avvio (che espande ciò che può essere fatto con gli hack). Sfortunatamente, l’exploit richiedeva la scrittura sull’MBR della memoria interna, che richiede i privilegi del kernel. Ciò significa che dovremmo sfruttare il kernel ( HENkaku) per installare l’exploit. (Prima di chiedere, no, non è possibile installare con una mod hardware perché ogni PSVita ha la sua NAND crittografata con una chiave univoca. Inoltre, non ci sono testpoint per la NAND, quindi flashare è notoriamente difficile … non così semplice come il 3DS .)

Vulnerabilità

La vulnerabilità è un overflow del buffer dovuto al bootloader che assegna staticamente un buffer di cache per le letture di dispositivi eMMC utilizzando una dimensione di blocco costante di 512 byte ma quando carica effettivamente i blocchi nella cache, utilizza il campo a dimensione di blocco (controllato dall’utente) in l’intestazione della partizione FAT. Lo abbiamo sfruttato sovrascrivendo un puntatore a funzione che esiste dopo il buffer della cache nella classica modalità di overflow del buffer. La vulnerabilità è relativamente semplice, ma abbiamo dovuto utilizzare alcuni trucchi per sfruttarla (specialmente nel tentativo di eseguire il debug del crash). xyz ne parlerà più in dettaglio nel suo post sul blog (TBD), mi concentrerò di più su ciò che accade dopo aver preso il controllo.

Per quanto ne sappiamo, 3.61-3.65 sono ancora vulnerabili. Tuttavia, come ho detto all’inizio, è necessario un exploit del kernel per modificare l’MBR (necessario per l’exploit) e per scaricare il bootloader non sicuro (per trovare gli offset da correggere). Nessuno del team molecule è interessato a hackerare qualcosa oltre il 3.60 perché Sony non sta spedendo nuove console a livello globale con le versioni più recenti del firmware, chiunque desideri eseguire homebrew può scegliere di non aggiornarlo. Tuttavia, se sei già aggiornato alle precedenti 3.60 e desideri eseguire homebrew, probabilmente in futuro, il mio consiglio è di non aggiornare OLTRE il  3.65 perché qualcun altro potrebbe trovare un nuovo exploit del kernel e permetterti di installare questo hack in 3.65. Non trattenere il respiro però. Chiunque può scaricare e invertire il codice del kernel con HENkaku, quindi forse ci sarà una motivazione in più per gli estranei a trovare un nuovo hack ora.

Poiché il 3.65 è ancora vulnerabile, è anche possibile per qualcuno creare un programma di aggiornamento personalizzato per 3.60 che flasha 3.65 HENkaku Ensō allo stesso tempo e usa lo stesso CFW (taiHEN) in 3.65. Questo ti permetterebbe di giocare a nuovi giochi bloccati a 3.60. Tuttavia, per farlo, qualcuno dovrebbe scaricare il bootloader non sicuro di 3.65 per trovare gli offset e ricostruire l’exploit (che è open source). Di nuovo, questo richiede almeno un exploit del kernel su 3,65 (e forse anche un altro exploit perché WebKit in realtà colpisce la memoria in cui risiede NSBL e se si sfrutta il kernel dopo l’esecuzione di WebKit, è troppo tardi per fare il dump di NSBL ma sto facendo una digressione) . Un altro modo, forse pazzo, è cercare di indovinare le compensazioni. Lo scenario migliore è che nessuno degli offset sia cambiato (dal 3.61-3.65 sono tutti aggiornamenti molto minori). È possibile creare hardware personalizzato che provi diversi offset e ripristinare il dispositivo in caso di errore.

Design

Nel creare Ensō, abbiamo avuto un paio di importanti obiettivi di design

  • Consentire il ​​caricamento del codice del driver non firmato il prima possibile. Ciò consentirà di sviluppare una maggiore varietà di hack.
  • Supportare il recovery in caso di errore dell’utente. Non vogliamo un plug-in cattivo per briccare la PSVita.
  • Riutilizzare il più possibile l’infrastruttura attuale. taiHENkaku è testato e funziona e non vogliamo frammentare l’ecosistema homebrew già piccolo. Fortunatamente, taiHEN è stato progettato pensando a questo caso d’uso.

È un po ‘complicato soddisfare tutti questi obiettivi contemporaneamente. Ad esempio, se vogliamo caricare i plug-in prima di SceShell, un plug-in non valido potrebbe garantire che SceShell non si carichi mai e che il ripristino non sia possibile. Se scrivi un menu di ripristino personalizzato, dovremmo anche scrivere codice di inizializzazione della grafica personalizzata (per OLED, LCD e HDMI) e codice per gestire il control pad e USB / DualShock 3 per PS TV. Tutto quel codice personalizzato in un menu di ripristino renderebbe il recupero stesso instabile, il che vanifica lo scopo. D’altra parte, se prendiamo in carico la modalità di ripristino di Sony, che carica molto tardi nel processo di avvio e potrebbe non essere abbastanza buono per il ripristino da plugin del kernel errati. Alla fine, abbiamo deciso di riutilizzare la maggior parte delle funzionalità che già esiste come possibile invece di implementarne di nuove. In questo modo non dobbiamo fare affidamento su estesi test e debug delle “funzionalità CFW” e affidarci al firmware di Sony, insieme a HENkaku, per funzionare già. Il nuovo codice che Ensō aggiunge al sistema è minimo. Meno codice nuovo significa meno possibilità che qualcosa vada storto e meno sforzo richiesto per il test.

Processo di avvio

 

Prima di discutere del design di Ensō, dovrei spiegare come Vita si inserisce nel suo kernel. Una descrizione della catena di avvio sicura e la sequenza di avvio completa sono disponibili nel wiki. Qui, invece, ingrandirò e spiegherò più dettagliatamente l’ultima catena della sequenza di avvio: caricamento del kernel in un mondo non sicuro.

Il bootloader non protetto (d’ora in avanti: NSBL) ha la sua versione integrata dei moduli del kernel di base: SceSysmem, SceKernelThreadmgr, SceModulemgr, ecc. Che utilizza prima che i moduli di base siano caricati. Usando il caricatore interno, NSBL prima istanzia uno stub chiamatoos0:psp2bootconfig.skprx, che ha percorsi codificati ai moduli del kernel di base insieme ai moduli del driver di base (come SceCtrl, SceSdif, SceMsif, ecc.). Seleziona anche il driver di visualizzazione da caricare (SceOled, SceLcd, SceHdmi) e dopo aver caricato il gestore framebuffer (SceDisplay), il logo di avvio viene visualizzato su modelli non PSTV. L’ultimo modulo in questa fase è SceSysstateMgr, che è responsabile della migrazione dello stato NSBL al kernel (così, ad esempio, SceModulemgr può assumere il controllo dei moduli caricati dal loader NSBL incorporato). Quindi crea e passa al processo del kernel (pid 0x10005), ripulisce il processo di pre-avvio, cancella NSBL dalla memoria e carica lo script di configurazione di avvio.

La sintassi dello script di configurazione di avvio è documentata sul wiki . Supporta semplici comandi come load path.skprxcaricare un modulo e un semplice flusso di controllo, in modo if SAFE_MODEda eseguire solo i comandi procedurali se la console si avvia in modalità sicura. Lo script è, ovviamente, firmato e crittografato ed è diverso per PS TV (per caricare i driver per il DualShock 3, ad esempio). Il comando finale nello script è spawnil processo LiveArea (SceShell) o il processo in modalità provvisoria (in modalità provvisoria) o il processo di aggiornamento (in modalità di aggiornamento).

Lo schema sopra riportato è un riepilogo di questo processo. Non menzionato è bootimage.skprx, che è un archivio (crittografato e firmato) di molti dei moduli del kernel caricati dallo script di avvio. Non sono sicuro del motivo per cui alcuni moduli sono in questa immagine di avvio mentre altri sono archiviati come file nella os0partizione, ma non credo ci sia un motivo. La freccia indica la dipendenza dell’ordine di avvio. Le caselle blu, come sotto dettagliate, sono ciò che viene rattoppato da Ensō.

Prendendo il boot

L’exploit ci consente di controllare l’esecuzione del codice nel bootloader non protetto, quindi il nostro compito è mantenere il controllo e consentire al resto del sistema di avviarsi. Se si guarda di nuovo il diagramma, è possibile vedere che ci sono tre fasi di avvio prima che il kernel sia completamente caricato. Il primo stadio è NSBL, che controlliamo dall’exploit. Il secondo stadio sta caricando il kernel di base e i driver usando il caricatore all’interno di NSBL. Un modulo nel kernel di base è authmgr.skprx, che esegue il controllo della decrittografia e della firma per qualsiasi codice caricato dal kernel. La prima patch che facciamo è disabilitare questi controlli per il codice non firmato. Successivamente, vogliamo essere sicuri taihen.skprxhenkaku.skprxvengono caricati all’avvio. Il posto perfetto per questo è nello script di configurazione di avvio. Quindi la prossima patch è dentrosysstatemgr.skprxsupportare il caricamento di uno script personalizzato (non firmato). Infine, aggiungiamo load ur0:tai/taihen.skprxe inseriamo load ur0:tai/henkaku.skprxnello script personalizzato e questo dovrebbe caricare i nostri moduli non firmati all’avvio.

Ci sono un paio di altri dettagli minori però. Vogliamo un logo di avvio personalizzato perché questa è la medicazione che tutti i firmware personalizzati hanno. Per fare questo, semplicemente patch display.skprxquando viene caricato da NSBL. Successivamente, dobbiamo assicurarci che le nostre modifiche all’MBR per attivare l’exploit non interrompano il kernel. Questo ci impone di patchare il driver del dispositivo a blocchi eMMC sdif.skprxdove reindirizziamo le letture del blocco 0 al blocco 1 dove l’installer Ensō ha memorizzato una copia di un MBR valido. Con queste patch in atto, possiamo avviare taiHENkaku all’avvio. Come bonus, dato che possiamo modificare lo script di avvio, possiamo anche abilitare alcune funzionalità come il driver di archiviazione di massa USB sul palmare Vitas.

Recovery

L’Hacking del sistema all’inizio del boot è molto pericoloso perché gli errori possono causare un sistema in brick. Ci sono due potenziali problemi che si presentano. Innanzitutto, poiché carichiamo uno script di avvio senza firma, se lo script è danneggiato dall’errore dell’utente o da altri mezzi, il sistema non si avvierà. Vita ha una “modalità sicura” integrata, ma dipende da uno script di avvio valido. In secondo luogo, se c’è un bug in taihen.skprxhenkaku.skprx, il modulo potrebbe mandare in crash il sistema prima che l’utente abbia la possibilità di aggiornare i file. La soluzione che abbiamo deciso è di disabilitare (quasi) tutte le patch se Vita sta avviando in modalità sicura (tenendo premuto il pulsante R + PS durante l’avvio o rimuovendo la batteria durante l’avvio e ricollegandola). L’unica patch che non possiamo disabilitare è quella insdif.skprx(indicato in ciano nello schema sopra) perché quella patch garantisce che il nostro exploit MBR non rovini il kernel. Come conseguenza della disattivazione delle patch, viene caricato lo script di avvio predefinito (firmato e crittografato) e il menu della modalità provvisoria.

Poiché archiviamo tutti i file di hack in ur0:(la partizione dati utente), se l’utente seleziona l’opzione di ripristino dalla modalità provvisoria, eliminerà lo script di avvio personalizzato (danneggiato) e taiHENkaku. Quindi quando si riavvia in modalità normale, il patch sysstatemgr.skprxvedrà che lo script di avvio personalizzato non viene trovato e ricade nello script di avvio predefinito. L’utente può quindi installare HENkaku dal browser Web e reinstallare uno script di avvio funzionante utilizzando l’installer di Ensō.

Forniamo anche un altro livello di recupero. Se si tenta di reinstallare il firmware 3.60 dalla modalità provvisoria, questo dovrebbe rimuovere anche l’haso Hack. Questo funziona perché l’updater cambierà sempre l’MBR, quindi, poiché il nostro blocco 0 read patch reindirizza il blocco 0 al blocco 1 ma non reindirizza le scritture al blocco 1, l’updater leggerà l’MBR valido e quindi lo aggiornerà e proverà a scriverlo indietro per bloccare 0 dove cancellerà l’MBR compromesso. Ciò garantisce anche che se un utente si aggiorna accidentalmente, per esempio, 3.65, si assicurerà che Ensō venga cancellato altrimenti l’utente avrà un mattone permanente. Ovviamente, la Vita non funzionerà più in homebrew, ma è ancora meglio di un mattone.

Tutto ciò significa che fino a quando l’utente non modifica i settori di hack in eMMC o modifica la os0partizione, sarà in grado di recuperare da qualsiasi errore. La Vita monta os0di sola lettura per impostazione predefinita, quindi non vi è alcuna possibilità di scrittura accidentale lì. Inoltre, con lo script di avvio personalizzato, gli hacker non avranno mai la necessità di modificare os0quando possono invece avviare i moduli da altre partizioni come ur0.

Analisi

L’ultimo e più importante passo in questo viaggio è assicurarsi che il design sia stato testato correttamente. A causa dei meccanismi di ripristino, purché il programma di installazione funzioni esdif.skprxpatch funziona, qualsiasi altro errore può essere recuperato. Per quanto possiamo testare internamente, non abbiamo abbastanza dispositivi e configurazioni per coprire l’ampia varietà di Vitas hackerati là fuori. Questo è il motivo per cui ho chiesto ai membri della comunità degli hacker di sacrificare potenzialmente il loro Vitas nel test dei mesi prima del rilascio. Finché i tester sono disposti a correre il rischio di una Vita in muratura, possono essere “in prima linea” nell’installare e utilizzare l’hack. Se succede qualcosa di sbagliato, loro ci faranno sapere e noi prenderemo il bug prima che si spenga alle masse. Ho creato una registrazione e mi sono assicurato che il rischio di essere il primo a eseguire un tale attacco fosse esplicito. Dopo aver aperto le registrazioni per un giorno, ho ricevuto 160 risposte. Da quelle risposte, ho invitato 10 persone al giorno per 10 giorni a partecipare alla beta.

Guida di prova

Per facilitare il processo di test, ho scritto una guida che i tester possono seguire per installare, disinstallare e recuperare Ensō. Ho chiesto ai tester di registrare l’intero processo nel caso qualcosa dovesse andare storto e di inviarci il video se dovesse andare storto. Poiché il test richiede istruzioni precise, ho voluto escludere candidati che non hanno le competenze linguistiche necessarie per comprendere le istruzioni o sono troppo incuranti per seguirli. In questo modo, posso essere più fiducioso nei dati raccolti e che, ad esempio, nessuno sta semplicemente rispondendo sì a tutto. Inoltre, per il loro bene, non volevo permettere alle persone che hanno appena visto la parola “beta” e ignorare tutti i miei avvertimenti per eseguire le build beta. Volevo essere sicuro che il partecipante comprendesse appieno il rischio che stavano assumendo e acconsentisse. Per fare questo,

 

e alla fine della pagina

Beta Guide 2

Non sorprende che un buon numero di persone non abbia superato il test di lettura al primo tentativo. Dopo averlo superato, la guida ha attraversato 7 scenari tra cui installazione, fallback quando HENkaku non è installato, fallback quando non è stato trovato lo script di avvio personalizzato, disinstallazione, modalità sicura e ripristino da script di avvio errati.

Risultati

Su circa 100 tester invitati, 67 hanno completato la guida del test (compreso il test di lettura che ha filtrato molte persone). I tester sono stati suddivisi in 10 gruppi assegnati ogni giorno per garantire che ogni nuova build sia stata testata.

 

Dei 67 tester, abbiamo avuto una buona distribuzione di dispositivi testati

 

C’erano solo due brick permanenti. Erano i primi due tester nella primissima build. Abbiamo rapidamente identificato il problema e risolto il problema e non c’erano più brick per il resto del test. C’erano anche due tester che hanno subito guasti di installazione non fatali.

 

Tutto sommato, la maggior parte dei tester non ha segnalato problemi con nessuno degli scenari di test. Tuttavia, ci sono stati alcuni ostacoli comuni che abbiamo affrontato grazie al feedback.

  • Quando si avvia in SceShell con lo spoofing della versione, Vita scrive la versione del firmware “corrente” nella scheda di memoria id.dat. Questa “funzione” serve a impedire agli utenti di prendere una scheda di memoria da una PSVita che esegue il firmware più recente e la trasferisce su una Vita con un firmware precedente. Tuttavia, una volta disinstallato Ensō, questa “funzione” viene attivata causando il rifiuto di Vita della scheda di memoria a meno che non sia stata formattata. Per risolvere questo problema, HENkaku R9 disabilita la scrittura dell’ id.dat.
  • Se l’utente cambia la sua scheda di memoria e la scheda di memoria ha una versione precedente di HENkaku installata, potrebbe causare l’arresto anomalo di SceShell e l’unico modo per utilizzare la scheda di memoria è formattarlo per eliminare i vecchi file HENkaku. Per risolvere questo problema, HENkaku R10 installa tutto ciò che è integrato nella memoria di sistema ur0.

Grazie

Grazie a tutti i nostri tester per correre il rischio e aiutarci a migliorare il processo di installazione e correggere molti bug. Grazie a motoharu per i suoi contributi wiki che hanno velocizzato lo sviluppo della patch di reindirizzamento dei blocchi eMMC. Grande, grande grazie a @ NickLS1 per averci dimostrato con Vitas con modulazione dura per testare e sviluppare. Grazie a tutti i nostri amici che conoscevano l’exploit e lo hanno tenuto nascosto su mia richiesta perché sapevamo che Sony non l’aveva ancora aggiornato in quel momento.

Se vuoi dare un’occhiata alla fonte, è su Github . Per favore, non provare a costruire e installare la tua build, a meno che tu non sia assolutamente sicuro di quello che stai facendo. Ogni piccolo errore si tradurrà in un brick irrecuperabile.

Fonte

Yifan Lu

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