Home Homebrew Rilasciato PlayStation 5 Remote JAR Loader v3.0.0

[Scena PS5] Rilasciato PlayStation 5 Remote JAR Loader v3.0.0

124
0

Il developer hammer-83 ha rilasciato una nuova versione di PlayStation 5 Remote JAR Loader ispirata alle modifiche implementate da daddy-bitcoin, introducendo alcune ottimizzazioni per le chiamate native, tratte dalle idee di Andy Nguyen.

La nuova versione include due immagini ISO: una completa, che integra tutti i payload aggiornati e un menu per caricarli direttamente dal disco, e una versione base con il solo remote JAR loader.

Entrambe le versioni permettono il caricamento remoto dei payload, ma la versione completa offre anche un menu per gestire i payload già masterizzati sul disco, grazie al contributo di iakdev.

Le ottimizzazioni recenti per le chiamate native hanno migliorato notevolmente la velocità di convergenza del payload UMTX, sebbene UMTX2 sia stato deprecato a causa della sua maggiore vulnerabilità ai deadlock e dei costi di mantenimento di due implementazioni separate.

La rimozione di UMTX2 è prevista per le versioni future. Sono stati risolti anche numerosi problemi nell’SDK, ma i payload compilati con la versione precedente dell’SDK potrebbero non essere compatibili con questo loader.

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

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

  1. Assicurarsi che la variabile d’ambiente JAVA_HOME punti alla radice del JDK 11. Aggiungere la directory ${JAVA_HOME}/bin a ${PATH}.
  2. Assicurarsi anche che MAVEN_HOME punti alla radice dell’installazione di Apache Maven. Aggiungere la directory ${MAVEN_HOME}/bin a ${PATH}.
  3. 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.
  4. 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.
  5. 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.
  6. Inserire il disco nella PS5 e avviare “PS5 JAR Loader” dalla sezione Media / Disc Player.
  7. Un messaggio sullo schermo dovrebbe informare che il loader è in attesa del JAR.
  8. Inviare il JAR utilizzando il comando: java -jar xploit/target/xploit-[version].jar <indirizzo IP della PS5>.
  9. La PS5 dovrebbe informare sullo schermo riguardo allo stato del caricamento e dell’esecuzione.
  10. 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

  1. 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.
  2. Se uno dei POM viene modificato, è necessario eseguire Maven -> Reload Project in IntelliJ per sincronizzare i file del progetto.
  3. 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.
  4. 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.
  5. 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.
  6. 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

  • Due versioni dell’immagine ISO: una con tutti i payload (aggiornati al momento della pubblicazione) e il menu che consente di caricarli direttamente dal disco; un’altra, come prima, con solo il remote JAR loader. Entrambe le versioni permettono di caricare remotamente i payload più recenti allegati a questa release, ma l’immagine ISO completa include anche il menu che carica i payload masterizzati sul disco. Grazie a iakdev.
  • Incorporate le recenti ottimizzazioni per le chiamate native da Andy Nguyen nell’SDK. Il payload UMTX ora converge molto più velocemente.
  • UMTX2 è deprecato con questa release. È più soggetto a deadlock e mantenere due implementazioni aggiunge un overhead inutile. Probabilmente verrà rimosso nelle versioni future.
  • Varie correzioni nell’SDK.
  • I payload compilati con la versione precedente dell’SDK probabilmente non funzioneranno con questo loader e viceversa (il loader precedente probabilmente non caricherà correttamente i JAR compilati con questa versione dell’SDK).

Nota: Su firmware 6.00+, tentare di scrivere sui dati del kernel causa un panic. Il testo del kernel può essere letto/scritto solo su firmware inferiori alla versione 3.00.

Passaggi:

  • Compilare il progetto e masterizzare il contenuto della cartella assembly/target/assembly-3.0.0 su di un disco BD-RE. È anche fornita una ISO precompilata. Facoltativamente, compilare con l’opzione -Dloader.logger.host=[IP del server di logging] per visualizzare l’output su uno schermo remoto.
  • Inserire il disco nella PS5 e avviare il JAR Loader.
  • Inviare un payload: java -jar <payload.jar> <IP PS5>

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.

Download: PlayStation 5 Remote JAR Loader v3.0.0

Download: Source code PlayStation 5 Remote JAR Loader v3.0.0

Fonte: x.com

LASCIA UN COMMENTO

Per favore inserisci il tuo commento!
Per favore inserisci il tuo nome qui

Questo sito utilizza Akismet per ridurre lo spam. Scopri come vengono elaborati i dati derivati dai commenti.