Deviner Un Code Cpu

[Télémaque]

Salut les Gueux,

Une idée m'est venue hier soir et je pense qu'elle mérite qu'on s'y intéresse notamment pour nos chères consoles NON-Compatibles JTAG.

La plupart d'entre nous le savent sûrement, il existe des softs, genre Advanced Password Recovery, qui devinent une clef de cryptage par comparaison de données partielles cryptées/décryptée. Perso, j'ai déjà déchiffré une archive WinZIP encryptée grâce à un texte non-crypté à l'intérieur. L'APR s'en est chargé et qques minutes plus tard j'avais mon fichier décrypté !

Imaginez maintenant un petit soft du même jus qui comparait une clef DVD (extraite du lecteur) et le Kvraw.bin extrait de la nand dumpée (d'une console non-JTAG) en cherchant une occurrence sur la clef DVD que contient le Kvraw (Kv enc.bin).

Résultat: le soft devine la clef de cryptage et nous ressortirait la Clef CPU !

Bref, nand modifiable à nouveau !

Naturellement, ça ne permettrait pas d'installer un XBR pour autant mais les modif du Kv.bin sont possibles.

Qu'en pensez vous ?

@+++

[Yelrac]

Salut les Gueux,

Une idée m'est venue hier soir et je pense qu'elle mérite qu'on s'y intéresse notamment pour nos chères consoles NON-Compatibles JTAG.

La plupart d'entre nous le savent sûrement, il existe des softs, genre Advanced Password Recovery, qui devinent une clef de cryptage par comparaison de données partielles cryptées/décryptée. Perso, j'ai déjà déchiffré une archive WinZIP encryptée grâce à un texte non-crypté à l'intérieur. L'APR s'en est chargé et qques minutes plus tard j'avais mon fichier décrypté !

Imaginez maintenant un petit soft du même jus qui comparait une clef DVD (extraite du lecteur) et le Kvraw.bin extrait de la nand dumpée (d'une console non-JTAG) en cherchant une occurrence sur la clef DVD que contient le Kvraw (Kv enc.bin).

Résultat: le soft devine la clef de cryptage et nous ressortirait la Clef CPU !

Bref, nand modifiable à nouveau !

Naturellement, ça ne permettrait pas d'installer un XBR pour autant mais les modif du Kv.bin sont possibles.

Qu'en pensez vous ?

@+++

As-tu une idée de la puissance de calcul nécessaire pour une clé de cette longueur?

Bien sur que c'est possible, mais on se revoit dans une 10aine d'années

[tomtom33]

Tout à fait d'accord avec mon ami yelrac il faut une grande puissance de calcul sinon bon courage

[Télémaque]

Non,

Ce n'est pas comparable: on ne travaille pas de "ex nihilo", cad de rien du tout mais à partir d'éléments connus tel que la clef DVD (extraite) et le Kvraw (dumpé lui aussi) et on ne fait que comparer jusqu'à trouver, c'est faisable j'en suis sûr !

On est d'accord ça va tourner un peu mais pas tant que ça, j'en suis persuadé, c'est un simple attaque prédictive.

Y'a t'il un codeur par nous ?

Help, ça serait une belle porte de sortie pour les consoles récentes...

[Shakin]

Salut,

Moi je te conseil d'encypter un fichier, mais un tout petit fichier encore plus petit que le KV, et ensuite d'en trouver la clé, tu vas voir le temps que ça va te prendre.

Je te rappelle que c'est une clé avec 32 caractères en hexadécimal ce qui fait 3,4^38 combinaisons possibles.

@+

[Télémaque]

Hello Shakin,

Yes, tu me l'a déjà dit mais ce n'est pas du brute-attack, c une simple attaque prédictive jusqu'à trouver la clef de décryptage (pas la clef CPU, à ce stade on y est pas encore).

Pour tout t'avouer, à l'époque quand j'avais décrypté avec APR un fichier ZIP encrypté dont le MDP était une phrase complète (donc + de 32 caractères), ça m'avait pris seulement une dizaine de minutes, pas plus. Même si ça prenait une semaine de calculs intensif, je pense que le jeu en vaut la chandelle.

Bon, sur le fond tu as raison et en fait ton expérience m'intéresserait bien car je pourrais la confier à l'un de mes potes informaticiens sur leurs serveurs mais encore faut il que j'ai le bon soft de décryptage, tu en connais un de valable ?

Je suis sûr que c'est humainement faisable...

Y'a pas un gars de la NSA parmi nous ?

@+++

Modifié le 22 mars 2010 par Télémaque

[val532]

Salut,

L'idée est pas mal et je la comprend bien.

Mais il y a un gros problème dans le raisonnement, les cryptages doit s'effectuer par bloc de donnée et à mon avis un bloc est plus grand que la clef DVD.

Toi se que tu pense faire c'est retrouvé une phrase dans la quel les lettres on été mélangé, mais se que on a c'est une phrase planqué dans un texte avec les lettres mélangé partout.

(je sais c'est un gros dessin et peut être faut mais c'est juste pour illustré mon avis sur le sujet.)

[Télémaque]

Et c jouable à ton avis ?

Perso, j'ai phosphoré ça à cause de toutes ces CM dont le CD n'est plus exploitable et dont je n'ai plus la clef DVD.

Je persiste à rêver que c'est réalisable vu ce que j'ai déjà fait sur des archives ZIP encryptées...

@+

[Yelrac]

Et c jouable à ton avis ?

Perso, j'ai phosphoré ça à cause de toutes ces CM dont le CD n'est plus exploitable et dont je n'ai plus la clef DVD.

Je persiste à rêver que c'est réalisable vu ce que j'ai déjà fait sur des archives ZIP encryptées...

@+

C'est pas le même codage... Et la clé n'est pas vraiment de la même longueur cf plus haut.

[val532]

Je crois que pour se qui est du codage l'algorithme est connu donc de se coté la pas de problème.

Après il faudrait un bon dev qui touche sa bille en cryptage pour faire quelque teste.

Le plus simple pour commencé est de dumpé un Nand dont on connais la clef DVD, créer un fichier en hexa qui contiendra juste la clef (crypté). Et créer un logiciel qui s'occupera de testé les décodage.

Sinon j'ai une idée pour vérifier la validité de cette théorie, mais pour sa il faudrait une console dont on connais la clef CPU et la clef DVD et un logiciel permettent de crypté de la même façon que dans la console (le même algorithme de cryptage).

Je m'explique : On créer un fichier .bin qui contient uniquement la clef et donc qui fait 32 octet (il me semble si la clef fait 32 caractère).

Avec la clef CPU on l'encrypte comme si il s'agissait d'un fichier de Nand complet.

Et on compare de résulta du fichier crypté le la valeur dans la Nand de la console (crypté bien entendu).

Si le fichier contient le même résultat sa veut dire qu'il y a une chance que sa marche, sinon il faudra emprunté un super calculateur.

Si je suis pas clair dite moi.

[amiralj]

Tout à fait d'accord avec mon ami yelrac il faut une grande puissance de calcul sinon bon courage

Demande à un possesseur de ps3, il va te dire que le cell peut le faire

[charlo.charli]

Si c'est fait sur un fichier, l'algorythme devra etre alors retenu pour justement casser plus facilement les autre clés sans avoir a decrypter... C'est ce que je vois moi

Mais en meme temps je suis pas pro dans le domaine

[wj_64]

Bonjour.

Juste une idée en lisant ce post.

Y aurait-il pas une clé passe partout ?

Je pense que lorsque une mise à jour officelle est envoyée, on a bien le même fichier crypté pour toutes les consoles du MOOOOOONDE !!!!

Et pour s'installer dans la Nand, ce fichier est bien décrypté par des milliers de clés différentes, ou peut-être avec une seule et unique clé !????!!!!.

Je raconte probablement une bêtise pour ne pas dire une c..... mais c'est juste une idée.

Bon, je retourne à mes moutons !!!!

A+

[val532]

Oui pour signé les xex il y a une clef unique, qui est la clef privé de MS que personne n'a sinon pas besoin de craké les consoles pour lancé du code non signé.

[Télémaque]

Bonjour.

Juste une idée en lisant ce post.

Y aurait-il pas une clé passe partout ?

Je pense que lorsque une mise à jour officelle est envoyée, on a bien le même fichier crypté pour toutes les consoles du MOOOOOONDE !!!!

Et pour s'installer dans la Nand, ce fichier est bien décrypté par des milliers de clés différentes, ou peut-être avec une seule et unique clé !????!!!!.

Je raconte probablement une bêtise pour ne pas dire une c..... mais c'est juste une idée.

Bon, je retourne à mes moutons !!!!

A+

Re les Gueux,

Content de ne pas être le seul à y penser.

Maintenant, pour ça faut trouver et kidnapper le bon gus...

@+

[tipeddp]

il faudrais chopper le l'algorythme de cryptage ( il a ete trouver pour faire les encrypteur de KV.bin avec les clef CPU ) puis de le faire a l'envers !!!

mais bon il doit y avoir une association de la clef sur elle meme !!!!

en conaissancertain paramétre, tu doit pouvoir trouver une partie de la clef par calcul mais bon ce n'est que des supposiition

[AnGe7]

Bonjour.

Juste une idée en lisant ce post.

Y aurait-il pas une clé passe partout ?

Je pense que lorsque une mise à jour officelle est envoyée, on a bien le même fichier crypté pour toutes les consoles du MOOOOOONDE !!!!

Et pour s'installer dans la Nand, ce fichier est bien décrypté par des milliers de clés différentes, ou peut-être avec une seule et unique clé !????!!!!.

Je raconte probablement une bêtise pour ne pas dire une c..... mais c'est juste une idée.

Bon, je retourne à mes moutons !!!!

A+

Re les Gueux,

Content de ne pas être le seul à y penser.

Maintenant, pour ça faut trouver et kidnapper le bon gus...

@+

Y en a qui vont voir débarqué le FBI chez eux à faire des blagues dans le genre... non rigolé pas, ca c'est déjà vu pour moins que ça...

[-Zou-]

Je crois que pour se qui est du codage l'algorithme est connu donc de se coté la pas de problème.

Après il faudrait un bon dev qui touche sa bille en cryptage pour faire quelque teste.

Le plus simple pour commencé est de dumpé un Nand dont on connais la clef DVD, créer un fichier en hexa qui contiendra juste la clef (crypté). Et créer un logiciel qui s'occupera de testé les décodage.

Sinon j'ai une idée pour vérifier la validité de cette théorie, mais pour sa il faudrait une console dont on connais la clef CPU et la clef DVD et un logiciel permettent de crypté de la même façon que dans la console (le même algorithme de cryptage).

Je m'explique : On créer un fichier .bin qui contient uniquement la clef et donc qui fait 32 octet (il me semble si la clef fait 32 caractère).

Avec la clef CPU on l'encrypte comme si il s'agissait d'un fichier de Nand complet.

Et on compare de résulta du fichier crypté le la valeur dans la Nand de la console (crypté bien entendu).

Si le fichier contient le même résultat sa veut dire qu'il y a une chance que sa marche, sinon il faudra emprunté un super calculateur.

Si je suis pas clair dite moi.

1°) Rien ne dit que la clé DVD cryptée se trouve en un bloc dans le keyvault crypté, elle peut très bien être dispersée.

2°) Ce que tu décris est la technique du brute force (tester toutes les combinaisons pour retrouver la valeur attendue). Petit calcul vite fait :

