[CB ANTI RGH]NUOVO aggiornamento XBOX LIVE Kernel 2.0.14717

**MARCHISIO80** · 15-02-12

Originariamente Scritto da Tommybig86

Ma se venisse confermato chi come me ha gia rgh nn corre rischi giusto? Nel senso ke il freeboot uscirà o c'e il rischio ke non riescano a fare il freeboot?

Inviato dal mio GT-S5570 usando Tapatalk

Il freeboot si fa sempre,come per Jtag

E le Jtag continuano ad aggiornarsi col FReeboot dal 2009

Ovviamente bisogna stare lontani dal Live,cosa che si fa anche senza pericolo aggiornamento

**MARCHISIO80** · 15-02-12

Originariamente Scritto da phobos_79

Questo come mai? le nand sono distinte fisicamente, cambierebbe il CB solo della nand stock, e l'hack non è soft, rimangono solo gli efuse e 1BL in comune tra i 2 boot, ma non si era detto che non erano considerati ai fini dell'rgh?

Sulle FAT il CB centra
Non cambia solo la nand,viene bruciato un e-fuse nella cpu
Inoltre su dual CB cambia almeno il timing,ci stanno lavorando,ma al momento non e' hackabile

Originariamente Scritto da phobos_79

ps: è terrribile la censura "no link"... davvero, non ho parole, e lavoro per i cinesi...nessuno ruba gli utenti di nessuno...

Non e' censura,e' solo al momento una persona,per di piu' con xenon e console che era stata in assistenza....

