mcsteve

Just to elaborate a little, an MD5 is a little calculation that gives files a (more or less) unique signature. PB has access to all files within the game directory and can check not just for files of a particular name but also their signature. This can help to find out if a game file has been altered/tampered with. Most people will have the files et.exe and etded.exe (the dedicated server executable), and some servers do MD5 checks on those files. People switching between different versions of ET (2.55, 2.60 and 2.60b etc) will have different versions of et.exe, and sometimes just the one version of etded.exe (since they probably wont use it). Hence connecting to a server with multiple versions of the et executables (often renamed) may get the client kicked if PB finds a version of et.exe or etded.exe with the wrong MD5. Long story short, dont worry about MD5 mismatches unless you see a violation turn up on the banlist.

You haven't identified what about my previous post you consider nonsense. Freely available cdkeys do indeed serve little purpose, I never asserted anything to the contrary. As for MAC address, again at no point did I suggest it changed each time the client connected to a server. Perhaps I left too much ambiguity in my post, and I can see that this could well be the case seeing as how this thread is in the context of kicking/banning specifically in ET. I was talking more about the general principle of client identification, and how given the availability of the following information; cdkey (and subsequent guid); IP; MAC address, the cdkey represents the most technically challenging to spoof and the most costly to change in the normal situation where game distributors charge money for the privilege. In the case of ET, the cdkey loses its cost to change and hence becomes a very weak client identifier. Roadwarrior has vouched for you and so this gives me confidence that you are a nice chap and the pewpewing of my post was just down to a misunderstanding. I hope I helped to clear it up.

If this is indeed the banning functionality in Jaymod, then only the MAC address is additional to that already available in PB. Additionally, banning by MAC address will not be effective against any internet users other than those who have ISPs that require them to connect with the same MAC address each time. CDkeys represent the closest we can practically get to unique identifiers for clients, hence why the gaming industry chose them as the preferred method. Anything else is inferior (currently, and likely to be the case for the forseeable future). The availability of free cdkeys for ET could be described as a curse, but dont forget that they were a blessing in the first place.

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.

Deffo WH, shameful that he made no effort to hide it even when he was aware he was being specced.

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

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

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.

Note though that "ignoring MD5 queries" is due to communication problems the vast majority of the time. It is nothing to worry about.

http://www.pbbans.com/forums/index.php?sho...c=25268&hl=

First things first, update your profile plz, it took me a while to track down your current server IP and find out what mod you are running. You should definitely perform the following steps: 1) Change your rcon password, ideally to something that scores "BEST" on the checker below: password strength check 2) Change your ref and any semi-admin passwords; 3) Subnet banmask this person for a minimum of 1 month. How to banmask with PB: i) Find the player's IP from your PB logs ii) Open up rcon and type "pb_sv_banmask abc.def", where abc.def are the first 2 fields of his IP e.g. if his IP is 213.200.95.43, then do "pb_sv_banmask 213.200". There are a couple of known vulnerabilities with even the 2.60b ETDED server. It has not been widely publicised for obvious reasons, and I'm not going to mention them here just yet. There is a fix however, and I'm currently looking into the most appropriate way of promulgating the information. Once I've done a couple of quick checks, I shall pm you the fix. This patch should really be advertised openly so that server admins can patch, as was the case with 2.60b. The SGA forums should be an appropriate place to start doing this, but I'd like to check with the head PBBans chaps before I post. If you really want to take things as far as possible, note that if this chap is crashing servers then it counts as a DOS attack, which is illegal (in most countries anyway). Do a WHOIS lookup and find the contact for reporting abuse. Follow guidelines on how to submit evidence to the ISP which they can then take forward. This can be a time-consuming business however, but you have this option if you wish to go down that road.

There is no real way to ban someone in ET, even a subnet ban can be bypassed. ET is a free game, and new cdkeys can be obtained at any time. With a new cdkey comes a new pbguid, hence banning by pbguid is of limited use. As for the screenshots, the first is due to a common bug with nvidia cards. As for the 2nd one, again this is likely to be nothing more than a graphics issue.

B97C7A333674024F9684702275CEE50E58268194 - ETPro guid, PBBans do not deal with these 80c1a44561e17585f39325a6af9c5681 - PBguid which is on the banlist, the YAWN facility has linked this pbguid to the above etpro guid you mentioned. All I can say for sure is that the pbguid above is on the banlist. ETProguids are unreliable and can be spoofed, pbguids can not. If you wish to use data from YAWN, that is up to you.

I dont believe PB has the ability to monitor and kick for change frequency of any setting except playername. If you are really determined to restrict this, it *may* be possible with LUA. However, I notice your servers are etpub and LUA only works with etpro (update profile btw :) ) You say you have players zooming in and out whilst firing. I was just wondering, how do you know and do you think it gives them any advantage? I know some people use a toggle to change between FOVs for long and short range shots, is that what you mean?

et.trap_SendServerCommand(victimnum, string.format("cpm \"" .. killername .. "^7 had^o " .. killerhp .. " ^7HP left\n")) That's the line I use in my hpannounce script. The message is sent as "cpm", which appears to the client only on the left hand side of the screen. "cp" will print it in the middle, which I think is how the original script posted on bani forums did it.