Is ET is a lost cause?

The last few weeks we had serious problems with mostly cheating nazis on our server, and somehow I feel left in the lurch by PB. As far as I can see, there are only two things in ET Punkbuster that are still reliable: IP range bans work, and PB GUIDs are not arbitrarily fakable, cheaters can only get random new GUIDs.

Apart from this, everything else is not really effective anymore:

* vote kicks / kicks: when our regulars try to votekick the cheaters, they can rejoin immediately, although neither their IP nor their GUID changes:

Quote

When I joined the server and had someone votekick me it worked - I had to wait several minutes before I could join again, so there's no configuration mistake.

* bans: most cheating kiddies can be scared away with bans, but especially the quoted cheater from above from the IP range 84.160.*.* is not impressed at all - new GUID and that's that. We soon started to use IP bans (without saving them in the config), but he came back whenever the server was restarted. Now I've put the range into the config, that keeps at least this guy away. A fast grep through our shrubbot.cfg shows that there are about 50 bans within that IP range... We're lucky that there seems to be only the cheater from this range, there are no other regulars within there.
Today I wanted to ban a regular who greeted the nazis with "HEIL HITLER" yesterday (noticed that in the log; we're collecting IPs and nazi says because we're thinking about reporting this to the police). Of course he was back within 5 seconds, explaining he only wanted to "pose" as a nazi so they wouldn't kick him. I banned him again, and after 5 seconds he was back in the game. IP ban's not possible because there are several players from his range, so there's nothing I can do. I somehow have the urgent need to bang my head repeatedly against a wall.

* minguidage: I understand that ET is rather problematic because there are no CD keys, and banned cheaters can easily get new keys from the master server. I don't understand though why EB is completely unable to make minguidage work again - it once worked and the mechanism is both uncrackable (because it works completely server-sided) and extremely simple to implement. Just have a database on the master server that records the date when each CD key was issued, and there is your GUID age - servers could request that info and thereby kick cheaters who deleted their etkey. Combined with a mechanism that allows only one key per IP per day to stop cheaters from getting hundreds of keys at once, this would be wonderfully annoying for cheaters.

* hardware GUIDs: I dunno. Did they ever work? If yes, why can't we use them to ban players from our server?

Next to PB, there is etpro IAC. Let's see how it performs...

Quote

That's a folder containing 139 log files, each for one day, dating back into august 2007. In an old backup, we have another pile of 97 log files, dating from 04/2007 to 07/2007... no hits. In an even older log, ending in 04/2007 and being 560 MB big (we weren't using logrotation back then, so I don't know when that log started; if I assume an average 5MB per day, that would be about 112 days):

Quote

So essentially, etpro IAC is as abandoned as PB - it once worked, but isn't worth a penny today. Wonderful.

Oh, and etpro GUIDs. I guess there's no need to tell anyone that they're crap... cheaters were actually using them against us - they faked our own etpro GUIDs and made us ban both their worthless faked PB guid, and our own etpro GUIDs. My clanmates panicked because they thought cheaters were able to actively ban them, until we figured out what was happening and fixed the etadmin_mod to ignore etpro guids completely.

So, to sum it up, we as game administrators are rather fucked up. Why are we still fighting this fight, when all the responsible companies are showing the white feather?

Part of the price you pay for playing a free game. Active Admin can do some damage against hackers by streaming, and by uploading pbss and demo's here along with the appropriate log information from your pb folder, and this does make it much harder for the hackers to play their game.

Grabbing a new GUID in ET has always been a problem as it's a free game, and the GUID is generated from the master server, as you've stated. That's something you've got to be willing to deal with, though.

Being patched to 2.60b will help to some degree, the larger number of hackers reside in the 2.55 version of the game that is plumb-full of security holes and other exploitable bugs within.

Helmut Honigdachs, on Dec 25th 2007, 05:51 PM, said:

