Obtenir un romdump - Page 1

Jetons ici les idées pour accéder au firmware.

http://www.zataz.com/news/14647/iphone-nor-dumper-memory-simlock.html

eux ils ont réussi à dumper la flash NOR de l'iphone.

Difficulté pour la nspire: les boitiers sont au format BGA mais avec un peu de chances les bus doivent être accessibles.
On en revient au jtag, mais on sait toujours pas si il y en a un. Le PCB ne donne aucun indice dans cette direction, sauf peut être le connecteur imprimé du bas.

Je ne suis pas un expert en bidouilles mais j'ai une tite suggestion à vous faire. Bon, j'imagine que quelque part dans la mémoire de la Nspire on doit trouver, mappée, l'image la mémoire de la 84+ émulée avec la même organistation que la 84+ normale. Sachant que l'on peut en ASM lire le contenu de la mémoire sur 84+ on pourrait très bien écrire un progrmme en ASM qui ne s'arrête pas à l'adresse maxi de la 84 mais qui lise au dessus. Si on à la chance que la zone mémoire 84+ se trouve en partie basse, on pourrait très bien accéder au dessus dans la zone Nspire ? Evidemment, je dis ça, mais je suppose que l'émulation 84+ refusera un accès à une adresse supérieure à la dernière adresse mémoire 84+. Qu'en dites vous ?

Je serais surpris qu'il n'aient pas protégé à ce niveau là (surtout avec une MMU)

Que t'as les réponses dans la question.

C'est une très bonne idée, c'est celle qui a marché pour fargo (en gros), mais c'est très probable que les accès mémoire soient filtrés.

Imagine, la nspire a un CPU de modèle ARM.
mais la 84+ a un CPU Z80.

Donc, pour chaque instruction asmz80, la nspire va en fait choisir un cas dans un gros "switch(opcode)" (un ensemble de tests If then else) et exécuter "à la main" (en arm quoi) les opérations nécessaires pour exécuter une instructions asm z80.

C'est donc très facile pour cet émulateur (ca en est un) de vérifer l'adresse demandée.

mais je suis d'accord avec toi, c'est un test à faire, au moins pour être sûrs.

(cross aussi)

(post cross: même sans MMU en fait)

De plus, le Z80 est un processeur à adressage 16 bits, qui fonctionne donc avec des pages. Donc on ne peut pas facilement déborder, ça s'arrête à 0xFFFF parce qu'il n'y a plus de place dans le registre. Et je ne pense pas qu'il soit possible de donner n'importe quoi comme numéro de page.

J'avais déjà essayé de lire un peu partout la mémoire, y compris à des pages n'existant pas sur la 84+, sans succès (mais on pourrait faire un test plus exhaustif).

Franchement je pense que la NSpire alloue 64K de ram (cad le max addressable pour un Z80 sans pagination) pour la 84+ rendant de toute maniere impossible de déborder (a moins d'un enorme bug dans l'émulation)

Donc ça me parais impossible de ce coté la.

moi je dis rien, je sais pas comment marche la 84+. elle a seulement 64k de mem? Y compris le framebuffer et le système de fichiers?

24k de RAM.
Des infos sur le système de pagination sont disponibles sur WikiTI.

Godzil (./8) :
Franchement je pense que la NSpire alloue 64K de ram (cad le max addressable pour un Z80 sans pagination) pour la 84+ rendant de toute maniere impossible de déborder (a moins d'un enorme bug dans l'émulation)

