Conversion d'un fichier .exe en C ou C++

Signaler
Messages postés
7
Date d'inscription
mercredi 4 août 2004
Statut
Membre
Dernière intervention
16 septembre 2008
-
Messages postés
202
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019
-
[size= 12] decodman [:o)=12
Salut tout le monde! Si c'est possible, est ce que vous pouvez m'aider à trouver un code source en ASM qui permetra de convertir un fichier .exe en un langage de haut niveau comme C ou c++

5 réponses

Messages postés
2023
Date d'inscription
mardi 24 septembre 2002
Statut
Membre
Dernière intervention
28 juillet 2008
5
Je ne crois pas qu'il existe de tel programme, au mieux tu peux désassembler un exécutable, cad le convertir en code ASM, mais c'est tout.
Messages postés
6535
Date d'inscription
lundi 16 décembre 2002
Statut
Modérateur
Dernière intervention
22 août 2010
7
Si tu trouves ca je pense que ca intéressera pas mal de gens
Messages postés
298
Date d'inscription
jeudi 12 juin 2003
Statut
Membre
Dernière intervention
9 juillet 2008
1
ça va interesser touuuuuuuuuut le monde...se sera une evolution ou plutot une catastrophe :)
convertir un exe en langage de haut niveau est presque impossible (par contre en ASM no probleme)
meme les elites des programmeurs dans le monde ne peuvent pas le faire, en faite il est plus facile de developper à nouveau une application similaire à l'application concerné que d'obtenir son code source apartir de l'exe.
Messages postés
7
Date d'inscription
mercredi 4 août 2004
Statut
Membre
Dernière intervention
16 septembre 2008

Est ce que vous pouvez me donner un peu de modèle de code source qui permet de transformer un exe en ASM. Si possible avec les fonctions nécessaires, vous pourriez m'éclaircir un peu plus. Merci d'avance.
Messages postés
202
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019

Ca existe, on appelle ça un décompilateur.

Le problème pour décompiler un programme exécutable est qu'il faut bien connaitre la façon dont un compilateur a produit le code de l'exécutable, car cela varie beaucoup d'une version à l'autre, et car les compilateurs, en ne cessant de s'améliorer, chamboulent complètement le code initial en un code "équivalent" mais plus optimisé en fonction de l'architecture finale. On peut donc décompiler certains programmes avec un décompilateur donné, mais pas forcément bien les autres.

Autre problème: le code "décompilé" sera dépourvu des commentaires initiaux, et souvent totalement dépourvu du nom des variables et de pas mal de fonctions (non liées par nom à une librairie partagée externe) si le programme a fait l'objet d'une suppression des données de débogage. Le décompilateur tentera alors seulement de créer des noms de variables en fonction des types de données qu'il aura pu "déduire" et de ce qu'il sait de la plateforme sur lequel le programme est sensé tourner (les API système, les structures de données système). Mais rapidement il se heurtera à l'utilisation de nombreuses autres librairies tierces (indépendantes du système et aillant chacune leur propre version).

Le code obtenu sera difficilement lisible car tout ne pourra pas être déduit (notamment de nombreuses constantes auront des valeurs "magiques" car précalculées par le compilateur sans savoir comment elles ont été obtenues.

Au mieux, on peut éventuellement obtenir un code C (voire C++) immédiatement recompilable tel quel mais très difficile à modifier (car le code source cachera pas mal de déductions faites par le compilateur d'origine, dont de nombreuses dépendances et interactions, qu'il va vous falloir déduire avec votre propre intelligence). C'est peut-être plus pratique pour certains d'analyser un code ainsi converti avec difficulté en C ou C++, que le code en assembleur, mais la puissance expressive du C/C++ sera rarement bien meilleure que celle de l'assembleur. De plus convertir un code assembleur en C ne garantit pas qu'en recompilant ce code C (en assembleur puis code binaire) on obtiendra exactement les mêmes résultats, car chaque compilateur C va réorganiser le code et éventuellement d'une façon inattendue incompatible avec ce que faisait réellement l'ancien programme dont le code source original mentionnait des contraintes pour le compilateur, contraintes supprimée lors de la compilation originale dans le code exécutable obtenu.

En revanche, la décompilation d'un programme compilé en Java ou C# (ou un code intermédiare pour une machine virtuelle) a de bonnes chances d'obtenir quelquechose de très lisible et facile à exploiter, puisque la partie finale de la compilation en code exécutable n'est pas faite par le compilateur d'origine en présumant d'une plateforme théorique (non optimale) mais directement sur la machine hôte (où des optimisations supplémentaires et plus pertinentes seront possibles). C'est une raison supplémentaire du succès des langages à machine virtuelle, qui arrivent à battre maintenant en performance un certain nombre de programmes même ecrits en C ou assembleur (car ces derniers nepeuvent être optimisés que pour un nombre très restrictif de machines cibles, ou doivent être compilés en autant de versions que de machines cible, ce qui est devenu un véritable casse-tête avec la multiplication des plateformes dites "compatibles" mais qui ont des comportements et performances très différentes).

Raison de plus pour s'intéresser aux langages qui se compilent en deux passes: une compilation unique pour une machine virtuelle bien testée, l'autre réalisée par la machine hôte elle-même. De plus, cela permet de mieux tester l'application elle-même, et de diviser la tâche de façon plus efficace d'autres se chargeant de tester les machines hôtes et de les optimiser et les certifier dans un effort commun qu'aucun programmeur ne pourrait aujourd'hui réaliser seul.