RGLoader - Forse ci siamo

[DoM3]

Vi stimo, grandi ragazzi!

[Tommybig86]

ragazzi una curiosità ma puere per il jtagh si passò tanto tempo tra la scoperta dell exploit e la creazione di dash???

[Pa0l0ne]

Veramente pochissimo tempo per codare freeboot,....ma credimi, e' un po' come la storia dell'uovo e della gallina, mica so' dirti se il jtag e' stato cucito su freeboot o viceversa...probabile il progetto sia andato "di pari passo". Bisognerebbe chiedere ad "Ikari"....chiunque esso/i sia/siano!


Sent from my Jailbreaked iPhone using Tapatalk

[Electron^-]

Purtroppo la situazione è ben più complicata al momento... con il JTAG, si sfruttava un Bootloader che aveva un bug, mentre al momento cerca di capire come permettere l'esecuzione del boot... è "moooooooooolto" più complessa la cosa...

[brundu]

grande notizia complimenti ,come sempre qui si trova qualita' e competenza .

[The Pusher]

Il discorso è che stiamo testando praticamente un .py al giorno , per avere una sorta di bootloader efficace (in parole spicciole)
I test sono abbastanza complessi in quanto ogni tipo di console "reagisce" (o carica) usando una schematica diversa la dash.
Quindi , il progetto va avanti , tranquillamente , sappiate che appena trovato il .py giusto (file che genera a sua volta "un altro file" da iniettare modello .ecc del glitch) il gioco è fatto (SEMBRA SEMPLICE DETTO COSI' )
Ho cercato di essere il piu' comprensibile possibile nella spiegazione,ma adesso almeno avete un quadro chiaro di quello che è il progetto , i test , il modo di approcciarsi.
Stay Tuned

[Tommybig86]

novità?
allora avete trovato qualcosa di interessante?

[Pa0l0ne]

novità?
allora avete trovato qualcosa di interessante?

Di interessante c'e' praticamente tutto il progetto in se'!

La notizia del giorno e' relativa alla tabella di Post Code che viene popolata su un bus ad 8bit durante il boot della nostra Xbox360 (pin da Ft6u1 ad Ft6u8)
Avere piena conoscenza degli "step" di questa tabella rende il debugging ed il concepimento di Rgloader molto piu' "semplice" di un "banale" output da Rs232 tramite putty (interfaccia di cui ogni xbox360 e' dotata ma con logica ttl).
il problema e' che ovviamente non tutti gli step sono noti, rendendo, di fatto, la comprensione del processo di booting non sempre molto chiara. Molta di questa conoscenza si deve al nostro rf1911 che ne ha postato diversi valori come potete verificare voi stessi da qui:
[url=http://xedevwiki.com/wiki/POST]POST - XeDevWiki[/url]

Spero di essere stato "abbastanza chiaro", nei limiti della specificita' tecnica di un tale progetto.

Un grazie ad Rf1911 !

Allegato 963

Concludo quotando le parole del nostro rf1911:
Please fill in all known POST Codes. (And create a better table if you can )

[Chuck Bartowski]

Grandi ragazzi! Sono convinto che potrete farcela, noi avremo pazienza

[rf1911]

Finalmente oggi mi torna il pic per montarmi l'spi flasher, dato che il nandx proprio a fagiolo era morto.. con l'lpt non mi sono azzardato.. comunque, il mio intento fra oggi e domani è modificare il build.py per togliere le patch di GLIGLI sul controllo dell'SMC (incluso quindi lo Zeropairing). Se da una parte questo eviterà problemi legati allo zeropairing, e cioè evitera in breve che l'xbox pensi di essere appena uscita dalla fabbrica, dall'altra darà solo 5 reboot al glitch per partire. Dato che dopo 5 reboot l'xbox va in rrod se non ci va significa che il glitch è partito e con il post possiamo sapere quel è l'ultimo step eseguito. Questo segna un punto, poi ripartiamo.

[Luke69]

Finalmente oggi mi torna il pic per montarmi l'spi flasher, dato che il nandx proprio a fagiolo era morto.. con l'lpt non mi sono azzardato.. comunque, il mio intento fra oggi e domani è modificare il build.py per togliere le patch di GLIGLI sul controllo dell'SMC (incluso quindi lo Zeropairing). Se da una parte questo eviterà problemi legati allo zeropairing, e cioè evitera in breve che l'xbox pensi di essere appena uscita dalla fabbrica, dall'altra darà solo 5 reboot al glitch per partire. Dato che dopo 5 reboot l'xbox va in rrod se non ci va significa che il glitch è partito e con il post possiamo sapere quel è l'ultimo step eseguito. Questo segna un punto, poi ripartiamo.

Qualcuno del vostro gruppo sarebbe capace di fare una patch ad hoc per togliere il limite dei 5 reboot senza però far credere all'xbox ogni volta di essere appena uscita dalla fabbrica? Altrimenti mi sa che su slim il RGLoader sarebbe inutilizzabile, dubito che nei 30 secondi di boot delle slim (di Xell intendo) si rebooti meno di 5 volte...

[rf1911]

Per le slim il problema non sussiste, il glitch agisce sul controllo dell'hash del cb_b che controlla l'hash dell'smc, quindi viene patchato e i riavvii sono infiniti. Quindi nessun ZP. Il discorso è solo per le fat. Non ho una slim da testare..

[Tommybig86]

fatemi capire, fino ad adesso le fat andavano bene cosa hanno ke nn vanno x reset???? insomma parte xell il problema è il tempo??? scusate l'ignoranza

[Luke69]

fatemi capire, fino ad adesso le fat andavano bene cosa hanno ke nn vanno x reset???? insomma parte xell il problema è il tempo??? scusate l'ignoranza

Se ho capito bene, GliGli ha fatto una patch per il SMC che rende i reboot infiniti nelle console fat (solitamente per un limite Microsoft dopo 5 reboot darebbero i 3 led rossi) che però a quanto pare ad ogni riavvio della console, essa crede di essere appena uscita di fabbrica...ora, con Xell non crea nessun problema perchè tanto Xell non si deve configurare, mentre su una dashboard ogni volta che si accende la console bisognerebbe rimettere tutte le impostazioni...

[Tommybig86]

a ecco, però ragazzi ho sentito dello squirt oppureei l patrix ke bootava in 5 secondi potrebbe essere la soluzione???

[Electron^-]

a ecco, però ragazzi ho sentito dello squirt oppureei l patrix ke bootava in 5 secondi potrebbe essere la soluzione???

Il matricola bootta in 5 secondi, ma su far, dove hai gli stessi tempi anche con il classico CPLD...
Il problema sono le slim che ci mettono 10-120 secondi...

Sent from my Nexus S using Tapatalk while I'm looking what you are doing... o.O

[Electron^-]

Se ho capito bene, GliGli ha fatto una patch per il SMC che rende i reboot infiniti nelle console fat (solitamente per un limite Microsoft dopo 5 reboot darebbero i 3 led rossi) che però a quanto pare ad ogni riavvio della console, essa crede di essere appena uscita di fabbrica...ora, con Xell non crea nessun problema perchè tanto Xell non si deve configurare, mentre su una dashboard ogni volta che si accende la console bisognerebbe rimettere tutte le impostazioni...

In realtà il problema non é quello di perdere la configurazione... la cosa è ben più complessa... il fatto di far credere alla console di essere in modalità fabbrica, serve per bypassare alcuni controlli e far eseguire determinati codici...

Sent from my Nexus S using Tapatalk while I'm looking what you are doing... o.O

[rf1911]

Facciamo un po' di chiarezza. Sia su fat che su slim l'SMC viene patchato. Ora su slim non c'è problema perché il controllo sull'integrità (hash) dell'smc viene eseguito del CB_B che grazie al glitch sul CB_A può essere modificato:

- SLIM: CB_A->CONTROLLO_HASH(CB_B)->GLITCH->CONTROLLO_OK->QUINDI CARICA CB_B CON LE PATCH SU INTEGRITA' SMC / CD->CD CUSTOM CARICA XELL
- FAT: CB->CONTROLLO(CD)->GLITCH->CONTROLLO_OK->QUINDI ESEGUE CD CUSTOM->CD CUSTOM CARICA XELL

Siccome per le fat il controllo sull'integrità dell'SMC lo fa il CB (immodificabile perché firmato da MS!) per ovviare a questo si è attuato lo ZP cioè mettere a zero l'hash sull'SMC. Questo fa sì che il CB non controlli l'hash credendo di essere in modalità fabbrica, non caricando quindi la dash. Da qui le prove da fare senza modifica all'SMC.

[Tommybig86]

quindi si può dire che il glich su slim e più pulito perchè interviene prima rispetto alle fat, ora ditemi ma il cb fat e pachabile?? intendo da microzoz

[rf1911]

Certo... MS lo ha già fatto in passato quando ha aggiornato alla dashboard 8955. Ma questo non significa che il glitch non sia replicabile!