Secure highscore submission over HTTP

Newbie & Debugging Questions
#1

Hi all,

I’m new to this forum. It’s great! (Well, so far I’ve mostly “used” the Showcase forum to find amuzing games to play:))

So here I have a problem, I would like your input on.

The setup:

A web server with PHP and a mysql database is used to collect player scores. Whenever a player has completed a game/level, the score is submitted to the server.

The problem:

Somewhat needy players are able to decompile the game and see what and how data is sent. Ie. http://blah.blah?score=123&player=JohnDoe. The players are then able to setup their own script that submits a score on a regular basis.

The attempted solution:

Add some checksum, ie. in the client do a MD5(score + “secret passphrase” + playername) and submit that as well: http://blah.blah?score=123&player=JohnDoe&checksum=14FSJHGFD45SA32lsGF2464GFD

  • but that obviously just makes it slightly more difficult. One could make a “crazy checksum” with variables spread across all of the client, but it just takes a slightly more determined “hacker” to figure it out.

I’ve previously read suggestions like “do a replay of the game on the server, ie. submit all user actions” but that’s also quite easy to figure out for a determined person.

So, how do you do it? Is it possible to achieve “good enough” security by using an obfuscator in Java? Switching to HTTPS is not a solution, as far as I can tell.

Any input would be greatly appreciated. I imagine it MUST be possible to avoid the decompilation somehow in Java. In Flash at least, the conclusion to this problem is sad: http://stackoverflow.com/questions/73947/what-is-the-best-way-to-stop-people-hacking-the-php-based-highscore-table-of-a-f

I hope for some good suggestions!

Best regards and thanks in advance,

adadad

#2

No such thing as clientside security. You can only waste your time at raising the bar.

#3

I once thought that this would solve it for some games:

Edit: I did not read your post completely. You have already suggested this but the person really needs to be determined to make a perfect run.

  • Record every input data so you can make a replay of the run
  • Append the input to the highscore
  • Verify the highscore by running the input data through the same version of the game as the player used
    • Input data that are “to much similar” to previously recorded input data are considered cheating

Problems:

  • Can be very expensive. But can for example be applied for position 1,2 and 3 only which helps a lot.
  • Need to make sure that the floating point operations are the same. Strict math perhaps? Fixed point math perhaps?
  • Still possible to make extremely good highscores by running the game several times with different inputs such as in those machine speed runs. But it is more difficult since you check that the input are “different enough” than previous inputs.

For some games this might be feasable if I haven’t missed any other problems.

#4

IMHO if your game gets good enough to be spammed in this way then you could afford to hire experts!
Order of play;

  1. Write a really good game that becomes massively popular.
  2. Deal with spammers.
#5

Riven is dead right. Even with proguard and things this only makes it a little tiny bit harder for anyone with half a clue (byte code is not hard to “read” in a disassembler). You can’t prevent decompilation in any programing language. If a computer can execute it, a human can “read” it and understand it. It is quite easy in C/C++ too. x86 assembly is not that hard to understand.

Even worse you are talking about “hidden” network protocol. They could just use tcpdump and work out whats sent that way, and then write their own spambot in C if they want.

They have the code, if you have encryption, they also have the keys. It can be cracked and generally quite easily. There is a reason, despite after spending wads of cash commercial games are cracked in a few days.

So why bother with proguard? I do it for space and speed–it doesn’t make that much difference with speed. But it makes the jars a lot smaller.

So how do you do “secure” high scores? Well the only way i can think of is clients play the game on a server. A server submits the scores, and you run the server. Clients can still cheat however, ie aim bots, map hacks etc.

#6

There’s no way to be completely secure - just imagine your needy clients write their own program
that does nothing but spoof your server. If it’s sufficiently good, there’s no way you can tell.

However, you can make it very difficult by variations on the MD5 checksum you proposed. For example,
if your server generates a stream of random numbers used as keys for games, and gives each game
a unique key. And periodically change some hash function, requiring them to re-reverse engineer your
code.

#7

you should give a little more details on the kind of game you are talking about, you wont be able to make an unbreakable one as long as the game is fully running client side but depending on the game you can sliglty increase its security.

An example for a car game :
you send time when player pass the start line
you send time for each check point
you send time when player pass the end line

=> server side you verify the coherence of the data (for exemple : minimum time before each check point for a given race) and compute high score
=> you only authorize higscore submission for same account every “n” minutes

