[mOved] TI-Nspire, sous la robe... - Page 2

Dude (./28) :
Bloo> En ayant installé Noshell d'abord, Ion ou MirageOS passent-il ?

Je n'ai pas essayé. En fait j'ai installé MirageOS, il a fonctionné sans problème. Puis j'ai installé une application ASM pour MirageOS que j'avais sous la main, il s'agissait de "Gravity". J'ai donc relancé MirageOs et là, plantage. La Nspire a rebooté, Gravity a disparu mais Mirage était toujours là, je l'ai relancé une nouvelle fois et il a fonctionné de nouveau. A priori, c'est à l'ouverture;lorsqu'il cherche les applis ASM qu'il plante. Cela dit, je vais essayer avec d'autres applis.

rah j'hésite franchement à en prendre une, c'est pas mal de pognon dépensé, mais si on peut rien en sortir... En plus je sais pas si j'aurai du temps...

bloo (./27) :
Voilà, les scans HD des circuits de la Nspire sont faits, à squalyl de jouer pour les mettre sur le wiki.

a+

Le wiki est accessible ?

oui.

Nouvelle page: http://hack
plip
spire.uns
plop
ads.com/Hardware

virez les trisos du milieu, c'est pour google, il a déja indexé ce post...

Aidez moi avec le wiki, je suis un manchot pour la mise en page.

Faudrait trouver les datasheets de ces puces...

squalyl (./32) :
rah j'hésite franchement à en prendre une, c'est pas mal de pognon dépensé, mais si on peut rien en sortir... En plus je sais pas si j'aurai du temps...

Mon avis c'est que si tu es tenté d'en acheter une principalement parce ce que tu as l'espoir de bidouiller dessus (comme moi d'ailleurs) ; méfiance ! Ce n'est malheureusement pas demain que nous aurons un NspireGCC...

c'est clair. Mais si personne n'en achète, c'est pas comme ça qu'on va accélérer les choses.

J'en veux pas une pour utiliser des bidouilles, mais pour chercher des bidouilles.

bloo (./31) :
... A priori, c'est à l'ouverture;lorsqu'il cherche les applis ASM qu'il plante...

Pb de VAT alors ? Ce serai la nouvelle VAT de la NSpire qui serait utilisée au lieu de la VAT de la 84+
L'emulation de la 84+ n'est pas parfaite dans ce cas, mais bon, on est loin d'avoir percé tous les mysteres de la NSpire encore...

Pour NSpireGCC ca va demander du travail c'est clair (Surtout la lib a mon avis)
Mais on a quand meme un avantage : TiGCC existe deja

Quel rapport aevc TIGCC ? surement aucun

Visiblement le wiki est toujours protégé par mot de passe

RAM HYB18L256160BF-7.5
http://www.qimonda.com/download.jsp?ref=/qis_docs/Datasheets/Datasheets%20Mobile/HYx18L256160BxL-7.5_rev173.pdf

FLASH NOR SST39WF400A
http://www.sst.com/downloads/datasheet/S71220.pdf


CPU : difficile de trouver des infos, puisque c'est un ASIC
http://www.lsi.com/consumer_home/products_home/digital_home/edutainment_etoys/zevio/index.html
Visiblement, on peut avoir plein de choses dedans. Evidemment, on a l'ARM + contrôleur mémoire. Je ne pense pas qu'on ait le DSP, l'accélération 3D, le son, ...
Le tout est de trouver les broches JTAG, si elles sont cablées.

franchement un compilo c'est pas trop dur:

tar zxvf gcc.tar.gz
./configure --program-prefix=arm-nspire --target=arm-cekifo
make && make install

avec les options kivonbien

Non, le plus dur, c'est EXECUTER ce code , donc, oué, la lib ^^

Et il n'y a pas un sdk comme pour les flashapps sur 68k ?

Faire tourner du code natif en trouvant un moyen de sortir de l'émulation Z80 ne va pas nous aider pour la version CAS, qui ne contient pas l'émulateur Z80.

