Forum TI-Planet.org

Peut-être vous souvenez-vous d'imgdump, l'outil dont toutes les versions permettent de décompresser le boot2 des Nspire, et dont certaines versions permettent de déchiffrer l'OS des Clickpad & Touchpad.

Une version améliorée, destinée aux développeurs (fournie sans binaires, pour des raisons évidentes), avait été publiée il y a quelques semaines sur TI-Planet: imgdump.

Aujourd'hui est publié imgmanip, version un peu plus récente d'imgdump, disposant en plus de la capacité de compresser en utilisant le même algorithme que celui que TI utilise pour les boot2
imgmanip reste, comme les versions récentes d'imgdump, destiné aux développeurs: ceux qui savent compiler, lire et modifier du code C(++).

Ceci s'inscrit dans la lignée de ce que critor a mentionné tout à l'heure Boot2 et Diags interchangeables: un pas vers le dual Boot?), et pourrait éviter la réinvention de la roue à ceux qui voudraient faire des expériences avec FlashBoot2, FlashBoot2CX, FlashDiags et FlashDiagsCX.

Naturellement, les expérimentateurs ne doivent pas oublier que les boot2 et diags sont signés avec des clés RSA privées que seul TI possède, validés par les clés RSA publiques présentes dans le boot1

Show/Hide spoilerAfficher/Masquer le spoiler

Pour rappel, il est calculatoirement infaisable (pour nous) de factoriser des clés publiques de 768 bits et plus. Même la plus grande grille de calcul dédiée à la factorisation d'entiers, NFS@Home, ne peut pas factoriser des clés RSA 768 bits, et les clés 1024 bits sont encore au moins trois ordres de grandeur (x1000+) plus difficiles à factoriser
En 2009, à la fin de leur factorisation de RSA-768, même les chercheurs à la pointe de la factorisation d'entiers n'envisageaient pas (sauf improbable percée algorithmique) la factorisation de RSA-1024 avant 2015 environ, et ils sont les seuls à disposer des ressources (milliers d'années CPU) et des implémentations (à toutes les phases) capables de mener à bien ce genre de factorisations.

Je connais le Cpp mais la c'est du c++11 j'ai testé avec gcc 4.6, 4.7, 4.8 et clang impossible de le compiler je vais devoir faire mon propre compresseur en c++

Edit: après une réécriture en quelque chose qui ressemble plus a du C++ j'ai enfin compressé (semi manuellement) un boot2

Le code d'imgmanip n'est pas directement compilable, mais il est très facile de le transformer en code C++ compilable. Et comme indiqué dans les commentaires, c'est en effet du C++11, qui nécessite g++ >= 4.6 ou clang >= 3.0.

Je n'ai pas tout à fait compris comment on pouvait obtenir les clés RSA ? (le fichier keys.c j'imagine ?)
Si seul TI les possède ...

Non, les clés qui sont dans le fichier keys.c sont des clés Blowfish
Si tu examines bien le code source du programme et que tu comprends bien comment il fonctionne, tu trouveras peut-être quelque chose d'intéressant.

Dans le cas général, on peut obtenir les clés RSA privées à partir de la factorisation des clés RSA publiques. On l'a du reste fait pour les TI-Z80 et TI-68k en 2009, d'abord Benjamin Moody en solo, puis collectivement avec RSALS, maintenant fusionnée avec sa descendante NFS@Home, créée par un habitué de la factorisation d'entiers (ce qui n'était pas du tout notre cas).
Mais les clés RSA de tailles usuelles (nombre de bits puissance de 2) plus grandes que 512 bits sont trop difficiles à factoriser par des tiers. A ce jour, le record reste la factorisation de RSA-768, terminée en 2009 par les chercheurs au top du domaine; aucune factorisation aussi difficile que RSA-768 n'a encore été réalisée par d'autres personnes, même si le record actuel de NFS@Home est à moins d'un ordre de grandeur.
Dans le papier détaillant la factorisation de RSA-768, les chercheurs prédisaient que RSA-1024 ne serait probablement pas factorisée avant 2015, mais très probablement avant 2020. J'aurais tendance à penser que la factorisation de RSA-1024 est déjà en cours, mais bien sûr, il n'y a pas d'infos publiques à ce sujet. Et même après avoir donné à manger à RSALS la grande majorité des quelques centaines d'entiers mathématiques factorisés par RSALS, et en continuant à m'occuper d'une partie de NFS@Home, je doute de faire partie des personnes qui pourraient être mises dans la confidence, d'autant que je n'ai pas de compétences mathématiques appropriées ^^

