./264 : tiens, salut roms.

Lionel Debroux (./265) :
Personne n'aurait trouvé sur la Nspire l'équivalent de la table des ROM_CALLs des TI-68k, des fois ?

Non, il faudra revenir à la mode 92 et ses constantes.

critor (./261) :
Faut-il avoir conservé le boot2 1.1, ou ça n'intervient pas?

Non c'est indépendant. Ca me fait penser qu'on va pouvoir dumper cette version de boot maintenant, tant qu'il y en a dans la nature.

Un peu plus sur ces problématiques de downgrade et ce que j'ai en tête :

- Sur l'OS 1.7, deux des failles requises sont colmatées. Et même si ça n'était pas le cas ça le serait un jour sur les futures 1.8, 1.9, etc. Donc se baser sur des vieilles failles inévitable.
Il n'y a aujourd'hui pas de protection contre le downgrade dans le boot et l'OS. Le boot 2 permet de supprimer l'OS, et ne conserve pas la version du dernier OS installé. C'est un comportement qu'ils pourront modifier, mais tant qu'on garde le contrôle de l'exécution sur la version précédente du boot et de l'OS, il est possible d'injecter du code dans la version suivante, donc ce n'est pas un vrai problème, ça rend les choses plus délicates.

- Je prévoie d'intégrer à l'installeur un patch du boot 2 pour charger juste avant l'exécution de l'OS du code externe issu d'un fichier. Ce code pourra éventuellement appliquer des patches à l'OS en RAM avant son chargement (hook, désactivation de validation de signature d'OS (mais lui aussi à appliquer sur le boot 2), ...). Un kernel pourra être ensuite facilement construit là dessus (qui lui s'occupera du chargement de code, relogement et autres fantaisies que l'on maîtrise bien). Cette méthode permet de garder le contrôle tout en rendant possible la montée d'OS.
Le risque est que toute corruption du boot 2 requière un adaptateur RS232 et un peu de soudure pour le reflasher, mais on n'en est pas au premier hack risqué.