Java开发网 - RETROGUARD(tm)字节码（.class文件）混淆器常见问题

Java开发网

您没有登录

» Java开发网 » Java Security

打印话题 寄给朋友 订阅主题

作者

RETROGUARD(tm)字节码（.class文件）混淆器常见问题

netboy

发贴: 0
积分: 0

于 2004-09-23 16:21

——译自Retrologic Systems
1，为什么要混淆？

除了Java文件中的注释，Java字节码包括其源文件的所有的信息。竞争对手用一种称为反编译器的工具能够容易地反转你的.classes文件为Java文件。考虑到这种威胁，在发布你的软件前混淆你的.class文件是必要的。

2，混淆器如何改变Java classes文件？

混淆处理从classes文件删掉所有不必要的信息（行数，本地变量名称，用于调试的源文件名称）。并且，类（class)、接口、数据（field）和方法（method）标识都会被重命名以使其无意义。

3，混淆可逆吗？

不可以。混淆是一种单向的信息损耗处理。

4，哪些Java版本与RetroGuard兼容？

RetroGuard用Java语言写成，运行在JDK1.1到JDK1.4系统，可以混淆所有有效的Java字节码。特别地，JDK1.1引入的内部类扩展（inner class extensions，含综合属性）能被正确处理。

5，RetroGuard需多少钱？

RetroGuard的发布遵从GNU Lesser General Public License,可免费用于商业和非商业用途。

6，为什么RetroGuard是一个命令行工具？

RetroGuard被设计为无缝集成到你的开发处理中。如果混淆工具的操作依赖于图形化用户界面，它就不能被集成到可靠的可重复的开发处理中。

7，为什么RetroGuard只能以JAR文件的方式工作？

为了判定混淆哪一个classes，大部分的混淆器以一个简单的入口点开始（一般是一个应用中的main方法或一个扩展自Applet的类），并且构造一个从这个点可访问到的所有类树结构。不幸的是，这种方法十分有限，只能处理一些简单的情况。如果你的代码有多个入口（几个应用、applets或JavaBeans，或者你的代码计划作为Java library使用），这种方法是不够灵活的。
作为替代，RetroGuard混淆一个JAR文件中的所有类和接口。JAR文件是对散布的classes文件进行打包的工业标准机制。—— 用Sun Microsystems公司的Java开发工具中的jar utility将classes文件打包为jar文件是容易的。JAR中的入口的数量可被RetroGuard脚本指定。这使混淆处理十分灵活。

8，CAB文件是什么？

虽然RetroGuard不能直接支持CAB文件，但是它可很简单地JAR classes，混淆这些类，对JAR解包，用微软的工具CAB这些类。

9，什么是RetroGuard脚本文件？

某些需要从外面对其访问的名称被混淆保留。这些被保留的名称可以为main方法和应用的类、扩展自Applets的类和JavaBean类。对一个Java libraries 的作者来说，当代码中有大量入口点时，这些被保留的名称的列表会变得很多。
RetroGuard脚本文件是这些被保留名称的列表。
默认情况下，在混淆期间所有不必须的类属性被掩饰。不过，万一你要保留这些属性，你可通过脚本文件来实现。

10，既然RetroGuard的脚本是灵活的，除了谨慎写列表外还有更容易的途径吗？

在RetroGuard中包括一个图形化用户界面使脚本的产生和更新更简单。必须要强调的是：这个GUI不能运行混淆器——RetroGuard，一个严格的命令行工具。 GUI的唯一目的是使产生脚本文件更容易。
GUI使扫描JavaBeans/applets/applications的JAR文件自动化，并且允许保留其他有些类、接口、方法或数据名称。

11，RetroGuard在混淆了Java classes文件后会使其质变吗？

