Home Homebrew Rilasciato PS5 JAR Loader v4.0.1

[Scena PS5] Rilasciato PS5 JAR Loader v4.0.1

10 Febbraio 2025 Data modificata: 10 Febbraio 2025

478

Il developer hammer-83 ha rilasciato una versione correttiva di PS5 JAR Loader, il progetto sfrutta le vulnerabilità scoperte nel livello BD-J del firmware PS5 fino alla versione 7.61 per eseguire codice sperimentale

Il loader consente di ascoltare ed eseguire file JAR, permettendo di masterizzare il BD-R con il loader una sola volta e poi caricare nuove versioni del codice senza bisogno di ulteriori scritture su disco.

⭐️PS5 JAR Loader 4.0.1 released by hammer-83

🔹Implemented AGC-based kernel read/write primitives to allow write access to kernel data on firmware 6.00+
🔹Various improvements.

Release v4.0.0 was yanked as it contained a critical bug on firmware 7.00+

📥https://t.co/GNE0N24ohS pic.twitter.com/5yYlV9CYgZ

— aldostools🔸ᐱᒪᑐ〇 VᐱᒋᏀᐱS (@aldostools) February 10, 2025

L’aggiornamento è stato rilasciato per correggere un bug critico riscontrato nei firmware 7.00 e superiori, che aveva compromesso la stabilità dell’exploit. A causa di questo problema, la precedente versione 4.0.0 è stata cancellata e sostituita da questa build corretta.

Avvio rapido

Scaricare l’immagine ISO del JAR Loader.
Masterizzare l’immagine su di un disco BD-R(E) e avviarlo dalla scheda “Media” della PS5.
Scaricare uno dei file JAR pre-compilati o compilarlo seguendo i passaggi riportati di seguito.
Inviare il file JAR al JAR Loader utilizzando NetCat o direttamente con il file JAR, se la macchina ha Java installato: java -jar [jarfile].jar [ip] [host].

Prerequisiti

JDK 11 (la console PS5 utilizza il runtime Java 11).
Apache Maven.
IntelliJ IDEA Community Edition (facoltativo, ma consigliato).

Alcuni dei payload inclusi

Server FTP (sandboxed).
Gioco di mini tennis di esempio.
Stampa le proprietà di sistema.
Dump del classpath corrente della JVM, incluso il modulo java.base (potrebbe non funzionare su tutti i firmware).
Implementazioni di bug UMTX da flat_z, Cryptogenic e cheburek3000 adattate a questo SDK. Ognuna di esse può essere utilizzata per ottenere la lettura/scrittura del kernel. Nota: UMTX1 è il payload raccomandato. Con il miglioramento della stabilità, le altre implementazioni saranno deprecate e infine rimosse.
Implementazione Byepervisor da Cryptogenic.
Kernel dumper. Una volta ottenuta la lettura/scrittura del kernel, inviare questo payload per eseguire il dump del kernel. Se è stato eseguito prima Byepervisor, verranno dumpati testo e dati. Altrimenti, verranno inviati solo i dati. Utilizzare netcat su un computer per ricevere il binario del kernel collegandosi alla PS5 sulla porta 5656.

Struttura

Il progetto comprende le seguenti componenti:

