Protecting Java code, how?

Newbie & Debugging Questions
#1

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?

#2

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.

#3

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?

http://www.javaworld.com/javaworld/javatips/jw-javatip22.html

#4

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 :slight_smile: you wouldn’t store anything sensitive in a html code!

#5

Yes. Quite apart from decompiling being a bit of a pain in the bum, I would be very surprised if Microsoft licences allowed it.

As appel says, 99% of your users will have no interest in decompiling, 99% of the remainder won’t know how, the remaining .01% will crack whatever protection scheme you have no matter what you do.

If you are absolutely convinced of the need to keep your code secret and secure, your only choice is not to give it to anyone else.

#6

Cracking a Java app is more work then cracking a native one. Disabling usual CD checks takes average non-programmer Joe 2 minutes. Crack generation included. The required knowledge fits on a postcard.

Even without any obfuscation Java is better “protected”, because it requires more knowledge and time.

#7

Note that I do not mean copy protection or piracy but rather protecting from ppl stealing code or entire classes using it as their own source code for making games.

#8

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.

#9

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?

#10

well technically speaking yes, easier than if they where all bundled in one package, especially if the packages are nicely named explaining what classes each package contains.

#11

[…]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. :slight_smile:

#12

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”. :slight_smile:

#13

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 :slight_smile:

#14

Another thought is this: Open source code is easy to protect, because it’s out in the open with a well-known license.
If people do steal it, it’s far more easy to prove they stole it.

#15

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.

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())

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? :smiley:

#16

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.

#17

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.

#18

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.