Disponibile un aggiornamento per JTegraNX, il programma sviluppato in Java e C++ simile a TegraRcmGUI, ci permette di iniettare payload RCM all’interno delle console Switch.
Questo utilissimo strumento purtroppo non funziona su Java 11 o versioni successive, questo perché JavaFX non è incluso (se avete comunque intenzione di provarlo su Java 11 o versioni successive, dovrete compilarlo dal codice sorgente).
Caratteristiche
- Iniezione del payload RCM.
- Iniezione automatica.
- Indicatore di stato RCM con immagini trasparenti.
- Sistema di configurazione (simile ai preferiti in TegraRcmGUI).
- Payload in bundle.
- Supporto Tray Icon con funzionalità.
- Preparazione della scheda SD.
- Rilevamento/installazione del driver APX.
- Modalità portatile.
Guida
- Cliccare su Browse for payload o su config.
- Cliccare su Inject payload.
Supporto Linux
Il supporto per Linux è stato aggiunto solo nella versione 1.6.6, per utilizzare JTegraNX su Linux potrebbe essere necessaria una certa preparazione.
- JTegraNX su Linux deve essere eseguito come root o con le regole udev configurate. Per configurare le tue regole udev, seguire questa guida.
- L’iniezione di payload su Linux richiede che il dispositivo RCM si connetta a una porta gestita da xhci_hcd o ad una porta con un driver EHCI con patch.
- Il mio modo per superare questo problema è stato creare una macchina virtuale Ubuntu 21.04 in VMware con USB 3.1 abilitato.
Utilizzo delle configurazioni
Il sistema di configurazione permette di salvare quanto inserito nel campo “Payload Path” e caricarlo nuovamente in un’altra sessione.
Caricamento di una configurazione salvata
Basta fare clic su “Load Config” per visualizzare l’elenco delle configurazioni, quindi selezionare la configurazione che si desidera utilizzare.
Salvataggio di una configurazione
Fare clic su “Save Config”, inserire un nome per la configurazione e premere invio.
Impostazioni personalizzate
Ora puoi personalizzare le impostazioni di JTegraNX a tuo piacimento.
- Ora puoi attivare il controllo automatico per gli aggiornamenti di JTegraNX.
- Ora puoi attivare il controllo automatico per gli aggiornamenti del payload.
- Ora puoi scegliere quali payload vuoi includere con JTegraNX.
- Ora puoi attivare o disattivare l’icona nella barra delle applicazioni.
Preparazione della scheda SD
Questa nuova funzionalità con JTegraNX scaricherà tutti i requisiti di base per preparare la console Switch per CFW e li copierà nel percorso di output specificato.
Rilevamento/installazione del driver APX
JTegraNX è in grado di rilevare se il driver APX è mancante o errato e, in tal caso, è possibile installarlo da lì.
Modalità portatile
Il vecchio comportamento di JTegraNX per la gestione dei file di dati è stato re-implementato come opzione secondaria. La modalità portatile arriva al punto in cui vengono creati la directory “Payloads” e il file di configurazione principale nella directory di lavoro in cui viene eseguito il JAR. Puoi passare dalla modalità standard a quella portatile utilizzando il menu Settings.
Payload in bundle
Per tutti i payload in bundle, JTegraNX li scaricherà automaticamente, li inserirà nella directory “Payload” e, facoltativamente, controllerà gli aggiornamenti su di essi ogni volta che viene avviato il programma. Se gli aggiornamenti sono abilitati e viene trovato un aggiornamento per un payload, questo verrà risolto.
Payload attualmente in bundle
Changelog v1.6.7
- Arrivato il supporto per Mac OS X (più o meno, potrebbero esserci ancora dei problemi).
- Aggiunta la modalità riga di comando per coloro che preferiscono la riga di comando su una GUI.
- Rielaborato il programma di installazione del driver APX per Windows per correggere un bug che non poteva essere corretto con il vecchio programma di installazione.
- Rimosso Incognito_RCM a causa dei rischi che fornisce.
- Miglioramenti generali della stabilità del sistema per migliorare l’esperienza dell’utente.
Changelog v1.6.6
[stextbox id=’info’]Nota: Questa versione DEVE essere scaricata direttamente da questa repository, NON tentare di aggiornare a questa versione utilizzando l’auto-aggiornamento di JTegraNX, fallirà a causa della nuova strategia di distribuzione.[/stextbox]
- Il supporto per Linux è arrivato ed è pronto per l’uso.
- Aggiunto il programma di installazione libusbK per coloro che non possono avviare JTegraNX su Windows.
- Corretto un bug con il listener di modifica del testo del campo del percorso del payload.
- Miglioramenti generali della stabilità del sistema per migliorare l’esperienza dell’utente.
Changelog v1.6.5
- Aggiunto Incognito_RCM alla Tray perché ho dimenticato di farlo prima.
- Corretto un bug con il pulsante includi Incognito_RCM.
- Il campo del percorso del payload ora controlla se il payload specificato esiste e abilita/disabilita il pulsante Inject di conseguenza.
- La disabilitazione di un payload in bundle ora cancella il campo del percorso del payload se contiene il percorso per esso.
- Miglioramenti generali della stabilità del sistema per migliorare l’esperienza dell’utente.
Changelog v1.6.4
- Ridisegnata l’interfaccia utente per essere più user-friendly.
- Sostituito lo sfondo blu predefinito con un tema scuro.
- Aggiunto Incognito_RCM ai payload in bundle.
- Corretto il problema con il sistema di payload in bundle che a volte non si aggiornava.
- Miglioramenti generali della stabilità del sistema per migliorare l’esperienza dell’utente.
Changelog v1.6.3
- Imposta il programma di aggiornamento per utilizzare l’architettura JRE per ogni evenienza.
- Corretto il riavvio dopo la funzione di aggiornamento.
- Sono state apportate alcune modifiche minori all’interfaccia utente.
- Aggiunta una finestra di dialogo sulle informazioni.
- Miglioramenti generali della stabilità del sistema per migliorare l’esperienza dell’utente.
Changelog v1.6.2
- Aggiunta modalità portatile.
- Questo è lo stesso comportamento delle versioni precedenti di JTegraNX quando si trattava di creare file di dati, è stato appena re-implementato come opzione secondaria.
- Se viene rilevato
JTegraNX.ini
nella directory di lavoro in cui viene avviato il JAR, si attiverà la modalità portatile. - Puoi passare facilmente dalla modalità Standard a quella Portatile dal menu Impostazioni
- Migliorato il programma di aggiornamento per la nuova distribuzione.
- Il programma di aggiornamento ora acquisisce la versione in base all’architettura del sistema operativo del sistema, non all’architettura JRE.
- Se questo diventa un problema, farò in modo che utilizzi l’architettura JRE.
- Il programma di aggiornamento ora sovrascrive anche il file JAR attualmente in esecuzione e richiede un riavvio.
- Se scegli di non riavviare quando JTegraNX ti chiede di farlo, la voce di menu “Check for JTegraNX updates” viene impostata per riavviare JTegraNX.
- Il programma di aggiornamento ora acquisisce la versione in base all’architettura del sistema operativo del sistema, non all’architettura JRE.
- Si spera che abbia corretto la distribuzione per le architetture x86 e x64.
Changelog v1.6.1
- Corretto un piccolo bug con la richiesta di riconnessione del dispositivo durante l’installazione del driver APX.
- Aggiunto un piccolo vantaggio per l’implementazione della modalità portatile.
Changelog v1.6
JTegraNX è stato riscritto da zero in uno sforzo estremo per renderlo molto più stabile.
- JTegraNX non utilizza più TegraRCMSmash, la funzionalità per l’iniezione del payload RCM è ora scritta in JTegraNX.
- Il bit di iniezione del payload utilizza usb4java per portare a termine il lavoro.
- Prima che il dispositivo RCM venga inizializzato, JTegraNX verifica se il file del payload esiste e può essere utilizzato, se questo è falso, il dispositivo RCM non viene inizializzato, consentendoti di scegliere un payload diverso senza dover riavviare il tuo Switch in modalità RCM.
- Lo stack smashing utilizza
<setupapi.h>
invece di libusbK. - Gli argomenti personalizzati non sono più supportati.
- L’uso principale per questo era il montaggio della scheda SD, che è stato anche rimosso perché Hekate può essere fornito in bundle con JTegraNX e Hekate lo ha coperto. Se si verifica un errore, l’errore viene stampato nel registro, invece che JTegraNX si arresti in modo anomalo.
- Il bit di iniezione del payload utilizza usb4java per portare a termine il lavoro.
- Il listener di dispositivi RCM ora utilizza il modulo HotK di libusbK.
- Questo elimina due bug.
- Un bug in cui il dispositivo RCM non veniva rilevato all’avvio anche se era connesso.
- L’altro bug in cui il riavvio in RCM da un payload a volte non veniva rilevato.
- Questo elimina due bug.
- Aggiunto il rilevamento e l’installazione del driver APX.
- I privilegi di amministratore sono necessari per l’installazione del driver.
- JTegraNX può rilevare solo se manca il driver APX se il dispositivo RCM è connesso all’avvio di JTegraNX.
- Questo perché i moduli HotK e LstK in libusbK rilevano solo i dispositivi che hanno un driver libusbK installato per loro. Quindi, se un dispositivo non viene rilevato all’avvio utilizzando LstK, JTegraNX utilizza
<setupapi.h>
per verificare se è collegato un dispositivo che corrisponde al fornitore e agli ID prodotto di uno Switch in modalità RCM. Se ne trova uno, presume che manchi il driver APX. Fare in modo che JTegraNX rilevi il driver mancante quando il dispositivo è connesso dopo l’avvio richiederebbe l’implementazione di un secondo listener di dispositivi al di fuori di libusbK. Libusb standard non funzionerà perché può rilevare il dispositivo RCM solo se è installato il driver APX. - Se installi il driver APX mentre il dispositivo RCM è stato rilevato, verrà richiesto di riconnettere il dispositivo. Questo serve a prevenire il 50/50 di possibilità di errore durante la scrittura del payload sul dispositivo.
- Questo perché i moduli HotK e LstK in libusbK rilevano solo i dispositivi che hanno un driver libusbK installato per loro. Quindi, se un dispositivo non viene rilevato all’avvio utilizzando LstK, JTegraNX utilizza
- JTegraNX rileva anche se il driver APX errato è installato quando il dispositivo RCM è connesso all’avvio e dopo l’avvio.
- Non dovrei spiegare la differenza tra un driver mancante e un driver sbagliato.
- Il sistema di payload in bundle ora utilizza una mia libreria personalizzata chiamata GitHandler.
- Questo rende l’aggiornamento del payload molto più stabile.
- Questo elimina anche un bug critico che si è verificato quando il tag di rilascio per Hekate era v5.5.4-v2.
- Questo bug è stato causato dal vecchio sistema che tentava di analizzare la v5.5.4-v2 per ottenere il collegamento per il download di Hekate, che non è riuscito perché JTegraNX si aspettava una stringa come v5.5.4 e invece ha ottenuto v5.5.4-v2. Ciò ha causato il blocco di JTegraNX.
if (line.contains("<a href=\"/CTCaer/hekate/releases/tag/")) { latestVersion = line.substring(line.indexOf("tag/") + 5, line.indexOf("\">")); latestNyxVersion = line.substring(line.indexOf("Nyx") + 5, line.length() - 4); success = true; break; }
- GitHandler supera questo problema analizzando il collegamento di download di ogni risorsa scaricabile per versione per repository.
- Aggiunta la preparazione della scheda SD.
- Quando attivato, JTegraNX scaricherà tutti i requisiti di base per preparare la console Switch per CFW (basato su questa guida) e li copierà nel percorso di output specificato, non aver paura di puntarlo alla radice della scheda SD.
- Questa funzionalità utilizza anche GitHandler per garantire che venga scaricata l’ultima versione di ciascun prerequisito.
- Poiché sono così sicuro di GitHandler, anche l’aggiornamento automatico di JTegraNX lo utilizza ora.
- Il sistema di configurazione ora utilizza solo un file di configurazione per tutto.
- Ciò include le impostazioni dell’interfaccia utente, le configurazioni salvate e le informazioni sull’aggiornamento del payload.
- Anche il caricamento di configurazioni esterne è stato rimosso a causa del nuovo sistema.
- Se la configurazione selezionata viene eliminata e il testo del campo del percorso del payload corrisponde al percorso del payload della configurazione eliminata, il testo del campo del percorso del payload viene cancellato.
- Il file di configurazione principale e i payload in bundle ora vengono salvati in “Documents/JTegraNX/”.
- Il Tray Icon ora presenta un pulsante per iniettare semplicemente il payload specificato nel campo Payload Path.
- Aggiorna automaticamente l’etichetta quando viene modificato il percorso del payload.
- Se il payload specificato non esiste, non ti consentirà di iniettarlo.
- Il pulsante inoltre non permetterà di iniettare un payload se il driver APX è mancante o errato.
- Ora non devi più fare affidamento sull’auto-iniezione quando JTegraNX viene ridotto ad icona nel system tray.
- Aggiorna automaticamente l’etichetta quando viene modificato il percorso del payload.
- L’icona nella barra delle applicazioni ora mostra le notifiche quando viene iniettato un payload o quando si verifica un errore.
- Le notifiche vengono attivate solo se JTegraNX viene ridotto a icona nel system tray.
- Nascondi il registro è stato rimosso perché, onestamente, sembra inutile.
- Ora puoi personalizzare le impostazioni di JTegraNX a tuo piacimento.
- Ora puoi attivare il controllo automatico per gli aggiornamenti di JTegraNX.
- Ora puoi attivare il controllo automatico per gli aggiornamenti del payload.
- Ora puoi scegliere quali payload vuoi includere con JTegraNX.
- Ora puoi attivare o disattivare l’icona nella barra delle applicazioni.
- Sono state aggiunte nuove icone e più immagini di stato RCM.
- Sono stati aggiunti suggerimenti per i pulsanti che hanno un’icona senza testo.
Download: JTegraNX v1.6.7
Download: Source code JTegraNX v1.6.7
Fonte: github.com
JTegraNX v1.6.8 risolve un problema con l’aggiornamento di Hekate e aggiunge il supporto per Java 11 e versioni successive. Presto seguiranno altri aggiornamenti.