pom.xml nella directory principale definisce le proprietà comuni e la configurazione del plugin Maven per tutti i progetti.
Il sottoprogetto assembly crea la directory da masterizzare su un disco BD-R. Si consiglia di utilizzare il software ImgBurn per questo. Assicuratevi di utilizzare il file system UDF 2.50, quindi trascina semplicemente il contenuto della directory assembly/target/assembly-[version] nell’editor del layout del disco.
Il sottoprogetto bdj-tools non necessita di modifiche. Sono le utility tratte dall’HD Cookbook, adattate per funzionare su JDK 11 e integrate nel processo di build del file system del disco BD-R.
Il sottoprogetto stubs contiene lo script di build per scaricare i file di classe BD-J da HD Cookbook e organizzarli per l’uso con il JDK 11 locale. È anche il luogo dove dichiarare i file stub specifici per PS5 in modo che possano essere utilizzati nell’Xlet e nel JAR remoto.
Il sottoprogetto sdk contiene classi helper che semplificano l’invocazione nativa nel codice eseguito. Le classi in questo modulo sono incorporate nel JAR finale che verrà inviato alla PS5 per l’esecuzione.
Il sottoprogetto xlet contiene il codice dell’Xlet che si avvia quando il disco BD-R viene lanciato su PS5. Avvia semplicemente il JAR loader (di default sulla porta 9025).
Il sottoprogetto xploit contiene il codice da inviare per l’esecuzione sulla PS5. Il codice può fare riferimento a classi di xlet, come la classe Status per l’output a schermo. Il progetto produce un JAR in grado di inviare se stesso per l’esecuzione.

Configurazione

Le seguenti proprietà in pom.xml possono essere regolate prima di masterizzare il JAR Loader su disco:

loader.port – Porta su cui il caricatore JAR ascolterà i dati.
loader.resolution.width, loader.resolution.height – Risoluzione dello schermo da impostare in vari file. Non sono sicuro di come questo influisca su qualcosa, non l’ho sperimentato abbastanza.
remote.logger.host – Indirizzo IP dove far risuonare i messaggi mostrati sullo schermo. Se vuoto, la registrazione remota non verrà utilizzata. Questo host può anche ricevere dati binari, vedere RemoteLogger#sendBytes.
remote.logger.port – Porta su cui il logger remoto invierà i messaggi di stato.
remote.logger.timeout – Numero di millisecondi da attendere prima di abbandonare i tentativi di connessione all’host di registrazione remoto. Se l’host è inattivo dopo questo timeout al primo tentativo di invio, non verranno eseguiti ulteriori tentativi di registrazione remota.

Modificare direttamente il POM o passare i nuovi valori dalla riga di comando, ad esempio: mvn clean package -Dloader.port=9025 -Dremote.logger.host=192.168.1.100.

Per ascoltare i messaggi sulla macchina remota quando il logger remoto è attivato, si può utilizzare socat udp-recv:[remote.logger.port] stdout.

Anche se il logger remoto non è attivo di default nell’Xlet masterizzato su disco, è possibile modificare programmaticamente il server di logging remoto direttamente dal payload nel file JAR chiamando Status#resetLogger.

Utilizzo

Assicurarsi che la variabile d’ambiente JAVA_HOME punti alla radice del JDK 11. Aggiungere la directory ${JAVA_HOME}/bin a ${PATH}.
Assicurarsi anche che MAVEN_HOME punti alla radice dell’installazione di Apache Maven. Aggiungere la directory ${MAVEN_HOME}/bin a ${PATH}.
Creare un payload da eseguire sulla PS5 aggiungendo l’implementazione al sott modulo xploit. Non è necessario modificare file esistenti (anche se è possibile farlo se lo si desidera). Basta aggiungere la propria classe di payload nel pacchetto org.ps5jb.client.payloads e specificarne il nome come parametro durante la compilazione del progetto (vedere il passo successivo). Sono già forniti alcuni payload di esempio in questo pacchetto.
Eseguire mvn clean package -Dxploit.payload=[payload classname] dalla radice del progetto. Questo dovrebbe produrre i seguenti artefatti: a. La directory assembly/target/assembly-[version] contiene tutti i file che devono essere masterizzati su un disco BD-R. b. Il file xploit/target/xploit-[version].jar contiene il codice che può essere inviato ripetutamente alla PS5 una volta che il loader è stato distribuito. Per evitare di dover specificare il payload ogni volta con un switch -D (anche nel passo 9), è possibile modificare anche la proprietà xploit.payload nel pom.xml del progetto xploit.
Masterizzare il BD-R (meglio ancora il BD-RE) con il contenuto della directory menzionata nel passo 4a. Si noti che la ri-masterizzazione del disco del JAR loader è necessaria solo quando la sorgente di xlet o dei moduli assembly viene modificata.
Inserire il disco nella PS5 e avviare “PS5 JAR Loader” dalla sezione Media / Disc Player.
Un messaggio sullo schermo dovrebbe informare che il loader è in attesa del JAR.
Inviare il JAR utilizzando il comando: java -jar xploit/target/xploit-[version].jar <indirizzo IP della PS5>.
La PS5 dovrebbe informare sullo schermo riguardo allo stato del caricamento e dell’esecuzione.
Una volta completata l’esecuzione, il loader attenderà un nuovo JAR. Effettuare le modifiche necessarie nel progetto xploit, ricompilare utilizzando mvn package e rieseguire il passo 8 per ripetere il processo quante volte necessario.

