Avertissement NumWorks: attention aux diodes qui s'éteignent

[critor]

Nous l'évoquions dans un article précédent dans le cadre du protocole mode examen défectueux publié par l'académie d'Aix-Marseille, certains menus de tests présents sur nos calculatrices permettent, lorsque accessibles en mode examen, d'éteindre la diode. Il y a ainsi en théorie moyen à frauder :

1. activer le mode examen chez soi
2. rentrer toutes les données de son choix
3. éteindre la diode avec le menu concerné
4. tromper ainsi le surveillant sur l'état du mode examen et pénétrer en salle d'examen avec toutes ses données
5. sortir du menu en question pour rallumer la diode lorsque le surveillant demandera d'activer le mode examen, le trompant donc de nouveau en lui faisant croire que le contenu mémoire éventuel vient d'être effacé ou verrouillé

Une bonne partie des modèles commercialisés cette année sont concernés, et la

NumWorks

ne fait pas exception. Taper

6

après s'être positionné sur son champ

FCCID

permet de lancer l'outil de diagnostic, et ce même en mode examen.

Il suffit ensuite de passer les tests jusqu'à celui de la diode, et voilà la diode cesse de clignoter alors que l'on est toujours en mode examen.

En pratique toutefois cette astuce est totalement inutile pour frauder avec la

NumWorks

, car sortir de cet outil pour remettre la calculatrice en fonctionnement normal nécessite d'enfoncer le bouton

reset

au dos, bouton qui justement efface l'intégralité du contenu mémoire.

Mais cela indiquerait surtout que l'état de la diode ne semble pas verrouillé chez

NumWorks

et peut être altéré par l'exécution de n'importe quel code, l'application du changement ne nécessitant apparemment pas de redémarrage et donc de droits d'accès privilégiés.

Bien évidemment, aucun candidat ne va donc rentrer en examen dans ce menu totalement inutile.

Mais pourtant problème, nous avons reçu depuis hier plusieurs signalements de graves incidents avec les calculatrices

NumWorks

pendant la première épreuve de spécialité du

BAC 2022

en Métropole :

• un signalement par
  annales2maths
  , enseignant avec qui nous travaillons depuis des années : concernant une calculatrice
  NumWorks
  en version
  16.4
• un signalement par un enseignant de surveillance présent sur le
  discord Omega
  : concernant une calculatrice
  NumWorks N0110
  en version
  17.2

Dans les deux cas la diode a soudainement cessé de clignoter en cours d'épreuve, et ne voulait absolument plus se rallumer malgré la tentative de toute une série de manipulations simples.

Dans les deux cas également la calculatrice était toujours en mode examen, c'est vérifiable au drapeau en forme de chapeau de diplômé universitaire américain, présent en permanence dans la barre de titre dans ce mode.

Le dernier enseignant qui compte pour sa part parmi les surveillants bienveillants, a mis à jour la calculatrice du candidat concerné en version

18

et la diode a alors bien voulu recommencer à clignoter ; la diode n'était ainsi pas grillée et ce n'était donc pas une panne matérielle.

Il semble que ce soit totalement involontaire : c'est un enchaînement de manipulations non intentionnelles de la part du candidat, ou encore un événement logiciel ou matériel interne, qui interrompt le clignotement.

Ce comportement de la calculatrice est une violation des spécifications du mode examen qui exigent un signal permanent et régulier sur une diode, signal qui doit être impossible à désactiver, altérer ou falsifier par le candidat.

Si tu rencontres ce cas sur une

NumWorks

, vérifie donc bien la présence du drapeau mode examen dans la barre de titre. Si bel et bien présent le candidat n'a strictement rien fait de mal, ce n'est pas de sa faute, et il ne doit donc surtout pas être inquiété avec un procès verbal de suspicion de fraude !

Que tu sois candidat ou surveillant, si tu rencontres le cas, merci de nous remonter le signalement avec un maximum d'informations afin que le constructeur puisse comprendre et corriger le problème au plus tôt :

• type de la machine :
  N0100
  ou
  N0110
• firmware
  que fait tourner la machine :
  Epsilon
  ,
  Upsilon
  ,
  Omega
  ,
  Khi
  , ...
• version du
  firmware
  en question
• numéro de série de la machine
• quelles étaient les manipulations du candidat juste avant le déclenchement de l'incident

Il est à noter que les calculatrices concernées en version

16.4

et

17.2

ne faisaient donc pas tourner de

firmware

tiers mais bel et bien le

firmware

officiel

Epsilon

. En effet elles étaient forcément verrouillées puisque la version était supérieure à

16

, et si un

firmware

tiers avait été installé avec un

dualboot

alors

Epsilon

aurait forcément été en version

18.2.0

ou

18.2.3

.

Mais la version

18

étant une évolution de ces versions et les

firmwares

tiers étant eux-mêmes des

forks

du

firmware

