Je voudrais crypter ou obscurcir mon fichier de guerre afin que l'ingénierie inverse prendra un peu plus d'effort. Existe-t-il un tel outil ou un plug-in Maven qui cryptera un fichier de guerre et son contenu?
En outre, une fois que la guerre est cryptée, comment l'application Web sera-t-elle déployée à ce moment-là? Si le serveur Web explose la guerre, chaque bocal et chaque ressource seront toujours cryptés, comment le comportement de démarrage sera-t-il modifié pour déchiffrer les pots et les ressources imbriquées?
merci, Walter
5 Réponses :
Zelix Klassmaster peut être exécuté à partir de la fourmi. On dirait que ça traite Wars aussi.
Je ne pouvais pas vous parler du déploiement de la guerre, mais de tout Obfuscator qui provoque une archive de ne pas travailler après que cela a été obscurcié ne valait pas grand chose.
Dasho des solutions préventives obtiendra également des fichiers de guerre.
Pouvez-vous s'il vous plaît dites-moi comment puis-je faire ça?
Cracking Java octet-Code-CodeCryption - Pourquoi Java Obfuscation Schémas basé sur le cryptage de code d'octet ne fonctionnera pas - article de Javaworld.
Si votre code est suffisamment important pour aller à tous ces problèmes, il est probablement logique de l'organiser sur un serveur privé ...: \
L'hébergement privé semble être la meilleure option
Votre lien dit "page non trouvée". Probablement propriétaire supprimé l'article
J'ai le même problème ici. Je l'ai essayé avec Yguard 2.4, Proguard 4.7, Zelix 5.4.6, Allatori 4.0, Javaguard 1.0, Sablemark 3.40. Tous ceux qui ne me donnent pas d'un coup d'œil que mon application Web obscurcie ne serait pas exécutée. Ils peuvent obscurcir des bytecodes même ils peuvent obscurcir mon application. C'est tout.
P.s: le serveur d'applications (conteneur de serveur Tomcat, Apache, Glassfish, Weblogic, WebSphere, etc.) ne peut pas masquer notre code à partir de pirates. Dans mon expérience, tous disposent de dossier Temp qui contient actuellement des articles. Dans ce dossier, nous pouvons voir le code.
Enfin, je dirais que si nous utilisons Java, alors nous faisons OpenSource. : P
J'ai eu une solution à ce problème. Ça va comme ça:
chiffrer un fichier de guerre. Comme zip IT et chiffrer cela, il ne peut donc pas être lu sans mot de passe.
Configurez un système ou donnez uniquement le mot de passe à un service d'hébergement. Une fois que vous et un client ont élaboré vos conditions, vous donnez le mot de passe au service d'hébergement. Ils déchiffrent la Fichier de guerre et l'installer. Leur client ne voit que le site Web / API. Le client n'a jamais Accès à vos fichiers JAR.
Des commentaires?
Pourquoi veux-tu faire cela? Si quelqu'un est intéressé par votre code, il sera capable de le reconstituer de toute façon, tant qu'il accède au binaire (en l'occurrence une guerre). En Java, c'est particulièrement simple, mais cela est également possible pour C. intéressé par votre code ne peut être que des développeurs, avec peu d'efforts qu'ils acquièrent les connaissances nécessaires pour cela. Donc, l'effort extra-extraordinaire pour obscurcir votre code ne peut affronter que très peu de pirates informatiques. Je ne peux pas voir l'avantage.
+1 pour les commentaires de @ mnementh. Quel est l'objectif ici? Vous déployez votre guerre dans un conteneur d'applications Web (par exemple Tomcat), côté sévère. Les clients Web n'auront pas accès à celui-ci.
Je ne suis pas inquiet pour les gens qui visionnent le site de Firefox ou quoi que ce soit, mais d'autres personnes sur le système ou si vous développez un site Web pour un client et en utilisant leurs serveurs, je peux ou non qu'ils ont facilement accès au code source.
Je suppose que la meilleure solution serait d'aller avec l'hébergement privé alors.
@Walterwhite Walter, j'essaie de comprendre la même chose (comment éviter le client de voir le code source). Avez-vous pu proposer une belle solution autre que l'hébergement privé?