Note

Per utilizzare IntelliJ, puntare il dialogo File -> Open sulla radice del progetto. Verrà eseguita l’importazione di Maven. Successivamente, seguire i passaggi manuali nella Struttura del Progetto di IntelliJ per regolare le dipendenze in modo che IntelliJ veda le classi BD-J prima delle classi JDK.
Se uno dei POM viene modificato, è necessario eseguire Maven -> Reload Project in IntelliJ per sincronizzare i file del progetto.
Per generare i Javadocs, utilizzare mvn verify anziché mvn package. I Javadocs sono abilitati per i moduli sdk, xlet e xploit e vengono generati nella directory target/site/apidocs di ciascun modulo.
Il JAR nel modulo xploit accede ad alcune classi interne del JDK tramite riflessione. Questo comporterà avvisi che possono essere ignorati in sicurezza. Per silenziare gli avvisi, aggiungere il seguente switch dopo l’eseguibile di Java quando si invia il file JAR: --add-opens java.base/jdk.internal.loader=ALL-UNNAMED.
Se il file JAR xploit non ha dipendenze specifiche per PS5, può essere testato localmente. La parte importante è avere i JAR di xlet, stubs e xploit tutti nella stessa cartella. Se il payload fa riferimento a GEM, BD-J o Java TV API, i corrispondenti file JAR generati nella directory lib dovrebbero essere presenti nella stessa cartella. La build di Maven crea automaticamente questa disposizione nella directory xploit/target, quindi il comando per eseguire il payload sulla macchina di sviluppo è molto simile a quello che invia il JAR alla PS5: java -jar xploit/target/xploit-[version].jar. Quando viene eseguita localmente, la classe Status stampa su standard output/error, anziché su schermo.
Attualmente il progetto utilizza due numeri di versione distinti:
- La versione xlet è indipendente e viene incrementata solo quando è necessario masterizzare un nuovo disco con le classi JAR aggiornate del caricatore. Se la PS5 mostra una versione diversa da quella prodotta dal codice di questo repo, non è garantita la compatibilità dei payload, quindi è meglio masterizzare un nuovo disco loader. Non si prevede che questa versione venga incrementata spesso, poiché il caricatore è piuttosto stabile. Per incrementare questa versione, modificare il valore della proprietà xlet.version in pom.xml.
- Il resto dei moduli utilizza la versione del POM padre. Questa versione verrà incrementata con la nuova release e riflette che l’SDK o i payload sono cambiati. Se la versione del caricatore è rimasta invariata, queste nuove versioni dei payload possono essere inviate al caricatore JAR senza dover masterizzare nuovamente il disco. Questa versione può essere incrementata eseguendo mvn versions:set -DnewVersion=[versione], quindi aggiornando il progetto IntelliJ Maven come descritto al punto 2.

Struttura del Progetto IntelliJ

I file del progetto Maven di IntelliJ si trovano in una cartella locale privata di IntelliJ. L’apertura iniziale e i successivi ricaricamenti del progetto Maven importano erroneamente alcune impostazioni.

