RGLoader - Forse ci siamo

RGLOADER è un progetto per creare un kernel patchato usando il RGH.

Vi prendo parte come beta tester, do una mano a disassemblare codice qua e la e brainstorming vari...

Ad oggi (ieri notte....) il kernel 13599 viene caricato ma c'è ancora un po' da fare con i fuseset/zeropair (da e79).

Vi lascio il link alla wiki: [url=http://xedevwiki.com/wiki/Main_Page]XeDevWiki[/url]

Alcune news:

- GLIGLI e Tyros hanno trovato Slim con 1BL e relativa 1BL key nuova
- Il CB sulle fat refurbished da MS è splittato come sulle FAT (jasper è 2BL=CB_A 6752 , 3BL=CB_B 84.. non ricordo)

Ovvio che sulle xbox già prodotte l'1BL non si può aggiornare. Il fatto del CB splittato sulle fat apre diversi scenari, alcuni buoni, altri no... Su queste il RGH deve essere fatto come sulle slim e potrebbe implicare tempi di glitch simili..

Cercherò di tenervi informati.

Ottime notizie veramente... complimenti...

Se serve una mano fai un fischio... :)

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

Ottimo, tienici informati...

Ragazzi siete dei grandi purtroppo non ho tantissimo tempo altrimenti facevo l'hack anche alla mia console e vi davo una mano come beta tester! Spero di riuscirci presto! :D

Che notizia! Ottimo lavoro rf1911!

Ho appena ricevuto la beta che forza l'errore E99 per testare il corretto caricamento del kernel con patch 13599.. appena posso lo flasho e vediamo...:)

ottime notizie!

wow !!!!!!!!!!!!
complimenti anche a te e seguiamo gli sviluppi

Here's a Quick explanation of the RGH and how it works.

For reference, 1BL = First Boot Loader, 2BL = CB [CB_B] {Slims & Refurbished Units have a CB_A as well}, 4BL = CD

The Xbox 360's boot system works like this:
1BL (First Boot Loader) is loaded by the CPU (also burned into the ROM of the CPU so it can't be changed)
1BL then Loads 2BL from the NAND, does a Hash compare, and then boots it.
2BL then Loads 4BL from the NAND and checks for the MS signature and correct encryption based on the private and local keys.
4BL then moves on to the rest of the boot sequence, somewhat modified between each revision,but the end result is your Dashboard.

What's Glitched here is the check when 2BL loads 4BL. [On Slims & Refurbs, it's the check when CB_A loads CB_B]
The glitch makes the CPU return correct values to the checks on 4BL, even though it's modified. [Again, Slims & Refurbs, Check is on CB_B by CB_A]
As such, regardless of the hash or signature of 4BL [or CB_B], it'll load as usual and do what ever we want it to do.

As the Xbox 360 will normally only attempt to boot 5 times [around 5 seconds from power on to fifth check], there isn't enough time to correctly glitch the Xbox 360 on some motherboard revisions. To make up for this, the CD [and CB_B] is patched to reload the Xbox 360 infinitely until a successful boot has occurred.

As to why it's un-patchable, if you haven't already noticed:

1BL is burned to the CPU's ROM. As ROM, or Read Only Memory, can't be re-programmed after it's initial programming at the factory, Microsoft can't change it in any currently released Hardware.
2BL is on the NAND, and Microsoft can modify it, but because there's no fuse check on the current version and 1BL will always recognize the old version as valid we can downgrade it as necessary.
4BL can also be modified. As we broke all the checks in 2BL though, we can run any 4BL we want, with or without correct signatures. Even if Microsoft decides to makes a new one, they can't stop us from downgrading it as well, as 2BL is the only law in the system after 1BL and when 2BL tells an application to boot, there's nothing to stop it from doing so.
As such, only with a new 1BL that renders the CPU hardware hack impossible can Microsoft prevent current versions of the Xbox 360 hardware from being exploitable. As 1BL can't be modified on any released hardware, It is not possible for it to be patched on said released hardware.
All currently released hardware revisions, excluding the Xenon (due to a difference in the CPU's clock controller), will ALWAYS be hackable.

Raga siete incredibili nn solo siete i primi a postare notizie ma addirittura i primi a tentare un booter per RGH che dire...sono davvero fiero di far parte di questo forumXD!!!

Grazie :)
Mi sono registrato solo per ringraziare il vostro del team del lavoro che state facendo :)
Io attendo RGH speranzoso e cerco novità ogni giorno, oggi sono stato ripagato. Aggiornateci in caso di ogni novità e ancora grazie.

