• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Xanather

How to verify as a valid client?

17 posts in this topic

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?
0

Share this post


Link to post
Share on other sites
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...
0

Share this post


Link to post
Share on other sites
[quote]How would i go around making sure only real clients can connect who have the correct client software/application? [/quote]

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

Share this post


Link to post
Share on other sites
[quote name='hplus0603' timestamp='1340519314' post='4952246']
[quote]How would i go around making sure only real clients can connect who have the correct client software/application? [/quote]
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.
[/quote]
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
-2

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='DevLiquidKnight' timestamp='1340522300' post='4952252']
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.
[/quote]
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)
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='SimonForsman' timestamp='1340526644' post='4952257']
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)
[/quote]
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.

[quote name='Prefect' timestamp='1340525622' post='4952254']
Cryptography isn't some magic dust you can sprinkle on your game to make it have whatever property you like.
[/quote]
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 [url="http://en.wikipedia.org/wiki/Digital_signature"]http://en.wikipedia....gital_signature[/url] before assuming I don't know what I am talking about. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Edited by DevLiquidKnight
-1

Share this post


Link to post
Share on other sites
[quote name='DevLiquidKnight' timestamp='1340536919' post='4952282']
[quote name='SimonForsman' timestamp='1340526644' post='4952257']
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)
[/quote]
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.

[quote name='Prefect' timestamp='1340525622' post='4952254']
Cryptography isn't some magic dust you can sprinkle on your game to make it have whatever property you like.
[/quote]
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 [url="http://en.wikipedia.org/wiki/Digital_signature"]http://en.wikipedia....gital_signature[/url] before assuming I don't know what I am talking about. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
[/quote]

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
0

Share this post


Link to post
Share on other sites
[quote name='DevLiquidKnight' timestamp='1340522300' post='4952252']
Otherwise eCommerce would be impossible.
[/quote]

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

Share this post


Link to post
Share on other sites
You can design it to prevent tampering of the client, a hardware dongle comes to mind. Edited by DevLiquidKnight
-1

Share this post


Link to post
Share on other sites
[quote name='DevLiquidKnight' timestamp='1340565639' post='4952401']
[quote name='SimonForsman' timestamp='1340550234' post='4952328']
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)
[/quote]
Combine it with a unalterable hardware dongle.
[/quote]

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
0

Share this post


Link to post
Share on other sites
[quote name='hplus0603' timestamp='1340563851' post='4952392']
Did you not read, or not understand, the argument?
[/quote]
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
-1

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='Prefect' timestamp='1340566840' post='4952408']
All the things you mentioned are hurdles. They do slow developers of cheats down.
[/quote]
How would you design a cheating system if all your being fed is image data such as on-live?
0

Share this post


Link to post
Share on other sites
[quote name='DevLiquidKnight' timestamp='1340567023' post='4952409']
[quote name='Prefect' timestamp='1340566840' post='4952408']
All the things you mentioned are hurdles. They do slow developers of cheats down.
[/quote]
How would you design a cheating system if all your being fed is image data such as on-live?
[/quote]

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
0

Share this post


Link to post
Share on other sites
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
-1

Share this post


Link to post
Share on other sites
[quote name='DevLiquidKnight' timestamp='1340565639' post='4952401']
You can design it to prevent tampering of the client, a hardware dongle comes to mind.
[/quote]

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

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0