Java代码，安全性

Question

I am creating a client program that talks to a server (which I programmed). I am making a little game for myself in which I roll a dice and the server does also. Whoever gets the higher numbers wins. However within my code, I send the server commands when the user presses a button, and then the server responds by sending back what it rolled, so it can be shown in the GUI window. However, I find this a very insecure method. For example, a person could just simply decompile the jar file, and make it so they always roll a 12. Since the only place that both rolls are together (the users and the servers) is the users screen, I have to evaluate the game from the client, obviously not very secure. I am trying to make my game more secure, and have found 2 options.

1. Obfuscators

   • Unless someone knows of a very easy one to use, I cannot figure out how to set any of them up, as they rarely come with a gui that I can easily "pop" my .jar file into

2. Binding to an .exe

   • I honestly dont know how secure this is. There are programs in which I can "bind" two things (mostly for making viruses which I am obviously not doing), into a single .exe file. I can bind my .jar into an .exe, but I still dont know if the .exe could be decompiled back into the .jar file and from there back into the .java code.

By the way, another security issue is that it connects to the server from my ip adress (which I do not want the client user to know about)

Answer 1

Never trust client input.

The only truly "secure" method is to have the server generate both its own roll and a roll for the client.

Of course, if the outcome of the comparison of the rolls has no impact beyond what the user sees (in other words, the client does not report back who won), then really, who cares? I could patch Solitaire to let me always win, but that's no fun.

Answer 2

If the code is on someone's computer, you should consider it compromised and exploited already. In the race between crackers and developers, the crackers always win because the crackers have everything they need. Jars can be (easily) decompiled and deobfuscated, .exes can be picked apart, and at extreme levels the OS can be modified to go behind your back - literally.

Instead, you should reconsider your architecture: do you really need the client to roll the dice? Could the server roll both?

Answer 3

Both obfuscation and compiling to a ".exe" can be defeated relatively easily. Hackers / crackers, and anti-virus security experts do this kind of thing every day.

Basically, you cannot trust any application that is running on any machine that could be controlled by someone you don't trust. In practice, this means anything that isn't in your (locked and firewalled) server room.

(Aside: even systems based on TPM are potentially vulnerable, since there have been successful attacks on TPM chips. And that wouldn't be practical anyway, since TPM is not available for securing application-level code. AFAIK, it is not even used at the OS level ... though I've heard that the next version of Windows is going to require hardware that is TPM encumbered.)