gamedevlists-general

RE: [GD-General] Galaxy HQ, major trouble

[Gareth L. <GL...@cl...>]

Ok, this is not funny anymore.

I think he is "playing"
http://www.pbm.com/~lindahl/pbm_list/descriptions/galaxyng.html

Please stop.

> -----Original Message-----
> From: Steven Webb [mailto:st...@ba...]
> Sent: 09 February 2003 19:38
> To: gam...@li...
> Subject: [GD-General] Galaxy HQ, major trouble
> 
> 
> 
> O wise leader your mail did not contain any orders.
> Remember orders start with,
>  #GALAXY <Galaxy Name> <Nation Name> <Password>
> and end with,
>  #END
> 
> Your orders have been discarded!
> Please correct the mistake and retransmit your orders.
> 
> 
> GalaxyNG release-5-0g, March 2001.
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

RE: [GD-General] Galaxy HQ, major trouble

[Brian H. <bri...@py...>]

He's been unsubbed, no worries -- we have the technology =3D)

On Sun, 9 Feb 2003 20:07:57 -0000, Gareth Lewin wrote:
>Ok, this is not funny anymore.
>
>I think he is "playing"
>http://www.pbm.com/~lindahl/pbm_list/descriptions/galaxyng.html
>
>Please stop.

[GD-General] opensource for online play

[Mike W. <mi...@ub...>]

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.

We've decided that the network side of things will be a .lib that we 
distribute, along with the source, for people that need to recompile the 
engine....most users don't, so this is no big deal...
 
This still leaves us with the problem of having someone create a stub 
exe using our network lib to create hacker tools mind you...

i've considered having some kind of 'GUID' or 'security passcode' that 
the game needs to validate, almost like the WonID system, only for the 
game itself, before the game server lets the client connect...

Perhaps some sort of time/date stamp authentication, along with a check 
of the exe's size (to make sure it's not hacked), etc...but overall, 
none of these systems seem to respect our 'open source roots'...

My company is moving into the position of being the sole administrators 
of the 'master servers' for the entire engine, as such as are setting up 
the master servers, chat/lobby servers and the like, as well as 
providing game server hosting for developers that are looking for 
affordable game server hosting (and publishing)...anyways..

i'd like to balance somehow the security issues (which proprietary 
closed source games can't seem to handle, let alone open source ones) 
with the open source traditions of our engine.

any suggestions on ways to proceed?  the GUID seems to be the most 
common sense method, but anyone with a hexcode reader can grab the GUID 
(and any kind of 'hard-coded' password that we include in the exe) and 
defeat the system...

anyone else been through this before and come up with any solutions?

the engine is called 'reality factory' - site is at 
http://rfactory.uber-geek.ca

screens of the multiplayer maps in action - 
http://www.uber-geek.ca/games/turing/ctf/

anyways...i'm curious how (if) people have managed this before, and what 
techniques they've used to provide security for your client applications...

cheers

mike w
www.uber-geek.ca

Re: [GD-General] opensource for online play

[Mads B. D. <ma...@ch...>]

On Mon, 10 Feb 2003, Mike Wuetherick wrote:

> 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.

This have been discussed extensively on the LInux game related mailing 
lists. The consensus seems to be that there is no way you can protect your 
game, wheter closed or open, if you place any trust on the client. Open 
source in general makes it easier.

> 
> We've decided that the network side of things will be a .lib that we 
> distribute, along with the source, for people that need to recompile the 
> engine....most users don't, so this is no big deal...

If you have the stuff in a single file, you actually make it easier for 
the cracker.
>  
> This still leaves us with the problem of having someone create a stub 
> exe using our network lib to create hacker tools mind you...

Yes, not to mention intercepting system calls, using a scripted debugger, 
etc etc.

> Perhaps some sort of time/date stamp authentication, along with a check 
> of the exe's size (to make sure it's not hacked), etc...but overall, 
> none of these systems seem to respect our 'open source roots'...

And are easily fooled both for open and closed source.

> screens of the multiplayer maps in action - 
> http://www.uber-geek.ca/games/turing/ctf/

this gives a 404.

> 
> anyways...i'm curious how (if) people have managed this before, and what 
> techniques they've used to provide security for your client applications...

I am sure some will have more constructive answers than mine, but I 
believe it boils down to minimize the trust in the client.

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
The low quality of [MP3] files should prevent this format from threatening
control of our intellectual property. Why would anyone listen to a sub-CD
quality song when they can easily buy the CD at the local Tower Records?
                               - RIAA head, Hillary Rosen, March 1997

Re: [GD-General] opensource for online play

[Mike W. <mi...@ub...>]

