Java's Security as a whole

Miscellaneous Topics
#1

Hi,

I have been recently investigating the fact that it appears to be quite easy to decompile .class files to attain source code. This scares me! So I have done a bit more research to find out some solutions to stop this.

1.) Encrypt the byte code and use a different class loader.
This is flawed and will not work. This article is great: http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html
2.) Use an obfuscation tool.
Just makes it harder…
3.) I have heard of a way to ‘lock’ the jar so that tools like winrar cannot open it. I do not know anything about that.

Those are the ones that I currently know of to protect the source code. It doesn’t seem to hopeful to be honest. I find it very saddening that this is a possibility with java.

Does anyone else have any ways that they protect themselves against potential source code thefts?

I am going to post up some more information as I stumble across this. I feel this is an important aspect to java.

Thanks!
James

#2

you can do that with any language :o
just live with it and get on with releasing your games.

anything that is deployed on clientside is crackable. class files, exe files, hd-dvd, fairtunes, dvd, ps2, xbox etc etc.

#3

Also be aware James that your source code is worthless to anyone else, so don’t worry about people getting rich off of your hard work.

Cas :slight_smile:

#4

It’s the wrong label btw. This stuff isn’t related to security.

If you’re afraid that someone steals some of your rocket science tech… don’t release it. Well, for the most part your code won’t be all that interesting anyways. It’s glue between libraries to make this specific application. Only a tiny fraction of that glue stuff is reusable… after heavy refactoring that is.

All the interesting things one might want to steal are open source anyways. :slight_smile:

#5

Thanks for the replies guys.

I realize that anything is crackable. It only takes time. What just bothers me is the ease of it. I am under the assumption that it is more difficult to crack, say, an exe file that has been compiled in C++ than a java jar or some class files. Perhaps I am just being ignorant and I have just not stumbled upon a series of decompilers for exe files. I have not looked. I discovered this event last night shortly before I was heading to bed so I did not have time to look around for that.

As my game will be online, I can spend some time to make the client as light as possible such that all the important stuff is located on the server. I am just paranoid. Which can be good and which can be bad :slight_smile:

In terms of the name of this thread, I also realize that there is a subset of Java called Java Security (I work with Java Security in Industry). Perhaps I should of named it something different but I am talking about Java’s Security not Java Security :stuck_out_tongue: :stuck_out_tongue: :stuck_out_tongue: :stuck_out_tongue: ::tease::

An another note, has anyone used any code obfuscator’s for Java? I am inclined to at least spend a little bit more effort to ensure it is not AS easy.

#6

I am under the assumption that it is more difficult to crack, say, an exe file that has been compiled in C++ than a
java jar or some class files.

Well, that assumption is wrong. Removing the average CD check takes a few minutes (crack generation included). You also don’t need programming skills and the required knowledge fits on a postcard. Removing an equally simple protection in Java requires way more knowledge and time.

Btw I didn’t mean java.security. I meant those things which make Java secure. Eg class loaders, bounding checks, immutable strings… that kind of thing. That’s what comes to mind if you use a title like “Java’s security as a whole”.

#7

I was thinking more than removing a CD crack. Those are relativity easy to do. I googled for exe decompilers and received a large amount of results, but I do not know how reliable they are to use. Do you happen to know? Maybe I was just ignorant and they say ignorant is bliss!

#8

You don’t just decompile .exe’s. You would actually debug them; see what many protection schemes do is encrypt the code and load it into ram. But no matter what you do your assembler code is always going to be loaded into ram so no, there is nothing you can do in any language.

And I can tell you this as a person who has been handed the debugging tools used to crack programs. Exe’s are difficult to decompile properly since anything can be data or code, but if you encrypted java byte code then you are in the same boat.

#9

[quote]An another note, has anyone used any code obfuscator’s for Java?
[/quote]
Try ProGuard (free, open source, has an Ant task).

#10

Thanks. I tried retroguard and got that going. I’ll check out proguard.

I’m in the process of decoupling my server and client code from the networking framework I developed. This makes me feel better inside knowing I won’t have to put the server code (and most of the processing) in a risker situation.

I appreciate the replies I have received on this topic.

#11

Whatever you do, don’t rely solely (or heavily) on this type of protection for anything where if someone were to manage to decompile the code that they would not be able to suddenly destroy your entire system, or steal other players money. Protection is a deterrent for amateurs, and a filter for the skilled.

