Some weeks ago I was discussing with a few friends about whether or not it was possible to secure a completely open source game (an FPS specifically) against cheating. I'll focus this discussion on FPSes because they are historically the most cheat-infested and because they offer up a number of interesting challenges in ways that people can cheat. When I asy "completely" open source, I mean that no closed source components are allowed. We cn't rely on a magic closed source black box like PunkBuster to fix things for us. Now source code merely facilitates seeing the behavior of a program, but it makes what might be an eventual achievement on the part of a reverse engineer doable almost immediately. First, let's quickly take a look at the ways people have historically cheated. Wallhacks are one that are fairly striaghtforward; for games built on the HL1 engine for example, the OpenGL dll can be trivially hooked -- a few tweaks to rendering modes, and suddenly players are visible through walls. Another simple kind is to ues custom models, particularly simple with games that are built to be moddable. Simply use a player model which is larger than normal (a "spike" model for example) and hiding in weird corner spots becomes ineffective. Another thing that's been done on occasion is to use hacked video or mouse drivers to gain an advantage; these methods are less relable but largely undetectable. The most powerful and most complex hacks are highly intrusive, going directly into the process memory, interloping in-between game dlls, or otherwise dipping deeply into the system to control and rewire it. The usual approach to preventing these measures has been to use client side code, either as part of the game itself or as a seperate process, that attempts to detect these hacks. Scanning for video DLLs in non-standard directories, signatures of known evil processes in memory, seeing if a sketchy "debugger" has attached to your game, or looking for weird system-wide hooks. Many of these methods are largely reactive, since they rely on known evil signatures, not unlike a virus scanner. A quick look at games nowadays makes it clear that these methods are of limited effectiveness, as it's a constant fight between the game developers trying to detect evil programs and the hackers trying to evade detection. Open source makes this a basically useless approach, since your scanning methods are easy to see and thus blocked without that much difficulty. (For example, memory scans can be deftly cut down with clever virtual allocations and tweaking of page access permissions.) We can't even checksum anything, because our checksumming code is open source and we can't guarantee that it's doing what it's supposed to and not simply returning what it already knows are the correct results. Without getting deeper into that discussion, suffice to say that it is impossible to completely prevent cheating without resorting to psychotic measures like RSA encrypting every frame on the server, sending it to the client, allowing only trusted drivers, etc. Even then it might not be possible (theoretically speaking) to guarantee that the player is not cheating without using a TPM. The approach up to this point has been to make cheating a general pain, and that's worked to some extent but not really. If you know where to look, a cheat for any of the popular FPSes can be picked up easily. So if the situation is hopeless, why am I posting? Well, when I originally discussed this with my friends, one of whom is a specialist in this sort of security, we couldn't figure out any kind of client-side undefeatable system, and the truth is that there probably isn't, and you can probably prove that there isn't. You guessed it, we move to the server side of things. The key point is this -- we only need to identify a cheater and ban his ass; it's not necesary to make it impossible to cheat. The server is open source too, so technically there's no reason somebody can't modify the server to allow cheating. But since the server sets the rules to begin with, that's not a problem. What we need to do is to detect all forms of cheating on the server. I believe this is possible and reasonable to do, although it's likely to be somewhat CPU intensive on the server. Enter HackCam. The idea is that the server has at least as much information as any client has. Obviously some of this information wil be difficult to get (we can't afford to render every client's screen on the server and run image analysis on every frame, for example). However, the server should be able to do at least enough analysis to throw out obvious cheaters, and the discussions I've read of HackCam indicate that it is fairly good at identifying cheaters even amongst pro-class players. If we have a level where a considerable amount of visibility precalculation has been done, then the server could conceivably run very fast queries as to whether or not it is possible that one player knows the presence of another. Certain behaviors can then be identified as suspicious, and we can mark players who accumulate a lot of suspicious activity with some kind of likelihood of cheating. (Bayesian techniques might assist accuracy as well.) Speedhacks are easy to catch. Wallhacks are more difficult, but the HackCam interview suggests that it's entirely in the realm of possibility. Examination of a player's behavior could also identify use of aimbots and the like. I don't have the AI background to know how much of this is possible, but the things I've heard and see about HackCam are very heartening. It turns out that we get a number of interesting benefits from this kind of analysis, rather than simply attacking the programs involved in cheating. For one thing, players are now allowed to modify any part of the game code, including the rendering system. I can write up a new shader for players or walls or whatever and use it, and as long as the shader doesn't cause me to be able to see things I shouldn't, it's perfectly alright. Also, a few oddball brands of cheats can now be picked up. The one that comes to mind is "ghosting", the process of using out-of-game voice-chat and a spectating and/or dead teammate to give you extra information about what is going on. We're no longer reacting to cheats that appear; instead of blacklisting the illegitimate, we are whitelisting the legitimate. There are disadvantages as well, of course. For one thing, implementing this kind of an intelligent analysis system is probably not easy. There's a fair bit of temporal information required, and the player needs to get the benefit of the doubt in all cases. We have to deal with crazy cases where the player may not have been cheating. For example, the case of the rifle barrel stick out past the end of the box is going to be difficult to detect, but the case where the rifle barrel was sticking through is going to be a hell of a lot more irritating. Also, this method is likely to only catch the outright cheaters; people who are using more subtle configurations (an aimbot with a visibility of 2 degrees, for example) are going to be difficult or impossible to seperate from the legitimate players. So, as far as replies from you guys go I'm looking for a couple different things. If you want to challenge me and say that client side prevention is possible, go right ahead -- I'll enjoy tearing you apart [grin] I was quite irritated with the prospect that cheating might actually be literally, provably impossible to prevent, and server side heuristic analysis provides what seems to be a way out, though again I don't know how challenging it will be to implement or how well it will do in practice. If anyone's attempted something like this bfore, I'd love to hear about it. In the end, I just want something interesting to read and ponder on as a response to this thread/rant [smile]

