Signer une ROM - Page 1

Bon, je sais que deja beaucoup de TRES TRES bons ont essayé de signer les ROMS pour ne pas avoir besoin de tibreceiver. Mais je viens de penser a quelquechose :
1-J'ai entendu dire que la ROM de la Ti implementait du RSA. Ca, je veux bien le croire, car j'ai vu des ROM_CALLs de crypto. Mais par contre, j'ai aussi entendu dire que la ROM entiere etait cryptée. Ca, j'y crois MOYEN : quand on voit le temps que met un bon PC a encoder en RSA, j'imagine meme pas sur une Ti ! Donc a mon avis, le RSA, c'est juste pour les certifs des logiciels payants.
2-J'ai remarqué dans le menu de teste a la sortie d'usine (Faites Trap #10 = Exec '4e4AE750000') qu'il y avait une option TEST de la FLASH ROM. Bon, cette option m'a parue assez interessante, et je l'ai testée sur mes deux Ti : sur ma 92 HW1, ou la ROM etait celle originale, le teste ce deroule et on est ramene au menu : tout ce passe bien. Sur ma HW2, patchée avec le genial HW2Patch, les choses se sont corsées : le test se deroule, et il m'affiche a un moment : checksum error, et ensuite deux longwords en hexa : a mon avis la valeur de checksum calculée et celle enregistree. Bon, ca c'était une supposition. J'ai donc debuggé le trap 10 avec DB92, et effectivement, c'est bien ce qui se passe : la Ti fait bien un checksum sur la ROM, et la compare ensuite a une valeur bien fixée.
Ne tient on pas la le moyen de signer une ROM ????? Parce que si ca ce trouve, c'est le meme algo qui est employé par la Ti lorsqu'elle vient de recevoir une ROM.

Je n'ai pas la possibilité de tester ca moi meme (pas de PC !), mais j'espere que qqn pourrait le faire. (ou me dire sinon pourquoi je me suis gourré)

Merci beaucoup :-)

ce qui pourais justifier une certaine redondance de certains code.. (cf topic janjan...)

Ouais, peut etre... Toujours est-il que j'aimerai bien que quelqu'un me dise si je fais fausse route ou pas ! Je suis trop impatient, mais malheureusement, je peux pas tester moi-meme

Signer une ROM reviens à trouver la clé publique que TI a utilisée, ce qui demande une quantité de calcul absolument démentielle.

Mais je vais quand même commenter ton post :

1-J'ai entendu dire que la ROM de la Ti implementait du RSA.
Oui c'est bien ça. C'est même du RSA 512 bits.

Mais par contre, j'ai aussi entendu dire que la ROM entiere etait cryptée.
Qu'est-ce que tu entends par là ??

Sur ma HW2, patchée avec le genial HW2Patch, les choses se sont corsées : le test se deroule, et il m'affiche a un moment : checksum error, et ensuite deux longwords en hexa : a mon avis la valeur de checksum calculée et celle enregistree.
Je n'ai volotairement pas patché le checksum pour savoir, non seulement parce que ça demande du boulot, et aussi parce que ça permet de savoir si la flash a été modifiée (important à savoir avant d'envoyer sa ROM vers une autre calculatrice).

Parce que si ca ce trouve, c'est le meme algo qui est employé par la Ti lorsqu'elle vient de recevoir une ROM.
Non justement. Le boot n'utilise pas la même méthode que le self test.
Il effecute d'une part un checksum MD5 du tib (TI basecode ou code produit) (sauf des derniers 65 octets) et encrypte d'autre part les derniers 64 octets à l'aide de la clé privée (sauvée dans le boot). Il compare ensuite les deux résultats et ne boote que s'ils sont égaux. Les derniers 65 octets étant l'octet 0x40 (taille) suivi du checksum MD5 du tib encrypté par TI avec la clé publique.

Ouais, OK :-) Je me disais bien aussi que je n'allais pas tout révolutionner :-) Merci quand meme d'avoir répondu, j'ai appris des trucs interessants... Mais comment vous avez su tout ca ????

Avec le débogueur de VTI et de la patience

Question topics révolutionnaires, on est dans le même cas tout les deux

>JM : "Il effecute d'une part un checksum MD5 du tib (TI basecode ou code produit) (sauf des derniers 65 octets) et encrypte d'autre part les derniers 64 octets à l'aide de la clé privée (sauvée dans le boot). Il compare ensuite les deux résultats et ne boote que s'ils sont égaux. Les derniers 65 octets étant l'octet 0x40 (taille) suivi du checksum MD5 du tib encrypté par TI avec la clé publique."

Ca serait pas plutôt un decryptage des 64 derniers octets avec la clé publique, et une comparaison ?

Dans la doc de TIGCC, MD5_CTX :

Summary, message digests create a unique number for given data. By sending a message digest encrypted with the private key, along with the original message, it is possible to check that the message came from the correct source. This is done by generating the message digest, and comparing it against the encrypted version sent along with the message (decrypted with the public key). If they match, then this "authenticates" the message.

La clé qui manque pour signer un OS, ça serait alors plutôt la clé privée.

Question de point de vue.
Dans une correspondance entre deux personnes, chacun possède 2 clés : une privée, qu'il conserve pour décrypter un message qui lui est destiné, et une publique qu'il diffuse pour qu'on puisse lui envoyer un message qu'il sera le seul à pouvoir lire.
Donc c'est bien la clé publique, celle qui crypte, qui nous manque.

Mais bon, ça change rien.

La doc de TIGCC mentionne l'autre utilité du RSA : s'assurer quele message est envoyé par la bonne source.
Mais pour moi, le cryptage me fait d'abord penser à la confidentialité.
De toute façon, le protocole RSA classique effectue le double cryptage.

ok.