I am not sure how that works in etpro, but other mods set a default amount of time to temp ban a person after a kick. This is usually user-configurable. If you don't have that option in etpro, etadmin_mod provides this feature - [link=http://kmod.quakewarsterritory.com/index.php]kMod[/link] might also; it's an add-on for etpro.

Helmut Honigdachs, on Dec 25th 2007, 05:51 PM, said:

What config is this? Again I am not that familiar with etpro's behavior - are you saying it autoclears that list each restart? If so, try putting the IP/GUID bans in your pbbans.dat file.

Helmut Honigdachs, on Dec 25th 2007, 05:51 PM, said:

Mute him & abuse him as much as possible. Eventually it is likely he may get bored and leave. Yes, this is not really a solution, per-se, but it does tend to work. If your other players are regulars & you know them well, perhaps you can range ban for a week or so & let them know what is going on before hand & hope they'll understand.

Helmut Honigdachs, on Dec 25th 2007, 05:51 PM, said:

minguidage as I understand it was a test implementation from the get go. etadmin_mod did have this feature but from what I've heard, it is buggy & guidages are not always reported.

Dedicated asshats also tend to age their guids & keep a nice stash ready to get around features such as these - so it's not as helpful as it seems at face value.

Helmut Honigdachs, on Dec 25th 2007, 05:51 PM, said:

Whether they were ever of any use, I do not know. I do know, however, that they are essentially useless now. The etpro team (bani himself iirc) has stated that "etpro guids are buggy & should not be used". They are easily spoofable and it is also possible for multiple machines to get the same GUID - most famously - any Win98 install on any machine gets the same guid - & while banning all win9x users may not be a big loss percentage wise, you get the idea of the reliability of etpro guids.

These are the only GUIDs for ET that are hardware-based that I know of, unless you are referring to information used for PB Global Hardware bans, which is not available to end-users & is only done on their end.

Jaymod has added the function of MAC address banning since one of the 1.5 (what became 2.0) betas & this, though also spoofable, adds another layer of complication to cheaters' efforts to come back, increasing the odds you may bore them into leaving (and also probably foiling a percentage of cheaters who simply do not know how to bypass them)

Helmut Honigdachs, on Dec 25th 2007, 05:51 PM, said:

From what I've heard the entire etpro project is abandoned. With regards to PB - what do you mean? Minguidage aside, PB is updated quite frequently for ET and it should be noted as EvenBalance have stated before, you do not always need a new 'full-blown' PB update to detect cheats - alot of that is done on their end with little to no notification (as it should be). PB Server v2.0 has just been rolled out for quite a few games & et is one of them.

Helmut Honigdachs, on Dec 25th 2007, 05:51 PM, said:

apparantly i wasted my time typing the etpro guid speech above ;P

Helmut Honigdachs, on Dec 25th 2007, 05:51 PM, said:

imo, EvenBalance has not shown the 'white feather'. I hate to think about what the ET scene would be like without PB. It's simply harder to manage these things in a free game then in a for-pay one w/ cd key & that, essentially, is the price you 'pay'.

ET is a great game, and we put the effort into it because we want to see it prosper & be a fun environment - you are not alone, either in your efforts or frustrations - don't give up .

Please forgive the lengthy post; I've put down a lot of info just in case it might help others still running public ETPro servers.

This thread is a couple of weeks old now, but I sympathised so much I felt like posting. Nothing much has changed since I was actively adminning an ET server about a year ago. I thought I'd share some info as to how I made it as difficult as possible for cheaters to bother my community and regulars on our ET server.

Nothing beats having an actively adminned server, and I suppose I was quite lucky that I had so many refs who were all willing to take time out from their games to deal with cheaters. However, since we ran an ETPro server I was able to automate some useful processes and add a bit of functionality using Lua scripting. I've tried to summarise here some of the most useful features of the scripts I used.

