Some notes on reverse engineering Java code.
If you're lucky, you might be able to recompile the output from Jad. However, the Java VM has more lenient rules for variable naming than the Java language itself. For instances, a valid class file can have several variables named 'a', as long as they have different types. If you decompile such a class, the source code you get will not be valid.
JAD will usually rename the offending fields, and make a recompilable file... the only problem being that the recompiled file won't be compatible with the original classes.
Happily, with Jode you can customize the obfuscator by writing new renaming rules. You can actually use the obfuscator to de-obfuscate the class files before you decompile them: Make a rule file giving each variable a readable, unique name, preferably related to the type. {i,j,k} is much better than {i1,i2,i3}; {red,green,potato} is probably even better.
If you're lucky, you can deobfuscate the entire application, and patch that. If that doesn't work, you can deobfuscate, patch and recompile a class, and then re-obfuscate that class (by using the inverse mapping from the deobf step) and plonk it back into the application.
If the files are really mangled, you won't be able to recompile them at all (the byte code itself simply will not be representable as Java source code). You will need to disassemble the file, patch the byte code, and reassemble it.
The easiest way to do this is to add the code you need in a separate file, and just add static calls in the original file, like so:
.method public mousePressed(Ljava/awt/event/MouseEvent;)V .limit stack 4 .limit locals 6 aload_0 ; load this aload_1 ; load event invokestatic Patch/one(Lf;Ljava/awt/event/MouseEvent;)Z ifeq continue return continue: aload_0 getfield f/C I..and..
class Patch {
public static boolean one(f foo, MouseEvent ev) {
if(foo.z > 4) { // whatever calls you need
foo.x(); return true;
}
return false;
}
}
That way you can change the patch without having to reassemble and repackage everything.