Page 1 of 1

Raison officielle du blocage assembleur en 5.3.1

Unread postPosted: 30 Mar 2018, 20:12
by critor
Pour exécuter des programmes assembleur sur TI-83 Premium CE (et TI-84 Plus CE à l'international), on avait historiquement besoin de la commande Asm(, commande bloquée en mode examen mais devenue optionnelle avec la version 5.3.0.
En conséquence nous avions une grave faille de sécurité, avec la possibilité à l'aide de la commande Asm83CEPrgm/Asm84CEPrgm de saisir des programmes assembleur destinés à altérer le comportement du mode examen, et alors les exécuter.

Nous nous attendions donc à des changements autour de cette commande en version 5.3.1, et ce fut effectivement le cas, la commande étant désormais bloquée :
Mode examen 5.3.0
Mode examen 5.3.1

9339Mais malheureusement, les choses ne s'arrêtaient pas là. Le dernier système 5.3.1 bloque en fait la commande Asm83CEPrgm/Asm84CEPrgm même hors du mode examen. En conséquence, il est désormais impossible de créer le moindre programme assembleur sur ces calculatrices. :mj:

En réponse à coolcrab123, Texas Instruments communique enfin aujourd'hui sur cette étrange régression en fonctionnalités :
Daryl (Texas Instruments) wrote:[...]
There are classroom exams and other test scenarios where simple calculator clearing or calculator resets are used instead of test modes such as Press-to-Test. This restriction strengthens calculator security to support those exam scenarios.
While the use of the Asm84CEPrgm command is now restricted when writing programs on the stand-alone calculator, its functionality remains. Programs that are written using computer tools such as the TI Connect CE Program Editor have access to the Asm84CEPrgm command in the catalog tree. Programs that use these commands to create an Asm program can then be linked to, edited and run on the calculator.
[...]

Apparemment la commande a donc été également désactivée hors du mode examen pour améliorer la sécurité des enseignants qui n'utilisent pas le mode examen mais réinitialisent la mémoire, soit sur des calculatrices appartenant à l'école et ensuite distribuées aux élèves, soit directement sur les calculatrices des élèves (ce qui est illégal en France).

La question est pourquoi. Un élément de réponse est illustré par le programme Archive Undelete CE par Mateoconlechuga, une adaptation pour les TI-83 Premium CE et TI-84 Plus CE du programme sorti par DrDnar pour TI-83+/84 et TI-84+CSE. La mémoire d'archive n'est pas véritablement nettoyée par les menus de réinitialisation mémoire, c'est juste l'index qui est vidé et ne référence donc plus les anciens contenus. C'est pour cela que la manipulation est relativement rapide. Mais les contenus en question sont toujours physiquement présents en mémoire, et peuvent être récupérés tant que non encore écrasés par de nouvelles données.

Bref oui, en théorie, on pouvait imaginer un candidat qui, après avoir subi une réinitialisation en début d'épreuve, se mette à saisir le code d'un programme assembleur lui permettant de récupérer ses données effacées, si elles étaient en mémoire d'archive.
Mais en pratique, qui sera capable de faire ça ? Le programme Undelete CE fait par exemple 664 octets, ce qui impliquerait de retenir par cœur et saisir pas moins de 1328 caractères. Avant d'être réalisable par un être humain sans erreur et dans la durée de l'épreuve, il y a du gros travail de simplification à faire... :#roll#:

Mais comme tu le vois c'est loin d'être nouveau, c'était déjà possible sur la TI-83 Plus sortie en 1999. Tout comme avec le mode examen qui met désormais dans les 1 minute 30 à s'activer avec la version 5.3.1, nous trouvons Texas Instruments excessif dans son virage sécuritaire très soudain, avec son choix d'aller jusqu'à dégrader les fonctionnalités ou performances de son modèle phare, impactant ainsi l'ensemble de ses utilisateurs qui n'ont rien fait de mal, et cela juste pour bloquer des failles dont l'exploitation nous semble à ce jour plus qu'hypothétique. :mj:
Ce zèle très soudain viserait-il à éviter une nouvelle annulation du mode examen en France en 2019 ?... :#roll#:

On peut toutefois se demander si cette régression ne serait pas liée à une actualité récente niveau réglementation dans un autre pays. En effet comme par hasard, Casio vient tout juste lui aussi de sortir une mise à jour apportant des nouveautés dans les fonctionnalités de réinitialisation... Et les questions concernant les possibilités de simuler une réinitialisation mémoire ont pas mal fleuri dans la communauté anglophone ces derniers temps, même encore aujourd'hui comme par hasard...

Source : https://www.cemetech.net/forum/viewtopi ... 454#269454

Re: Raison officielle du blocage assembleur en 5.3.1

Unread postPosted: 31 Mar 2018, 11:33
by critor
Il devait quand même y avoir nombre d'autres moyens d'obtenir la même sécurité en bloquant cette possibilité de fraude très imaginaire (qui va se coder un archive-undelete en asm à la main en début d'épreuve, franchement ?... certainement pas le public ayant besoin de frauder), sans que les 99,99% d'utilisateurs honnêtes et non concernés ne soient impactés. :mj:

Comme rajouter une défragmentation automatique à chaque reset. Oui ça prendrait du temps, mais ce n'est visiblement de toutes façons pas ce qui les arrête donc l'objection ne me semble pas valide.

Ou encore en bloquant la commande uniquement dans l'intervalle de temps séparant un reset de la 1ère défragmentation. Auquel cas c'est sûr qu'il ne reste plus rien d'antérieur à accéder en mémoire, que ce soit avec ou sans asm.
L'utilisateur ayant subi un reset et estimant avoir besoin de l'asm, aurait donc juste eu à demander manuellement une défragmentation pour y avoir accès.

Ou encore déclencher automatiquement une défragmentation au seul 1er usage de la commande suivant un reset.

Et sûrement plein d'autres façons de faire encore. Pourquoi avoir comme par hasard choisi la pire du point de vue utilisateurs ? :#roll#:

A quoi ça sert d'avoir un modèle spécifique à la France si c'est maintenant pour lui appliquer les restrictions d'autres pays ? :mj:
(comme ce que Casio a fait en bloquant le calcul vectoriel en mode examen à partir de la version 2.09, et que nous n'avions pas manqué de dénoncer)

Re: Raison officielle du blocage assembleur en 5.3.1

Unread postPosted: 31 Mar 2018, 15:42
by Adriweb
De la défragmentation(/RàZ) systématique, ce n'est pas bien, certes pour au moins l'attente, mais ça c'est pas bien grave, mais par contre là où ça ne va pas (probablement pour ça que TI ne le fait pas), c'est que ca écrit beaucoup en flash, or on sait bien qu'il ne faut pas le faire (le moins possible, du moins), car la flash s'abime au cours des écritures...

Mais, oui, il y a des pistes d'améliorations côté Reset, puisque c'est ce que veulent/utilisent certains profs: par exemple un menu-item supplémentaire "Reset & Disable ASM", comme ça tout le monde est content et tranquille: en temps normal, rien n'est désactivé (comme en 5.3.0), mais dès que les profs font ça, ben l'ASM et les commandes liées sont désactivées jusqu'au prochain transfert par exemple (comme pour le PTT).

TI aurait pu prendre davantage de temps pour essayer de trouver une solution qui ne retire pas des fonctionnalités beaucoup trop globalement...

Re: Raison officielle du blocage assembleur en 5.3.1

Unread postPosted: 02 Apr 2018, 08:54
by puppy65
critor wrote:Il devait quand même y avoir nombre d'autres moyens d'obtenir la même sécurité en bloquant cette possibilité de fraude très imaginaire (qui va se coder un archive-undelete en asm à la main en début d'épreuve, franchement ?... certainement pas le public ayant besoin de frauder), sans que les 99,99% d'utilisateurs honnêtes et non concernés ne soient impactés. :mj:


Mieux vaut apprendre ses cours que apprendre l'Archive Undelete en code hexa 0:]

Re: Raison officielle du blocage assembleur en 5.3.1

Unread postPosted: 08 Apr 2018, 09:26
by critor
Une vidéo vient de sortir à ce sujet :

Re: Raison officielle du blocage assembleur en 5.3.1

Unread postPosted: 08 Apr 2018, 13:50
by critor
Par contre, pas du tout d'accord avec le fait que pour obtenir quelque chose de TI il faudrait rendre service à TI en faisant bénévolement la promotion de cette saleté inégalitaire de mode examen. :mj:
La preuve que le "donnant-donnant" ne marche pas est justement sous nos yeux.

Re: Raison officielle du blocage assembleur en 5.3.1

Unread postPosted: 08 Apr 2018, 13:54
by Adriweb
En absolu, en effet.
Mais la c'etait "par principe" en reponse specifique a la raison donnee par TI de "certains profs utilisent un reset au lieu du PTT". En gros, s'ils utilisaient tous le PTT, on n'aurait pas eu ce blocage :/

Re: Raison officielle du blocage assembleur en 5.3.1

Unread postPosted: 08 Apr 2018, 13:58
by critor
En passant, qui a fait de la rétention d'informations sur les failles ?
(critique à 0:40)

Il me semble que le principe en est correctement expliqué chez nous (cela relève de la simple information) et certes qu'il n'y a pas à en dire/faire plus (car au-delà on passe à mon sens dans l'aide à l'exploitation), mais j'aurais eu du mal à cacher des choses vu que l'on ne m'a rien demandé.

Re: Raison officielle du blocage assembleur en 5.3.1

Unread postPosted: 08 Apr 2018, 13:59
by Adriweb
Oui je pense qu'il a du demander à avoir le PoC, par exemple :P

Re: Raison officielle du blocage assembleur en 5.3.1

Unread postPosted: 08 Apr 2018, 14:01
by critor
Ah, le code asm hexa qui désactive le mode examen sans éteindre la diode... ;)
Il peut courir pour l'avoir en effet. :p