1) Automated guid checking
All connecting players had their etpro and cl_guid (=cloned pbguid unless spoofed) submitted to basic tests (etpro guid should be 40 hex chars, cl_guid(pbguid) 32 hex chars). If they failed these basic tests they were immediately kicked with one of a few automated messages. The messages never mentioned anything about the guid, they were silly messages to try to convince the cheater he had some other problem e.g. "The instruction at 0x00000000 referenced memory at 0x00000000. The memory could not be read." This script might be a little less effective now since a number of such scripts have been published and the cheaters are a bit more wise to it.

2) **New Guid To Server checking**
This was perhaps the most effective measure despite its simplicity. ETPro guids are unreliable, and pbguids for ET are but a console command away, plus the minguidage functionality has long been broken. I created a script that collected and stored a list of pbguids of all players that connected to the server. If a player connected and his pbguid was already on the list, he could join a team and play immediately. If not, his guid was added to the list but the player was forced to sit in spectator mode for a time before he could join a team (I used 2 minutes). What this amounts to is essentially a kick-time that cannot be bypassed. A kicked player (who generates a new guid to get around the kick) can connect again but is disallowed from joining a team. Relatively few would see out their time and most would mooch off pretty quick (probably to try another server).

The downside is that it applies to every player that connects, so there was a bit of whining occasionally from players new to the server. It doesnt sound like much, but I found this script to be quite powerful, making the pbguid for ET a useful admin tool again.

3) Auto-kicking of aimbots
I didnt publicise this one much, I thought it was better kept a bit hushhush. One of my scripts monitored players and collected statistical data of their shooting. After a good bit of number-crunching, I defined a threshold that was pretty much impossible for a human player to achieve (short of shooting at a number of stationary targets). The script was then set to automatically kick players who exceeded this threshold. Although not perfect (the script does NOT detect cheat programs, it simply measures end-effects), any cheaters who tried to come on with their aimbots turned up to the max would be kicked quite quickly. This script was intended as a minimum level of protection for when no referees/admins were around. However, it would frequently kick aimbotters before any admin actually online even had a chance to react.


4) Additional ref commands
After a while, I pretty much stopped trying to ban cheaters and instead would play around with them using some additional commands from another Lua script. The best of these was undoubtedly the !disarm command, which allowed me to set all of a client's ammo to zero (constantly refreshed, so respawning or picking more up doesnt help). It was particularly satisfying to see so many aimbotters made impotent, and was a great source of laughs for the admins and indeed my regulars who knew what was happening when they saw that command being used. Some would reconnect and try again, but the command was much more successful at keeping cheaters away than any number of kick/ban attempts.


My server was ofc streaming to pbbans, which in itself gives a good level of protection against cheaters. However, despite the good protection, the banlists are much lower impact for ET due to the availability of new guids. The good news though is that the "New Guid To Server" script I wrote worked nicely with the pbban system since the cheater would have to create a new pbguid to attempt to reconnect, and hence be subjected to a wait-time. Its not much, but it was about the best I could manage.

Its sad I know, but nothing is going to change with regards to the pbguid system for ET, and the PB hardware ban system is for PB only to implement. If any of the measures listed above are of interest to you then please feel free to get in touch and I can give access to any of my scripts not published on the wolfwiki.

Edited by mcsteve, Jan 8, 2008 - 02:06 PM.

