Cheat prevention

#1 Only provide the dso files when releasing a game. dso's are compiled scripts (p-code.)

#2 Don't give trust the client on anything it tries to tell the server, make sure all the goodies are server side, adds a little overhead now but prevents alot of headaches later.

#3 After I get used to the engine, I plan on implementing a unique verification procedure for use in the games I make and I'll most likely be able to refine it as a patch for Torque for the rest of the community. This will essentially place a unique, coded thumbprint on all associated files, allowing their use privately, and also, since it'll be merged with the relative data structures of both the client and server, will be flawless in it's hack/cheat prevention. Granted, there's still plenty of research I need to do in order to make it feasible (as well as plenty of Torque studying I need to catch up on), and then there's the fact that, if it works and is as invisible as it's supposed to be, that, if in the wrong hands, it could be catastrophic, I think I may have my work cut out for me! ;)

But, we'll see what happens...

R304X01 1415 320X345Y
4EU3C9A AAGW 9ZU4E3WX
90R2)9T0T4050RURI0251
D (! 2M MBY5 F ( !5K

- Ronixus

#4 Tribes 2 had very few real cheats, as all player movement, position, inventory, weapons, weapons fire, etc was handled by the server.

The cheats that did exist would bypass the shape validation so things like the Flags would be 200 feet tall, etc.

#5 Christopher: Signatures of files are not very secure at all, especially when someone can just falsify them (eg: they send the correct ones even for bad files).

#6 Picture it like this:

Pretend it's like a puzzle of sorts - most of the script is actually quite normal, but the values in it are dependant on other placeholder values, which are being generated in a specified random pattern that's hidden by the encryption. The encryption (de)compiler code is even hidden from the client, forcing it to use the server to help it to reconstruct it before it's placeholder values can be set. If any of this chain is broken (hacked), the values will become corrupt and the program will recognize this and shut down. The server would also be able to recognize this as well, telling us who's trying to hack it! ;)

Programs are pretty much just alot of mathematical equations, making their output an exact science. If we know there's a limited outcome, then we can make a hidden value a requirement. This also shouldn't require much for resources to do in realtime, either, making it that much more of a flawless, unhackable program.

"Why make it complicated, then try to simplify? I say we make it simple, then complicate things!"

- Ronixus

#7 People have tried similar techniques before - what generally happens is the cheaters use a program to attach to the process and set the proper check values in memory directly, instead of relying on the game's own calculations.

#8 Fundamentally, the person with physical access to the hardware has full access to your product. Your only protection is the time required to determine how the cheat protection works. That means that anti-cheat technology must constantly evolve to conceal that which the cheat writers have revealed.

For Torque, with its ability to run on open operating systems like Linux, the vulnerability is increased because the tools to crack the cheat protection are much more powerful. (I like the fact that Torque builds on Linux, but I recognize the cost of that capability.) One could also use virtual OS hosting like VMWare and WINE to crack a game client. These effectively hide the cracking tools from detection by the client code.

So the question becomes, what can you do over time that's time-intensive in reverse-engineering? How can you make your release cycle shorter than the cheaters'?

#9 Yes, I've seen and played with a few of those as well, but what I'm talking about would severely limit the ability of those types of hacks. That's why it works the way I'm making it.

If the values are only present in encrypted form, how can anything other than the server-client link decrypt them? Unless you knew how to get to those values and what they are and the fact that they are always going to be realtime random number sequences for the placeholder values, I don't think that leaves much room for anything to crack them.

I just have to concentrate on making the code more random itself. I wonder if anyone can crack the message above? ;)

- Ronixus

#10 I believe what you're describing is "challenge-response". It's like using the game server as a modern remote dongle. Take a look at the methods used to crack dongle-protected software.