Lionel Debroux wrote:Non, les clés qui sont dans le fichier keys.c sont des clés Blowfish
Si tu examines bien le code source du programme et que tu comprends bien comment il fonctionne, tu trouveras peut-être quelque chose d'intéressant.

Dans le cas général, on peut obtenir les clés RSA privées à partir de la factorisation des clés RSA publiques. On l'a du reste fait pour les TI-Z80 et TI-68k en 2009, d'abord Benjamin Moody en solo, puis collectivement avec RSALS, maintenant fusionnée avec sa descendante NFS@Home, créée par un habitué de la factorisation d'entiers (ce qui n'était pas du tout notre cas).
Mais les clés RSA de tailles usuelles (nombre de bits puissance de 2) plus grandes que 512 bits sont trop difficiles à factoriser par des tiers. A ce jour, le record reste la factorisation de RSA-768, terminée en 2009 par les chercheurs au top du domaine; aucune factorisation aussi difficile que RSA-768 n'a encore été réalisée par d'autres personnes, même si le record actuel de NFS@Home est à moins d'un ordre de grandeur.
Dans le papier détaillant la factorisation de RSA-768, les chercheurs prédisaient que RSA-1024 ne serait probablement pas factorisée avant 2015, mais très probablement avant 2020. J'aurais tendance à penser que la factorisation de RSA-1024 est déjà en cours, mais bien sûr, il n'y a pas d'infos publiques à ce sujet. Et même après avoir donné à manger à RSALS la grande majorité des quelques centaines d'entiers mathématiques factorisés par RSALS, et en continuant à m'occuper d'une partie de NFS@Home, je doute de faire partie des personnes qui pourraient être mises dans la confidence, d'autant que je n'ai pas de compétences mathématiques appropriées ^^

C'est bon j'ai réussi à la décompresser
En tout cas ça a vraiment dû être un boulot énorme pour faire tout ça (rien que savoir que c'était du blowfish ^^).

Sinon (c'est peut être indiscret), pourquoi "présenter" le fichier source de cette façon ? (Des problèmes de droits avec TI ? )

Savoir que c'était du Blowfish a été très rapide après que le code binaire clair ait été obtenu à partir du boot2, en 2009. C'est cette décompression du boot2 qui a été difficile à trouver.

Sinon (c'est peut être indiscret), pourquoi "présenter" le fichier source de cette façon ? (Des problèmes de droits avec TI ?)

Ce n'est pas indiscret, et c'est en effet à cause de possibles problèmes avec TI.
Depuis les suites de la factorisation des clés RSA des TI-Z80 et TI-68k en 2009, qui constituent l'épisode relaté à https://en.wikipedia.org/wiki/Texas_Ins ... ontroversy (j'ai édité la page, il y avait deux conneries - merci de me l'avoir faite pointer ^^), la communauté se méfie des actions inappropriées de TI.
Après l'intro Hey, TI, Leave Those Kids Alone, EFF Warns Texas Instruments to Stop Harassing Calculator Hobbyists explique de façon formelle et détaillée en quoi les lettres envoyées par TI à trois membres de la communauté étaient proprement illégales. Ca n'a pas empêché TI de continuer à envoyer ce genre de missives à des citoyens américains, ce qui leur a valu la deuxième couche Hey, Texas Instruments -- Stop Digging Holes.
Pour RSALS, fait par des français et hébergé en France, squalyl et moi n'avons pas eu l'équivalent sous la LCEN de ces DMCA takedowns, de même que yAro (français) pour yAronet (hébergé en Suisse, si je me souviens bien).

Enfin bref, à cause de ça, imgdump / imgmanip par leur(s) auteur(s), tout comme mon tiosmod+amspatch, ne sont pas fournis avec des binaires, et imgmanip n'est pas fourni sous forme complète ou directement compilable. Même si ça limite grandement l'utilisabilité, et donc la diffusion, des outils.