我们需要保护几个JavaEE 6应用程序（.war文件）以防止逆向工程，但似乎没有很多可用的选项。
我喜欢JarCrypt/JInstaller产品中使用的加密.jar文件（SJAR）的想法，但目前尚不清楚JarCrypt / JInstaller是否适用于JavaEE 6应用程序。像Glassfish3.1这样的服务器。加密的SJAR文件必须使用自定义类加载器由本机库解密，因此显然我必须向Glassfish添加自定义类加载器。
有没有人使用过JInstaller / JarCrypt技术？它们是否在Application Server中工作？
我也看过混淆，但对于JavaEE应用程序，存在很多问题。我将不得不单独留下所有Web服务和JNDI查找。使用诸如a.b.c.MyClass.class之类的东西（即创建log4j Loggers）是有问题的。读取日志文件变得困难。对于所有这些问题，混淆几乎没有什么可以保护我们的代码。
我尝试过Proguard，但显然是can't deal with the JavaEE 6 libraries。
还有其他替代方案，或者这些是关于我的所有选项吗？
感谢。
答案 0 :(得分：2)
您是否将这些应用程序发送给将在其基础架构上运行的第三方？然后加密根本不会帮助你，因为JVM无法执行加密的字节码，it is trivial to retrieve the loaded class files from a running app。
看看GuardIT for Java - 迄今为止我没有使用它的经验，但至少该供应商声称它专门用于保护Java Web应用程序。
如果您的应用程序在Tomcat上运行，您可以将它们编译为本机代码。或者他们需要一个完整的Java EE应用服务器吗？
答案 1 :(得分：1)
过去两年我一直致力于软件保护，我已经评估了市场上的大多数欧洲解决方案（对不起，我们避免采用美国解决方案......）。
我们将四种技术视为保护解决方案： - 混淆 - 加密 - 编译为本机代码 - 转码
除转码外，你可能知道大多数这些技术。
混淆需要做很多工作才能最终保护得不好。但是你可以将混淆和所有其他技术结合起来。
加密非常容易破解（没有解决方案将密钥存储在安全区域;即使使用加密狗也很容易检索）。此外，还有一种方法是从内存中窃取解密的类（或者更直接地说，加密密钥）。
大多数Java开发人员认为编译为本机代码可提供良好的保护......但是，它根本不提供保护; 20多年来，它已经可以反转本机代码，并且有一些非常熟练的逆向工程师可以做到这一点。还有一些很好的C语言反向编译器可以帮助...
最后，还有转码（其中互联网上的信息非常少）。这是针对熟练逆向工程师的唯一有效保护。打破是一种痛苦，因为它需要多年的工作。这并非不可能，但需要非常长的时间。此外，每次发布新补丁时，必须重新启动逆向工程，因为在每次发布时，代码都完全不同。有缺点吗？是的，表现。但它可以与所有其他技术结合使用，并且没有部署限制（应用程序服务器，动态类生成等）或Java限制（反射等）。
没有银弹。可以根据您的目标使用每种解决方案。保护政府或反对脚本小子是不一样的...选择相对于利弊的解决方案，更重要的是相对限制（如Jarcryp和网络应用程序上的混淆）。
要回答有关Jarcryp（以及其他加密解决方案）的问题，有可能：您只需要向Componio（提供JInstaller / Jarcryp）请求给您一个继承自您的应用程序服务器类加载器的类加载器使用
转码适用于所有应用服务器。
答案 2 :(得分：0)
使用ProGuard进行WAR文件混淆将帮助您在很大程度上加密war文件。有关详细信息，请访问链接http://bratonfire.blogspot.in/2012/01/war-file-obfuscation-using-proguard.html
答案 3 :(得分：-1)
预防实际上是不可能的。你可以期望的最好的是稍微提高障碍，这将导致错失良好因素Security through obscurity no security at all。声称这样做的产品实际上是在兜售silicon snake oil