Jump to content

  • Log In with Google      Sign In   
  • Create Account

How to verify as a valid client?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • This topic is locked This topic is locked
17 replies to this topic

#1 Xanather   Members   -  Reputation: 712

Like
0Likes
Like

Posted 23 June 2012 - 09:37 PM

Im creating a server, at the moment though anyone with a TCP connection and a specified port can connect to my server, this itself can be very vulnerable. But what if I create a system where after a specified amount of time, if the client has not verified himself, he will be banned from the server for 5 minutes.

So here is the question: How would i go around making sure only real clients can connect who have the correct client software/application?

Sponsor:

#2 riverreal   Members   -  Reputation: 616

Like
0Likes
Like

Posted 23 June 2012 - 10:05 PM

I think a ban is not the solution, because after 5 minutes the impostor can try to verify again, and again.

Maybe you can use a specific number, or ip number to make a "doble verification".
I'm just guessing, I don't know much about servers, and net programming... sorry

I think you can read a cryptograpy book (?)
I'm guessing again...

#3 hplus0603   Moderators   -  Reputation: 5734

Like
2Likes
Like

Posted 24 June 2012 - 12:28 AM

How would i go around making sure only real clients can connect who have the correct client software/application?


This question pops up every month, and the thread always goes the same way:
- Those how know, say "It can't actually be done, because a server only sees the bytes on the network, and there is no way to tell where those bytes came from. Someone can reverse engineer your client, because they have the compiled executable/libraries for it, and you wouldn't know the difference."
- Others will pipe in with all kinds of "what ifs," and other kinds of denial, that won't actually solve the problem, and generally end up recommending spending years of hard-core development to add another five minutes to the time it would take to reverse-engineer a game client.
- Long posts and frustrations on all sides, because those who *want* it to be possible to tell what's on the other side of the wire, simply won't accept that you can't.

So, let's all agree to not do this again? There is no way to tell what program is sending the bytes from the other end. All you can do is specify what "good" bytes are, and anything that does not follow the pattern of "good" bytes is probably a bug in your client (rather than some attempt to attack your server.)

Cryptography does not help, because it protects against some shady third party. The problem is that the code for the client is in the hands of a second party -- the actual player. No amount of downloadable DLLs or server-client-collaborated checksums can deter a skilled hacker with a virtual machine to host your game in.

A networked game has to be designed with the protocol for the network packets frontmost in mind. If you add a packet that says "I gained X gold," be prepared to receive packets that say "I gained 4,000,000,000 gold." If that's not good for your game balance, then don't create those kinds of packets. This may require a different way of implementing your game, or even a different game design.

On the Xbox, life is slightly simpler, because Microsoft takes care of banning hacked consoles everytime a new Modern Warfare comes out. No suck luck in the PC or cell phone world.

enum Bool { True, False, FileNotFound };

#4 DevLiquidKnight   Members   -  Reputation: 834

Like
-2Likes
Like

Posted 24 June 2012 - 01:18 AM

How would i go around making sure only real clients can connect who have the correct client software/application?

Cryptography does not help, because it protects against some shady third party. The problem is that the code for the client is in the hands of a second party -- the actual player. No amount of downloadable DLLs or server-client-collaborated checksums can deter a skilled hacker with a virtual machine to host your game in.

This is wrong, proper cryptography will solve it, although its not necessarily easy to do and likely not worth your time. The only way a hacker could thwart proper cryptography is with millions of dollars worth of computer hardware, or the ability to time travel. Their are ways of using certificates to validate that the person is who they say they are, and that what was sent is authentic its the entire point of digital signatures. Otherwise eCommerce would be impossible. Look into non-repudiation, however this is not the only thing that should be considered. A poorly coded server design that is insecure is likely to have other flaws.

Edited by DevLiquidKnight, 24 June 2012 - 01:46 AM.


#5 Prefect   Members   -  Reputation: 373

Like
0Likes
Like

Posted 24 June 2012 - 02:13 AM

Your response to hplus is simply saying No without justification. Cryptography isn't some magic dust you can sprinkle on your game to make it have whatever property you like.

Specifically, all cryptographic key material that is used by a "legitimate" client will also be known to a cheater, and do doesn't add more than a hurdle.
Widelands - laid back, free software strategy

#6 SimonForsman   Crossbones+   -  Reputation: 6325

Like
0Likes
Like

Posted 24 June 2012 - 02:30 AM

