Désassemblage du boot2 - Page 14

Petite question, je regarde pour me me prendre une NSpire sur ebay ducoup...

Donc, je peux prendre n'importe laquelle ?

Nspire CAS & Nspire non CAS ?
Je vais voir pour le modèle avec TI-84...

Pour infos, en provenance des states, c'est vachement avantageux (environ 60-70€ la calto)

update: tu cryptes avec leur clé. Tant qu'à se foutre d'eux, faut le faire puissamment

Il est aussi possible d'utiliser le même format bizarre de compression que pour le boot2, cassé par Goplat.


@iceman:
Le modèle avec émulateur 84+ intégré est le modèle non CAS. Mais à moyen terme, les deux modèles auront certainement émulateur TI-Z80 + émulateur Game Boy + émulateur TI-68k, voir plus haut.
Evite absolument le modèle "CAS+", c'est un prototype qui ne dispose pas de la possibilité d'upgrade de l'OS.

Pour infos, en provenance des states, c'est vachement avantageux (environ 60-70€ la calto)

Yep, mais attention aux frais de douane + dossier, surtout si l'expéditeur utilise FedEx ou un autre "grand transporteur"
Ma 83+SE (+ SilverLink non explicitement indiqué) à ~53 euros était elle aussi très avantageuse par rapport à ce qu'on trouve en France... elle l'est devenue nettement moins quand j'ai reçu 9 euros de taxes (TVA 0% ) + 11.96 euros de frais de dossier (dont TVA 19.6% ).

[EDIT: suppression des symboles "euro", ils apparaissent comme "€"]

(./372 : tiens, salut Moot )

./391 : le pad de 84+ sera probablement plus pratique pour les jeux.
Et généralement (mais pas toujours) le modèle non CAS est moins cher.

./390 : ça m'a jamais vraiment perturbé de faire du reverse-engineering avec des noms de méthodes et champs obfuscés.

Kevin: heureusement qu'on a pas attendu Fedora pour avoir des linux foncitonnant sur ARM...

Lionel Debroux (./392) :
Le modèle avec émulateur 84+ intégré est le modèle non CAS. Mais à moyen terme, les deux modèles auront certainement émulateur TI-Z80 + émulateur Game Boy + émulateur TI-68k, voir plus haut.Evite absolument le modèle "CAS+", c'est un prototype qui ne dispose pas de la possibilité d'upgrade de l'OS.

Rhaa je serais un poil plus jeune je pense que ça m'aurait fait acheter une nSpire pour faire un ému GB, mais en même temps comme je l'ai déjà fait sur DS (66 MHz) l'envie de défi n'est plus là si la nSpire est à 90 MHz Mais en contrepartie la gestion de l'affichage doit être plus complexe sur nSpire... hmm à voir
Cela dit malgré cette puissance ça ne sera vraiment pas évident. Et peut être que c'est une bonne chose, parce que les émulateurs ont une grosse tendance à tuer la communauté de jeu amateur et ça se comprend. En plus ça fait plein de màj par mois et des newz sur tous les sites imaginables, éclipsant les auteurs de softs originaux, qui se découragent.
Concernant le 68k ça me semble à priori impossible d'émuler une 89 HW2 en fullspeed avec niveaux de gris à une fréquence d'affichage correcte. Il ne manquerait certainement pas grand chose, donc je suis curieux de voir comment un éventuel codeur qui s'y attellerait s'en sortira

Pour info on peut définir des classes a partir d'un byte[] qui peut venir d'un fichier .class (ou autre) crypté.

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html#defineClass%28byte[],%20int,%20int%29

(la fonction est deprecated mais toujours présente en java 6)
http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#defineClass%28byte[],%20int,%20int%29

Mais bon si c'est pour avoir la clé de cryptage à côté...

Concernant le patch du boot 2 pour rentre le hack persistant, j'ai finalement des doutse sur la faisabilité : le boot 1 valide la signature du boot 2 à chaque chaque chargement d'après mes anciens tests de flash de boot 2 par RS232.