Citazione:

---

Originariamente Scritto da Chuck Bartowski

Grazie :)
Mi sono registrato solo per ringraziare il vostro del team del lavoro che state facendo :)
Io attendo RGH speranzoso e cerco novità ogni giorno, oggi sono stato ripagato. Aggiornateci in caso di ogni novità e ancora grazie.

---

Grazie mille... presto avrete aggiornamenti in merito... :)

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

dopo che sarete riusciti a sfornare un kernel modificato(non "se ci riuscirete" badate bene perchè siete incredibilmente capaci,quindi do per certo che ci riuscirete),propongo di farli beatificare all'instante Santo Electron e San rf1911 XD

Stavo giusto tenendo in serbo della bava per momenti come questi :** la scena non muore mai!

Inviato dal mio GT-I9000 usando Tapatalk

Ma l'aspetto di RGLoader è uguale al kernel 13599?
Poi stavo cercando di spargere la voce, perchè magari qualche utente capace vi possa aiutare ( io è già tanto se uso visual basic XD magari ci vediamo sulla prossima console ) ma i siti volevano qualche prova in più, più avanti farete un piccolo video? Grazie mille.

Citazione:

---

Originariamente Scritto da Chuck Bartowski

Ma l'aspetto di RGLoader è uguale al kernel 13599?
Poi stavo cercando di spargere la voce, perchè magari qualche utente capace vi possa aiutare ( io è già tanto se uso visual basic XD magari ci vediamo sulla prossima console ) ma i siti volevano qualche prova in più, più avanti farete un piccolo video? Grazie mille.

---

Si, l'aspetto è lo stesso... si caricherà la stessa dash ma con delle parche, come già avviene per freeboot su Jtag...

Video probabilmente più avanti, non al momento...

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

Citazione:

---

Originariamente Scritto da riff82

dopo che sarete riusciti a sfornare un kernel modificato(non "se ci riuscirete" badate bene perchè siete incredibilmente capaci,quindi do per certo che ci riuscirete),propongo di farli beatificare all'instante Santo Electron e San rf1911 XD

---

Non dovrai certo santificare noi, ma tutti quelli che hanno partecipato!!!!!!!!!! In primis Stoker25!!

Grandi! Siamo tutti con voi!!

Citazione:

---

Originariamente Scritto da rf1911

Non dovrai certo santificare noi, ma tutti quelli che hanno partecipato!!!!!!!!!! In primis Stoker25!!

---

vabe ma a loro va proprio una statua d'oro e devono essere nominati divinità all'instante XDXDXD

Grandi ragazzi, se serve una mano, ho una Jasper 512mb con Cool Runner II già pronto a lavorare!

Ragazzi ci sono novità? :D

Vi stimo, grandi ragazzi!

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

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

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

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

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

novità?
allora avete trovato qualcosa di interessante?

Citazione:

---

Originariamente Scritto da Tommybig86

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

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

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.

Citazione:

---

Originariamente Scritto da 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.

---

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

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

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

Citazione:

---

Originariamente Scritto da 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

---

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

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

Citazione:

---

Originariamente Scritto da Tommybig86

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

Citazione:

---

Originariamente Scritto da Luke69

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

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.

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

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