Je discute avec un ami et nous ne sommes pas d'accord.
Est-il théoriquement possible de faire un décompilateur de langage
machine vers C ?
- je dis non, car il y a perte d'information de structure lors de la
compilation.
- il dit oui, parce que le C étant plus abstrait (plus "haut-niveau"),
il y a plus d'informations dans le langage machine.
Si des spécialistes pouvaient nous éclairer, ce serait très sympa de
leur part...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Stephane Zuckerman
Est-il théoriquement possible de faire un décompilateur de langage machine vers C ? - je dis non, car il y a perte d'information de structure lors de la compilation. - il dit oui, parce que le C étant plus abstrait (plus "haut-niveau"), il y a plus d'informations dans le langage machine.
Il faudrait définir ce que vous attendez d'un décompilateur. En pratique oui je ne vois pas ce qui l'empêcherait. Mais par contre, oubliez toute notion de structure (je ne vois pas comment le compilateur pourrait devenir comment utiliser des structures de données plus compliquées que des tableaux...).
Si des spécialistes pouvaient nous éclairer, ce serait très sympa de leur part... Oui, en tant qu'amateur, ça m'intéresse :-)
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Est-il théoriquement possible de faire un décompilateur de langage
machine vers C ?
- je dis non, car il y a perte d'information de structure lors de la
compilation.
- il dit oui, parce que le C étant plus abstrait (plus "haut-niveau"),
il y a plus d'informations dans le langage machine.
Il faudrait définir ce que vous attendez d'un décompilateur. En pratique
oui je ne vois pas ce qui l'empêcherait. Mais par contre, oubliez toute
notion de structure (je ne vois pas comment le compilateur pourrait
devenir comment utiliser des structures de données plus compliquées que
des tableaux...).
Si des spécialistes pouvaient nous éclairer, ce serait très sympa de
leur part...
Oui, en tant qu'amateur, ça m'intéresse :-)
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
Est-il théoriquement possible de faire un décompilateur de langage machine vers C ? - je dis non, car il y a perte d'information de structure lors de la compilation. - il dit oui, parce que le C étant plus abstrait (plus "haut-niveau"), il y a plus d'informations dans le langage machine.
Il faudrait définir ce que vous attendez d'un décompilateur. En pratique oui je ne vois pas ce qui l'empêcherait. Mais par contre, oubliez toute notion de structure (je ne vois pas comment le compilateur pourrait devenir comment utiliser des structures de données plus compliquées que des tableaux...).
Si des spécialistes pouvaient nous éclairer, ce serait très sympa de leur part... Oui, en tant qu'amateur, ça m'intéresse :-)
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Jean-Baptiste Nivoit
quelque chose comme ceci peut-etre? : http://www.itee.uq.edu.au/~cristina/dcc.html
ceci dit c'est beaucoup + facile de decompiler du java que du C...
jb.
quelque chose comme ceci peut-etre? :
http://www.itee.uq.edu.au/~cristina/dcc.html
ceci dit c'est beaucoup + facile de decompiler du java que du C...
quelque chose comme ceci peut-etre? : http://www.itee.uq.edu.au/~cristina/dcc.html
ceci dit c'est beaucoup + facile de decompiler du java que du C...
jb.
Rakotomandimby Mihamina
Jean-Baptiste Nivoit wrote:
ceci dit c'est beaucoup + facile de decompiler du java que du C...
Je ne sais pas si l'OP a remarqué, mais on ne cross-décompile donc pas: On ne décompile du C qu'en C, du Java en Java...
Parceque j'ai comme préssenti que l'OP voulait décompiler "n'importe quoi" _vers_ du C...
-- Miroir de logiciels libres => http://www.etud-orleans.fr Un Nokia sous Linux, "programmable" en Open Source http://www.nokia.com/770 , http://www.maemo.org/ http://www.maemo.org/platform/docs/tutorials/Maemo_tutorial.html
Jean-Baptiste Nivoit wrote:
ceci dit c'est beaucoup + facile de decompiler du java que du C...
Je ne sais pas si l'OP a remarqué, mais on ne cross-décompile donc pas:
On ne décompile du C qu'en C, du Java en Java...
Parceque j'ai comme préssenti que l'OP voulait décompiler "n'importe
quoi" _vers_ du C...
--
Miroir de logiciels libres => http://www.etud-orleans.fr
Un Nokia sous Linux, "programmable" en Open Source
http://www.nokia.com/770 , http://www.maemo.org/
http://www.maemo.org/platform/docs/tutorials/Maemo_tutorial.html
ceci dit c'est beaucoup + facile de decompiler du java que du C...
Je ne sais pas si l'OP a remarqué, mais on ne cross-décompile donc pas: On ne décompile du C qu'en C, du Java en Java...
Parceque j'ai comme préssenti que l'OP voulait décompiler "n'importe quoi" _vers_ du C...
-- Miroir de logiciels libres => http://www.etud-orleans.fr Un Nokia sous Linux, "programmable" en Open Source http://www.nokia.com/770 , http://www.maemo.org/ http://www.maemo.org/platform/docs/tutorials/Maemo_tutorial.html
Antoine Leca
En <news:42ce9994$0$6580$, Olivier FAURAX va escriure:
Je discute avec un ami et nous ne sommes pas d'accord.
Est-il théoriquement possible de faire un décompilateur de langage machine vers C ?
Sans avoir lu en détail la thèse de Ms Cifuentes (indiquée par Jean-Baptiste, et qui est souvent citée sur ce sujet), et en ajoutant l'hypothèse supplémentaire que le langage machine fut originellement créé par un compilateur C donné, il semble possible à partir d'un « source » en langage machine de créer un programme en langage C, de manière à ce que lorsque ce dernier est recompilé il redonne l'original.
Information complémentaire : un tel décompilateur est lié au compilateur utilisé pour recompiler.
D'autre part, un tel processus ne permet en aucun cas d'inverser le processus de compilation, c'est-à-dire retrouver le texte source (et les options de compilation) qui ont servi originellement à créer le langage machine. En particulier, les commentaires initiaux (fonctionnellement inutiles) et l'orthographe des identificateurs autres que main (dans un programme C, écrire fichier_Entree ou f est équivalent pour le compilateur) ne peuvent pas être retrouvés.
- il dit oui, parce que le C étant plus abstrait (plus "haut-niveau"), il y a plus d'informations dans le langage machine.
J'aurais tendance à penser que l'argument prouve le contraire : s'il y a _plus_ d'informations en langage machine, il existe des quanta d'informations en langage machine qui ne peuvent être représentés en langage C, ce qui rend impossible la « décompilation » de ces quanta. D'ailleurs l'emblématique dcc traduit en langage d'assemblage les parties qu'il ne sait pas correctement décodées.
Antoine
En <news:42ce9994$0$6580$636a15ce@news.free.fr>,
Olivier FAURAX va escriure:
Je discute avec un ami et nous ne sommes pas d'accord.
Est-il théoriquement possible de faire un décompilateur de langage
machine vers C ?
Sans avoir lu en détail la thèse de Ms Cifuentes (indiquée par
Jean-Baptiste, et qui est souvent citée sur ce sujet), et en ajoutant
l'hypothèse supplémentaire que le langage machine fut originellement créé
par un compilateur C donné, il semble possible à partir d'un « source » en
langage machine de créer un programme en langage C, de manière à ce que
lorsque ce dernier est recompilé il redonne l'original.
Information complémentaire : un tel décompilateur est lié au compilateur
utilisé pour recompiler.
D'autre part, un tel processus ne permet en aucun cas d'inverser le
processus de compilation, c'est-à-dire retrouver le texte source (et les
options de compilation) qui ont servi originellement à créer le langage
machine. En particulier, les commentaires initiaux (fonctionnellement
inutiles) et l'orthographe des identificateurs autres que main (dans un
programme C, écrire fichier_Entree ou f est équivalent pour le compilateur)
ne peuvent pas être retrouvés.
- il dit oui, parce que le C étant plus abstrait (plus "haut-niveau"),
il y a plus d'informations dans le langage machine.
J'aurais tendance à penser que l'argument prouve le contraire : s'il y a
_plus_ d'informations en langage machine, il existe des quanta
d'informations en langage machine qui ne peuvent être représentés en langage
C, ce qui rend impossible la « décompilation » de ces quanta.
D'ailleurs l'emblématique dcc traduit en langage d'assemblage les parties
qu'il ne sait pas correctement décodées.
En <news:42ce9994$0$6580$, Olivier FAURAX va escriure:
Je discute avec un ami et nous ne sommes pas d'accord.
Est-il théoriquement possible de faire un décompilateur de langage machine vers C ?
Sans avoir lu en détail la thèse de Ms Cifuentes (indiquée par Jean-Baptiste, et qui est souvent citée sur ce sujet), et en ajoutant l'hypothèse supplémentaire que le langage machine fut originellement créé par un compilateur C donné, il semble possible à partir d'un « source » en langage machine de créer un programme en langage C, de manière à ce que lorsque ce dernier est recompilé il redonne l'original.
Information complémentaire : un tel décompilateur est lié au compilateur utilisé pour recompiler.
D'autre part, un tel processus ne permet en aucun cas d'inverser le processus de compilation, c'est-à-dire retrouver le texte source (et les options de compilation) qui ont servi originellement à créer le langage machine. En particulier, les commentaires initiaux (fonctionnellement inutiles) et l'orthographe des identificateurs autres que main (dans un programme C, écrire fichier_Entree ou f est équivalent pour le compilateur) ne peuvent pas être retrouvés.
- il dit oui, parce que le C étant plus abstrait (plus "haut-niveau"), il y a plus d'informations dans le langage machine.
J'aurais tendance à penser que l'argument prouve le contraire : s'il y a _plus_ d'informations en langage machine, il existe des quanta d'informations en langage machine qui ne peuvent être représentés en langage C, ce qui rend impossible la « décompilation » de ces quanta. D'ailleurs l'emblématique dcc traduit en langage d'assemblage les parties qu'il ne sait pas correctement décodées.
Antoine
Jean-Baptiste Nivoit
Rakotomandimby Mihamina wrote:
Jean-Baptiste Nivoit wrote:
ceci dit c'est beaucoup + facile de decompiler du java que du C...
Je ne sais pas si l'OP a remarqué, mais on ne cross-décompile donc pas: On ne décompile du C qu'en C, du Java en Java...
Parceque j'ai comme préssenti que l'OP voulait décompiler "n'importe quoi" _vers_ du C...
je ne voulais pas parler de decompiler autre chose que du C vers du C,
je soulignais juste que decompiler du byte code java en java etait plus facile, desole si ca n'etait pas clair.
jb.
Rakotomandimby Mihamina wrote:
Jean-Baptiste Nivoit wrote:
ceci dit c'est beaucoup + facile de decompiler du java que du C...
Je ne sais pas si l'OP a remarqué, mais on ne cross-décompile donc pas:
On ne décompile du C qu'en C, du Java en Java...
Parceque j'ai comme préssenti que l'OP voulait décompiler "n'importe
quoi" _vers_ du C...
je ne voulais pas parler de decompiler autre chose que du C vers du C,
je soulignais juste que decompiler du byte code java en java etait plus
facile, desole si ca n'etait pas clair.
ceci dit c'est beaucoup + facile de decompiler du java que du C...
Je ne sais pas si l'OP a remarqué, mais on ne cross-décompile donc pas: On ne décompile du C qu'en C, du Java en Java...
Parceque j'ai comme préssenti que l'OP voulait décompiler "n'importe quoi" _vers_ du C...
je ne voulais pas parler de decompiler autre chose que du C vers du C,
je soulignais juste que decompiler du byte code java en java etait plus facile, desole si ca n'etait pas clair.
jb.
Marc Boyer
Olivier FAURAX a écrit :
Je discute avec un ami et nous ne sommes pas d'accord.
Est-il théoriquement possible de faire un décompilateur de langage machine vers C ? - je dis non, car il y a perte d'information de structure lors de la compilation. - il dit oui, parce que le C étant plus abstrait (plus "haut-niveau"), il y a plus d'informations dans le langage machine.
C'est un non argument: puisque le compilateur n'invente pas la sémantique du programme, il faut bien que toute l'information soit déjà présente dans le code C.
Si des spécialistes pouvaient nous éclairer, ce serait très sympa de leur part...
Que ferait ce décompilateur ?
S'il s'agit de prendre un binaire B, d'en sortir un programme P tel que, une fois P compilé en B', alors les programmes B et B' aient toujours les même comportement, oui, c'est possible et assez facile.
S'il s'agit de prendre B, d'en sortir P tel que, en compilant P avec un compilateur donné, on ressorte exactement B, ça devient plus chaud (mais peut-etre pas infaisable).
Après, si on cherche à retrouver le source S qui, une fois compilé avec un compilo donnée, a donné B, c'est impossible, à moins que le compilo soit très gentil.
L'opposition entre toi et ton ami vient que vous ne cherchez pas la même information. Lui s'intéresse à l'information des comportements, toi à celle de la structure.
Après, on peut pinailler: la norme C définit un certain nombre de comportements "observables", et le compilateur respecte cela. Mais la norme ne dit pas combien de cycles doit prendre une instruction. Si j'écris: x= 2*y; le compilateur est libre de calculer X en demandant au processeur de faire la multiplication, un décalage à gauche d'un bit (sous reserve du bit de signe), ou en additionnant Y avec lui même. Idem si j'écris x= y+y; Quelle est l'information pertinente alors ?
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
Olivier FAURAX <faurax@emse.fr.invalid> a écrit :
Je discute avec un ami et nous ne sommes pas d'accord.
Est-il théoriquement possible de faire un décompilateur de langage
machine vers C ?
- je dis non, car il y a perte d'information de structure lors de la
compilation.
- il dit oui, parce que le C étant plus abstrait (plus "haut-niveau"),
il y a plus d'informations dans le langage machine.
C'est un non argument: puisque le compilateur n'invente pas
la sémantique du programme, il faut bien que toute l'information
soit déjà présente dans le code C.
Si des spécialistes pouvaient nous éclairer, ce serait très sympa de
leur part...
Que ferait ce décompilateur ?
S'il s'agit de prendre un binaire B, d'en sortir un programme
P tel que, une fois P compilé en B', alors les programmes
B et B' aient toujours les même comportement, oui,
c'est possible et assez facile.
S'il s'agit de prendre B, d'en sortir P tel que, en
compilant P avec un compilateur donné, on ressorte
exactement B, ça devient plus chaud (mais peut-etre
pas infaisable).
Après, si on cherche à retrouver le source S qui,
une fois compilé avec un compilo donnée, a donné B,
c'est impossible, à moins que le compilo soit très
gentil.
L'opposition entre toi et ton ami vient que vous
ne cherchez pas la même information. Lui s'intéresse
à l'information des comportements, toi à celle de la
structure.
Après, on peut pinailler: la norme C définit un certain
nombre de comportements "observables", et le compilateur
respecte cela. Mais la norme ne dit pas combien de cycles
doit prendre une instruction.
Si j'écris:
x= 2*y;
le compilateur est libre de calculer X en demandant
au processeur de faire la multiplication, un décalage
à gauche d'un bit (sous reserve du bit de signe),
ou en additionnant Y avec lui même.
Idem si j'écris
x= y+y;
Quelle est l'information pertinente alors ?
Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?
Je discute avec un ami et nous ne sommes pas d'accord.
Est-il théoriquement possible de faire un décompilateur de langage machine vers C ? - je dis non, car il y a perte d'information de structure lors de la compilation. - il dit oui, parce que le C étant plus abstrait (plus "haut-niveau"), il y a plus d'informations dans le langage machine.
C'est un non argument: puisque le compilateur n'invente pas la sémantique du programme, il faut bien que toute l'information soit déjà présente dans le code C.
Si des spécialistes pouvaient nous éclairer, ce serait très sympa de leur part...
Que ferait ce décompilateur ?
S'il s'agit de prendre un binaire B, d'en sortir un programme P tel que, une fois P compilé en B', alors les programmes B et B' aient toujours les même comportement, oui, c'est possible et assez facile.
S'il s'agit de prendre B, d'en sortir P tel que, en compilant P avec un compilateur donné, on ressorte exactement B, ça devient plus chaud (mais peut-etre pas infaisable).
Après, si on cherche à retrouver le source S qui, une fois compilé avec un compilo donnée, a donné B, c'est impossible, à moins que le compilo soit très gentil.
L'opposition entre toi et ton ami vient que vous ne cherchez pas la même information. Lui s'intéresse à l'information des comportements, toi à celle de la structure.
Après, on peut pinailler: la norme C définit un certain nombre de comportements "observables", et le compilateur respecte cela. Mais la norme ne dit pas combien de cycles doit prendre une instruction. Si j'écris: x= 2*y; le compilateur est libre de calculer X en demandant au processeur de faire la multiplication, un décalage à gauche d'un bit (sous reserve du bit de signe), ou en additionnant Y avec lui même. Idem si j'écris x= y+y; Quelle est l'information pertinente alors ?
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
Okerampa
S'il s'agit de prendre un binaire B, d'en sortir un programme P tel que, une fois P compilé en B', alors les programmes B et B' aient toujours les même comportement, oui, c'est possible et assez facile.
S'il s'agit de prendre B, d'en sortir P tel que, en compilant P avec un compilateur donné, on ressorte exactement B, ça devient plus chaud (mais peut-etre pas infaisable).
Après, si on cherche à retrouver le source S qui, une fois compilé avec un compilo donnée, a donné B, c'est impossible, à moins que le compilo soit très gentil.
L'opposition entre toi et ton ami vient que vous ne cherchez pas la même information. Lui s'intéresse à l'information des comportements, toi à celle de la structure.
Ce que j'en pense, étant en stage de métacompilation...
J'ajouterais qu'il est impossible de récupérer la structure. Et impossible en partant des instructions d'en arriver à l'algorithme. Sinon à partir de l'assembleur on pourrait en arriver à déduire toute la structure d'un programme, et l'UML de Windows seraient déjà en libre circulation sur le net :p Ne serait-ce (très bas niveau) qu'un code avec des tests type JNE (jump not equal) qui pourraient se traduire en "if" ou en "for" selon qu'on pense que c'est une boucle for ou un nombre fini de tests. De la même manière on ne peut pas retrouver le nom des variables, ni la structure des fonctions facilement (l'inlinage etc.), les déclarations de fonction, ... De quoi rendre le code illisible.
Ton code assembleur est plus gros, mais contient moins d'informations effectivement au niveau structure. Je m'avance peut être un peu, mais je pense que dcc est loin de marcher dans tous les cas. Tu devras plus ou moins réinterpréter toi même le code. D'ailleurs en parlant de Java, il existe quand même des obfuscateurs de code qui rendent la décompilation assez moche.
S'il s'agit de prendre un binaire B, d'en sortir un programme
P tel que, une fois P compilé en B', alors les programmes
B et B' aient toujours les même comportement, oui,
c'est possible et assez facile.
S'il s'agit de prendre B, d'en sortir P tel que, en
compilant P avec un compilateur donné, on ressorte
exactement B, ça devient plus chaud (mais peut-etre
pas infaisable).
Après, si on cherche à retrouver le source S qui,
une fois compilé avec un compilo donnée, a donné B,
c'est impossible, à moins que le compilo soit très
gentil.
L'opposition entre toi et ton ami vient que vous
ne cherchez pas la même information. Lui s'intéresse
à l'information des comportements, toi à celle de la
structure.
Ce que j'en pense, étant en stage de métacompilation...
J'ajouterais qu'il est impossible de récupérer la structure. Et
impossible en partant des instructions d'en arriver à l'algorithme.
Sinon à partir de l'assembleur on pourrait en arriver à déduire
toute la structure d'un programme, et l'UML de Windows seraient déjà
en libre circulation sur le net :p
Ne serait-ce (très bas niveau) qu'un code avec des tests type JNE
(jump not equal) qui pourraient se traduire en "if" ou en "for" selon
qu'on pense que c'est une boucle for ou un nombre fini de tests. De la
même manière on ne peut pas retrouver le nom des variables, ni la
structure des fonctions facilement (l'inlinage etc.), les déclarations
de fonction, ...
De quoi rendre le code illisible.
Ton code assembleur est plus gros, mais contient moins d'informations
effectivement au niveau structure.
Je m'avance peut être un peu, mais je pense que dcc est loin de
marcher dans tous les cas. Tu devras plus ou moins réinterpréter toi
même le code.
D'ailleurs en parlant de Java, il existe quand même des obfuscateurs
de code qui rendent la décompilation assez moche.
S'il s'agit de prendre un binaire B, d'en sortir un programme P tel que, une fois P compilé en B', alors les programmes B et B' aient toujours les même comportement, oui, c'est possible et assez facile.
S'il s'agit de prendre B, d'en sortir P tel que, en compilant P avec un compilateur donné, on ressorte exactement B, ça devient plus chaud (mais peut-etre pas infaisable).
Après, si on cherche à retrouver le source S qui, une fois compilé avec un compilo donnée, a donné B, c'est impossible, à moins que le compilo soit très gentil.
L'opposition entre toi et ton ami vient que vous ne cherchez pas la même information. Lui s'intéresse à l'information des comportements, toi à celle de la structure.
Ce que j'en pense, étant en stage de métacompilation...
J'ajouterais qu'il est impossible de récupérer la structure. Et impossible en partant des instructions d'en arriver à l'algorithme. Sinon à partir de l'assembleur on pourrait en arriver à déduire toute la structure d'un programme, et l'UML de Windows seraient déjà en libre circulation sur le net :p Ne serait-ce (très bas niveau) qu'un code avec des tests type JNE (jump not equal) qui pourraient se traduire en "if" ou en "for" selon qu'on pense que c'est une boucle for ou un nombre fini de tests. De la même manière on ne peut pas retrouver le nom des variables, ni la structure des fonctions facilement (l'inlinage etc.), les déclarations de fonction, ... De quoi rendre le code illisible.
Ton code assembleur est plus gros, mais contient moins d'informations effectivement au niveau structure. Je m'avance peut être un peu, mais je pense que dcc est loin de marcher dans tous les cas. Tu devras plus ou moins réinterpréter toi même le code. D'ailleurs en parlant de Java, il existe quand même des obfuscateurs de code qui rendent la décompilation assez moche.
