Different banning method.

Make suggestions for improving one of the best games on the net!
ShadowSpectre
Private First Class
Private First Class
Posts: 19
Joined: Sat Aug 12, 2006 5:58 pm

Different banning method.

Post by ShadowSpectre » Sat Sep 08, 2007 6:33 pm

I have a novel banning approach that has been successfully used on other non BzFlag sites. It sidesteps the normal approach and is not IP address specific. It may be the only way to remove miscreants who do IP address jumping or simple name changing. I would like to share the info privately with a develloper. Please PM me and I will forward the info and concept.

User avatar
Macrosoft
Private First Class
Private First Class
Posts: 142
Joined: Fri May 04, 2007 2:21 am

Post by Macrosoft » Sat Sep 08, 2007 6:46 pm

this is an open-source game. anything that is added will be visible to everyone, so there's no use in hiding it
gazz: A bullet may have your name on it, but shrapnel is addressed "to whom it may concern".
http://bash.org/?785529

ShadowSpectre
Private First Class
Private First Class
Posts: 19
Joined: Sat Aug 12, 2006 5:58 pm

No hiding

Post by ShadowSpectre » Sat Sep 08, 2007 6:48 pm

I don't want to hide it, I just want it to go in the correct ear.

User avatar
Macrosoft
Private First Class
Private First Class
Posts: 142
Joined: Fri May 04, 2007 2:21 am

Post by Macrosoft » Sat Sep 08, 2007 6:49 pm

will this be useful to server owners too? or is it something that will only work on the forums
gazz: A bullet may have your name on it, but shrapnel is addressed "to whom it may concern".
http://bash.org/?785529

ShadowSpectre
Private First Class
Private First Class
Posts: 19
Joined: Sat Aug 12, 2006 5:58 pm

Concept

Post by ShadowSpectre » Sat Sep 08, 2007 6:52 pm

The concept is universal to the servers, similar to a version query but using a different signing technique. It can be instituted on the listserv level or on the individual server level using a simple but effective plugin possibly able to be implemented without the client's knowledge.

User avatar
blast
General
General
Posts: 4791
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Post by blast » Sat Sep 08, 2007 7:11 pm

ShadowSpectre, a lot of the main developers hang out on the #BZFlag IRC channel on irc.freenode.net (including myself).
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image

User avatar
AAA
Private First Class
Private First Class
Posts: 79
Joined: Sat Aug 07, 2004 3:36 pm
Contact:

Post by AAA » Mon Sep 10, 2007 7:09 am

