Discussion :

[boubounagh]

bonjour,

je ne sais pas est ce que c'est le bon endroit de poster ma question ou non mais bon je n'est pas trouvé une autre rubrique meilleure.

selon le titre de mon problème je veux savoir est ce qu'il y a des outils qui permettent de récupérer le code source à partir de son exécutable(je sais bien que c'est illégal mais je veux savoir).

selon la recherche que j'ai déjà fait qu'il n'y a pas des décompilateurs mais ils existent de désassembleur tel que IDA, WinDbg et OllyDbg.

mais le pb que ces logiciels permet de donner le code assembleur et non pas le code source.

j'ai trouvé également C-decompiler (qui en principe un décompilateur C) mais j'ai pas pu le télécharger.

s'il vous plait est ce quelqu'un peut m'aider et me donner plus d'informations sur ce domaine.

[Obsidian]

Bonjour,

Non, il n'est pas possible de retrouver le code source original à partir d'un exécutable, pour la bonne raison qu'un code source C ou C++ est en fait une route à suivre par le compilateur qui, lui, va produire du code en langage machine et même éventuellement l'optimiser.

Seules exceptions : certains désassembleurs sont suffisamment intelligents pour, par exemple, t'indiquer en commentaire à quel objet on accède quand l'info est disponible, mais cela reste très loin du code source.

Il arrive également que ces exécutables soient compilés avec les infos de déboguage. Dans ce cas, il peuvent embarquer une partie du code source original mais, généralement, il ne s'agit que de référence vers le fichier source qui doit se trouver à proximité.

[boubounagh]

pourquoi pour le Java il existe et pour le .Net il existe Reflector et pour le C il n'existe pas?

[Obsidian]

Réponse courte : parce que Java et .Net ne produisent pas de langage machine (pas par défaut en tout cas). Également parce que C et Java sont deux langages qui n'ont rien à voir entre eux (beaucoup d'étudiants, malheureusement, choisissent Java parce que « c'est comme le C mais sans les pointeurs »).

Réponse un peu plus détaillée : quand tu compiles un programme Java, tu ne produis pas du langage machine mais du bytecode, dont tu trouveras la liste ici. Les opérations du bytecode sont très élémentaires mais elles sont définies par la norme et elles sont censées être les mêmes partout. Il y a donc une relation bien définie entre le code source Java et le bytecode produit en conséquence. D'autre part, un programme en bytecode Java s'appuie quand même sur une infrastructure objet : typiquement, « new » crée un nouvel objet et renvoie une référence dessus. Or, rien ne t'indique dans cette instruction de quelle manière cet objet doit être créé et géré. Ça implique au minimum l'appel à une routine capable d'allouer de la mémoire, de gérer sa fragmentation, de retrouver dans une table l'objet à initialiser et d'appeler ses constructeurs. Donc : du code dans un langage encore en dessous du bytecode.

Tes programmes Java sont exécutés en fait exécutés par la JVM qui est un logiciel remplissant toutes ces tâches et interprétant ton code. Et cette JVM est écrite… en C !

De son côté, le langage C, lui, a été conçu pour travailler sans framework sous-jacent et de proposer un modèle qui est très proche du fonctionnement réel d'un micro-processeur, en général. C'est pour cela qu'on a souvent coutume de dire qu'il se trouve « un cran au dessus de l'assembleur ».

C'est en fait à ça que sert le langage C, et c'est aussi pourquoi il est toujours aussi populaire 40 ans après sa naissance. Il sert à produire du code en langage machine le plus concis et le plus indépendant possible sans avoir à écrire spécifiquement de l'assembleur, dont le premier inconvénient est d'être spécifique à chaque famille de processeurs. Ça implique également deux choses :

• Un même programme C va être pouvoir compilé en plusieurs assembleurs différents selon la plate-forme cible ;
• Tout ce qui peut être résolu à la compilation va l'être. En particulier, si tu appelles une fonction « mafonction() » déclarée statique et dans le même fichier que l'appelant, alors le micro-processeur n'a absolument pas besoin de connaître le nom de cette fonction. Tout ce qui lui faut, c'est son adresse en mémoire pour y poursuivre l'exécution. Rien que pour cela, tu ne pourras pas retrouver à partir d'un programme compilé un code source dans lequel il soit clairement écrit « mafonction() ».

[boubounagh]

bonjour,

Merci pour votre réponse mais en principe selon la recherche que j'ai effectué j'ai trouvé les deux logiciels suivants Boomerang et C-Decompiler qu'en principe permet de trouver le code source à partir de l'exécutable mais le problème j'ai pas pu les télécharger avez vous une idée sur ce deux logiciels et comment je peux les installer?

[Obsidian]

Comme je te l'ai dit, toutes les fonctions internes à un même logiciel sont résolues à la compilation et tu n'en retrouveras ni les noms ni les prototypes officiels. Par contre, les appels aux fonctions de tes bibliothèques (DLL) eux se font toujours à travers leur nom explicite, car c'est le seul moyen de les résoudre a posteriori (à l'exécution).

Ça veut dire que tu pourras quand même visualiser tous les appels systèmes et aux fonctions des bibliothèques. Ton décompilateur pourra également deviner les déclarations de variables dans une certaine mesure, là encore sans pouvoir les nommer sauf s'il s'agit de globales externes. Et c'est à peu près tout.

Tu vas obtenir un code qui « ressemble à du C », que tu pourras éventuellement compiler, mais tu n'auras aucune structuration propre de tes fichiers, aucun commentaire original (à la limite, tu auras les notes de ton décompilateur), aucune macro #define originale non plus, etc. Fais une recherche et tu verras que les captures d'écran te présentent du code comme « proc_1(), proc_2(), proc_3() ».

Bref, ce sera peut-être un poil plus lisible que de l'assembleur brut, certes, mais ça ne te permettra jamais de revenir à 100 % au code source initial.