Q. How do I install ClassCracker?
A. Unzip the classcracker301.zip file which you downloaded to a directory named ClassCracker (case sensitive), then follow the instructions in Install.html. These instructions are also available here.
Q. Where can I find the ID of my copy of ClassCracker?
A. The ID is indicated in the "About ClassCracker" dialog box. From the menu select Help | About... to display this dialog box. Note that this ID is case-sensitive and must be copied exactly to an order form when purchasing.
Q. What versions of Java does ClassCracker 3 work with?
A. ClassCracker 3 requires Java 2 versions 1.3.x or 1.4.x to run. Users of Java version 1.3.0 will experience sluggish performance - it is recommended that you upgrade to versions 1.3.1 or 1.4.0 (download from http://java.sun.com).
ClassCracker 3 will decompile java class files from any Java version (from Java 1.0.1 upwards).
Q. Why don't my floppy and CD drives appear in the directory tree?
A. Removable media drives (floppy, CD, etc) are detected automatically only if they are loaded before ClassCracker is launched. The directory tree can be manually updated with the File | Refresh command.
Q. Some class
files decompile properly with all the variable names and method names. However when some other class files are decompiled, variables have names like 'locVar_5' and some methods even have names like '_$9315'. Why?
A. ClassCracker can only use the information that is contained in the class file. If the class file contains a local variable table (ie. it was compiled with debug information - usually the case during software development) then ClassCracker will recover all the variable and method names. If the class file does not have a local variable table (ie. it was compiled without debug information - this is usually the case with 3rd party software) then ClassCracker must create its own variable
names eg. 'locVar_1", 'locVar_2', etc. Method names such as '_$9315'
usually means that the class file has been obfuscated.
Note that even in these cases the decompiled java file produced by ClassCracker is still valid source code and can be recompiled by any java compiler.
Q. When I click on the File tab, the File Pane is empty even though I know there are files in that directory. What's going on?
A. ClassCracker only displays class files in a directory. If a particular directory does not contain any class files, it will appear empty.
Q. How can I tell which version of ClassCracker I have?
A. The ClassCracker version number is indicated in the "About ClassCracker" dialog box. From the menu, select Help | About... to display this dialog box.
Q. How can I tell which version of Java I have?
A. The Java version number is indicated in the "About ClassCracker" dialog box. From the menu, select Help | About... to display this dialog box.
Q. Why is the decompiled Java output from ClassCracker different from my original source code?
A. ClassCracker produces equivalent Java source code. By equivalent source code, we mean source code which is functionally identical to the original source code - the differences are then only stylistic. Differences between the original and decompiled source code are inevitable and occur with all decompilers. Sometimes, the decompiled code is more logical and elegant than the original - for example:
...
if( i < 10 ) {
a = b;
c += d;
}
else break;
fn( a, c);
...
might be decompiled as:
...
if( i >= 10 ) break;
a = b;
c += d;
fn( a, c);
...
If some doubts still remain about the accuracy of a decompilation, the following test can be performed:
Q. Why doesn't ClassCracker always reproduce 'for'
loops from my original source code?
A. A 'for' loop is nothing more than a shorthand version of a specialized 'while' loop construct. For example, the statement:
...
for( int i = 0; i < max; i++) statement;
...
can be replaced by the equivalent construct:
...
int i = 0;
while( i < max ) {
statement;
i++;
}
...
Since these two code snippets above are functionally equivalent, this is a stylistic issue which is subject to personal preference. Although, the above example is a straightforward 'for' loop, this is not always generally the case. To always convert to a 'for' loop would be unacceptable. ClassCracker always favors accuracy in the decompiled code over stylistic issues - in general, it will tend to produce more 'while' constructs than 'for' loops.
Q. Can ClassCracker
decompile obfuscated code?
A. Yes! The purpose of obfuscation is not to prevent decompilation but to make the decompiled code less meaningful. This is accomplished by giving variables and methods meaningless names. For example the valiable 'myvariable' might be given the name '_1234' and the method 'myFunction( )' might have its name changed to '_5678( )'. ClassCracker generally is able to decompile such obfuscated code but it is up to the user to infer the meaning of the obfuscated variables. Note that not all Java code, even commercial code, is obfuscated. Even when it is, not all variables and methods can be obfuscated; for example variables and methods which are declared public cannot be obfuscated.
Q. When attempting to decompile a Java class file, ClassCracker returns an error message. What is the cause?
A. The error message should be self-explanatory. Often, an error is due to an invalid, corrupted or obfuscated Java class file.