针对Java Web部署和发布项目的加密和反编译的一些看法

【需要加密的反编译的一些场景】

1、公司开发的java web要项目打包成war包往外卖，怎么对war包进行处理，防止其自己拷贝后往外出售呢，如果不通过加密的方式，还有其他方式防止其出售呢.

2、大家都知道的，class很好反编译。出于对知识产权和自身软件的保护，不希望任何人都可以看到源代码或者被反编译工具进行解密。

【java web发布运行在tomcat 大概加密与反编译过程如下】

对于传统的C或C++之类的语言来说，要在Web上保护源代码是很容易的，只要不发布它就可以。遗憾的是，Java程序的源代码很容易被别人偷看。只要有一个反编译器，任何人都可以分析别人的代码。Java的灵活性使得源代码很容易被窃取。
    有几种技术可以“模糊”Java类文件，使得反编译器处理类文件的效果大打折扣。然而，修改反编译器使之能够处理这些经过模糊处理的类文件并不是什么难事，所以不能简单地依赖模糊技术来保证源代码的安全。
    我们可以用流行的加密工具加密应用，比如PGP（Pretty Good Privacy）或GPG（GNU Privacy Guard）。这时，最终用户在运行应用之前必须先进行解密。但解密之后，最终用户就有了一份不加密的类文件，这和事先不进行加密没有什么差别。
    再说硬件加密锁，大多数厂商提供的加密锁只能进行dll的连接或简单的api调用，只要简单地反编译，就很容易把api去掉，这样加密锁根本起不了作用，那到底是否还有更好的解决办法呢？
       现提供2种解决办法：
    1、HASP加密锁提供的外壳加密工具中，有一个叫做数据加密的功能，这个功能可以很好的防止反编译而去掉api的调用，大家知道：硬件加密锁的保护原理就是让加密过的软件和硬件紧密相连，调用不会轻易地被剔除，这样才能持久地保护您的软件不被盗版，同时，这种方式使用起来非常简单，很容易被程序员掌握，要对一个软件实现保护，大约只需几分钟就可以了，下面简要介绍一下它的原理：
    运用HASP HL的外壳工具先把java解释器进行加密，那么，如果要启动这个解释器就需要有特定的加密锁存在，然后，再运用外壳工具中的数据加密功能把java程序(CLASS或JAR包)当作一个数据文件来进行加密处理，生成新的java程序，因为这个加密过程是在锁内完成的，并采用了128位的AES算法，这样，加密后的java程序，无论你采用什么样的反编译工具，都是无法反编译出来。您的软件也只有被加密过的java解释器并有加密锁的情况下才能正常运行，如果没有加密锁，程序不能运行，从而达到真正保护您的软件的目的，该方法只支持Windows平台。
     2、HASP提供专门针对java外壳加密工具，直接加密jar或war包，防止反编译，目前支持J2SE，J2EE主要支持容器为TOMCAT6.0以上，可在Windows和Linux平台下运行，如果情况适合则是最简单的使用方法。
     到目前为止，HASP是加密锁行业中唯能针对java加密，防止反编译的。

如果是windows操作系统的方案

把一个核心的东西放到dll里面，这样dll是反编译不了的

目前能解决的就是这个方式了。想一劳永逸是不可能的。win都能破解，何况java

高级方案：混淆(RetroGuard )+数字签名验证

建议方案：根本的方法是凡是拷贝的副本，在运行时，程序自动连接到官方的服务器做正版验证。至少解决大部分问题。

反编译源代码被修改这种破解方法：

这个比较靠谱，验证的jar包，加密混淆，或者各个jar包注入 验证，反编译好像无解吧。

javaee加密部署，tomcat使用自己的classloader解密  http://www./kf/201312/264455.html

APK反编译，因为当下绝大多数的Android安卓手机的app都是用java编写的;

1、Android APK反编译就这么简单 详解（附图） http://blog.csdn.net/vipzjyno1/article/details/21039349/

2、apk反编译获取完整源码 及 apk反编译后的处理 http://blog.csdn.net/wh_19910525/article/details/7915738/

没有绝对的安全，只要人真的有心，破解是早晚的事情。

war包打包的已经是编译过的class文件了，看不到源码的，甚至数据库的连接账号也已经不可见了。即使是反编译，也是需要花费一番功夫的，要相信没人有闲工夫看你的烂代码，放心的交接吧