I’ve read about code obfuscators but these seem insufficient to me. I’ve packaged my application as an exe for now, but I want users from other operating systems to be able to run the game. How much protection can I give my could in its .jar form?
.jar files offer no protection.
I’ve tooken someone else’s Runescape Private Server Client, Extracted the .jar files, than using ‘JAD’ you can DeCompile the .class files into readable/editable .java files.
So my options are obfuscate + encrypt strings or convert to each os specific executable?
If that’s the case, how can I convert the jar to a mac app? Can I do this from a windows environment?
I’ve never used a Obsfucator, and i’ve only seen a video on exporting to jars / .exe’s (using 3rd party libs).
Believe you can add Environments (Different Native O.S Library’s) in with your resources folder.
Believe making the Run time executable on what ever native O.S library’s you included (Mac, Windows).
You protect your code by running it on the server. You can’t prevent someone from looking at bytecode that you gave them.
There are some tricks to make the (current) decompilers spit out only bytecode.
As they run into problems decompiling the code propperly.
Works only for some parts of the classes. But is at least one way to obfuscate (vital) codeparts more.
In the end, only a server side implementation can prevent the code to be analysed.
If you want to prevent your Jars from being directly readable, you could encrypt all classes and write your own classloader for decryption.
But’s that’s only another small obstacle and a real hacker would just inject some code for writing down all decrypted classes…
My opinion about security of jar is that its too much hard work for very small benefit.
Maybe one can write a bytecode “nastyfier”. Such that the bytecode gets extra weired command paths, gotos etc
such that the VM can still execute it correctly, but the decompiler runs into issues understanding how to translate this back
into a propper .java source.
[quote]My opinion about security of jar is that its too much hard work for very small benefit.
[/quote]
The benfit is the following:
The smaller the potential userbase of the program is (small game), and the more hurdles to decompiling (such as security features) you provide, the
less likely it will be that a skilled hacker wants to invest the time to decompile and alter it. (be it for pirating or writing an unwanted modification)
… program security is a game of economics in the end
That’s what many obfuscators can do. But the question is, if the resulting weird control flow keeps the VM from proper optimization.
@Damocles - That’s completely unfounded - you might as well just say that having obfuscated colde is like a red rag to a bull and more likely to get hacked for the challenge.
Here’s food for thought: Revenge of the Titans source code has been available in its entirety - including the DRM, which is the coolest DRM ever and extensively explained - and can you guess how much we worry about people looking at all our precious source code?
Don’t waste your time!
Cas 
I second the “don’t bother” notion. If you want to prevent cheating, the go server side as it’s the only option. If you want to protect your code…don’t worry about it. The number of people that could actually use it in any real way AND actually would rip-off your code is too small to worry about. And chance are they won’t finish anything because their probably too busy looking for other code to rip-off. Spend your time doing something more productive…like making a working product.
I think it makes sense to run a simple obfuscator over your JAR (renaming methods and packages), to ‘protect’ yourself from your average script kiddie that would otherwise (accidently?) attack your server, with the aquired knowledge of the protocol.
In no way does this deter any competent developer, but it’s nice to rule out a group of known mallicious folks, by raising the bar a bit, a tiny bit.
It doesn’t half make debugging remote logs that bit harder as well though, and on balance, it is vastly more preferable to have super easy to read stacktraces than it is to deter a couple of script kiddies. IMHO.
Cas
You can set proguard to keep the correct function names in the stacktraces and still obfuscate the code. I do that and when decompiling my jars I see the obfuscated code while my stacktraces are clean.
No idea how it works though and I guess that the not so common script kiddie can use the stacktrace data to get the function names back
As Riven said though, it’s only to protect from the most basic script kiddies. My client/server communication is clear text anyway for a bit more experienced script kiddies 
Mike
Obfuscators ship with stacktrace transformers, that convert it right back to the original classnames / linenumbers.
You can even script it, to transform the serverside (logged) stacktraces before you even see them.
Yes, but… you know. Hassle. Customer sends you a stacktrace in email = instantly look at it, go to line in IDE. It’s all about time.
Cas
I have no experience with customer support, so I’ll take your word for it
(I usually send logs/stacktraces to the server before the user has a chance to mail them to me)