java bytecode security

原来在公司内部使用的系统(Java实现),需要在公司外部架设使用。这样系统的程序就暴露出来,由于Java Class文件十分容易反编译,只要得到了源代码,则对于会java的程序员来讲,其中的逻辑跟写法很容易分析得到。由此对公司软件版权保护是不利的。更 甚者,如果暴露的程序含有敏感逻辑或是数据,则对于公司的运营安全都会造成风险。因此,对于需要架设到公司外部的系统程序进行一定程度的保护措施,应视为 系统交付前的必要动作。
至于保护程序的方式,目前找到的有
  • 对Class文件进行混淆:对类名,变量名,方法名等等重命名。这样可以增加反编译的难度,并且反编译后得到的代码也不易读懂。这方面关注的有现成的开源工具Proguard 。这种方式的局限性可能在于,经过混淆后的Class文件如果面对的是经过优化的反编译器 + 一定水准的程序员,则还是可以分析得出的。不管怎样,这种方式可以增加反编译程序的难度,在一定程度上保护了程序的安全,不失为一种选项。
  • 利用java的类装载机制及加密框架,先对Class文件进行加密,运行时使用客制化的ClassLoader先解密后再进行装载。这样在文件系统中始终不会有解密后的程序版本,从而无法直接进行反编译。有关这种方式,这里 找到一篇介绍的文章。该方式可以说较前一种方式在保证代码的安全性上有所提高,不过也有破解之法,只要获得密匙或设法将解密后的文件内容存至文件系统,则后续工作则如探囊取物,自然而然了。
  • 将字节码程序进一步编译为机器码程序。这样要再反编译的难度就相当的大了。就笔者目前所知,该方式可以获得最高的代码安全性,不过同时也失去了Java应用本应具有的跨平台特性。如果公司对于应用代码安全性的要求已经超乎应用跨平台特性的需要,则可以考虑使用这种方式。

有没有更好的解决方式?笔者目前还在寻找跟评估中。有关java代码安全性(防反编译,逆向工程)的问题,也是笔者未来一段时间关注的主题。 
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值