by - le boot1, gravé lors de la fabrication, et à priori non modifiable (une seule version pour le moment à ma connaissance: 1.1.8916)
- le boot2, modifiable - les premiers modèles étaient fournis avec la version 1.1.8981, et les mises-à-jour avec systèmes 1.4 et supérieurs incluent la version 1.4.1571.
Tout ce qui suit aurait été découvert et expliqué bien plus tôt, si TI avait pris l'habitude d'appeller un chat, un chat.
Les fichiers de mise-à-jour TNO/TNC n'ont rien à voir avec leurs prédécesseurs sur z80/68k.
Car ce sont en fait des archives!!!
Ils peuvent être ouverts avec WinRAR par exemple, qui détecte un format ZIP-SFX.
Qu'y a-t-il dedans?
- TI-Nspire.img: il s'agit d'une autre archive (archive dans l'archive) - le format détecté est encore ZIP-SFX, mais il a du être quelque peu altéré par TI, car certains fichiers échouent à la décompression, et de plus ce ne sont pas les même selon les versions du fichiers... ces échecs semblent réguliers, comme si TI avait rajouté périodiquement une somme de contrôle... cette archive contient les dossiers:
- documents
- phoenix: le système d'exploitation, peut-être crypté...
- ti84: uniquement si c'est une mise-à-jour TNO - contient une image ROM brute (non cryptée, non compressée) de la TI-84, sous forme de fichiers numérotés (un par page ROM) - il suffit de les concaténer pour obtenir une image ROM complète
[*]boot2.img: uniquement si c'est une mise-à-jour en système 1.4 ou supérieur - c'est le code du Boot2 en version 1.4.1571, mais compressé de façon non standard (au moins il n'est pas crypté)
[*]boot2.cer: uniquement si c'est une mise-à-jour en système 1.4 ou supérieur - sûrement la clef 1024bits, signant le fichier ci-dessus, et interdisant donc de transférer ou d'installer un boot2 modifié
[*]samples.zip: uniquement si c'est une mise-à-jour en système 1.4 ou supérieur
Intéressons-nous donc au code du fichier boot2.img.
Personne n'y avait reconnu de l'assembleur ARM, car il était compressé.
Il faut donc trouver le format de compression (non standard) utilisé par TI.
Et c'est chose faite.
- 4 premiers octets: taille non compressée
- 128 octets suivants: table des 64 combinaisons de 2 octets les plus fréquentes
- les données présentées de façon récurrente ainsi:
- 1 bit à l'état 1, suivi de 16 bits de données (2 octets)
ou bien - 1 bit à l'état 0, suivi de 6 bits indiquant l'index dans la table de début de fichier
Y'a plus qu'à faire un décompresseur en C pour lire le code assembleur ARM.
Nous pourrons peut-être mieux comprendre pourquoi il y a deux boot sur nSpire (que fait le boot1? que fait le boot2?), et peut-être à terme faire bouffer à la calculette un boot2.img modifié contenant notre propre code assembleur.
(ça devrait être à priori plus facile dans un premier temps, que de tenter une modification du TI-NSpire.img...)
