next »

[NiallM]

So I'm toying with the idea of online high scores for a game I'm working on.  I've done a bit of research and I think I see how to implement them (POST and GET requests to a db on my website via something like libcurl, right?), but I'm wondering if it's worth the effort, since my game's going to be open source.

Short of making the game closed source (which is not something I have any intention of doing) I don't see any way of preventing someone just building their own version of the game and spamming the score boards with ridiculously high scores.  I did a search to see if there are any open source games with online high scores, but I didn't turn up anything useful.  So, before I consign the whole idea to the pile of 'nice ideas that didn't work out', I thought I'd pose the question here.  Is it possible to have reasonably secure high scores in an open source game?


On a related note, does anyone have any experience with GamerCV?

[ThemsAllTook]

I've struggled with the same issue, and ended up releasing the one game I wrote that used online high scores as closed source. This of course only protects against the most casual hacker; someone with a binary can exploit it just the same with a little bit more dedication. I do some server-side checking too to make sure that all submitted scores are in the realm of possibility, and discard the ones that blatantly aren't, but it doesn't really stop someone from submitting spoofed maximum-score-the-server-will-accept-as-plausible entries.

This is a tricky one - I'd be very interested if you manage to come up with a clever solution to it.

[TobiasW]

My game "Catcher" which I want to release as Open Source later on too, currently uses some encryption mechanic with a salt - which of course I won't release with the rest of the game.

It looks like this:

[Client] --- requests one-time-usable-key --> [Server]
[Client] <-- responds with one-time-usable-key --- [Server]
Client generates passkey out of playername, playerscore and one-time-usable-key.
[Client] -- playername, playerscore, one-time-usable-key, passkey --> [Server]
The Server (which has the same salt) then trys to generate the passkey too.

Secure? Dunnow.
As "secure" as closed source? If you don't release the encryption mechanic along with it, probably.
As secure as a non-online-game can get, I guess (/hope).

[David Pittman]

Perhaps you could use the macros __DATE__, __TIME__, or __TIMESTAMP__ as part of your salt, so that you can release the source without revealing what unique salt you're actually using on your server and released client. Or just define your salt in a header that you don't release publicly, I guess.

[Draknek]

You can release the source code for everything except the high-score component. Or for everything except a salt value for the high-score component.

For certain games, you might be able to send some gameplay data with the score to verify the playthrough on the server.

[TobiasW]

Perhaps you could use the macros __DATE__, __TIME__, or __TIMESTAMP__ as part of your salt, so that you can release the source without revealing what unique salt you're actually using on your server and released client. Or just define your salt in a header that you don't release publicly, I guess.

The problem is that the client AND the server have to have the same salt without communication. __DATE__ would work, I guess, though when you can crack the code for one day, I don't think it would be too much work to crack it again for another. Just one more layer of obfuscation.

[David Pittman]

Perhaps you could use the macros __DATE__, __TIME__, or __TIMESTAMP__ as part of your salt, so that you can release the source without revealing what unique salt you're actually using on your server and released client. Or just define your salt in a header that you don't release publicly, I guess.

The problem is that the client AND the server have to have the same salt without communication. __DATE__ would work, I guess, though when you can crack the code for one day, I don't think it would be too much work to crack it again for another. Just one more layer of obfuscation.

Yes, of course. I'm assuming you'd know what __TIMESTAMP__ was at compile time and what the resulting salt was, and you'd configure the server to match. I'm not assuming that every person who builds the game will be able to run on any server that anyone else built. Obviously, my suggestion would fail under those circumstances (by design).

[NiallM]

As "secure" as closed source? If you don't release the encryption mechanic along with it, probably.

I did consider having the score encryption as a separate closed source module, but - perhaps I'm missing something, my understanding of encryption is very limited - surely there's nothing to stop someone just passing the wrong score to the encryption module in the first place?

Perhaps you could use the macros __DATE__, __TIME__, or __TIMESTAMP__ as part of your salt, so that you can release the source without revealing what unique salt you're actually using on your server and released client. Or just define your salt in a header that you don't release publicly, I guess.

This is perhaps the way to go.  I'll be releasing under the GPL, so I'll have to release all my source, but I don't think there's anything stopping me from releasing it with a different salt to what I'm using in the binary versions.  It would probably have to be some random number rather than __TIMESTAMP__ though, since I'll be doing binaries for more than one platform.

It doesn't have to be completely unbreakable, just strong enough that I don't get flooded with dodgy scores (in the eventuality that enough people play the game to want to flood me with dodgy scores ).

[TobiasW]

@David Pittman:
Sorry, fault is on my side! I didn't think of the predefined macros as I was typing my post. My bad.

As "secure" as closed source? If you don't release the encryption mechanic along with it, probably.

