APPS Flash - Page 3

note au passage: pour recompiler quelquechose il faut en avoir la source, si tu trouves la source d'AMS ça peut être marrant j'aimerais bien voir ^^

H

Comment veux-tu qu'à partir de code machine brute un désassembleur soit capable de distinguer le code des données?
De plus, c'est illégal de désassembler AMS ()
Enfin, vu qu'il a été écrit en C et pas en asm, le code désassemblé ne devrait pas être trop t'avancer...

I

Certains désassembleurs le font. Les éditeurs hexa le font. Et c'est pas parceque ce sont des données que leur code ne correspond pas à des instructions. Et ce n'est pas parceque ce ne sont pas des instructions que ce sont des chaînes de caractères. Enfin si tu n'es pas content tu peux toujours faire ton propre décompilo ...

C'est pas franchement aussi simple que ça de reconnaître les données du code. Code un désassembleur, tu t'en rendras vite compte.

Ensuite, une fois que tu as commencé à considérer des octets comme des données, tu t'arrêtes où ? Pour peu que le code utilise des techniques d'adressage un peu moche, ça devient vite compliqué

J

Bah comme je l'ai dit, n'importe quel éditeur hexa fait ça

J'aimerais bien faire un désassembleur de l'AMS, mais je suis un peu limité : vu que je connais aps trop le C, je susi obligé de le coder on-calc et là je suis un peu limité par les capacités de la TI Je pensais envoyer les fichiers sources quand ils sont pleins. Mais faudrait d'abord que je finisse de débuguer le désassemblage de prog kernel (avec reconnaissance partielle des données )...

K

Le débugger de vti par exemple allie de façon efficace éditeur hexa et désassembleur. Ca marche très bien, personne ne s'en plaint...

AMS est du code en lecture seule, donc pas de code automodifiant, donc il est probablement possible de distinguer le code des données en utilisant les algorithmes connus qui résolvent des cas particuliers solubles du halting problem. Et il est certainement possible de faire le tri à la main, parce que tout est univoquement soit code, soit donnée (pas de code automodifiant).

en utilisant les algorithmes connus qui résolvent des cas particuliers solubles du halting problem

A mon avis c'est bien plus simple que ça. Dans AMS, les données ne sont pas vraiment légion, et le code est très stéréotypé, donc on peut s'attendre à des trucs bien précis (une bête vérification portant à la fois sur l'intégrité du stack pointer et sur l'interdiction de modifier/utiliser un registre autre que d0-d2/a0-a1 sans le charger et le restaurer correctement devrait suffire, et ça ne devrait pas être trop chaud étant donné que le compilo Sierra adopte une structure "MaFonction: <code de la fonction, sans rts> ; rts").
Ce qui demanderait du boulot, ce serait surtout de gérer les cas particuliers (qques fonctions écrites "à la main", et puis les fonctions du style "trap #0" qu'il faut absolument gérer de manière spéciale), et de bien se démerder avec le code de protection de la FlashRom.