Basic idea. Say for an mmo, the client does the majority or the work but stores/retrieves vital data from a server. Now this would ideally be sent via a highly encrypted tcp ssl connection. So I am assuming that the ssl connection makes it difficult to packet sniff packets and hence find out what bytes do what.

However before being sent over ssl, the bytes sent must at one point be put into memory, and memory can be read. I assume it's easier to work out what is being sent/recieved via packet sniffing than by trying to work out what is going on directly in memory?

From what I can see, with decompilers, dissemblers and a good bit of trial and error and perseverance, hackers can plough through memory locations to try and work out what bytes correspond to what aspects of the game and there is no way to prevent this?

Basic idea. Say for an mmo, the client does the majority or the work but stores/retrieves vital data from a server. Now this would ideally be sent via a highly encrypted tcp ssl connection. So I am assuming that the ssl connection makes it difficult to packet sniff packets and hence find out what bytes do what.

No, actually it's trivial. The client needs to know the decryption key to use that data at some point. Once the hacker has that, he can simulate your server sending data to his client to learn what everything does.

However before being sent over ssl, the bytes sent must at one point be put into memory, and memory can be read. I assume it's easier to work out what is being sent/recieved via packet sniffing than by trying to work out what is going on directly in memory?

Both are trivial, you can't trust the client.

From what I can see, with decompilers, dissemblers and a good bit of trial and error and perseverance, hackers can plough through memory locations to try and work out what bytes correspond to what aspects of the game and there is no way to prevent this?

Correct. You can never trust the client.

So I am assuming that the ssl connection makes it difficult to packet sniff packets and hence find out what bytes do what.

Not really. SSL, when implemented and used correctly, will make it so that someone out on the network cannot read your traffic, or impersonate one or both ends of the traffic. It does nothing for attackers that run on the client machine, or on the server machine.

However before being sent over ssl, the bytes sent must at one point be put into memory, and memory can be read.

That is correct.

I assume it's easier to work out what is being sent/recieved via packet sniffing than by trying to work out what is going on directly in memory?

Not really. If you make a game that is good, and that people will want to cheat in, then people will figure out how to cheat on the client. If you're at that point, you have to make sure that everything important is only decided on the server, and that clients don't have information they're not supposed to have.

The main challenge for 99.9% of all games, though, is becoming good and fun enough that people would care about them at all.

conquestor3 summed it up quite nicely. It boils down to sanity-checking everything you receive on the server-side. That will already eliminate most of the "important" hacks.

To prevent "visual" hacks, like wall-hacking in a shooter for example, you would ideally make sure that the client only receives data about the visible objects from his point of view. A hacker can still subvert the audio system and guess where the enemy is standing based on the last sound they emitted. Most games try to counter stuff like this by scanning the computer for publicly available hacks (e.g. signature-based) or common hijacking patterns (pattern recognition) which again eliminates most of that. Private hacks: not much you can do here.

In regards to (illegal) player movement, like teleporting or speedhacking: the server can drive the player movement, i.e. walk in direction XYZ with a given velocity. The client would then only receive and interpolate the position data. Some games didn't / still don't do this which means that the client is sending the player position data to the server. If that's the case, then you can try to use some heuristics to guesstimate how far the player is allowed to travel in a given time period in his current state: is he walking or is he in a vehicle / on a mount?

Hope that helps.