I did consider having the score encryption as a separate closed source module, but - perhaps I'm missing something, my understanding of encryption is very limited - surely there's nothing to stop someone just passing the wrong score to the encryption module in the first place?

To pass it to the encryption module, they'd have to have access to it. Since it is compiled into your client (like every other bit of your code), the only way I can think of (besides some sort of decompiling) would be to change the score value in memory, and that is an entirely different section of security.

Do you mean that by "surely there's nothing to stop someone just passing the wrong score to the encryption module in the first place"?

[Solved]

I think he meant that, as it is open source, there is nothing to stop people from changing the source code to give them a certain score and just having that sent to the server through the encryption module. Memory hacking would work too.

[tzachs]

How about releasing two versions?
One open source without the highscores system, and one closed with the highscores...

[Skofo]

How many monkeys does it take to remove the secret portions of a game's source code before open sourcing it?

Seriously, guys. This isn't hard.

[TobiasW]

I think he meant that, as it is open source, there is nothing to stop people from changing the source code to give them a certain score and just having that sent to the server through the encryption module. Memory hacking would work too.

But they don't have the encryption "module", because it is closed source:

I did consider having the score encryption as a separate closed source module, but [...]

It isn't some magic separated "module" from the game - it is just a regular class of the game that never gets Open Source'd.

[NiallM]

Sorry, I should have made myself clear; when I said open source, I meant GPL.  Keeping some part of the code closed source/not releasing it at all would break the license.  And also it would be contrary to my whole motivation in releasing the source.  I want the user to be able to download the source and compile the game for themselves without modification.  The free software/open source nature of the code is more important to me than the inclusion of online high scores.

Anyway, per my previous post, I think David Pittman's idea is a reasonable compromise.  If anyone's interested, I might post about how well it worked out once the game's been released.  If it's a massive failure I'll just turn off the online score boards and revert to local high scores.

[Core Xii]

The most reliable method of verification I've come up with is to record a replay of the game, and have the server play it back. This verifies that the high-score was actually achieved... Though it does not verify that it was achieved legitimately.

To verify that a human produced the scoring input you'd have to analyze the replay, comparing it against average human reaction times, etc. Even then, it's technically impossible to actually tell the difference between playing in real-time and frame by frame using save-states.

Sites like Speed Demos Archive use a human verification process where a panel of volunteers watch a replay to verify its authenticity before it is accepted.

[Solved]

I think that the replay would be enough for most purposes. It would stop people from being able to use memory hacking or changing the source code to get a high score. You can't really go any further than that and I don't think you would need to. I believe that a playthrough of an extremely good player would be pretty much indistinguishable from the playthrough of somebody using savestates. And your idea about reaction times would not work as people have different reaction times and the game would run slower on an extremely slow machine.

[TobiasW]

Sorry, I should have made myself clear; when I said open source, I meant GPL. Keeping some part of the code closed source/not releasing it at all would break the license.

Ah, I understand. And I guess I understand why.

And also it would be contrary to my whole motivation in releasing the source.  I want the user to be able to download the source and compile the game for themselves without modification.

Could be done by providing alternative code for the highscore encryption. But I guess that would be against GPL too.

[Skofo]

Sorry, I should have made myself clear; when I said open source, I meant GPL.  Keeping some part of the code closed source/not releasing it at all would break the license.

This is incorrect.

As the copyright holder of your code, you are free to do whatever you want with it. Releasing your code under the GPL does not imply that you must license all copies of that code under the GPL. You can release a GPL'd copy of the code without the secret high score portion, while keeping the original, unmodified version closed-source; therefore, you can release your game with the high score functionality without revealing the code for the online high scores.

The source codes of the Quake games were released under the GPL, but without the code that verifies license keys, and it's totally legit.

Do note, however, that if someone else contributed to your GPL'd code, he'd be the copyright holder of whatever he contributed, so you wouldn't be able to use that contribution inside your closed-sourced version with the secret high score code unless he gave you permission to do so.

A lot of people seem to have major misconceptions about open source, even in more coding-oriented communities such as this one. Some people here even paint open source in a bad light due to those misconceptions, which is quite a shame. Perhaps I should write a tutorial about open source geared towards indie game developers...

[David Pittman]

A lot of people seem to have major misconceptions about open source, even in more coding-oriented communities such as this one. Some people here even paint open source in a bad light due to those misconceptions, which is quite a shame. Perhaps I should write a tutorial about open source geared towards indie game developers...

I think there are some legitimate concerns about GPL--mostly, I would never use a GPL-ed library because I want the choice to not open source my own projects. So for me, it's a zlib-esque permissive license or nothing.

But a tutorial on the meaningful differences between open source licenses would be super useful. The information is all out there already, but I don't think I've seen it consolidated and presented with respect to game development especially well.

[Skofo]

It is pretty damn rare to find a GPL'd library, so you hardly have anything to worry about.