You can totally make a hackproof game like this:

Client:
-get keyboard input
-send keyboard input to the server
-get jpeg(or equivilant) screenshot (prevents texture swapping)

Server:
-get keyboard input from all clients
-maintain all game information
-send pixel information to each client for every frame

Sarcasm aside :) Closed source games can't even be secured, so why would open source games be able to?

Quote:Original post by DrEvil
Sarcasm aside :) Closed source games can't even be secured, so why would open source games be able to?

The whole point of my post was that they can't be secured, and more importantly that it's not necessary to secure them.

Quote:The key point is this -- we only need to identify a cheater and ban his ass; it's not necesary to make it impossible to cheat

You see, the problem with this in an open source environment is that it probably didn't cost them anything to get that account and it won't cost them anything to get another. In fact, even if you IP ban or MAC address ban them, there are ways around that which serious griefers will use. If you somehow get a hardware profile of their system that might work, but if you can't trust a client about their cheating or not, how can you trust that they didn't fudge the profile?

Basically, your system is not secure and can not be. You can't secure against cheaters and you can't even ban people who do cheat. Worse yet, they have the source code and can probably come up with some really creative hacks (more easily than without source certainly.)

Steam and Battlenet are workable systems for one (and only one) reason. You have to purchase a game and that game is attached to one account. If you get banned on that account then you're fuck out of luck unless you buy another copy of the game for 50 bucks or whatever it's worth. This is a very strong deterrant against hackers because they are not being IP banned or anything to do with their computer. It's a ban completely against their ID that they had to purchase to play with. Unfortunately free games do not have this same luxury of personal investment with accounts and thus do not carry the same weight in a ban.

The fact that the person has the source code and can compile a new client means that they can very simply return whatever response that will make the server happy there is nothing weird going on when in fact there is.

Hmm, that's a fair point. Even if we identify a cheater and throw them out, they could come back 10 seconds later as someone else (and maybe with a seperate IP and even Mac address).

I've got nothing for that one. I'll have to think on it.

Have them accept an agreement when they create an account that says that a virus will unleash on their computer if they cheat. If they cheat, unleash a routine that clears the BIOS and screws with the low-level-formatting on their HD.

I believe I have the (an) answer to your problem.

Quote:Original post by Promit
The key point is this -- we only need to identify a cheater and ban his ass; it's not necessary to make it impossible to cheat.

I think you need to take this a step further than you have. It is neither necessary to make it impossible to cheat, nor necessary to detect/ban cheaters. It is necessary to make cheating pointless.

As an example, take a look at wall-hacks. By whatever method the wall-hack is achieved (clear walls, spiked models, etc.), the point is that cheaters are obtaining information they shouldn't have. There is a 100% fool proof way to prevent all wall-hacks, and that is simply not to send the client information he shouldn't have. If the server is not sending me the locations of players I shouldn't be able to see, I could hook the OpenGL dll and stick spiked models everywhere, and I still wouldn't be able to see anything I shouldn't.

As another example, take a look at speed hacks. With proper sanity checking server side (or one of a few other solutions) they become a non issue.

I believe that a well designed game will be immune to hacks by nature, not because it has any kind of active cheat prevention or detection, but simply because it was designed to render cheats useless in the first place.

So I think you should reconsider your anti-cheat approach to one of making your game immune to hacks by design, rather than one of trying to tack on cheat prevention/detection after the fact.

Quote:Original post by dwelty
As an example, take a look at wall-hacks. By whatever method the wall-hack is achieved (clear walls, spiked models, etc.), the point is that cheaters are obtaining information they shouldn't have. There is a 100% fool proof way to prevent all wall-hacks, and that is simply not to send the client information he shouldn't have. If the server is not sending me the locations of enemies I shouldn't be able to see, I could hook the OpenGL dll and stick spiked models everywhere, and I still wouldn't be able to see anything I shouldn't.

But you need to transmit players in the vicinity anyway for correct sound playback. In CS, sound can be critical to what you do and can tip you off as to what's going on behind a wall or a box. You have to send those positions, and combined with a quick tweak that renders the positions of sounds, you've got a decent wallhack/ESP right there.

Speed hacks, on the other hand, I never understood why they were possible in the first place.