Version 16 bêta : verrouillage NumWorks anti Omega / KhiCAS

→ **MyCalcs** profile · by **parisse** » 28 Jul 2021, 07:24

1/ J'ai un connectivity kit integre a Xcas, qui utilise dfu-util, mais personne ne l'a teste pour le moment (sauf moi sur mon mac). Il ne gere pas le recovery et il vaudrait de toutes facons mieux avoir un client autonome.
2/ je ne comprends pas bien comment fonctionne le recovery. Si je fais 6+reset, je ne peux pas envoyer vers 0x90000000, par contre je peux envoyer vers 0x80000000. On peut certainement envoyer vers la ram aussi, mais comment executer le code correspondant?

→ **MyCalcs** profile · by **redgl0w** » 28 Jul 2021, 07:42

parisse wrote:1/ J'ai un connectivity kit integre a Xcas, qui utilise dfu-util, mais personne ne l'a teste pour le moment (sauf moi sur mon mac). Il ne gere pas le recovery et il vaudrait de toutes facons mieux avoir un client autonome.
2/ je ne comprends pas bien comment fonctionne le recovery. Si je fais 6+reset, je ne peux pas envoyer vers 0x90000000, par contre je peux envoyer vers 0x80000000. On peut certainement envoyer vers la ram aussi, mais comment executer le code correspondant?

1/ Le connectivity kit permet quoi précisément ? (upload des firmwares, et parse le storage ?)
2/ Lorsqu'on utilise le bootloader DFU des STM32 (accédé lorsqu'on appui sur 6+reset), seul la flash interne et la RAM sont accessibles. Comme la flash externe n'est pas accessible, numworks a écrit dans epsilon un petit flasher situé en RAM pour écrire interne et externe (et car le code était déjà fait). Si je ne me trompe pas, il y a un paramètre dans dfu-util pour exit DFU à une certaine adresse, permettant de jump
le leave sur epsilon (et où / comment il est call)
Voilà aussi comment le dfu d'epsilon exit à une addresse
Sans avoir testé, c'est peut être

Code: Select all: :leave

le paramètre dfu-util pour sortir à une adresse

→ **MyCalcs** profile · by **critor** » 28 Jul 2021, 07:44

Mince, j'avais zappé quelque chose... leur gestion d'application c'est encore plus grave que ce que je pensais :
viewtopic.php?f=97&t=25012&p=262438#p262438

→ **MyCalcs** profile · by **parisse** » 28 Jul 2021, 08:13

redgl0w wrote:1/ Le connectivity kit permet quoi précisément ? (upload des firmwares, et parse le storage ?)

Le CK Numworks de Xcas permet de charger un script de la Numworks dans un niveau de programme Xcas ou on peut l'executer avec l'interpreteur MicroPython de Xcas (qui est identique a celui utilise par KhiCAS, donc avec les memes modules), il permet aussi de charger une session KhiCAS de la Numworks vers Xcas. Il fonctionne aussi dans l'autre sens mais il y a des restrictions, on ne peut pas faire sur la Numworks tout ce qu'on peut faire dans Xcas.
On peut aussi installer Delta+KhiCAS depuis Xcas, et certifier que le firmware installe sur la Numworks est bien Delta+KhiCAS, pour eviter des fraudes en mode examen.
C'est aussi possible depuis la version web de Xcas.

2/ Lorsqu'on utilise le bootloader DFU des STM32 (accédé lorsqu'on appui sur 6+reset), seul la flash interne et la RAM sont accessibles. Comme la flash externe n'est pas accessible, numworks a écrit dans epsilon un petit flasher situé en RAM pour écrire interne et externe (et car le code était déjà fait). Si je ne me trompe pas, il y a un paramètre dans dfu-util pour exit DFU à une certaine adresse, permettant de jump

En effet, leave permet de sauter a l'adresse d'apres la doc de dfu-util. Du coup, c'est bien la ram qu'il faut envoyer. En fait il faut probablement envoyer les deux: flash interne et ram.

→ **MyCalcs** profile · by **redgl0w** » 28 Jul 2021, 09:54

parisse wrote:En effet, leave permet de sauter a l'adresse d'apres la doc de dfu-util. Du coup, c'est bien la ram qu'il faut envoyer. En fait il faut probablement envoyer les deux: flash interne et ram.

Euhm
Normalement (mais faudrait que je re teste), flasher le flasher en ram suffit, et il faut jute après flash external puis internal, puis leave sur internal

→ **MyCalcs** profile · by **parisse** » 28 Jul 2021, 10:19

J'ai recupere la RAM dans les 2 situations, connection DFU normale, connection DFU en mode recovery.

Code: Select all: dfu-util -i 0 -a 0 -s 0x20038000:0x8000:force -U recovery.ram

