Jump to content
  • Advertisement
Sign in to follow this  
_Flecko

Open source + encryption

This topic is 4914 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm adding a feature to my game that will allow players to record demos/"ghosts" to show how they got their best times on levels. The file would ideally include the player's name and be encrypted so that it would be impossible for one to change the name field and take credit for it. However, I also want to release the source code. Is there a way that I can obscure the encryption keys so that people cannot tamper with these files, while releasing code that can immediately be compiled and produce files compatible with the binaries I release?

Share this post


Link to post
Share on other sites
Advertisement
The encryption key should be implicitly user supplied, perhaps a random number/string automatically generated on the user machine and then hashed with the username.

Share this post


Link to post
Share on other sites
Let the user supply a password and hash it with a random string.Then use any decent encryption algorithm you want.

Encryption algorithms like XOR will do fine because no one going to take huge pains to make their names come in a record demo.People who have the skill to do that might find it easier to play the game.

Share this post


Link to post
Share on other sites
Just make sure that its unique. ie. No script kiddies going to go "Crack Encryption" on it.

Maybe soemthing like a counter.

You encrypt the entire file with something like


for i = 0 to linelen
line(i) = line(i) xor (pkey[i % lenpkey] xor ((i + j) * linelen) % 255)
netx i
j += i


Would be harder to break. (ie. its unique, so although you can wright your cracker program in seconds... its reasobaly secure.

From,
Nice coder

Share this post


Link to post
Share on other sites
Depends how hardcore you want to get. For a freeware game, I'd say XOR-type obfuscation will probably do fine, coupled with a little creative obscurity. If you were really serious about doing it properly, sign the replay data (complete with name) using public-key cryptography and have an online database of players' public keys. This would raise the bar to the level where, with an adequate key size, not even the NSA could steal your replays. :)

Share this post


Link to post
Share on other sites
Release the source code with a dummy "null" encryption module.

For your high scores / "ghost" system, insist that people use precompiled binaries which have a closed-source encryption module statically linked into it.

On your internet high score table, only take notice of people using an official binary with the closed-source encryption module.

Otherwise, people would be able to modify the game.

Be sure that you include in your save files
- Some sort of hash of the levels data (so you know the user hasn't made unauthorised mods)
- Some sort of hash of the executable (same)
- A cryptographic signature on the whole thing, to prevent the user easily modifying the file.

The data file does not need to be encrypted, only *signed*. Encrypting it will make it compress less well and not achieve anything.

But bear in mind:

- Even if you carry out all these steps, people will still be able to cheat. In-memory modification of the game's data is essentially impossible to prevent and will allow people to cheat.

Mark

Share this post


Link to post
Share on other sites
There seems to be some confusion about the actual threat. I can think of two possible attacks to a demo system that allows you to show off your "best runs" of a game (obviously, there may be more):

A) Attacker modifies the game code and/or data files to allow him to beat the game more easily. This is obviously a very tempting (and, even for many closed source games, simple) attack, and it's the one most people here seem to be talking about.

B) Take an existing, valid demo file and change some part of it to make it appear as if it was created by the attacker. This is the concern that Flecko explicitly mentioned in the original post.

Protection against Point A) depends greatly on the type of game and how demo recording works. Suppose demos are video-like, for example like Quake demos (Quake singleplayer demos are basically a dump of the entity data that the server sends to the singleplayer client). Now the attacker could modify the AI to be easier to beat in a subtle way. Tampering like this will be very hard or even impossible to notice.

However, demos can also be implemented by recording the player input. This is how real-time strategy games usually do this, since it's how their multiplayer mode natively works. In this case, you can easily verify that the game logic has not been modified, because playing the demo involves rerunning the game logic: If the logic has changed, their will be desyncs.
Of course, some forms of cheating are still possible, in particular information cheats (e.g. reveal maps in RTS, wallhacks in FPS, etc.) and bots (aimbots etc.).

Protection against Point B) is trickier. As long as you have a centralized ladder on a central server, you could just hash the relevant part of the demo file. If a different user attempts to upload a demo that has already been registered, their attempt is denied.

But now consider this: An attacker could basically playback a pre-existing demo from a different player up to a certain point, and then play the end of the game from this basis. A demo that is obtained in this way will differ from the original, but its score (or time, or whatever your benchmark is) will be very close. You could fight this problem by using two hash values: one for the entire demo, and one for the first half of the demo. If the game is rich enough, it will be extremely unlikely for two players to produce exactly equal input even for small parts of the game.

Keep in mind that while all this works without a central server, there is the problem of arbitration: What if two players lay claim on a demo? How do you decide who was first? Of course, from what I've read you want to create such a central server anyway.

An additional measure you could take which does not depend on a central server is to use random elements in the game based on a random number generator that is seeded with a hash of the player's name.

cu,
Prefect

Share this post


Link to post
Share on other sites
Don't reinvent the wheel or invent your own trivial to crack encryption scheme; this is a solved problem. Look up "digital signatures" on google. It's the kind of thing companies use to sign programs so you can verify their origins. The idea is that the encrypted file contains a hash of the message (the demo and the player name here) so you can easily check if the file has been tampered with because altering the file and getting the hash to match is virtually impossible. Here's a starter article I found quickly. Good luck!

Share this post


Link to post
Share on other sites
If you're really interested, pick up "Applied Cryptography" by Bruce Schneier. You can get a CD-ROM with just about every publicly released crypto and hash algorithm on it, via the mail after buying the book. It goes over not only the algorithms and the math, but more importanly, the protocols, when what type of algortihm is needed, and how to write things that are secure. Schnier's later books ("Secrets and Lies" and "Beyond Fear") are all about how just slapping a hash function or PKE in your code is not enough to make it secure.

http://www.schneier.com/book-applied.html

Share this post


Link to post
Share on other sites
Quote:
Original post by StaticEngine
If you're really interested, pick up "Applied Cryptography" by Bruce Schneier. You can get a CD-ROM with just about every publicly released crypto and hash algorithm on it, via the mail after buying the book. It goes over not only the algorithms and the math, but more importanly, the protocols, when what type of algortihm is needed, and how to write things that are secure. Schnier's later books ("Secrets and Lies" and "Beyond Fear") are all about how just slapping a hash function or PKE in your code is not enough to make it secure.


Not that you suggested it, but only experts should write high-security software anyway as you are bound to make mistakes if you don't know what you're doing. You might create an insecure protocol or implement a secure one insecurely. If you take a look on google, there are hundreds of readily available libraries that you can use for this kind of thing which is by far the best option. For example, in the standard Java API, there are several classes for things like RSA signing, public/private key generations, digital signatures etc. that make this kind of thing so easy it's like you don't even need to try.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!