Objective | Name obfuscation | Flow obfuscation | String encryption |
---|---|---|---|
Mimimum bytecode size | yes | no | no |
Balance between size and protection |
yes | yes | no |
Maximum protection | yes | yes | yes |
If the specified file already exists then it will be overwritten. Note that you should keep the change log produced when you obfuscate your final release in a safe place.
List item | Explanation |
none | Select this setting if you don't want to use flow obfuscation. |
light | Select this setting if your classes must run in the widest variety of JVMs. "Light" flow obfuscation works around a number of JIT compiler bugs that can cause some flow obfuscated bytecode to fail. |
normal | This setting performs a more thorough obfuscation than the "light" setting. However, it increases the risk that your bytecode will not run on some buggy JIT compilers. |
aggressive | This setting performs a more thorough obfuscation than the "light" and "normal" settings. However, it increases the risk that your bytecode will not run on some buggy JIT compilers. |
List item | Explanation |
none | Select this setting if you don't want to use String encryption. |
normal | Select this setting if you want Zelix KlassMaster to encrypt your String literals in the most basic fashion. This setting will leave String literals in interfaces unencrytpted. |
aggressive | This setting encrypts your String literals as with the "normal" setting but Zelix KlassMaster will attempt to use a more sophisticated approach that allows the encryption of Strings in interfaces. However, for runtime performance reasons, this more sophisticated approach will not be used in the case of interfaces with many (ie. 500 or more) String literals. In these cases the Constant Value Attributes associated with the interface "static" String fields will be cleared and Zelix KlassMaster will output a warning. The clearing of the fields is only a problem if the "static" String fields need to be accessed at runtime by classes outside of your application or if you need to compile other classes against your obfuscated classes. |
flow obfuscate | This setting encrypts your String literals as with the "aggressive" setting but it will also add a flow obfuscated version of the special decrypt instructions to your classes. As with the "aggressive" setting, in interfaces with many String literals, the Constant Value Attributes associated with the interface "static" String fields may be cleared. |
Packages whose names have been excluded from being changed are never collapsed. So packages with excluded superpackages will be collapsed into the nearest excluded superpackage. If a package has no excluded superpackage then it will be collapsed into the package specified in the "Default name" field that appears to the immediate right of the "Collapse packages" box. If the the "Default name" field is empty then packages with no excluded superpackage will be collapsed into the Java default package "" (which is no package at all).
Remember that one of the purposes served by package names is to ensure that fully qualified class names are unique. If you collapse your packages into the Java default package (ie. no package) then Zelix KlassMaster will ensure that your class names are unique within your application. However, you must be sure that there will be no runtime name clashes with other default package classes in the runtime classpath.
Take as an example the following set of packages.
com
|
If you
1. select the "Collapse packages" box
2. exclude the com.mycompany
package name from being excluded
3. enter foo
into the "Default name" field
then the packages will be collapsed as follows
com | => | com |
com.mycompany | => | com.mycompany |
com.mycompany.package1 | => | com.mycompany |
com.mycompany.package2 | => | com.mycompany |
com.yourcompany | => | foo |
com.yourcompany.package1 | => | foo |
giving the result
com
|
Typically you would only collapse the package structure if your obfuscated classes were self contained.
The following settings are typical for the different application types.
Application type | Ok to collapse packages? |
Non-extensible library | No |
Extensible framework | No |
J2ME MIDlet | Yes |
Self contained application or applet | Yes |
Generally, Inner Class attributes are not used at runtime so, removing them can reduce your bytecode size. However, Inner Class attributes are used by some debuggers and by compilers. If you need to compile other classes against your obfuscated inner classes then you should not select this option.
|
Explanation |
delete | This setting instructs Zelix KlassMaster to delete all Line Number table information. It reduces the size of bytecode that contains Line Number tables but it means that stack traces produced by the bytecode cannot contain line numbers. |
scramble | This setting instructs Zelix KlassMaster to scramble all Line Number table information. There is no size reduction but the JVM will be able to produce stack traces containing line numbers. However, because the line numbers will be scrambled, you would have to use a tool like the inbuilt Zelix KlassMaster Change Log Translate tool to convert them back to the original line numbers. Most importantly, it would be very difficult for a decompiler to make use of the scrambled line number information to improve the quality of the source code it produces. |
keep | This setting instructs Zelix KlassMaster to keep all Line Number table information in its original form. There is no size reduction and there is a risk that the original line number information could be used by a decompiler to improve the quality of the source code it produces. However, any stack trace line numbers will map directly to the original source code. |