et (apres 6+reset et recovery partiel depuis le site Numworks jusqu'a voir apparaitre RECOVERY MODE sur la calc)

Code: Select all: dfu-util -i 0 -a 0 -s 0x20032000:0xe000:force -U recovery.ram32000

J'ai mis les 2 fichiers dans https://www-fourier.univ-grenoble-alpes.fr/~parisse/numworks/. On a bien la chaine "RECOVERY MODE" dans recovery.ram32000.
Mais ensuite, je n'arrive pas a relancer le dfu RECOVERY MODE depuis 6+reset.
Si j'essaie d'envoyer le DFU normal

Code: Select all: dfu-util -i 0 -a 0 -s 0x20038000:force:leave -D recovery.ram

on voit l'ecran des apps avant l'ecran de connection donc ca reboote surement.
Si j'essaie d'envoyer le DFU RECOVERY MODE, c'est pareil.

Code: Select all: dfu-util -i 0 -a 0 -s 0x20032000:force:leave -D recovery.ram32000

→ **MyCalcs** profile · by **redgl0w** » 28 Jul 2021, 10:22

parisse wrote:J'ai recupere la RAM dans les 2 situations, connection DFU normale, connection DFU en mode recovery.
Code: Select all
dfu-util -i 0 -a 0 -s 0x20038000:0x8000:force -U recovery.ram

et
Code: Select all
dfu-util -i 0 -a 0 -s 0x20032000:0xe000:force -U recovery.ram32000

J'ai mis les 2 fichiers dans https://www-fourier.univ-grenoble-alpes.fr/~parisse/numworks/. On a bien la chaine "RECOVERY MODE" dans recovery.ram32000.
Mais ensuite, je n'arrive pas a relancer le dfu RECOVERY MODE depuis 6+reset.
Si j'essaie d'envoyer le DFU normal
Code: Select all
dfu-util -i 0 -a 0 -s 0x20038000:force:leave -D recovery.ram

on voit l'ecran des apps avant l'ecran de connection donc ca reboote surement.
Si j'essaie d'envoyer le DFU RECOVERY MODE, c'est pareil.
Code: Select all
dfu-util -i 0 -a 0 -s 0x20032000:force:leave -D recovery.ram32000

Je sais pas précisément d'où tu as dump le recovery, mais souvent, republier des binaires que tu n'as pas compilés toi même est une plutôt mauvaise idée. Le flasher verbose / flasher light est dans epsilon et il vaudrait mieux que tu le compiles toi même du coup.
Pour la partie flash du flasher, je teste ça quand je suis rentré chez moi...

→ **MyCalcs** profile · by **parisse** » 28 Jul 2021, 10:34

J'ai recupere les binaires directement depuis ma calculatrice, comme indique, avec les commandes dfu-util. Il n'y a pas de raison que ca ne fonctionne pas dans le cas du recovery mode au moins. Le seul truc pas clair, c'est quel point d'entree doit etre utilise lorsqu'on fait la commande dfu leave, il faut qu'on appelle bien ion_main de flasher/main.cpp

→ **MyCalcs** profile · by **parisse** » 28 Jul 2021, 10:55

Bon, je pense que j'ai trouve. Il suffit de faire

Code: Select all: make flash.verbose.bin

ca cree un fichier de flash binaire a charger a l'adresse 0x20030000 (et pas 0x20032000, mon approche etait donc bonne mais ca plantait a cause de la mauvaise adresse) avec la commande

Code: Select all: dfu-util -i0 -a0 -s 0x20030000:force:leave -D flasher.verbose.bin

J'ai mis le fichier dans mon repertoire numworks: https://www-fourier.univ-grenoble-alpes.fr/~parisse/numworks/flasher.verbose.bin
Ca devrait me permettre d'avoir un mode de recuperation dans Xcas pour les Numworks qui ne sont jamais passees en Epsilon>=16. Mais pour les versions >=16 d'Epsilon (y compris beta), ca risque de ne pas marcher, parce qu'il doit y avoir des protections dans l'ecriture en RAM.

→ **MyCalcs** profile · by **redgl0w** » 28 Jul 2021, 11:19

parisse wrote:Bon, je pense que j'ai trouve. Il suffit de faire
Code: Select all
make flash.verbose.bin

C'est de ça dont je voulais parler
Il vaut mieux diffuser un binaire d'epsilon que tu as compilé toi même, qu'un que tu as récupéré grâce au site de NumWorks

parisse wrote:ca cree un fichier de flash binaire a charger a l'adresse 0x20030000 (et pas 0x20032000, mon approche etait donc bonne mais ca plantait a cause de la mauvaise adresse) avec la commande
Code: Select all
dfu-util -i0 -a0 -s 0x20030000:force:leave -D flasher.verbose.bin

Ah, j'avais calculé à l'époque, et ma valeur était la bonne (pour le recovery d'omega). J'aurais du le refaire à nouveau, ou regarder les sources de numworks.js (et pas croire à la valeur en commentaire du linker script).

parisse wrote:Mais pour les versions >=16 d'Epsilon (y compris beta), ca risque de ne pas marcher, parce qu'il doit y avoir des protections dans l'ecriture en RAM.

Le stack USB de la beta a maintenant une gestion des alternates modes USB, et possède maintenant différentes interfaces. N'ayant pas les sources, c'est difficile de savoir précisément les changements fait.
Le kernel doit utiliser de la RAM (tout comme sûrement le bl), et donc j'imagine que le stack DFU d'epsilon 16 gère ça afin d'éviter qu'on puisse rewrite cette ram, ou même le heap (pour éviter de ROP). Comme le kernel (qui possède le stack DFU) s'execute en supervisor, c'est la seule solution sécurisé j'imagine.