How M$ Killed The XOR Hack

[xboxaro]

se fosse così il castello di sabbia si sgretola! Fine produzione Chip RGH1/2... e relativa vendita.... quindi ci si concentrerebbe sulle Corona che sono il presente....che dite?

hai ragione ma pensoche i vari hackers devono pensare cia alle corona che alle vecchie motherboard...sennò che senso avrebbe???cioè tutti quelli che hanno phat(jasper,eccc)e trinity che sfortunatamente hanno aggiornato sono fot..ti???io penso che gli hackers se trovano una soluzione per una motherboard la trovano anche per le altre(tranne xenon)

[Vola]

Be la gente ha avuto quasi un anno x per questo rgh.... Quindi ad una certa se hai la smania di update sono fatti tuoi

Inviato dal mio nokia 3310 tramite codice morse

[kazoom]

hai ragione ma pensoche i vari hackers devono pensare cia alle corona che alle vecchie motherboard...sennò che senso avrebbe???cioè tutti quelli che hanno phat(jasper,eccc)e trinity che sfortunatamente hanno aggiornato sono fot..ti???io penso che gli hackers se trovano una soluzione per una motherboard la trovano anche per le altre(tranne xenon)

se la si prende come una sfida allora concordo con te, ma ci sono molti fattori che entrano in gioco, non ultimo quello prettamente commerciale ed investire tempo e risorse su HW inaffidabile e obsoleto come molte Phat mi lascia perplesso.
Diverso è il discorso Slim, ma non conoscendo il linguaggio C, non so quanto questo cambiamento nei CB_A abbia definitivamente chiuso il discorso RGH.
Anni fa prima dell'avvento delle JTAG e RGH si pensava che le 360 fossero inespugnabili... è anche vero poi in seguito molti bug sono stati corretti/scoperti da entrambe le parti, ma a questo punto siamo all'epilogo? M$ ha proprio ucciso l'hack?

[xboxaro]

se la si prende come una sfida allora concordo con te, ma ci sono molti fattori che entrano in gioco, non ultimo quello prettamente commerciale ed investire tempo e risorse su HW inaffidabile e obsoleto come molte Phat mi lascia perplesso.
Diverso è il discorso Slim, ma non conoscendo il linguaggio C, non so quanto questo cambiamento nei CB_A abbia definitivamente chiuso il discorso RGH.
Anni fa prima dell'avvento delle JTAG e RGH si pensava che le 360 fossero inespugnabili... è anche vero poi in seguito molti bug sono stati corretti/scoperti da entrambe le parti, ma a questo punto siamo all'epilogo? M$ ha proprio ucciso l'hack?

straquotone sia per te e sia per vola....penso che gli hackers si concentreranno per far uscire la RGH per corona se uscirà dato che prima della 157XX ankora non lavevano fatto uscire e pensa ora con questo aggiornamento...ci vorrà ancora mooolto tempo dato che per le 250gb l'hanno trovato la soluzione per quelle 4gb ancora in progress....fortunati saranno quelli che non avranno aggiornato alla 157xx parlo di corona e se avranno aggiornato allora sono fottuti ...

[kazoom]

però, però.... c'è di mezzo un update 15572 che è passato veloce come il vento..... è credo che come ipotizzava Marchisio80 in un 3D qualche giorno fa.... li c'è il bandolo della matassa... sarà ma qualcosa mi dice che l'RGH non è morta..

[xboxaro]

però, però.... c'è di mezzo un update 15572 che è passato veloce come il vento..... è credo che come ipotizzava Marchisio80 in un 3D qualche giorno fa.... li c'è il bandolo della matassa... sarà ma qualcosa mi dice che l'RGH non è morta..

dici che si puo trovare il modo per far RGH con quella dashboard??? si però penso che al99% delle persone hanno aggiornato all15574 invece della 15572...non sò se sono uguali

[kazoom]

dici che si puo trovare il modo per far RGH con quella dashboard??? si però penso che al99% delle persone hanno aggiornato all15574 invece della 15572...non sò se sono uguali

non mi pare che in Italia ci sia stato l'up a 15572, credo che in quell'aggiornamento il CB_A e CB_B abbiano una falla....

[freelancer]

