Timing Attack / Degraded / Flash De Nand


zouzzz
 Share

Messages recommandés

Salut,

voilà ce qui a été posté sur xboxscène ce matin même :

Robinsod managed to successfully boot his Xbox360 with one flashed eFuse with kernel 1888 using the timing attack we talked about some weeks ago. It's not something everyone out there can do yet, but as more information gets released (it's an open source project :)) and things get optimized and developed further it might open homebrew and linux for the Xbox360 on a much larger scale soon. Of course once your 360 is back to an (older) vulnerable kernel (4532,4548), you won't be able to go on LIVE anymore (it only accepts the latest kernel (5766 atm)) ... but a dual kernel system is a possibility (using a xD memory card even).

From Robinsod on XBH:

Done it! My bricked box - one blown eFuse but no CPU key and no valid flash dump that would boot (I did have a valid 2241 dump though that would no longer boot because of the eFuse) - is now alive and well and booting 2.0.1888 with a patched CB (LD count = 1) and a "guessed" hash. Even doing it "manually" only took 3 evenings ;) Now, sleep

Just to be clear, the timing attack will allow you to downgrade to 2.0.1888. You can then upgrade to 4532 & run the KK sploit and obtain your CPU keys. You should be able to replace the original CB after the upgrade (this needs to be confirmed) and then the only "clue" to what happened is that you may have 1 or 2 more burned eFuses for the HV/Kernel version you are running

Here's a bit more info about his "proof of concept" downgrader hardware:

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.

More useful information by Arnezami explaining the attack:

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.

Ca avance dur!

Modifié par zouzzz
Lien vers le commentaire
Partager sur d'autres sites

  • Réponses 152
  • Created
  • Dernière réponse

Top Posters In This Topic

Robinsod managed to successfully boot his Xbox360 with one flashed eFuse with kernel 1888 using the timing attack we talked about some weeks ago. It's not something everyone out there can do yet, but as more information gets released (it's an open source project smile.gif) and things get optimized and developed further it might open homebrew and linux for the Xbox360 on a much larger scale soon. Of course once your 360 is back to an (older) vulnerable kernel (4532,4548), you won't be able to go on LIVE anymore (it only accepts the latest kernel (5766 atm)) ... but a dual kernel system is a possibility (using a xD memory card even).

--> en gros ils ont bossés sur les cycles de boot de la console et on reussi à lancer du code au mmemnt ou la console boote juste entre deux cycles d'horloge.Ca ne marche que sur les kernels inferieurs au 4532,4548, tu pourras plus aller sur le live mais un dual boot depuis une carte XD est possible

Attention pour la carte XD le lecteur est à monter sois meme et vu les diagrames c'est très très chaud (mais bon je suis informaticien et pas electricien ;)

Done it! My bricked box - one blown eFuse but no CPU key and no valid flash dump that would boot (I did have a valid 2241 dump though that would no longer boot because of the eFuse) - is now alive and well and booting 2.0.1888 with a patched CB (LD count = 1) and a "guessed" hash. Even doing it "manually" only took 3 evenings wink.gif Now, sleep

Just to be clear, the timing attack will allow you to downgrade to 2.0.1888. You can then upgrade to 4532 & run the KK sploit and obtain your CPU keys. You should be able to replace the original CB after the upgrade (this needs to be confirmed) and then the only "clue" to what happened is that you may have 1 or 2 more burned eFuses for the HV/Kernel version you are running

---> l'attaque au boot permet de downgrader vers 2.0.1888, tu recupère ta clef et tu upgrade en 4532 par contre tu grille 1 ou 2 efuse

A mon avis si tu vire la R6T3 ca devrait etre plus cool au niveau efuse.

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

More useful information by Arnezami explaining the attack:

CITATION

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.

--> en gros:

ils decrivent le contenu de la NAD et explique qu'avec le hack au boot on peut revenir à un kernel d'origine et recuperer sa clef ansi que le contenu de la NAND. Ils pensent qu'une puce (infectus ou autre) ourra dans l'avenir faire ces opérations. Tout ceci en vue de faire , je suppose , un dual boot depuis une XD ou jouer au jeux (jusqu'au kernel 4532). Ils sont pessimiste sur le futur de ce projet (une puce et 34min pour pouvoir recuperer les données uniquement pour pouvoir en fait lancer linux sur un support ou avoir un dash!!!) etant donné que la sequence de boot est surement changer apres les kernel 4532 !!

Voila bref avancée sympas dash ou exploit en vue mais de toute facon choix obligatoire entre le live et le dash alternatif et SURTOUT sur une console qui a un dash qui permet de lancer le code donc construite avant le 01/01/2007.

++

Modifié par luxskywalker
Lien vers le commentaire
Partager sur d'autres sites

zouzz toujours a l'affut de big news .

j'espere que bientot le hack ne se contente pasde jouer avec des backup.

Belle avancee, merci zouzz

Lien vers le commentaire
Partager sur d'autres sites

zouzz toujours a l'affut de big news .

j'espere que bientot le hack ne se contente pasde jouer avec des backup.

Belle avancee, merci zouzz

merci zouzzz pour l'info

allez les gars encore un peu, et le kernel 4552 passera a la trappe (pour mon plus grand bonheur !)

++Ludo

Lien vers le commentaire
Partager sur d'autres sites

zouzz toujours a l'affut de big news .

j'espere que bientot le hack ne se contente pasde jouer avec des backup.

Belle avancee, merci zouzz

merci zouzzz pour l'info

allez les gars encore un peu, et le kernel 4552 passera a la trappe (pour mon plus grand bonheur !)

++Ludo

5759 faut te mettre à jour :ok:

Sinon ça avance bien ça fait plaisir

Lien vers le commentaire
Partager sur d'autres sites

zouzz toujours a l'affut de big news .

j'espere que bientot le hack ne se contente pasde jouer avec des backup.

Belle avancee, merci zouzz

merci zouzzz pour l'info

allez les gars encore un peu, et le kernel 4552 passera a la trappe (pour mon plus grand bonheur !)

++Ludo

5759 faut te mettre à jour :ok:

Sinon ça avance bien ça fait plaisir

ouais mais moi c'est le 4552 avec lequel ma console est flashé :prout: :lol:

Lien vers le commentaire
Partager sur d'autres sites

Ah j'ai pas tout compris de cette manière, voilà le topix que j'ai créé avant de qu'on me redirige vers ce topix :

Des membres du forum Xbox Hacker ont réussit à downgrader leur 360 de n'importe quel Kernel post 4548 vers le Kernel de base 1888. Il ne suffit plus ensuite qu'à passer en Kernel 4532 ou 4548 possèdant la faille hyperviseur pour prendre le controle total de la 360 et donc connaitre la clé unique de sa console.

Pour le moment la technique ne semble pas accessible à tout le monde mais serait réalisable pour peu qu'on s'y investisse.

Apparemment il serait nécessaire de fabriquer un circuit qui permettrait de contrôler de la puce infectus de manière autonome car il s'agit d'une méthode brute de hacking (tester plusieurs combinaisons de code) et le faire manuellement prendrait trop de temps. Les composants de ce circuit couterait une 20aine d'euro.

J'ai pas tout bien compris mais le principe du hack serait le suivant (d'après ce post ):

