Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Protecting Java code, how?  (Read 3234 times)
0 Members and 1 Guest are viewing this topic.
Offline zappsweden

Junior Devvie




Java games rock!


« Posted 2007-06-11 12:22:16 »

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?

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #1 - Posted 2007-06-11 13:04:51 »

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.

Offline zappsweden

Junior Devvie




Java games rock!


« Reply #2 - Posted 2007-06-11 13:11:40 »

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?

http://www.javaworld.com/javaworld/javatips/jw-javatip22.html
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline appel

JGO Wizard


Medals: 68
Projects: 4


I always win!


« Reply #3 - Posted 2007-06-11 13:13:29 »

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 Smiley you wouldn't store anything sensitive in a html code!

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline ryanm

Senior Devvie


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #4 - Posted 2007-06-11 13:26:42 »

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?

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.
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #5 - Posted 2007-06-11 13:42:04 »

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.

弾幕 ☆ @mahonnaiseblog
Offline zappsweden

Junior Devvie




Java games rock!


« Reply #6 - Posted 2007-06-11 13:59:13 »

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.

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.
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 81
Projects: 15


★★★★★


« Reply #7 - Posted 2007-06-11 14:13:49 »

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.
Offline zappsweden

Junior Devvie




Java games rock!


« Reply #8 - Posted 2007-06-11 14:16:41 »

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?
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 81
Projects: 15


★★★★★


« Reply #9 - Posted 2007-06-11 14:19:37 »

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?

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #10 - Posted 2007-06-11 14:23:32 »

>[...]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. Smiley

弾幕 ☆ @mahonnaiseblog
Offline zappsweden

Junior Devvie




Java games rock!


« Reply #11 - Posted 2007-06-11 14:32:42 »

>[...]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. Smiley

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". Smiley
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #12 - Posted 2007-06-11 14:55:00 »

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 Smiley

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #13 - Posted 2007-06-11 15:03:47 »

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.

Offline broumbroum

Junior Devvie





« Reply #14 - Posted 2007-06-11 16:19:16 »

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? Cheesy

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline fletchergames

Senior Devvie





« Reply #15 - Posted 2007-06-11 16:22:59 »

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.
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.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #16 - Posted 2007-06-11 17:02:13 »

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? Cheesy
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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #17 - Posted 2007-06-11 18:31: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.

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.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (33 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (51 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (59 views)
2014-11-29 21:32:03

toopeicgaming1999 (123 views)
2014-11-26 15:22:04

toopeicgaming1999 (114 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!