Forum TI-Planet.org

Bonjour à tous

Je suis professeur dans une école et je crée des programmes pour mes élèves. Pour éviter que mes programmes ne fassent le tour du monde j'aimerais savoir s'il existait un moyen de bloquer les programmes dans la calculatrice qui héberge ce programme.
En résumer éviter le transfert d'une calculatrice à une autre, ou pire d'une calculatrice à un PC

Si cela est impossible pouvons nous bloquer la modification du script histoire de pouvoir au moins y assigner ma signature.

Une école concurrente de la notre ne rêve que d'une chose "mettre la mains sur nos programmes"


(Je parle d'une Ti Nspire CX CAS)

Merci à tous !!!!

Bonjour ,

Je ne sais pas, désolé ...
(Peut-être Excale connaît-il une astuce ?)

Pour info, vous êtes professeur dans un lycée ou plus haut ? Parce que pour le lycée, il y a déjà beaucoup de programmes disponibles pour la nspire.

C'est probablement faisable sur une Nspire jailbreakée, mais dans le cas de celles des élèves, on ne peut pas savoir si elles le sont ou non...

Sur des CX CAS normales, je ne pense pas que ce soit possible.

En résumé: non, il n'existe aucun moyen efficace d'empêcher la récupération d'un programme. Tenter d'empêcher la diffusion est une approche fondamentalement vouée à l'échec et donc inutile, si l'autre établissement est un tant soit peu motivé par la récupération du programme, comme vous semblez le craindre.
Pour maximiser les chances que votre nom reste attaché à votre programme, une possibilité est de publier le programme (sur votre propre site et avec une licence restrictive, j'imagine; ça n'interdit pas de linker le programme depuis les archives de TI-Planet, un certain nombre de nos archives pointent vers des sites externes), pour faciliter la détection de programmes avec des fonctionnalités similaires...
Je mentionne cette possibilité car elle a été utilisée par certains admins de TI-Planet confrontés à un copiste peu talentueux. Contre ces gens-là, monter la barre est la seule vraie solution: ils ne peuvent pas suivre, le bouche à oreille fonctionne... et puis tout le reste de leur mauvais comportement finit par se savoir.

Dans le détail:
* d'un côté, modifier une partie de la fonctionnalité de link est en effet réalisable grâce au code natif: nLaunchy le fait pour empêcher le transfert direct d'OS et obliger à passer par le menu de maintenance pour enlever nLaunchy, on pourrait faire un patch à l'OS pour divers autres aspects de la fonctionnalité de link;
* de l'autre côté, le menu de maintenance et le code natif offrent quantité de possibilités de contourner ou d'annuler une telle modification: restaurer la fonctionnalité de transfert en annulant les modifs, copier le contenu du fichier vers un autre endroit du système de fichiers qui ne serait pas protégé, aller dans le menu de maintenance et supprimer l'OS mais pas les fichiers pour avoir un accès sans restrictions au système de fichiers, transférer le fichier depuis la calculatrice avant d'avoir installé Ndless 3.6 sans nLaunchy (seule possibilité sur les machines disposant du boot2 3.2.4.7), et j'en passe.

Vous pouvez toujours passer du temps à obscurcir le code de votre programme ("obfuscation")... mais c'est fondamentalement un gaspillage de temps, car toute obfuscation non inutile est décodable (les obfuscations parfaites détruisent l'entrée et sont donc totalement inutiles en pratique). Le temps serait mieux utilisé à améliorer les fonctionnalités du programme, au bénéfice de vos élèves

Globalement, on est quand même dans le cas des logiciels PC propriétaires dont leur éditeurs ne veulent pas voir leur logiciel être copiée sur d'autres ordinateurs.

On voit bien que pour l'instant, à partir du moment où le logiciel fonctionne offline (ce qui est le cas sur calculatrice...), ils n'ont pour l'instant trouvé aucun moyen pour arrêter le piratage de leur logiciel. De plus le basic sur Nspire est fondamentalement open source. A partir du moment où l'utilisateur a la main sur le matériel, il est théoriquement impossible de l'arrêter.

J'ai bien une bonne poignée de techniques qui rendent la plupart des personnes incapables de transférer le programme ou voir le code source, mais je sais toutes les contourner.

En pratique, ce qui me semble le plus sûr serait d'avoir un programme Natif (donc besoin que les élèves aient Ndless) et vérifier le numéro de série de la Nspire dans le programme. Pour 99.9% des gens, il sera impossible de faire fonctionner le programme sur une autre calculatrice. Pour moi (et d'autres...), il me faudra sans doute moins de 20 minutes pour le faire marcher.

PS: Si, il existe une méthode en fait, mais elle est __vraiment__ radicale.
Il s'agit d'installer avec une version de nLaunchy (modifiée pour ne pas savoir s'updater ou updater l'OS) un OS de TI suffisement patché pour que tout type de connexion soit désactivé.
On le patche alors aussi pour qu'il refuse d'afficher le code source des variables "Lockées" par exemple (et bien sur, on désactive "Unlock").
Et surtout, on met le programme dans le dossier d'installation de l'OS.
Ainsi, il est impossible de transférer le programme, ni de voir le code source.
Le seul moyen de se débarrasser de nLaunchy sera alors de le faire via le menu de maintenance, qui supprimera tout le contenu du dossier l'installation de l'OS, et donc supprimera le programme.
Petit bémol: on peut sans doute récupérer le programme après avec un logiciel de type "récupération de fichiers effacés"
Encore plus improbable: quelqu'un pourrait trouver une faille dans l'OS qui ne nécessite pas de connexion et l'exploiter pour récupérer le contenu du programme.

Bonjour,


Les programmes sont-ils en Basic ou en Lua ?

Il est en effet possible de verrouiller le code source des programmes Lua par un mot de passe.
Cela ne répond certes pas à la demande, mais c'est peut-être une piste complémentaire à explorer.

Il est en effet possible de verrouiller le code source des programmes Lua par un mot de passe.

Facile à contourner, ça

Il y a aussi la possibilité, via la version enseignant du TI-Nspire Computer Software, de mettre le fichier en lecture seule, mais au vu des fonctionnalités assez pauvres en matière de protection des documents mises en place par TI, je suis presque sûr qu'il y a là encore moyen de contourner cela.

Lionel Debroux wrote:

Il est en effet possible de verrouiller le code source des programmes Lua par un mot de passe.

Facile à contourner, ça

Si l'on part sur cette idée, tout est contournable par un certain public.

Il s'agit de mettre des bâtons dans les roues de l'utilisateur non expert.

Quelque soit le moyen, il y a possibilité de contourner, bien sûr (un peu comme partout...), au final avec la méthode "brute", par exemple : le dump de RAM sur émulateur lorsque le document est ouvert.
Mais il est possible de rendre la tâche de celui qui veut "copier" (ou autre) un peu plus difficile en mettant le classeur en lecture seule, en remplissant les informations de Copyright du document, en mettant un password au script Lua, pourquoi pas en lockant les variables.... bref, des batons dans les roues...

Mais... probablement suffisant pour des débutants ou des gens qui ne veulent/savent pas aller bien loin.

Ca , ce sont les techniques "traditionnelles". Ensuite, il existe d'autres "trolleries" déjà bien plus poussées qui consistent par exemple à modifier soi-même la structure interne du fichier .tns afin de rendre la tache beaucoup plus ardue que d'habitude, même pour le connaisseurs (cf le post d'Excale)

Bref, est-il vraiment nécessaire d'aller si loin ?