ma in sostanza si tratta di capire qual è il secondo algoritmo usato e relativa keystream (quel "C" che diceva Marchisio80) oppure risulterebbe cmq tutto inutile?

Considerando poi il fatto che Trinity è un HW non più in produzione, la scena HAck si muoverà meno celermente? In pratica è un problema che verrà deliberatamente lasciato alla deriva e ripreso magari in altri momenti ?

L'algoritmo si conosce completamente, non è quello il punto.

RC4 funziona così

(1) C = KS XOR P
(2) KS = ALG(KEY)

C = messaggio cifrato
P = messaggio in chiaro
KS = keystream

Dalla (1) si ricava KS = C XOR P, questo è quello che viene impropriamente chiamato xor hack, cioè viene ricavato il KS mediante lo xor dei dati criptati e di quelli in chiaro senza bisogno di conoscere la KEY. Notare che KEY, KS e C sono informazioni che variano da console a console. P invece è fisso così come lo è l'algoritmo ALG.

Ricavare la KEY a partire dal KS (mediante le debolezze di RC4 tipo quelle sfruttate nel wep) è possibile solo se conosciamo più keystream generati usando la stessa key e l'algoritmo ALG. In questo caso abbiamo solo un keystream. Quindi ammesso e non concesso che si possano ipotizzare attacchi di quel tipo mancherebbe comunque la materia prima, i dati grezzi su cui lavorare.

Ora veniamo alla 360 con CB 9188. CB_B è criptato con RC4, CB_A non è critptato ed opera come segue:

(1) autentica di CB_B
(2) calcola KS=ALG(cpukey) decripta CB_B e lo carica.

Il glitch opera su CB_A neutralizzando (1) e permettendoci di modifcare CB_B. Notate che CB_A non si può patchare perchè viene autenticato dal precedente bootloader. Dopo aver modificato CB_B si deve poterlo criptare in modo che (2) continui a funzionare. Questo richiede la conoscenza di cpukey o di KS. Se non abbiamo la cpukey (e non l'abbiamo) dobbiamo ricavare KS con lo xor hack.

Se però microsoft cambia algoritmo nella nuova coppia CB_A/CB_B il passo (2) diventa KS=ALG2(cpukey), quindi lo xor hack ci restituisce un keystream che non è compatibile con il precedente CB_A il quale usa ancora KS=ALG(cpukey). Ci troviamo nell'impossibilità di cifrare il vecchio CB_B in modo che sia installabile su questa console a meno che non abbiamo a disposizione

a) la cpukey (che possiamo utilizzare per calcolare KS=ALG(cpukey) vecchio keystream).
b) un vecchio dump (che possiamo utilizzare per ricavare KS = C XOR P vecchio keystream).

[Vola]

da quello che so tra il 15572 e il 15574 non c'è differenza a livello cb, e cmq sarebbe poco utile.. se hai la dash aggiornata non puoi tornare indietro.

[xboxaro]

ora in pratica ora dovremo aspettare che qualche hacker intelligentissimo(XD)rilasci il metodo per fare la RGH almeno su corona per tutti e due i tipi e prima delle corona su trinty....per le phat la vedo dura ma penso che gli hacker potrebbero provarci...anche non è cosi facile

[andreagtr]

forse perchè staranno lavorando su un progetto più ampio con la riprogettazionee della xbox720 e su questo non ci perdono troppo tempo? mah?

O forse perche' anche se viene "bucata" la keystream per attuare il glitch devi prima procurarti una Xbox
Non credo che M$ conti molto sulla percentuale dei games venduti, bensi' faccia fatturato sull'HW che vende! Come i SO, sono sempre stati creackabili e credo che sempre lo saranno...

EDIT Ma scusate, mi son perso un pezzo, io avevo capito che i vecchi CB venivano "bloccati" solo quando veniva chiuso un fuseset, difatti se sempre il caldo non mi sta' uccidendo (sto' anche reballando 2 ps3 :/) su slim anche con CB 9230, una volta creato il freeboot viene utilizzato il 9188! Dove sbaglio???

[Vola]

Se però microsoft cambia algoritmo nella nuova coppia CB_A/CB_B il passo (2) diventa KS=ALG2(cpukey), quindi lo xor hack ci restituisce un keystream che non è compatibile con il precedente CB_A il quale usa ancora KS=ALG(cpukey). Ci troviamo nell'impossibilità di cifrare il vecchio CB_B in modo che sia installabile su questa console a meno che non abbiamo a disposizione

