Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (492)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
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  
  Prevent jar from being easily reverse engineered.  (Read 3612 times)
0 Members and 1 Guest are viewing this topic.
Offline ChexWithRaisins

Senior Newbie


Projects: 1


SphereCCG.com


« Posted 2012-03-28 00:39:36 »

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?

Help Beta test SphereCCG!
Offline GabrielBailey74
« Reply #1 - Posted 2012-03-28 00:43:40 »

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

Offline ChexWithRaisins

Senior Newbie


Projects: 1


SphereCCG.com


« Reply #2 - Posted 2012-03-28 00:55:38 »

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?

Help Beta test SphereCCG!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline GabrielBailey74
« Reply #3 - Posted 2012-03-28 01:05:11 »

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

Offline sproingie

JGO Kernel


Medals: 202



« Reply #4 - Posted 2012-03-28 03:27:58 »

You protect your code by running it on the server.  You can't prevent someone from looking at bytecode that you gave them.
Offline Damocles
« Reply #5 - Posted 2012-03-28 03:55:24 »

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.

Offline 65K
« Reply #6 - Posted 2012-03-28 07:23:37 »

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

Offline Fokusas

Senior Member


Medals: 3
Projects: 1



« Reply #7 - Posted 2012-03-28 07:26:18 »

My opinion about security of jar is that its too much hard work for very small benefit.
Offline Damocles
« Reply #8 - Posted 2012-03-28 07:28:11 »

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.

Offline Damocles
« Reply #9 - Posted 2012-03-28 07:33:12 »

Quote
My opinion about security of jar is that its too much hard work for very small benefit.

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

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline 65K
« Reply #10 - Posted 2012-03-28 07:39:01 »

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.
That's what many obfuscators can do. But the question is, if the resulting weird control flow keeps the VM from proper optimization.

Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2012-03-28 07:40:46 »

@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 Smiley

Offline Roquen
« Reply #12 - Posted 2012-03-28 09:23:58 »

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

JGO Overlord


Medals: 784
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #13 - Posted 2012-03-28 10:09:57 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2012-03-28 10:41:57 »

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 Smiley

Offline Mike

JGO Wizard


Medals: 74
Projects: 1
Exp: 6 years


Java guru wanabee


« Reply #15 - Posted 2012-03-28 11:03:22 »

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 Smiley

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 Wink

Mike

My current game, Minecraft meets Farmville and goes online Smiley
State of Fortune | Discussion thread @ JGO
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 784
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #16 - Posted 2012-03-28 12:13:02 »

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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2012-03-28 12:51:24 »

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 Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 784
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #18 - Posted 2012-03-28 12:53:57 »

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.
I have no experience with customer support, so I'll take your word for it Smiley

(I usually send logs/stacktraces to the server before the user has a chance to mail them to me)

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
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.

Nickropheliac (15 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (33 views)
2014-08-22 19:31:30

atombrot (42 views)
2014-08-19 09:29:53

Tekkerue (41 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (26 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
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

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!