Version imprimable
Bonjour à tous,
j'ai codé une appli en java et il faudrait que les sources de cette appli ne soient pas accessibles or le code java est facilement décompilable, d'où ma question, existe-t'il un moyen de rendre son code indécompilable ?
Merci à vous :)
Bien sûr que non, mais tu peux toujours compliquer la compréhension de cette décompilation avec un obfuscateur. Genre ProGuard ou yGuard.
Par contre, je te préviens, c'est la porte ouverte à de nombreux ennuis.
La faute à cette volonté de rendre les choses indécompilables, totalement déraisonnable. Pour l'amour du ciel, la compilation ne consiste pas à cacher le code source, elle consiste à transformer le code source en une chose facilement exécutable. Jamais il n'a été question de cacher le fonctionnement, ce n'était qu'un effet secondaire et gênant.
je suis d'accord avec toi sur le but de la compilation mais dans ce cas comment fournir une application à des clients tout en rendant les sources inaccessibles ?Citation:
Envoyé par thelvin
Ma foi, je dirais que c'est impossible, tout comme faire tenir un éléphant en équilibre sur sa trompe.
Tout aussi difficile l'un que l'autre, et tout autant à gagner si seulement on y arrivait.
Non, moqueries à part, pour essayer de faire ça en Java je ne vois que l'obfuscation, qui apporte beaucoup de problèmes et aucun avantage mis à part une certaine tranquillité d'esprit basée sur l'illusion d'avoir accompli un but qui avait l'air nécessaire.
L'obfuscation complique vraiment la vie de celui qui essaie de lire le code source. Le truc, c'est qu'on se demande bien l'intérêt de lui compliquer la vie. Comme si le fait de ne pas lui donner le code source n'était pas déjà suffisant dans cette poursuite de l'inutile.
je ne veux pas que mon code source soit lisible car je développe une appli pour mon boulot, elle va être disctribuée à des clients qui auront payé et on souhaite donc la protéger... l'open source c'est très bien je suis d'accord mais là dans mon cas l'appli doit être protégée. C'est normal, il y a des enjeux économiques derrière.Citation:
Envoyé par thelvin
L'obfuscation empeche de lire du code source qui a été obtenu pas décompilation.
Avantage:
- si vous vendez votre logiciel, le client ne pourra pas regarder dans les sources ni revendre les sources
- le programme peut etre plus rapide (je ne sais pas en fait, il faudrait vérifier)
Inconvénients:
- l'obfuscation peut être buggé, il faut tester le logiciel après obfuscation, cela ajoute de la lourdeur
- quand le logiciel plante, les logs sont difficiles à lire et c'est plus difficile à débugger, mais cela reste faisable
Si j'ai un conseil à donner, il faut utiliser l'obfuscation pour les parties vraiment stratégique du programme, là où il y a l'algorithmique ou la valeur ajouté du programme par rapport aux concurrents, pas la peine de tout obfusquer
j'ai entendu dire qu'à chaque obfuscateur il y avait un desobfuscateur, est-ce vrai ? si c'est le cas, mon appli ne sera pas réellement protégée ?Citation:
Envoyé par toto828
Peut être oui, mais peut etre que le desobfuscateur est seulement utilisable par qui a obfusqué. En gros, l'obfuscateur change le nom des méthodes par des "a" et des "b" ainsi que le nom des variables, ça rend le code illisible. Je ne vois pas comment on peut revenir en arrière.
Fait une petite recherche google.
Protéger l'appli est le travail du copyright, pas de la compilation.Citation:
Envoyé par _LittleFlea_
Je comprends qu'on puisse n'avoir aucun intérêt pour l'open source, raison pour laquelle je ne cherche pas à pointer les nombreux avantages à fournir le code source avec l'appli.
Mais l'obfuscation, et toute autre méthode d'empêcher la tentative de décompilation, est source de gros problèmes, qui eux ont un vrai coût concret, contrairement à la vague possibilité que les clients violent le copyright et le contrat d'utilisation de l'application et qu'une réparation ne puisse pas être exigée en conséquence.
Je dis les choses comme elles sont, pour protéger tes intérêts et ton retour sur investissement, à toi et à tes employeurs/sponsors/je ne sais quoi. Les mécanismes de protection anti-décompilation sont souvent, et en Java toujours, des escroqueries visant à facturer plus cher un produit de qualité égale ou moindre. Tu me crois ou tu ne me crois pas, peu m'importe, mais je pense que tu as plus besoin de ces explications que d'être encouragé à t'entêter.
Quant aux désobfuscateurs, il y en a bien plus d'un par obfuscateur, mais ils ne servent qu'à guider le travail, ils ne peuvent pas rétablir les choses comme avant.
Je plussoie ce qui a pu être dit avant: compiler n'a pas pour but d'obfusquer.
Néanmoins si on veut protéger son code (pour diverses raisons, pas seulement le copyright) ça reste une manière relativement efficace.
A noter qu'une autre méthode un peu plus radicale est de compiler le programme Java en code natif, avec GCJ par exemple (il existe des solutions payantes qui seraient mieux abouties, paraît-il). Mais ça reste à prendre avec des pincettes et à tester au cas pas cas:
- non seulement ça ôte de fait la portabilité du programme (un des atouts de Java) car il faudra compiler pour chaque plateforme cible.
- mais j'ai déjà entendu dire ça et là que GCJ n'était pas parfait et qu'un test approfondi du programme après compilation en code natif s'avérait plus que prudente.
Ca dépend du logiciel aussi, il faut connaitre le contexte avant de dire si c'est une erreur d'obfusquer. J'ai travaillé chez un éditeur qui obfusquait la partie algorithmique, la ou l'"intelligence" et le plus par rapport aux concurrents se trouvait, c'est pas complétement débile, surtout quand c'est vendu à des pays où le copyright est pas forcément respecté.
Donc voila, si le programme est révolutionnaire, pourquoi pas obfusquer, sinon c'est vrai que c'est pas mal d'embetements.
La compilation en natif n'est certainement pas plus sécurisée... Il est actuellement possible de décompiler des applications natives sans trop de souci. Et si ce n'est pas de la décompilation, c'est au moins du tracing, ce qui est similaire, puisqu'on lance l'application et les instructions natives lancées sont affichées.
Et rien ne tient vraiment la route pour ceux qui veulent arriver à leurs buts : des logiciels comme SecuROM sont si pas crackés, contournés...
précisons aussi que, quand tu compile, les noms des variable locales et champs privés sont déjà supprimés du code compilé (car inutiles), sauf si tu a compilé en ajoutant ces informations de debug (-g:vars dans la ligne de commande javac). Le code décompilé sera donc déjà gorgé de variables appelées a, b, c, d .....
Sache qu'un IDE incluera souvent un max d'infos de debuggage (après tout ca sert à développer un IDE, pas a faire une release). Dans la pluspart des cas, le code obfusqué restera compréhensible, suffit de lire le code et au fur et à mesure (avec du refactoring dans un IDE par exemple) donner un nom aux méthodes qu'on comprend, en commencant pas les plus simple). Ce sera juste un peu plus long ;)
En payant, il existe JET qui est beaucoup plus puissant que GCJ mais il est très cher. Il supporte Swing et Java 6 au contraire de GCJ qui est bloqué à la version 1.4 de Java et qui supporte assez mal Swing.Citation:
Envoyé par nouknouk
Je n'ai jamais dit que le natif était 100% indécompilable ; simplement qu'un programme Java compilé en natif est encore plus dur à décompiler qu'un programme en bytecode obfusqué.Citation:
Envoyé par dingoth
Reste qu'entre les deux, il y a quand même une bonne différence, de la même façon qu'un programme en C compilé est bien plus ardu à décompiler qu'un programme en bytecode Java :
- dans un cas (obfuscation) on se retrouve avec un code Java qui a simplement perdu les noms de fonctions/variables/classes/etc... mais qui garde par exemple en clair les appels à toutes les méthodes de l'API standard, genre java.io.File() restera java.io.File
- dans l'autre cas (compilation en natif), si je ne m'abuse, on se retrouve avec au mieux du code assembleur.
Merci à tous pour vos réponses :)Citation:
Envoyé par thelvin
comment on fait un copyright ? Il faut contacter un organisme ? cela a un cout je suppose, non ?
J'ai vu il y a déjà 5 ans une démonstration d'un outil qui recréait du code c basique (le c de k&r) à partir de l'exécution d'un programme.Citation:
Envoyé par nouknouk
Faire un copyright est très facile : "(c) copyright 2009 - COMPAGNIE" suffit.Citation:
Envoyé par _LittleFlea_
Après, en cas de conflit, il te suffit de prouver que ton code était là avant (c'est un autre avantage d'utiliser des systèmes de versionnement).
Le copyright est un droit international. Il est lié à toute oeuvre de l'esprit (donc au codes des logiciels) et t'a rien de particulier à faire pour le préserver (mis à part bien indiquer que ce programme est à toi, et que donc tu en est le détenteur des droits). Par défaut, tu conserve tous les droits sur ton oeuvre, a moins d'explicitement en transférer à un tiers (via les termes d'une licence par exemple). T'a rien à faire de particulier. Tout ce qu'il faudra payer, c'est les avocats le jour ou tu voudra intenter un procès pour violation du copyright ;)Citation:
Envoyé par _LittleFlea_
L'obfuscation, c'est juste des batons dans les roues.
Si la JVM arrive à comprendre ton code obfuscé,
qu'est ce qui empêche quelqu'un de l'interpréter ?
Une autre piste à suivre d'après moi : Internet
La majorité des sites web que l'on utilise sont "fermés", et cela définitivement.
Leur code source et/ou code compilé se trouve côté serveur, et donc quasiment inviolable.
Tout ce que reçoit le client, c'est le côté "présentation".
Je ne sais pas si ça peut être utile dans ton cas, mais pour moi, c'est la seule chose "sûre" si tu veux masquer une partie ou totalité de ton code aux utilisateurs.
un programme informatique où les méthodes ont des noms aléatoires, ainsi que les classes est incompréhensible.
A premiere vue oui, mais si tu veux vraiment trouver, ce n'est pas si compliqué dès le moment ou il y a le code. C'est juste long, mais si tu sais ce que tu cherches, c'est tout à fait possible de trouver.Citation:
Envoyé par toto828
oui tout est possible même trouver ce que fait ce programme :
un code non commenté, où tu ne sais pas quelle est la responsabilité d'une classe ni celles des méthodes est bon à jeter à la poubelle.Citation:
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
La seule raison pour laquelle il est impossible de trouver ce que fait le code que tu donnes en exemple est qu'il n'est pas compilable...
C'est du brainfuck, donc compilable je crois...Citation:
Envoyé par Baptiste Wicht
si c'est compilable en Brainfuck :mrgreen: , c'est un hello world
Oki pour du BrainFuck (je l'avais oublié celui-là :oops:) :P
Mais un code Java obfusqué devrait plus ressembler à ça :
Mais par contre, tout ce qui est des appels à la librairie standard ne peuvent pas être obfusqués et améliorent la lisibilité du code compilé.Code:a[b.xyzzy(zui)].asdf(q,w,e,r,t,y).
De toute manière, c'est *********** d'obfusquer du code Java.
Les fichier .class étant plus ou moins lisibles...
De plus, ça s'éloigne complètement de la philosophie d'origine de Java : réutilisabilité, maintenabilité, blabla etc ...
Au fait, si on veut obfusquer du code natif, je connais un autre moyen détourné : les compresseurs d'exe.
ça sert souvent dans les productions de demoscene, pour rendre les exe les plus petits possibles.
ça sert aussi dans la création de virus soit dit en passant...
Et donc, ça rend le code fourni à l'utilisateur encore plus difficile à décompiler.
Il n'y a pas un décompilateur Java fourni avec le JDK au fait ?
Tout à fait, il s'agit de javap.Citation:
Envoyé par PierreD87
Par contre, il ne ressort le code des méthodes qu'en bytecode Java.
Comme tu le dis, c'est juste une question de temps.Citation:
Envoyé par Baptiste Wicht
Mais justement, ça fait toute la différence entre:
- un code que le 'pirate' prendra le temps de décompiler pour en récupérer ce qu'il veut
- un code sufisamment ardu à décompiler pour que le temps mis pour décompiler le bazar soit supérieur au temps pour redévelopper la même chose par soi-même, et donc que le 'piratage' ne présente plus aucun intérêt.
Et à ce jeu, les différences sont énormes entre:
1- un code Java non obfusqué (donc les sources récupérables en trois clics),
2- un code Java obfusqué (donc sources récupérables en trois clics + un gros boulot de refactoring pour comprendre puis renommer chaque variable/méthode/classe/..., mais pas titanesque puisque tous les appels vers l'API de base reste en 'clair')
3- un code Java compilé en natif (donc récupérage du code assembleur en trois clics, mais boulot titanesque ensuite pour comprendre le fonctionnement de chaque partie).
Et autant la solution 1 n'a quasiment aucune chance de rebuter qui que ce soit, autant la solution 2 ou 3 a toutes les chances de rebuter l'immense majorité des prétendants 'pirates'.
Finalement, l'ensemble des notions de chiffrement reposent exactement sur le même principe: connaissant l'algorithme de chiffrement, il est tout à fait possible de déchiffrer l'information ; la seule 'subtilité' réside dans le fait que ça demandera tellement de ressources, notamment en temps (on parle de siècles ici) que le jeu n'en vaut pas la chandelle.
Pourtant, jusqu'à preuve du contraire, on considère les algorithmes de chiffrement couramment utilisés comme comme 'sûrs', non ?
Simplement, parce qu'on considère implicitement qu'une information déchifrée x siècles après sa transmission n'a plus aucune valeur et donc que n'importe qui de raisonnable ne se lancera pas dans une telle aberration.
ha et aussi,
si tu veux obfusquer ton code pour cacher un mot de passe/clé privée :
non !
Si effectivement ce sont des méthodes qui sont plus rapides à réécrire que de comprendre le code obfusqué, alors, de fait, ca n'a aucun intérêt de les obfusquer car, dans ce cas, ce sont des méthodes et algos simples ;)Citation:
Envoyé par nouknouk
Pour moi si tu cherche à obfusquer un algo pour protéger les intérêts de ton entreprise, c'est que l'algo et mis des mois à être développer. Et je pense pas, même avec un très bon obfusqueur, que l'algo sera si difficile que ça à décompiler. Au plus au lieu de passer 1 semaine à comprendre ton code, la méchante société concurrente y passera 1 mois. Sans compter que, pour du "vol", elle peut toujours re-obfusquer ton code (pour que toi tu ne le reconnaisse pas) et se contenter d'appeler tes méthodes en fournissant gentillement ta librairie avec leur programme (ils n'ont pas besoin de comprendre tout le code pour repérer le point d'entrée d'un calcul et son résultat ;) )
Re-bonjour à tous,
La solution qui a été choisie finalement est de compiler mon application en natif grâce au logiciel JET.
Merci à tous pour vos réponses :)
A mon avis, c'est la pire des solutions, à moins que le code natif soit lui aussi obfusqué.Citation:
La solution qui a été choisie finalement est de compiler mon application en natif grâce au logiciel JET.
La pire des solutions ??? Faut pas exagérer quand même, au mieux le code qu'un "pirate" pourra avoir c'est de l'assembleur, alors bon courage à lui s'il veut retrouver les sources avec ça...Citation:
Envoyé par Uther
Ce n'est pas pire, Il faut savoir cacher le savoir faire au moins pour un temps.. ;)
de toute façon si on connais la plate forme du client alors ça serai pas plus mal de lui donner un exe qu'un jar qui lui a besoin d'une jvm.
Si l'obfuscateur est bon, on ne peut pas retrouver un source, ou alors dans un état illisible.Citation:
La pire des solutions ??? Faut pas exagérer quand même, au mieux le code qu'un "pirate" pourra avoir c'est de l'assembleur, alors bon courage à lui s'il veut retrouver les sources avec ça...
Par contre les crackeurs parlent l'assembleur couramment.
L'idéal serait d'obfusquer le code binaire car il est vrai qu'il offre généralement plus de possibilités d'obfuscation que le bytecode.
Ceux qui n'ont jamais eu de problème à interpréter de l'assembleur normal levez la main !Citation:
Envoyé par _LittleFlea_
*Lève la main.*
Et je ne parle pas du fait que je n'ai pas besoin de comprendre le code pour simplement le copier et l'utiliser.