Dump partiel (boot2)

→ **MyCalcs** profile · by **Armael** » 12 Dec 2009, 11:06

Salut,
je me demandais si je pouvais être utile à quelque chose, car je vais acheter une nSpire CAS dans pas longtemps, et qu'un tel travail de décompilation ... m'intéresse pas mal

.

Mes programmes · by **Levak** » 12 Dec 2009, 13:51

Armael wrote:Salut,
je me demandais si je pouvais être utile à quelque chose, car je vais acheter une nSpire CAS dans pas longtemps, et qu'un tel travail de décompilation ... m'intéresse pas mal .

Salut,
Tu sais, tout effort, qu'il soit petit ou grand, est déjà une énorme avancée, un énorme +. Il faut savoir que l'on n'est qu'au début (comparé aux autres caltoches) de la découverte de la TI-nSpire, donc TOUT est bon à prendre ^^

Bonne chance

→ **MyCalcs** profile · by **Armael** » 13 Dec 2009, 15:47

Tiens, je me posais quelques questions, sous forme d'affirmations

, de ce que je crois avoir compris, ou non :

- Le boot 1 est inscrit en dur dans une puce de la TI. On ne le connaît pas, et on suppose qu'il vérifie le boot 2 (mais dans quelle mesure ?) puis le charge et le démarre.
- Le boot 2 est inclus dans les mises à jour (ça j'en suis sûr), il sert à charger l'OS, et le vérifie (?) .
- L'OS est il à la suite de l'archive des mises à jour, écrit en brut à la fin, comme il en avait été question un moment ? Si oui, où commence t'il ?

- C'est quoi qui est crypté par les clefs 1024 bits ? Où sont elles et à quoi servent elles ?
- Comment fait l'émulateur nSpire pour émuler le boot 1 , puisque on ne le connait pas ? Et donc, se pourrait il qu'un boot 2 modifié soit accepté par l'émulateur, mais pas par la TI, celle ci faisant dans son boot 1 des vérifications que l'émulateur ne fait pas ?

- Enfin, on ne sait pas «reconstruire» l'archive des mises à jour après en avoir modifié un élément ?

→ **MyCalcs** profile · by **critor** » 13 Dec 2009, 15:57

Armael wrote:Tiens, je me posais quelques questions, sous forme d'affirmations
, de ce que je crois avoir compris, ou non :

- Le boot 1 est inscrit en dur dans une puce de la TI. On ne le connaît pas, et on suppose qu'il vérifie le boot 2 (mais dans quelle mesure ?) puis le charge et le démarre.

Le Boot1 est inscrit dans la même puce que le Boot2 et que l'OS (la ROM en gros).
Simplement il s'agit d'une zone protégée de la puce (au début ou à la fin de la mémoire ROM).

Armael wrote:- Le boot 2 est inclus dans les mises à jour (ça j'en suis sûr), il sert à charger l'OS, et le vérifie (?) .

Oui

Armael wrote:- L'OS est il à la suite de l'archive des mises à jour, écrit en brut à la fin, comme il en avait été question un moment ? Si oui, où commence t'il ?

Cela dépend de quelle archive tu parles...
L'OS est dans le fichier nspire.img (qui est une archive "spéciale") qui est inclut dans les archives de mise-à-jour.

Armael wrote:- C'est quoi qui est crypté par les clefs 1024 bits ? Où sont elles et à quoi servent elles ?

L'OS n'est pas crypté.
Les clefs "cryptent" la signature de l'OS (qui permet de vérifier qu'il n'est pas modifié notamment).

Armael wrote:- Comment fait l'émulateur nSpire pour émuler le boot 1 , puisque on ne le connait pas ?

Justement, on ne le connaît pas...
Car il faudrait ou arriver à exécuter de l'assembleur sur la nSpire pour le lire, ou dessouder la superbe puce Zevio, et la brancher sur un programmeur de puces adéquat pour en lire le contenu...
(je ne sais même pas si il existe des programmeurs de puces de cette forme, ailleurs que dans les chaînes de montage de nSpire...)

L'émulateur n'avait au départ pas de Boot1.
Apparemment, cela ne posait pas de problème, sauf pour le système 1.1 non CASqui ne démarrait pas.

Pour corriger ce problème, du code très basique a été mis dans la zone Boot1, mais ça ne fait pas grand chose.

Armael wrote:Et donc, se pourrait il qu'un boot 2 modifié soit accepté par l'émulateur, mais pas par la TI, celle ci faisant dans son boot 1 des vérifications que l'émulateur ne fait pas ?

Parfaitement.
L'émulateur n'a pas de Boot1.
Donc il n'y a pas de vérification du Boot2.
Donc on peut exécuter n'importe quoi à la place du Boot2.

Cela a déjà été fait justement.

Armael wrote:- Enfin, on ne sait pas «reconstruire» l'archive des mises à jour après en avoir modifié un élément ?

La reconstruire si... c'est possible.
Mais avec les signatures pour pouvoir la faire accepter par une vraie nSpire, non.

→ **MyCalcs** profile · by **Armael** » 13 Dec 2009, 16:35

Merci pour ces réponses.
Sinon, j'ai un autre problème :
j'ai récupéré le fichier .tnc, je l'ai extrait (au passage, unzip m'informe qu'il y a «warning [TI-Nspire.tnc]: 63 extra bytes at beginning or within zipfile» ) .
Dedans il y a donc bien les fichiers boot2.img, boot2.cer, TI-Nspire.cer , TI-Nspire.img et samples.zip, qui contient visiblement les traductions.
Comme dit plus tôt, je vire le début du boot2.img avec mon éditeur hexa (ghex sous Linux).
Cependant, je ne vois aucune trace des chaines de caractères... :/

Sinon, le fichier TI-Nspire.img contient le code de l'OS directement ? Il suffit de le décompiler ?
Qu'en est-il des octets fantômes à la fin du fichier tnc, non accessibles par extraction, dont il était question plus tôt dans le topic ?

Serait il utile de faire un programme qui scanne le fichier tnc, et qui détecte tout ce qui ne correspond pas à la norme zip, à savoir headers, et code supplémentaire issu de TI ?

EDIT : les 63 octets contiennent : "TI-Nspire.tnc 1.7.2741 7711867 0
__RES__ 1.7.2741 0 2026409" qui sont donc des infos TI ajoutées au début....

→ **MyCalcs** profile · by **geogeo** » 13 Dec 2009, 17:30

> Le Boot1 est inscrit dans la même puce que le Boot2 et que l'OS (la ROM en gros).
Simplement il s'agit d'une zone protégée de la puce (au début ou à la fin de la mémoire ROM).

J'aimerai savoir d'où tu sors cette information ? Pour moi le boot1 est dans la 512KB NOR FLASH en lecture seule et le boot2 dans la 32MB FLASH NAND copiée en RAM par le boot 1 ! D'ailleur si tu regardes bien l'espace de stockage ne fait pas exactement 32 M. Une partie est réservée au boot2.

L'OS n'est pas crypté.
Les clefs "cryptent" la signature de l'OS (qui permet de vérifier qu'il n'est pas modifié notamment).
Bien sûr que si l'OS est crypté (blowfish_decrypt et cert_descrypt).

Justement, on ne le connaît pas...
Car il faudrait ou arriver à exécuter de l'assembleur sur la nSpire pour le lire, ou dessouder la superbe puce Zevio, et la brancher sur un programmeur de puces adéquat pour en lire le contenu...
(je ne sais même pas si il existe des programmeurs de puces de cette forme, ailleurs que dans les chaînes de montage de nSpire...)

Comme dit la puce Zevio est un ASIC qui contient l'ARM9... et les controleurs. C'est une puce Made In Texas. Mais elle ne contient pas le Boot1 (voir puce 39WF400A 90-4C-B3KE).
Les puces sont trop petites pour qu'on puisse en extraire les données de plus il faut utiliser le protocole JTAG.
Enfin, le boot1 ne fait que vérifier le boot2 et le copier en RAM appararemment.

Sinon, le fichier TI-Nspire.img contient le code de l'OS directement ? Il suffit de le décompiler ?
Désassembler plutôt. Non comme dit il faut le décrypter. L'astuce utilisée est de le faire avec gdb par l'intermédiaire du boot2 (qui est lui n'est pas crypté).

DIT : les 63 octets contiennent : "TI-Nspire.tnc 1.7.2741 7711867 0
__RES__ 1.7.2741 0 2026409" qui sont donc des infos TI ajoutées au début....

Le code assembleur nous informe que cette en-tête est comparée avec le fichier /phoenix/manuf.dat et que enfin, le fichier spécifié ici TI-Nspire.tnc est copié dans /tmp/.

→ **MyCalcs** profile · by **critor** » 13 Dec 2009, 17:44

Désolé Geogeo de ne pas répondre de façon totalement exacte.
On pose des questions "poussées", je fais de mon mieux.

geogeo wrote: Le Boot1 est inscrit dans la même puce que le Boot2 et que l'OS (la ROM en gros).
Simplement il s'agit d'une zone protégée de la puce (au début ou à la fin de la mémoire ROM).

J'aimerai savoir d'où tu sors cette information ? Pour moi le boot1 est dans la 512KB NOR FLASH en lecture seule et le boot2 dans la 32MB FLASH NAND copiée en RAM par le boot 1 !
D'ailleur si tu regardes bien l'espace de stockage ne fait pas exactement 32 M. Une partie est réservée au boot2.

J'ai bien dit que le Boot1 étant en ROM.
Pour moi qui suis un fan de TI-83+/84+, ROM=Flash.
Je sais qu'il y a 2 ROMs sur nSpire, mais je ne me suis pas encore interrogé sur leur rôle respectif.
N'oublie pas que nous sommes sur un site de vulgarisation, que nous accueillons avec plaisir les débutants, et même ceux qui se trompent.

geogeo wrote: L'OS n'est pas crypté.
Les clefs "cryptent" la signature de l'OS (qui permet de vérifier qu'il n'est pas modifié notamment).
Bien sûr que si l'OS est crypté (blowfish_decrypt et cert_descrypt).

Tu parles d'un cryptage, si on a déjà réussi à en extraire le code et les messages (ce qui est le cas).
Nous éclaireras-tu de tes lumières là-dessus?

Si c'était un cryptage, on serait en train de chercher la clef (et encore pour quelques siècles comme tu le faisais justement remarquer), comme nous l'avons fait sur les z80/68k cet été.

Parlons plus d'un encodage dans ce cas-là.

Au plaisir de te lire.

→ **MyCalcs** profile · by **geogeo** » 13 Dec 2009, 18:20

> N'oublie pas que nous sommes sur un site de vulgarisation, que nous accueillons avec plaisir les débutants, et même ceux qui se trompent.
Oui bien sûr. Mais disons que les infos sur la NSpire se font au compte goutte et qu'il vaut mieux qu'elles soient exactes pour qu'elles soient exploitables.

Tu parles d'un cryptage, si on a déjà réussi à en extraire le code et les messages (ce qui est le cas).
Nous éclaireras-tu de tes lumières là-dessus?
Si c'était un cryptage, on serait en train de chercher la clef (et encore pour quelques siècles
comme tu le faisais justement remarquer), comme nous l'avons fait sur les z80/68k cet été.

La clé publique est dans le fameux TI-Nspire.cer mais la clé privée elle est bien dans boot2.raw. Elle se situe même dans la fonction blowfish_decrypt. Nous n'arrivons pas à l'extraire car le code est ofusqué (illisible pour un simple humain disons).
Il s'agit bien d'un cryptage et non d'un codage (sauf dans le cas du boot2). L'astuce employée, tout comme le fait l'émulateur est de laisser le soin au boot2 de decrypter l'OS et de le copier en RAM. C'est comme cela que nous avons fait pour désassembler l'OS.

Aujourd'hui nous cherchons comment executer notre propre code mais la seule piste envisagée est quand même complexe.

→ **MyCalcs** profile · by **critor** » 13 Dec 2009, 18:34

Merci Geogeo.

→ **MyCalcs** profile · by **Armael** » 13 Dec 2009, 19:10

Ouch.

Bon, voyons si j'ai suivi :

- le boot 2 n'est pas crypté. Cependant, je n'arrive pas à voir les chaines de caractères dont il était question... comment faire ?

- J'ai compris le coup de l'OS crypté et l'astuce pour récupérer le code décrypté par boot2. Par contre, où est-il stocké par l'émulateur une fois décrypté ? geogeo, aurais tu le code de l'OS (et du boot2 aussi) ? (par MP si c'est nécessaire

)

Hum... le fichier TI-Nspire.cer contient la clef publique pour le cryptage de l'OS. et la clef privée est dans la fonction blowfish_decrypt . Que contient alors le fichier boot2.cer ???

EDIT : y a des désassembleurs ARM sous Linux ?