Pubblicato per intero il codice sorgente di Henkaku Ensō insieme ad una vasta documentazione redatta da Yifan Lu

Il developer Yifan Lu ha pubblicato un interessante articolo sul suo blog, riguardante una certa vulnerabilità nel bootloader che ha portato alla nascita di Henkaku Ensō.

Insieme all’articolo, il team Molecule ha voluto pubblicare all’interno della propria repository l’intero codice sorgente di Henkaku Ensō, basta scovare un nuovo kernel exploit per poterlo sfruttare anche sul firmware 3.65.

HENkaku Ensō bootloader hack per Vita

Quando noi (team Molecule) abbiamo decodificato il firmware della PlayStation Vita anni fa, una delle prime vulnerabilità che abbiamo trovato era quella presente nel bootloader.

Nota: Il bootloader è un programma che viene eseguito automaticamente all’accensione della console andando ad eseguire tutta una serie di routine per avviare il sistema operativo. 

Questa era una vulnerabilità particolarmente interessante perché in fase di avvio (prima che ASLR e alcune altre funzionalità di sicurezza venissero correttamente inizializzate) e perché consentiva di applicare 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 avremmo dovuto sfruttare il kernel (e HENkaku) per installare l’exploit.

Prima di chiedere, no, non è possibile installare questo con una modifica hardware perché ogni console esegue una crittografia diversa sulla sua memoria NAND con una chiave univoca.

Inoltre, non ci sono testpoint per la NAND, quindi flashare la memoria risulta particolarmente difficile… non così semplice come su console portatile 3DS.

Vulnerabilità

La vulnerabilità è un buffer overflow dovuto al bootloader che assegna staticamente un buffer nella 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) nell’intestazione della partizione FAT.

Nota: Il buffer overflow è una condizione di errore che si verifica a runtime quando in un buffer di una data dimensione vengono scritti dati di dimensioni maggiori. Quando questo accade viene sovrascritta parte della zona di memoria immediatamente adiacente al buffer in questione. 

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).

Lo sviluppatore 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, i firmware 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).

Al momento nessuno del team Molecule è interessato ad hackerare qualcosa oltre il firmware 3.60, questo perché Sony non ha rilasciato nuovi modelli, e quasi tutte le console PlayStation Vita e PlayStation TV montano firmware addirittura inferiori.

Chiunque desideri eseguire homebrew può scegliere di non aggiornare la console. 

Se si monta il firmware 3.65 e si desidera eseguire nuovamente homebrew nativi su console PlayStation Vita e PlayStation TV, non aggiornare, probabilmente qualche hacker di talento potrebbe rilasciare un nuovo kernel exploit e permettere di eseguire l’installazione di Henkaku Ensō.

Ora chiunque potrà scegliere di scaricare e invertire il codice del kernel con HENkaku, quindi forse ci sarà una motivazione in più per gli estranei di trovare un nuovo hack ora.

Poiché il firmware 3.65 è ancora vulnerabile, è anche possibile per qualcuno creare un programma di aggiornamento personalizzato per 3.60 che andrà a flashare il firmware 3.65 con HENkaku Ensō allo stesso tempo e utilizzando lo stesso CFW (taiHEN) in 3.65.

Questo ci permetterebbe di eseguire anche i giochi ancora bloccati su firmware 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).

