Failles de sécurité dans TI BASIC +

Bonjour et bienvenue sur ce sujet dévoilant les failles de sécurité involontairement laissées par TI BASIC +.

Voici la liste des failles que j'ai décelées hier :

1) Si une personne malveillante remplace un des programmes basic par un virus, l'utilisateur risque de le faire fonctionner
2) Avec Doors CS 7, on peut modifier le code source de tous les programmes de TI BASIC +, et même retirer la protection
Des programmes du logiciel

Voilà !

J'espère qu'Alexis, l'administrateur du site, corrigera bien vite ces failles !

Je propose donc de réunir tous les programmes en un seul, puis les convertir en programme en ASM Z80, ce qui permettra non seulement de ne pas pouvoir remplacer les programmes, mais en plus d'avoir accès au code source pour les versions 1.0 et supérieures de TI-BASIC +.

Note : Pour assembler les programmes, d'abord les réunir en un seul fichier puis convertir en ASM Z80 grâce à l'application Axe.

Tu ne te rends pas compte qu'il n'y a aucune équivalence entre le Basic et l'assembleur. Changer de language reviendrait à tout refaire. (Et se contenter de refaire la même chose serait un gâchis puisque l'assembleur est plus puissant. Là c'est juste mon propre avis.)
Axe est seulement un compilateur qui reçoit un code source stocké dans un programme Basic, et ce code source n'a rien à voir avec un code Basic.

Il n'y a pas besoin de DCS7 pour modifier un programme protégé contre l'édition. Il suffit de le déprotéger et tous les shells corrects le font.
De plus on peut se contenter des programmes ZPROT et ZUNPROT écris par Alexis et Matrefeytontias autant pour ti83plus que pour ti82stat.
On peut aller plus loin avec HIDE de Matrefeytontias.

Celui qui veut créer un virus pourra quand-même modifier un programme assembleur, qu'il soit squished ou non. (squished signifie que le programme est brut pour le processeur, sinon il est lisible en hexadécimal dans l'éditeur de programme basic)
Et si le but du malveillant est un RamClear ou plus grâve, il suffit de modifier le code hexadécimal au hasard, de préférence en modifiant le registre iy pour semer le chaos dans les flags, c'est très efficace pour 3 octets maximum.

Je ne sais pas trop comment les shells bloquent les programmes par mot de passe.

Cela dit l'idée de rassembler les programmes en un seul peut effectivement être une solution à des trafics sur les composants.
Mais le projet devait permettre d'ajouter des "Plug-in", donc passer à l'assembleur et un unique programme ne correspond pas.

Comment les shells gèrent les mots de passe avant l'exécution, c'est simple : puisque c'est eux qui lancent le programme, ils n'ont qu'à demander un mot de passe avant de l'exécuter.

Sinon, pour ta proposition Clément, comme dit Linkakro l'Axe est un langage à part qui n'a rien à voir avec le Basic si ce n'est qu'ils utilisent le même éditeur. C'est comme si tu disais que JavaScript et HTML étaient pareils puisque les navigateurs les comprennent tous les deux.

Par contre, un truc qui existe est BasicBuilder : ça compile des programmes Basic en applications Flash, donc absolument pas éditables par aucun moyen.

Ah, ça c'est intéressant, le BasicBuilder dont tu parles.
Mais je pense qu'une ou plusieurs pages mémoires d'appli sont excessives pour l'importance de ces programmes.

La solution Basic Builder est la seule envisageable, mais il y aura beaucoup d'inconvénients :
- Basic Builder laisse des bugs ;
- tout le monde (ou presque) se fout aujourd'hui de TI-Basic + ;
- personne ne va te "hacker" ta calculatrice, et si on veut vraiment le faire, TI-Basic + serait sans doute le dernier moyen auquel on penserait ;
- ça prend de la place pour rien ;
- on perd le système de "plug-in" qui était un atout du programme ;
- on perd la compatibilité toutes z80.

Et on pourrait en rajouter.

Et puis au pire si tu veux vraiment protéger ta calto, tu n'as qu'à utiliser ZLOCK de matref, personne ne pourra allumer ta calto

Oui ca n'a absolument aucun interet de proteger TI-Basic+

D'accord, je croyais qu'Alexis voulait protéger le code source de TI-BASIC +.

Cela dit, transformer le programme en application flash sauf le programme des plug-ins est une bonne idée car le programme, une fois installée, utilise environ 15 ko de mémoire vive !

Alors qu'une application flash prendrait un seul espace App, c'est-à-dire 16384 octets ( 16 ko ); et cela permettrait de réduire la quantité de mémoire vive utilisée à 1 ko seulement !

Au fait, j'ai une question : à quoi servent les plug-ins et comment les programmer ( je sais qu'on les faits en TI-BASIC, mais agir directement sur le menu de TI-BASIC + est très difficile : il faudrait écrire les textes et les pixels à un endroit précis de l'écran, etc. ).

Il y a eu jadis un concours de ce forum qui devait lancer des plugins, la méthode de création était rappelée.
Puisque le code source est actuellement accessible, tu peux déjà regarder comment ça marche.
Je crois me souvenir, qu'il fallait nommer le programme ZPLUGIN et seulement ça.
J'ai tout oublié du reste. Même la méthode de mot de passe.
J'ai sous la main le plugin que j'avais écrit.

Clément.7 a écrit:Cela dit, transformer le programme en application flash sauf le programme des plug-ins est une bonne idée car le programme, une fois installée, utilise environ 15 ko de mémoire vive !

Alors qu'une application flash prendrait un seul espace App, c'est-à-dire 16384 octets ( 16 ko ); et cela permettrait de réduire la quantité de mémoire vive utilisée à 1 ko seulement !

Euh, non. BasicBuilder n'exécute pas les programmes qu'il contient depuis la Flash, il les copie dans la RAM. Donc certes, ton application n'utilise pas de RAM tant qu'elle n'est pas lancée (ce qui est déjà bien en soi) et ne nécessite pas de désarchivage avant d'être lancée, mais si tu n'as pas les 15 Ko de RAM nécessaires au lancement des programmes Basic, ils ne se lanceront pas, donc tu n'utilises pas que 1 Ko de mémoire vive (ou alors j'ai mal compris ce que tu voulais dire).