Non hanno cambiato l'algoritmo per il calcolo della keystream, è sempre KS=ALG(key), ma la key non è solo la cpukey ma un hmac della key CB_A con il random CB_B (byte da 0x10 a 0x20) + cpukey + header CB_A (quest'ultimo aggiunto con l'ultimo update).

il vecchio e il nuovo cba generano quindi una key e di conseguenza KS differente (come detto da freelancer) partendo dagli stessi dati, quindi la console non riesce + a decrittare il CB_B.
In pratica si riuscirebbe sempre a utilizzare questo "xor hack" per modificare il CB_B ma non possiamo + inserire un CB_A glitchabile.

[Luke69]

O forse perche' anche se viene "bucata" la keystream per attuare il glitch devi prima procurarti una Xbox
Non credo che M$ conti molto sulla percentuale dei games venduti, bensi' faccia fatturato sull'HW che vende! Come i SO, sono sempre stati creackabili e credo che sempre lo saranno...

EDIT Ma scusate, mi son perso un pezzo, io avevo capito che i vecchi CB venivano "bloccati" solo quando veniva chiuso un fuseset, difatti se sempre il caldo non mi sta' uccidendo (sto' anche reballando 2 ps3 :/) su slim anche con CB 9230, una volta creato il freeboot viene utilizzato il 9188! Dove sbaglio???

Il CB9188 non fa un check sulla fuse line 02, è per questo che è sempre stato possibile il "downgrade" a questo CB su slim...

[kazoom]

L'algoritmo si conosce completamente, non è quello il punto.

RC4 funziona così

(1) C = KS XOR P
(2) KS = ALG(KEY)

C = messaggio cifrato
P = messaggio in chiaro
KS = keystream

Dalla (1) si ricava KS = C XOR P, questo è quello che viene impropriamente chiamato xor hack, cioè viene ricavato il KS mediante lo xor dei dati criptati e di quelli in chiaro senza bisogno di conoscere la KEY. Notare che KEY, KS e C sono informazioni che variano da console a console. P invece è fisso così come lo è l'algoritmo ALG.

Ricavare la KEY a partire dal KS (mediante le debolezze di RC4 tipo quelle sfruttate nel wep) è possibile solo se conosciamo più keystream generati usando la stessa key e l'algoritmo ALG. In questo caso abbiamo solo un keystream. Quindi ammesso e non concesso che si possano ipotizzare attacchi di quel tipo mancherebbe comunque la materia prima, i dati grezzi su cui lavorare.

Ora veniamo alla 360 con CB 9188. CB_B è criptato con RC4, CB_A non è critptato ed opera come segue:

(1) autentica di CB_B
(2) calcola KS=ALG(cpukey) decripta CB_B e lo carica.

Il glitch opera su CB_A neutralizzando (1) e permettendoci di modifcare CB_B. Notate che CB_A non si può patchare perchè viene autenticato dal precedente bootloader. Dopo aver modificato CB_B si deve poterlo criptare in modo che (2) continui a funzionare. Questo richiede la conoscenza di cpukey o di KS. Se non abbiamo la cpukey (e non l'abbiamo) dobbiamo ricavare KS con lo xor hack.

Se però microsoft cambia algoritmo nella nuova coppia CB_A/CB_B il passo (2) diventa KS=ALG2(cpukey), quindi lo xor hack ci restituisce un keystream che non è compatibile con il precedente CB_A il quale usa ancora KS=ALG(cpukey). Ci troviamo nell'impossibilità di cifrare il vecchio CB_B in modo che sia installabile su questa console a meno che non abbiamo a disposizione

a) la cpukey (che possiamo utilizzare per calcolare KS=ALG(cpukey) vecchio keystream).
b) un vecchio dump (che possiamo utilizzare per ricavare KS = C XOR P vecchio keystream).

di fatto dici che pur conoscendo il nuovo algoritmo che mi validerebbe il nuovo CB_B si dovrebbe riscrivere un nuovo CB_B_9231 modificato perchè il glitch prosegua con le stesse modalità su Trinity e questo non lo si può fare perchè non ne esiste uno decriptato?