I had one idea.
Run a separate site which would handle etkey registration that would communicate with Hub.
It could provide etkeys in following ways:
1. One key per account
2. Make a third party program which would tie etkey to hw guid.
3. Selling etkeys
4. Bind etkey with registered username(http://evenbalance.com/index.php?page=registry.php)

Hub could query this site and kick players with unknown guids. It would be also possible to check guid age.

The 1st possibility is the easiest but the least effective

The 2nd one is in theory the best one but it would require third party program that would communicate with the registry. Sooner or later it would be cracked and bypassed.

The 3rd one is good but not sure if would be legal.

The 4th one is the best for practical implementation. It would make et non-free game and thus reduce cheating. And all money would be for PB.

Chris64, on Dec 26th 2007, 01:46 PM, said:

As I said, usually this works in ETPro, too. The cheaters just seem to have found a way around that. kmod and etadmin_mod won't help much, because they have to rely on the GUID.

Chris64, on Dec 26th 2007, 01:46 PM, said:

Bans of course get stored permanently, but due to the availability of new GUIDs they're not of much help anymore. IP bans are not permanent as long as we used the etadmin_mod command "!banip 80.160", and I finally put it in the server.cfg then. That's what I wanted to say

Chris64, on Dec 26th 2007, 01:46 PM, said:

Well, !disarm from mcsteve sounds like a funny idea

Chris64, on Dec 26th 2007, 01:46 PM, said:

Yes, it was, but I can't understand why they actually abandoned it. The idea seems just so simple and error-free... detecting new hacks may be complicated and hard work, but storing GUID creation dates is not. It just doesn't make any sense.
etadmin_mod relied on this PB feature, so without the PB support, etadmin_mod won't do anything.

Chris64, on Dec 26th 2007, 01:46 PM, said:

I already wrote about that in my original post
Combine it with an only-one-GUID-per-IP-per-day mechanism, and maybe a CAPTCHA, that will make GUID stashing hard work.

Chris64, on Dec 26th 2007, 01:46 PM, said:

Yeah, I was thinking about the real PB hardware GUIDs. I know that global hardware GUID banning is only for EB, but local hardware GUID banning should be possible too, IMO.

Chris64, on Dec 26th 2007, 01:46 PM, said:

It would definitely increase the odds, but it has to be done on the client side, via mod code. We would have to wait for bani to put it in ETPro...

Chris64, on Dec 26th 2007, 01:46 PM, said:

Yeah, you're right, it is being updated. I just have the feeling sometimes that it's not enough; the cheaters are making the game unplayable, and EB seems to be too slow to stop them. OTOH, there are many VIOLATION (MULTIHACK) #70476 bans in my ban list here, so it detects the hack. If there would be just a sensible GUID mechanism now, there would be no problem.

mcsteve, on Jan 8th 2008, 08:02 PM, said:

I see that this is integrated in your gwrev script, though it only warns, it doesn't kick if I get that right. I have no idea about lua, could you update that script so automatic kicking is configurable?

mcsteve, on Jan 8th 2008, 08:02 PM, said:

Cool! It's like kicking reversed - instead of forcing a known bad GUID to wait, we force all unknown GUIDs to wait, only excluding known good GUIDs. Due to the fact that there are unlimited GUIDs available, and cheaters can easily get new ones and thereby circumventing the wait time, this is absolutely the way to go in ET and maybe simlilar free games.
I see that this feature is integrated in the gwrev script too, but as far as I can see, it lacks the feature to store good GUIDs in a file, thereby forcing players to wait everytime even though they may have waited before. Could you add that to the script too? I'd then activate the wait feature and set the time to 5 minutes
Until then I'll leave it disabled, my admins will have to be content with !gwdisarm and !gwown

mcsteve, on Jan 8th 2008, 08:02 PM, said:

Our regulars will understand that, they know that we are trying everything possible to keep their gameplay cheater free.

mcsteve, on Jan 8th 2008, 08:02 PM, said:

Although I'm not that much into autokicking because of too high accuracy, I guess it may be worth a try as long as the treshold is high enough. It won't kick for high mortar/grenade/satchel/dynamite/mine/panzerfaust accuracies I guess?

Please send me that script via PM. I could post them in the restricted SGA-only forum, too, if you want.

mcsteve, on Jan 8th 2008, 08:02 PM, said:

Oh yeah, I'm looking forward to test these

mcsteve, on Jan 8th 2008, 08:02 PM, said:

I think I have an idea there... we could make minguidage work again for servers that stream to the PBBans hub. Instead of using the real GUID creation time from the master server (that is not available to us), we just use the time when the PBBans hub saw the GUID for the first time. It could work like this:

1) Player joins a streaming server.
2) The hub notices the player by scanning the PB logs; it looks into it's database, determining whether it knows the player for at least X days. X could be configured by every streaming game admin in the configuration panel; the feature should be of course disabled for every server by default, so every admins has to enable it himself and also set X. I'd go for 7 days.
3) If the GUID is too new, the hub would use it's rcon rights to either kick the player or force him to stay spec.
4) If the GUID was still completely unknown, the time between join and kick should be long enough for the hub to store the player in it's database, so that the GUID can then age.