Quant à la chaîne d'outils, je pense qu'il est plus probable de pouvoir réutiliser des parties de HPGCC que de TIGCC, leur CPU est un ARM au moins. Mais même là, ça ne va pas nous avancer beaucoup plus que GCC directement de la FSF.

Kevin Kofler (./42) :
Faire tourner du code natif en trouvant un moyen de sortir de l'émulation Z80 ne va pas nous aider pour la version CAS, qui ne contient pas l'émulateur Z80.

Ben ça pourrait aider à dumper la ROM décryptée, ce qui serait déjà un gros pas en avant ^^ (qui permettrait potentiellement de programmer un ému et de trouver des failles communes aux deux versions)

Sinon si l'émulateur est "optimisé" pour exécuter l'OS et pas les programmes assembleur, c'est tout à fait possible qu'il y ait des trous qui restent (puisque par définition l'OS n'écrit pas n'importe où)

./43: Sauf que pour pouvoir écrire une telle faille, il faudrait avoir la rom décryptée.

ben pas forcément, on peut déjà voir ce qui se passe en écrivant n'importe où en assembleur, regarder le comportement des ports IO (il se peut très bien qu'il y en ait un qui ne fasse pas toutes les vérifications nécessaires), etc ; bon alors après c'est sûr que passer d'un plantage du code ARM à un exploit permettant d'exécuter du code ARM c'est pas forcément trivial, mais c'est pas a priori impossible ^^

C'est pas ce qui s'est fait sur la HP...euh... 49+ machin ?

Non, HP a fourni un moyen officiel de sortir de l'émulation Saturn.

Ok... Mais dès le début ? Il n'y avait pas eu d'exploit quelconque ?

Pas vraiment un exploit, non, mais il me semble que le moyen de sortir de l'émulation ait été trouvé en regardant le code de l'OS Saturn (qui l'utilise pour optimiser certains morceaux en vitesse à travers du code natif), HP n'a effectivement donné des informations (pas beaucoup, hein...) qu'après.

Bref, avec un OS crypté ça n'aide pas

Ce qui veux dire que dans ce cas il ne reste plus que les tests on-calc ?
Et sait-on au moins s'il existe une instruction similaire a la fameuse chaine Exec sur Ti68k ?
Mais a mon avis, l'emulateur de la 84+ reste une piste a explorer faute d'autre chose...
Car meme si on arrive a un petit quelque chose par ce moyen, ca restera +/- valable pour la version CAS.
Il y aura bien evidement des des differences mais le gros de l'OS doit rester identique (ca me fait penser a un truc : Quelqu'un a compris la difference de taille entre les 2 roms ?)
Sinon decrypter l'OS de maniere brute ca risque de prendre un peu de temps

(Et visiblement la rom est envoyée telle quelle sur la calc (Vérifié par Bloo), donc le coupable serait-il le boot ?
Ou un proc capable d'executer du crypté ? Mais là, ca m'etonnerai beaucoup...)

> Ou un proc capable d'executer du crypté ?
Une intégration du chiffrage assez profondément dans la plate-forme est malheureusement loin d'être impossible... AD intègre ça sur sa nouvelle famille de Blackfin BF-54x, voir http://www.analog.com/en/content/0,2886,763%255F207%255F113650,00.html
Extrait:

Lockbox Security Features Protect Intellectual Property The Blackfin ADSP-BF54X family also incorporates new Lockbox™ Secure Technology that allows developers to ensure code and data integrity through authentication, and to safeguard confidentiality by means of encrypting any or all of the system. Not only does this provide a means for developers to protect the intellectual property of their own products, but it also offers a platform for the digital rights management (DRM) content protection that is required for devices such as media players. In addition, the programmable aspect of the Lockbox software-based system gives system designers the opportunity to choose any encryption algorithm they prefer.

Vive les DRM !

