Secure highscore submission over HTTP

[adadad]

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

[Riven]

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

[krasse]

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.

Games published by our own members! Check 'em out!

[SimonH]

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.

[delt0r]

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.

[ddyer]

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.

[DzzD]

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

[Mordan]

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.

[delt0r]

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.

[ryanm]

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.

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.

Games published by our own members! Check 'em out!

[Mordan]

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.

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.

[DzzD]

... In theory though we agree. there is no security at all. neither server side.

no I wont agree 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

[Mordan]

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)

[ryanm]

<engage socratic mode>

your processes will be spied upon. (therefore it won't be cross platform)

1) How does your hack-checking code see what other processes are running?
2) How do you determine if a given process is forbidden

[Mordan]

<engage socratic mode>

1) How does your hack-checking code see what other processes are running?
2) How do you determine if a given process is forbidden

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

[Eli Delventhal]

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.

[Matzon]

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

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

[Riven]

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.

[Mordan]

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.

lol listing processes is spyware? Why the emotional blahblahblah?

[Matzon]

lol listing processes is spyware? Why the emotional blahblahblah?

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.

[BoBear2681]

Besides that, just listing processes alone wouldn't be good enough, somebody could make a copy of "java.exe" (or whatever program) and raname it to something else, like "mspaint.exe", so your app couldn't detect a "bad" process by name alone.  It would have to resort to even more devious shenanigans to analyze what all other processes are up to...

[woogley]

At the risk of beating a dead horse: the client cannot be trusted. ever.

A few years back when I wrote BeetleMania, I was convinced my homebrew-security was uncrackable (or at least not worth trying).

But encryption tricks or spying on processes or whatever is meaningless because you're fighting the wrong battle.

For example, I asked the #lwjgl channel to bypass the highscore "security" in BeetleMania. Matzon promptly wrote a java app that simply called the routine/function that fired off the highscore. He didn't have to break my 'encryption', he simply provided an input to my own program which it happily encrypted and sent to the server.

Now, granted, that was poor design on my part. But the point is you can't defend against state. Even if it came down to someone editing the program's memory to adjust the score .. you just can't defend against that.

Summary: if, under correct circumstances, your program can submit a valid high score .. those circumstances can _always_ be emulated to fool your program. That is virtualization and/or emulation at the most basic level.

[delt0r]

I am 200% on Riven side here. Its spyware plain and simple. Its looking and seeing things it has no business seeing. Your highscore list is just not that important. We are not securing launch codes here.

There is a reason (other than i hate grind) I won't touch WoW. It takes a screen shot of every open window (even if minimized) and "hashes" it and phones home. Well it has a hard time doing that on wine. Or in VM doesn't it.

So not only will this method *not* work. But all the honest players will hate you for it.

So server side content and logic, and/or constant "updates" to the client that break map hacks etc is about as good at you will get.

You can also "randomize" the binary so that a patch will only work on some of them. However then the crack will just include the whole binary.

[Orangy Tang]

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.

The sequel was much better.

[Mordan]

well if you are in a money tournament you will be willing to let the process listing work and the random screenshot (for map hacks) being taken.

highscores were just the subject of this post.

Another solution for highscores is the recorded game. The game is recorded as an instruction set. So this instruction set can be replayed and the highscore can be verified by the community. A hacker able to create an instruction set to reach the highscore deserves it.

[Orangy Tang]

A hacker able to create an instruction set to reach the highscore deserves it.

Not really - all the hacker has to do it make the client run at half or quarter speed. From the recorded keystrokes it'll look like they're playing really well. Similarly a hacker could put a memory image save/restore and so 'incrementally' play a perfect game.

Running a for-money tournament on an open machine and trusting the client is flat out stupid IMHO.

[DzzD]

There is a reason (other than i hate grind) I won't touch WoW. It takes a screen shot of every open window (even if minimized) and "hashes" it and phones home

lol

what about :

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

any chance to have more detail on the target game ? it is IMO important to design security

[Mordan]

At the risk of beating a dead horse: the client cannot be trusted. ever.

in theory it cannot be trusted, and  you cannot trust the server either in theory. In practice you can find ways to trust both.

You got to think out of the box. Maybe by using real life ways...

Score laundering is like money laundering. How do you think emoney is secured?

[DzzD]

In practice you can find ways to trust both

I dont think so... can you point me only one client software (game or other) that deal with money and wich is trusted ? (client may check basic error but server will doublecheck => client is not trusted)

[woogley]

You got to think out of the box. Maybe by using real life ways...

It's not about thinking outside the box .. I can respect that you have this blissful fantasy that securing the client is possible .. we've all been there, you just haven't yet crashed into the wall of realization.

Score laundering is like money laundering. How do you think emoney is secured?

That's a different problem. It is technically feasible with the correct inputs to post funds to your account from someone else's account. That information is usually obtained through social engineering.

But the point is the entire "state" of an account is handled on the server - the client can only request transactions to be made, which the server will always validate. But that doesn't solve the problem of someone usen valid (but stolen) information to post a valid transaction.

To make a game analogy .. you could use a similar strategy with a game of Checkers. The server generates a game state and hands it off to the client. The client can then tell the server move-by-move what it wants to do. The server maintains the game state and validates each move.

But even this is not securing the client - it's just computing game state on the trusted end. Anytime you have a game where the state is exclusively maintained on the client side, you've already lost. It will be possible to cheat.

(you could also cheat at the "Checkers" strategy with a bit of AI).