Si je veux interpréter ce programme, je dois donc plutôt me baser sur la version obtenu avec threading et tenir compte des zones de données ? Et à priori ne pas tenir compte des lignes de code qui ont été remplacées par des DB... ?
(c'est mon premier contact avec un programme assembleur, donc là je découvre...)
Dessassembler un programme sans bien connaitre l'assembleur du µC ....... autant aller sur la lune avec un vélo !Envoyé par corde57
Tu veux modifier quoi sur ce programme ?
Je suis programmeur (C, VB, Java, également un peu d'automates programmables) mais c'est la première fois que j'ai à faire à de l'assembleur, qui a l'air quand même très différents des langages que je connais (qui sont d'ailleurs un peu tous similaires).
C'est pour donner un coup de main à un ami automaticien sur un projet, je ne compte pas modifier le programme.
Le µC est utilisé sur des cartes d'entrées/sorties pilotant l'ouverture et la fermeture de portes de coffrets.
L'utilisateur indique quel coffret ouvrir sur l'interface utilisateur, l'interface envoie la demande d'ouverture via un bus à la carte d'entrées/sorties (et donc au µC), la carte pilote le relais permettant d'ouvrir la bonne porte.
La carte E/S vérifie également périodiquement le bon fonctionnement des relais, en les activant à tours de rôle.
Le but du projet est de remplacer l'interface utilisateur par une interface informatisée plus moderne. La partie coffret, relais, carte E/S et le µC ne doit pas être modifiée.
Ce qu'on cherche donc à savoir c'est "que doit envoyer l'interface aux cartes d'E/S", pour cela on cherche dans un premier temps à comprendre ce qui se passe dans le µC.
Comme il n'a pas trouvé d'expert en progammation assembleur, il m'a demandé de jeter un oeil au programme des µC.
Bonjour
Quand on a l'habitude de l'assembleur et du reverse engineering en informatique industrielle, le code est assez simple à lire et à comprendre. Mais (comme l'a suggéré DAUDET78 au #3) cela reste néanmoins un travail qui réclame du temps, et ce n'est pas un « coup d’œil » rapide qui va pouvoir régler l'affaire.
Je doute que la question doive être développée plus avant sur le forum. En effet, les explications des détails du code risquent de vite prendre la tournure d'un véritable cours sur l'assembleur. De plus, d'après ce que je comprends, il s'agit d'un projet professionnel dans lequel on cherche à faire l'économie d'un spécialiste. Or, le forum n'a pas vraiment vocation à prodiguer des formations ou des prestations d'ingénierie gratuites, mais seulement à donner des coups de pouce ponctuels.
Je pense qu'il faudrait que ton ami fasse appel à un professionnel compétent, ou bien, si tu souhaites tout de même faire le travail, que tu commences par lire des cours et des documentations techniques sur l'assembleur, le langage machine et les microprocesseurs (on en trouve facilement sur Internet). Tu pourras toujours revenir nous solliciter si tu as des questions sur des points précis.
En venant sur le forum l'objectif n'est bien entendu pas d'y étudier ou d'y faire étudier l'intégralité du code,
mais d'avoir un coup de pouce pour obtenir un désassemblage correct du programme afin d'avoir une bonne base pour débuter les travaux.
Le terme "coup d'oeil" est relatif, étudier un programme durant plusieurs semaines, ça reste pour moi un coup d'oeil...
Bonjour,
Si tu programmes courrament en vb, fais ton desassembleur, ce n'est pas si difficile que ça, il te faut juste la bible intel sur le 8748, pour ma part j'avais fait un assembleur qui attaquait directement un programmateur de 8748, mais il ya +20 ans de celà !
Bon courage
Merci Claudio pour tes encouragements,
Je viens de commencer de lire la bible Intel 8748, donc ça m'encourage à continuer. Il y a effectivement des similitudes avec les langages que je connais, encore plus avec le C qu'avec le VB j'ai l'impression, notamment le système de pointeur.
Cordialement
Dans ce projet, le plus gros du travail n'est pas le désassemblage, dont la question semble de mon point de vue avoir suffisamment été réglée ici, mais l'analyse et la compréhension du code obtenu.
Contrairement aux langages évolués qui sont plutôt attachés à décrire le travail qu'on veut effectuer, le LM (langage machine) se contente strictement d'énumérer les opérations du processeur. De ce fait, on n'y retrouve pas les mêmes notions.
Certaines opérations du LM n'ont pas leur équivalent en VB ni même en C, et lorsque des concepts de langage évolué sont implémentés en LM, on doit les y découvrir par le biais d'une analyse.
Les variables et les types n'y existent pas a priori. Les octets peuvent aussi bien représenter un code exécutable qu'une donnée de calcul, une information, voire rien du tout d'interprétable. Et ce qu'ils représentent peut évoluer en fonction de l'état du système.
L'analyse du code peut parfaitement mener à modifier le langage assembleur obtenu initialement, que l'interprétation ait été correcte (contenu polymorphe) ou erronée (désassemblage statique désynchronisé).
L'assembleur obtenu par reverse engineering peut donc réserver beaucoup de surprises, et doit être traité au travers d'une analyse itérative sérieuse.
Oui bien sûr, le désassemblage ne permet ici que de débuter les travaux dont le but final est d'interpréter pleinement le code (et d'en faire quelque chose par la suite)
La question du désassemblage est effectivement réglée. D'ailleurs petit résumé pour ce qui aurait besoin de désassembler un programme de microcontroleur Intel 8748 :
- Extraire d'abord le programme du microcontroleur avec un programmateur. Pour ma part j'ai utilisé le Galep 5 de Conitec, mais il en existe d'autres.
Enregistrer le programme au format bin ET au format hex Intel, ce qui permettra de vérifier le code obtenu.
- Désassembler le programme extrait avec un désassembleur. J'ai utilisé dasmx140 (http://myweb.tiscali.co.uk/pclare/DASMx/). Le programme fonctionne sous DOS, il faut désassembler le fichier au format bin.
- J'ai testé le code obtenu avec le logiciel 8048v208, trouvé à cette adresse : http://www.acebus.com/. Ce logiciel permet entre autre d'assembler du code et de simuler le fonctionnement du programme.
En assemblant le code obtenu avec le désassembleur (fichier asm), on peut vérifier qu'on obtient bien un fichier hex identique au fichier hex extrait du microcontroleur. Si tout c'est déroulé sans erreur ce logiciel
permet également de simuler le fonctionnement du programme. Certains des outils courant dans les environnements de développement sont présents (exécution pas à pas, visualisation et modification des entrées/sorties...)
Si le ré-assemblage du code désassemblé donne les mêmes octets qu'au départ, c'est on ne peut plus normal. Cela signifie seulement que le désassemblage fonctionne (... ou bien que l'assembleur fait les mêmes erreurs que le désassembleur).
Mais ça n'implique pas que le code obtenu soit forcément bon.
Seuls une analyse ou un désassemblage dynamique (sur ICE ou simulateur) permet de voir ce qui est réellement exécuté. Sinon, comme je l'ai indiqué, on peut avoir des surprises.
Oui effectivement tu fais bien de le préciser PA5CAL, c'est un point qui manque à mon résumé.
Le fait de retomber sur le fichier hex de départ permet surtout de vérifier que le désassemblage a fonctionné correctement. Mais cela ne veut pas dire qu'on a obtenu un code identique au code écrit par celui qui a réalisé le programme.
Certaines zones du programme peuvent contenir des données et non du code par exemple. Le désassembleur peut difficilement différencier ces zones. Dasmx140 possède une option (Threading) permettant d'effectuer un premier tri entre zones de données et zones de code. Mais le résultat est seulement indicatif, il faudra étudier le programme pour y voir plus clair.
D'ailleurs que l'on active l'option threading ou non, on retombe toujours sur le fichier hex de départ après réassemblage, alors que le code obtenu n'est pas exactement le même.
