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.
|