En théorie tout est possible. En pratique il faut coder, et il faut que l'altération ne présente pas d'inconvénient trop lourd à l'utilisation
(et ce n'est pas évident car la sécurité du système fait des vérifications, et avec pas mal de redondance sur TI-Nspire).
Mais je ne vois pas trop ce que ControlX pourrait faire sur tes fichiers; ControlX est exécuté au niveau du Boot1 et dans ce contexte il n'y a aucun accès au système de fichiers. Le pilote Flash n'est même pas encore chargé à ce moment-là.
Il y aurait l'alternative de patcher l'OS à l'exécution afin d'altérer le fonctionnement du mode examen, mais bon courage déjà pour décrypter l'OS, puis pour rechercher dans plus de 10 méga-octets de code les bons octets à modifier et avec les bonnes valeurs. Extrêmement difficile, je voudrais moi-même le faire que j'en serais totalement incapable.
C'est différent si tu utilises les chargeurs de démarrage nLaunch/nLoader par contre, ces derniers étant exécutés au niveau du Boot2, et donc avec accès au système de fichiers. Même si je ne vois toujours pas trop ce que tu peux faire avec ça.
Dans les deux cas, l'exécution de code dans le contexte du Boot1/Boot2 subit nombre de contraintes; ce n'est pas comme avec Ndless sous l'OS. Selon comment tu écris ton code, il pourra très facilement être instable ou même planter, alors que parfaitement valide dans un autre contexte. Franchement, je dirais qu'il y en a au minimum pour des semaines de travail à temps plein
(code + tests) avant d'arriver à un exploit réellement
utilisable, et encore pour quelqu'un qui connaît le fonctionnement du mode examen Nspire, comprend toutes les conséquences logicielles/fonctionnelles/techniques induites par ses altérations, et maîtrise les contraintes du développement dans un contexte Boot; pas sûr que ça en vaille la peine. Autant apprendre tes formules qui de toutes façons sont rappelées dans les énoncés de BAC, ça te prendra moins de temps.
![;) ;)](./images/smilies/wink.png)