Uh, oh.

Feels like if I want this highscore to be secure, I need to work pretty hard :).
And the Obfuscator thingy seems to cost me a bit too "Our obfuscator is available at $799 for 1-5 developers."

I'm using SharpDevelop which doesn't (yet) have an obfuscator. But if VS.NET have one, I guess I could find one for free somewhere.

Quote:Feels like if I want this highscore to be secure, I need to work pretty hard :)

The only way that actually works is to support record/replay of the game, and upload the replay file to the server. The server replays the game, and enters the score that it arrives at.

Any scheme that depends on trickery on the client can be hacked -- and will, if it's important enough to somebody.

I actually though of that replay solution, but I was afraid it would use too much bandwidth. I'm using a low-price webhost with limited bandwitdth.

When I decided to do an online highscore game, I tried to come up with a game concept that you easaliy could create small replays-files to. But I ended up remaking an old DirectX game I made in C++ a long time ago and using a very simple form of highscore.

Quote:Original post by hplus0603
Then create a "perfect" replay file and send it to the server.

If your game is somewhat complex, I guess the easiest way to make a perfect replay-file is to play the game. I imagine a replayfile where you have a LOT of coordinates for instance. Editing these maybe tens of thousands of coordinates isn't really worth it. If you want more security, you can also let the game send the replay-file to a human, which then would analyze it so it looks "natural". If you want to submit a highscore to the old classic Elasto Mania, the replay is first analayzed by humans.

The replay method would probably be the safest. You at least get the guarantee that what they did to get the score is at least possible. Plus having replays of all the best players would be a cool feature. Still doesn't stop them from hacking it to always use the same seed to make it easier, or slowing it down to give them more time to react to things.

For storing the replay, you store the game's seed used by the RNG, and then record key presses/actions/events as a frame offset since the last event, and a special 'null' event that does nothing to prevent the offset counter from overflowing, which would screw things up.

Assuming 1 byte per offset (game logic could run at, say, 30 fps) there will be at least 2 bytes (offset + null event) every 8.5 seconds. Assuming the null event is 0xff, and the offset is 0xff, having a long run of 0xffff will be easilly compressed. Next, assuming an average of 8 key presses per second, a recording of a 20 minute game should total about 19KB. Again, it should be less with compression.

I'm not sure how authentication would help. It just ensures it coming from who we think it is and that it got there okay. It's not going to stop them from sending fudged data.