My question would be would it be possible to Encrypt the Data before it is sent to the client, so he/she cannot alter the data. Is the data already Encrypted? I am looking for a encryption method so people cannot just when sending data, such as bullet HIT_LOCATION, theres a couple, L_ARM, R_ARM, HEAD, CHEST, L_LEG, R_LEG. I wouldnt want them to make something such a program to go, if->Certain Spot switch it to, head. Which head is instant kill. Any ideas?

You can encrypt or obfuscate packets, sure. But it won't achieve what you want.

Regardless of the strength of the encryption of the data, the data is on the client machine. If your encryption is too hard to crack on its own, the hacker will just wait for you to decrypt it for him in your game code and then intercept data there.

The solution is to not trust the client. In a client/server model this is easy -- simply have the server verify that everything the client does is legal. This will make it possible for the client to hack his own copy of the game, but none of the things he does will affect anybody but him, which will cause him to become out of sync with the real game and drop or die.

It's a little trickier in a peer-to-peer relationship, but you can get pretty clever with it.

Alright well, would it be possible to kick the player from the Server? Like if he trys editing memory, would it be possible for it so see that the Client wasn't trying to edit memory, and a outside program not Verified under the Check,
CHECK is the (Checking Program) Client Hash Encryption Clear Kick. Kicks a user if something wouldn't be right. Could I use like tokens, the server has a token every 5 seconds it automaticly generates, and every time the user trys to do something it requires a token, the client would store the token, the server would

Like a certain 5 second it would be like 8390, the user would try to get a ammo pack/healh pack, the server would would give the health packet a certain variable token

Packet A -> Generated 5.4 MS, RESPAWN H_Packet 2 min.
That would be Health Packet a it came into the World in 5.4 ms, and would come back after it was used in 2 minutes, the server would give it the token 8390, and it would connect to the CHECK SERVER. And every 5 second it would get a new id, ONLY for the health packets, the health packet would meet a certain standard while ammo packets would have to meet a different requirement. Now that would be good. That would be a proffessional way to do it. Since a fps, doesnt require much bandwidth I could do it for anything that would affect the player, I wouldnt want the player to get a health packet worth 1000000, health, I could also probally sent a constant for MAX_HEALTH. But still if the health pack was only worth 25 health, you would want him to change it.

This is all starting to make sense. I am going to make a method.

Thanks, reply with any suggestions,

We discussed this in #gamedev, but to reiterate: this will not work because you are still trusting data from the client. You're suggesting encoding some kind of rotating hash inside packets that the server can check to see if the data was modified, kind of like a CRC.

The problem with this is that the client must, by definition, always know the correct number to hash into the packet or it will be unable to do so, and can never send valid packets. The server has to update the client with the new hash when it rotates (or the rotation can be done client-side only via an agreed-upon algorithm, but either way, the client must know it). And if the client knows it, the hacker knows it and can send it.

This obfuscates things, certainly, but it is still vulnerable. It's just a deterrent, and a poor one. You'd be better off designing the protocol the way we discussed in IRC, where you send basically only user input from the client. This eliminates huge swaths of vulnerabilities (although not all of them).