ToonTown and hackers?

I’m curious. Has it been stated before if ToonTown was developed with Python on the client-side?

Reason I’m asking… How do you keep people from hacking the client? I mean, anyone can just view your text Python files. Unless you have them compiled into byte-code and then shipped that way I guess.

Right, the files are compiled into byte-code and compressed into an archive. This doesn’t completely prevent hackers, of course; but nothing does–even a compiled C++ program is hackable.

We tried to engineer the game protocol between client and server so that if a hacker did gain access to the client program, he wouldn’t be able to do much damage to other people’s game experience.

David

Thanks David. That’s what I wanted to know. Still trying to find my way around Panda. Learning something new daily.

Yeah, the rule is: never trust the client. Everquest, Diablo etc were all client-hacked pretty quickly, even though they were in C/C++. From what Ive read its pretty easy to memory scan stuff, without understanding anything in the code at all.

Unless one was going to inline encryption/decryption for every data access, this is kindof tough to stop, since the value of, say, runspeed, is bound to appear in clear at some point in one’s program.

That said, as CPU’s become faster, I guess one could inline encryption/decryption for data read/writes. I just thought of this in the middle of this post, so I havent had time to think this through properly, but for example:


INLINE int ReadIntData( int &memvalue )
{
   return memvalue + 13;  // ROT13, for illustration
}

INLINE void SetIntData( int &memvalue, int datavalue )
{
   memvalue = datavalue - 13;
}

int iHealth.

Somefunction()
{ 
   SetIntData( iHealth, 50 );

   cout << "Your health is " << GetIntData( iHealth ) << endl;
}

Now it is true that the 50 is still in clear:

  • during the set
  • during the cout

… but its very hard to intercept these calls, and these values are not exposed statically in memory in the way that they would be if one simply set iHealth to 50.

Of course, theres probably still ways to expose this. Probably many values are static in memory anyway?, so the simple action of changing one’s health and watching which values change is probably going to give a lot of clues? :

  • watch which bits of memory are changing on a per-frame basis, from just moving around a little. These are primarily graphical; discard them.
  • change one’s health, watch which bytes just changed, and which didnt change before

In any case, back to reality, in any successful MMORPG, the rule is: anything on the client that can be hacked will be. That’s true for any client, in any language, closedsource or not. Thats also true for consoles, even though you cant actually easily access the OS, because you can run the game inside a VM.

Hugh

Client exploits generally fall into three categories. If you give a client authority for anything, someone will hack the client to alter it. If you give the client more information than it needs, and rely on the client to conceal that data from the player, it will be revealed. And your client is in danger of being macroed, proxied, or otherwise automated.

You can address the first two by following good practices in your design. The third problem may be easy - don’t make your game reward monotonous repetitive actions. It’s different if your game depends on quick reflexes and aiming - an automated client in this case ruins the game, and you have to depend on heuristic analysis to detect and ban cheaters.

Basically, when you design the client/server interaction (and you should design it before the project is underway), pretend that the client is being written by strangers, and assume the client may do anything, at any time, that your command set offers, and may reveal anything, at any time, that your server sends it, and there is nothing you can do about it.

That’s sound advice. I remember an MMO called Elemental Saga, where most everything was handled on the client. For a while most of the game was avoiding people using exploits. The worst one was where they set the power of a heal spell negative so that it could be used in town to kill people. And then they’d use it to kill the NPC who would rez players.

City of Heroes on the other hand did it right. The client only sends requests, and only recieves updates from the world. Everything else is handled by the server. A year into the game, the worst exploits found relate to balance problems, not hacking.

Sorry to revive an old topic, but I was about to ask a similar question.

This means converting multiple .pyc and .bam files into a single archive file right? And you can still run off of them without extracting them all onto the client’s harddrive right?

A single archive file would have several advantages. Besides looking more professional, it would discourage tampering. You could md5 hash the client archive file to make sure it hasn’t been tampered with when they connect to the server.

My question is, how do you do this? How do you compile multiple python scripts and .bam’s into an archive that you can still run without extracting?

Use the multify tool to build a Panda .mf file to store all of your bam files and their associated images. You can then load models from the .mf file as if they were on the disk by mounting the multifile, for instance by putting:


vfs-mount my_file.mf . 0

in your Config.prc file, or by using the command:

vfs = VirtualFileSystem.getGlobalPtr()
vfs.mount(Filename('my_file.mf'), '.', 0)

at runtime.

I believe the packpanda utility will bundle up all of your .pyc files into a single Windows executable.

David