不会。RetroGuard只输出有效且完全被验证过的Java字节码（在Tim Lindholm和 Frank Yellin合著的“The Java Virtual Machine Specification”中有介绍）。
作为对照，几个市场上的阻止反编译混淆器被介绍为非法或使类文件变质。
在JVM中检查类是否变质的组件叫验证器（verifier），默认情况下，所有下载的 applets在运行前都被其检查。目前的一批JVM中的验证程序没有JVM规范中指定的那么严格，但是将来的JVM会进行更严格的验证，混淆后变了质的Java代码将失效。使用会使混淆后的代码变质的混淆器的一种情况是当前的JVM不能发现其问题，这当然是不安全的——这是商业软件开发者在供不应求的情况下的冒险。

12,在混淆后为什么日志文件（log file）报告说有些名称没有被混淆改变？

由于继承的限制，有些标识不能被改变。例如，如果一个类实现了一个接口“java.util.Enumeration”，这个类从其继承的方法"hasMoreElements"和"nextElement"不能被改变。

13，是否有混淆前后的代码运行不一致的情况？

有。在JDK中有某些方法（在java.lang.Class,java.lang.ClassLoader中）用字符串名称指向类、方法或变量。如果在你的JAR文件中有这些方法，那么在混淆后可能不能正常执行，因为那些指向类、方法或变量的字符串名称被改变了。

14，如何解决上述问题？

如果在混淆过的JAR文件中有上述方法，RetroGuard会在日志文件中加一个警告。如果这些方法只作用于JAR文件以外的类、方法或变量将不会出现问题；但是，如果这些方法作用于JAR内的标识（类、方法或变量），这些标识就必须被RetroGuard script文件指定以便不对其混淆改变。

15，为什么“Class foo=com.company.MyClass.class;”类名称参照破例保留？

在JDK1.2中编译器用java.lang.Class.forName(String)方法构造类。因此，在用到Class.forName(String)方法时，类名称com.company.MyClass必须用script文件保留。

16，我的应用用到RMI。在混淆后会受影响吗？

是的。请在混淆时保留执行远程调用的类名称，这样远程调用将工作正常。

如果你还有不明白的请通过以下电子邮件联系：

info@retrologic.com

--2002/10/29--

附：原文

