Secure Server

the less the client knows, the less the client can do, which is the less the hacker can do, which in turn means the less a legitmite player can do. for instance (ignore reasonable cpu constraints and bandwidth, though not to absurtidy), assume your server handles ALL movement and tells the clients the position of players that he can see only. the client can ONLY send:
move direction, look direction, shoot. the client MUST recieve positions of players in order to find them to attack or have any fun at all. well now mr hacker also knows basically everything the client knows (the degree of knowledge is only dependent on the dedication of the hacker). therefore if a player can turn to shoot at an enemy. the hacker could create a program that would turn the player automaticlly and lock onto the enemy. there is little you can do about this.

just follow the golden rule. NEVER trust the client. unfortunatly you will have to trust the client to a point if you want the player able to do anything at all. sending the clients prerendered frames is not an option, though probally the closest you will get to a NEARLY unhackable system. for a truly unhackable server, it must never exist in the first place. also the more burden you place on the server, the more data that may have to pass between the client and server thus killing gameplay.

you do realize that hacks exist for counter-strike dont give the players abilities that the client cant normally do in game. though the player cant actually aim perfect the client has no trouble telling the server "i am aiming at x, y, z coordinate", since the server must accept. though constraints can be enabled, it would degrade gameplay.

Gang Wars has all of about 10 different packets it''ll accept. Each packet is assigned a type number which the client and server use to interpet the packet data.

switch (msg.type) { case 1: break; ... default: //report bogus message type break;

That knocks off bogus packets right there. The way on-line games are compromised is by using manipulated valid packets. Or by breaking into the server computer to grab usernames and passwords.

To keep valid packets types from having bogus information you require the client send up generic information. For instance, the player clicks on an item on the map. Don''t send up the item to add to the players inventory. Send the map coordinates the player clicked on. Have the server check what was there and react accordingly. Have the client only send the coordinates if it thinks something is there. That way you reduce bandwidth use. You could also do a distance check to make sure the client is in range of the item so they aren''t trying to pick something up that they can''t actually see.

Basically both do a share of logic but let the server make the final decision.

Depending on how you design your packets encryption would be very easy. Currently mine are just obscure and generic but adding encryption would be easy.

Ben

quote:

---

Original post by robirt
I read an article about making secure encrypted packets to stop hackers and saying they can be reverse engineered, so it is impossible to make a unhackable game, but you still try to make it difficult.......... I want to know if i will still need encryption.

---

If it has a key it can potentially be "hacked". CounterStrike does have "hacks" now. Such as seeing through walls and knowing the location of everyone.

Encryption will help but problems such as lag might pop up if your server has a big job of decrypting packets.

Maybe create a check to see if any thing out of the ordinary popups up. such as high stats or 50 kills in 5 mins and give them a kick. this will make it where even if the person changes something .. it can only go so far before becoming 'superman'-god-like-hacked status.

I am not too much into networking code.. but that's my 2 cents

just a late night thought.
good night



Edited by - GoofProg on January 12, 2002 4:57:59 AM

Hi,

We''ve had an interesting discussion about this last year, it lists many options which you might want to use. Check:

http://www.gamedev.net/community/forums/topic.asp?topic_id=59559

HTH,
Almar

Taking the example of Half-Life nobody has reverse-engineered its networking protocol to write a cheat yet - all cheats are based on code manipulation. And HL doesn''t even use an academic encryption technique!

Also, please read my first post in the thread posted by ajoling. Categorizing different kinds of cheats really simplifies the discussion.

cu,
Prefect

I just skimmed over that thread again, and I realized that one thing wasn''t really mentioned: Cheat detection vs. cheat prevention.

Basically, cheats cannot be prevented, you can only make it harder to cheat. However, once you know about a cheat out there, you can _detect_ it. You would then have to punish the player, ideally by locking them out of the game forever on a global basis.

This would require your game to have a central server which authenticates globally unique IDs - think Won IDs in the Half-Life case. The problem is that players might be able to switch those IDs: In the Half-Life case, the WonID is some kind of a hash of the CD key, and there are long lists of CD keys out there (if not a key generator).
Using an email-address won''t work either, for obvious reasons.

One must find a way to make this unique ID valuable. The ideal way of doing this would be a global ranking system, so if you created a new account for yourself, you''d have to start from 0 points again, and you would never be able to reach the top of the ladder.

cu,
Prefect

ok, i get it. but, then if it is a game which players do not win by controling their player the best, it shouldn''t be able to be hacked.

So, if my game is an rpg, players will not be able to cheat at all as long as i remember not to trust the client. But, my game does include action combat. Now, i don''t know what to do to stop cheaters. I guess i could change it a little and make it more rpgish. It might even make it more fun. I''ll figure it out through some trail and error.

BTW, why would counterstrike have cheats that let you see through walls. I know it does, but shouldn''t the server only send you the location of players you can see? It seems like a security flaw in the design. I asume the reason is to let you see a player when you run around a wall without receiving a server upate, but i think security is more importan than supporting slow modems. But, maybe thats just me. I really hate cheaters and software pirates and people like that.
-Robert

"TW, why would counterstrike have cheats that let you see through walls. I know it does, but shouldn''t the server only send you the location of players you can see? It seems like a security flaw in the design. I asume the reason is to let you see a player when you run around a wall without receiving a server upate, but i think security is more importan than supporting slow modems. But, maybe thats just me. I really hate cheaters and software pirates and people like that."

I believe it was more an option in a certain OpenGL driver, it''s like turning Wireframe redering on instead of solid faces.

Well, it''s not that easy. First of all, anyone can have a high ping, not just slow modem users.
If you play the TFC map well, you can experience what happens if players around the corners aren''t transmitted with <100 pings.

And even if everybody had a ping of 0, it wouldn''t be so easy. Determining the visibility of entities isn''t as easy as it sounds. Quake engine types use the PVS check for this, which is extremely fast, but rather rough. You might want to add to that check by tracing a line from the player''s viewpoint to the target entity, but that''s a rather difficult job, because you have to account for fine gratings, etc...

Of course, in an ideal world you''d just render the player''s view on the server and stream it to the client - but we all know that''s not an option

cu,
Prefect

Hmm, I actually might try such a system once for fun, using a pretty good compression over the images, like PNG, it might work pretty good for "no very fast updating games"

Coolest thing is you only code some input system, and no graphic data is needed on the client side