#8

hey there is no such thing as client security. hmmm really?

what about sending a challenging compiled class server to client. Client has no way to know what this class does. Client has to run the class or challenge is failed.

the class (spy, crack detector or whatever) among other things validate the client setup (MD5 for example on the jar + list of running processes), writes result in a string and encodes it with a public key. send result back to server. Server decrypts with its private key and interpret string. Has client succeeded the security challenge? It is the server to decide.

challenger class byte code is time dependant, so a hacker cannot be sure of its content in the future.

#9

I don’t like this idea from a security point of view. The attacker can still decompile and read your code and watch the network. Now he/she can spoof the server and get clients to run any code on their machines.

Really its not hard to do. Try it. Even obfuscated code doesn’t take long to find the important checks.

#10

Run an unhacked client in addition to the hacked client. Pass the security challenge class to the unhacked client, intercept the result and pass it back to the server from the hacked client.

There is no such thing as clientside security.

#11

what if security challenge class checks for duplicate hacked client. Hack client would have to masquerade as something else in the process list. And of course you would need a security challenge class for each Operating System. Of course with Java, everything runs as java.exe so that’s a bugger.
But the idea is highscore cannot be sent if “unacceptable process is running on”

Besides the above you say does not work. I beg to differ. the scc goes to the unhacked client. so what? result is encrypted with public key AFTER the unhacked client has been identified. THe hacked client is totally unable to modify the result content. It is also unable to intercept, mainly because the content is not created if everything is not spotlessly hackerfree. let me remind you the scc is time dependant so it changes automatically and constantly.

the difficulty is how does the scc tell no hacked client is running.

i’m sure following this idea you can provide practically reliable client side security. In theory though we agree. there is no security at all. neither server side.

#12

no I wont agree :slight_smile: server side security problematic is completly different than client side, you can theorically (and practically) get unbreakable server security, you cannot client side, think of how much client software are hacked in comparaison of server, in certain case server may be breaked but it is a completly different process and far easier to secure

#13

wrong. someone just need to know learn you server password and id.

so 100% security does not exists. It is more philosophical than practical. But yes it is easier to secure server side. I never said the contrary.

and I stand by my genius. you can have a reliable hacker free highscore delivery system. You just need to get the server involved with a dynamic security challenge. And tell your user this: if you want to record your score, your processes will be spied upon. (therefore it won’t be cross platform)

#14
[quote="Mordan,post:13,topic:35832"] your processes will be spied upon. (therefore it won't be cross platform) [/quote] 1) How does your hack-checking code see what other processes are running? 2) How do you determine if a given process is forbidden
#15

I never said it was easy.

#1
long time ago, I have done a prototype on Windows XP with an small dos exe file that I put in the jar. It simply lists running processes as strings.
You could use JNI. I don’t know. I never went very far. But you have the idea
#2 for each target os you create a safe list + blacklist.

You could ask that only one java.exe to be running when submiting highscores for example

Unfortunately Java does not provide many builtin ways to query the system on which it runs.

EDIT: I also remember wanting to add random screen shots sent to the server to deter the user from hacking

#16

Here is why, no matter how insanely you obfuscate your client, it can never be secure.

  • The user installs a proxying program
  • The user sniffs outgoing traffic
  • The user is able to see exactly what data you’re sending to the server for your highscores or whatever

That means that the user can figure out how to change the data. You can do things like put check digits or whatever on it, but in the end the “hacker” has access to both the outgoing information and the client that generates that information. Therefore you are boned.

#17

run another client in a virtual environment or use VPN to another system. There are tons of ways to avoid this. There is no client side security - ever. There is security through obscurity. There are mostly secure and very complex applications. But given enough time, all client side security plans will be broken. You best bet is that you have sold enough games by then :slight_smile:

#18

Are you seriously suggesting installing spyware on my system, for the purpose of uploading a highscore? What on earth are you thinking. You are like those DRM nuts: hijacking my computer through rootkits (and accidently opening security holes) so I can play a game that I bought.

Any clientside security that is so invasive is clearly heading in the wrong direction.

#19

lol listing processes is spyware? Why the emotional blahblahblah?

#20

listing processes IS spying!
If I am running naughty-nurses.exe then that is my prerogative and your application should not be tracking this unless I specifically allow it.