Posté le 20/03/2024 21:17
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 98 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 20/03/2024 21:56 | #
Alors, le problème c'est qu'un g1a ne contient pas les sources. C'est juste un gros blob dans lequel du code compilé est mélangé avec les données, et les modifications qu'on peut faire direct sur un g1a sont très limitées.
La grosse grosse question c'est est-ce que tu as ou peux trouver les sources. Les outils à utiliser (compilateur etc) viennent après et dépendent en gros de comment le programme a été écrit (tu as envie d'utiliser les mêmes outils que l'auteur original essentiellement).
Si tu as les sources, tout va bien se passer, avec un peu d'aide on y arrivera.
Si tu n'as pas les sources, tout est compliqué et tu ne peux faire que des modifications basiques.
Citer : Posté le 21/03/2024 09:35 | #
Bonjour et merci à toi de ta réponse rapide !
Mince moi qui pensais possible de faire du rétro-ingéniering il semble donc à te lire que je puisse récupérer les programmes pour les mettre à jour.
Non je pense pas pouvoir avoir accès aux sources malheureusement et c'est dommage, car c'est du beau travail ! Quelle perte !
Partant du principe que je n'ai pas les sources il n'y a donc rien à faire ?
Citer : Posté le 21/03/2024 09:38 | #
Tu peux faire des choses, tu es juste limité d'une façon assez simple : essentiellement, tu peux remplacer des bouts de code ou de données mais tu ne peux pas ajouter des choses au milieu. Par exemple, imaginons que tu as un tableau périodique contenant 80 éléments, tu peux probablement modifier les informations de ces éléments, mais tu ne peux pas en ajouter. La raison c'est que ça allongerait la table et ça "décalerait" le reste du fichier, ce qui le casserait.
Du coup, il faut maintenant se poser la question de qu'est-ce que ce programme fait et qu'est-ce que tu veux changer dedans.
Citer : Posté le 21/03/2024 09:42 | #
En fait il faut actualiser des données chiffrées.
Par exemple mettons que je suis comptable et que je souhaite effectuer la déclaration de revenus de mes clients, le programme me permet de calculer l'impôt des mes clients. Mais les données datent d'une loi de finance ancienne, les plafonds sont modifiées je dois les mettre à jour.
Le code est bon mais les dates à faire tourner le sont plus.
Par ailleurs si nombre à changer dans le code augmente d'un chiffre, que nous passions de 999 à 1000, cela va-t-il décaler le code ?
Enfin il reste possible si je te suis bien de lire les codes, et de refaire le programme en "le copiant" proprement si je te comprends bien ?
Citer : Posté le 21/03/2024 10:00 | #
Ok, donc si tu as uniquement des constantes à changer ça devrait être possible. Non si tu passes de 999 à 1000 ça ne devrait pas augmenter la taille du code ; l'unité la plus courante des nombres entiers a une plage de ±2 milliards et sauf si l'add-in est vraiment codé avec les pieds ça doit être stocké dans ce format-là. Les nombres flottants c'est pareil.
Refaire le programme en le copiant proprement... pas exactement. Le but de la manipulation serait plutôt d'aller lire le programme pour trouver les données que tu cherches, et ensuite aller modifier. C'est un peu comme substituer une aiguille dans une botte de foin : il n'est pas question de détricoter la botte complète, tu vas juste chercher ton aiguille, aller pile au bon endroit pour la remplacer, et pas toucher le reste.
Clarifions que le code compilé c'est tout en binaire (pas en texte) et même quand tu l'affiches sous une forme lisible ("désassemblée") ça te donne du code comme ci-dessous (une fonction prise dans un de mes add-ins).
300000: 2f 86 mov.l r8,@-r15
300002: 68 43 mov r4,r8
300004: 2f 96 mov.l r9,@-r15
300006: 69 53 mov r5,r9
300008: 2f a6 mov.l r10,@-r15
30000a: 2f b6 mov.l r11,@-r15
30000c: da 09 mov.l 300034 <_start+0x34>,r10 ! 313c40 <_start2>
30000e: db 0a mov.l 300038 <_start+0x38>,r11 ! 8102848 <_gint_restart>
300010: 4f 22 sts.l pr,@-r15
300012: 65 93 mov r9,r5
300014: 4a 0b jsr @r10
300016: 64 83 mov r8,r4
300018: 61 b2 mov.l @r11,r1
30001a: 21 18 tst r1,r1
30001c: 89 04 bt 300028 <_start+0x28>
30001e: d1 07 mov.l 30003c <_start+0x3c>,r1 ! 313954 <_gint_osmenu_native>
300020: 41 0b jsr @r1
300022: 00 09 nop
300024: af f6 bra 300014 <_start+0x14>
300026: 65 93 mov r9,r5
300028: 4f 26 lds.l @r15+,pr
30002a: 6b f6 mov.l @r15+,r11
30002c: 6a f6 mov.l @r15+,r10
30002e: 69 f6 mov.l @r15+,r9
300030: 00 0b rts
300032: 68 f6 mov.l @r15+,r8
300034: 00 31 .word 0x0031
300036: 3c 40 cmp/eq r4,r12
300038: 08 10 .word 0x0810
30003a: 28 48 tst r4,r8
30003c: 00 31 .word 0x0031
30003e: 39 54 div1 r5,r9
Et y'en a des kilomètres de comme ça, d'où le fait que tu ne veuilles pas repasser sur "tout" le code.
Avant de se lancer dedans cela dit, il faut continuer à se poser des questions sur le programme. Est-ce qu'on peut avoir une copie du g1a pour l'analyser ? Est-ce que tu as une liste complète des données à changer ? Et est-ce que tu connais les valeurs d'origine ?
Parce qu'autant chercher et trouver une aiguille bien identifiée ça se fait, autant si tu ne sais pas vraiment quelles formules sont employées et tu comptes sur l'analyse du code pour te révéler quelles constantes tu vas devoir mettre à jour... ça va être compliqué. (D'où le fait que d'habitude on passe beaucoup d'efforts à chasser les sources avant de recourir à une modification directe d'une g1a.
Citer : Posté le 21/03/2024 11:36 | #
Oui effectivement c'est totalement imbitable en l'état, merci d'avoir partagé l'impression écran, cela dépasse largement mes compétences.
Je suis capable en C++ de comprendre les boucles, les assignations, et de trouver les constantes qui avaient été introduites dans les calculs que fait le programme, mais là...
Je ne vois pas du tout comment faire.
Pour analyser le programme sur le principe pas de soucis, merci de le proposer. Il y a quand même un copyright dessus, et c'est pourquoi je voulais plus le mettre à jour pour mes besoins personnels que de le diffuser... A voir avec toi.
Citer : Posté le 21/03/2024 12:20 | #
À moins que la page originale spécifie qu'il n'est pas autorisé de le réuploader, tu peux le mettre en pièce jointe de ton message. Si tu as un lien vers la page de présentation d'origine je suis preneur aussi, histoire de comprendre un peu la situation et voir si on a la moindre chance de récupérer les sources.
Citer : Posté le 21/03/2024 13:07 | #
l'unité la plus courante des nombres entiers a une plage de ±2 milliards et sauf si l'add-in est vraiment codé avec les pieds ça doit être stocké dans ce format-là.
Je veux pas dire mais c'est un peu le contraire, pourquoi prendre de la place en plus quand on a pas besoin de la plage
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 21/03/2024 13:35 | #
Y'a rien à gagner. Une poignée d'octets sur plusieurs dizaines ou centaines de milliers ? Tu y penses que tu fais des gros tableaux, tu y penses pas le reste du temps. Le compilateur optimise un peu quand c'est des littéraux dans les fonctions mais pas au point de mettre des entiers de 8 bits (sur SuperH y'a pas de mov pc-rel en 8 bits de toute façon).
Citer : Posté le 21/03/2024 13:48 | #
Fcalva, faut pas que tu décompiles l'OS car tu vas faire des cauchemars ...
Les booléens dans des uint32_t sont plus que monnaie courante, c'est loin d'être optimisé, sauf peut être pour des questions d'alignement, mais j'ai qq doutes. Quand j'ai regardé la partie "Serial", y'a des moments où j'ai eu un peu peur
Citer : Posté le 21/03/2024 14:00 | #
Lephe : Ben... si il y a des gros tableaux ?
Sly : Je dis pas que tout le monde le fait, mais que je sais que j'essaye de le faire au moins, et je suis pas le seul
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 21/03/2024 14:06 | #
Lephe : Ben... si il y a des gros tableaux ?
Sly : Je dis pas que tout le monde le fait, mais que je sais que j'essaye de le faire au moins, et je suis pas le seul
En gros si tu as un seul int32_t alors qu'il de faut un int8_t, c'est pas la mort.
Par contre si tu as un tableau de 10000 ou 100000 entiers et que tu prends des int32_t au lieu d' int8_t, là ça va piquer méchamment sur l'utilisation de la mémoire. Donc autant dans le premier cas du t'en fous, autant dans le second cas tu peux plus trop t'en "balec"
C'est ça (je pense) que veut dire Lephe avec les "gros tableaux".
Citer : Posté le 21/03/2024 17:57 | #
Merci à tous de ces réponses.
Lephenixnoir je peux te le passer en mp ou autre dans un premier temps pour ton analyse ?
Citer : Posté le 21/03/2024 18:10 | #
Oui, très bien.