I think you guys are missing the point of what he is asking. He just wants to stop people from debugging the game. You don''t need to do all kinds of complex encryption crap to stop that. I''d suggest (1), make it so people can''t alt-tab or minimize the game. That way they won''t be able to switch to windows trainer creator, or whatever that use. (2) for people who have somethin like softice where it runs over the operating system, just make it so that the client drops them if a packet isn''t received for more than 30 seconds. If the guy can drop into softice, reprogram your crc checks, filter your data packets, setup break points and watches, etc, in 30 seconds he friggin deserves to cheat.

You could get around that if you have a second monitor that has a program running that just displays changes in memory. You''d then write down the address or the program could record it all to disk, you''d later write the program to hack it.

osmanb, I really doubt someone would be able to go through the entire assembly code for the game and pull out all the code for the encryption. If hackers were able to do that, they''d have all that source code they''re always asking for. Without sourcecode, it''s to difficult to figure out what every part of a program is doing.


E:cb woof!

It''s not that difficult, especially when you have tool like SoftICE, or any other debugger, that lets you view the assembly code as it''s executing. As long as you have an idea where it happens, you can wait, then watch. I really wonder how many times people need to learn the lesson that "security through obscurity" isn''t security at all. Even if only one person in 6 billion takes the time to watch your program in a debugger and figure out what your encryption algorithm is, you''re still screwed, thanks to this marvel of modern networking technology. Server side storage with minimum disclosure of information to the client is still the only way to insure protection.

-Brian

OK. OK.
I learned to hex edit buy hacking games. Unless you daon''t put anything in the client it is possible to hack. There is no way around it.

To the original poster:

From my experience with online multiplayer games i have learned one major rule: if the server ever trusts data from the client, there''s a security hole, and where there''s a security hole, there are exploits.

So, here''s my suggestion; keep all the data server-side. Now, i know you said that because of collision detection and other fun things, having the server figure everything out would just be insane, so here''s my idea, which may or may not work, based both on your type of game and on implementation.

Set up distributed computing to do your server''s number crunching. That is, don''t let clients do their own computations, have them do parts of others'' computations. That way, while there is still a security hole because the client may return the wrong data, it''s likely not going to help the client. In fact, it''ll probably just cause some weird affects. The way to get around this, if it turned out to be a problem, is let two clients do the same work, and then "investigate" if there are descrepencies.

Basically, by doing this, you''re removing any incentive to crack the client, so while general mischief making is possible, there''s nothing to be gained from it.

The obvious problem with this is that you can''t get twitch-game responses from this, but i image you could do a fairly good job, at least with some things. I originally thought of this for NPC''s in MMORPGs, but i thought it might be helpful.

Good luck, and don''t underestimate your users.

-Shelrem

What I''m doing right now is keeping my game data in variable states. At the beginning of the user''s data, I have a long integer with bits that can be set to indicate which part of the data is where in the file. Each time the program runs, it changes the format of the user''s data, retrieving different bits of it first.

This is crackable, but most likely the person will end up fouling up their own data. Especially if you use a complex method to hide the ''key'' integer.

A downside is that if you try to copy your data to another machine, it might not recognize the data, if it has a different key bit stored as current.

Another good method is to give all your game things variable length records, and adjust the length of those. If someone is gonna crack your stuff, make sure you give them a headache.

I also recommend putting stuff in so that if you DO detect cracked data, don''t tell the user that their data is bad... just do rotten things to his character, such as making it impossible for the character to hurt other players. This way, they''ll never know if they''re up against security, or ruined something when they edited the data.

It also depends on how much processor usage you don''t mind using on it.

If you had a variable data stucture, dummy blocks (real data but in pointless bits of the unused data structure) and if you are game, checks to make sure that the last segment written was the same read, and then a nice amount of hefty encryption on the saved files, you can get away with it pretty well by confusing the hell out of most people. If anyone is still game, they will sit their and pull your program apart to find out what you did, but most will just give up before they get that far.

The majority of copy protection and encryption are more deterents than preventions.

Collision detection is not necessarily necessary to do completely server-side.
In Ultima Online (and probably others, UO is the only one I''ve been "in the guts of" for writing an emulator) collision detection has 2 levels.

1) Client attempts to determine if the desired square has a "fixed obstacle" (an obstacle part of the original game, such as a shop in a town)

2) If there is a fixed obstacle, no movement is registered and sent to the server.

3) If there is no fixed obstacle, the client "appears" to move, as a request is being sent to the server to move to the desired square. The timing on this fluctuates. In times of extreme lag, the compensation is a little off and the player''s character will appear to "snap back" to where it was if an obstacle encounter is returned by the server. This is called the "rubber banding" effect and is extremely annoying.

4) The server returns a go/no go to the client and the move is complete.

Note that the server is aware of the collision map that the client holds as well, and if the client is modified in an attempt to change the collision map, the only result will be more lag for the would-be cheater.

This approach appears to be relatively efficient, though it does cause lag in areas where there are many characters and moveable items present.

-fel

I don''t think that just trying to protect the game data will ever work as eventually people will crack it.

Instead have you thought about storing the history of the data, (including values and events that change the values) and the current data on the server, as well as having a copy on the local machine, and then doing a comparison every minute or two?

You didn''t give details of what the game was like, but lets use a Diablo type game as an example.
When the player logs on, his current game stats are initialised from the values stored on the server. He then goes to find a quiet corner to hide in while he edits his stats.

When the server does the next comparison of his stats it sees that the values have changed and the server doesn''t have any record of why they have changed so it can label him as a cheater.

Of course this means that the server has to record all the game events that can change somebodies stats (and all the random numbers that might be used in the calculations.

That shouldn''t be too large an amount of data to send over the network, but it could be quite a bit of programming to do if the variables are spread out over the whole code.

Danack@codemasters.com

If I were you, I''d take a look at what has been done with Netrek. It''s a client/server game which has been around for ten years plus, and has quite a few features to help combat cheating. Considering the source for the client and server is publicly available, it''s probably worth a look.