La clé CPU est de 16 octet. Sachant qu'un octet c'est 256 possibilité, il y aura 256^16 possibilité de combinaisons soit un peu plus de 340282366920938463463374607431770000000 combinaisons.

En supposant qu'on ai un processeur ultra puissant comme le dernier Intel Core i7 Extreme Edition i980EE qui effectue 147,6 BIPS et en admettant de manière totalement farfelue qu'on puisse effectuer l'opération que tu décris en une seule instruction (ce qui est est une estimation très très optimiste car il faut beaucoup beaucoup ... plus qu'une instruction pour réaliser un cryptage + une comparaison ), cela reviendrait à pouvoir tester 147,6 milliard de combinaisons en une seconde.

Il faudrait donc 340 282 366 920 938 463 463 374 607 431 770 000 000 / 147 600 000 000 = 2305436090250260592570288668 secondes pour effectuer toutes les combinaisons ce qui représente 731048988536992831231 années . Si avec un peu de chance la clé de cryptage se trouve au milleu, il faudrait tout de même attendre 365524494268496415615 années et demi pour tomber dessus ...

Modifié le 31 mars 2010 par -Zou-

[-Zou-]

Ce n'est pas comparable: on ne travaille pas de "ex nihilo", cad de rien du tout mais à partir d'éléments connus tel que la clef DVD (extraite) et le Kvraw (dumpé lui aussi) et on ne fait que comparer jusqu'à trouver, c'est faisable j'en suis sûr !