All regulars would not be affected, because they're already known to the hub. foxdie, what do you think? Is this realizable? I'm not sure whether the PB logs contain all the neccessary information...

Edited by Helmut Honigdachs, Jan 10, 2008 - 05:57 AM.

Helmut Honigdachs, on Jan 10th 2008, 11:56 AM, said:

Yes it is. But it would eat up too much resources.

foxdie, on Jan 10th 2008, 11:59 AM, said:

Bummer. And if we would make that a premium service, so it would cost admins a few euros if they activate it?

Helmut Honigdachs, on Jan 10th 2008, 12:27 PM, said:

We are non-profit organization. We can't earn any money.

All possibilities are above.

@ Helmut

Most of the scripts I used to provide the features I spoke about were not on the wolfwiki. I've had a bit of interest in them in response to this post, so this weekend I'll find some time to document them properly and stick them up on my webspace.

The auto-kicking of aimbots script is very limited in its application, partly due to the way it works and partly because I made the threshold very high to virtually negate the occurence of false-positives. I was always hoping the next ETPro would be released and contain a fix for a broken function in the Lua api so that I could write a much more robust version. Unfortunately, it seems to be the case that ETPro development has long since been closed.

Thanks to all who got in touch, I'll post again with a link soon.

Ok, couple of scripts up on the webspace now.

knownguidsv1.lua
botdetectv3.lua

There is a bit of an issue with the knownguids script, which I will fix now that the script is being published. Might take another couple of days since I'll have to set up a server on a spare PC for testing.

Please note that if you run an ETPro server, I highly recommend using "combinedfixes.lua" by ReyalP, which prevents a variety of exploits (including an ETPro guid check).

Thanks Steve

WL - BaZ, on Jan 14th 2008, 04:44 PM, said:

I can only second that, these scripts are great!

If I find the time, I'll add name to ID translation to gwrevv3.lua...

Finally got around to updating the script. Now it will not add a new guid to the list until the client joins a team after the wait-time is up.

knownguidsv2.lua

edit: links changed, go here instead.

Edited by mcsteve, Mar 24, 2008 - 07:01 AM.

Thanks again Steve

Bumping an old thread, however the solution to all your problems is to run Jaymod 2.x.x series, MAC address bans work... for an hour.

With regards to votekicks, everybody should know how to get around those by now, c'mon.

iGod, on Feb 11th 2008, 11:12 AM, said:

Thats interesting, because I never got that to work on the firewall. Your thinking inside the box, one of the benefits of running a server from home is that you get to administer the firewall, if a ban within the framework of et doesnt stick, id bet one on the outside firewall would. Kinda works the same way as subnet banning, but with a little more control. Most dynamic ip i see latley are varied on the the last 2 strings likw 82.24.x.x, now if you know the range your hack connects from, you can instruct your firewall not to ban the entire subnet, but a particular range.
just my 2 cents, I know that hosting companies dont do this.

It works from on my server and is extremely effective. Subnet bans (The ones via PB, however) are not at all effective as they arn't kicked/disconnected immediately, which I don't really understand...

The only problem is that (strangely) some people (like myself) don't send the MAC address to the server, so it just shows up as blank, honestly don't see how it's possible.

iGod, on Feb 11th 2008, 12:23 PM, said:

On the firewall. Is there a set way of banning just the mac address in jaymod? Cause I thought it was part of the mod that it just showed up on the banlist. I understand if the mod is using all of that info for banning, just never saw it work that way.