Tag Info

Hot answers tagged

36

The short answer is you can't do it. Anything that runs client side, especially from source, can be modified to defeat your tactics trivially. If you put in place a client side checker to look for abrupt changes, a user can just disable the checker. The good news is that, generally, there is very little cheating on single-player games. The only major ...


24

The way you have it described, somebody hacking a save file would just need to construct an MD5 hash of the save file values in order to bypass this measure. You need to add one thing in order for this to even really be worthwhile: a secret block of arbitrary data that's added to what you're hashing (both when creating the save and when validating it on ...


24

Specifically regarding the last bit of your question: No, it is never forgivable to have an insecure authentication system. Users are rarely enlightened when it comes to computer security. Users use the same password for your little game as they do for their Google account, Facebook account, bank account, and so on. Even if you can claim that it's their ...


23

Basically, you have three requirements: it should not be easy to use the same key for multiple client instances, it should not be easy to generate new valid keys, and it should not be easy to steal the key of a legitimate client. The first part should be pretty straightforward: just don't let two players log into the same server with the same key at the ...


20

There is no way to guarantee that the client in use is the client you want them to be using, there are always ways around every technique, even with a closed source application. When it comes down to it, with a closed-source application, any good reverse engineer with some free time can spoof packets to/from your server. In an open-source application, it ...


19

There is no such thing as good DRM. Consider it from the computer owner's perspective: DRM is a program whose function is to override the owner's ultimate control of the system and allow some other programmer somewhere else to dictate what he can and cannot do with the computer, which is his personal property. In any other context, this would be considered ...


17

Don't trust the client. It's as simple as that. Any safeguard you can put in place can be broken; and truly safe methods are impossible within the scope of JavaScript. The best approach is to only trust the client with drawing what you send it and retrieving user input. Giving it anything more is just asking for trouble. Any information you send to your ...


17

It depends how they're cheating, focusing on one of the primary ways of creating cheats, other processes latching into your application and modifying it - you can enumerate through all other processes, and hook their memory manipulation methods, and their keyboard/mouse emulation methods. Wallhacks are typically written by injecting code between your ...


16

first lets say since you have a very simple save file, you can use text file. one of the simplest ideas is to use a string key to lock/unlock data: void encrypt(string& data,string key) { for(unsigned i=0;i<data.size();i++) data[i] += key[i%key.size()]; } void decrypt(string& data,string key) { for(unsigned ...


16

There's no 100% savety, but you could start with a rather simple approach: You'll need some way to verify generated keys, for example included checksums. Of course, this must not be too easy to figure out. Optional (but recommended) there'd be a server side database verifying the keys with a database of all given out keys so you can't generate keys, even ...


15

Simple ways to protect your game: Duplicate your data: store some information twice and compare the copies. If they are different, something is going wrong. You don't have to do it per variable, you can also make CRC's on some big areas of memory (ex: on a struct that contains all player information). Encrypt your data before its written to memory (and ...


15

You can't stop memory editing cheats, so design your game so that such cheats won't matter. For an online game, sensitive data like money on your own server, and don't rely on the client to have the correct amount. That way it won't matter if players change the amount of money displayed on the client, because when the player purchases stuff the game checks ...


15

Yes, somebody (in fact, multiple somebodies) on the team that develops any multiplayer game, regardless of scale, should have a strong working knowledge of networking security concepts at both the hardware and software level. This is especially true for games that will involve a lot of persistence of agency, since that constitutes investment on the part of ...


15

Don't just send an integer score to the server. Send a collection of game stats that can be used to verify the score was realistic. Or you can implement some pre-shared key for calculating the score. You could send incremental scores and stats throughout the game and ensure that the increase is reasonable. However, I wouldn't worry too much about it. The ...


14

At the most extreme solution, you basically never trust the client. For games like MMOs, users don't run their servers, and any gameplay logic is handled server side. Never give the client the authority to say "I have X health" or "I have X ammo", etc.


14

Nothing can be considered secure client side; anyone who tells you it is, is lying. You can use any encryption and scramble method you want, but since the client must be also able to decode it, and the user has access to the client itself, if he is resourceful enough he'll have access to the decryption key / algorithm. You can only add layers of annoyances ...


14

Answers SRP - Secure Remote Password - This is based on Diffie-Hellman. The idea is that you can do a mutual password check without actually ever transferring the password or any information that can be used to derive it. Even though it's secure over the wire you should still hash and salt your passwords as your server must never store them in plain text. ...


13

For a PC title, Steam is really the only one that should be considered these days. Safedisc and SecuROM install terrible things onto the user's computer and cannot be uninstalled.


13

That's interesting problem, but I think you are asking the wrong question here. Let me start from detecting hacked client approach: If your client is executed on user's side, he can do whatever he wants with your code (until it's too complicated for him, but there will always be someone smarter in the line). Everything you can do like hard-coding encryption ...


13

I once found a very neat quote on the net that's very, very true for any online game: The client is in the hands of the enemy. As such, you can't really avoid people doing nasty things to your game client. Due to this, don't trust the client at all, i.e. everything important should at least be verified server side (better: calculated there). If this is ...


12

Attack vector 1: The netcode As already pointed out by Mario, one important factor when designing the network protocol of a client/server application is to not blindly trust the client. You can't control the software which runs on the client machine. You can't even tell that it's your software and not something the user programmed themself. The same ...


11

If this is not an online tracked competitive type game: Let em hack away man. You can spend way too much energy on things like this when people who will play the game, will just play the game. Those who want to hack it will never really want to play it, they just want to hack it. If it is an online competitive type game: All you have to do is store the ...


10

All multiplayer games that respect themselves takes all important decisions server side. All as in All. Never trust the client if there is something in an action that might give an advantage for the player. World of Warcraft creates all loot, checks transactions etc server side but due to lag it lets the client control how the player moves (to check that ...


10

Knowing something about security is a good idea before trying to write a multiplayer game, but things like port scanning and router hacking, or even cryptography, are not what you should be looking into at this stage. Rather, the things you should learn about are trust, validation and robustness. Knowing a little bit about psychology, especially about ...


10

There is nothing on the client side which can not be faked, everything somebody has physical access to can be manipulated. The IP contains routing information and thus hints on the location. But the player just needs a proxy and whoops... the IP hints at a completely different location than the player actually is. Trust your players, don't give them a ...


10

You can use an IP geolocation service to obtain an approximate location from where the user is connecting. Compare this with the GPS data received and you can weed out some extreme cases (players connecting though proxy, etc). You can even calculate distances between user logins and if they are too high (say, the location moved 1000 kms between two login ...


10

I already answered a question like that here, and I'm sorry to tell but: I wouldn't bother to make some server side simple checking, but I don't want to go the Diablo 3 path keeping all my game state changes on the server side. Is the baddest thing you could have say here. If you wanna do an "anti-cheat" engine, you'll have to do that. You can add ...


9

If you've got a system where the logic is expensive and must be done mostly on the client to save server cycles, you can implement a probabilistic cheat detection system. Every few minutes it chooses a different few players to inspect closely and consistency-check on the server. Since cheaters rarely limit their cheating to short and rare periods of time, ...



Only top voted, non community-wiki answers of a minimum length are eligible