On est d'accord ça va tourner un peu mais pas tant que ça, j'en suis persuadé, c'est un simple attaque prédictive.

Y'a t'il un codeur par nous ?

Connaitre la clé DVD ne signifie pas qu'on ne fait pas du brute force. Justement le faite de savoir à quoi on s'attend (la clé DVD par ex.) va permettre de faire du brute force. Si on avait pas cette donnée, on ne pourrait tout simplement pas déchiffrer ce qui a été crypter, logique puisqu'on ne saurait pas quel déchiffrage serait la bonne réponse.

[Télémaque]

Y en a qui vont voir débarqué le FBI chez eux à faire des blagues dans le genre... non rigolé pas, ca c'est déjà vu pour moins que ça...

Flûte et Saperlipopette,

J'avais totalement zappé ça, t'as raison Man !!!

[tikilou]

Je crois que pour se qui est du codage l'algorithme est connu donc de se coté la pas de problème.

Après il faudrait un bon dev qui touche sa bille en cryptage pour faire quelque teste.

Le plus simple pour commencé est de dumpé un Nand dont on connais la clef DVD, créer un fichier en hexa qui contiendra juste la clef (crypté). Et créer un logiciel qui s'occupera de testé les décodage.

Sinon j'ai une idée pour vérifier la validité de cette théorie, mais pour sa il faudrait une console dont on connais la clef CPU et la clef DVD et un logiciel permettent de crypté de la même façon que dans la console (le même algorithme de cryptage).

