Tag Info

Hot answers tagged

44

If people want to bot, I don't think you can really stop them. You can of course implement many measures that make botting more or less of a pain. But you can only do so much before your codebase turns into a gigantic mess that's hell to maintain, error prone, and annoys legitimate users. Meanwhile the botters will always find a way to defeat your ...


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 ...


24

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 ...


24

The best and only effective defense against bots is to design your game in a way that players don't feel the need to automatize in the first place. When your players automatize simple tasks which do not actually require skill, it is a sign that your user interface is lacking and they are substituting an UI feature they are missing. Does your game include ...


22

Don't make your game so vulnerable to johnny-on-the-spot effort First, make sure that players who only play your game for twenty minutes or an hour a day in a single sitting aren't at a huge disadvantage to players who leave it open at work and play 16 hours a day. This may require a change in your game mechanics - for instance a move allotment that fills ...


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 ...


19

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 ...


18

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

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 ...


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

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 ...


16

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 ...


16

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 ...


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

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 ...


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. ...


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.


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

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 ...


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

You can't stop them. But you can make their lifes miserable, as they have to spend lots of time writing their bots, and updating them. You have to use whatever you have to verify if user is valid. Check for request headers, and reject requests with invalid values. Either set custom headeror check for existing like user-agent. Sure it's easy to overcome, ...


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

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 ...


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

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

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 ...



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