[url=http://www.ixtreme.net/open-forum/25288-14717-update-what-ive-found-out-so-far-nand-dumps-2.html]14717 Update: What I've found out so far with Nand dumps! - Page 2[/url]

Io mi fido di piu'

Originariamente Scritto da rf1911

Da irc alcuni utenti hanno detto che è stato aggiornato a dual. Io testerò più tardi..

Aspettiamo il test di RF1911,cosi' andiamo sul sicuro

**Tommybig86** · 15-02-12

Originariamente Scritto da MARCHISIO80

Il freeboot si fa sempre,come per Jtag

E le Jtag continuano ad aggiornarsi col FReeboot dal 2009

Ovviamente bisogna stare lontani dal Live,cosa che si fa anche senza pericolo aggiornamento

giussto non avevo pensato alle jtag.. ke poi tra l'altro freeboot si aggiorna sugli efuse vecchi e nn li ribrucia...

un altra curiosità però.... se io avessi una dual nand su fat aggiornando la stock e cambiando cb nn vado a bloccare anke la nand hack? nel senso che la nand hack nn troverà piu gli efuse e il cb nelle stesse posizioni...

**Vola** · 15-02-12

Originariamente Scritto da Tommybig86

un altra curiosità però.... se io avessi una dual nand su fat aggiornando la stock e cambiando cb nn vado a bloccare anke la nand hack? nel senso che la nand hack nn troverà piu gli efuse e il cb nelle stesse posizioni...

Hai centrato il problema, se aggiorni la nand stock e ti brucia un fuse, la nand hack non parte +

**MARCHISIO80** · 15-02-12

Su FAT

Esatto,se la nand originale brucia gli e-fuse finche non esce una modifica o un porting CB_A CB_B su fat non partira' piu' il freeboot in quanto il CB e' revocato
Si ha la stessa situazione delle jasper 6752

Non vuol dire che non saranno mai piu' rghackate,ci sta lavorando il team RGLoader

@ VOLA Sei stato velocissimo

**Chuck Bartowski** · 15-02-12

Domanda: ma chi ha RGH/JTAG ( senza dual nand ) perchè dovrebbe mai voler aggiornare? Cioè, con dash vecchia non dovrebbe partire comunque tutto? Io ho RGH e non capisco perchè aggiornare.

**FirebladeRR** · 15-02-12

Originariamente Scritto da Chuck Bartowski

Domanda: ma chi ha RGH/JTAG ( senza dual nand ) perchè dovrebbe mai voler aggiornare? Cioè, con dash vecchia non dovrebbe partire comunque tutto? Io ho RGH e non capisco perchè aggiornare.

Nessuno ha detto che bisogna aggiornare , chi lo fà e solo per capire che problemi porta tale aggiornamento.

**MARCHISIO80** · 15-02-12

Qui si dice soprattutto di fare attenzione a chi ha fat dual nand e chi ha fat non ancora rgh

Chi ha gia' jtag/rgh fat senza dual nand non deve andare mai in Live,come piu' volte ripetuto da tutti

Naturalmente deve fare attenzione anche chi ha la modifica al lettore
Chi se ne fotte se partono tutti i backup al momento,potrebbe esserci il ban piu' avanti.......

L'aggiornamento e' appena uscito

**phobos_79** · 15-02-12

Non capisco il senso, l'hack è hardware, non software come sul jtag.

"
CB can then run some kind of simple bytecode based software engine whose task will mainly be to initialise DRAM, CB can then load the next bootloader (CD) from NAND into it, and run it. " (per le FAT)

Ok, cambia il layout degli e-fuses e la nand STOCK li controlla, ma in tutta la catena di boot delle nand rgh non dovrebbero essere stati eliminati i controlli sullo stato degli e-fuses?

Ossia, il CB della nand RGH FAT, è identico al CB della nand RGH FAT hack? il boot non segnato parte dal CD? ovvero il CB della nand HACK fa lo stesso i controlli sugli e-fuses?

**Tommybig86** · 15-02-12

quindi in pratica sulle slim nessun problema semplicemente perchè il controllo efuse o comunque la pach di MS eventualmente potrebbe funzionare su CB_B mentre il glich parte gia in precedenza su CB_A non modificabile giusto? ed ecco il lavoro di RGloader nel porting del CB da slim a Fat...

**MARCHISIO80** · 15-02-12

Originariamente Scritto da Tommybig86

quindi in pratica sulle slim nessun problema semplicemente perchè il controllo efuse o comunque la pach di MS eventualmente potrebbe funzionare su CB_B mentre il glich parte gia in precedenza su CB_A non modificabile giusto? ed ecco il lavoro di RGloader nel porting del CB da slim a Fat...

Esattissimo

Originariamente Scritto da phobos_79

Non capisco il senso, l'hack è hardware, non software come sul jtag.

"
CB can then run some kind of simple bytecode based software engine whose task will mainly be to initialise DRAM, CB can then load the next bootloader (CD) from NAND into it, and run it. " (per le FAT)

Ok, cambia il layout degli e-fuses e la nand STOCK li controlla, ma in tutta la catena di boot delle nand rgh non dovrebbero essere stati eliminati i controlli sullo stato degli e-fuses?

Ossia, il CB della nand RGH FAT, è identico al CB della nand RGH FAT hack? il boot non segnato parte dal CD? ovvero il CB della nand HACK fa lo stesso i controlli sugli e-fuses?

Sulle Fat l'hack e' hardware come sulle jatg(altrimenti non dovresti saldare niente,tipo soft MOD sulla WII)ma viene sfruttato via software

L'xbox non parte se il CB e' stato revocato dalla CPU
L'RGH non modifica il CB,cambia solo il risultato di un check sul CD,in parole povere quando il CB verifica il CD(modificato)noi lo glitchamo facendogli credere che il CD e' autorizzato

**Tommybig86** · 15-02-12

Originariamente Scritto da phobos_79

Non capisco il senso, l'hack è hardware, non software come sul jtag.

"
CB can then run some kind of simple bytecode based software engine whose task will mainly be to initialise DRAM, CB can then load the next bootloader (CD) from NAND into it, and run it. " (per le FAT)

Ok, cambia il layout degli e-fuses e la nand STOCK li controlla, ma in tutta la catena di boot delle nand rgh non dovrebbero essere stati eliminati i controlli sullo stato degli e-fuses?

Ossia, il CB della nand RGH FAT, è identico al CB della nand RGH FAT hack? il boot non segnato parte dal CD? ovvero il CB della nand HACK fa lo stesso i controlli sugli e-fuses?

su fat non esiste CB_A e CB_B ma solo CB che può essere modificato come venne fatto in precedenza su jtag... ora si ti confermo che con freeboot devi avere gli stessi efuse ( che ti ricordo si bruciano sulla cpu) quindi la nand nn riconoscerebbe la cpu bruciata da lei e quindi la cpu nn procede al bootloader CD

il glich non e altro che un inganno che il chip hana fa su cpu, facendogli crredere che freeboot è firmato , ma cmq freeboot controlla gli efuse, se il discorso che fai tu fosse vero cioè che freeboot parte direttamente da CD allora, sarebbe ancora possibile il jtag ...

**phobos_79** · 15-02-12

marchisio e tommy molte grazie.

Ho capito pienamente adesso, ignoravo il fatto che il freeboot controllasse lo stesso gli efuses, se cambiano quindi addio boot del freeboot.

Naturalmente credo sia altamente improbabile che riescano a contropatchare il freeboot in modo tale da fargli ignorare lo stato degli e-fuses, lo avrebbero già fatto.

Quindi era una leggenda metropolitana anche il fatto che le SLIM sono immuni ad aggiornamenti dei CB.

**MARCHISIO80** · 15-02-12

Su FAT,Fosse un aggiornamento senza cambio CB(associato a diversa sequenza di boot) nessun problema,basta sistemare LDV fuseset 07 per far partire il Freeboot

L'1BL e' la prima cosa che parte e verifica che il CB sia firmato

Le SLIM(Trinity) sono al momento(forse per sempre)immuni

Su SLIM si glitcha CB_A per far "partire" che CB_B vogliamo,quindi non ci sono problemi

Il CB_A,come spiegato da Rf1911,non verifica gli e-fuse,quindi anche nel caso di un cambio CB,noi possiamo utilizzare il vecchio CB_A e far partire che CB_B vogliamo(questo e' quello che ho capito io)

Sulle FAT si glitcha il CB per far "partire" che CD vogliamo
Con 1 unico CB,il controllo lo fa chiaramente quel CB,e se e' cambiata la sequenza di boot,l'xbox non prosegue il boot oltre il CB............addirittura non arriva neanche al punto di verificare il CD che sta per caricare,rendendo vano il glitch cosi' come lo utilizziamo adesso

**Tommybig86** · 15-02-12

prego, non sono immuni ma il glich su slim parte da un livello piu basso rispetto alle fat, cioè da CB_A ed infatti hanno revisionato l'hardwere delle slim per fermare il glich....

**phobos_79** · 15-02-12

Originariamente Scritto da MARCHISIO80

Il CB_A,come spiegato da Rf1911,non verifica gli e-fuse,quindi anche nel caso di un cambio CB,noi possiamo utilizzare il vecchio CB_A e far partire che CB_B vogliamo,il solito

Ancora più chiaro, e dire che mi ne ho speso tempo sulla sequenza di boot su free60..c'è sempre da imparare

dabol tenchs

**MARCHISIO80** · 15-02-12

AGGIORNATO PRIMO POST

Microsoft cerca di mettere un freno all'RGH su consolle aggiornate
Confermato cambio CB su xbox Fat

Al momento esclude la possibilita' di glitch sulle xbox Fat che aggiorneranno con l'update 14717

guerrierodipace · 15-02-12

incollo da altro forum dei test che hanno fatto:

Just got done soldering, dumping, updating, dumping, starting games, and dumping again. This was on my Xenon console that was unbanned by MS. There's some serious changes going on with the bootloader and CB. Here are before and after dumps in 360 Flash Dump Tool.

2BL [CB] has changed from 7373 to 7377. This value has the final say whether your console can be Jtag'd/RGH'd. The 2BL number depends on the motherboard revision.

4BL [CD] shows up empty.

5BL [CE] has changed from 1888 to 5968. 5BL has been the same on every console and dash version since Adam walked out of the Garden of Eden. It's never changed. 360FDT also shows the Nand as "Retail Unknown Model" instead of "Retail Xenon (v1.0)".

The latest version of 360FDT is from 2010. So I started thinking, "Maybe MS changed the format of the Nand a little so that 360FDT can't fully read it anymore."

For those few of us who have played around with the newest RGLoader (turns your RGH console into a DevKit), a newer tool came with it called RGBuild2. I opened the 14717 dump in it and I was right.

RGBuild2 shows a 2-stage CB along with the following values:
CB_A (2BL) = 7377
CB_B (2BL) = 7377
CD (4BL) = 7377
CE (5BL) = 1888 (Still the same)
6BL and 7BL are still the same. 360FDT now reads a wrong value for 4BL and 5BL.

For illustration, here's a Nand dump from my MS-refurbished Jasper with a 2-stage CB. It has an 3BL [CB] value (2BL[CBv1] = CB_A; 3BL[CBv2] = CB_B).

360FDT should have showed something similar from my Xenon 14717 Nand dump, so MS obviously changed some things around in the bootloader. 2-Stage CB's prevent PHAT consoles from being RGH'd. This could very well be the start of MS cutting down on the number of RGH-able consoles.

I know the above is little over most of your heads and you just want to know if anything has changed as far as backups go. This console was flag-free before I updated. After updating, I started a couple of XGD3 games offline and online and dumped the Nand again. Still no flags.

I don't have the CPU key of this console, so even if did know what to look for as far as new security scheme changes, I couldn't decrypt the KV anyway. As of 3:30 PM MST, none of my other online consoles (3 of them) still haven't asked for the update.

My instinct says there's nothing in this to try to counter LT+ 3.0 but I'm no authority on anything so take it with a grain of salt.