Mads Bondo Dydensborg wrote:

>On Mon, 10 Feb 2003, Mike Wuetherick wrote:
>
>  
>
>>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.
>>    
>>
>
>This have been discussed extensively on the LInux game related mailing 
>lists. The consensus seems to be that there is no way you can protect your 
>game, wheter closed or open, if you place any trust on the client. Open 
>source in general makes it easier.
>  
>
this is pretty much what we've come up with as well...somehow to make 
the clients a simple 'dumb terminal' that renders instructions sent to 
it by the server...

>>We've decided that the network side of things will be a .lib that we 
>>distribute, along with the source, for people that need to recompile the 
>>engine....most users don't, so this is no big deal...
>>    
>>
>If you have the stuff in a single file, you actually make it easier for 
>the cracker.
>
very good point...i'll pass that on to the programmers (i just come up 
with the dumb ideas and try to get them to make it work ;)

>> 
>>This still leaves us with the problem of having someone create a stub 
>>exe using our network lib to create hacker tools mind you...
>>    
>>
>
>Yes, not to mention intercepting system calls, using a scripted debugger, 
>etc etc.
>  
>
yeah it's not that difficult to do if you are really looking

>>Perhaps some sort of time/date stamp authentication, along with a check 
>>of the exe's size (to make sure it's not hacked), etc...but overall, 
>>none of these systems seem to respect our 'open source roots'...
>>    
>>
>
>And are easily fooled both for open and closed source.
>  
>
yes i would imagine, but it seems that valve and other companies do this 
type of thing with their games as at least a 'deterent' type of 
prevention...however 'effective' it might be...

>>screens of the multiplayer maps in action - 
>>http://www.uber-geek.ca/games/turing/ctf/
>>    
>>
>this gives a 404.
>
hmm...oops

www.uber-geek.ca/games/turing/screens/ctf/

forgot a directory in there.

>>anyways...i'm curious how (if) people have managed this before, and what 
>>techniques they've used to provide security for your client applications...
>>    
>>
>
>I am sure some will have more constructive answers than mine, but I 
>believe it boils down to minimize the trust in the client.
>  
>
yeah, i agree.  we'll have to focus specifically on this during the 
initial design...

cheers,

mike w
www.uber-geek.ca

Re: [GD-General] Galaxy HQ, major trouble

[Colin F. <cp...@ea...>]

I guess that was the first time a game generally
started to develop on the general game development list.

Still, I'd be a little afraid to turn down messages from
"Galaxy HQ"...  It just seems like we might one day
miss a legitimate e-mail from Galaxy HQ, and maybe 
not know about public hearings concerning the Soylent
Green rollout plans, manditory "renewal" celebrations
at Carousel when our lifeclocks reach "Red 6", and 
possibly zoning decisions for Vogon interstellar
freeways.

Okay, okay, I'll just put the aluminum foil back
on my head and tape an "X" on the window...
I can't HANDLE the truth!





































.

Re: [GD-General] Galaxy HQ, major trouble

[Mike W. <mi...@ub...>]

lol

good point...might want to turn down that mail filter setting, just in 
case...

Colin Fahey wrote:

>I guess that was the first time a game generally
>started to develop on the general game development list.
>
>Still, I'd be a little afraid to turn down messages from
>"Galaxy HQ"...  It just seems like we might one day
>miss a legitimate e-mail from Galaxy HQ, and maybe 
>not know about public hearings concerning the Soylent
>Green rollout plans, manditory "renewal" celebrations
>at Carousel when our lifeclocks reach "Red 6", and 
>possibly zoning decisions for Vogon interstellar
>freeways.
>
>Okay, okay, I'll just put the aluminum foil back
>on my head and tape an "X" on the window...
>I can't HANDLE the truth!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>.
>
>
>
>
>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Gamedevlists-general mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
>
>  
>

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

Re: [GD-General] opensource for online play

[Mike W. <mi...@ub...>]

Tom Hubina wrote:

> 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. 

i agree, which is why i was asking the question ;}

> 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

could see this being pretty useful though...hmm....

> 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.

this is a problem we run into on our counter-strike servers all the 
time...only the ability for an admin to shadow players seems to be an 
effective counter...

> 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.

good point...

> 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.

on thing i'm sorta hoping is that the hacking community won't be as 
interested in creating hacks for the game based on the very 'ease' of 
doing so...what fun is it to hack something that is handed to you on a 
plate like this?  

of course, this is mostly delusional, but can't hurt to hope ;}

one article that has been a major motivation to this line of thinking is 
this:

http://www.gamasutra.com/features/20011226/fitch_pfv.htm

thanx for your opinions...

mike w
www.uber-geek.ca