Zelix KlassMaster Frequently Asked Questions
Version 1.0.2
- Why wont Zelix KlassMaster run?
- Does Zelix KlassMaster run under JDK v1.0.2?
- Does Zelix KlassMaster support JDK v1.1?
- Will Zelix KlassMaster run in UNIX, in an Apple OS or using the Microsoft SDK 2.0?
- Does Zelix KlassMaster's Unobfuscate reverse it's Obfuscate?
- Why don't all names change when I obfuscate or unobfuscate?
- Wont string encryption slow down my code and make it bigger?
- When I change a method name in one class, why do some methods in other classes also get
renamed?
- When changing a method name, why do I get the message
"New name clashes with a method in Class name" when the class mentioned doesn't seem
to be related to the class that defines the method?
- Why wont it let me change package names?
- After being obfuscated why does my code get the runtime errors "VerifyError" or
"NoClassDefFoundError" or "Can't find class Classname"?
- Are there classes that Zelix KlassMaster can't reliably process?
- When I load some classes why do I get the "Class Load Warnings" screen?
- When I load some classes why do I get the "Class Load Errors" screen?
- What options should I use when obfuscating my classes?
- What can I do if I get an "insufficient memory" error?
- Why does Zelix KlassMaster run so slowly?
Answers
There could be a number of problems.
- You cannot run Zelix KlassMaster using Java 1.0.2 or lower.
- Zelix KlassMaster will not run with verification switched on.
- The file klassmaster.jar must be in your classpath or be unjarred (
jar -fx klassmaster.jar) into a directory that is in your classpath.
- Zelix KlassMaster may not run on your operating system. See the answer to Q4.
If you are not getting a useful error message, try running with the -verify and -verbose switches. As stated above, Zelix KlassMaster will not run with the -verify switch but you may get some clues as to why it wont run when verification is switched off.
No. Zelix KlassMaster requires JDK 1.1 to run. Of course it can still load and process JDK 1.0.2 bytecode.
Zelix KlassMaster recognizes Inner Classes and optionally retains Inner Class information. It has been successfully tested on Java 1.1 applications and applets.
Zelix KlassMaster is written entirely in Java 1.1 and technically should run on any platform that supports a 1.1 Virtual Machine. However differences in the file systems and GUIs can cause problems. It has only been tested on
Also Zelix KlassMaster will not run if you use the Microsoft SDK for Java 2.0. This problem is being investigated.
No. Obfuscation irreversibly removes the original meaningful names. Unobfuscation simply makes names legal and readable and removes ambiguity. Also, unobfuscation doesn't reverse string encryption.
There are a number of reasons why all class, field or method names don't change when you obfuscate or unobfuscate.
- The name is public or protected and your obfuscate or unobfuscate options say that
public or protected names shouldn't be changed.
- The name of a package scoped method is overridden to be protected or public in a subclass.
If your obfuscate or unobfuscate options say that protected or public method names shouldn't
be changed then the overridden method name can't be changed without breaking the polymorphic
link.
- The name of a method overrides a method in a superclass or implements a method in an interface
but the superclass or interface hasn't been loaded into Zelix KlassMaster. In such cases the
method name cannot be changed without breaking the polymorphic link.
Encrypted strings are decrypted at runtime using code that has been added to the class. This means that the class will run slower and will be bigger. How much slower and bigger depends upon the design of the class. If all of the class's string literals are coded as static final variables (e.g. static final String s = "Hello World;") then the decryption will be done only once at the time of class initialization which greatly reduces any performance degradation. The bytecode size increase is typically only significant for trivial classes. It is recommended that you measure the impact on your classes.
When you change a method name, Zelix KlassMaster automatically changes all method names that are polymorphically linked to that method. So overridden methods in superclasses and overriding methods in subclasses must also be renamed. If the method is an implementation of an interface method then the method in the interface and the corresponding methods in all classes that implement that interface must also be renamed. So the change can ripple across to different branches of the class hierarchy.
The answer to Q8 explains how a method name change can ripple across to different branches of the class hierarchy. So Zelix KlassMaster must check that the new name wont clash with existing names in these other classes. A name clash occurs if the proposed new signature
- already exists in a class
- already exists in a superclass or subclass so that a new polymorphic relationship would be created.
Zelix KlassMaster can only change package names if you are changing all class names. Change your obfuscate or unobfuscate option settings.
This will happen if you obfuscate your bytecode using Java illegal identifiers or adding heavy corruption, and
you have run you code with verification switched on. (Verification is on for applications run with the -verify switch and is always switched on for Applets.) You cannot use illegal identifiers or add heavy corruption if your classes must run after being verified.
Alternatively, you will get such messages even when not runing with verification if you have renamed your highest level package qualifiers so that class names are Java illegal when fully qualified. For example a class named com.1.0 will cause no problems when running without verification but a class named 1.1.0 will cause problems.
Some classes cannot be reliably obfuscated, unobfuscated or have any names changed. Examples are classes that hardcode package, class, field or method names in a string and then
- at runtime, test a class, field or method's name against that string
- create Class, Field, Method or Constructor instances at runtime using that string
When Zelix KlassMaster loads a class that it might not be able to process reliably it reports the fact using the "Class Load Warnings" screen. See the answer to Q13 for more detail.
Some classes cannot be processed reliably. (See the answer to Q12 for more detail.) When Zelix KlassMaster loads a class that it might not be able to process reliably it reports the fact using the "Class Warnings Screen".
You get the "Class Load Warnings" screen whenever a loaded class contains a call to one or more of the following methods:
- Class.forName(String)
- Class.getName()
- Class.getField(String)
- Class.getMethod(String)
- Class.getDeclaredField(String)
- Class.getDeclaredMethod(String)
- Field.getName()
- Method.getName()
- Constructor.getName()
- ClassLoader.loadClass(String,boolean)
- ClassLoader.defineClass()
- ClassLoader.findSystemClass(String)
- ClassLoader.findLoadedClass(String)
Zelix KlassMaster may still be able to process classes that contain some of the above method calls. For example, calls to Class.getName() are often made for debugging purposes. In these cases, the user must look at the way the call is used to determine if the class can be reliably processed.
Some obfuscators add corrupt information to bytecode files in the hope of confusing or crashing decompilers. Zelix KlassMaster detects this corrupt information and reports the fact using the "Class Load Errors" screen. Corrupt Local Variable Table and Inner Class information is automatically removed.
Generally, don't select the "keep inner class information" and do select "remove line number tables". This will reduce the size of your bytecode. The "encrypt string literals" option is generally safe provided you have no public or protected final String fields that may be accessed from outside the packages you are obfuscating. However, string encryption does make your bytecode somewhat larger and slower (see the answer to Q7).
If you are obfuscating an applet then select the "legal identifiers" option but don't select the "add corrupt symbolic entries" with "heavy corruption" option. Applet bytecode is fully verified before being run. Otherwise it should be safe to change all package, class, field and method names.
If you are obfuscating an application that doesn't have to run with verification switched on then you can get extra protection by using illegal identifiers and by adding heavy corruption. However, if you are using illegal identifiers and you are changing package names then make sure that your top level package qualifier(s) wont be changed. Class names must always be Java legal when fully qualified. Otherwise it should be safe to change all lower level package names and class, field and method names.
If you are obfuscating a package that will be used by third parties as a class library then you should
- not obfuscate package names
- not obfuscate public class names
- not obfuscate public or protected field or method names
- not encrypt string literals if you have any public or protected final String fields
- not select the "remove line number tables" option.
Please note that whatever options you choose it remains your responsibility to fully test or retest your classes after they have been processed by Zelix KlassMaster.
Zelix KlassMaster holds a lot of information in memory for each class that it loads. So, the more classes you load and the more complicated those classes are the more memory you need. If Zelix KlassMaster tells you that there was insufficient memory to load your classes or if it crashes with an OutOfMemoryException then you can do one of the following:
- Give java more memory to work with by using the -mx??m option where ?? represents the number of megabytes. (For example, the option -mx48m gives java 48 megabytes of heap space.)
- Install more physical memory.
It is not recommended that you make use of virtual memory (by giving java more memory to work with than is physically installed.) Performance will be unreasonably slow.
There are a number of reasons Zelix KlassMaster may run slowly.
- Your computer may have insufficient real memory installed. If your computer has to
use virtual memory performance will be very poor. You will notice that the hard disk
is being very heavily utilized.
- You are obfuscating or unobfuscating while viewing a very large class or method. This
results in reduced performance due to the overhead of updating the class or method
details.
- You are using the Sun JDK 1.1.4 for Windows. This version of the JDK has a bug
in it's AWT List component that can reduce the performance of Zelix KlassMaster
markedly. If you can, use the JDK 1.1.3 instead.
Copyright © 1997 Zelix Pty Ltd (ACN 078 740 093)
