Ricordando che l'unico exploit noto per 360 è presente nel kernel 4532 ed inferiori (gli stessi su cui è utilizzabile il metodo King Kong), e che la 360 è la prima console mainstream con un'efficace sistema anti-downgrade, si evince la necessità di aggirare il secondo per arrivare al primo.
Esistono fondamentalmente due principali modi per farlo: l'SMC Hack (scorrettamente ma molto più comunemente noto come "JTAG"), in cui la console "fa da chip per sè stessa", e l'RGH che usa un chip esterno, detto glitcher, per disturbare il processore al momento giusto e saltare alcuni controlli.
Ci sono in realtà multiple variazioni sul tema, considerando non solo le diverse interfacce e tecnologie presenti su diversi modelli, ma anche diverse compatibilità e prestazioni di queste varianti, diverse difficoltà di installazione, e che diversi chip...
Avremo essenzialmente una NAND contenente un sistema operativo non firmato, ed un chip che tenterà di far saltare il controllo ed osservare il risultato: se l'avvio fallisce, riavvierà la console e riproverà, potenzialmente all'infinito.
Di fatto, allo stato dell'arte attuale, 30 secondi sono già considerati un tempo molto lungo per un'installazione soddisfacente, mentre in passato anche 2 minuti erano considerati ragionevoli.
Considerando che, esattamente come sulla precedente console di Microsoft, la modifica è stata fondamentalmente inventata per avviarci Linux, la prima cosa che si andrà ad installare ed eseguire come sistema operativo sarà fondamentalmente XeLL (Xenon Linux Loader) o meglio uno dei suoi successori, quale Xell Reloaded. Questo homebrew è l'equivalente di GentooX Loader per la prima Xbox e vagamente paragonabile a Boot9Strap/Fastboot3DS nella scena Nintendo, in quanto non direttamente compatibile con il sistema operativo ufficiale ma utilissimo per avviare appunto Linux (od altri homebrew indipendenti dal sistema operativo), nonchè per dumpare l'identità della console o riscrivere la NAND senza un programmatore esterno. Per motivi storici, questa immagine "solo Xell" è popolarmente detta ECC
Una volta che avremo ottenuto grazie a Xell la CPU Key, ed ovviamente un backup della NAND allo stato iniziale (senza Xell) potremo poi dilettarci con XeBuild a creare un sistema operativo personalizzato, utilizzante il famoso kernel 4532 + FreeBoot + DashLaunch + i file dell'ultimo aggiornamento ufficiale per avere un sistema a prima vista uguale ad uno ufficiale ma con importanti differenze dietro le scene, quali il poter avviare Xell accendendo la console con Eject e varie patch per avviare titoli non firmati o regolare la velocità delle ventole; naturalmente sono possibili moltissime personalizzazioni, sia all'atto della creazione con XeBuild che in seguito.
Ah già, i chip: è importante sapere che in linea di massima, tutti i glitcher usano lo stesso FPGA (Xilinx XC2C64A) ed i relativi firmware sono in linea di massima universali; le differenze si avranno nel circuito stampato ed altri componenti, ed ovviamente nella qualità costruttiva. Non aiuta (ma nemmeno significativamente ostacola) il fatto che la massima parte dei prodotti disponibili al giorno d'oggi siano cloni...
I pinout spesso e volentieri sono diversi.
Se non Winchester (quindi perciò Trinity o Corona, compatibili con RGH2 su qualsiasi versione del kernel. L'RGH2 propriamente detto è un metodo superato da S-RGH e Muffin.
Il primo è di fatto un RGH2 accelerato (dopotutto la S significa Speed), ma più sensibile alla lunghezza e posizionamento dei fili (non stabilibili a priori per via delle tolleranze produttive). Richiede anche più saldature su punti piccoli; d'altro canto è più tecnicamente pulito dell'alternativa. Il chip più usato per S-RGH è l'X360ACE V3.
Il Muffin è invece una variante semplificata dell'RGH, con tolleranze più larghe sulla lunghezza dei fili, e che consente di non dover saldare direttamente su componenti SMD (bensì solo su pad vuoti). Come contro, è associata ad un rischio di danneggiamento del southbridge nel lungo termine (usando un modo meno ortodosso di rallentare il processore, che porta ad un surriscaldamento durante i tentativi di avvio). I chip più utilizzati per questo metodo sono il CoolRunner Rev C per le Trinity e Rev D per le Corona, oppure il suo clone Matrix V1 (rispettivamente senza e con oscillatore, comunque disattivabile rimuovendo un componente).
Come abbiamo detto nell'introduzione, i chip sono in massima parte intercambiabili, ed è perciò tecnicamente possibile utilizzarne uno per fare il lavoro di un altro (applicandogli un firmware appropriato e sapendo come adattare la piedinatura), tuttavia la qualità è variabile (ad esempio, il CoolRunner è utilizzabile benissimo anche per S-RGH, il Matrix meno).
Per prima cosa parliamo dell'eccezione, ovvero le Xenon, che sono di fatto incompatibili con l'RGH. Se fossero ancora su un kernel 7371 od inferiore (ovvero non aggiornate da metà 2008 circa) si possono però modificare con JTAG. Esiste invece per le console più aggiornate (15572 e successive) un metodo chiamato R-JTOP, ibrido tra JTAG ed RGH, adattabile alle Xenon.
Per tutti i modelli Fat successivi ci sono invece molte varianti dell'RGH possibili, ma le più diffuse sono R-JTOP (sempre solo su kernel 15572 o maggiore) ed RGH 1.2, entrambe utilizzanti un chip collegato nello stesso modo ma con firmware diversi. I chip più utilizzati al giorno d'oggi sulle Fat sono sempre i CoolRunner (C o D che sia) ed i Matrix senza oscillatore.
Notiamo come, con poche ed ormai rare eccezioni, convenga aggiornare completamente la console prima di modificarla.
I programmatori classici (JTAG + SPI) hanno appunto due funzioni principali, di cui potremmo necessitare di entrambe, una, o nessuna:
La massima parte dei chip è venduta senza firmware. Dovremo perciò programmarli con un file XSVF che lo contenga tramite la loro porta JTAG (da non confondersi con una 360 modificata col metodo "JTAG", che non richiede un chip!)
Alcuni chip sono preprogrammati in fabbrica (come gli X360ACE V3 per le Corona), oppure alcuni venditori offrono un servizio di programmazione: in questi casi potremmo fare a meno di un programmatore per i chip, ma sarebbe comunque un vantaggio averlo a disposizione, dal momento che anche una volta definita una console ed una variante dell'RGH, potremmo voler provare differenti firmware con timing diversi, per trovare quello che si avvii più rapidamente.
Avremo sicuramente bisogno di un modo per creare un backup della NAND (anzi, più di uno, in modo da poterli verificare a vicenda), nonchè di installare Xell; ci servirà quindi un programmatore di NAND SPI.
Naturalmente, le console Corona V2, V4, o V6 hanno una NAND eMMC invece che SPI, quindi non useremo tale funzione.
Tra i principali abbiamo:
Cavo parallelo - facilmente costruibile in casa, ma richiede un PC con una porta parallela ed una certa creatività nel posizionamento di PC e console (i fili devono essere molto corti, nell'ordine degli 8 cm); è inoltre molto lento (ore intere).
Matrix NAND Programmer - economico e di qualità accettabile, ma non utilizzabile come programmatore JTAG senza significative modifiche al circuito stampato.
Xecuter J-R Programmer V2 - un'ottima scelta bilanciata per uso personale. Buone prestazioni (circa 4 minuti per una tipica NAND da 16 MB). Attenzione ai cloni, funzionanti senza problemi ma a volte con connettori molto stretti o larghi.
Xecuter NAND-X - un prodotto di fascia alta, fortemente raccomandato per chi avesse molti amici, ma probabilmente eccessivo per uso personale.
A maggior ragione, anche per essi uno vale l'altro, seppur con differenze di qualità, comodità, e prestazioni.
Separatamente ad essi, per le console eMMC avremo bisogno di un programmatore dedicato, ovvero di un adattatore meccanico (quale lo SD Tool di Element18592, od uno autocostruito) e di un lettore SD compatibile.
Attrezzi e materiali per saldatura: saldatore da circa 15~25 W con temperatura regolabile, stagno fine preferibilmente con piombo, flussante, alcool (per rimuovere il flussante), carta vetrata fine o (meglio) penna in fibra di vetro per grattare via il solder resist, e soprattutto abilità dell'operatore.
Cavi adeguati per collegare tra di loro chip, programmatore, computer, e console (dopo aver verificato cosa sia incluso con i prodotti da voi scelti):
Fili di diametro 28 o 30 AWG (ovvero cavi IDE di scarto, oppure fili isolati in Kynar se si vuole fare un lavoro professionale).
Cavo miniUSB (per la maggior parte dei programmatori commerciali).
Cavo tra chip e programmatore, in genere incluso con quest'ultimo, e connettore da montare sul chip se non preinstallato (in genere, i classici connettori Berg/Dupont "per arduino/raspberry" maschi in singola fila); alternativamente si può tagliare la spina del cavo e saldarlo direttamente al chip.
Cavo tra NAND e programmatore, in genere incluso con quest'ultimo: quelli Xecuter si dividono in tre e sono progettati per l'uso con un QSB opzionale, alternativamente si possono tagliare le 3 spine piccole e saldarlo direttamente alla scheda madre.
Con il J-R Programmer è incluso un terzo cavo più largo, detto Rater; è inutile a meno che non abbiate un chip Xecuter compatibile e vogliate usare la sua funzione di ottimizzazione automatica.
I proprietari di console Corona che non abbiano il segnale POST_OUT collegato necessiteranno naturalmente di un Postfix Adapter (V1 o V2, sono equivalenti).
Avrete anche bisogno di un PC, preferibilmente con Windows XP/Vista/7 a 32 bit (una VM è perfettamente accettabile, se sapete come destreggiarvi per collegarci dispositivi USB). Presumendo utilizziate un programmatore Xecuter, installateci anche il .NET Framework 4, e scaricate ed estraete JRunner_V0.7 di BenMitnick, che supporta l'ultima versione ufficiale (17559).
Nastro biadesivo per fissare il chip.
...
Visto il gran numero di varianti, non è fattibile spiegarle individualmente: completate perciò queste istruzioni con uno schema di montaggio per il vostro chip e modello (vedi siti a fine pagina). Accertatevi di avere compreso cosa state per fare e perchè prima di farlo. Questo inoltre non è un corso di saldatura, bensì un esame.
Accendere la console ed aggiornarla all'ultima versione (17559) via internet od USB. Spegnerla e scollegare tutto.
Smontate la console, fino ad arrivare alla scheda madre completamente libera dal case metallico interno. Raccomando la lettura di iFixIt.
Non è necessario rimuovere Xclamp e dissipatore, ma se sapete farlo senza danni, è una buona idea farlo e togliere la pasta termica, ormai vecchia, per poi rimetterla alla fine (guadagnandoci anche in manovrabilità della scheda madre).
Identificate tutti i punti di saldatura necessari, rimuovete il solder resist, ed aggiungetevi una piccola pallina di stagno fresco.
Montate fisicamente il chip nella posizione desiderata: generalmente, essa è sopra la presa video per le Fat, ed a destra del southbridge per le altre.
Saldate il QSB o il cavo per la NAND.
Saldate i fili/connettori del chip, facendo attenzione a rispettare il più possibile lunghezze e percorsi "standard".
Collegate il programmatore al PC, ed installatene i driver. Aprite il software e verificate che venga riconosciuto. (In JRunner, apparirà il logo del vostro programmatore nell'area vuota tra i pulsanti "Write Nand" e "Nand Compare".
Dopo aver verificato che non appoggi su superfici metalliche, collegate la NAND al programmatore, la scheda madre all'alimentazione (ma non accendetela!!) ed eseguite multipli backup.
Nel caso di JRunner, è sufficiente impostare almeno 2 letture in alto a sinistra , premere "Read Nand", ed attendere i risultati. I backup verranno salvati nella cartella "output" come "nandread?.bin".
Nella scheda XeBuild in alto a destra, verificate che sia selezionata la versione del sistema attuale, la scheda madre corretta, ed il tipo di exploit desiderato (ad esempio, per Muffin ed S-RGH, si selezioneranno "Glitch2" e "CR4").
Cliccare "Create ECC" e salvare il file image_00000000.ecc contenente Xell.
Installarlo con il pulsante "Write ECC": la console ora non sarà più avviabile senza un chip funzionante (a meno ovviamente di non ripristinare un backup pulito).
Staccare il cavo di alimentazione della console.
Scollegare il cavo NAND dal programmatore e collegare quello JTAG al chip (non è necessario scollegare il programmatore dal computer mentre si faccia ciò, ma è consigliato). Alimentare il chip.
Selezionare in JRunner: Advanced → Custom Nand/CR functions → Xsvf → il firmware desiderato per il chip, e programmarlo. Disattivare l'alimentazione del chip e rimuovere il cavo.
Se è stato rimosso il dissipatore, riapplicare la pasta termica e rimontarlo.
Riposizionare la scheda madre nella schermatura metallica inferiore; montare e collegare la ventola.
Collegare la console ad alimentazione e monitor/TV, ma non montare HDD od altri accessori, ed accenderla (è possibile usare un telecomando infrarossi, un controller USB, o rimontare il pannello anteriore ed usare il pulsante od un controller wireless).
Attendere che venga visualizzato Xell (se non si avviasse in un tempo ragionevole, sospettare il chip, il suo firmware, od i collegamenti), che mostrerà dopo un po' il Fuseset, la CPU Key, e la DVD Key. Si raccomanda di scattare una foto leggibile a questa schermata, spegnere poi la console.
Tornando su JRunner, verificare che in Load Source sia selezionata uno dei backup originali e non il file ECC.
Inserire la CPU Key ottenuta nel passaggio precedente; appena completata verrà verificata, e nella scheda KV Info appariranno dettagli sulla nostra console.
Verificare di nuovo i dati nella scheda XeBuild, e premere il pulsante "Create XeBuild Image".
Infine dovrete programmare la nand appena creata, col nome updflash.bin, nella console: potete usare il vostro programmatore con la funzione "Write Nand", oppure metterla nella root di una chiavetta USB MBR/FAT32, inserirla nella console, accenderla, ed aspettare un paio di minuti che Xell faccia tutto da solo.
Accendete la console: dovrebbe avviarsi "normalmente", escluso ovviamente il tempo aggiuntivo necessario per il glitching.
Potete ora rimuovere dalla scheda madre il cavo per la NAND, e riassemblare completamente la console.
Avete ora una console con RGH perfettamente funzionante, avviabile con qualsiasi modo eccetto che col tasto Eject (che ora avvierà Xell).
Potete già avviare titoli non firmati, anche se giustamente vi starete chiedendo come farli apparire nella dashboard ufficiale. Ecco un valido modo di proseguire:
Scaricate la versione disco di XeXMenu e masterizzatela: si avvierà senza problemi (che NON significa che ora potrete avviare dischi copiati).
Alternativamente, potete scaricare la versione LIVE (digitale) ed usare un file manager apposito per Xbox/360 (che gestisca quindi il file system FATX) per metterlo direttamente su HDD o chiavetta formattata "per uso col sistema", ma questi programmi non sono molto affidabili... Troverete in questo caso XeXMenu nella sezione "giochi demo".
Una volta entrati in XeXMenu premete RB per entrare nel file manager; se avete usato la versione disco, selezionate il lettore DVD (con le frecce ←/→ oppure X) dove troverete la cartella CODE9999, che potrete copiare in Hdd1:/Content/0000000000000000/ per installarne la versione digitale.
Ora scaricate le ultime versioni di Aurora e DashLaunch; estraete tutti i file del primo in una cartella "Aurora" su una chiavetta, mentre del secondo estraete solo Installer/default.xex in una cartella "DashLaunch".
Inseritela nella console e tornate in XeXMenu. Copiate la cartella Aurora nella root di Hdd1, e sempre nella root create una cartella "Homebrew" in cui copiare quella di DashLaunch.
Avviate DashLaunch (o meglio, il suo configuratore) e divertitevi:
Nella sezione Paths, selezionate Default → Hdd:\Aurora\Aurora.xex
Nelle sezioni Behavior, Network, Timers configurate a vostro piacimento (istruzioni ed esempio tipico) le patch.
Premete LB, verificate che la quarta opzione sia Uninstall (nel caso non lo fosse, selezionatela), poi selezionate la seconda, System Info, ed impostate le temperature desiderate (sulla mia Trinity uso 55/53/52).
Tornate indietro, premete LB, scorrete fino a Flash, e premete X per salvare le impostazioni dei tab precedenti.
Spegnete e riaccendete la console: si avvierà direttamente in Aurora (a meno che non teniate premuto RB quando l'accendiate od usciate da un titolo).
Premete Start in Aurora e configurate anch'essa. Io vi raccomando:
Nella sezione Profile, selezionate Auto Sign In ed il vostro utente.
Nella sezione Content, aggiungete le cartelle in cui si trovano i titoli. Sicuramente Hdd1\Content\0000000000000000 per i titoli digitali, più eventuali altre cartelle a vostra discrezione per homebrew e backup di dischi in formato estratto.
Nella sezione Modules, attivate se desiderato il server FTP per trasferire file via rete.
Tornate alla schermata iniziale e premete B. Nella sezione Display disattivate il letterboxing.
Se siete online, tornate alla schermata iniziale e premete Back. Nella sezione Scripts aprite Aurora Repo Browser, e nella sezione Utility scaricate Aurora Disc to GOD installer: questo accessorio vi consentirà di creare facilmente backup dei vostri dischi originali.
Buon divertimento!