我们知道,有很多java反编译工具可以将.class转换为.java文件.
因此,我们需要保护我们的.java文件免受反编译.我知道这是一个很大的话题,也许没有结局.
通常,有两种方式:混淆器和自定义类加载器.
是否有任何成熟的解决方案或开源框架,这两种方式相结合?
另一个方面与exe4j有关,它将jar包装到exe文件中,看起来它可以保护java代码,因为我们可以看到的是exe文件而不是jar文件或类文件.但实际上,当它运行时,它会将所有jar文件分解为临时目录,这意味着很容易获得反编译器的类文件.那么从exe4j方面保护java代码的任何考虑因素呢?
感谢您的意见和建议.
更新
感谢大家的建议或经验分享.这对我很有帮助.为了得出结论,我将放弃任何具有加密功能的混淆器或自定义类加载器.因为最终Java代码可以在聪明的黑客之前公开.
我将在编译时使用C语言中的"#ifdef"等技巧删除一些核心代码.在Java中,static和final布尔类变量可用于执行相同的工作.然后,compilered类文件将不包含受需要保护的java代码.
您可以使用混淆器,如ProGard或Ygard,但解密字符串并重命名类,字段和方法并不太复杂.
您可以使用私钥加密类,并使用自定义类加载器在加载到内存之前使用公钥解密类,但修改类加载器以将所有加载的类保存到光盘上并不太复杂.
你可以试试崩溃反编译器.JAD是最好的反编译器之一,但如果在常量池中添加损坏的条目,则由JAD驱动的所有产品都会崩溃.但是,一些反编译器仍然在工作.
保护软件的唯一方法是将其部署在SaaS/PaaS中.
但要保持头脑:大多数人使用反编译器,因为他们有技术问题并且文档很差或不存在.写一篇好文档并使用一个可靠的EULA是更好的解决方案.
您无法保护反编译器和恶意用户的类文件.但是反编译器的输出可能不是有效的java.
最好的方法是记录您的API(假设这可供您的客户使用)和应用程序非常好.并让您的支持人员能够解决API和应用程序问题.然后,您的客户将没有理由想要使用反编译器来探究为什么事情无法正常工作.
软件作为服务.
唯一有效的方法是将您的程序作为某种Web服务提供,以便编译代码在最终用户机器上永远不可用.
下一个最有效的解决方案,即在实践中广泛使用的解决方案,是使您的程序如此糟糕,以至于没有人想要使用它或者花时间将其逆向工程化.我怀疑,当发生这种情况时,它通常是偶然的.