Re: [GD-General] opensource for online play

[Tom H. <to...@3d...>]

At 02:14 AM 2/10/2003, you wrote:
>Hey all.
>
>We've been slowly setting up the inner workings of the network play for 
>our engine. One thing that has come up is the fact that our engine also 
>happens to be Open Source, so how do we deal with security issues for 
>hacking online games when we are giving the hackers all of our source code.

I don't believe an OpenSource FPS can work without rampant cheating.

Let's say you're smart enough not to put any kind of authority for 
movement, heath, hit/miss, etc on the client. That means that you have to 
validate everything that comes from the client. Source code validation of 
any kind (CRC, run time code queries, whatever) just won't work so let's 
assume for the moment that you do as much client validation as is 
reasonable on the server in an attempt to identify hackers. You have limits 
because you have to deal with fairly high latency players with packetloss 
problems and slightly out of sync clients. This slack and the fact that all 
rendering is done on the client opens the door for some fairly serious 
hacks that would destroy gameplay for non-cheaters.

The following things are what I would hack if I wanted an unfair advantage 
over others, and you'd be practically unable to detect it without hurting 
legit players:

1. I'd use partial transparency on the walls to uncover hidden opponents... 
and thus be able to track them and shoot them the second they became 
"visible". You can address this by only sending position information from 
the server on people that are actually visible, but that has implications 
for shadows, sounds, and other things that happen outside the direct view 
of the client but still require the client to know the position of. It also 
means that people would "pop" into view when they came around a corner due 
to latency issues.

2. I'd use auto-targeting to always get a head shot. Basically, when I 
fired I'd look to see what targets were close to what I was shooting at, 
then orient the player to make a head shot right before the "fire" packet 
was sent out. Even a 10% improvement in targeting here can make a HUGE 
difference and could be pretty damn hard to catch on the server.

3. I'd perturb the player position .. basically makes the player hop all 
over the damn place so others can't target him, but within a small area 
that should be within normal "jitter" for a low latency/lossy connection to 
make detection more difficult. However, the real player would be running at 
full speed and clean. You can attempt to catch this by comparing jitter to 
latency/packetloss, but those things can also be simulated on the client 
with ease and still allow the client to make sure the "important" packets 
(the ones when firing happens) are correct and fast.

These are only a few things that I could think of off the top of my head. 
I'm sure players would find a ton more things to screw with. In short, it 
isn't about security as much as it is about players being able to take the 
information you give them and gain an unfair advantage over other players.

Basically, once you hand the player an executable they can hack the hell 
out of it to do what they want, but there's at least some limits and 
difficulties involved because they have to shoehorn whatever they're doing 
into the base executable. Any new executables mean the work has to be 
repeated. Once you hand them the source code, things become an order of 
magnitude easier for them, and your ability to stymie their efforts becomes 
significantly harder.

Tom