In particolare, i JAR dello stack BD-J vengono completamente ignorati o importati con uno scope errato. Sfortunatamente, a causa di questo fatto, i seguenti passaggi devono essere eseguiti ogni volta che si verifica un ricaricamento del progetto Maven:

Sincronizzare il progetto Maven modificando il file .idea/compiler.xml per contenere percorsi di sistema assoluti. Sostituire semplicemente questi con la macro $PROJECT_DIR$ .
Accedere alla finestra Project Structure e passare alla scheda Modules. Verificare ogni modulo e assicurarsi che i moduli bdj-api, javatv-api e gem-api abbiano uno scope “Provided”.
Inoltre, per tutti i moduli che hanno le dipendenze sopra menzionate, cliccare sul pulsante + (Add) -> Library e aggiungere la dipendenza della libreria bdjstack. Assicurarsi che venga spostata nella posizione superiore sopra l’entrata SDK 11. Questa impostazione era precedentemente registrata nel controllo di versione e poteva essere semplicemente ripristinata, ma negli aggiornamenti recenti deve essere eseguita ogni volta.

Changelog

Novità

Implementate primitive AGC-based per la lettura e scrittura del kernel, consentendo l’accesso in scrittura ai dati del kernel sui firmware 6.00+. Un ringraziamento a flat_z.
Aggiunto il payload per attivare il menu Debug Settings, con crediti a CryoNumb.
Vari miglioramenti e refactoring dell’SDK.
Aggiunta la visualizzazione dei numeri di versione per JAR Loader e i payload (basata sulla versione del progetto Maven).

Note

La versione v4.0.0 è stata rimossa poiché conteneva un bug critico sui firmware 7.00+.
I nuovi payload non sono compatibili con le versioni precedenti di JAR Loader, e viceversa.
La ISO completa include un menu e tutti i JAR disponibili in questa release. La ISO ridotta contiene solo il loader remoto dei JAR, quindi i payload devono essere inviati tramite rete.
La ISO completa non include i JAR per il jailbreak e il klogserver, poiché il jailbreak non funziona correttamente con il menu del loader.
Alcune directory non sono accessibili in BD-J, anche con il jailbreak attivo. Questo è un problema noto e non è ancora stata trovata una soluzione per aggirare questa restrizione.

Payload

Implementazioni del bug UMTX di flat_z, Cryptogenic e cheburek3000 adattate per questo SDK. Ognuna di esse può essere utilizzata per ottenere l’accesso in lettura e scrittura al kernel. Nota: UMTX1 è il payload raccomandato. Con il miglioramento della stabilità, le altre implementazioni verranno deprecate e infine rimosse.
Implementazione di Byepervisor realizzata da Cryptogenic.
Dumper del kernel. Una volta ottenuto l’accesso in lettura e scrittura al kernel, è possibile inviare questo payload per eseguire il dump del kernel. Se Byepervisor è stato eseguito prima, verranno scaricati testo e dati; altrimenti, verranno inviati solo i dati. Utilizzare netcat su un computer per ricevere il file binario del kernel collegandosi alla PS5 sulla porta 5656.
Implementazione del jailbreak, che consente al processo BD-J di ottenere privilegi di superutente ed evadere dalla sandbox /app0.
Server FTP (con accesso root dopo il jailbreak).
FTP server (with root access after jailbreak).
Server Klog, che però non è molto stabile quando un client vi si collega.
Debug Settings: Attiva/disattiva le impostazioni di debug (la disattivazione funziona solo all’interno del processo BD-J iniziale).
Samples:
- Mini gioco del tennis.
- Stampa le proprietà di sistema.
- Dump del classpath corrente della JVM, incluso il modulo java.base (potrebbe non funzionare su tutti i firmware).
- Elenco di tutte le directory del filesystem utilizzando chiamate native.