This is wrong, proper cryptography will solve it, although its not necessarily easy to do and likely not worth your time. The only way a hacker could thwart proper cryptography is with millions of dollars worth of computer hardware, or the ability to time travel. Their are ways of using certificates to validate that the person is who they say they are, and that what was sent is authentic its the entire point of digital signatures. Otherwise eCommerce would be impossible. Look into non-repudiation, however this is not the only thing that should be considered. A poorly coded server design that is insecure is likely to have other flaws.

Proprer cryptography won't work since the legitimate client needs access to the same keys the hacker needs, The hacker has access to the legitimate client and can do anything it does (Which means the hacker can encrypt his modified packets with the same key as the legitimate client uses to encrypt its unmodified packets)
I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#7 Angus Hollands   Members   -  Reputation: 722

Like
0Likes
Like

Posted 24 June 2012 - 05:20 AM

Unless you can encrypt your game source into an industry standard encryption algorithm, there's little point. A system's entry point is always it's weakest, and so whilst your source may be protected, the moment it hits an interpreter / compiler / loading algorithm, there are more methods of revealing it's contents then there are words in the dictionary. Considering the fact that a cheating client can define more than one thing, the best method of prevention you have is twofold:
1) Clamping the ability of the client to the parameters of the world (As server side servers can simply limit velocity / orientation deltas).
2) Allowing access to the game source. Sometimes, allowing people access to your game source actually reduces the rate of cheating attempts. When you release the source to the public (as in, don't bother wrapping the game in encryption) you save yourself the time spent on algorithms, and the challenge of "hacking" the game is gone.

#8 DevLiquidKnight   Members   -  Reputation: 834

Like
-1Likes
Like

Posted 24 June 2012 - 05:21 AM

Proprer cryptography won't work since the legitimate client needs access to the same keys the hacker needs, The hacker has access to the legitimate client and can do anything it does (Which means the hacker can encrypt his modified packets with the same key as the legitimate client uses to encrypt its unmodified packets)

Proper cryptography gives each user an individual key, or a certificate, not each client, thus making it so only those who have them are allowed on. In this case I think it would make more sense to only give them individual public keys, as they would be unable to determine the private key. Furthermore if one key was cracked some how which is unlikely if its sufficiently strong all the others would not be. And you'd have revocation lists in the event a account is removed, breached, etc. Hence why I said its more trouble then its worth.

Cryptography isn't some magic dust you can sprinkle on your game to make it have whatever property you like.

I believe I said how to do it, its using asymmetric cryptographic, and digital signatures, along with non-repudiation. Such a system would ensures users cannot deny sending and or receiving data. It would also protect against man in the middle attacks, along with telling you who sent the data. I refer you to read more about digital signatures http://en.wikipedia....gital_signature before assuming I don't know what I am talking about. Posted Image

Edited by DevLiquidKnight, 24 June 2012 - 06:16 AM.


#9 SimonForsman   Crossbones+   -  Reputation: 6325

Like
0Likes
Like

Posted 24 June 2012 - 09:03 AM


Proprer cryptography won't work since the legitimate client needs access to the same keys the hacker needs, The hacker has access to the legitimate client and can do anything it does (Which means the hacker can encrypt his modified packets with the same key as the legitimate client uses to encrypt its unmodified packets)

Proper cryptography gives each user an individual key, or a certificate, not each client, thus making it so only those who have them are allowed on. In this case I think it would make more sense to only give them individual public keys, as they would be unable to determine the private key. Furthermore if one key was cracked some how which is unlikely if its sufficiently strong all the others would not be. And you'd have revocation lists in the event a account is removed, breached, etc. Hence why I said its more trouble then its worth.

Cryptography isn't some magic dust you can sprinkle on your game to make it have whatever property you like.

I believe I said how to do it, its using asymmetric cryptographic, and digital signatures, along with non-repudiation. Such a system would ensures users cannot deny sending and or receiving data. It would also protect against man in the middle attacks, along with telling you who sent the data. I refer you to read more about digital signatures http://en.wikipedia....gital_signature before assuming I don't know what I am talking about. Posted Image


Such a system still doesn't prevent the user from modifying his own client, the best it lets you do is identify the user (But a normal login system lets you do that as well), There is no need to crack the keys since the modified client only needs the public key (Which it allready has access to) to encrypt any data it is going to send, it can freely modify it before that point, digital signatures on the code itself are worthless since the server cannot verify them (it can request verification data from the client but a modified client can get the correct data from the unmodified one for such purposes)

Edited by SimonForsman, 24 June 2012 - 09:05 AM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#10 hplus0603   Moderators   -  Reputation: 5734

Like
1Likes
Like

Posted 24 June 2012 - 12:50 PM

Otherwise eCommerce would be impossible.


Did you not read, or not understand, the argument?

ECommerce works because the protocol is designed correctly. There is no possible request to "please add $1,000,000 to my account."

The use of SSL and authentication (cryptography) is there to protect against third parties, not second parties.

enum Bool { True, False, FileNotFound };

#11 DevLiquidKnight   Members   -  Reputation: 834

Like
-1Likes
Like

Posted 24 June 2012 - 01:20 PM

You can design it to prevent tampering of the client, a hardware dongle comes to mind.

Edited by DevLiquidKnight, 24 June 2012 - 01:27 PM.


#12 SimonForsman   Crossbones+   -  Reputation: 6325

Like
0Likes
Like

Posted 24 June 2012 - 01:25 PM


Such a system still doesn't prevent the user from modifying his own client, the best it lets you do is identify the user (But a normal login system lets you do that as well), There is no need to crack the keys since the modified client only needs the public key (Which it allready has access to) to encrypt any data it is going to send, it can freely modify it before that point, digital signatures on the code itself are worthless since the server cannot verify them (it can request verification data from the client but a modified client can get the correct data from the unmodified one for such purposes)

Combine it with a unalterable hardware dongle.


The client is responsible for reading/writing data from/to the dongle, so it doesn't work either, those things are fine for authentication, not for preventing modification. (I.E, you can ensure that the user has a valid dongle (or valid emulation of a dongle if its a good hacker), but the dongle cannot be trusted to verify the clients software since the client controls the software which interacts with the dongle.

Edited by SimonForsman, 24 June 2012 - 01:26 PM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#13 DevLiquidKnight   Members   -  Reputation: 834

Like
-1Likes
Like

Posted 24 June 2012 - 01:35 PM

Did you not read, or not understand, the argument?

The argument is checking the validity of a client, that is what digital signature is for, and it will do that. You are assuming a hacker with unlimited knowledge and power, which most aren't.

You could easily implement a system such as on-live if your that worried about it. I was not assuming the worst case scenario, but this would solve it.

Edited by DevLiquidKnight, 24 June 2012 - 01:37 PM.


#14 Prefect   Members   -  Reputation: 373

Like
0Likes
Like

Posted 24 June 2012 - 01:40 PM

All the things you mentioned are hurdles. They do slow developers of cheats down. But cheating remains possible, and in the meantime you were slowed down as well: your time could have been spent developing nice new features, or possibly cheat detection, which is arguably more important. So you have to ask yourself if you're really spending your time well.
Widelands - laid back, free software strategy

#15 DevLiquidKnight   Members   -  Reputation: 834

Like
0Likes
Like

Posted 24 June 2012 - 01:43 PM

All the things you mentioned are hurdles. They do slow developers of cheats down.

How would you design a cheating system if all your being fed is image data such as on-live?

#16 SimonForsman   Crossbones+   -  Reputation: 6325

Like
0Likes
Like

Posted 24 June 2012 - 02:08 PM


All the things you mentioned are hurdles. They do slow developers of cheats down.

How would you design a cheating system if all your being fed is image data such as on-live?


aimbots can work with image recognition, but on-live is pretty much as secure as it gets since the client is just a dumb terminal (The software runs entierly on trusted machines), the only type of cheats that work with on-live are bots basically, and they take quite a bit of extra effort to write since you don't get the data in an easy to use format.

Edited by SimonForsman, 24 June 2012 - 02:11 PM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#17 DevLiquidKnight   Members   -  Reputation: 834

Like
-1Likes
Like

Posted 24 June 2012 - 02:34 PM

I think if you combined any of the techniques I mentioned, with a cheating detection techniques, and put as much data as possible on the server, the idea of hacking is impractical.

Edited by DevLiquidKnight, 24 June 2012 - 02:35 PM.


#18 hplus0603   Moderators   -  Reputation: 5734

Like
0Likes
Like

Posted 24 June 2012 - 03:09 PM

You can design it to prevent tampering of the client, a hardware dongle comes to mind.


Wow, we're really following this same trajectory again?

Each and every software application that has a hardware dongle is available in a cracked version.

If you sign a message using a hardware dongle, then there's still the question of where the message came from in the first place -- the user can feed whatever message he wants into the dongle, and have it signed.

The only way to avoid this is to have the hardware dongle generate the messages as well -- at that point, you have a closed hardware platform, like the Xbox. And, even there, there exists mod chips and hacks, which Microsoft ends up dealing with by detecting banning consoles, rather than trying to authenticate each message into each game server.

I'm going to lock this thread. This conversation has been had a dozen times, and you can just search through the archives for the various arguments.

enum Bool { True, False, FileNotFound };




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS