Alo

I have download a nice applet. It works fine but a nag frame is coming up everytime i click on it....

I decompiler the class file with DJ java decompiler....The source file look almost like a ordinary java file.....but never mind...I found the bad guy

Now I want to compiler the file again....but the source file contains non java statements like "else", "goto".

Any body know a good obfuscation program or is there another way to get away with it.

Thx

Chitech

"else" is allowed in Java.


Have you tried using JAD yet?!

Oops just saw that DJ is a GUI front-end for JAD.. so never mind..

>> http://kpdus.tripod.com/jad.html

alo SiNTAX

U are rigth else is allowed

Do I have to know what kind of obfuscation program it's using so I can maybe use the build-in deobfuscation function.

Please guide me.....

Thx

Chitech

Hiya,

Though it is entirely possible that you might be able to recompile a decompiled class file, it will probably be problematic. And if it is obsfucated, you will never be able to recover a perfect copy of the original source. This is mainly due to the fact that obsfucators permanently remove information contained in the original class files (ie. like original variable and method names, which are renamed to meaningless garbage). There is no way to recover this information. It is also possible to transform / obsfucate the actual code flow such that it is more difficult to follow. It is my understanding that there are some deobsfucators which will attempt to reverse these obsfucating algorithms and transformations, but I have not used any of them myself and cannot vouch for their effectiveness. Zelix KlassMaster is an obsfucator / deobsfucator you could look at.

If recompiling the decompiled class files remains problematic, you might consider an alternative approach... And that is patching the Java bytecode itself, much like you would hex edit a regular .exe. In addition to "decompiling" Java classes, it is also possible to "disassemble" them. JCD is a disassembler that can be used for this task. Once disassembled, you will need to locate the function you need to patch and examine the surrounding asm instructions to plan your patch. In order to do this you will probably need to download a copy of the java opcode mnemonics. This should be available in the VM Class file specification from java.sun.com. Don't foget, that your patched class will be run through the java bytecode verifier so if your patch is overly, umm, "creative" it probably will not run You could also try to reassemble the disassembly using Jasmine, a java bytecode assembler.

If you want a more concrete explanation, +Tsehp did an essay on patching java a while back. You can find it here: http://www.woodmann.net/fravia/keyser_patching_java_essay.html

Cheers,
Clandestiny

alo Clandestiny

It's the hard way but just the information I need.

Maybe a solution : I can successful dump a java class from memory, will it still be a lot of garbage or is it been deobfuscation?. (sorry for my bad english)


Please guide me.

Thx

Chitech

If you just want to disassemble java byte code, then you could also use IDA, which is capable of disassembling Java Byte codes.

alo SiNTAX

Thx for the answer...


Chitech

I presume you're asking weather you can eliminate the obsfucation on a java class by dumping it from memory, as you would strip off the compression / encryption of a packed .exe by waiting until it had been loaded and unpacked in memory before dumping an image of it to disk. If your class was encrypted, I would agree with you... Your class would have to be decrypted before it could be put through the Java Class Loader and executed... BUT encryption is not the same thing as obsfucation. A class will execute, obsfucated or not... An obsfucated piece of code will run and maintain the same functionality as an unobsfucated piece of code... It has simply been stripped or transformed in a way that makes it more difficult for a human reader to understand. Simplest case: Your java virtual machine doesn't care if it is running methods with descriptive names like CalculateSerial or DisplayNagScreen. For all it cares, your code might as well have method names like Garbage1 and Garbage2. Therefore, the obsfucator can change CalculateSerial to Garbage1 and the JVM doesn't care. Only *you* will care when you go to decompile it. Same with the code flow transforms. The code still does the same thing, it is just uglier. Consider a nice piece of code with easy to understand high level control structures like if, else, and elseif statements. Now, transform all of those instructions to cmp, jmp combinations. You haven't changed the functionality, but you've taken it up a notch in complexity for the programmer to understand. Clearly, this would not deter an ASM programmer, but from the point of view of the average high level OOP programmer, converting their high level control directives to ASM would be a form of "obsfucation" Another concrete example of the concept of obsfucation would be self modifying code... The code runs, but it is a bitch to trace (for you )... The processor doesn't care if its running SMC or not.

Patching is probably the cleanest and easiest solution in this situation, especially since you're only changing a few bytes to remove a nag screen.

Cheers,
Clandestiny

alo Clandestiny

thx for the answer....


So the only way out is find the bad guy and patch it. I will use the "view java byte-code" which is build in DJ-java decompiler.

Wish me luck...

Chitech