Voir la version complète : Envoi de code non signé sur la ds via le wifi
Bonjour,
je découvre la ds et la scéne qui va avec et je souhaiterai avoir des informations sur l'envoie de code sur la ds via le wifi.
Evidemment il faut un code signé pour qu'il soit lu par la ds, j'aimerai avoir des infos sur cette signature, savoir si il y'a des forums ou post où il est en question car je n'ai pas trouvé grand chose...
Y'a t-il des demos de jeux que nintendo fourni que l'ont peut envoyé à sa ds?
D'après ce que j'ai compris (parce que j'y connais rien en cryptographie donc je me plante peut être)
Effectivement, pour que le firmware de la DS accepte de lancer un programme téléchargé depuis le "Téléchargement DS", il faut qu'il ai également recu différentes clefs, qui correspondent à la signature de différentes zones du programme (binaire arm9, arm7, header, programme complet, ...) par une clef privée (RSA) de Nintendo. Cette clef n'est pas connue pour le moment, et il y a peu de chance qu'elle soit un jour "crackée".
Il y a effectivement des démos officielles de disponibles qui -comme elles sont signées- peuvent être envoyées via WMB. Il doit y avoir sur PA un topic qui liste ces démos.
Dr.Vince
17/07/2006, 17h14
ces vrais que y a pas beaucoup d'infos sur le sujet....
c'est bien dommage car c'est plutôt intéressant comme sujet
donc en fait le firmware modifié permet de passé outre cette vérification RSA ??
Ok merci pour les infos, je n'ai pas trouvé le topic qui liste les demos, si vous avez le lien...
Sinon pour la théorie, en effet, pour envoyer son code, on doit calculer une signature en fonction des données que contient le code.
Quand elle reçoit les données, la ds doit calculer la signature et si jamais ça ne correspond pas, elle refuse de l'executer.
Dr.Vince
17/07/2006, 17h25
je viens de me rendre compte de la connerie que j'ai écrit, le firmware modifié permet juste d'exécuter du code DS depuis le port GBA
Ok merci pour les infos, je n'ai pas trouvé le topic qui liste les demos, si vous avez le lien...
Sinon pour la théorie, en effet, pour envoyer son code, on doit calculer une signature en fonction des données que contient le code.
Quand elle reçoit les données, la ds doit calculer la signature et si jamais ça ne correspond pas, elle refuse de l'executer.
Je pense que c'est plus compliqué, et à vrai dire je comprends pas trop. Puisque cette clef est privée, la DS ne peut pas calculer cette signature, en fait, il doit y avoir une autre clef, publique celle là qui entre en jeu. (cette clef publique est connue, elle a été extraite du firmware).
Mais là faudrait se renseigner sur le mécanisme RSA et clef privée/publique. :S
donc en fait le firmware modifié permet de passé outre cette vérification RSA ??
Le Flashme supprime cette vérification effectivement. :)
ouep Dr vince, sinon vous connaissez pas un forum anglais ou autre qui pourrait en parler?(si je me souviens bien,dextrose etait bien pour la n64 mais y'a rien pour la ds)
thoduv, c'etait une spéculation, il y'a plusieurs solutions pour empecher le premier venu d'ajouter la signature nintendo à son code.
Pour RSA la clé publique permet à tout le monde d'encrypter son code et c'est précisement l'inverse que l'on veut avec la ds, on veut eviter que les gens puisse generer la signature nintendo.
Je pensais plutot à une methode de hachage made by nintendo.
voila ce ne sont que des spéculations et j'aimerai bien en savoir plus !
ouep Dr vince, sinon vous connaissez pas un forum anglais ou autre qui pourrait en parler?(si je me souviens bien,dextrose etait bien pour la n64 mais y'a rien pour la ds)
-> Gbadev
Dr.Vince
17/07/2006, 17h38
en fait je pense que c'est la clef privée qui a été extraite du firmware et il manque la clef publique connu que de bigN ??
[EDIT] en fait, y a un truc que je comprend pas
car pour que la DS puisse décrypter un truc(on va appeler ça message) encodé RSA il lui faut la clé privée (et la clé publique mais celle-ci est générée depuis la clé privée)
donc la clé qui se trouve dans le firmware est forcément la clé privée sinon la DS peux rien décoder. Donc si on a la clé privé et donc la publique bah il manque rien du tout pour passer à travers de RSA....
et quand aux démo officielles nintendo, vous les avez essayé?
je les ai trouvés la pour les curieux:
http://forum.gbadev.org/viewtopic.php?t=5861
en fait je pense que c'est la clef privée qui a été extraite du firmware et il manque la clef publique connu que de bigN ??
[EDIT] en fait, y a un truc que je comprend pas
car pour que la DS puisse décrypter un truc(on va appeler ça message) encodé RSA il lui faut la clé privée (et la clé publique mais celle-ci est générée depuis la clé privée)
donc la clé qui se trouve dans le firmware est forcément la clé privée sinon la DS peux rien décoder. Donc si on a la clé privé et donc la publique bah il manque rien du tout pour passer à travers de RSA....
Je vais me renseigner parce que ca m'énerve de pas comprendre :D
En tout cas, la seule clef connue c'est bien la publique (comme son nom l'indique :P)...
thoduv c'est confirmé que c'est un cryptage rsa ? as tu le lien ou autre ?
merki en tout cas !
Bon j'ai été voir sur Wikipédia et j'ai trouvé ce que je cherchais. En fait il s'agit d'un cryptage asymétrique: une clef qui crypte, une qui décrypte.
Dans le cas de la DS, celle qui crypte est privée, et c'est Nintendo qui l'as. L'autre, celle qui décrypte, est publique et se trouve dans le firmware.
Voir ici: http://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique
EDIT: Pas de lien pour savoir si c'est RSA, tu n'as qu'à retourner ta DS ! :lol:
Dr.Vince
17/07/2006, 18h04
oui, oui c'est bien un cryptage RSA
Dr.Vince
17/07/2006, 18h08
Bon j'ai été voir sur Wikipédia et j'ai trouvé ce que je cherchais. En fait il s'agit d'un cryptage asymétrique: une clef qui crypte, une qui décrypte.
Dans le cas de la DS, celle qui crypte est privée, et c'est Nintendo qui l'as. L'autre, celle qui décrypte, est publique et se trouve dans le firmware.
Voir ici: http://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique
EDIT: Pas de lien pour savoir si c'est RSA, tu n'as qu'à retourner ta DS ! :lol:
bah nan justement, dans l'exemple la NDS c'est alice car elle décrypte le message envoyé par Bob (le jeu) donc alice possède la clé privée
car on crypte avec la clé publique connue des deux parties et on décrypte avec la clé privée connue que d'une partie
Non, ca peut marcher dans les deux sens: où bien Alice donne à Bob une clef qui lui permet de lire les message qu'elle envoie (seul Alice peut encrypter des messages de facon à ce qu'il soient lisibles par Bob avec cette clef), où bien elle lui donne une clef qui lui permet de lui envoyer des messages (une fois le message crypté par Bob, seule Alice peut le lire).
Dr.Vince
17/07/2006, 18h26
nan, nan j'insistes mon cher thoduv, c'est le contraire, la clé publique permet d'encrypter et la clé privée de décrypter
donc alice ne peut pas donner à Bob une clé qui lui permet de lire les messages qu'elles envoies, sinon cela revient à dire qu'elle lui envoie la clé privée
[EDIT] Au temps pour moi
On remarque ici, que la clé publique a un rôle double puisqu'elle permet de chiffrer des données (lors du chiffrement conventionnel) mais aussi de déchiffrer des données (lors d'une identification).
mais c'est valable uniquement pour la phase d'identification
Y faut pas séparer les deux clefs sur le critère privée/publique, mais sur le critère cryptante/décryptante. Ensuite, selon à quoi elles servent, l'une ou l'autre seront privée/publique.
1) Nintendo crypte (clef privée, cryptante) une signature générée à partir du programme envoyé
2) Le firmware génère cette meme signature
3) Le firmware décrypte la signature cryptée par Nintendo (clef publique, décryptante)
4) Le firmware compare les deux
5) Si c'est les mêmes, il lance, sinon, il freeze sur l'écran blanc "Nintendo"
Dr.Vince
17/07/2006, 18h40
c'est exactement ça en fait, il utilise de RSA seulement la phase d'indentification et pas celle de chiffrement
Mon cours de crypto me fait dire ceci (pour essayer d'être clair) :
Nintendo crypte la signature avec sa clé privée pour prouver que c'est bien lui qui a écrit cette signature (la clé étant privée, seul Nintendo la possède et peut donc générer cette signature cryptée). La DS décrypte ensuite la signature avec la clé publique cette fois-ci (incluse dans le firmware, et récupérable par des bidouilleurs un minimum avertis), en effet, Nintendo se fout complètement qu'on ai la clé publique et la signature, puisque le chiffrage asymétrique ne nous permettra pas de générer la signature cryptée avec la clé privée...
Ai-je été clair? :lol:
de ce que j'ai lu sur gba dev:
nintendo calcule un hash du fichier à envoyé et l'encrypte en RSA 2048 bits :o
Ben niveau méthode, y'a vraiment moyen que ce soit ça, après, 2048 bits, c'est énorme !!!
[EDIT]Ca parait même normal que ça se passe comme ça, après réflexion...
Je m'explique.
Si la signature RSA présente dans un jeu était fixe (ie. pas dépendante du code qu'on veut faire exécuter à la DS), alors il suffirait de la récupérer telle quelle, brute, sans même réfléchir à la décrypter, de la coller dans du code quelconque, pas validé par Nintendo, pour en faire d'un coup un code signé par Nintendo.
Maintenant, si ce qu'on met dans la signature est un hash du code qu'on veut faire exécuter, alors, on aura ça: pour un code précis il y aura un hash (unique a priori), qui une fois crypté donnera une signature unique. Si le hash décrypté par la DS (avec sa clé publique) ne correspont pas au hash du code calculé par la DS, alors ce n'est pas ce code qui a été signé par Nintendo.
*souvenirs de mes cours de crypto :rolleyes:*
oui sto c'est exactement ça pour la méthode, on peut chopper la clé pour le décrypter sur la ds mais la clé pour encrypter est chez nintendo :)
Pour le nombre premier nintendo à fait appel à RSA BSAFE:
Nintendo Uses RSA Security
BSAFE encryption to be used in future wireless-capable DS software.
By Craig Harris
February 2, 2005 - RSA Security today announced that Nintendo is a licensor of RSA's BSAFE encryption solutions for the Nintendo DS system. This encryption will allow for safe and protected data transferred wirelessly between Nintendo DS units.
RSA BSAFE technology is used to protect the digital rights of game publishers for titles shared over these wireless links. The technology also allows Nintendo to protect game software that is issued on a trial basis for play in retail stores and other demo environments.
"Nintendo's use of our embedded RSA BSAFE technology in its portable game console is a great endorsement of our leadership in providing the security components consumer device manufacturers need, in order to offer protection for digital entertainment assets on their platforms," said Rick Welch, Vice President of Developer Solutions and Professional Services at RSA Security.
Nintendo DS systems have been using RSA security since the unit's debut in November 2004, as noted in the "RSA Secured" branding on the back of every system.
Pour les 2048 bits, c'est evidemment monstrueux!
Pour 256 bits il faudrai quelques heure sur un pc récent mais la complexité de l'algo de factorisation du nombre est exponentielle donc il faudrait des centaines d'années ou un truc sympa dans le genre...à vos maple ou ti en tout genre!:D
Sachant que les seules données qu'on ai pour casser le cryptage sont les environs 500 jeux (signés par Nintendo) et la clé publique incluse dans le firmware de la Nintendo DS... :ph34r:=_=:rolleyes:
en fait 500 jeux ou pas ça ne change rien, il faut factoriser en deux facteurs premiers la clé publique qui est dans la ds.
Dr.Vince
18/07/2006, 16h51
bon je crois avoir tout compris.
donc voici une méthode de hack possible :
1- on génére une clé bidon à la place de celle de Nintendo
2- on applique la clé publique de la DS
3- on obtiens le CRC32 (je pense)
3- on modifie la ROM pour obtenir le même CRC32
avec comme optimisation :
- on peut générer beaucoup de clé/CRC32 histoire que les étapes d'après soit plus simple qu'on ai moins a modifier la ROM (technique utilisée dans une des méthodes de hack du WEP)
quelques questions subsistent :
- où est stocké la (les ?) clé cryptée par BigN ?
- est-ce le CRC32 ?? en tout les cas c'est vérifiable
je comprend pas trop ta démarche dr vince, en tout cas c'est certainement pas du crc32 mais plutot une méthode de hachage genre SHA1 et co
Pour les 2048 bits, c'est evidemment monstrueux!
Pour 256 bits il faudrai quelques heure sur un pc récent mais la complexité de l'algo de factorisation du nombre est exponentielle donc il faudrait des centaines d'années ou un truc sympa dans le genre...à vos maple ou ti en tout genre!:D
Ou sinon tu demandes au Commissariat à l’énergie atomique de te prêter leur supercalculateur. :whst:
Bon sinon si vous vous lancez la dedans bon courage v_v :lol:
on discute juste pour le plaisir :)
sinon apparament les mecs de gbadev avaient penser faire un projet du genre seti@home pour factoriser le nombre, mais bon meme en étant dessus à plusieurs milliers, c'etait deja trop long donc c'est tombé à l'eau mais je vais essayé d'en savoir plus!
pour dr vince: la clé de nintendo est stocké dans le nombre premier public qui est deja connu, il faut factoriser ce "grand" nombre et à partir des deux facteurs premier on pourra generer la private key de nintendo!
pour mieux comprendre rsa, cette page est bien, ça ma rafraichis la mémoire sur rsa :
http://bobbyseb.free.fr/theme_8.html
Voici un ptit récapitulatif :
Les données à faire executer par la DS sont :
[pomme]
->nintendo calcule le sha1(ou autre méthode de hash je sais pas lequel nintendo utilise) de pomme
752c14ea195c460bac3c3b7896975ee9fd15eeb7
->Maintenant qu'on le sha1, il faut l'encrypter via RSA, 'm' contient les données et nintendo utilise ses deux clé privé 'n' et 'e', il genere 'c' la signature made by nintendo en utilisant ( c=m^e mod n ),
->il met la signature à la fin des données
pommeSIGNATURE
La ds reçoit les données et decrypte la signature à l'aide de la clé publique.
Il obtient le sha1 et calcule le hash des données puis les compare au hash qu'elle vient de decrypter!
Aprés vous avez compris la suite,il suffit à la ds de comparer les deux hash et si jamais ça correspond pas, soit y'a eu une erreur
de transmission de donnée soit le sha1 est pas crypté by nintendo!
Dr.Vince
18/07/2006, 17h59
n et e sont la clé publique.....
quelqu'un a-t-il un lien ou bien leurs valeurs ??
dr vince: rsa les apelles clé publique car rsa permet aux utilisateur un cryptage à l'aide de la clé publique et un décryptage à l'aide de la clé privée.
or dans le cas de nintendo, c'est un cryptage qui est reservé à nintendo et un decryptage pour tous les utilisateurs.
la clé publique devient privée et inversement.
Dr.Vince
18/07/2006, 22h33
dr vince: rsa les apelles clé publique car rsa permet aux utilisateur un cryptage à l'aide de la clé publique et un décryptage à l'aide de la clé privée.
or dans le cas de nintendo, c'est un cryptage qui est reservé à nintendo et un decryptage pour tous les utilisateurs.
la clé publique devient privée et inversement.
heu j'ai pas compris ta remarque
qu'une clé crypte/décrypte c'est pas ça qui fait qu'elle soit publique ou privée, c'est le fait qu'on la diffuse ou non
dr vince : ce que je veux dire c'est que n et e ne sont pas diffusé et sont les clés privés qu'on ne connais pas meme si dans le contexte RSA ce sont les clés publiques!
Sinon pour sortir un peu du rsa, voici un lien interressant sur le protocole wifi de la ds :
http://www.bottledlight.com/ds/index.php/Wifi/WMBProtocol
edit: apparament c'est bien du sha1 pour la signature :
http://www.cs.unc.edu/~jasleen/Courses/Fall05/projects/wmb_presentation.pdf
excellent ce pdf d'ailleur!
En tout cas, ce que j'ai pu lire partout, c'est qu'il ne faut VRAIMENT pas compter sur la brute force pour casser une clef de 1024bits (la taille de la clef privée de Nintendo).
L'algorithme de réduction c'est effectivement du SHA-1.
Et sinon, y'a pas une signature, mais 5.
- Binaire ARM9
- Binaire ARM7
- Header
- Header + ARM9 + ARM7
- Signature des signatures (:S)
Et la clef publique la voilà apparement: (sources de ndstool)
/*
* Data
*/
unsigned char publicKeyNintendo[] =
{
0x9E, 0xC1, 0xCC, 0xC0, 0x4A, 0x6B, 0xD0, 0xA0, 0x6D, 0x62, 0xED, 0x5F, 0x15, 0x67, 0x87, 0x12,
0xE6, 0xF4, 0x77, 0x1F, 0xD8, 0x5C, 0x81, 0xCE, 0x0C, 0xD0, 0x22, 0x31, 0xF5, 0x89, 0x08, 0xF5,
0xBE, 0x04, 0xCB, 0xC1, 0x4F, 0x63, 0xD9, 0x5A, 0x98, 0xFF, 0xEB, 0x36, 0x0F, 0x9C, 0x5D, 0xAD,
0x15, 0xB9, 0x99, 0xFB, 0xC6, 0x86, 0x2C, 0x0A, 0x0C, 0xFC, 0xE6, 0x86, 0x03, 0x60, 0xD4, 0x87,
0x28, 0xD5, 0x66, 0x42, 0x9C, 0xF7, 0x04, 0x14, 0x4E, 0x6F, 0x73, 0x20, 0xC3, 0x3E, 0x3F, 0xF5,
0x82, 0x2E, 0x78, 0x18, 0xD6, 0xCD, 0xD5, 0xC2, 0xDC, 0xAA, 0x1D, 0x34, 0x91, 0xEC, 0x99, 0xC9,
0xF7, 0xBF, 0xBF, 0xA0, 0x0E, 0x1E, 0xF0, 0x25, 0xF8, 0x66, 0x17, 0x54, 0x34, 0x28, 0x2D, 0x28,
0xA3, 0xAE, 0xF0, 0xA9, 0xFA, 0x3A, 0x70, 0x56, 0xD2, 0x34, 0xA9, 0xC5, 0x9E, 0x5D, 0xF5, 0xE1,
};
Pas mal d'infos dans le code, ici: http://devkitpro.cvs.sourceforge.net/devkitpro/tools/nds/ndstool/source/header.cpp?view=markup
Dr.Vince
19/07/2006, 11h25
ouais j'étais tombé sur ce pdf hier, et en plus c'est une fille qui l'a écrit !!
oué carrement et elle dit je cite ,concernant le paquet entier qui ne possede pas de signature 'a foolish security flaw'.
sinon merci thoduv, super lien, c'est donc une clé de 1024bit car javais lu que c'etait une clé de 2048bits sur gbadev, dans l'ensemble c'est quand meme assez difficile de trouver une explication claire sur cette signature.
Ces sources correspondent aux librairies fourni par nintendo ou bien c'est fait par des utilisateurs?
en tout cas j'ai maté le code et voici comment se fait le décryptage :
unsigned char sha1_from_sig[SHA1_DIGEST_SIZE];
{
BigInt _signature;
_signature.Set(signature, sizeof(signature));
//printf("signature: "); _signature.print();
BigInt _publicKey;
_publicKey.Set(publicKeyNintendo, sizeof(publicKeyNintendo));
//printf("public key: "); _publicKey.print();
BigInt big_sha1;
big_sha1.PowMod(_signature, _publicKey);
//printf("big_sha1: "); big_sha1.print();
big_sha1.Get(sha1_from_sig, sizeof(sha1_from_sig));
}
Il a lu la signature crypté dans la fct ShowVerboseInfo()(plus haut dans le code), ensuite pour la decrypter il met la signature à la puissance de la clé nintendo(bizarre d'habitude powmod sert à calculer a^n mod p, il n'y a que deux arguments ici) et il a donc le hash sha1!
on etait pas loin du compte!
edit: j'ai mater les source de la libraire bigint, il a codé en dur la puissance qui est 65537.
j'aimerai bien avoir une explication claire du pourquoi de ce 65537(2^16+1)
vBulletin® v.3.7.2, Copyright ©2000-2009, Jelsoft Enterprises Ltd. Tous droits réservés - Version française vbulletin-fr.org