officiel

Epsilon

, a priori rien n'empêche que le problème y soit également présent et donc généralisé.

[critor]

Par rapport à l'outil de tests qui permet de falsifier l'état de la diode en mode examen, c'est signalé et en cours de correction pour la prochaine mise à jour :
https://github.com/numworks/epsilon/pull/1951

Mais les candidats concernés ne sont probablement pas allés là-dedans, il y a bel et bien un autre problème, sans doute plus profond...

[critor]

Précision sur les manipulations tentées par le 2ème enseignant concerné.

Il a utilisé le menu permettant de réinitialiser/revalider le mode examen des calculatrices qui sont déjà en mode examen :


Cela a permis de relancer le clignotement de la diode dans un premier temps.
Mais après environ 10 minutes, la diode s'est à nouveau éteinte. C'est là qu'il a mis à jour vers la dernière version 18, et le problème n'est plus revenu pour la suite de l'épreuve.

Après, un exemple ne prouve rien, surtout pour un bug dont le déclenchement semble à ce jour aléatoire.
Peut-être qu'une mise à jour en version 18 supprime le problème, ou pas et que c'était juste de la chance.

[parisse]

Je ne comprends pas la reaction du surveillant. Mettre a jour a chaud pendant un examen une calculatrice (qui plus est vers une version potentiellement plus difficile a deverrouiller), c'est la derniere des choses a faire je trouve. A partir du moment ou il etait evident qu'il n'y a pas eu de tentative de fraude, il aurait du laisser composer avec la calculatrice qui ne clignote plus (ou eventuellement proposer a l'eleve un echange avec sa propre calculatrice Numworks si l'eleve n'avait pas encore entre de donnees).

[critor]

Je n'aurais pas osé, en tous cas pas sans que le candidat prenne l'initiative de la demande. Mais le surveillant a pu supposer que la nouvelle version fonctionnerait mieux. Et cela semble avoir été le cas, même si ce serait à confirmer.

[parisse]

J'ai plutot l'impression que c'est une defaillance materielle qui intervient au bout d'un temps aleatoire. En tout cas mettre a jour l'OS (avec potentiellement des variations de l'UI) en plein examen, c'est vraiment a proscrire!

[critor]

Quelques tests rapides, et déjà une première piste.

Quand la calculatrice est occupée en mode examen dans des opérations lourdes/longues

(scripts

Python

par exemple mais pas que, graphes, calcul de sommes/produits, ...)

, la diode de la

NumWorks

peut se mettre à clignoter de façon extrêmement rapide.
J'avais déjà remarqué et signalé ça il me semble dès la sortie du modèle.

Se pourrait-il que ce soit lié ?
Que l'accélération extrême puisse finir par rendre les flash du clignotement invisibles ? Ou encore puisse bloquer ou faire planter le processus gérant le clignotement ?

Si j'avais su que ça pouvait mener à ça, j'aurais insisté...

En v18 ça affiche un drapeau occupé en barre de titre, donc il se pourrait justement que cet état soit géré différemment et ne déclenche en conséquence pas le problème.

[Yaya.Cout]

Ce serait possible que ce soit la vitesse, car le clignotement est géré par le PWM (https://github.com/UpsilonNumworks/Upsi ... d.cpp#L116)

[parisse]

Je n'ai pas l'impression qu'il y ait un process qui controle le clignotement de la diode, en fait il me semble que l'OS de la Numworks a un seul process. Mon impression est que le clignotement est plutot lie au hardware de la LED, et presente effectivement des variations de vitesse dans certaines conditions (processeur a 100% par exemple sur un long calcul, ou bien lorsqu'on est branche sur USB).

[ceut]

C'est super bizarre ce bug.
Je viens de vérifier électroniquement sur le schéma fourni par Numworks: la led rouge est cablée via un mosfet sur le pin PB4 qui est bien programmé en PWM sur le CH1 du TIM3.
Dans le Datasheet du STM32F730 (pris sur le site de Numworks),

" The TIM3 and TIM4 timers are based on a

16-bit auto-reload up/downcounter and a 16-bit prescaler.

They all feature 4 independent channels for input capture/output compare,

PWM

or one-pulse mode output. "

Ce qui veut dire qu'une fois la valeur du PWM du TIM3 paramétré: la led est indépendante du software, et pas besoin de processus pour ça

Sauf si il y a ré-écriture dans le registre concerné, cela provoquerait forcément des aléas d'éclairage en cours de route (reset du PWM etc..) , donc ces bugs

(En passant, les 3 leds sont cablés sur ce même TIM3, mais sur des sous-canaux).


Edit: Autre interrogation: Je ne sais pas si la led rouge s'allume lorsque la batterie atteint un certain seuil ?
Si c'est le cas il pourrait y avoir un conflit entre l'écriture de la led rouge fixe pour la batterie, et clignotant pour le mode examen.