Questo richiede sempre un exploit kernel nel firmware 3.65 (e forse anche un altro exploit perché il 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. Questo ci ha permesso di sviluppare una maggiore varietà di hack.
  • Supportare il recupero in caso di errori da parte dell’utente. Non vogliamo che l’installazione di un cattivo plug-in possa danneggiare irrimediabilmente la console.
  • Riutilizzare il più possibile l’infrastruttura attuale. taiHENkaku è stato testato più volte e funziona e non vogliamo frammentare l’ecosistema homebrew già di per sé molto 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 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 boot

Prima di discutere del design di Ensō, dovrei spiegare come la PlayStation 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ù nel dettaglio l’ultima catena della sequenza di avvio: Il 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 viene utilizzato prima che i moduli di base vengano caricati.

Utilizzando il caricatore interno, NSBL prima istanzia un caricatore di stub denominato os0:psp2bootconfig.skprx, che ha percorsi hard codificati per i 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.skprx per caricare un modulo e un semplice flusso di controllo come se SAFE_MODE eseguisse 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 è generare il 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 partizione os0 ma non penso 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ō.

Taking Over Boot

L’exploit ci permette 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 i controlli di decrittografia e firma per qualsiasi codice caricato dal kernel.

La prima patch che facciamo è disabilitare questi controlli per il codice non firmato. Successivamente, vogliamo assicurarci che taihen.skprx e henkaku.skprx siano caricati all’avvio.

Il posto perfetto per questo è nello script di configurazione di avvio. Quindi la prossima patch è in sysstatemgr.skprx per supportare il caricamento di uno script personalizzato (non firmato).

Infine, aggiungiamo load ur0:tai/taihen.skprx e carichiamo ur0:tai/henkaku.skprx nello 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, dobbiamo semplicemente patchare il file display.skprx quando 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 su sdif.skprx dove 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 Vita.

Recovery

Hackerare il sistema all’inizio del boot potrebbe risultare molto pericoloso, questo perché il sistema potrebbe entrare 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 verrà avviato.

PlayStation Vita ha una “modalità sicura” integrata, ma dipende da uno script di avvio valido. Secondo, se c’è un bug in taihen.skprx o henkaku.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 la PlayStation Vita si sta avviando in modalità sicura (tenendo premuto il pulsante + durante l’avvio o rimuovendo la batteria durante l’avvio e ricollegandola).

L’unica patch che non possiamo disabilitare è quella in sdif.skprx (indicata in ciano nel diagramma poco sopra) perché quella patch garantisce che il nostro MBR di exploit 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, elimina lo script di avvio personalizzato (danneggiato) e taiHENkaku.

Quindi, quando si riavvia in modalità normale, il file sysstatemgr.skprx con patch vedrà 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 modificherà sempre l’MBR, quindi, poiché la nostra patch del blocco 0 legge 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 prova a scriverlo indietro per bloccare 0 dove cancellerà l’MBR compromesso.

Ciò garantisce anche che se un utente si aggiorna accidentalmente, per esempio, su firmware 3.65, si assicurerà che Ensō venga cancellato altrimenti l’utente avrà un mattone permanente. Ovviamente, la PlayStation Vita non potrà più eseguire gli 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 partizione os0, sarà in grado di recuperare la console da qualsiasi errore.

La PlayStation Vita monta os0 in sola lettura per impostazione predefinita, quindi non c’è possibilità di scrivere accidentalmente lì. Inoltre, con lo script di avvio personalizzato, gli hacker non avranno mai bisogno di modificare os0 quando possono invece avviare i moduli da altre partizioni come ur0.

Testing

L’ultimo e più importante passo in questo viaggio è assicurarsi che il design sia stato testato correttamente. A causa dei meccanismi di ripristino, fino a quando il programma di installazione funziona e la patch sdif.skprx funziona, qualsiasi altro errore può essere ripristinato.

Per quanto possiamo testare internamente, non abbiamo abbastanza dispositivi e configurazioni per coprire l’ampia varietà di unità Vita hackerate là fuori.

Questo è il motivo per cui ho chiesto ai membri della comunità degli hacker di sacrificare potenzialmente i loro modelli di console nel test nei primi mesi ancor prima del rilascio.

Finché i tester sono disposti a correre il rischio di brikkare una console PlayStation Vita, 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.

Test guide

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.

Poiché il test richiede istruzioni precise, ho voluto escludere candidati che non avevano le competenze linguistiche necessarie per comprendere le istruzioni o erano 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”, ignorare tutti i miei avvertimenti per eseguire le build beta.

Volevo essere sicuro che il partecipante comprendesse pienamente il rischio che stava assumendo e acconsentisse. Per fare ciò, ho aggiunto un semplice test di lettura all’inizio della guida.

e alla fine della pagina

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 filtrate da 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 con:

C’erano solo due mattoni permanenti. Erano i primi due tester nella primissima build. Abbiamo rapidamente identificato e risolto il problema e non c’erano più stati brick durante tutto 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 durante i test. Tuttavia, ci sono stati alcuni ostacoli comuni che abbiamo affrontato grazie al feedback.

  • Quando si avvia in SceShell con lo spoof della versione, la PlayStation Vita scrive la versione del firmware “corrente” in id.dat sulla scheda di memoria. Questa “funzione” serve a impedire agli utenti di prendere una scheda di memoria da una PlayStation Vita che esegue il firmware più recente e la trasferisce su una console con un firmware precedente. Tuttavia, una volta disinstallato Ensō, questa “funzione” viene attivata causando il rifiuto della PlayStation Vita della scheda di memoria a meno che non sia stata formattata. Per risolvere questo problema, HENkaku R9 disabilita la scrittura di id.dat.
  • Se l’utente cambia la sua scheda di memoria con una scheda di memoria che monta 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 in ur0, che è la memoria di sistema integrata.

Ringraziamenti

Grazie a tutti i nostri tester per aver corso il rischio e averci aiutato a migliorare il processo di installazione e correzione di molti bug. Grazie a motoharu per i suoi contributi nel wiki che hanno velocizzato lo sviluppo della patch di reindirizzamento dei blocchi eMMC.

Un grandissimo ringraziamento a @NickLS1 per averci dimostrato come sarebbe possibile eseguire una modifica hardware nella modulazione per effettuare test 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 al codice sorgente, questo è presente sul 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 mattone irrecuperabile.



Source : yifan.lu

(Visited 1 times, 1 visits today)

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *