我正处于构建Java EE应用程序的需求阶段,该应用程序很可能在GlassFish/JBoss后端运行(现在无关紧要).我知道我不应该在需求时考虑架构,但人们不禁开始想象组件是如何全部拼凑在一起的:-)
以下是客户端的一些硬性,非灵活性要求:
(1)客户端应用程序将是一个Swing框
(2)客户端可以免费下载,但将使用订阅模型(因此需要与服务器的登录机制)侧认证/授权等)
(3)是的,Java是最好的了手头的问题这篇文章的范围之外的平台解决方案的原因
(4)客户端的.class文件需要维护反编译
最后(第4个)要求是这篇文章的基础.
我并不是真的担心有人会实际反编译并获取我的源代码:最后,它只是由一些轻量级业务逻辑驱动的Swing控件.
我担心会有人反编译我的代码,修改它以利用/攻击服务器,重新编译并激活它.
我设想了各种令人讨厌的解决方案,但不知道这是否是Java EE开发人员常见解决方案的常见问题.有什么想法吗？
对"代码混淆"技术不感兴趣!
感谢您的任何意见!
您必须假设代码将被反编译并将用于利用/攻击服务器.
只相信服务器在做什么.
我来这里是为了给你带来坏消息.你无法阻止这一点.
我深深地挖了一次这个.在JVM的最低级别,类加载器必须获得未加密的字节流,即类文件.你无法改变用你自己的代码替换JVM的缺点.此外,还有一个钩子允许查看(复制等)字节流.无论你在更高级别做什么,JVM总是会到达这一点并允许访问你的类文件.获得类文件后,可以对其进行反编译.混淆技术和工具可以降低速度或使其变得困难,但它们也无法阻止它.
我强烈建议您使用经过验证的安全方法来保护您的服务器.不要把秘密酱涂在你给客户的东西上.如果他们足够坚定,他们会以某种方式得到它.
| 归档时间： |
|
| 查看次数： |
595 次 |
| 最近记录： |