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
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Gros problème : comment rendre une appli Java indécompilable ?
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 ?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.
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 ?
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.
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.
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é.
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
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.
Faire un copyright est très facile : "(c) copyright 2009 - COMPAGNIE" suffit.Merci à tous pour vos réponses
comment on fait un copyright ? Il faut contacter un organisme ? cela a un cout je suppose, non ?
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 copyrightMerci à tous pour vos réponses
comment on fait un copyright ? Il faut contacter un organisme ? cela a un cout je suppose, non ?
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.
Répondre avec citation
Partager