avoir le .c depuis l'.exe

J'avais déjà dit ça ailleurs, la compilation n'est pas bijective :


Pour te donner une exemple, le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

int a; a= 2; if(a==2*3+1) { int a = 1; } else { a = 2; }

---

Va déjà être passé en code 3 adresses (avant d'être compilé) qui ressemblent à ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

/*variable utilisateur*/ int u1, u2; /*variable temporaire*/ int v1,v2; bool v3;   u1 = 2; v1 = 2; v2 = 3; v1 = v1 * v2; v2 = 1; v1 = v1 + v2; u1 = v1; v3 = u1==v1 if(!v3) goto else u2 = 1; goto fin else: u1 = 2; fin:

---

Il a perte d'information : au niveau des structures de contrôles, au niveau du nom des variables. Et il y a ajout de variables temporaires. Evidemment l'exemple que j'ai donné dépend du code 3 adresses que l'on choisi.
Tu pourras également remarquer que 2 variables déclarées dans deux blocs différents ont des noms différents.

D'ailleurs, si l'on compile avec -S -O0, on trouve le code assembleur suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

/*on met 2 dans a qui est représenté par un registre = la pile ici*/ movl $2, -4(%ebp) cmpl $7, -4(%ebp) /*on voit qu'il a optimisé la partie 2*3+1 que j'avais découpé*/ jne L2 /*on met dans une autre partie de la pile, pas comme a*/ movl $1, -8(%ebp) jmp L3 L2: /*on met bien dans a*/ movl $2, -4(%ebp) L3:

---

Ce qui serait équivalent au code 3 adresses :

Code:

---

1 2 3 4 5 6 7 8

v1 = 2; if(!v1==7) goto L2 v2 = 1; goto L3: L2: v1 = 2; L3:

---

Si tu testes, tu peux te rendre compte que le code d'origine (je parle sans optimisation) est totalement équivalent dans le code exe à :

Code:

---

1 2 3 4 5 6 7 8

int d; int salut; d= 2; if(d==7) salut = 1; else d = 2;

---

Si tu fais une optimisation, tout le bloc des if/else va disparaitre... C'est à dire que l'on aurait juste :

Code:

---

1 2 3

int d; d= 2;

---

Donc quand bien même on arriverait à obtenir un code C à partir d'un exe(après conversion : exe -> assembleur -> C) on obtiendrait un code avec perte d'information et optimisé donc le code ne peut pas être exacte.

Citation:

---

Envoyé par Shugo78

on obtiendrait un code avec perte d'information

---

Non ce n'est pas une perte d'information, enfin pas du point de vue de l'execution[1]. Puisqu'il s'agit de code inutile mais de code qui ne s'executera jamais ce n'est pas de l'information (information implique un caractere utile) tout au plus du bruit.

Citation:

---

Envoyé par Shugo78

et optimisé donc le code ne peut pas être exact.

---

Qu'entends tu par exact ?

* un code strictement identique au code initial (la effectivement, sauf cas particulier ou coup de chance c'est peu probable)
* un code correct produisant le meme executable (ce qui est le but recherche de ce style d'outil)


[1] du point de vue du developpeur, ca peut etre une pert d'information. Mais a cote de la suppression des commentaires et de la perte des noms la suppression de code inutile est anectodique.

Ce n'est pas vrai, imagine qu'on lise la valeur de A dans un fichier, lors de l'éxécution la valeur de A est de 2 donc les conditions qui sont censée être inutiles sont supprimées et sur un autre ordinateur la valeur de A rempli la condition qui à été supprimée le code ne serait pas fiable.

Citation:

---

Envoyé par Shugo78

Ce n'est pas vrai, imagine qu'on lise la valeur de A dans un fichier, lors de l'éxécution la valeur de A est de 2 donc les conditions qui sont censée être inutiles sont supprimées

---

C'est un mauvais compilateur.

Si il voit quelque chose du genre :

Code:

---

1 2 3 4

int a; a = fonction(); if(a!=2)

---

Ou :

Code:

---

1 2 3 4

int a; a = 2; if(a!=2)

---

Ces deux codes sont très différents car le compilateur ne va pas chercher à prédire le retour de la fonction. Dans le premier cas, il ne fera pas d'optimisation, dans le deuxième, il connaitre de manière sûr et déterministe la valeur de a à ce moment.

Il faut bien noter qu'un code (horrible certes) du genre :

Code:

---

1 2 3 4 5 6 7

int a; int * i = (int*) ((size_t) &a);   a = 2; *i = 3; if(a!=2)

---

Il y a une probabilité non nul que i pointe vers a (même si je n'ai pas directement écrit : int *i = &a. Il ne fera normalement pas d'optimisation car il est probable que a change de valeur. Mais le compilateur risque d'avoir beaucoup de mal à savoir que i pointe sur a.

Il peut y avoir un équivalent encore plus méchant (qui marche lorsque la pile est orientée dans le ce sens et si on a de la chance que le compilateur n'ait pas modifié l'ordre de déclaration des variables) :

Code:

---

1 2 3 4 5 6 7 8 9

/* ceci est un code d'exemple, celui qui l'utilise dans une vrai application   * risque d'avoir des soucis :aie:   */ int * i = (int*)&i -1 ; int a; a = 3;   *i = 2; //maintenant, a = 2

---

Citation:

---

Envoyé par Shugo78

Ce n'est pas vrai, imagine qu'on lise la valeur de A dans un fichier, lors de l'éxécution la valeur de A est de 2 donc les conditions qui sont censée être inutiles sont supprimées et sur un autre ordinateur la valeur de A rempli la condition qui à été supprimée le code ne serait pas fiable.

---

C'est un exemple qui ne correspond pas du tout au cas qui a ete evoque et la ce n'est pas un probleme de decompilateur ou autre mais carrement de compilateur puique meme l'executable obtenu a partir du source original ne serait pas fonctionnel.

Un cas qui peut par contre se produire (et se produira forcement a un moment ou a un autre) est la substitution de "constantes" dont la valeur depends de la plateforme (typiquement les sizeof). Le code obtebu ne sera donc effectivement pas portable, mais reste correct sur la plateforme d'origine.

Il faut bien etre conscient qu'aussi bon soit-il un decompilateur n'est qu'un outil et comme tout outil a des limites d'utilisation. Ce n'est pas une baguette magique.

Citation:

---

Envoyé par Davidbrcz

Pour enfoncer le clou :

Citation:

---

As tu déja réussi a crée une vache a partir de 400 Kg de steack haché ?

---

Et ben pour retrouver les sources a partir de l'exécutable, c'est la même chose.

---

Je pense que tu (et c'est aussi vrai pour Shugo78, d'ou peut etre sa "critique", en partie justifiee, vis a vis de ce type d'outil) te meprends sur le role de ces outils.

Leur but n'est pas de faire de la gestion de source ou de la sauvegarde. Tu ne vas pas effacer les sources d'un logiciel sous pretexte que tu as l'executable et un decompilateur. Ni de retrouver a la virgule pres le code source d'un logiciel

Ces logiciels servent pour faire du reverse engeenering, pour apporter une correction/modification sur un programme dont les sources ont ete par accident perdues, etc.
Bref dans toutes les phases ou sans eux il est indispensable de travailler dans le binaire ou dans le code desassemble. Et a ce titre ils sont bel et bien utiles.

C'est vrai mais cela ne porte t-il pas atteinte au droits d'auteur si je peux m'exprimer ainsi du programmeur ?

Citation:

---

Envoyé par Shugo78

C'est vrai mais cela ne porte t-il pas atteinte au droits d'auteur si je peux m'exprimer ainsi du programmeur ?

---

Pas forcement, si tu es dans une entreprise et que tu dois reprendre une application dont les sources ont été perdu, tu peux faire du reverse.

Il est également possible de faire du reverse si c'est dans le but d'assurer l'interopérabilité de l'application avec d'autres systèmes, mais tu ne dois pas diffuser plus d'informations que ce qui est strictement nécessaire pour l'intéropérabilité.

Par exemple pour l'iPod, il est nécessaire de faire du reverse sur le code qu'il y a dans l'ipod pour savoir comment mettre linux dessus.

Oui mais tout le monde ne souhaite pas que l'on puisse faire ça avec son code.

Mais d'un certain sens il est vrai que cela peut être indispensable dans certains cas, mais lmieu vaut comme même faire des sauvegardes :mouarf:.

Citation:

---

Envoyé par Shugo78

Mais d'un certain sens il est vrai que cela peut être indispensable dans certains cas, mais lmieu vaut comme même faire des sauvegardes :mouarf:.

---

Ce n'est pas incompatible et ca ne vise pas le meme objectif. Ce ne sont pas les sauvegardes de mes programmes qui vont me permettre de comprendre le format des fichiers du soft de quelqu'un d'autre et de pouvoir les ouvrir :lol:

Plus serieusement, il existe des cas (dependant des pays et e leur legislation) ou le reverse est legal. L'interoperabilite est un cas frequent.

Dans quels pays(en tout cas pas chez Bill Gate :mouarf:) ?
Non sérieusement je n'en doute pas mais des gens doivent quand même abuser de ces procédés, non ?
C'est tout de même risqué si on autorise ça, mais cela peut être obligatoire.

Citation:

---

Envoyé par Shugo78

Non sérieusement je n'en doute pas mais des gens doivent
quand même abuser de ces procédés, non ?
C'est tout de même risqué si on autorise ça, mais cela peut être obligatoire.

---

Oui bien sur que certaines personnes abusent de ca.
Mais je ne vois pas en quoi c'est risque de l'autoriser dans certains. Je ne pense pas que les personnes qui le font illegalement lorsque c'est autorise dans certains cas particuliers ne le feraient pas si c'etait totalement interdit.

Le seul probleme qui peut eventuellement apparaitre dans ce cas, c'est l'usage illegale en toute bonne foi, mais ca reste marginal.

Encore heureux mais les licenses ?
C'est autorisé en France ?

Bonsoir,
tu peux décompiler certains programmes, mais dit toi que les grosses boites rendent la décompilation (quasi)impossible.
Cherche obfuscateur.
Tu devrais avoir de la documentation.

Franchement, je pense pas que beaucoup de boite s'amuse à obfusquer leur code...

Faut quand même enir vachement à son code pour payer quelqu'un et sacrifier du temps d'éxecution en échange d'une sécuritée.

C'est dure de décompiler un EXE ?

Une idée comment ca marche ?

Si tu as la spécification du format PE et le "PROGRAMMER'S REFERENCE MANUEL" pour le processeur adéquat, ça devrait pas être violent, mais tout de même assez long.

Par exemple pour le motorola 68k : http://www.freescale.com/files/archi.../M68000PRM.pdf (maintenant, je ne vois pas trop l'interêt de faire ça...). C'est sympa de décompiler 3 instructions machines à la main, une fois que t'as compris, tu passes ton chemin.

Uoi t'as raison , merci pour cette explication ...