[CB ANTI RGH]NUOVO aggiornamento XBOX LIVE Kernel 2.0.14717

[The Pusher]

grazie rf sempre gentile.

spero che piu' avanti porti/ate buone novelle voi del team rgloader..... cmq chiusa una porta si apre un portone.

vorrei chiedere un'altra cosa.
dato che questo aggiornamento dash apporta svariate modifiche al kernel,non si puo' decriptare l'aggiornamento dash per vedere come questo interagisce con la console??
cerco di essere piu' preciso.
non si puo' vedere,avendo le varie key della console,come e cosa va a modificare l'aggiornamento per poter creare una dash homemade che magari possa fissare e ripristinare i vari cb o la bootchain??

E come la fai partire la dash homemade?

[diffusore]

sapendo le varie key della console non si puo' mettere in chiaro la dash update per poterla modificare...tipo quando si cura un eseguibile.....

la dash originale per aggiornare la console chiede ed ottiene dei privileggi dalla console ,quindi suppongo che questa chieda alla console dei dati di sicurezza per eseguire l'aggiornamento.
avendo le varie key della console non si puo' vedere dove e cosa vuole per autorizzare il software.

[altix]

[url]http://www.consoleopen.com/forum/news-xbox-360-e-xbox-360-slim/3551-cb-anti-rgh-nuovo-aggiornamento-xbox-live-kernel-2-0-14717-a-4.html#post33176[/url]

grazie mille

[The Pusher]

sapendo le varie key della console non si puo' mettere in chiaro la dash update per poterla modificare...tipo quando si cura un eseguibile.....

la dash originale per aggiornare la console chiede ed ottiene dei privileggi dalla console ,quindi suppongo che questa chieda alla console dei dati di sicurezza per eseguire l'aggiornamento.
avendo le varie key della console non si puo' vedere dove e cosa vuole per autorizzare il software.

Non è cosi' semplice , credimi , ma nn escludo si possa arrivare in futuro a flashare il lettore tramite dash , ovvio con lo SPI aperto a 0x00 via hardware

[rf1911]

@Diffusore: devi avere chiaro il chain of trust della xbox prima.. avere la cpukey non ti porta da nessuna parte. L'unica cosa interessante (direi vitale) che puòi fare con la cpukey è decryptare i bootloader e le patch del kernel per poi poterli analizzare con IDA. Ma non puoi modificare un eseguibile.

In sostanza:

1BL - Carica, decriptda con 1BL e controlla firma del CB_A
CBA- Carica , decripta con CPUKEY e controlla l'hash del CB_B
CBB - Carica, decrypda con CPUKEY e controlla l'hash del CD
CD - Carica,etc,etc.. CE e ci applica le patch kernel


ora però vo a nanna..

[pocoyo2]

Ciao raga! Purtroppo ho fatto l'aggiornamento oggi su una slim RGH Dual Nand. Non lo sapevo ancora di questo aggiornamento! Adesso infatti l'RGH non parte, mi sono dannato un pomeriggio! Però non parte neanche in originale perchè purtroppo non sapendo di questo aggiornamento per erroro ho riscritto la Nand originale e non quella con Freeboot, quindi non so cosa sia cambiato! Adesso mi ritrovo con la nand originale prima di aver effettuato l'RGH però se vado a rimetterla su la consolle non si avvia neanche in originale! tra l'altro la nand originale estratta a suo tempo si presenta così Allegato 2631
C'è un modo per risolvere o almeno per farla tornare a funzionare originale????

Se avessi fatto un dump della nand, post 14717, ti bastava rimetterla su. Ora, se lo fai con pre14717, hai ldv diverso, fuse07 diverso e cb_a/cb_b diversi. No boot! Attendi sviluppi

Inviato dal mio Desire HD

[rf1911]

Per ora no. Per l'originlare devi attendere una nuova versione di xebuild, ma probabilmente addio live. Per FB devi attendere il nuovo FB o TX che ha fatto una patch.

[freelancer]

Il concetto di base a mio avviso è uno... a livello tecnico non penso ke il glitch si possa bloccare (a meno di una revisione HW)... uso l 'ipotesi perchè mi baso sulle info di cui sono a conoscenza... ergo stanno intervenendo a manetta per rallentare il proliferare della mod... è comprensibile e prevedibile... nulla di strano, anzi sarebbe strano il contrario... è sempre il solito principio del bastone e della carota...

Il glitch è stato bloccato. Qui non si tratta di intervenire a casaccio anzi sono state modifiche molto ben congeniate.

Inserendo un delay a random nel codice del bootloader, proprio sulle chiamate che eseguono le comparazioni dell'hash code, rendi impossibile glitchare la console perchè non puoi temporizzare l'impulso correttamente. Ma non si sono fermati qui sono intervenuti anche sugli altri strumenti utilizzati per l'hacking della console come i postcode.

Non si tratta di panico, altrimenti questo aggiornamento sarebbe uscito a settembre. Hanno fatto esattamente quello che dovevano fare e che tutti si aspettavano.

Ora RGH può solo essere ripristinato tramite downgrade del CB sulle trinity ed eventuali porting futuri di quel CB (che non contiene efuse check) sulle altre revisioni, la fattibilità di quest'ultima parte è solo teorica. Di fatto è stato fixato ed in modo definitivo con sole modifiche al software di sistema.

[Titty]

