Layenn
23-08-2007, 14:25
Testato con successo il Timing Attack:downgrade da qualsiasi kernel senza CPU KEY!
La notizia era nell'aria e un ringraziamento va al nostro xomebrew che ha seguito con passione la vicenda.
Robinsod di Xboxhacker è riuscito a far partire la sua Xbox 360 con un efuse bruciato con il kernel 1888 usando il timing attack. Non è una cosa che chiunque può fare al momento, ma appena verranno rilasciate nuove informazioni (è un progetto opensource ) e appena ci saranno ulteriori sviluppi, potrebbe essere l'ora degli homebrew e di linux su larga scala nelle Xbox 360. Ovviamente dopo il downgrade a una versione vecchia e vulnerabile del kernel( 4532, 4548), non sarete più in grado di accedere a Xbox live perchè accetta unicamente l'ultimo kernel che al momento è il 5766. Tuttavia non è impossibile immaginare un chippetto con una eeprom e uno switch.
Riporto anche uno stralcio del discorso di Robinsod:
Quote:
L'ho fatto! La mia Xbox Brickata - un efuse bruciato, niente cpu key e nessun dump valido che volesse partire( avevo un 2241 valido ma penso che non partisse per via dell'efuse bruciato) - è ora di nuovo in vita e boota un kernel 2.0.1888 patchato e un hash "indovinato" (ndr. chi è il mago othelma??? )
C'ho perso 3 sere...ora dormo...
Per essere chiaro, il timing attack offre la possibilità di downgrade alla 2.0.1888. Poi è possibile ovviamente l'aggiornamento alla 4532 per far partire l'exploit di king kong e ottenere la CPU KEY.
Dovreste poi essere in grado di sostituire il CB originale dopo l'upgrade( per questa cosa però aspettate una conferma) e poi l'unica traccia di ciò che avete fatto sarà che avete uno o due eFuse bruciati che per la versione di Kernel che state utilizzando normalmente non dovrebbero esserlo.
Infine ecco qualche informazione sulle tecniche utilizzate:
Quote:
I'm using the Infectus chip (with a dll interface provided by them) to rewrite one NAND block with sequential hash guesses. The process takes approx 1 second. The Hynix data sheet quotes a 100,000 read write cycles, our worst case is 4096 or 4%. Since this is a one time operation I think 4% wear is acceptable.
Some PIC processors have CCP modules that allow an internal 16 bit counter to be sampled when a +ve or -ve edge is detected, the counter is claimed to have a 50nS resolution although I'm not convinced Simple software in the PIC allows me to detect the end of CE and the POST port changing from 0x21 => 0xA4 (the end of hashing). The PIC also drives the JTAG reset line. A couple of cheap interface ICs and some passives complete the design - you will definitely be able to build your own hardware from easy to obtain parts, on stripboard, for around 20 Euros.
Controlling all this is some PC software that can generate the required CB section patch, control the infectus and the PIC. It would seem that the "cycle" time should be less than 3 seconds. To test this I am using the 360 I "bricked" at christmas, I don't know the CPU key for this box so I cant "cheat" and test each correctly "guessed" hash byte.
Once I finish testing I will post more info followed by a complete, open source package of hardware and software so you can build your own in a few hours. Now might be a good time to get that infectus chip.
One final point, a lot of the people who want to downgrade will probably have recent versions of the applications (dash, media player etc etc). Some of the latest dashes definitely completely replaced the dash.xex (and possibly others) rather than write new xexp files. These newer versions of the applications definitely require newer system libs and I doubt they will boot on a 2.0.1888 machine. We will need to obtain an image of a clean 2.0.1888 file system.
Altre info arrivano da un altro hacker, Arnezami, che ci spiega l'attacco:
Quote:
The timing attack does not try to "bruteforce" the cpu key itself. It tries to find/bruteforce a hash value which is a result of the usage of the cpu key (so even if you have that hash you still cannot backwards compute the cpu key). But finding this hash value (I usually refer to it as the CB-auth value) will enable the xbox to boot the original kernel (v 1888). This then allows you to upgrade to a vulnerable kernel (eg 4532) and THEN you can extract the cpu key using the kk exploit.
The real NAND flash memory contains several sections. Sections are referred to as CB, CD, CE, CF etc (also SMC and KV). The CB section contains (among many other things) the 16 bytes CB-auth value. But because we want to change the CB-auth value each time we boot we somehow have to make sure that when the CPU reads the 16 bytes in the CB section from the NAND we (sneakly) take over with a nand emulator. This is some electronics that behaves like a NAND but is not. The reason we do is because its easier/faster/better to change bytes in the nand emulator than to change bytes in the nand flash itself (which may also break if you flash it too many times).
So the nand emulator makes sure 1 byte (of the 16 bytes) changes each time the xbox boots. And since we already got the electronics/chip -to emulate the nand- we also use this (programmable) electronics/chip to automatically reset and measure time. This makes an easier design.
From a hardware perspective this means that the programmable electronics/chip has soldering connections to the real nand flash (since it has to be able to "take over"), to the reset "button" to reboot (recently found and tested) and to the connections on the cpu that signify an error or a boot state. That way it can measure between two points in the boot sequence: 1) just before the error is detected 2) just after the error is detected. This means our guessed CB-auth 16 bytes are compared byte-by-byte with the real one (only known by the cpu) and a difference is found at one of the 16 bytes. And if it takes 2,2 micro seconds longer between these points in the boot sequence we know we have found another valid CB-auth byte.
Since -on average- you will find the correct value at roughly half of the possible byte values you only need to try (approx) 128 values for each of the 16 bytes. Thats why vax is talking about 16 * 128 total number if byte changes...
There is a theoretical minimum to the reboot time of about 1 second. So in theory you could find the 16 bytes in 34 minutes. Thats probably not gonna happen. Grin And installing the hardware will probably take even more time so its not a really big issue. But this is basically where the time speculations are based on.
Beh, questa volta pare che ci siamo... chiaramente c'è spazio per i soliti discorsi sull'utilità o meno di far partire linux o codice homebrew(che comunque va sviluppato...), ma è quantomeno apprezzabile il lavoro realizzato da questi ragazzi.
fonte xbox tribe
La notizia era nell'aria e un ringraziamento va al nostro xomebrew che ha seguito con passione la vicenda.
Robinsod di Xboxhacker è riuscito a far partire la sua Xbox 360 con un efuse bruciato con il kernel 1888 usando il timing attack. Non è una cosa che chiunque può fare al momento, ma appena verranno rilasciate nuove informazioni (è un progetto opensource ) e appena ci saranno ulteriori sviluppi, potrebbe essere l'ora degli homebrew e di linux su larga scala nelle Xbox 360. Ovviamente dopo il downgrade a una versione vecchia e vulnerabile del kernel( 4532, 4548), non sarete più in grado di accedere a Xbox live perchè accetta unicamente l'ultimo kernel che al momento è il 5766. Tuttavia non è impossibile immaginare un chippetto con una eeprom e uno switch.
Riporto anche uno stralcio del discorso di Robinsod:
Quote:
L'ho fatto! La mia Xbox Brickata - un efuse bruciato, niente cpu key e nessun dump valido che volesse partire( avevo un 2241 valido ma penso che non partisse per via dell'efuse bruciato) - è ora di nuovo in vita e boota un kernel 2.0.1888 patchato e un hash "indovinato" (ndr. chi è il mago othelma??? )
C'ho perso 3 sere...ora dormo...
Per essere chiaro, il timing attack offre la possibilità di downgrade alla 2.0.1888. Poi è possibile ovviamente l'aggiornamento alla 4532 per far partire l'exploit di king kong e ottenere la CPU KEY.
Dovreste poi essere in grado di sostituire il CB originale dopo l'upgrade( per questa cosa però aspettate una conferma) e poi l'unica traccia di ciò che avete fatto sarà che avete uno o due eFuse bruciati che per la versione di Kernel che state utilizzando normalmente non dovrebbero esserlo.
Infine ecco qualche informazione sulle tecniche utilizzate:
Quote:
I'm using the Infectus chip (with a dll interface provided by them) to rewrite one NAND block with sequential hash guesses. The process takes approx 1 second. The Hynix data sheet quotes a 100,000 read write cycles, our worst case is 4096 or 4%. Since this is a one time operation I think 4% wear is acceptable.
Some PIC processors have CCP modules that allow an internal 16 bit counter to be sampled when a +ve or -ve edge is detected, the counter is claimed to have a 50nS resolution although I'm not convinced Simple software in the PIC allows me to detect the end of CE and the POST port changing from 0x21 => 0xA4 (the end of hashing). The PIC also drives the JTAG reset line. A couple of cheap interface ICs and some passives complete the design - you will definitely be able to build your own hardware from easy to obtain parts, on stripboard, for around 20 Euros.
Controlling all this is some PC software that can generate the required CB section patch, control the infectus and the PIC. It would seem that the "cycle" time should be less than 3 seconds. To test this I am using the 360 I "bricked" at christmas, I don't know the CPU key for this box so I cant "cheat" and test each correctly "guessed" hash byte.
Once I finish testing I will post more info followed by a complete, open source package of hardware and software so you can build your own in a few hours. Now might be a good time to get that infectus chip.
One final point, a lot of the people who want to downgrade will probably have recent versions of the applications (dash, media player etc etc). Some of the latest dashes definitely completely replaced the dash.xex (and possibly others) rather than write new xexp files. These newer versions of the applications definitely require newer system libs and I doubt they will boot on a 2.0.1888 machine. We will need to obtain an image of a clean 2.0.1888 file system.
Altre info arrivano da un altro hacker, Arnezami, che ci spiega l'attacco:
Quote:
The timing attack does not try to "bruteforce" the cpu key itself. It tries to find/bruteforce a hash value which is a result of the usage of the cpu key (so even if you have that hash you still cannot backwards compute the cpu key). But finding this hash value (I usually refer to it as the CB-auth value) will enable the xbox to boot the original kernel (v 1888). This then allows you to upgrade to a vulnerable kernel (eg 4532) and THEN you can extract the cpu key using the kk exploit.
The real NAND flash memory contains several sections. Sections are referred to as CB, CD, CE, CF etc (also SMC and KV). The CB section contains (among many other things) the 16 bytes CB-auth value. But because we want to change the CB-auth value each time we boot we somehow have to make sure that when the CPU reads the 16 bytes in the CB section from the NAND we (sneakly) take over with a nand emulator. This is some electronics that behaves like a NAND but is not. The reason we do is because its easier/faster/better to change bytes in the nand emulator than to change bytes in the nand flash itself (which may also break if you flash it too many times).
So the nand emulator makes sure 1 byte (of the 16 bytes) changes each time the xbox boots. And since we already got the electronics/chip -to emulate the nand- we also use this (programmable) electronics/chip to automatically reset and measure time. This makes an easier design.
From a hardware perspective this means that the programmable electronics/chip has soldering connections to the real nand flash (since it has to be able to "take over"), to the reset "button" to reboot (recently found and tested) and to the connections on the cpu that signify an error or a boot state. That way it can measure between two points in the boot sequence: 1) just before the error is detected 2) just after the error is detected. This means our guessed CB-auth 16 bytes are compared byte-by-byte with the real one (only known by the cpu) and a difference is found at one of the 16 bytes. And if it takes 2,2 micro seconds longer between these points in the boot sequence we know we have found another valid CB-auth byte.
Since -on average- you will find the correct value at roughly half of the possible byte values you only need to try (approx) 128 values for each of the 16 bytes. Thats why vax is talking about 16 * 128 total number if byte changes...
There is a theoretical minimum to the reboot time of about 1 second. So in theory you could find the 16 bytes in 34 minutes. Thats probably not gonna happen. Grin And installing the hardware will probably take even more time so its not a really big issue. But this is basically where the time speculations are based on.
Beh, questa volta pare che ci siamo... chiaramente c'è spazio per i soliti discorsi sull'utilità o meno di far partire linux o codice homebrew(che comunque va sviluppato...), ma è quantomeno apprezzabile il lavoro realizzato da questi ragazzi.
fonte xbox tribe