tu files la clé à ceux qui te la demandent par email après avoir montré patte blanche

et au moins ça résiste à la décompilation brute du jar, il faut exécuter le programme, le modifier pour aller dumper le résultat du décryptage dans un autre fichier, puis le décompiler

^^

bref

Sasume (./371) :

ExtendeD (./347) :
./342 : Personnellement je n'ai pas trop le courage, mais j'intègre volontiers si quelqu'un veut bien s'y atteler Le format est en 320x240, 4 bits par pixel (16 niveaux de gris), 0 est noir.

L’écran est utilisable pour des jeux (par rapport à la TI-89, il ne bave pas trop ?) ?

Aucune idée. Comme dit hwti de base il est pas terrible.

ExtendeD (./397) :
Concernant le patch du boot 2 pour rentre le hack persistant, j'ai finalement des doutse sur la faisabilité : le boot 1 valide la signature du boot 2 à chaque chaque chargement d'après mes anciens tests de flash de boot 2 par RS232.

Aille...

Dans ce cas-là, (en attendant que nos arrières-petits-enfants puissent signer un boot2), tu installerais le hack dans l'OS ?

Avec les inconvénients suivants si j'ai bien suivi:
- le hack ne survivrait pas à une mise-à-jour de l'OS
- on serait condamné à utiliser uniquement les vieux OS TI qui sont assez limités en fonctionnalités (c'est-à-dire au moins la version 1.1 - peut-être les versions 1.2/1.3 si les failles ne sont pas corrigées)


D'un autre côté, sur TI-68k c'était similaire avec hw2patch.
Il ne fallait pas mettre à jour avec une version trop récente...

Il ne fallait pas mettre à jour avec une version trop récente...

... du moins, tant que HW2Patch (ou MaxMem, d'ailleurs) n'avait pas été updaté. On bride ce genre de logiciels pour éviter qu'il patche n'importe quoi sur une machine disposant d'une version ultérieure de l'OS, sur laquelle le hack qui permet de trouver l'adresse à patcher n'a pas encore été testé.


Ca serait super que les failles existent encore sur les premières versions de l'OS Nspire qui ont une capacité de programmation en BASIC.

ExtendeD (./393) :
./390 : ça m'a jamais vraiment perturbé de faire du reverse-engineering avec des noms de méthodes et champs obfuscés.

Il ne fait pas que ça, il optimise pas mal le code, on pouvait pas debugue correctement après le passage de proguard...

iceman (./402) :

ExtendeD (./393) :
./390 : ça m'a jamais vraiment perturbé de faire du reverse-engineering avec des noms de méthodes et champs obfuscés.

Il ne fait pas que ça, il optimise pas mal le code, on pouvait pas debugue correctement après le passage de proguard...

Je ne vois pas vraiment ce que ça changerait, il leur suffirait d'espionner les transferts pour voir ce qui se passe.

Bien sur, mais ça permettrais de gagner un peut de temps, avec juste l'appel d'un prog a la compil...

Enfin, faites comme vous le sentez ;-)

Wah, génial, je m'attendais pas à autant de progrès en si peu de temps :]
Maintenant qu'on a un dump de l'OS, est-ce qu'il y a une chance que le format crypté et/ou compressé des TNS récent soit trouvé? (Pour rappel, voilà ce qu'on sait dessus: http://hackspire.unsads.com/wiki/index.php/TNS_File_Format). Si oui, ça me motivera peut-être à terminer mon éditeur de texte multi-plateforme(codé en C++/Qt) pour n-spire .

./405 : la réponse est oui

iceman (./391) :
Petite question, je regarde pour me me prendre une NSpire sur ebay ducoup...

Apparemment il y aurait une grande braderie de CAS ici : http://groups.google.com/group/tinspire/browse_thread/thread/ef90371d46008433

ExtendeD (./397) :
Concernant le patch du boot 2 pour rentre le hack persistant, j'ai finalement des doutes sur la faisabilité : le boot 1 valide la signature du boot 2 à chaque chaque chargement d'après mes anciens tests de flash de boot 2 par RS232.

Je vais quand même à l'occasion vérifier ça, c'est-à-dire que modifier en asm le boot 2 revient à le flasher en RS232, et donc que tout est toujours validé par le boot 1.

En réfléchissant un peu, un alternative pour la persistance entre les montées d'OS serait quelque chose de ce type :
- Le hook est installé sur l'OS 1.1
- Le nouvel OS est transféré comme un fichier classique
- Le hook est capable de patcher en RAM le boot 2 pour lui faire charger le nouvel OS, et pour que le hook puis être réinstallé dans ce dernier.
L'inconvénient est la consommation mémoire des 2 OS en NAND, et le temps d'exécution du boot 2 multiplié par 2.

Une astuce est requise concernant la gestion des fichiers sytèmes : ceux-ci sont normalement installés au moment de l'installation de l'OS.
Avec ce système de double boot, il est nécessaire d'avoir les fichiers systèmes de l'OS 1.1 lors de son boot, puis ceux du nouvel OS lors de son boot. Une solution serait de patcher le nouvel OS juste avant son exécution, pour préfixer tous les accès fichiers (l'arborescence du nouvel OS serait donc une sous-arborescence de l'OS 1.1).

Tout ça reste quand même un peu compliqué

Patcher le boot1 n'est peut-être pas impossible, mais on n'aurait pas le droit à l'erreur.

Si tu peux le faire avec ton code actuel : dump du boot1, peut-être qu'il a des failles (et en plus si TI n'a pas prévu sa mise à jour, on aurait quelque chose qui résisterait aux upgrade d'OS, au moins pour les calc actuelles).

Mais peut-être que la NOR est protégée en écriture ?
On a un "developer guide" correspondant à l'écriture dans cette NOR ? (il n'y a aujourd'hui probablement pas de code d'écriture dans la NOR dans le boot 2 et l'OS, puisque le boot 2 est sûrement dans la NAND vu sa taille).

La NOR est peut-être protégée en écriture (tout dépend comment ils ont cablé WE#).
Il y a peut-être des protections (lecture et/ou écriture) via la MMU.

La programmation est décrite dans la datasheet (http://www.sst-ic.com/PDF/39WF400A.pdf).
Une première étape serait de tester le mode "Software ID".

Mais il faut de toute façon la dumper avant, peut-être qu'on n'aura pas besoin d'écrire dedans.

L'utilisation en lecture/ecriture dans de la NOR est "normalisé" par le JEDEC

La version de l'émulateur GameBoy que m'a envoyée calc84maniac fonctionne particulièrement bien sur calc réelle : http://www.youtube.com/watch?v=3Rg4RdN2FAU

L'installeur est quant à lui en bonne voie, mais inutile de s'impatienter :

Super !!!

Cependant j'ai une question ExtendeD : l'écran est-il de bonne qualité ou il est comme celui de la TI 89 (bavure, trainée de pixels,.....) ?????

Enorme !!! Félicitations, vraiment !!!

et espérons qu'on pourra programmer en C++ sur cette machine

Arf déjà un énorme truc de fait...
sam22> On voit dans la vidéo que l'écran est de même qualité que la TI89.

Pas de bavure particulière, par contre il est très mal contrasté, et aujourd'hui le contraste n'est pas réglable sur l'émulateur GB.
Il est particulièrement grand par rapport à ce qu'une GB doit afficher, ça devrait rendre encore mieux sur des graphismes plus fins.

Re spoiler ./414: oh oui, il y a moyen de faire du C++ sur un ARM à 90 MHz

O_o respect

EPIC WIN IS EPIC comme dit l'autre

féliciations