基于JVMTI的Java字節码保护技术的研究和实现v022.docVIP

PAGE \* MERGEFORMAT 1 基于JVMTI的Java字节码保护技术的 研究和实现 吴芳 （陕西省纺织科学研究所，西安 710038） 摘要：本文分析了Java字节码保护技术的现状，在此基础上提出了一种基于JVMTI的Java字节码保护技术，使得Java字节码的安全级别相当于传统的二进制代码。本文还给出了该技术在Windows平台和Linux平台下的实现方案。 关键词：Java；JVMTI；字节码保护；安全级别 引言 C/C ++等编程语言开发的程序被编译成本机可执行的二进制代码。编译器用内存地址代替了程序中的变量名称、方法名称等信息。因此对这些本地二进制代码进行反编译从而得到源代码是非常困难，甚至是不可能的。 Java是一种跨平台的、解释型语言。Java编译工具将Java 源代码被编译成为class文件（即Java 字节码），由Java 虚拟机（Java Virtual Machine，JVM）负责对class文件进行解释执行。与本地目标代码不同，class文件中仍然保留了方法名称、变量名称，并且通过这些名称来访问变量和方法，这些符号往往带有许多语义信息。因此，对class文件进行反编译就显得比较容易。目前，市场上有许多Java的反编译工具，有免费的，也有商用的，还有的是开放源代码的。这些工具都能够从class文件生成高质量源代码。所以，如何保护Java程序就变成了一个非常重要的挑战。 Java字节码保护技术的现状 目前主要有有如下几种Java字节码保护技术：隔离Java程序、字节码混淆、转换本地代码、数字水印、自定义类加载器等。 隔离Java程序是指将关键的class文件放在服务器端，客户端通过访问服务器的相关接口来获得服务，而不是直接访问class文件。这样黑客就没有办法反编译class文件[1]。HTTP、Web Service、RPC等标准和协议都能够支持通过接口提供服务。但是有很多应用都不适合这种保护方式，例如对于单机运行的程序就无法隔离Java程序。 字节码混淆主要是通过将定义的类、变量、方法和包的名字改为无意义的字符串、使用非法的字符代替变量符号和在软件中添加一些无关的指令或永远执行不到的指令[2]等手段来增加反编译和对反编译后源代码阅读的难度。但这种方法并不能真正阻止反编译，而且不论是开源的或是商用的混淆工具都有一定的规律可循，如果掌握这些规律，在反编译时仍然可以得到一定质量的源代码。 转换本地代码即将Java程序像C/C++程序编译成本机可执行的二进制代码，目前TowerJ、jexegen、JET、JOVE、JToEXE等工具都能做到这一点。但是这样做使得Java程序失去其跨平台的特性，而且这种技术目前并不十分成熟，因此不适用于大型应用程序。 数字水印技术是在class 文件中嵌入以数字水印形式存在的开发者的签名[3]。数字水印技术并不能阻止反编译，但是能在确认某些程序是否属于剽窃时提供有效的证据。 自定义类加载器是指首先将class文件进行加密处理，然后自己编写一个Java类装载器（即继承java.lang.ClassLoader并重载其loadClass方法）在class文件装载时再进行解密处理。这种方法的缺点在于虽然经过加密的class文件无法被反编译，但自定义的类加载器本身却不能防止被反编译。因此，加密过的class文件仍然是不安全的。 另外，一些商用的专业数据加密软件也能提供对Java字节码的保护，如HASP、CodeMeter等，其原理是对Java程序和java.exe都进行加壳处理，在Java程序运行时需要连接加密狗进行解密。这种方法虽然安全性较高但是对于不使用java.exe来运行的Java程序（如Eclipse平台使用的是javaw.exe）则无能为力。因此通用性较差。 利用JVMTI和JNI保护Java字节码 通过第一节对Java字节码保护现状的分析可以得出结论：要找到一种更好Java字节码保护方法则必须满足以下3个条件： 能够有效防止反编译，使得Java程序的安全级别相当于本地应用程序。 保持Java程序的跨平台特性。 不修改JVM。 将class文件作为数据文件进行加密是比较容易的（关于数据加密的算法很多，在此不再赘述），实现了这一步即可阻止对class文件的直接反编译。但问题的关键在于何时以何种方式将加密过的class文件安全地解密？首先来分析一下JVM的类加载机制。 JVM的类加载机制 Java 语言是一种动态性的解释型语言。Java编译器将每个类和接口都编译成一个单独的class 文件，这些文件对于JVM来说就是一个个可以动态加载的单元，这些文件只有在需要使用时才会被加载。当指定程序运行的时候，JVM就将class 文件按照需求和一定的规则加载到JVM的内存