**RETROGUARD(tm) BYTECODE OBFUSCATOR** Frequently Asked Questions about obfuscation and RetroGuard. 1) Why obfuscate Java code? Java bytecode (*.class files) contains all of the information, apart from comments, that is in Java source (*.java) files. Using a tool called a 'decompiler' a hostile competitor can easily reverse engineer your Java classes. To counter this threat, it is possible to 'obfuscate' your class files before distributing your software. 2) How does obfuscation change the Java classes? The obfuscation process strips all unnecessary information (line numbers, local variable names and source file names used by debuggers) from the classes. Also, class, interface, field and method identifiers are renamed to make them meaningless. 3) Can obfuscation be reversed? No. Obfuscation is an information-lossy (one way) process. 4) What versions of Java is RetroGuard compatible with? RetroGuard is written in Java and runs on JDK1.1 through JDK1.4 systems. It will obfuscate all valid Java bytecode. In particular, the inner class extensions introduced with JDK1.1 (the 'InnerClasses' and 'Synthetic' attributes) are treated correctly. 5) How much does RetroGuard cost? RetroGuard has been released under the GNU Lesser General Public License, and is distributed at no charge for commercial or non-commercial use. 6) Why is RetroGuard a command line tool? RetroGuard is designed to be seamlessly integrated into your build process. This cannot be done in a reliable and repeatable fashion if the obfuscation tool depends on a graphical user interface for operation. 7) Why does RetroGuard act only on JAR files? To determine which classes are to be obfuscated, most obfuscators start at a single entry point (usually the 'main' method of an application, or the 'Applet'-derived class for an applet), and construct a tree of all classes accessible from that point. Unfortunately, this method is quite limiting and works only in simple cases. If your Java code has multiple entry points (several applications, applets, or JavaBeans, or if your code is intended to be used as a Java library) then this method is just not flexible enough. Instead, RetroGuard obfuscates all classes and interfaces within a JAR file. JAR files are the industry standard mechanism for packaging Java classes for distribution - it is easy to package your classes as a jar using the 'jar' utility distributed with the Java Development Kit from Sun Microsystems. Any number of entry points to the JAR can be specified using a RetroGuard script file. This allows the obfuscation process to be completely flexible. 8) What about CAB files? Though RetroGuard does not directly support CAB files, it is simple enough to JAR your classes, obfuscate them, unpack the resulting JAR, and CAB them with the Microsoft tools. 9) What is the RetroGuard script file? Certain names have be reserved from obfuscation because they are intended to be accessed from outside. These reserved names can include the 'main' method and class of applications, any classes derived from 'Applet', as well as JavaBean classes. For the writers of Java libraries this list of reversed names can become quite extensive due the the large number of entry points into the code. The RetroGuard script file is a listing of these reserved names. Also, by default, all unnecessary class attributes are trimmed fom each class during obfuscation. In the unlikely event that you want to retain any of these attributes, this can be done through the script file. 10) RetroGuard scripts are flexible, but can be tricky to write. Is there an easier way? A graphical user interface is included with RetroGuard to make script generation and updating more straightforward. It must be stressed that this GUI will not run the obfuscator - RetroGuard is strictly a command line tool. The GUI's sole purpose is to ease the generation of script files. This GUI enables automated scanning of a JAR for applications, applets and Java Beans (the most common entry points to a JAR), as well as allowing reservation of any other class, interface, method or field name. 11) Does RetroGuard introduce corruption to the obfuscated Java classes? No. RetroGuard outputs only valid and fully verifiable Java bytecode (as described in 'The Java Virtual Machine Specification' by Tim Lindholm and Frank Yellin). In contrast, several obfuscators on the market attempt to prevent decompilation by introducing illegal or corrupt entries to the class files. The component of a Java virtual machine which checks for corruption is called the verifier - by default, all downloaded applets are checked by the verifier before being run. In the current batch of virtual machines, the verification procedure is not as strict as that specified in 'The JVM Specification'. However, future virtual machines may have much stricter verifiers, and Java code obfuscated using corruption will simply fail. Using an obfuscator that corrupts in a way which happens not to be caught by current VMs is therefore unsafe - it is a risk that commercial software developers cannot afford to take. 12) After obfuscation, why does the log file report that some names are left unchanged? Due to inheritance constraints, some identifiers cannot be modified. For example, if a class implements the interface 'java.util.Enumeration', the methods inherited from that interface ('hasMoreElements' and 'nextElement') cannot be changed. 13) Are there situations where obfuscated code can behave differently than the original? Yes. There are certain methods (in the classes 'java.lang.Class' and 'java.lang.ClassLoader') in the JDK which refer to classes, methods or fields using a 'String' name. If these JDK methods are used to refer to identifiers inside your JAR, your code may behave incorrectly after obfuscation because the 'String' name may have been changed. 14) How can these problems be solved? RetroGuard adds a warning to the log file if these reflection methods are used in the obfuscated JAR file. If the reflection methods act only on classes, methods and fields outside of the JAR, there will be no problem. If, however, the reflection methods act on identifiers within the JAR, these identifiers must be specified in the RetroGuard script file so that obfuscation does not change them. 15) Why does the reference 'Class foo = com.company.MyClass.class;' break? The JDK1.2 compiler implements the '.class' construct using the 'java.lang.Class.forName(String)' method. So, as with any other use of 'Class.forName(String)', the class-name 'com.company.MyClass' must be reserved from obfuscation using the script file. 16) My application uses RMI. Will this work after obfuscation? Yes. Just reserve the class-names which implement 'Remote' from obfuscation, and RMI calls will work normally. If you have any questions please contact: info@retrologic.com --29th October 2002--

已读帖子

新的帖子

被删除的帖子