Posté le 26/11/2019 19:28
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 75 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 27/11/2019 17:28 | #
Oublie pas de spécfier --toolchain selon tes besoins.
Edit : Pour fxos tu n'as pas besoin du cross-compilateur, du reste.
Citer : Posté le 27/11/2019 17:29 | #
Oublie pas de spécfier --toolchain selon tes besoins.
Pas faux j'ai fait un peu ça à l'arrache du coup
Ajouté le 27/11/2019 à 17:33 :
Edit : Pour fxos tu n'as pas besoin du cross-compilateur, du reste.
Justement là je test fxSDK mais j'ai eu des problèmes avec le template de projet (sh3eb-elf-gcc était utilisé alors que avec la nouvelle méthode de compilation du cross compilateur c'est sh-elf-gcc et apres -m3 ou -m4-nofpu)
l'un des commits en question
Ajouté le 27/11/2019 à 17:39 :
Et encore autre chose quand je tape make uninstall dans le dossier pour déinstaller fxSDK les commandes ne s'executent pas elles s'affichent juste sur la console
rm -rf /home/lailouez/.local/share/fxsdk
Ajouté le 27/11/2019 à 18:04 :
Je viens de FIX le uninstall (le commit) je ne sais pas pourquoi ça marche pas avec les {} x)
Citer : Posté le 27/11/2019 20:41 | #
Le fait que les commandes s'affichent dans la console c'est normal, et ça prouve qu'elles sont bien exécutées.
Tu es sûr sur le fait que ça marche pas ? Tu as quoi comme shell ? o_o
Je testerai, promis ; j'ai pas mon install sous la main pour le moment donc je délaie un peu.
Citer : Posté le 27/11/2019 22:13 | #
Le fait que les commandes s'affichent dans la console c'est normal, et ça prouve qu'elles sont bien exécutées.
Tu es sûr sur le fait que ça marche pas ? Tu as quoi comme shell ? o_o
Je testerai, promis ; j'ai pas mon install sous la main pour le moment donc je délaie un peu.
Shell de base debian, moi aussi ça m'a fait drôle de remarquer ce bug
Citer : Posté le 27/11/2019 22:27 | #
Bizarre. Je testerai, et si j'arrive à reproduire (ou tout simplement dans le doute ou par compatibilité avec les configurations exotiques de shells) je séparerai.
Citer : Posté le 27/11/2019 22:30 | #
Le shell de base de Debian c'est Dash, pas Bash. Dash a moins de fonctionnalités…
Citer : Posté le 27/11/2019 22:31 | #
Le shell de base de Debian c'est Dash, pas Bash. Dash a moins de fonctionnalités…
Merci pour l'info. J'ai modifié le Makefile en local.
Ajouté le 28/11/2019 à 20:16 :
Bon du coup j'ai commencé à regarder fxos plus en détail et je vois pas mal de façons de le rendre plus puissant. J'ai vraiment envie de passer un peu de temps dessus.
L'outil qui peut l'amener au niveau d'IDA Pro sur les analyses automatiques serait un interpréteur abstrait. Avec ça, on passe vraiment au niveau supérieur, modulo quelques hypothèses raisonnables sur la gueule du code compilé. Quelques trucs qu'on peut faire avec, c'est...
• Trouver des constantes dans le code et dans les appels de fonctions
• Donc déterminer automatiquement quels messages sont affichés à l'écran
• Détecter le nombre de paramètres d'une fonction et leur taille
• Reconnaître des boucles de taille constante
• Faire des call graphs décents même en présence de jmp @r1 (il faut connaître la valeur de r1)
• etc etc.
Je tiendrai le sujet du fxSDK à jour.
Citer : Posté le 28/11/2019 20:49 | #
L'outil qui peut l'amener au niveau d'IDA Pro sur les analyses automatiques serait un interpréteur abstrait. Avec ça, on passe vraiment au niveau supérieur, modulo quelques hypothèses raisonnables sur la gueule du code compilé. Quelques trucs qu'on peut faire avec, c'est...
• Trouver des constantes dans le code et dans les appels de fonctions
• Donc déterminer automatiquement quels messages sont affichés à l'écran
• Détecter le nombre de paramètres d'une fonction et leur taille
• Reconnaître des boucles de taille constante
• Faire des call graphs décents même en présence de jmp @r1 (il faut connaître la valeur de r1)
• etc etc.
Je tiendrai le sujet du fxSDK à jour.
C'est ce que je voulais que IDA fasse ^^.
C'est un bon projet en tout cas, et largement réalisable je pense.
Ajouté le 01/12/2019 à 18:19 :
Bonjour,
Depuis ma migration définitive sous debian, j'utilise ghidra, je ne vous cache pas que c'est un outil vraiment très puissant (je suis étonné moi même).
En le paramétrant bien, le code est découvert automatiquement, et ghidra désassemble en C voici un exemple avec la fonction memcpy (syscall 0x2AA) :
à droite la fonction bien désassemblé en C (bien sûr c'est moi qui ai modifié les noms de variables)
Bref parfait pour désassembler.
Citer : Posté le 01/12/2019 18:21 | #
Hmm... bizarre. Tant que ça te plaît.
Citer : Posté le 01/12/2019 18:23 | #
Hmm... bizarre. Tant que ça te plaît.
Franchement c'est vraiment très bien, il y a le code désassemblé en SH4 au milieu et si on veut on peut analyser du code en C
Citer : Posté le 01/12/2019 18:54 | #
Il convertie tout en C ? C'est pas drôle x)
Citer : Posté le 01/12/2019 19:10 | #
C'est con mais... je suis d'accord, c'est "pas drôle"...
Bon localement ça doit vraiment aider à déchiffrer le flot de contrôle. C'est vrai que la partie dure du RE c'est pas tellement ça.
Citer : Posté le 01/12/2019 19:17 | #
C'est con mais... je suis d'accord, c'est "pas drôle"...
Bon localement ça doit vraiment aider à déchiffrer le flot de contrôle. C'est vrai que la partie dure du RE c'est pas tellement ça.
Oui c'est clairement de la triche mais bon quand on voit les résultats x).
J'ai remarqué grace à ça que le memset utilise une technique assez bizarre x)
Citer : Posté le 01/12/2019 19:52 | #
Alors oui, Casio fait très souvent des trucs bizarres. D'ailleurs, je me demande comment ghidra se débrouille pour convertir en C du code qui a été optimiser par GCC. Pour le cas de Casio, ils utilisent un compilateur assez... merdique qui fait, de temps en temps, des choses non conventionnelles comme appeler des fonctions via des registres comme r6. Je ne sais pas si ghidra te préviens s’il se passe des choses bizarres mais fait gaffe !
Chacun a son propre avis mais je trouve que ce qui est le plus important quand on fait de la RE ce n'est pas la finalité mais c'est le fait d'apprendre / comprendre certaine technique de rétro-ingénierie. Pour moi c'est un jeu d'esprit, ça permet d'être dans un état "d'exploration", intrigué par tout ce qu'on trouve et toujours prêt à découvrir une nouvelle horreur de Casio, ou un petit truc sympathique que personne n'avait exploité avant
Citer : Posté le 01/12/2019 19:59 | #
Le code de Casio n'est définitivement pas compilé par GCC. L'assembleur qu'on a est très "gentil" ; il n'est pas vraiment optimisé. Je peux décoder des segments de 10-15 lignes à vue sans problèmes, et c'est pas vraiment envisageable avec le code bien tordu que GCC peut sortir parfois.
Ah, et si tu parles de la photo alors ce n'est pas du code d'add-in mais bien du code de l'OS (regarde les adresses).
Perso j'aime cultiver ma capacité à déssasembler vite et bien. Maintenant je m'intéresse à étendre fxos pour me faire une base de données de documentation...
Citer : Posté le 01/12/2019 20:37 | #
Alors oui, Casio fait très souvent des trucs bizarres. D'ailleurs, je me demande comment ghidra se débrouille pour convertir en C du code qui a été optimiser par GCC. Pour le cas de Casio, ils utilisent un compilateur assez... merdique qui fait, de temps en temps, des choses non conventionnelles comme appeler des fonctions via des registres comme r6. Je ne sais pas si ghidra te préviens s’il se passe des choses bizarres mais fait gaffe !
Oui j'ai des choses que je règle à la main sur ghidra.
Je m'aide du code C mais je regarde principalement le code SH4.
Un truc bizarre que j'ai déjà vue :
extu.b r2,r2
Ajouté le 01/12/2019 à 20:37 :
Chacun a son propre avis mais je trouve que ce qui est le plus important quand on fait de la RE ce n'est pas la finalité mais c'est le fait d'apprendre / comprendre certaine technique de rétro-ingénierie. Pour moi c'est un jeu d'esprit, ça permet d'être dans un état "d'exploration", intrigué par tout ce qu'on trouve et toujours prêt à découvrir une nouvelle horreur de Casio, ou un petit truc sympathique que personne n'avait exploité avant
Je suis d'aaccord
Citer : Posté le 01/12/2019 21:04 | #
Un truc bizarre que j'ai déjà vue :
extu.b r2,r2
Ça n'a rien de bizarre ? C'est la façon la plus rapide d'obtenir r2=132.
Citer : Posté le 01/12/2019 21:23 | #
Un truc bizarre que j'ai déjà vue :
extu.b r2,r2
Ça n'a rien de bizarre ? C'est la façon la plus rapide d'obtenir r2=132.
Ah bon ? Pourquoi on fait pas un mov 132, r2 ?
Citer : Posté le 01/12/2019 21:41 | #
Si je te dis que le jeu d'instructions est 16 bits ?
Et si j'ajoute pc-rel ?
Citer : Posté le 01/12/2019 21:44 | #
Si je te dis que le jeu d'instructions est 16 bits ?
Et si j'ajoute pc-rel ?
AAAH donc sinon on devrait utiliser un mov PC-REL après pourquoi je ne sais pas ?
Citer : Posté le 01/12/2019 21:53 | #
Les instructions faisant 16 bits, il n'est pas raisonnable d'accorder plus de 8 bits à un opérande immédiat. Donc mov #imm, rn est une instruction pour #imm écrit sur 8 bits (signé).
Là il se trouve que 132 tient sur 8 bits en non signé donc on arrive à éviter le pc-rel.