如何防止 JavaEE 6 .war 文件的逆向工程？
我们有几个需要防止逆向工程的 JavaEE 6 应用程序（.war 文件），但似乎没有太多可用的选项。
我喜欢在 JarCrypt/JInstaller 产品中使用加密 .jar 文件 (SJAR) 的想法，但尚不清楚 JarCrypt/JInstaller 是否可以在 JavaEE 6 应用程序中工作。像Glassfish3.1这样的服务器。加密的 SJAR 文件必须由本机库使用自定义类加载器进行解密，因此显然我必须向 Glassfish 添加自定义类加载器。
有人使用过 JInstaller / JarCrypt 技术吗？它们在应用程序服务器中工作吗？
我也研究过混淆，但对于 JavaEE 应用程序来说存在很多问题。我必须放弃所有 Web 服务和 JNDI 查找。使用像 abcMyClass.class 这样的东西（即创建 log4j 记录器）是有问题的。读取日志文件变得困难。对于所有这些问题，混淆对于保护我们的代码几乎没有任何帮助。
我尝试过 Proguard，但显然它 无法处理 JavaEE 6 库。
还有其他选择吗？或者这些是我所有的选择吗？
谢谢。
We have several JavaEE 6 applications (.war files) that we need to protect against reverse engineering, but there don't seem to be many options available.
I like the idea of an encrypted .jar file (SJAR) used in the JarCrypt/JInstaller products, but it's not clear that JarCrypt/JInstaller will work in a JavaEE 6 app. server like Glassfish3.1. The encrypted SJAR files have to be decrypted by a native library using a custom classloader, so apparently I would have to add a custom classloader to Glassfish.
Has anyone used the JInstaller / JarCrypt technologies? Do they work in an Application Server?
I've also looked at obfuscation, but for JavaEE applications there are lots of problems. I would have to leave all web services and JNDI lookups alone. Use of things like a.b.c.MyClass.class (i.e. to create log4j Loggers) is problematic. Reading log files becomes difficult. And for all of those problems obfuscation does next to nothing to secure our code.
I've tried Proguard, but apparently it can't deal with the JavaEE 6 libraries.
Are there other alternatives or are these about all the options I have?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您是否会将这些应用程序交付给将在其基础设施上运行的第三方？那么加密对你根本没有帮助，因为 JVM 无法执行加密的字节码，并且从正在运行的应用程序中检索加载的类文件。
查看GuardIT for Java - 迄今为止我没有这方面的经验，但至少供应商声称它是专门为保护 Java Web 应用程序而设计的。
如果您的应用程序在 Tomcat 上运行，您可以将它们编译为本机代码。或者他们是否需要完整的 Java EE 应用服务器？
Are you shipping those apps to third parties who will be running it on their infrastructure? Then encryption won't help you at all, because the JVM cannot execute encrypted bytecode, and it is trivial to retrieve the loaded class files from a running app.
Take a look at GuardIT for Java - to date I have had no experience with it, but at least the vendor claims it is specifically designed to protect Java Web apps.
If your apps run on Tomcat, you could have compiled them down to native code. Or do they need a full Java EE app server?
过去两年我一直致力于软件保护，我评估了市场上的大多数欧洲解决方案（抱歉，我们避免美国解决方案......）。
我们认为有四种技术可作为保护解决方案：
- 混淆
- 加密
- 编译为本机代码
- 转码
您可能了解除转码之外的大部分技术。
混淆需要大量的工作，最终保护效果很差。但您可以将混淆与所有其他技术结合起来。
加密很容易被破解（没有将密钥存储在安全区域的解决方案；即使使用加密狗也很容易检索）。此外，还有一种解决方法可以从内存中窃取解密的类（或者更直接地说，加密密钥）。
大多数 Java 开发人员认为编译为本机代码提供了良好的保护......但是，它根本不提供保护； 20 多年来，逆向本机代码已经成为可能，并且有一些非常熟练的逆向工程师可以做到这一点。还有一些很好的 C 语言反向编译器可以提供帮助...
最后，还有代码转换（互联网上的信息很少）。这是针对熟练逆向工程师的唯一有效保护。打破它是一件痛苦的事，因为它需要多年的工作。不是不可能，但是需要非常非常长的时间。而且，每次发布新补丁，都必须重新启动逆向工程，因为每次发布的代码都是完全不同的。有缺点吗？是的，性能。但它可以与所有其他技术相结合，并且没有部署限制（应用程序服务器、动态类生成等）或 Java 限制（反射等）。
没有灵丹妙药。每种解决方案都可以根据您的目标来使用。防范政府或防范脚本小子是不一样的......选择相对于优点和缺点的解决方案，更重要的是，相对的限制（例如 Jacryp 和 Web 应用程序上的混淆）。
要回答有关 Jarcryp（以及其他进行加密的解决方案）的问题，这是可能的：您只需要求 Componio（提供 JInstaller/Jarcryp）为您提供一个继承自您使用的应用程序服务器类加载器的类加载器。
转码适用于所有应用程序服务器。
I have been working on software protection for the past two years and I have evaluated most of the European solutions on the market (sorry, we avoid American solutions...).
There are four techniques that we have seen as protection solutions:
- Obfuscation
- Encryption
- Compilation to native code
- Transcoding
You probably know most of these techniques except for transcoding.
Obfuscation requires a lot of work for what is, in the end, poor protection. But you can combine obfuscation and with all of the other techniques.
Encryption is pretty easy to break (there is no solution for storing the key in a safe area; even with a Dongle it is easy to retrieve). Further, there is a work around to steal decrypted classes from memory (or, more directly, the encryption key).
Most Java developers think that compilation to native code provides good protection... But, it does not provide protection at all; for more than 20 years it has been possible to reverse native code and there are some very skilled reverse-engineers to do this. There are also some good reverse-compilers to C language to help...
Finally, there is Transcoding (of which there is very little information on internet). This is the only efficient protection against skilled reverse-engineers. It is a pain to break because it requires years of work. It is not impossible but demands a very, very long time.. Further, every time a new patch is released, you must restart reverse engineering again because at each release, the code is totally different. Is there a drawback? Yes, performance. But it can be combined with all the other techniques and there are no deployment limitations (application server, dynamic class generation, etc.) or Java limitations (reflection, etc.).
There is no silver bullet. Each solution can be used depending of your target. Protecting against a government or against script kiddies is not the same... Choose a solution relative to the pros and cons, and more importantly, relative limitations (like Jarcryp and obfuscation on web application).
To answer to the question about Jarcryp (and other solutions doing encryption), it is possible: you just need to ask to Componio (providing JInstaller/Jarcryp) to give you a classloader that inherits from the application server class loader that you use.
Transcoding works with all application servers.
使用ProGuard对WAR文件进行混淆将在很大程度上帮助您加密您的war文件。有关更多详细信息，请访问链接 http://bratonfire.blogspot .in/2012/01/war-file-obfuscation-using-proguard.html
WAR file obfuscation using ProGuard will help you to encrypt your war file to a great extent. For more details visit the link http://bratonfire.blogspot.in/2012/01/war-file-obfuscation-using-proguard.html
预防实际上是不可能的。您所能期望的最好结果就是稍微提高门槛，这在很大程度上会导致错失感觉良好的因素通过模糊性是根本不安全。声称具有此功能的产品实际上是在兜售硅蛇油
Prevention is actually impossible. The best you can hope for is to raise the barrier slightly which will largely result is a miss placed feel good factor Security through obscurity is no security at all. Products that claim to do this are actually peddling silicon snake oil