Develop Reference

Decompiling a jar file and modifying the source to hack an application. How to prevent this? [duplicate]

How can I package my Java application into an executable jar that cannot be decompiled (for example , by Jadclipse)?

You can't. If the JRE can run it, an application can de-compile it.
The best you can hope for is to make it very hard to read (replace all symbols with combinations of 'l' and '1' and 'O' and '0', put in lots of useless code and so on). You'd be surprised how unreadable you can make code, even with a relatively dumb translation tool.
This is called obfuscation and, while not perfect, it's sometimes adequate.
Remember, you can't stop the determined hacker any more than the determined burglar. What you're trying to do is make things very hard for the casual attacker. When presented with the symbols O001l1ll10O, O001llll10O, OO01l1ll10O, O0Ol11ll10O and O001l1ll1OO, and code that doesn't seem to do anything useful, most people will just give up.

First you can't avoid people reverse engineering your code. The JVM bytecode has to be plain to be executed and there are several programs to reverse engineer it (same applies to .NET CLR). You can only make it more and more difficult to raise the barrier (i.e. cost) to see and understand your code.
Usual way is to obfuscate the source with some tool. Classes, methods and fields are renamed throughout the codebase, even with invalid identifiers if you choose to, making the code next to impossible to comprehend. I had good results with JODE in the past. After obfuscating use a decompiler to see what your code looks like...
Next to obfuscation you can encrypt your class files (all but a small starter class) with some method and use a custom class loader to decrypt them. Unfortunately the class loader class can't be encrypted itself, so people might figure out the decryption algorithm by reading the decompiled code of your class loader. But the window to attack your code got smaller. Again this does not prevent people from seeing your code, just makes it harder for the casual attacker.
You could also try to convert the Java application to some windows EXE which would hide the clue that it's Java at all (to some degree) or really compile into machine code, depending on your need of JVM features. (I did not try this.)

GCJ is a free tool that can compile to either bytecode or native code. Keeping in mind, that does sort of defeat the purpose of Java.

A little late I know, but the answer is no.
Even if you write in C and compile to native code, there are dissasemblers / debuggers which will allow people to step through your code. Granted - debugging optimized code without symbolic information is a pain - but it can be done, I've had to do it on occasion.
There are steps that you can take to make this harder - e.g. on windows you can call the IsDebuggerPresent API in a loop to see if somebody is debugging your process, and if yes and it is a release build - terminate the process. Of course a sufficiently determined attacker could intercept your call to IsDebuggerPresent and always return false.
There are a whole variety of techniques that have cropped up - people who want to protect something and people who are out to crack it wide open, it is a veritable arms race! Once you go down this path - you will have to constantly keep updating/upgrading your defenses, there is no stopping.

This not my practical solution but , here i think good collection or resource and tutorials for making it happen to highest level of satisfaction.
A suggestion from this website (oracle community)
(clean way), Obfuscate your code, there are many open source and free
obfuscator tools, here is a simple list of them : [Open source
obfuscators list] .
These tools make your code unreadable( though still you can decompile
it) by changing names. this is the most common way to protect your
code.
2.(Not so clean way) If you have a specific target platform (like windows) or you can have different versions for different platforms,
you can write a sophisticated part of your algorithms in a low level
language like C (which is very hard to decompile and understand) and
use it as a native library in you java application. it is not clean,
because many of us use java for it's cross-platform abilities, and
this method fades that ability.
and this one below a step by step follow :
ProtectYourJavaCode
Enjoy!
Keep your solutions added we need this more.

Easiest way to edit/modify compiled class file

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.

Is there a way to compile to hide the source code?

Using Play or Grails or any other JVM framework;
Is there a way (or what is the way) to full compile the generated war/jar files so that the source code can be hidden, without the possibility of decompiling?
Or even after compilation, is it possible to easily decompile and get strings and classes? e.g. db connection et al.
Thank you.

No, you cannot compile anything without the possibility of decompiling. That said, you can do some things to make the process more costly.
The real trick is to make the costs low to you and expensive to others. In short, expect to pay more in time / money / inconvenience and realize that you have just made the challenge harder, in one way (that possibly might become easy to circumvent). But, look on the bright side, the entire software industry has gotten along just fine without absolute protections against decompiling.
Sign and seal your JAR files. This prevents people from adding things to your JAR files and prevents people from replacing parts of your code (to get a better understanding of the operating program).
Consider a class / method name obfuscator. This will rename your classes and method names into an equivalent structure that contains small names like "a.a(..)" instead of "Client.connect(...)". This makes it harder for others to read your code (and others includes yourself in this case, so if you intend to debug, this increases your cost to support the code). Oh, and this breaks any reflection, so you must provide work-arounds and fixes for reflection.
If you provide any kind of decent logging, you also need to obfuscate the logging, otherwise one need only read the log messages emitted from a class to figure out that class "h" is the DatabaseConnection, class "k" is the "User" data object, etc.
Embedded strings in your classes can always be extracted. So, if you want to protect them, you must embed "scrambled" strings, and "descramble" them prior to use. Doing so has a CPU overhead, and as soon as the "descrambling" routing is known, the entire process can be circumvented.
Exotic solutions exist, like rewriting your code into equivalent code which performs similar operations. The problem is that for the end deliverable to be useful, it still must perform identically to the original, yet now to debug the output isn't even following the original code.
Often one wants to protect the ability to solve the problem, not really the source code. Keep this in mind, by delivering something that works, often copying the already-compiled elements is enough to breach the "this code is mine" mindset. If you really want control over you code, don't release it, set up a server and offer the software solution "as a service" on your own hardware.

What you looking for is called obfuscation. There are several popular byte code obfuscators for java.

Do a quick search for grails or groovy code obfuscators and it should generate a bunch of results. It's fairly easy to decompile afterwards if you know what you're doing. There's no foolproof way.

Is there any Java Source code obfuscator working on windows 7?

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.

Jar File - Prevent Access to Source Code

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.