Spring 应用程序的混淆值得尝试吗？答案

【问题标题】：Is obfuscation of Spring apps worth trying it?Spring 应用程序的混淆值得尝试吗？
【发布时间】：2011-11-01 12:18:18
【问题描述】：

我想使用混淆器（例如 ProGuard）来保护我的 Web 应用程序中的 IP。我知道混淆字节码的局限性，但仍然可以反编译它。但我感觉好一点，如果我知道网络服务器上有一个混淆的战争文件...... 在使用 ProGuard 进行第一次测试后，我想知道他们的“入口点”方法是否对使用 SpringMVC 的 Web 应用程序有用……还有 Spring。如果我必须“保留”我所有的@Repository、@Service、@Controller 和@Component 注释类，并因此将它们排除在混淆之外，那么这种工具的主要问题就没有得到满足。我读到，我应该使用基于 Java 的 Spring 配置，而 Spring 3.1 在这方面有很多改进，但值得使用吗？任何工具都可以真正混淆 Spring Beans 吗？

多米尼克

【问题讨论】：

如果这是一个未部署在客户端计算机上的 Web 应用程序，那么它肯定不值得。如果是，它可能是，但我通常持怀疑态度。

标签： java spring proguard obfuscation

【解决方案1】：

混淆服务器端代码是没有意义的。

如果攻击者进入您的服务器文件系统，.war 文件将是您最不关心的问题

【讨论】：

【解决方案2】：

我同意 Bozho 的观点，条件是它只安装在您控制的服务器上，但在某些情况下，您可以将其发送到您想要简单 DRM 之类的客户端，然后您想要模糊处理以增加少许保护。

我从未使用过 Spring，但您面临的问题听起来像是一个常见的混淆问题，您无法保护入口点，因为在某些时候需要调用它，因为某些不知道混淆的东西需要调用它。

如果可能的话，我建议您重构入口点类，使其成为哑壳，调用包含实现的混淆类。

还有一点需要注意的是，在你的混淆 Jar 上使用反编译器总是很有用的，你会很快看到你的混淆工作有多成功以及哪些重要的代码没有被混淆，然后你可以调整配置并改进混淆。

【讨论】：

【解决方案3】：

我希望这个问题还没有回答。

我遇到了与@Dominik 表达的相同的问题。

如果我们保持@Repository、@Service、@Controller、@Component、@Entities、@Transactional 和@Cachable 不变，那么混淆完全没有意义。如果我错了，请纠正我。有人尝试过任何不同的方法来混淆 Spring MVC 代码吗？

【讨论】：