Comment arrêter les decompilateurs java de faire la reverse engeneering
Il y a til un moyen de crypter son code pour qu'il ne soit pas decompiler, es ce que les ide ont un outils :mur: et rendre la decompilation d'une class difficile
:merci:
Version imprimable
Comment arrêter les decompilateurs java de faire la reverse engeneering
Il y a til un moyen de crypter son code pour qu'il ne soit pas decompiler, es ce que les ide ont un outils :mur: et rendre la decompilation d'une class difficile
:merci:
Les obfuscateurs domme proGuard, yGuard, retroguard & cie complexifie ton code de façon à ce qu'il soiit quasi impossible à lire après décompilation
Sinon tu peux aussi voir du coté des compilateurs natifs, mais le support de java est aléatoire (ceux supportant l'intégralité de java 5 sont payants)
Cf. la :faq: ici !
;)
web site
http://www.retrologic.com/images/rg_logo_grey_64x64.png
http://www.retrologic.com/
ca passe pas sur mon decompilateur
jessaye les autres ..........
COMMENTAIRE:
Aucun code ne résiste à une longue et patiente RE. C'est seulement une question de temps. ;)
:salut:Citation:
Envoyé par jowo
Donc Java Obfuscation, c'est seulement une ruse pour embrouiller le faire perdre du temps augmenter les chemins du labirynte.
[B]Il y a donc pas un moyen pour stoper la RE d'une .class :question: :question: :question: :idea:
:question:
Non, excepté la compilation native (cf Excelsior JET)
Je connais aucun moyen très efficace de stopper la RE. Même en transformant en natif ton programme java, il est toujours possible de RE sur un éxecutable (même si c'est difficile).Citation:
Envoyé par liquideshark
Mais dans la plupart du temps un bon obfuscateur suffit...
Salut,
Même les applications natives peuvent être décompilées...Citation:
Envoyé par sinok
La principale question est : pourquoi as-tu besoin d'un tel niveau de protection ?
a++
En même les humains lisant nativement l'assembleur ne doivent pas être légion sur terreCitation:
Envoyé par adiGuba
Tout comme les humains lisant nativement le bytecode :aie:Citation:
Envoyé par sinok
Bref je ne pense pas qu'il soit plus facile de lire du bytecode offusqué que de l'assembleur...
a++
un GRO projet sur Information retrival. Et nous voulons pas que le code source soit visible pour tous !
:roll: Donc il y a pas de moyen pour rendre ca un peu compliquer. dz astuces pour rendre le code moins lisible à la competition donc WALO NADA. JAVA == Opensource lol:lol::bebe:
Oui et on l'a déjà dit : les obfuscateurs !Citation:
Envoyé par liquideshark
Mais cela ne peut pas garantir un résultat sûr...
Si tu es vraiment si parano il faut te tourner vers des systèmes de cryptages...
Evite de tout confondre ! Cela n'a rien à voir avec Java ou l'OpenSource 8OCitation:
Envoyé par liquideshark
Pour qu'un programme puisse être exécuté il faut qu'il soit compris par la machine qui le fait tourner... à partir de là il est toujours possible de faire du reverse engineering... et ce quel que soit le langage !
a++
merci
jai dis java == opensource dans le sens que le code source de ton projet sera vu de toute facon, apres un RE,
mais pour d'autre language c'est pas aussi simple par exemple le code en c est recoder en assembleur et c'est pas tout le monde qui s'est lire ca
Ben cela n'a quand même rien à voir : l'open source est un mode de distribution !Citation:
Envoyé par liquideshark
Tu es en train de comparer un décompilateur avec un désassembleur !Citation:
Envoyé par liquideshark
Un désassembleur permet de convertir un code machine en langage d'assemblage, par exemple un fichier *.class en instruction bytecode, ou un fichier exécutable en instruction assembleur.
Un décompilateur permet de reconstituer le code source d'un logiciel à partir de son exécutable, et il en existe pour la plupart des langages et pas seulement Java ! Un exemple pour le C : boomerang
Toutefois il faut nuancer car ces outils sont quand même loin de donner le code source d'origine (et en particulier lorsqu'il a été offusqué).
Bref évites de cataloguer cela comme un problème de Java, c'est commun à tous les langages...
a++
Salut,
Si ton code source ne doit pas être dévoilé, je ne vois que la solution d'utiliser un serveur contenant ton executable, et interrogé à distance par ton application.
Ainsi, ton code ( sur ton serveur ) est innaccessible par l'utilisateur, qui n'a pas la main dessus. Il ne peut que décompiler l'application en local, mais toutes les logiques métiers restent sur le serveur.
Personnellement, je pars du principe que obfusquer ton code ne sert à rien; Quelqu'un de motivé arrivera toujours à décompiler, si il y a un gain substentiel à la manipulation. Tu lui donneras plus de fil à retordre, mais ton code reste visible et exploitable; Pareil pour les applications natives.
Personnellement, à moins que ton application soit une application de sécurité avec des algorithmes qui doivent rester indéchiffrables, je ne vois pas l'interêt de cacher le code source... Au pire, tu auras un concurrent sur le marché, il suffira que tu fasses un meilleur programme que lui ( qui aura pompé ton code source ) et tu auras toujours ta place sur le marché. C'est beaucoup plus sain comme façon de voir les choses. Il ne faut pas empêcher les gens de voir ton code source ( je suis pro open-source ), et je répète, sauf dans le cas d'une application gérant la sécurité.
A+
+1 pour KiLVaiDeN, un éxecutable distribué pourra toujours (après c'est une question de rapport coût/interêt de le faire) être décompilé.
D'ailleurs c'est pour ça que toutes les applications finissent par être crackée non? Je pense que si les industriels du logiciels avaient une solution pour protéger à 100% leurs bébé ils l'appliqueraient.
Merci du conseilv Kilvaden
:king:Citation:
Au pire, tu auras un concurrent sur le marché, il suffira que tu fasses un meilleur programme que lui ( qui aura pompé ton code source ) et tu auras toujours ta place sur le marché. C'est beaucoup plus sain comme façon de voir les choses. Il ne faut pas empêcher les gens de voir ton code source
Sinon il existe une autre astuce, bien plus complexe, c'est d'utiliser la crypto.
Concretement, tu vas compiler ton programme "normallement". Puis tu vas crypter tous tes fichiers .class (ou le .jar, a toi de voir).
Ensuite tu vas creer un tout petit programme tres simple, qui vas uniquement ouvrir tes .class (ou ton .jar) et le decrypter "on the fly" grace a un ClassLoader adapté, et lancer le main.
Je ne sais pas si un outil existe deja, mais sinon ce n'est pas tres compliqué (y'a meme des exemples dans le tuto officiel je crois).
Le problème c'est que ton ClassLoader spécial ne pourra pas être crypté (sinon pas moyen de lancer l'appli dans une JRE) et donc qu'il pourra facilement être décompilé/modifié pour obtenir les autres classes en clair.
Il n'existe pas de solution de protection du code java complètement sûre (pour autant que ce niveau de protection ait un sens) en full java. Pour implémenter un protection cryptographique efficace il faut forcément passer par du code natif.
Celà dit un bon obfuscateur suffit dans 99% des cas à protéger efficacement le code.
Bien sur que la partie de lancement pourra etre lue, la n'est pas le probleme. Il suffit d'utiliser une clé que tu gardes dans un coin, et seul les gens ayant la clé pourront lancer l'appli (je dis bien lancer, et pas decompiler).
C'est le principe de 99% des outils de crypto moderne: l'algo, tout le monde le connais, mais sans la clé, tu ne peux rien decrypter (meme avec l'algo...).
Ensuite, tu as toujours le bruteforce... Il y a toujours un problème, aucune solution n'est sûre à 100%...Citation:
Envoyé par gcube
C'est sur. Mais bon, en choisissant son algo avec un peu de discernement, on peut esperer que bruteforce sera VRAIMENT trop long pour etre faisable.Citation:
Ensuite, tu as toujours le bruteforce... Il y a toujours un problème, aucune solution n'est sûre à 100%...
Enfin dans tout les cas, on est tous d'accord: il n'existe AUCUNE methode fiable a 100%. Mais une methode fiable a 99.9999999% peut etre considéré comme suffisamment fiable pour les besoins de notre ami, non?
Salut!
La discussion m'interresse beaucoup!!!
Voila mon problème : mon appli se connecte à une base de donnée. Mais à cause du RE, n'importe qui peut retrouver les identifiants de connection à la base de données!!!!
Je réfléchis à un moyen pour éviter cela et je galère.
Il faut éviter que les identifiants soient écrits en "dur". Mais cmt?
Avez vous des idées?
Salut,Citation:
Envoyé par gamerome
En utilisant une fonction de hashing (md5, sha1, etc...) et en stockant le hash de l'identifiant dans la base. Apres pour la vérif, tu refaits un hash de l'identifiant que tu compares au hash stocké pour voir si ils sont similaires.
Voila.