editavo mentre vola ha scritto.

[kazoom]

Non hanno cambiato l'algoritmo per il calcolo della keystream, è sempre KS=ALG(key), ma la key non è solo la cpukey ma un hmac della key CB_A con il random CB_B (byte da 0x10 a 0x20) + cpukey + header CB_A (quest'ultimo aggiunto con l'ultimo update).

il vecchio e il nuovo cba generano quindi una key e di conseguenza KS differente (come detto da freelancer) partendo dagli stessi dati, quindi la console non riesce + a decrittare il CB_B.
In pratica si riuscirebbe sempre a utilizzare questo "xor hack" per modificare il CB_B ma non possiamo + inserire un CB_A glitchabile.

[url=http://msdn.microsoft.com/it-it/library/system.security.cryptography.hmac(v=vs.80).aspx]Classe HMAC (System.Security.Cryptography)[/url]


per questo motivo dici che il CB_A se riscritto fornirebbe un hash differente quindi CB_B non verrebbe autenticato?

"Qualsiasi modifica ai dati o al valore hash causa un'errata corrispondenza, perché è necessario conoscere la chiave segreta per modificare il messaggio e riprodurre il valore hash corretto. Pertanto, se i valori hash originale e calcolato corrispondono, il messaggio viene autenticato."

[xboxaro]

secondo me a sto punto o gli hacker riescono a trovare un modo per rifare RGH3.0 su almeno console che si potevano fare oppure si ritorna come al jtag...cioè chi c'è l'ha è fortunato chi non c'è l'ha è fottuto

[Vola]

no ferma non hai capito.

per il vecchio cba key = hmac(keyCBA, (randomCBB + cpukey))
per il nuovo cba key = hmac(keyCBA, (randomCBB + cpukey + headerCBA))

dove
keyCBA è la key calcolata per decrittare il CBA
randomCBB = byte del cbb da 0x10 a 0x20
headerCBA = sono i primi byte del CBA dove sono scritta la versione posizione di inizio e dimesione codice.

Se noi mettiamo il vecchio cba questo calcola una key differente quindi un differente keystream quindi non riesce a decodificare il CBB -> fine dei giochi.
La keystream del CBB non possiamo cambiare in quanto non conosciamo la cpukey, possiamo solo cambiare il contenuto in chiaro tramite il xor hack.

[freelancer]

Kazoom, il problema non il decriptaggio, ma il criptaggio. Per far funzionare l'hack devi criptare il CB_B dopo averlo modificato perchè il CB_A se lo aspetta criptato. Per criptarlo occorre KS = ALG(KEY) calcolato come previsto in CB_A. La KEY non l'abbiamo. Il KS lo possiamo trovare solo come C XOR P. Ma se C proviene da un dump 15xxx, KS non corrisponderà ad ALG(KEY) perchè come detto a partire da questa dash vengono eseguite delle operazioni sulla key che di fatto alterano completamente il KS generato.

[kazoom]

Kazoom, il problema non il decriptaggio, ma il criptaggio. Per far funzionare l'hack devi criptare il CB_B dopo averlo modificato perchè il CB_A se lo aspetta criptato. Per criptarlo occorre KS = ALG(KEY) calcolato come previsto in CB_A. La KEY non l'abbiamo. Il KS lo possiamo trovare solo come C XOR P. Ma se C proviene da un dump 15xxx, KS non corrisponderà ad ALG(KEY) perchè come detto a partire da questa dash vengono eseguite delle operazioni sulla key che di fatto alterano completamente il KS generato.

bene sto mettendo ordine, tra i neuroni... poi mi rileggo tutto con calma... intanto un grazie a tutti per aver reso molto interessante il Topic .. veramente chapeau !!!

[Armand]

straquoto aggiungo anche che dovrebbero trovare di nuovo il modo di far glitchare le phat e le slim aggiornate al ultima dash vergini però...ci sono anche le corona in mezzo....il problema è se i vari hackers ci riusciranno...altro che RGH2.0 qui si parlerà di RGH3.0 e penso che sarà piu istabile di prima...insomma praticamente si dovrà aspettare tanto tanto tanto prima di avere un RGH stabile come quello classico

mi spieghi il perchè di questa tua affermazione?