You don't get the concept of open source, do you?
If your idea works, saying it here will greatly improve the chances of it getting added. If it requires secrecy, It will not work. Period.
Also, don't assume that there is only one type of client connecting, I have a BZFlag client written in PHP, and if the solution involves changing bzproto in any way, it can be spoofed. It can be spoofed to look like a new client on a new IP, it can be spoofed to look like a good client on a dynamic IP. It cannot be tied to an OS, BZFlag runs on Linux, Macs, its roumored it works on xboxes, a GCN, and my DS Lite (actually those just were April fools jokes). Reguardless, the proof of concept exists.
Admin and Senior Vice Executive Administrator of Network and System Architecture @ BZFX -- Core Admin @ CAN -- SF.net user diamondmagic -- irc.freenode.net nickname AAA_awright (#bzfx if not #bzflag)

ShadowSpectre
Private First Class
Private First Class
Posts: 19
Joined: Sat Aug 12, 2006 5:58 pm

Concept

Post by ShadowSpectre » Mon Sep 10, 2007 3:54 pm

I do "get" the concept of open source. I don't necesessarily understand every aspect, nor do I readily know the proper venue to field ideas or improvements. I'll devellop the concept a little more and then submit it. I've already floated it and everyone cries "it won't work". I remember so many other things that were said not to be able to work but actually do and are a part of our daily lives now.

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5193
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Mon Sep 10, 2007 4:00 pm

the geneal idea is that you can never trust anything from the client. ever.
ImageJeffM

ShadowSpectre
Private First Class
Private First Class
Posts: 19
Joined: Sat Aug 12, 2006 5:58 pm

Idea

Post by ShadowSpectre » Mon Sep 10, 2007 4:07 pm

Never trusting anything from the client as a general rule is ok. I do understand that. Some things can be trusted, though. Little things like the video card cannot be faked and still have it work; If the client says it is a GeForce it won't work on an ATI. The API's can be moved but still cannot be faked per se. It's little, subtle things I am looking to to identify the client. Proof of concept many times doesn't work in practical application, but reverse applies too. Proof of concept for defeat CAN be done but to be replicated easily and consistantly may prove hard. I think subtlety is the key here.

ShadowSpectre
Private First Class
Private First Class
Posts: 19
Joined: Sat Aug 12, 2006 5:58 pm

Yet another Idea.

Post by ShadowSpectre » Mon Sep 10, 2007 4:16 pm


User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5193
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Mon Sep 10, 2007 4:58 pm

actually we can't trust any of that data. They have the source. They can modify the code that sends us the data.

You have to remember that we have no way to ensure that the binary they are running is not one that they have modified. THAT is the nature of open source. The users are free to modify,compile, and run there own versions.

Any type of machine ID, binary key, or other client side identification can be circumvented simply by changing the data as it's sent to the server.

If you do a key, the user could modify the network code to send out a valid key, even on modified code. If you do some sort of hardware ID, they can just modify the data as it's sent.

the "spooks" you are talking about are dealing with closed source system, or crypto keys. We are not ether of those. Crypto doesn't buy us anything since we have to have our crytpto logic be "out there" in the client, and then they can hack it up.

You can't trust a client, ever. it's as simple as that. The problem that your focusing on is only a symptom of a larger issue, and any solution for it will simply be a minor patch.

There is a lot of work that can be done at simply having the server disallow most of the actions that are outside of the game rules, or probable human behavior, AKA, an authenticated server. If you minimize what the cheaters can do, they will get a lot less out of cheating and will impact the game a lot less.

The only other way to minimize your problem is to require authentication. We have a system for that in place ( ban by BZID ), but few servers are willing to go reg only. This will not stop them, it just makes it harder to come back ( go to site, fill out a form, get an e-mail, etc.. ) and should hopefully make that type of behavior more of a pain then it's worth.

We are hoping to have future versions be easier to register ( have the installer do it, have the game help you reg, etc.. ). Then maybe more servers will be willing to go reg only.
ImageJeffM

User avatar
AAA
Private First Class
Private First Class
Posts: 79
Joined: Sat Aug 07, 2004 3:36 pm
Contact:

Post by AAA » Mon Sep 10, 2007 11:05 pm

Clock skew, wow...
Unfortunately banning a system based on it's temperature is no use in BZFlag, when a system is likely to always be running at a maximum temperature. Most systems are behind a firewall, so we can't attack the cheaters/whoever.
Using time alone, though, seems interesting, because it has to be accurate to a certain amount to play BZFlag, it could be possible to create a very accurate fingerprint based off of the timestamps sent by the client. Purposefully trying to vary the timestamps would get you kicked due to jitter (if this system was set up properly). The fingerprint would not be perfect, but it would probably be more accurate then most host bans done today. Then you only have the issue of an attacker changing CPU's or computers.
Such a method would be *very* hard to implement, and I can't say it wouldn't create a problem for the BZFlag servers, which are designed to play nice with processing power.
Again, the whole idea is purely theoretical, and assuming it even works it would take me, and any other people who know algorithms here, several years of studying, plus hardware donations.
Admin and Senior Vice Executive Administrator of Network and System Architecture @ BZFX -- Core Admin @ CAN -- SF.net user diamondmagic -- irc.freenode.net nickname AAA_awright (#bzfx if not #bzflag)

ShadowSpectre
Private First Class
Private First Class
Posts: 19
Joined: Sat Aug 12, 2006 5:58 pm

Clock skew

Post by ShadowSpectre » Mon Sep 10, 2007 11:39 pm

Jeff shot the clock skew idea down as not feasable. Clock skew works even behind firewalls, regardless of type. Pretty scary. Even if it's not feasable it does get the gears turning. Keep in mind that evey device on the PCI bus has its own seprate clock crystal, potentially making many different measurement points.

User avatar
blast
General
General
Posts: 4791
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Post by blast » Mon Sep 10, 2007 11:40 pm

Again, it would be pointless to try something like that anyway. The client could just fake a new "fingerprint" on each join.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image

User avatar
joevano
General
General
Posts: 1863
Joined: Sat Jun 18, 2005 1:08 pm
Location: South Bend, Indiana, USA

Re: Clock skew

Post by joevano » Tue Sep 11, 2007 12:01 am

ShadowSpectre wrote:Jeff shot the clock skew idea down as not feasable. Clock skew works even behind firewalls, regardless of type. Pretty scary. Even if it's not feasable it does get the gears turning. Keep in mind that evey device on the PCI bus has its own seprate clock crystal, potentially making many different measurement points.
I guess the real point ShadowSpectre is how do you know that the client is sending you the real data, or just some random crap that fits the data profile? The hacker can see the code, figure out what the valid values could be, and just past junk that fits, without actually querying the 'crystal'. They would create a virtual, software only crystal, that gets called in place of the real code that calls the crystal? You have no control over the source code on the client end, it can be and is changed. As long as the data fits the expected values, the server would never know.

We would love to have a solution for this problem, and have looked for ages. Without a closed source system, it really is not feasible. The hackers can always see the code in open source, and with the code all things are possible on the client end. When the client sends back data, you can check it on the server. But as long as the values are within expected tolerances you have no way of knowing the validity of the data.
There is nothing worse than aggressive stupidity. -- Johann Wolfgang von Goethe
"How many legs does a dog have if you call his tail a leg? Four. Calling a tail a leg doesn't make it a leg." -- Abraham Lincoln

ShadowSpectre
Private First Class
Private First Class
Posts: 19
Joined: Sat Aug 12, 2006 5:58 pm

Skewing

Post by ShadowSpectre » Tue Sep 11, 2007 12:33 am

The neat thing about the clock skewing is that it can be done server side only, sort of like the autokick for tank moving too fast or for wrong end shots or no jumping. -They don't have to know what data is being scrutinized. What I was pitching was a totally passive approach. I think that anything modifying the client data to mask all unique parameters like the TCP encapsulation or the TCP timestamps would seriously slow throughput to the point that that too would be detectable, or even better make the game unplayable for the miscreant. I doubt it would take much processing power from the server. I think it could be done with a module that could be used like the record function, switched on by the admins to watch a particular player.

The worst problem here is that to implement hacks against the safeguards requires skill, knowledge and assumably, education and intelligence. Usually education is associated with higher morals and standards. I would like to think that even if such "speed bumps" could be circumvented that the person capable of doing so would be of high enough standard to voluntarily choose to not do so. It's a game. There is no money involved, no prize to be won.

User avatar
A Meteorite
Private First Class
Private First Class
Posts: 1786
Joined: Thu Apr 28, 2005 12:56 am
Location: California, U.S.
Contact:

Re: Skewing

Post by A Meteorite » Tue Sep 11, 2007 1:00 am

ShadowSpectre
I don't think you understand. "Modifying the client data to mask all unique parameters like the TCP encapsulation or the TCP timestamps" would not "seriously slow throughput," and, in fact, would most likely be faster than getting "unique parameters" (like clock skews). Giving the server fake, random clock skews would be even easier than us programming it to get it. Anything the client gives the server can be faked. Period. You can never trust the client.

The only way to fully implement checks is to have full server-side tracking. That means the server checks all input data and makes sure that it is within reasonable values of what it should be (meaning calculating tank paths, shot trajectories, etc).
ShadowSpectre wrote:The worst problem here is that to implement hacks against the safeguards requires skill, knowledge and assumably, education and intelligence. Usually education is associated with higher morals and standards. I would like to think that even if such "speed bumps" could be circumvented that the person capable of doing so would be of high enough standard to voluntarily choose to not do so. It's a game. There is no money involved, no prize to be won.
You'd be surprised how easy most circumventions are. They do not require much skill and the average Joe gets them from someone else. Even though money is not involved, there are people out there who get an adrenaline rush by causing agony for others. That's just how some people are.

Your intentions are great, but I don't think you understand the full implications of an open source game. Anyone can modify their client and send any data it wants. Making it send fake data is easy. Comment out the lines that get the "unique parameters" and randomnize your own "unique parameters" and send that instead. And heck, some people don't even use the BZFlag client. I know people who do, and I personally use, PHP bots that nearly implement the full BZFlag protocol (without the graphics).
ShadowSpectre wrote:The neat thing about the clock skewing is that it can be done server side only, sort of like the autokick for tank moving too fast or for wrong end shots or no jumping [...]
Eh? I know I outlined my points above, but I'd like to know how clock skewing can be be done "server side only." You must get the client's clock timing first to determine a clock skew. And like I said, client data can be easily faked.
Image
Owner @ BZFX
Core Admin @ CAN

Email me: bzmet…@gmail.com

User avatar
blast
General
General
Posts: 4791
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Re: Skewing

Post by blast » Tue Sep 11, 2007 2:05 am

ShadowSpectre wrote:The neat thing about the clock skewing is that it can be done server side only, sort of like the autokick for tank moving too fast or for wrong end shots or no jumping. -They don't have to know what data is being scrutinized.
The server is open-source too. So yes, they would know what is being scrutinized.....


Do you understand this? The source code for the entire game is open to anyone and everyone.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image

ShadowSpectre
Private First Class
Private First Class
Posts: 19
Joined: Sat Aug 12, 2006 5:58 pm

Scrutiny

Post by ShadowSpectre » Tue Sep 11, 2007 2:29 am

True, potentially they could know. Not necesessarily would know. You can't look out of every window of your house at the same time. One idea I had was to make a small file download mandatory for entry to a server using an aspx session. It could be a very small file, maybe 10 to 25k to probe for the system fingerprint. Make it a random file name and size. With locking handles on the file due to the fact it's being used it would be very hard to circumvent. Use random API's for the probe to obscure its behavior. This would not be a part of the source; this would be an individual file for use by the server, much like an image or texture or special flag file. How could they circumvent a mandatory download with a random name and random API with locking handles? You'd have to do it on a session by session basis; Too hard to bypass. The randomness is the key. This is how rootkits are detected and defeated. I think it could be implemented on a server as easily as a image or texture is changed to suit the mood of the server owner.

User avatar
joevano
General
General
Posts: 1863
Joined: Sat Jun 18, 2005 1:08 pm
Location: South Bend, Indiana, USA

Re: Scrutiny

Post by joevano » Tue Sep 11, 2007 2:37 am

ShadowSpectre wrote:True, potentially they could know. Not necesessarily would know. You can't look out of every window of your house at the same time. One idea I had was to make a small file download mandatory for entry to a server using an aspx session. It could be a very small file, maybe 10 to 25k to probe for the system fingerprint. Make it a random file name and size. With locking handles on the file due to the fact it's being used it would be very hard to circumvent. Use random API's for the probe to obscure its behavior. This would not be a part of the source; this would be an individual file for use by the server, much like an image or texture or special flag file. How could they circumvent a mandatory download with a random name and random API with locking handles? You'd have to do it on a session by session basis; Too hard to bypass. The randomness is the key. This is how rootkits are detected and defeated. I think it could be implemented on a server as easily as a image or texture is changed to suit the mood of the server owner.
OK. I see what you are saying here, but how do you persist this data across sessions? A person gets kicked/banned, removes the pic (or whatever) and rejoins. The file was no longer locked because the client wasn't in use. Can you explain to me how this works, I'm confused.

PS here is an interesting online discussion on Open Source and stopping cheaters http://www.gamedev.net/community/forums ... _id=368086
There is nothing worse than aggressive stupidity. -- Johann Wolfgang von Goethe
"How many legs does a dog have if you call his tail a leg? Four. Calling a tail a leg doesn't make it a leg." -- Abraham Lincoln

ShadowSpectre
Private First Class
Private First Class
Posts: 19
Joined: Sat Aug 12, 2006 5:58 pm

data persistance

Post by ShadowSpectre » Tue Sep 11, 2007 2:49 am

Knowing which file, with the file being randomly named may be difficult. That doesn't really matter anyway because if a new file is required to be loaded by the server the file will be replaced on the next rejoin, even for legitimate players. The best part is; Data persistance doesn't matter. They delete the file and rejoin, downloading a new file with a different name in the process. In fact, the file from the last join would be discarded anyway upon the next rejoin anyway, much like the billboards are on MoFo or when maps are updated. It doesn't have to be a secure session, either. The server can track the mneumonics of the ID just like an IP logger and deny entry, just like a bad token will from listserv. Bad tokens will let you login for a few seconds and then boot you. The same concept applies here.

User avatar
joevano
General
General
Posts: 1863
Joined: Sat Jun 18, 2005 1:08 pm
Location: South Bend, Indiana, USA

Re: data persistance

Post by joevano » Tue Sep 11, 2007 2:55 am

ShadowSpectre wrote:Knowing which file, with the file being randomly named may be difficult. That doesn't really matter anyway because if a new file is required to be loaded by the server the file will be replaced on the next rejoin, even for legitimate players. The best part is; Data persistance doesn't matter. They delete the file and rejoin, downloading a new file with a different name in the process. In fact, the file from the last join would be discarded anyway upon the next rejoin anyway, much like the billboards are on MoFo or when maps are updated. It doesn't have to be a secure session, either. The server can track the mneumonics of the ID just like an IP logger and deny entry, just like a bad token will from listserv. Bad tokens will let you login for a few seconds and then boot you. The same concept applies here.
OK. I'll play the stupid guy (mostly because I am ;) ). So how does the server know it's the same client? If it is random, how does it know this is the SAME client?
There is nothing worse than aggressive stupidity. -- Johann Wolfgang von Goethe
"How many legs does a dog have if you call his tail a leg? Four. Calling a tail a leg doesn't make it a leg." -- Abraham Lincoln

User avatar
blast
General
General
Posts: 4791
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Post by blast » Tue Sep 11, 2007 2:58 am

ShadowSpectre, I'm starting to lose track of what you're talking about. Mandatory file download? Dude, okay, the CLIENT has to do that, right? Again, the client could just ignore or fake that. You just don't understand this.

I'm really losing interest in this whole discussion.


(Side thought: Rootkits? If a system has a rootkit, you don't "defeat it". You reinstall the system from scratch.)
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image

ShadowSpectre
Private First Class
Private First Class
Posts: 19
Joined: Sat Aug 12, 2006 5:58 pm

Random

Post by ShadowSpectre » Tue Sep 11, 2007 3:11 am

The server will know it's the same client from a log left by the previous login, just like the IP log does when a person changes their signin name. It's not the fact that the filename is random; It's how the file does its job. It does it a slightly different way each time, much like variants of a virus evading detection. I wonder if you'd even have to change the API's since the filename changes. Remember that you don't have to score a direct hit every time. Even if it worked half of the time guaranteeing a positive ID it would work, if you wanted to play conservatively. This would be like dodging bullets; The miscreants could only do it for but so long, and their previous defence would not be valid for their next login.

Post Reply