Si j'avais à faire quelque chose, et si on pouvait injecter du code, je ferais comme suit:
Le but est d'obtenir un romdump.
On connait un moyen de faire un buffer overflow (un gros).
Partant des hypothèses que la RAM fait NRAM octets, que la pile est vers la fin, la gueule de mon code (assumant un stack overflow) :
<----------------------------------------------------STACK ------------------------------------------------------------->
<----><Frame buffer-------><--------- Other memory ------------------------------------------------------>
| buffer stack overflow
| Point de retour
<------------------- A ------------------------> <------------------------------------- B ---------------><-C->
J'utiliserais un buffer démesurément grand qui écrit toute la pile:
A est une un table d'adresse absolue qui pointe dans la zone B (pour surcharger l'adresse de retour) assez grande pour surcharger tout le frame buffer.
B est une très grande zone de NOP (parce qu'on ne peut pas prédire où exactement ca va se lancer).
C est le code effectif
Le tout est de trouver l'adresse stockée dans A qui pointe dans B. Comme B est grand, et en faisant des suppositions sur le mapping de la mémoire de la pile, ca ne doit pas être bien difficile.
(On peut aussi faire une séquence grande Zone de B / petite zone C / grande zone de B / petite zone C si on a des problèmes sur la conjecture du mapping. Permet de minimiser la probabilité de tomber dans C directement).
Après le code à éxécuter:
je ferais d'abord une recherche de l'écran, en injectant autant de code qui suppose que l'écran se trouve dans une zone mémoire donnée, et on affine la recherche par dichotomie:
Pour tester, on inverse tous les bits de la zone mémoire sélectionnée, on attend, on réinverse, et ainsi de suite. Si on voit quelque chose à l'écran, c'est bon.
(On évite aussi d'écraser la table des vecteurs et de déclencher des exceptions et en priant qu'il n'y ait pas de protection de la mémoire).
Une fois qu'on a une idée de la zone mémoire de l'écran, on essaye de trouver comment c'est stocké (bitplane, linear ?)
Puis une fois qu'on sait comment fonctionne l'écran, on peut commencer à dumper la table de vecteur (en espérant qu'elle n'est pas protégée), et à dumper/afficher ce qu'elle pointe (toujours par plusieurs programmes successifs).
Puis peut être qu'on comprendra comment marche les touches claviers (et ou les ports), auquel cas, on pourra programmer un réel débuggueur.
Une autre solution (2) serait d'éxécuter un programme qui recopie la rom morceau par morceau dans un fichier spécialement chargé dans la calculatrice : on recherche un mot clé magique dans le fichier pour le trouver, une fois trouvée, on recopie une partie de la rom dedans. On télécharge le fichier sur le pc, on extrait l'information. On continue pour tous les morceaux.
Le problème est : comment faire pour que ce fichier soit conservée suite au reset inévitable qui va suivre (puisqu'on a complètement grillé la pile). Peut être exécuter un trap/vecteur qui éteins la calculatrice (ce trap/vecteur pourrait archiver/sauver lors de l'extinction ?)
Une troisième solution à partir du moment où on connait et sait gérer l'écran est de remonter le hack pour afficher les adresses exactes du frame buffer attacké (où se trouve l'adresse de retour lu) par essai / erreur (et aussi en considérant qu'on a du récupéré quand même dans les autres registres des valeurs qui sont juste avant).
Une fois cette adresse connue, on peut faire juste un petit loader dans le frame buffer qui va éxécuter un fichier spécial contenant du code écrit (par recherche de mot magique) puis saut pour exécuter ce code en priant qu'il n'y ait pas de protections d'exécution. Ce code applique la solution (2) et essaye de faire un retour dans la pile d'appel originale au niveau N+1 (qui n'a pas été écrasé) (en conjecturant et par essai sur le paramètre de retour -- en faisant un tri sur les nombres non multiples de 4, et sur les nombres qui ne se trouvent pas dans la méme zone que la table de vecteur).
A voir comment régler le problème de l'ARM et ou THUMB.
C'était les réflexions fumeuses d'un PpHd qui n'y connait rien en cracking, un Lundi Soir.
Vraiment fumeuses. Désolé pour ceux qui ont tout lu
Si tu lui avais dit qui d'autre travaillait dessus ça aurait été un peu plus constructif 
Si tu lui avais dit qui d'autre travaillait dessus ça aurait été un peu plus constructif