Je m'explique : On créer un fichier .bin qui contient uniquement la clef et donc qui fait 32 octet (il me semble si la clef fait 32 caractère).

Avec la clef CPU on l'encrypte comme si il s'agissait d'un fichier de Nand complet.

Et on compare de résulta du fichier crypté le la valeur dans la Nand de la console (crypté bien entendu).

Si le fichier contient le même résultat sa veut dire qu'il y a une chance que sa marche, sinon il faudra emprunté un super calculateur.

Si je suis pas clair dite moi.

1°) Rien ne dit que la clé DVD cryptée se trouve en un bloc dans le keyvault crypté, elle peut très bien être dispersée.

2°) Ce que tu décris est la technique du brute force (tester toutes les combinaisons pour retrouver la valeur attendue). Petit calcul vite fait :

La clé CPU est de 16 octet. Sachant qu'un octet c'est 256 possibilité, il y aura 256^16 possibilité de combinaisons soit un peu plus de 340282366920938463463374607431770000000 combinaisons.

En supposant qu'on ai un processeur ultra puissant comme le dernier Intel Core i7 Extreme Edition i980EE qui effectue 147,6 BIPS et en admettant de manière totalement farfelue qu'on puisse effectuer l'opération que tu décris en une seule instruction (ce qui est est une estimation très très optimiste car il faut beaucoup beaucoup ... plus qu'une instruction pour réaliser un cryptage + une comparaison ), cela reviendrait à pouvoir tester 147,6 milliard de combinaisons en une seconde.

Il faudrait donc 340 282 366 920 938 463 463 374 607 431 770 000 000 / 147 600 000 000 = 2305436090250260592570288668 secondes pour effectuer toutes les combinaisons ce qui représente 731048988536992831231 années . Si avec un peu de chance la clé de cryptage se trouve au milleu, il faudrait tout de même attendre 365524494268496415615 années et demi pour tomber dessus ...

Et faire du calcul à travers plusieurs unités... Une ferme de PC participant à ces calculs? Genre seti@home ?

Un seul PC, seul c'est rien, mais si tu y associe quelques dizaines/centaines de milliers de PC volontaires... Voir plus (vu l'engouement généré par une possibilité de faire tourner des backups)

Bon après c'est sûr... Faut le serveur pour gérer la redistribution/répartition des calculs... Et un logiciel client disponible sur Mac/Win/Lin pour récupérer les calculs à faire en exploitant les ressources non utilisées.

Avec un peu de bonne volonté, une exploitation des GPU à travers OpenCL ne serait pas de trop en plus de tout ceci.

Modifié le 1 avril 2010 par tikilou

[Shakin]

Salut,

On va pas construire une NASA2 rien que pour ça, ça serait pas rentable

@+

[-Zou-]

@tikilou :

- Je parle ici de trouver la clé CPU d'UNE seule Xbox, je vois mal réunir autant de moyen pour juste trouver la clé d'une Xbox.

- S'il s'agit de trouver la Clé de cryptage des XEX, ce ne sera pas aussi "simlple" puisque la clé de cryptage est encore plus longue que celle du CPU (il me semble 256 bit au lieu de 128 pour la clé CPU). Je me rappel qu'il y avait eu un projet similaire pour les xbe de la xbox 1 (partage des calculs pour trouver la clé) mais ça n'a jamais abouti. Donc maintenant en sachant que la clé des xex a encore été agrandie, je doute fortement qu'on y arrive même en se rassemblant.

- Je rappel que le PC que j'ai pris comme exemple n'existe pas encore et est à mon avis encore loin d'exister.

- De toute façon le calcul est simple si tu veux par exemple trouver la clé en 10 ans, t'as qu'à diviser le nombre d'année par 10 et t'obtiendra le nombre de PC pour pouvoir le faire en 10 ans. Soit 731048988536992831231 / 10 = 73104898853699283123 de PC ... . Je pense qu'il vaut mieux attendre les ordinateur quantique mais à ce moment là la xbox360 sera déjà morte et enterrée.

[val532]

Moi je pensais que se serais plus simple d'attaqué un fichier court dont on connais le résultat et et de le crypté avec toute les clef que on peut testé et comparé avec le résultat que l'on doit connaitre.

[-Zou-]

Ca revient à la même chose, déchiffre et comparer un petit fichier nécessite quand même un certains nombre d'instructions, alors que dans mon exemple j'ai supposé qu'il ne fallait qu'une seule instruction pour le faire, c'est dire si on est encore loin de pour voir faire du brute force.

Modifié le 2 avril 2010 par -Zou-