﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>语源科技BlogJava-javarun</title><link>http://www.blogjava.net/javarun/</link><description /><language>zh-cn</language><lastBuildDate>Wed, 29 Apr 2026 03:23:25 GMT</lastBuildDate><pubDate>Wed, 29 Apr 2026 03:23:25 GMT</pubDate><ttl>60</ttl><item><title>从常见的几种方式看保护java代码</title><link>http://www.blogjava.net/javarun/archive/2010/07/09/325645.html</link><dc:creator>javarun</dc:creator><author>javarun</author><pubDate>Fri, 09 Jul 2010 06:00:00 GMT</pubDate><guid>http://www.blogjava.net/javarun/archive/2010/07/09/325645.html</guid><wfw:comment>http://www.blogjava.net/javarun/comments/325645.html</wfw:comment><comments>http://www.blogjava.net/javarun/archive/2010/07/09/325645.html#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.blogjava.net/javarun/comments/commentRss/325645.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/javarun/services/trackbacks/325645.html</trackback:ping><description><![CDATA[<p>在java代码中往往包含着一
些非常敏感的信息，有些关系到开发者的利益，有些可能因为使用环境不同而关系到软件用户的利益，于是，java程序是赤膊上阵还是全副武装这个现实问题就
摆在了java开发人员的面前，所以在这种情况下，从开发商和用户两方面角度考虑，都非常有必要对java程序进行保护。以下从技术角度就常见的保护措施
和常用工具来看看如何有效保护java代码：</p>
<ol>
    <li>将java包装成exe<br />
    <br />
    特点：将jar包装成可执行文件，便于使用，但对java程序没有任何保护。<br />
    <br />
    不要以为生成了exe就和普通可执行文件效果一样了。这些包装成exe的程序运行时都会将jar文件释放到临时目录，很容易获取。<br />
    <br />
    常用的工具有exe4j、jsmooth、NativeJ等等。jsmooth生成的exe运行时临时目录在exe所在目录中或是用户临时目录
    中；exe4j生成的exe运行时临时目录在用户临时目录中；NativeJ生成的exe直接用winrar打开，然后用zip格式修复成一个jar文
    件，就得到了原文件。如果只是为了使用和发布方便，不需要保护java代码，使用这些工具是很好的选择。<br />
    <br />
    </li>
    <li>java混淆器<br />
    <br />
    特点：使用一种或多种处理方式将class文件、java源代码进行混淆处理后生成新的class，使混淆后的代码不易被反编译，而反编译后的代码难以阅
    读和理解。<br />
    <br />
    这类混淆器工具很多，而且也很有成效。<br />
    <br />
    缺点：虽然混淆的代码反编译后不易读懂，但对于有经验的人或是多花些时间，还是能找到或计算出你代码中隐藏的敏感内容，而且在很多应用中不是全部代码都能
    混淆的，往往一些关键的库、类名、方法名、变量名等因使用要求的限制反而还不能混淆。<br />
    <br />
    </li>
    <li>隔离java程序到服务端<br />
    <br />
    特点：把java程序放到服务端，让用户不能访问到class文件和相关配套文件，客户端只通过接口访问。<br />
    <br />
    这种方式在客户/服务模式的应用中能较好地保护java代码。<br />
    <br />
    缺点是：必须是客户/服务模式，这种特点限制了此种方式的使用范围；客户端因为逻辑的暴露始终是较为薄弱的环节，所以访问接口时一般都需要安全性认证。<br />
    <br />
    </li>
    <li>java加密保护<br />
    <br />
    特点：自定义ClassLoader，将class文件和相关文件加密，运行时由此ClassLoader解密相关文件并装载类，要起到保护作用必须自定
    义本地代码执行器将自定义ClassLoader和加密解密的相关类和配套文件也保护起来。<br />
    <br />
    此种方式能很有效地保护java代码。<br />
    <br />
    缺点：可以通过替换JRE包中与类装载相关的java类或虚拟机动态库截获java字节码。<br />
    <br />
    jar2exe属于这类工具。<br />
    <br />
    </li>
    <li>提前编译技术(AOT)<br />
    <br />
    特点：将java代码静态编译成本地机器码，脱离通用JRE。<br />
    <br />
    此种方式能够非常有效地保护java代码，且程序启动比通用JVM快一点。<br />
    <br />
    具有代表性的是GNU的gcj，可以做到对java代码完全提前编译，但gcj存在诸多局限性，如：对JRE
    5不能完整支持、不支持JRE 6及以后的版本。<br />
    <br />
    由于java平台的复杂性，做到能及时支持最新java版本和JRE的完全提前编译是非常困难的，所以这类工具往往采取灵活方式，该用即时编译的地方还是
    要用，成为提前编译和即时编译的混合体。<br />
    <br />
    缺点：由于与通用JRE的差异和java运用中的复杂性，并非java程序中的所有jar都能得到完全的保护；只能使用此种工具提供的一个运行环境，如果
    工具更新滞后或你需要特定版本的JRE，有可能得不到此种工具的支持。<br />
    <br />
    Excelsior JET属于这类工具。<br />
    <br />
    </li>
    <li>使用jni方式保护<br />
    <br />
    特点：将敏感的方法和数据通过jni方式处理。<br />
    <br />
    此种方式和&#8220;隔离java程序到服务端&#8221;有些类似，可以看作把需要保护的代码和数据&#8220;隔离&#8221;到动态库中，不同的是可以在单机程序中运用。<br />
    <br />
    缺点和上述&#8220;隔离java程序到服务端&#8221;类似。<br />
    <br />
    </li>
    <li>不脱离JRE的综合方式保护<br />
    <br />
    特点：非提前编译，不脱离JRE，采用多种软保护方式，从多方面防止java程序被窃取。<br />
    <br />
    此种方式由于采取了多种保护措施，比如自定义执行器和装载器、加密、JNI、安全性检测、生成可执行文件等等，使保护力度大大增强，同样能够非常有效地保
    护java代码。<br />
    <br />
    缺点：由于jar文件存在方式的改变和java运用中的复杂性，并非java程序中的所有jar都能得到完全的保护；很有可能并不支持所有的JRE版本。<br />
    <br />
    JXMaker属于此类工具。<br />
    <br />
    </li>
    <li>用加密锁硬件保护<br />
    <br />
    特点：使用与硬件相关的专用程序将java虚拟机启动程序加壳，将虚拟机配套文件和java程序加密，启动的是加壳程序，由加壳程序建立一个与硬件相关的
    受保护的运行环境，为了加强安全性可以和加密锁内植入的程序互动。<br />
    <br />
    此种方式与以上&#8220;不脱离JRE的综合方式保护&#8221;相似，只是使用了专用硬件设备，也能很好地保护java代码。<br />
    <br />
    缺点：有人认为加密锁用户使用上不太方便，且每个安装需要附带一个。</li>
</ol>
<p>从以上描述中我们可以看出：</p>
<ol>
    <li>各种保护方式都有其优缺点，应根据实际选用</li>
    <li>要更好地保护java代码应该使用综合的保护措施</li>
    <li>单机环境中要真正有效保护java代码，必须要有本地代码程序配合</li>
</ol>
<p>当然，安全都是相对的，一方面看你的保护措施和使用的工具能达到的程度，一方面看黑客的意愿和能力，不能只从技术上保护知识产权。总之，在java
代码保护方面可以采取各种可能的方式，不可拘泥于那些条条框框。</p>
<img src ="http://www.blogjava.net/javarun/aggbug/325645.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/javarun/" target="_blank">javarun</a> 2010-07-09 14:00 <a href="http://www.blogjava.net/javarun/archive/2010/07/09/325645.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>