RGH1.3 è un avanzato metodo di Reset Glitch Hack sviluppato per le console Xbox 360 “Fat” (modelli Xenon, Zephyr, Falcon e Jasper), progettato per superare i limiti delle tecniche precedenti come RGH1.2 e RGH3.
RGH1.3 si rivolge a chi cerca boot più rapidi e affidabili, in particolare per console che non si avviano in modo consistente. Questo sistema, ideato da würthless elektroniks, combina hardware e software, integrando un chip glitch, la catena di bootloader di RGH3, un file CB_B patchato e un’immagine SMC modificata per generare glitch estremamente rapidi sulla CPU.
Il progetto viene descritto scherzosamente come “RGH3 con un chip glitch” e si distingue per il monitoraggio aggressivo del processo di avvio, riducendo i tempi di attesa da 400 ms a 10 ms e riavviando automaticamente la console in caso di errori, risultando ideale per modding di console difficili.
Per le motherboard più vecchie, come Xenon e Zephyr, RGH1.3 include la variante EXT+3, che utilizza EXT_CLK per accelerare i tentativi di boot adattandosi alle peculiarità di queste console.
Tra le caratteristiche principali troviamo l’accelerazione della fase iniziale del glitch grazie a CB_X di RGH3, un SMC hackerato che rileva errori tramite i bit POST 6 e 7 e riavvia automaticamente la console, un secondo watchdog che resetta se l’animazione del Ring of Light non parte in tempo, e il CB_B modificato che consente il monitoraggio dei bit POST durante l’HWINIT.
Per console difficili come Jasper, il sistema fornisce un hard reset e include diagnostica visiva tramite la Ring of Light con codici colore per indicare lo stato del boot o eventuali errori.
Inoltre, grazie allo script g3fix.py, è possibile ripristinare la compatibilità con vecchi kernel come Blades o Kinect, richiedendo la CPU key.
Rispetto a RGH1.2, questa soluzione offre riavvii istantanei in caso di errore e un approccio più aggressivo, ma richiede modifiche hardware come il taglio di tracce o la rimozione del tilt switch con diodi.
Rispetto a RGH3, i glitch risultano invece più precisi e si evita il blocco dell’SMC che potrebbe spegnere la console, ma non è indicato per console che già instabootano correttamente con RGH3.
RGH1.3 è dunque utile per console che non bootano al primo tentativo, utenti con microcontrollori meno precisi di CPLD/FPGA e modder che vogliono ottimizzare console problematiche come “bad Jasper” o “bad Falcon”.
Flashing XeLL
Importante: È sempre necessario effettuare il backup della NAND prima di procedere! In caso contrario si rischia di perdere il keyvault!
Selezionare l’ECC desiderato dalla directory ecc/ e caricarlo in J-Runner tramite l’opzione “Load Glitch2 XeLL”. Successivamente è sufficiente cliccare su “Write XeLL”.
Dopo la scrittura di XeLL, la console, una volta accesa, entrerà in XeLL entro un minuto. Naturalmente, prima ciò avviene, meglio è.
Per le console particolarmente ostinate
Se una console non effettua il glitch in modo affidabile, la causa è legata a un comportamento anomalo della scheda madre. Alcuni sistemi, infatti, rifiutano di glitchare oltre CB_A, indipendentemente dal numero di tentativi, e l’unica soluzione possibile è eseguire un power cycle.
Questo problema è stato osservato soprattutto su Jasper, ma può presentarsi anche su Falcon.
Per questi casi sono stati creati gli ECC badjasper e badfalcon, che permettono un hard reset automatico della console se il boot fallisce nelle fasi iniziali. Il metodo non garantisce risultati immediati e può richiedere anche 30 secondi o più, ma di norma consente l’avvio entro 10–15 secondi.
Esistono due condizioni principali per stabilire se una console necessita di questo workaround. Se in un power cycle si presenta il problema, ma in un altro la console si avvia correttamente, allora è opportuno utilizzare badjasper.
- La console non riesce mai a completare il glitch in un singolo power cycle, anche dopo oltre 20 tentativi con RGH1.2 o RGH3.
- Con RGH1.3, sulla Ring of Light lampeggia una singola luce rossa (vedere i codici di lampeggio riportati più sotto).
Quando si utilizza badjasper o badfalcon e la console entra in bootloop per un tempo eccessivo, è sufficiente tenere premuto il pulsante Power per spegnerla immediatamente.
Inoltre, per una maggiore comodità, mantenendo premuto lo stesso pulsante per cinque secondi, sia con ECC normali che con quelli modificati, la console si spegne istantaneamente.
Codici di lampeggio della Ring of Light
Il LED lampeggiante del chip di glitch non fornisce quasi mai indicazioni utili. Per questo motivo, il codice SMC è stato modificato così da visualizzare informazioni direttamente sulla Ring of Light.
In questo modo l’utente può capire lo stato del sistema e individuare il punto esatto in cui il tentativo di glitch non è andato a buon fine.
Di seguito viene illustrato il significato delle varie combinazioni di luci colorate:
| Codice colore | Quello che succede | Cosa dovrebbe succedere dopo |
|---|---|---|
| Rosso | CB_A avviato | Si verifica un impulso di glitch, CB_X funziona |
| Rosso/Rosso | CB_X avviato | CB_B carica e funziona |
| Rosso/Arancione | CB_B avviato | Fusecheck/HWINIT viene eseguito |
| Rosso/Arancione/Rosso | HWINIT in esecuzione | HWINIT non si blocca |
| Rosso/Arancione/Arancione | HWINIT completo | Il CD carica ed esegue |
| Rosso/Arancione/Verde | GetPowerUpCause è arrivato | Kernel o XeLL carica ed esegue |
| Normale anello di luce bootanim | Avvio di finitura Kernel/XeLL | Le cose funzionano |
Si ricorda che la CPU si trova nello stato più instabile nei 100 ms successivi al glitch pulse. La maggior parte dei tentativi di boot fallirà con un lampeggio Rosso o Rosso/Rosso.
Questi codici di lampeggio aiutano anche a regolare i tempi del chip glitch. Se la CPU non supera CB_A, il timing è completamente errato oppure l’ampiezza dell’impulso è troppo grande. L’obiettivo è che CB_B parta in modo costante ed esegua HWINIT.
Esiste inoltre la gestione degli errori. Se qualcosa va storto all’avvio, il sistema mostrerà un Red Ring of Death e si spegnerà. È possibile premere Eject e Sync come di consueto per ottenere i codici di errore. I codici di errore di RGH1.3 sono:
- 3333: I bit POST 6 e 7 non erano bassi al termine del reset della CPU. Mancano i diodi oppure sono collegati in modo errato. Controllare inoltre che lo switch tilt sia stato disabilitato. Se si utilizza il condensatore e compare questo errore, significa che c’è troppo rumore sul filo PLL.
- 0000 (visualizzato come 4444): La CPU non è arrivata a
CB_Ain tempo. La CPU potrebbe essere guasta oppure c’è un errore nel cablaggio.
Creazione di updflash.bin
L’autore dubita che J-Runner supporterà mai questa parte, quindi viene fornita una soluzione alternativa.
In J-Runner, è necessario assicurarsi che sia selezionata l’opzione “RGH3” prima di generare la NAND. Non importa se si sceglie 27 MHz o 10 MHz, lo script di build utilizzerà comunque lo stesso SMC.
Una volta generata l’immagine e convertita a RGH3, non bisogna flasharla immediatamente. È necessario eseguire alcuni comandi da linea di comando.
Se si sono utilizzati i timeout raccomandati sopra:
python3 convert_rgh13.py path/to/updflash.bin
Se si è utilizzato badjasper:
python3 convert_rgh13.py path/to/updflash.bin --badjasper
Se compare il messaggio:
converted to RGH1.3 successfully, happy flashing
allora il file updflash.bin è pronto per il flashing. A questo punto si può flashare, testare la console, regolare i timing del chip glitch se necessario e godersi il risultato.
Esecuzione di kernel più vecchi
La catena di bootloader di RGH3 interrompe il supporto per i kernel più vecchi (in particolare Blades e Kinect). Per questo è stato fornito lo script g3fix.py, che risolve questi problemi e consente loro di avviarsi.
Poiché questo script sostituisce il manufacturing loader con un CB_A retail, è necessaria la CPU key per completare l’operazione. Probabilmente sarà necessario anche installare PyCryptodome affinché lo script funzioni.
Il comando da eseguire è:
python3 g3fix.py <your-cpu-key> path/to/updflash.bin
L’output dovrebbe apparire simile a questo:
found Jasper-style 16m NAND CB_A replaced CB_X replaced CB_B 6752: skipping SMC HMAC panic CB_B padded recalculating ECC data... writing final NAND... dunzo
Consultare questa issue per la documentazione tecnica del bug.
Supporto Slim
Per ora non è previsto. RGH3 effettua già un instaboot affidabile sulle Slim, quindi non c’è reale necessità di convertire questo codice per quelle console.
LED lampeggianti su RGH3
Sulle Slim non è utile, poiché già instabootano. Sulle Fat, invece, è assolutamente possibile e consigliato, vista la maggiore difficoltà che queste presentano con RGH3. Infatti l’approccio con tilt switch è stato scelto proprio perché facilmente portabile su RGH3.
Supporto Dual NAND
Non supportato in questa release, ma potrebbe essere aggiunto facilmente in futuro. Non è comunque considerato necessario: le Xbox 360 oggi sono economiche.
Perché non usare RGH1.2?
Lo sviluppo professionale si concentra su casi d’uso validi e affidabilità, non sul “WorksForMe” o sull’elitismo che danneggia la scena Xbox 360.
Se un modder vuole atteggiarsi da professionista, dovrebbe avere un vero lavoro, con colleghi, un capo e la necessità di collaborare per mantenere il posto e pagare le bollette. È in quel contesto che un certo atteggiamento mostra i suoi limiti.
Softmod e JTAG
Il rilascio di RGH non ha reso obsoleto JTAG e i softmod non hanno reso obsoleti né l’uno né l’altro. L’unico modo per rendere inutili per sempre RGH, JTAG e softmod sarebbe la pubblicazione delle chiavi private RSA-2048 utilizzate per firmare i bootloader, o un bootloader firmato che rompa la chain of trust.
Bug report e manutenzione
Per segnalare bug, occorre fornire quante più informazioni possibili, come la revisione della motherboard (Falcon, Jasper, ecc..), il tipo di GPU, il produttore della SDRAM, la revisione/date code del southbridge, ecc.. Maggiori informazioni equivalgono a migliori correzioni.
Consultare qui l’elenco dei bug noti.
Problemi noti e miglioramenti
È possibile eliminare i diodi POST, ma l’unico modo sarebbe inizializzare manualmente i FIFO dell’SMC all’inizio di CB_B, quando la CPU è ancora instabile dopo il glitch.
Ciò ridurrebbe l’affidabilità. Inoltre, poiché la maggior parte dei glitch falliti avviene nei primi 100 ms, le linee POST devono essere comunque monitorate.
È teoricamente possibile velocizzare i reset dei tentativi falliti resettando semplicemente la CPU. Tuttavia, la CPU può entrare in coma e bloccarsi, ignorando i successivi tentativi di reset.
Lo sviluppatore 15432 sta lavorando a miglioramenti per RGH3 che dovranno essere portati anche in questo metodo, una volta rilasciati e testati su più console.
Fonte e download: github.com
