EDIT:I was not clear enough, I did not mean protection from hack+piracy but rather protection from others hacking and ripping away copyrighted well structured code that they can use as their own source code when making games.

I heard that Java code is easy to decompile, can someone with knowledge in these kind of things explain that abit? I am wondering if it is possible to protect my code from being reverse compiled or not. I use obfuscator but is that really enough?

Was not Microsoft sued for not sharing their source code to other developers making integration to Windows difficult for the competing businesses? But windows is an Operating System and built from C++ so the lower the leve the easier to protect a code? It is obviously not so easy to decompile everything else they would have already done that with windows? Can someone compare the languages and compare other factors that decide this?

An obfuscator can certainly do the trick as it produces code that, if you decompile it, can't be compiled again.

However, an obfuscator can also introduce problems. I've tried it some time ago (not for protecting my code, but to make the jar smaller), and at that point the obfuscated code wouldn't run on Java6 anymore (that issue was fixed later with a new release of the obfuscator).

But what exactly is your reason for protecting your code?It's true that decompiling java is easier than with C, but with C it's still perfectly possible. In fact all binaries can be hacked and it's also not too difficult, which explains why almost all programs' copy protection is cracked even before they appear on the shelves.If people want to crack your software, they will, and no obfuscator will really protect you from that.

An obfuscator can certainly do the trick as it produces code that, if you decompile it, can't be compiled again.

However, an obfuscator can also introduce problems. I've tried it some time ago (not for protecting my code, but to make the jar smaller), and at that point the obfuscated code wouldn't run on Java6 anymore (that issue was fixed later with a new release of the obfuscator).

But what exactly is your reason for protecting your code?It's true that decompiling java is easier than with C, but with C it's still perfectly possible. In fact all binaries can be hacked and it's also not too difficult, which explains why almost all programs' copy protection is cracked even before they appear on the shelves.If people want to crack your software, they will, and no obfuscator will really protect you from that.

So, why did they sue Microsoft for not showing the source code for Windows if it is that easy? Did it have something to do with themselves being afraid being sued if they went into Microsoft code? I searched on google today and found a software named Mocha that could decompile Java code and then you would be able to compile it again. On the same webpage there was a software that would prevent the Mocha from doing it by using this so called Crema software. Is that just waste of time because I recon there are certain ways of hacking that as well?

You can never _really_ protect any code. Even C++ written applications can be decompiled on a assembly level.

The question is, how safe is safe enough?

In short, there is no real solution. All you can do is obfuscate your code so that most will shy away from figuring out how your application works (99% of the people), but for those who don't shy away they will do everything to figure it out. Just don't leave anything sensitive in your code, such as passwords, keys etc. Best to think of your obfuscated class code as a viewable html code anyone can see you wouldn't store anything sensitive in a html code!

obfuscating your code so that all variable names and class names are obfuscated and put into a single package/directory will pretty much prevent your code being stolen, even if the classes are decompiled they will be completely uncommented and variable names unmeaningful, the amount of effort it would take to find, understand and make the code usable would simply not make sense and it would be easier to write your own code from scratch. Besides theres also the legal deterrent if they are caught stealing your code.

obfuscating your code so that all variable names and class names are obfuscated and put into a single package/directory will pretty much prevent your code being stolen, even if the classes are decompiled they will be completely uncommented and variables names unmeaningful, the amount of effort it would take to find, understand, to make the code usable would simply not make sense and it would be easier to write your own code from scratch. Besides theres also the legal deterrent if they are caught stealing your code.

Ok, but if the code is like 200 classes spread out on 10 packages would that mean it was much easier for someone to pick out certain classes?

>[...]rather protecting from ppl stealing code or entire classes using it as their own source code for making games.

Oh that... well, that won't happen. Most people don't even use stuff from non-obfuscated commented code, because it relies to much on other classes. And even if someone would use some of my utility methods... so what? All my reusable stuff will be opensource anyways.

>[...]rather protecting from ppl stealing code or entire classes using it as their own source code for making games.

Oh that... well, that won't happen. Most people don't even use stuff from non-obfuscated commented code, because it relies to much on other classes. And even if someone would use some of my utility methods... so what? All my reusable stuff will be opensource anyways.

Ok, but I am talking about software being sold online and retail perhaps on several platforms so that is why I need to worry about ppl "steal and code reuse".

Is your code doing really something so utterly new and groundbreaking that people will want to steal it?If it isn't (which is probably the case, no offense intended), smart developers will either easily make the same thing (and read up on information available on the net), or reuse well documented open source code instead of decompiling your code, trying to understand it, and trying to fit it in their own programs.

But if obfuscating will make you feel safer, by all means go ahead and do it

I found a way to protect applications with Key Files I/O. Say you have an xml file to use every time you launch the program, and suppose you acquire it from your resources folder. The solution is to make a serialized zipped file from that xml file and to put it in the resources in place of that original unserialized ("unencoded") xml file. Then protect your File IO with the reverse read Key File IO process and use the file.With that thing, any cracker would have to find the serialize Key File IO method to use a different xml file.

[move]Scheme : SomeKeyFile_serialize() -> encode with serialize process -> put in the resources folder, SomeKeyFile_isSealed() -> you can use it after unserialize SomeKeyFile_unserialize() (<=> keep a back-copy of the original SomeKeyFile_backup())[/move]

Further suppose that this Key XML File IO be the ant-building xml file, if you were able to eventually compile your app with an appropriate installer app, it would be possible to protect that build process with such Key File I/O.

Let's see the Ant I've published in the Java Web Start pool below, it may be more understandable.

I found a way to protect applications with Key Files I/O. Say you have an xml file to use every time you launch the program, and suppose you acquire it from your resources folder. The solution is to make a serialized zipped file from that xml file and to put it in the resources in place of that original unserialized ("unencoded") xml file. Then protect your File IO with the reverse read Key File IO process and use the file.With that thing, any cracker would have to find the serialize Key File IO method to use a different xml file.

[move]Scheme : SomeKeyFile_serialize() -> encode with serialize process -> put in the resources folder, SomeKeyFile_isSealed() -> you can use it after unserialize SomeKeyFile_unserialize() (<=> keep a back-copy of the original SomeKeyFile_backup())[/move]

Further suppose that this Key XML File IO be the ant-building xml file, if you were able to eventually compile your app with an appropriate installer app, it would be possible to protect that build process with such Key File I/O.

Let's see the Ant I've published in the Java Web Start pool below, it may be more understandable.

What's yours?

Or they could just change your app to skip the encrypted file IO and just open a new xml file direct. Trivially easy to circumvent if you know what you're doing.

It might be easier to prove they stole it, but making your code open source is practically asking them to steal it in the first place.

Well, if someone wants to steal code, he'll do it anyway. This way, at least you'll be able to make your case more clear. Anyway, my comment was just food for thought, I'm not suggesting everybody should make their game open source.

Other than that, it seems to me that generally good content and gameplay mechanics make a good game, usually not because the code hides something so utterly groundbraking that the only way to compete is to disassemble it.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org