My main problem is that i have some class files from a game where i wan't to edit/modify parts of it
What would be the easiest way to achieve this ?
Decompiling the whole code and recompiling is not an option unless you have some decompiler that doesn't cause errors in the source code, as i do not wish to spend time fixing them.
Best regards
A solution could be the use of bytecode manipulators like ASM or BCEL. They both provide an API to load a class file, change part of it and save it. ASM has the advantage to be able to do this during runtime.
You can also use the Krakatau disassembler/assembler I wrote. The disassembler turns a class file into a human readable (well readable if you understand bytecode anyway) format, which you can then edit and reassemble. This is useful if you want to view and edit the classfiles by hand, where writing a bunch of library calls and then compiling and running a program just to use ASM or BCEL is rather unwieldy.
Krakatau also has a decompiler specifically designed to handle obfuscated classes, so it may be able to produce valid source code even when no other decompiler can. Of course if the class is obfuscated, the generated source will probably still be unreadable.
Related
I am developing an application that analyzes Java applications (Windup).
I'd like to be able to recognize programatically if a .class file was generated instead of written by a programmer and compiled.
As a human, I can tell because the decompiled code doesn't make much sense. It looks a bit like some kind of java-ish mix of C.
I could somehow implement recognizing the resulting decompiled code.
However, decompilation takes time, I'd like to skip decompiling for generated classes.
For more information on what is a generated .class file, see here.
Is there a way to recognize generated .class just from headers? Or perhaps some specific bytecode sequence?
As mentioned, any legal class file starts with the magic numbers 0xCAFEBABE as it is specified by the JVMS §4.1. The simple fact that a file starts with this magic number does however not guarantee you that the file represents a compiled Java class, as anybody is able to create such a file.
Reading between the lines of your question, I assume that you want to find out if a class was generated by javac or another compiler / runtime code generator. This is not possible to determine as anybody can imitate javac as close as possible. As a matter of fact, many runtime code generators try to imitate the javac compiler as closely as possible as it can lead to performance improvements as the JIT-compiler recognizes some patterns that are typically used by javac.
If the code that you want to analyze derives a lot from "usual Java code", you can look for byte code patterns that are not representable in the Java language. This way, you can prove that a class was not generated by javac but you cannot generally proof that it was generated by it.
Java Classfiles always begin with the magic bytes CAFEBABE. If you want to recognize classfiles, that's the best way to do it.
If that's not what you want, you'll have to clarify the question.
I wanted to know which of the below solutions is better:
I want to modify some .class files and as I have realized there is two ways to do that:
Decomplile the .class file, modify it and finally compile it again. -
Directly modify it with a hex editor.
Thanks
Of those two bad choices, decompiling, modifying and recompiling is better. Changing anything in binary is likely to change offsets of other stuff and far more error prone.
.class files don't have any checksums or error checking as far as I know, although the bytecode does need to be validated. Even so, output from a compiler is safer.
option #3 - if youre going to be messing around with bytecode, the least you could do is use some library designed for it to avoid re-inventing the wheel. see asm for example
It turned out that a JSP source is available for the classes. So a much better approach is to
make the modification in the JSP source and then use a JSP compiler (like this one).
If you don't have the source code, and you are sure that you want to modify .class files, I recomment using Javassist library (for byte-code modification) in combination with Java Decomiler (to inspect the source).
I am for option #1. Use JAD or some other decompiler to make .java, make changes, compile and replace the old .class with the new version.
No solution which involves messing around with bytecode files is a good solution.
The good solutions are:
Get hold of the source code and make the changes you need to in the source code. Then recompile, run the unit tests, build a WAR, redeploy, etcetera.
If you can't get the source code, get the people who wrote the source code to fix the problem.
If you can't get them to fix the problem for free, pay them.
If they won't fix it even if you pay them ... ditch the product, and look for an alternative.
Only consider the bad solutions of decompiling and/or bytecode engineering if none of the above is a viable option. And even then, you need to start planning a way to get yourself out of the whole you are currently in. 'Cos it will only get deeper with the bad solutions.
I can't honestly say which is the best of the bad solutions. It depends on:
the nature of the code,
the nature of the changes that you have to make to the code, and
your skills at reverse engineering bytecodes.
I have used cavaj, JAD and JD-GUI and they gave quite the same decompiled results. But JD-GUI had better results in comparison to the other two and therefore was a better choice for me. I wanted to share this in case anyone was looking for a decompiler to choose.
I have created a plugin project in Eclipse, distributed as a jar.
The user can take this jar and decompile it using JAD.
Is there any way so that i can stop the decompilation of a jar file?
Or, at least, to hide my source code from the user?
The best way to stop your jar from being decompiled is to give users no reason to want to. Obfuscation is just a bandaid. In fact, some people will probably reverse it just for the challenge if it's famous enough.
If you don't insert your source code in the jar, your sourcecode isn't what is decompiled by a decompiler, but something similar.
However, you may use an obfuscator to make code decompilation produce very ugly code like Proguard.
ProGuard is a free Java class file shrinker, optimizer, obfuscator,
and preverifier. It detects and removes unused classes, fields,
methods, and attributes. It optimizes bytecode and removes unused
instructions. It renames the remaining classes, fields, and methods
using short meaningless names. Finally, it preverifies the processed
code for Java 6 or for Java Micro Edition.
Search for other products with the term obfuscator.
I require a source code obfuscator for Java that is working on windows 7.
Because I plan to release a closed source library in GWT it really has to be an obfuscator that outputs source and does not process ready to use .class files. The result files need to be .java files.
The only obfuscator that is Java-to-Java instead of .class as a result is Java Source Code Obfuscator from Semantic Design.
But sadly it seems this one does not work on Windows 7.
What about compile it into class files with all the debugging symbols stripped and then run a decompiler on the resulting class files? Example decompiler
Despite the existence of some quality work out there, I assure you Java obfuscation will NOT stop someone who is determined to decompile your code. Understand that all you are buying is a bit of time. If they have your class files in hand and choose to decompile them, it won't take long before they have your source code.
If you don't trust your customer, don't give them the class files. Come up with a different solution. More and more companies are moving to services as a way to keep their source code in house and still make their monies.
Most Java source codes are self obfuscated, nobody can understand them.
There are no effective obfuscators, the silly things they do do not deter anyone determined to steal your code. This is a false market based on false fears. If the threats were real, there will be de-obfuscators, selling for much higher price than obfuscators.
If you really want to obfuscate your code, don't use meaningless symbols, use misleading symbols.
I want to hand over a small Java app as a runnable jar but I do not want anybody to have access to my source code. Am I right in presuming that there is no source code (.java files) included with a jar file?
User269799
Assuming you don't put the java files in the jar file, they're not going to magically appear :) You can include anything you like in the jar file of course. You can list the contents to check:
jar tvf foo.jar
Note that Java can be decompiled pretty easily though - so while any recipients wouldn't have access to your actual source code with comments etc, they could see your logic pretty clearly. You may want to use an obfuscator to help protect your IP. Personally I try to avoid obfuscators - given how hard most of us find to maintain code when we do have the real source with commments and tests, imagine how hard it is when you don't have those things :) It's your call though. Just make sure you test obfuscated code thoroughly - there can be subtle issues, particularly if you use reflection.
If a computer can run it, a human can reverse engineer it, and it is not particularly hard for Java.
So technical protection simply won't work. You need legal protection in form of a binding contract or similar. You may even put your works under the GPL except for those paying you, which is sufficient for most businesses to avoid stealing your work.
What situation exactly do you want to avoid?
Jar files usually only include .class files, which are java bytecode files, as well as resources. However, to be a little more secure about your code, you'll want to turn off debugging information and if you really want to be secure, run it through an obfuscator.
Edit: berry120's comment is right - they can contain source files, but usually they do not. I just want to clarify for any future readers of this. It depends on the settings of the tool you use to generate the jar.
You are right, there is no source code in the jar (unless you configure your build system to specifically put it in there). But you are always at the risk you code gets decompiled from the bytecode. An obfuscater might help here.
Yes. Usually, jars contain only byte-compiled .class files. That said, they can contain source code as well—it depends on what you (or your tools, respectively) put into them.
Note, however, that decompilation works pretty well on .class files, so don't make anything security-related rely on code obfuscation techniques such as this one.
Normally there isn't but you can use the jar -tvf <filename> command to check it.
However I have to warn you that it's extremely easy to decompile most .class files into reasonably readable java source code.
To avoid this, you'll have to use an obfuscator, but that needs some extra effort on your behalf. (E.g. RetroGuard.)
Having said that, ask yourself the question: "Is my code really that valuable or special that I need to do all this?" Usually the answer is no, most of the code we write is nothing special.
You are are correct, however the .class files can easily be disassembled to java code, and its pretty accurate in most cases.
If you really need it to be properly secure then you'll need to obfuscate.
It will depend on the way you generated that .jar, Eclipse does have an option to include .java files on the .jar but it is disabled by default and you have to activate it if wanted.
Jar files might contain the source (you can choose whether to include it or not) so not including the source specifically isn't an issue. What you need to be aware of though is people potentially reverse engineering the class files that will be in the jar file.
You can get around this usng an obfuscator such as yGuard which easily hooks in as an ant task, but as others have said, is your code really that important that no-one else sees it?
The .jar file does not include source code, only the bytecode (.class). But as the byte code is machine independent, it can be decompiled very easily. There is no way to prevent others to access your source code.