Mais il y 1,5MB de flash ! (ça me fait penser que j'étais parti sur 2MB dans mes calculs sur le wiki).

En fait le Z80 (comme le 6809 ou le 6502) sont des proco avec un bus d'@ de 16Bits, donc capable d'addresser directement 65535 octets. Toutes les TI-Z80 utilisent la technique de pagination pour swaper des pages de mémoire pour permettre d'avoir plus de "memoire", mais c'est le genre de choses super simple a emuler (swap de pointeurs par exemple) donc vu que c'est l'émulateur/hardware qui controle tout ça me parrait tres difficile de pouvoir acceder en lecteur/ecriture ailleurs que la ou il faut.

Pour prendre un exemple que je connais bien, je défie quiconque d'accéder a la mémoire système avec mon emulateur de NES uniquement avec une ROM NES, C'est virtuellement impossible. Vous pouvez planter l'emulateur, ou autre choses du genre, mais pas acceder a la mémoire autre que celle alloué par l'émulateur pour la mémoire du 6502.

./10: Oui, comme certains jeu de NES font largement plus de 64Ko, mais a moins d'un bug enorme dans l'émulateur, le swap de page se doit d'étre blindé

d'accord.

purée je pensais pas que c'était autant le binze l'adressage mémoire de la ti83

Godzil (./11) :
Vous pouvez planter l'emulateur, ou autre choses du genre

A propos de ça j'ai réussi à le faire planter violemment une fois (des logs usb8x activés sur une page au pif), des pixels non-84+ en niveaux de gris étaient apparus et le bazarre avais gelé (le plantage tenait au reboot, j'ai eu du mal à m'en débarasser). Je suis sûr que l'émulateur est une bonne voie d'accès.

Donc c'est que leur emu ne doit pas etre asez blindé (et tant mieux ^^)

(tiens tenter d'ecrire sur la rom pourrait etre une idée pour voir ce que ça fait ^^)

Si leur emu est fait a-la-TI© ça pourrait marcher

-> http://hackspire.unsads.com/TI-84_Plus_Emulation#We_need_your_help . Mais étant donné qu'ils stockent dans le fichier d'OS la mémoire archive et l'OS 84+ séparemment, j'ai des doutes.

Oui, mais je pense que l'émulateur doit rester une entrée temporaire, afin d'exécuter des codes de test qui permettront de trouver des failles plus pérennes. En effet, le mieux c'est de trouver des failles dans le HW. Si on se limite à l'exploitation d'une faille soft (émulateur), TI la comblera rapidement.

Personnellement je cherche plus une faille permettant un romdump qu'une faille tout court pour le moment, puisque l'un permet l'autre.

Je pense a un truc... Si on reste dans le cadre de l'emulateur :
N'y aurait-il pas moyen de faire executer du code ARM par l'emulateur Z80 en faisant executer un code Z80 ?
Ne peut-on pas trouver des similitudes au niveau des instructions ?
C'est peut-etre ce type de plantage ExtendeD que tu as eu...

ça dépend des failles de l'ému, et donc du code de l'ému, et donc du romdump, etc...

C'est théoriquement impossible d'éxecuter du code "natif" dans un emulateur... apres ça va dépend de l'émulateur, mais bon

Il n'est pas impossible qu'il y ait un trap prévu pour exprès, les HPs ont bien ça dans leur émulation Saturn pour accélérer l'émulation. Ça a été trouvé en analysant la ROM Saturn. Donc vu qu'on peut dumper la ROM Z80, on trouve peut-être des trucs intéressants là-dedans?

Ceci dit, ça m'étonnerait quand-même que TI ait mis une faille tellement évidente dans leur système.

rien n'est impossible avec eux

analyser la rom (différences avec la version précédente) me semble intéressant. Il faudrait rameuter la troupe des spécialistes TI83-84, y'en a forcément.

Et sinon on en revient au même point, pour la ROM NOR de la nspire, pour le moment, j'ai pas d'autre idée que de dessouder la puce, mais bon c'est un peu extrême

Kevin Kofler (./22) :
Il n'est pas impossible qu'il y ait un trap prévu pour exprès, les HPs ont bien ça dans leur émulation Saturn pour accélérer l'émulation. Ça a été trouvé en analysant la ROM Saturn. Donc vu qu'on peut dumper la ROM Z80, on trouve peut-être des trucs intéressants là-dedans?

Ceci dit, ça m'étonnerait quand-même que TI ait mis une faille tellement évidente dans leur système.

Peut être du coté de la gestion du link USB.

Et encore j'ai un gros doute la dessus, vu que ce n'est pas la meme version de la ROM il on pu completement changer la gestion de l'USB au niveua de l'OS 84+ pour utiliser des ports virtuel mappé sur ceux de la NSprire

squalyl (./1) :
Difficulté pour la nspire: les boitiers sont au format BGA mais avec un peu de chances les bus doivent être accessibles.

C'était aussi le cas pour l'iPhone (y'en a un qui en a payé les frais) : http://iphonejtag.blogspot.com/2007/08/it-looks-bad-but-its-good.html

et il l'a ressoudé et ça a marché c'est ça?

Non non, celui-ci c'était uniquement pour trouver les pins JTAG, on lui avait donné, je pense pas qu'il ait servi à grand chose après.

ah ok