#12

Is this realistic to build a program that will re-build itself the first time it is launched? That is, you will have securized the java code by encoding the sources then once an appropriate app. launcher program executed you’ll be able to get the sources decode and built at Runtime. ???

[ make your java program-builder-launcher (PBL)] -----> give a zip file with the sources tree and a build.xml -----> [ launch your PBL with the zip file ] —> decode and build —> [ launch the created .jar from a temp/ securized place ] <= The app is almost securized!!!

#13

Correct! I have a plan that I developed in the past day after learning of this for Java.

1.) Obfuscate my code that will be released.
2.) Change from a thick to a very thin client. Think like a MUD. This is turning out to be a project in its own. Even though it’ll set me back for a week or so, the benefits out weigh the time it’ll take to do.
3.) Add in server side functionality to ensure the data that it is receiving is ‘secure’. One feature that I am going to do is if a connection sends X bogus commands in a row, they will be logged (IP address, connection times, what they tried to send, etc, and disconnected.).
4.) A checksum verifier that will be execute upon connection to the server.

I know that no matter what I do (besides not releasing) I cannot truly secure my code (I also realize my code isn’t all that interesting, but there is no reason not to take the measures). The steps above will just make it harder to get ahold of things. Even if they do decompile the client, it will be utterly useless. I suppose I’ll talk a bit more about my plan. I am going to pretty much make ‘skeleton’ classes in place of the real ones on the server. They will not have any execution code, nor will they have a complex structure (variables, polymorphism, etc). They will be very simple and straight forward. I realize with what I am trying to do, I can merely sending data to the client. The client just needs a good way to store it. So, in a way, this will help me actually have a more efficient program because I am not transmitting useless data to the server.

Well, I’ve rambled too much so I will not hit the post button!

#14

You seem fairly rational overall, not just a paranoid ranting about someone “stealing your code”.
– SO what specifically are you concerned that bad guys will do if they can see too much of your
client?

#15

Thanks for the kind words :slight_smile:

My plan was to have a thick client so I can offload some of the processing from the server. I have limited funds and I’m not sure how good of a processor I have. So they would be able to see some pretty important code that was related to the game (server protocols, how the data was arranged specifically). Even if they do not steal my code, it could give them a potential to disrupt the game. I wanted to avoid that situation.

I was also thinking of several ways to stem the bogus command sending. One other thing was having the server send the client a special code or something that the client could process and then send back with every command. This would allow the server to ensure the data is correct. We can make the code linked to the current account. It could then change every say, 10 seconds. This would make it so the server and client will always be in a secure fashion. Of course, the hacker could intercept the commands and blah blah blah etc. It is just another wall to climb :slight_smile:

#16

In case you haven’t thought about it already, here are two things to keep in mind: memory-editing tools and pixel-clicking bots. I had to deal with both of those for a simple game with high scores.

The memory-editing tools (like tsearch and Cheat Engine) allowed anyone to give themselves any score they wanted, usually within 5 minutes or so, no decompiling necessary. I fixed this problem by keeping certain variables (score, level, etc) encrypted in memory.

The pixel-clicking bots are a whole different problem. I didn’t even bother trying to detect bots because, for one, it would be difficult. Second, as far as I could tell, there was only one person who created a bot and he was actually a kind person who stopped using it. Of course, some game designs are more prone to this than others.

#17

If your game is a shooter or mmog, where the client has information that the user is not supposed
to have access to, you ultimately cannot win. You can only delay and make it harder. You should
install tripwires based on the idea that hackers will try easy things first, and if they don’t seem to
raise any alarm bells, might be happy with their work. One of my favorite tricks is to degrade, but
not shutdown, clients that trip your alarms. They’ll get frustrated and go home - probably badmouthing
your software all the way.

#18

You never want people badmouthing your software.

Cas :slight_smile:

#19

Unless they have the inability to speak, then you have encouraged a miracle 8)

#20

I was very careful to ensure that the server only was the sender of important data. It never ever takes data from the player and uses that to update itself. This wasn’t the case with the thick client and is still with the thin client. The thin client now is purely a storage mechanism for the player. Though, I did not think of the pixel-clicking bots. Do you happen to have some sort of additional information about this handy? I’m going to google it and see what I can come up with.

That’s a great idea and I am going to do something like that in order to make it so they are more apt to get discouraged.

This thread has a lot of good information in it! Keep it coming!