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.Envoyé par toto828
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
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.
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.++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
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...
si c'est compilable en Brainfuck, c'est un hello world
Oki pour du BrainFuck (je l'avais oublié celui-là)
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 : Sélectionner tout - Visualiser dans une fenêtre à part 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.
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.
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.
Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.
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
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é.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...
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.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 !
*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.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager