Please be patience, loading the applet may take some time.
Sorry you need a java enabled browser to test a java applet ;-)
Don't read the rest, it only contains information about the applet.
Press the start button to decompile Michael's -Plasma applet (and give the decompiler some time to download the -jar file).
%3a
This section contains features that I think would be great to have, -but are also very hard to implement. The name of the section is -inspired, by Mozilla.
Currently this are all my own ideas. But if you send me an idea -for an interesting feature, I will add it to this list.
If java gets called with `-O' switch, it inlines methods, -that are private, final, or static and contain no loops. When -decompiling this it sometimes produces really ugly code. The right -way to solve this would be to outline the code again. This is -possible but requires to find the inlined method.
-O
The name `outline' was suggested by Michael. -
The local variable naming is very stupid. Even with pretty it just -names the variable after the type with a unifying number appended. A -method containing very much objects of the same type looks very -ugly.
My plan is looking at the assignments. If we have locals in -assignments -
-int l_1 = array.length -String l_2 = object.getName() -
-MenuItem local_1 = new MenuItem("Open"); -MenuItem local_2 = new MenuItem("Save"); -
miOpen
miSave
It is currently possible to assign a (hint name,type) pair -to a local. If the type matches, the local will be named after -hint name. This could be extended by giving them several -weighted hints and constructing the name in an intelligent way.
First there should be a good Renamer: Methods that simply -return a field value should be renamed to getFieldName. -Fields should be named after their type, maybe also by assignments -(see section about local variable names).
The deobfuscator should detect inner and anonymous variables, -synthetic methods and so on, and rename them accordingly.
The obfuscator should detect Class.forName constructs (and -similarly for methods and fields) and if their parameters are constant -it should change the parameter according to the rename function.
It would be nice if the decompiler could merge the javadoc comments -into the class file. More and more people use javadoc to comment the -public api of their java classes. It shouldn't be too difficult to -copy them back into the java code.
This doesn't need to be built into the decompiler. A script that takes -the javadoc pages and the decompiled code can easily merge them.
Click here to download -the latest released source code of JODE . You need several -other packages to build JODE, check the links page.
The simplest way to get it, especially for non unix users, is in -precompiled form, though. I have two jar archives at the ftp server. You may -need to press shift while clicking on the link, depending on your -browser. - - -
You can get the latest sources from the CVS -repository. They may not always compile, though. If you want an -older version you can use the -r option:
-r
-r jode_1_0_93
-r branch_1_1
To build the sources from CVS change to the main directory where -the configure.in file resides and run - -
configure.in
aclocal && automake -a && autoconf
Jode is available in the download area in source or +binary form. For compiling the source code, you need several other +packages, check the links page. You +need a unix like environment for compilation.
The simplest way to get it, especially for non unix users, is in -precompiled form, though. I have two jar archives at the ftp server. You may -need to press shift while clicking on the link, depending on your -browser. +precompiled form, though. There are two jar archives in the download +area:
jode
To build the sources from CVS change to the main directory where the configure.in file resides and run @@ -43,5 +36,5 @@ the configure.in file resides and run
The class isn't verifiable, probably because there is not enough +information about used classes. See the question about the +classpath.
This could also be caused by malicious bytecode, or because there +is a bug in Jode's verifier.
Jode needs to know the full class hierarchie to guess the types. +This includes not only the classes in the program, but also the +libraries used by the java program, even the Java runtime library. +You should set the classpath to include all these classes.
If you don't specify the classpath on the command line, Jode uses +the same as your Java Virtual Machine.
As last resort, if Jode can't find a class in the classpath it uses +reflection to ask the Virtual Machine. This works quite well, but +loading classes can have side effects, e.g. when AWT classes are +loaded, an AWT thread is created, even though Jode doesn't need +it.
MyClass$Inner.class
You should decompile the outermost class (MyClass in +this case). The produced code contains the inner class.
MyClass
The program, all libraries, the Java runtime library. Don't omit a +library even when you don't want to obfuscate it.
The most common mistake is to preserve a class. In most cases this +is not what you want. This only makes sure the class won't be +renamed, it doesn't prevent it from being stripped. Instead you +should preserve methods and constructors. The constructor is just a +method with the special name <init&rt;.
Another common mistake is to omit the type +signature, e.g. to preserve Class.main instead of +Class.main.([Ljava/lang/String;)V. That doesn't work. If +you don't want to care about the format of the type signature use a +wildcard as in Class.main.*.
The type signature is a machine readable representation of a java +type that is used all over in java bytecode. The JDK ships a command +named javap. With java -s you can lists the fields +and methods of a class with their type signatures.
If you are interested in the format of type signatures read the +Java Virtual Machine Specification, Chapter 4.3 Descriptors
You can report bugs to the bug forum. -Please send me a short notice if you add a bug.
You can contact me per email via hoenicke at -users.sourceforge.net. Please mention jode in the -subject.
There is a mailing list. Check this page for subscription informations.
You can report bugs to the bug forum.
You can contact me per email via You can contact me by email via hoenicke at -users.sourceforge.net. Please mention Jode in the +users.sourceforge.net. Please mention jode in the subject.
Someday I found guavad, a disassembler for java byte -code (it does similar things like javap -c). I used -it on a class file, and found that it was possible to reconstruct the -original java code. First I did it by hand on some small routines, -but I soon realized that it was a rather stupid task. So I wrote a -small perl script that -did this process automatically. At the end of the next day I had my -first working decompiler.
guavad
javap -c
perl
Now while the perl script is working, it is not easy -to use. You have to decompile the code first with a disassembler, cut -out the code of a single method, and run the perl script on it. I -decided to get the bytecode directly out of the class files and do -this all automatically. I decided to write it in java -now, because it suited best.
java
Just for the records: the java code is now more than 50 times -bigger than the original perl script and is still growing.
JODE is a java package containing a decompiler and an -optimizer for java. This package is freely available under the GPL -(see license).
- -
The decompiler takes class files as input and produces -something similar to the original java file. Of course this -can't be perfect: There is no way to produce the comments or the names -of local variables (except when compiled with debuging) and there are -often more ways to write the same thing. But JODE does its job -quite well, so you should give it a try: start -the applet.
The optimizer transforms class files in various ways with -can be controlled by a script file. It supports the following -operations:
If not all dependent classes can be found, the verifier (which is - run before decompilation starts) may exit with a type error. You - can decompile it with --verify=off, but take the warning - serious, that types may be incorrect. There's sometimes no way to - guess the right type, if you don't have access the full class - hierarchie. - - This is not a bug in the verifier: java will complain the same way, - if it is run with bytecode verification turned on. And if you don't - have the dependent classes, you can't compile the code again.
There may be situations, where the code doesn't understand complex -expressions. In this case many ugly temporary variables are used, but -the code should still be compileable. This does especially happen -when you compile with `-O' flag and javac has inlined some -methods.
Sometimes this program may exit with an Exception or -produce incorrect code. Most time the code can't be compiled, so that -it can be easily spotted. If you have one of these problems (except -those that occur on some of the jode.test files, I would -be very interested in a bug report (including the class -file, if possible).
Exception
jode.test
class
Sometimes JODE generates some GOTO expression and labels. -This shouldn't happen any more with code produced by javac or jikes. -But some flow obfuscator may provoke this. In that case you can run -the Obfuscator first (to optimize away the flow obfuscation ;-).
+optimizer for java. This package is freely available under the GNU GPL.
-
The decompiler reads in class files and produces something +similar to the original java file. Of course this can't be +perfect: There is no way to produce the comments or the names of local +variables (except when compiled with debuging) and there are often +more ways to write the same thing. However, JODE does its job quite +well, so you should give it a try and start the +applet.
The optimizer transforms class files in various ways with can be controlled by a script file. It supports the following @@ -28,14 +28,23 @@ fields
Some jdk1.3 synthetic access functions aren't understood. The + produced source contains access$xxx functions, but it still compiles.
There may be other bugs, that cause Exceptions or invalid code. + If you have such a problems don't hesitate to issue a bug report. + Please include the class file if possible.
If not all dependent classes can be found, the verifier (which is @@ -55,15 +64,4 @@ the code should still be compileable. This does especially happen when you compile with `-O' flag and javac has inlined some methods.
JODE is Copyright © 1998-2000 by Jochen Hoenicke. - -
This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public -License as published by the Free Software Foundation; either -version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, -but without any warranty; without even the implied warranty of -merchantability or fitness for a particular purpose. See the -GNU General Public License for more details.
gnu.java.util.collections
-set CLASSPATH=C:\download\jode-1.0.93-1.1.jar;C:\swing\swingall.jar -
export CLASSPATH=/tmp/jode-1.0.93-1.1.jar:/usr/local/swing/swingall.jar
setenv CLASSPATH /tmp/jode-1.0.93-1.1.jar:/usr/local/swing/swingall.jar
- jar -xvf jode-1.0.93-1.1.jar bin/jode.bat resp. bin/jode -
java jode.decompiler.Main --help
jode --help
java jode.decompiler.Window
start
save
-java jode.swingui.Main --classpath classes.jar -resp.jode swi --classpath classes.jar -
If you want to integrate JODE into your own java program, -you can use the jode.decompiler.Decompiler -class. Note that the GPL only allows you to integrate JODE -into GPL programs. Please tell me if you use JODE in this -way.
jode.decompiler.Decompiler
You may use this stripped -down jar archive containing all necessary classes.
To use the obfuscator you should first create a script file, say myproject.jos. Then you can invoke the -obfuscator with: -
-java jode.obfuscator.Main myproject.jos -
The script file should contain the following options:
First select the classpath. You should include everything in the -classpath that you need to run your application. This also includes -the system class files (Sun puts them into classes.zip or -rt.jar))
classes.zip
rt.jar
-classpath = "c:\\jdk1.2\\jre\\lib\\rt.jar","d:\\project\\java", - "ftp://www.myorg.org/pub/classlib.jar" -
Specify where you want the obfuscated classes to go. I recommend -to write them directly into a zip file, but you can also give a -directory.
-dest = "obfuscated.zip" -
You can make JODE write its translation table. This table -can be used later to undo the name obfuscation, or you can look there -to decrypt exceptions you may get.
-revtable = "translat.tbl" -
Select what you want to strip. There are several -possibilities, which can be separated by comma(,):
-strip = "unreach","lvt","inner" -
Select the packages and classes you want to obfuscate. You should -only include libraries, that you don't ship separately. If you give a -package, all classes and subpackages are loaded. You can also use -* as wild card, that matches everything (including dots). -
*
-load = new WildCard { value = "org.myorg.myproject" }, - new WildCard { value = "org.myorg.mylib*" }, - new WildCard { value = "org.otherorg.shortlib" } -
Select the methods and classes you want to preserve. This is -the main method for applications and the default constructor -<init>.()V for applets, resource bundles and other classes -that you load manually at runtime. You have to give the method -name and the type signature to identify your method. javap --s will show you the type signatures for your classes, but you -may also use *, to select all methods with that name.
-preserve = new WildCard { value = "org.myorg.ApplicationClass.main.*" }, - new WildCard { value = "org.myorg.AppletClass.<init>.()V" }, - new WildCard { value = "org.resources.Bundle*.<init>.()V" }, -
If you want to obfuscate (or just shorten) the identifier you can -specify a renamer. There are currently following renamer -available
-renamer = new StrongRenamer -
You can also create a renaming table with the same format as the -table written by revtable. The entries in the table get precedence -over renamer. Entries not in the table will get renamed by the -renamer.
-table = "translat.tbl" -
Now you can select the analyzer. The purpose of the -analyzer is to mark all reachable methods, find out which methods -needs to get the same name (overloading), and which method names -mustn't change (overload of library methods, e.g. nextElement -for Enumerations). There are currently two analyzers. -
-analyzer = new ConstantAnalyzer -
Pre- and Post transformers transform the bytecode before -resp. after the Analyzer runs. Using this default should be okay. -You may remove the LocalOptimizer, though, if you have problems.
In the future I may add some new post transformers, that do string -encryption, flow obfuscation and similar things. If you want to write -your own Transformers please contact me, since the next version will -change the bytecode interface.
-post = new LocalOptimizer, new RemovePopAnalyzer -
After you have downloaded the jar archive +put it into your CLASSPATH. The package +swingall.jar is also needed if you are using JDK 1.1.
-set CLASSPATH=C:\download\jode-.jar;C:\swing\swingall.jar +set CLASSPATH=C:\download\jode-.jar;C:\swing\swingall.jar
export CLASSPATH=/tmp/jode-.jar:/usr/local/swing/swingall.jar
setenv CLASSPATH /tmp/jode-.jar:/usr/local/swing/swingall.jar
- jar -xvf jode-.jar bin/jode.bat resp. bin/jode + jar -xvf jode-.jar bin/jode.bat resp. bin/jode
java jode.decompiler.Main --dest srcdir program.jar
jode --dest srcdir program.jar
-java jode.swingui.Main --classpath classes.jar -resp.jode swi --classpath classes.jar +java jode.swingui.Main classes.jar +resp. jode swi classes.jar
The swing interface will show the package hierarchie of all classes in the classpath on the left side. You can now select a class and the decompiled code will appear on the right side. Via the menu, you may change the classpath or switch between package hierarchie tree and -class inheritence tree. +class inheritence tree.
The swing interface is very useful to browse through class files if you don't have the source code. You can also use it to trace bugs in library code. It is not meant to generate java files and so -you won't find a save option there. +you won't find a save option there.
If you want to integrate JODE into your own java program, you can use the jode.decompiler.Decompiler +href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jode/jode/jode/decompiler/Decompiler.java?rev=jode_1_1&content-type=text/vnd.viewcvs-markup" +>jode.decompiler.Decompiler class. Note that the GPL only allows you to integrate JODE into GPL programs. Please tell me if you use JODE in this way.
You should ship jode-1.1-embedded.jar with your program. This jar file is +available in the download area. +It works only under JDK 1.2 and above.
jode-1.1-embedded.jar