Io nn sono in panico... anzi onestamente non è ke mi cambi molto sapere se il glitch è morto o meno...ci sono gli ODE (ke al momento per come la vedo io sono usciti vincitori quando erano dati per spacciati)... anche le mod Fw (per ki nn ha 1175)... alla fine una soluzione ci sta. Io son sempre stato dell' idea che non si può aver tutto dalla vita. Fortunato ki ha già fatto il glitch... sfigato ki ha esistato e adesso ha una FAT temporaneamente (o permanentemente) kiusa...

Le dual NAND... le ho sempre ritenute superflue (e i miei soci lo possono confermare).... volete il live? Usate una seconda console... oggi come nn mai M$ ha nuovamente dismostrato ke fa ciò ke vuole con la sua console, Xbox1 non ha insegnato abbastanza...

Per le slim trinity basta aspettare... alla fine è tanto rumore per nulla...

[rf1911]

Per quello che ho visto disassemblando con IDA, e per le considerazioni fatte con altri membri dell'RGLOADER a casaccio non è il termine giusto.... hanno fatto di tutto e di più, stile "dove cojo cojo"... in sostanza hanno visto le vulnerabilità e le hanno in qualche modo rimosse... offuscati i POST, implementato Fusecheck, inserito delay e nops a più non posso nella memcompare, cambiato il check del ritorno da una comparazione a 0 a una a -1 (già questo da solo sarebbe bastato)...

Allego immagine di IDA..



Mi sbilancio? Sì.. secondo me non serve a molto, ci sono ancora diverse porte aperte..

[freelancer]

L'unica porta aperta è l'utilizzo di un vecchio CB. Casomai l'errore è nell'assenza del check per impedire il downgrade. Ma questa è storia vecchia.

Poi scusa se tu hai delle vulnerabilità conclamate e discusse ovunque perchè non dovresti fixarle? Probabilmente bastava mettere il delay ed il glitch sarebbe stato impossibile, ma in ogni caso non costava nulla intervenire anche sul resto, in questo modo si rende difficile anche l'ulteriore studio della macchina. E' ciò che io avrei fatto. Individuato qualcosa di potenzialmente pericoloso lo avrei corretto, indipendentemente dal fatto che sia strettamente necessario.

[rf1911]

Mi spiace smentirti, non è l'unica porta aperta. Credimi. Per lo studio della macchina mi pare di aver già dimostrato che non lo si è reso assolutamente difficile.. più chiaro di così..

[freelancer]

Mi spiace smentirti, non è l'unica porta aperta. Credimi. Per lo studio della macchina mi pare di aver già dimostrato che non lo si è reso assolutamente difficile.. più chiaro di così..

Beh staremo a vedere qual'è sarà la piega che prenderanno gli eventi futuri. Io scommetto che il prossimo RGH si baserà su un vecchio CB portato.

Hanno reso difficile lo studio della macchina, non del codice. Già togliere i POSTCODE, lo avessero fatto un paio di anni fa tu non avresti avuto RGH, anche dopo esserti disassemblato il codice e studiato riga per riga.

[rf1911]

Se mia nonna aveva le ruote era una cariola... il porting del cb è *un* modo.

[freelancer]

Se mia nonna aveva le ruote era una cariola... il porting del cb è *un* modo.

Che vuoi dire? Io cercavo di evidenziare la differenza tra studio del codice e studio della macchina. Meno informazioni puoi ricavare dalla macchina reale su cui il codice gira più l'hacking è difficile. E poi ricordati che come ingegnere software è TUO PRECISO DOVERE correggere ogni potenziale vulnerabilità di cui sei a conoscenza. E queste falle potenziali erano conclamate.

Il porting del CB per me è IL modo. Anzi credo che ci siano indizi abbastanza forti che qualcosa si stia già muovendo in tale direzione. Se ci fossero altre vulnerabilità sarebbe preferibile sfruttarle invece di proseguire per quella strada, quindi se tu ne sei a conoscenza potresti sempre darti da fare e rilasciare qualcosa.

[rf1911]

"Se mia nonna aveva le ruote era una cariola..." era riferito al fatto che non puoi solo riportarlo al fatto della rimozione dei post. Devi tornare al KK hack con i se e con i ma.. tutto è nato da lì... Per il resto chi vivrà vedrà..

[FirebladeRR]

oggi come nn mai M$ ha nuovamente dimostrato ke fa ciò ke vuole con la sua console, Xbox1 non ha insegnato abbastanza...

Come tutte le cose ,quando il giro diventa troppo grande , gli si dà una stretta , vedasi $ky et simile.....Se vogliono fanno quello che gli pare, tutto sta nella convenienza che hanno nel farlo.

[rf1911]

Il problema per loro è che l'ha fatto tardi.. e in questo caso "meglio tardi che mai" non vale...

[FirebladeRR]

Il problema per loro è che l'ha fatto tardi.. e in questo caso "meglio tardi che mai" non vale...

Condivido... probabilmente si sono trovati spiazzati dalla velocità con cui la modifica in se ha preso campo e hanno pensato meglio metterci na pezza.
Poi le strade del signore sono infinite .....

[P@olo]

Per come la penso io, chi voleva una xbox360 "aperta" ha avuto due treni (il primo quello del Jtag vero e il secondo quello del RGH) quindi se li ha persi entrambi è perchè ha voluto perderli e si accontenta di quello che resta, poi la storia insegna di "bug" ci sono sempre basta solo portarli alla luce e usarli