Pour ceux qui n'ont pas lu le début de ce topic, peu après l'installation de l'OS 2.0.0, la calculatrice de Mic s'est auto-détruite...
Le boot2 a été corrompu pendant que la calculatrice était éteinte.
Au rallumage, la calculatrice coincée dans le boot1 est totalement inutilisable car ce dernier ne gère pas la prise USB.
La calculatrice ainsi endommagée ne peut plus avoir que 3 destinations:
- Le retour chez TI si elle est encore sous garantie...
- La poubelle
- Le labo de Critor pour une dernière séance de torture
Curieusement, un nombre anormalement élevé de calculatrices avec un boot2 ou OS corrompu a été signalé cette année sur TI-Bank ou Univers-TI-Nspire. Et à chaque fois, le dernier OS installé était le 2.0...
Récemment, TI a sorti l'OS 2.1 qui contient une protection anti-downgrade. Voir
cette news.
Le boot2 inclus dans l'OS est identique à celui des anciens OS, mais plusieurs personnes m'avaient suggéré que cet OS pouvait peut-être patcher le boot2 pendant son exécution sur la calculatrice.
La protection a finalement été comprise, et est dans le même style d'idée.
La zone du boot2 réserve dans la mémoire de la Nspire les pages 0020 à 0AFF.
Mais en pratique, seules les premières pages sont occupées.
La protection de l'OS 2.1 inscrit dès l'installation une valeur dans la page 0A80 (page libre), valeur qui interdit alors les downgrades.
Commencez-vous à voir où je peux en venir?
Si la vérification du boot2 par le boot1 inclut la page 0A80 et que la valeur inscrite est erronée (bug?), le boot1 refuse de lancer le boot2 (considéré comme corrompu) et on se retrouve dans la configuration de Mic.
Et si la protection de l'OS 2.1 était déjà présente à l'état de prototype dans l'OS 2.0, à des fins de test ?
(inscrivant par exemple une valeur anodine ne bloquant pas le downgrade...)Pourquoi pas si TI a voulu tester sa protection en nous prenant comme cobayes...
Le déclenchement de l'écriture pouvait être aléatoire éventuellement.
Un prototype comportant souvent des bugs, l'écriture d'une mauvaise valeur (ou au mauvais endroit) a alors corrompu le boot2 de Mic...
On peut même imaginer dans le pire des cas, que l'écriture de valeurs erronées ou au mauvais endroit ait été prévue par TI
(déclenchement aléatoire encore pour ne pas casser toutes les Nspire au monde), pour tester les conséquences des défauts/failles de sa protection.
Une autre raison pourrait être une destruction volontaire du boot2 après déclenchement de la protection-prototype, afin qu'on leur renvoie la calculatrice, et dans ce cas ils ont du être bien contents de recevoir celle de Mic pour analyser si la protection-prototype avait bien écrit ce qu'il fallait...
Peut-être que j'exagère sur ce dernier point, mais le précédent ne m'a pas l'air si fantaisiste que ça.
Mic, tu es le premier concerné... Cela te paraît cohérent?
Qu'en pensez-vous?
by jacques » 09 Apr 2010, 17:27 