1) Dumper la flash d'une xbox post Kernel 4552.

2) Changer le flag du nombre d'eFuse dans l'image de la flash pour permettre au Firmware 1888 de booter.

3) Corrompre la mise à jour 4552 dans l'image de la flash (??? j'ai pas bien compris ça).

4) Trouver la valeur du hash (16 bytes) de la flash modifiée.

Comment?

a) programmer la flash avec la valeur de hash à 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (et coriger les bytes ECC)

booter la 360 et mesurer le temps que met la 360 pour planter.

c) re-programmer la flash avec la valeur de hash à 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

d) booter la 360 et mesurer le temps que met la 360 pour planter. Si la 360 met 2,2 µSecondes plus longtemps pour planter, mémoriser la valeur du 1er byte et passer au byte suivant. Sinon continuer et essayer la valeur suivante.

e) re-programmer la flash avec la valeur de hash à 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

f) booter la 360 et mesurer le temps que met la 360 pour planter. Si la 360 met 2,2 µSecondes plus longtemps pour planter, mémoriser la valeur du 1er byte et passer au byte suivant. Sinon continuer et essayer la valeur suivante.

g) ...

...

Continuer jsuqu'à trouver la bonne valeur pour le premier byte et passer au byte suivant.

Une fois le bon hash trouvé je suppose que la 360 bootera sans erreur en Kernel 1888.

Rem : dans le pire des cas, il faudrait reprogrammer la flash 128 x 32 fois càd 4096 fois la mémoire. On pourrait se demander si cela n'userait pas trop la mémoire mais selon son datasheet, elle peut être programmer environ 100 000 fois ce qui nous laisse de la marge.

Voilà pour la théorie, pour la pratique, faudra plus se renseigner mais null doute que les techniques vont évoluées et qui sait ptet que la Team Infectus dévelopera une manière de faire cette manipulation depuis son PC relié à la puce (enfin bon là je m'avance de trop).

Modifié par -Zou-
Lien vers le commentaire
Partager sur d'autres sites

je pense que le circuit a fabriquer, permetterait de mesurer les fameux temps de plantage,

avec tout ca relier au pc et un ptit soft qui va bien, ca permetterai d'avoir un systeme autonome.

++Ludo

Lien vers le commentaire
Partager sur d'autres sites

Exact, oh je sent que ça vient pas vous?

:0 :0 :0

Mais ça voudrait dire que sur toute les console vendu il y aurait plus de 2,500 console avec la même clé cpu??

Modifié par Yelrac
Lien vers le commentaire
Partager sur d'autres sites

Exact, oh je sent que ça vient pas vous?

:0:0:0

Mais ça voudrait dire que sur toute les console vendu il y aurait plus de 2,500 console avec la même clé cpu??

non non, chaque console a sa clef cpu

Lien vers le commentaire
Partager sur d'autres sites

Non le hash du firmware n'est en rien la clé unique de la console.

Des membres du forum Xbox Hacker ont réussit à downgrader leur 360 de n'importe quel Kernel post 4548 vers le Kernel de base 1888. Il ne suffit plus ensuite qu'à passer en Kernel 4532 ou 4548 possèdant la faille hyperviseur pour prendre le controle total de la 360 et donc connaitre la clé unique de sa console

Donc la méthode consiste à permettre de downgrader le Kernel (en trouvant le hash correct/compatible du firmware modifié avec sa console). Une fois revenu au Kernel 1888 il ne suffit plus qu'à passer en kernel 4532 et 4548 pour connaitre sa clé unique grâce au prog sous linux.

Modifié par -Zou-
Lien vers le commentaire
Partager sur d'autres sites

je pense que le circuit a fabriquer, permetterait de mesurer les fameux temps de plantage,

avec tout ca relier au pc et un ptit soft qui va bien, ca permetterai d'avoir un systeme autonome.

++Ludo

C'est possible là je suis pas catégorique parce que j'ai pas bien compris leur système.

Ils doivent flasher(console alumée éteinte?), alumer la console, mesurer le temps de boot, éteindre la console et recomencer le cycle. ils disent qu'ils font ça en 3 seconde avec le système automatique mais je suis sceptique.

Lien vers le commentaire
Partager sur d'autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
 Share

Annonces