Il reste le transfert entre calcs : le problème est qu'il faut en plus de deux nspire un analyseur USB

hwti (./53) :
Il reste le transfert entre calcs : le problème est qu'il faut en plus de deux nspire un analyseur USB

Je ne suis même pas sûr que cela soit utilie. Arretez moi si je dis une connerie, mais on peut très bien envisager que la Nspire garde le fichier .TNO sous la main pour le renvoyer tel quel à une autre Nspire.

Lorsque que l'on met l'OS à jour, la Nspire le reçoit comme n'importe quel fichier (on peut continuer à faire des calculs en même temps ) Puis elle passe en mode mise à jour automatiquement ce qui prend une bonne minute.
Ce qui est dommage, c'est qu'on ne puisse pas envoyer l'OS au PC. Mais il y a peut être une idée à creuser la dessous... car un analyseur soft, c'est plus facile à trouver

Sinon, je pensais à un truc. J'imagine que les documents .TNS ne sont pas les seuls fichiers présents sur la calc. Si on arrivait à avoir accès au reste, ( et si reste il y a) cela nous aiderait'il ?

Enfin, je viens de découvrir une fonction 'Login' dans le menu de l'explorateur de documents. Cette fonction m'intrigue. Malheureuseument elle est grisée, je ne sais donc pas à quoi elle peu bien servir.

bloo (./54) :
Je ne suis même pas sûr que cela soit utilie. Arretez moi si je dis une connerie, mais on peut très bien envisager que la Nspire garde le fichier .TNO sous la main pour le renvoyer tel quel à une autre Nspire.

Bien sur. Elle peut aussi crypter elle même compte tenu de la puissance de son CPU.

bloo (./54) :
Ce qui est dommage, c'est qu'on ne puisse pas envoyer l'OS au PC. Mais il y a peut être une idée à creuser la dessous... car un analyseur soft, c'est plus facile à trouver

Il faudrait que le PC émule une calc. Je ne sais pas si c'est faisable ou pas. Il faudrait déjà savoir comment dialoguent 2 calcs via leur port USB. Ce n'est pas parce que le port USB est utilisé que le protocole correspond à l'USB. Si c'est de l'USB, tout dépend si la calc qui reçoit est hôte ou périphérique. Si c'est un hôte, on pourrait l'émuler avec un PC.
C'est justement parce que les manipulations sont compliquées et peuvent nécessiter du matériel que c'est intéressant : TI pourrait avoir négligé la protection ici en jugeant que personne n'aurait le matériel nécessaire.

bloo (./54) :
Puis elle passe en mode mise à jour automatiquement ce qui prend une bonne minute.

Peut-être que l'OS est décrypté à ce moment.

C'est ce que je pensais aussi.
A moins que ce soit le temps pour écrire la flash
A moins que le code soit décrypté en hard XD (j'y crois peu mais on sait jamais)

bloo (./54) :
Lorsque que l'on met l'OS à jour, la Nspire le reçoit comme n'importe quel fichier (on peut continuer à faire des calculs en même temps ) Puis elle passe en mode mise à jour automatiquement ce qui prend une bonne minute.

Tiens c'est pas bête ça, ça évite les nombreux flashage ratés.

Thepro (./56) :

bloo (./54) :
Puis elle passe en mode mise à jour automatiquement ce qui prend une bonne minute.

Peut-être que l'OS est décrypté à ce moment.

Très probable.

D'après ce que j'ai compris du logiciel de link, c'est lui qui envoie une commande à la calc pour démarrer la mise à jour, donc si on interrompt le processus à ce moment, on garde certainement le fichier sur la calc. Si il était décrypté à la réception, on pourrait le relire avec le PC à ce moment.

Oui mais il est tres improbable que la NSpire decrypte l'OS dès reception de celui-ci, c'est plutot lors de ce fameux Mode Mise A Jour qu'elle le decrypte grace a ces certificats puis l'installe. Non ? (arretez-moi aussi si je dis une betise ^^)