Java客户端.class文件保护

发布时间：2020-12-15 00:08:49 所属栏目：Java 来源：网络整理

导读：我正处于构建 Java EE应用程序的需求阶段,该应用程序很可能在GlassFish / JBoss后端运行(现在无关紧要).我知道我不应该在需求时考虑架构,但人们不禁开始想象组件是如何全部拼凑在一起的:-) 以下是客户端的一些硬性,非灵活性要求： (1)客户端应用程序将是一个

我正处于构建 Java EE应用程序的需求阶段,该应用程序很可能在GlassFish / JBoss后端运行(现在无关紧要).我知道我不应该在需求时考虑架构,但人们不禁开始想象组件是如何全部拼凑在一起的:-)

以下是客户端的一些硬性,非灵活性要求：
(1)客户端应用程序将是一个Swing框
(2)客户端可以免费下载,但将使用订阅模型(因此需要具有服务器端认证/授权的登录机制等)
(3)是的,Java是针对当前问题的最佳平台解决方案,其原因超出了本文的范围
(4)客户端.class文件需要防止反编译

最后(第4个)要求是这篇文章的基础.

我并不是真的担心有人会实际反编译并获取我的源代码：最后,它只是由一些轻量级业务逻辑驱动的Swing控件.

我担心会有人反编译我的代码,修改它以利用/攻击服务器,重新编译并激活它.

我设想了各种令人讨厌的解决方案,但不知道这是否是Java EE开发人员常见解决方案的常见问题.有什么想法吗？

对“代码混淆”技术不感兴趣！

感谢您的任何意见！

解决方法

我来这里是为了给你带来坏消息.你无法阻止这一点.

我深深地挖了一次这个.在JVM的最低级别,类加载器必须获得未加密的字节流,即类文件.你无法改变用你自己的代码替换JVM的缺点.此外,还有一个钩子允许查看(复制等)字节流.无论你在更高级别做什么,JVM总是会到达这一点并允许访问你的类文件.获得类文件后,可以对其进行反编译.混淆技术和工具可以降低速度或使其变得困难,但它们也无法阻止它.

我强烈建议您使用经过验证的安全方法来保护您的服务器.不要把秘密酱涂在你给客户的东西上.如果他们足够坚定,他们会以某种方式得到它.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!