Open Arena Aimbot

[grey matter]

E+ (and some other mods) permit banning by player name, IP, and by GUID.

cl_guid is worth close to nothing when dealing with those kinds of cheats. Most of the Quake 3 hacks have a feature to change the guid or pb id. It's even easier in games without Punkbuster, since you just have to delete a single file for ioquake3 to generate a new guid, no hack required. This is intended behaviour and documented in the Readme.

Player name is not a proper criteria either. Quite a few of those hacks include name stealers as well.

I don't mean to say that one should not include these criterias into bans, I'm just saying that they're quite weak and are already taken into account in most oldschool hacks from Quake 3.
Unfortunately this also means that whitelists for players are the only safer way, but they have their own disadvantages.
If there were safe and unique ids for every player, I'd vote for a global (community) banlist as well.

Behaviour analysis can catch most of the simpler aimbots, which just set viewangles directly. More advanced aimbots include "human aim" or simply trigger on sight without aiming on their own, both which are hard to detect, even by humans.

[WaspKiller]

...In this case, I think that /wallhack should only work in demos, because I don't trust admins to always do the right thing. Power can be abused, and so it should be monitored, at all levels, not only at player's.

Remember, while Admins can use it during a real game, they have to be in spectator mode to use the command so it's not like they can use it to cheat while playing.  I don't know why it did not work for you in 2.1 unless you were playing when you tied it or used /rcon wallhack instead of /wallhack rconPassword.  However, you have my servers at your disposal to test.  I don't think Refs can use the command even if explicitly granted so via the xp_referee server command.

E+ (and some other mods) permit banning by player name, IP, and by GUID.

...I don't mean to say that one should not include these criterias into bans, I'm just saying that they're quite weak and are already taken into account in most oldschool hacks from Quake 3....

Agreed, but they are what we currently have.  Better ideas can always be implemented in OA because unlike Q3 it's not a dead project.

...this also means that whitelists for players are the only safer way, but they have their own disadvantages.

Whitelisting in gaming is NUTS!  Your welcome to your opinion but a ban list, regardless of its IP exclusion evils, is easier to manage.

[grey matter]

Agreed, but they are what we currently have.  Better ideas can always be implemented in OA because unlike Q3 it's not a dead project.

Sorry, no better ideas from my side. The Punkbuster Guids were at least somewhat bullet proof, but they require clientside "anti-cheat", which does not work with open source.

Whitelisting in gaming is NUTS!  Your welcome to your opinion but a ban list, regardless of its IP exclusion evils, is easier to manage.

Huh? You're already managing a whitelist of players, by assigning some players certain rights on your server, aren't you? I haven't actually looked at E+, but that's what tools like B3 do with a breeze.

We're _slightly getting off-topic here

[GrosBedo]

@WaspKiller: yes indeed it works as spectator, I now remember that I could once get it to work that way. But anyway, it allows for the "spectator cheat" where an admin voice via VoIP the positions and strategies of the enemy team to its own team. I know this should not happen, but this is a risk, and believe me, I saw so many ridiculous abuses from administrators that I won't be surprised if this happens.

We're _slightly getting off-topic here

No, I don't think so, this is relevant to the topic of aimbots and solutions to circumvent it in an opensource game.

I concur with WaspKiller that a whitelist is a VERY bad idea. You can't just permit people you know to play, this would be the death of the game. And giving special rights to a set of users is another domain, the domain of privileges, but it doesn't forbid the basic use (play) of the server by the others.

The PunkBuster GUID worked because there was a kind of registration system behind. It is totally possible to reproduce the same system, even better, in OA. I think that Iourt did something like that, and AfterShock is another example (I think currently it's not used this way, but it could). Anyway this would produce an overhead on the whole gaming process for both administrators and players. I think it can be done in a nice ergonomic way such that there's no overhead, but anyway it would be a lot of work for the devs, and I think that we, for now, have other good alternatives that would fit the current needs.

A global shareable and auto-updatable banlist would be good I think, and B3 allows just that. Combined with the E+ anti-cheat system, this could be a very good and transparent way to avoid most of the cheating.

And about a humanized bot, I think that noone did such a bot for Quake 3 as of now since it's a very old game, and noone is interested in making such an advanced bot for a dead game, or an opensource game such as OpenArena with no detection system at all. No challenge, no hassle.

[grey matter]

The PunkBuster GUID worked because there was a kind of registration system behind. It is totally possible to reproduce the same system, even better, in OA. I think that Iourt did something like that, and AfterShock is another example (I think currently it's not used this way, but it could). Anyway this would produce an overhead on the whole gaming process for both administrators and players. I think it can be done in a nice ergonomic way such that there's no overhead, but anyway it would be a lot of work for the devs, and I think that we, for now, have other good alternatives that would fit the current needs.

Yes, you can mimic the Quake 3 authserver and q3key features. This only makes sense if it requires quite some effort from the player to register an account, otherwise players need not to care about bans, they'd just register a new account. Given that you need to register, some players might abstain from playing the game alltogether.
It also requires some thoughts so rogue server admins don't get to capture other players' login credentials. Iirc the q3key system is quite flawed in that regard.

And about a humanized bot, I think that noone did such a bot for Quake 3 as of now since it's a very old game, and noone is interested in making such an advanced bot for a dead game, or an opensource game such as OpenArena with no detection system at all. No challenge, no hassle.

That's only partially true. Most nowadays bots are not tailored at a specific game, they're just a generic framework that needs some game-specific adaptions. That means that anyone in hold of such a framework could just backport it to Quake 3 (especially since it's quite similar to QuakeLive code-wise, it does have anti-cheat and is being played in leagues).

I concur with WaspKiller that a whitelist is a VERY bad idea. You can't just permit people you know to play, this would be the death of the game.

Well, I can - in case I'm the server admin. No one even forces me to make my (clan-)server public. The way you're saying this sounds like any admin not running a public server, free for anyone, want's the game to die.
Besides this is what's being done in many of the recent free2play games; the free accounts only get limited gameplay. Once more some effort is required by the player to make it into a whitelist, in this case a premium account. This gain is what makes the account id valuable as a means of banning, since the player does no longer want to lose it.

I still think we or some admins should split the topics here.

[WaspKiller]

...But anyway, it allows for the "spectator cheat" where an admin voice via VoIP the positions and strategies of the enemy team to its own team. I know this should not happen, but this is a risk, and believe me, I saw so many ridiculous abuses from administrators that I won't be surprised if this happens...

I concur it has been done but all we can do is monitor against abuses.

In E+, Clan Wars have to be played under several conditions to be approved for ranking:

1. Pure enabled
2. PunkBuster enabled
3. A demo from each team (I left Q3 competitively in 2009, so they may be requiring MVDs by now)
4. Scoreboard screenshots for each match
5. One or two sanctioned Referees
6. xp_matchmode server command enabled
7. Both teams locked (which basically prevents all spectators from seeing anything)

Even with all those precautions, one or both Referees could do something similar to the Admin in your example since Refs are automatically granted the ability to spec both teams when xp_matchmode is enabled.

How do you guard against that, other than having a few players of high integrity?

As far as your example, I guess one workaround to deal with the possible abusive of the /wallhack command would be to require that wars be played on League Servers and that log files accompany the other proofs of the war.  Another workaround would be to indicate on the ScoreBoard either by visual reference (the Admin's line glows like the BattleSuit powerup) or via text (Wallhack Identifier:On/Off).  Hey, you're the programmer not me.

So complicated... That's why I only play 4 fun now.

[GrosBedo]

@WaspKiller: indeed, the wallhack already gives no information about who is holding the beacon you're seeing, so indeed you can't identify the holder, but with some logic you can pretty much deduce who is from where the player is. I think that the best is simply to disable it in-game, only enable when watching a video. Anyway in most cases I guess it's used afterwards when watching a demo after a complaint, because during the game a single admin can't watch every player at the same time anyway.

That's only partially true. Most nowadays bots are not tailored at a specific game, they're just a generic framework that needs some game-specific adaptions. That means that anyone in hold of such a framework could just backport it to Quake 3 (especially since it's quite similar to QuakeLive code-wise, it does have anti-cheat and is being played in leagues).

I'm not saying it, but pro-coder of cheats, they clearly stated this on another forum [which I won't link here for obvious reasons], so I think that if they say so, they're right. Maybe one or two lost soul coded a humanized bot for fun, but they won't be very evolved.

Anyway, I think that you are overestimating the current AI state. AI can do a lot of amazing things, but the perfect humanized aimbot doesn't exist yet, else it would be covered in a scientific thesis and the author would be world-renowned, I can assure you. Of course, some features can be simulated, but 1- not all, 2- only partially, simulating completely a human feature is way beyond current AI research.

And about the framework, I think you're partially right. Some humanized features can be translated from game to game, but the set can only be very limited, because the physics engine, the way players adapts to the engine, and the game mechanics change a lot from game to game. For example: where will you find a framework for a humanized rocket aimbot, except in quake3 like games? Surely not in Battlefield or COD!

Well, I can - in case I'm the server admin. No one even forces me to make my (clan-)server public. The way you're saying this sounds like any admin not running a public server, free for anyone, want's the game to die.

You can do whatever you want with your server, but I thought we here discussed about public solutions that could be shared among all servers, not just specific solutions that would work but at the cost of forbidding a large part of the community (and possible future players).

To this matter, I forgot to say that ip is quite a reliable way to identify a user. Indeed, most people think that it's easy to find a proxy, but most people are used to HTTP proxy. UDP proxies (which is needed to obscure one's ip in OA) are much harder to find and much less reliable, because you need a relatively high bandwidth to play, which most proxies don't provide.

Of course, UDP proxies can always be found, but a UDP proxy + totally anonymous (so that we can't traceback) + moderate/high bandwidth are very hard to find, and I bet that the cheater won't find it very funny after a while if we ban all of its proxies (remember that there's not an infinite set of UDP proxies over the web contrary to HTTP proxies).

So I still think that a global shareable auto-updateable banlist is still the best, easier, and most accessible solution we have right now for OpenArena. And I must add that when it was implemented on the supeR,Servers (as it is no more right now), it was pretty successful in preventing cheating.

[7]

Yes, you can mimic the Quake 3 authserver and q3key features. This only makes sense if it requires quite some effort from the player to register an account, otherwise players need not to care about bans, they'd just register a new account. Given that you need to register, some players might abstain from playing the game alltogether.

So why not generate a uuid automatically from data gathered from the user's hard- and software? By concatenating and xoring data like the MAC-addresses of the network devices, name of the operating system, type of processor, device names on the pci bus etc. the generated uuid would have a high probability of being unique and is not very easily changeable by the user.

[grey matter]

Anyway, I think that you are overestimating the current AI state. AI can do a lot of amazing things, but the perfect humanized aimbot doesn't exist yet,[..]
For example: where will you find a framework for a humanized rocket aimbot, except in quake3 like games? Surely not in Battlefield or COD!

The aimbot does not need to be perfect, or how would you actually define a perfect human aimbot? Since the human himself is not perfect, you only need to model the behaviour accurate enough. The goal of not aiming 100% accurately and not fixing targets through walls is not that difficult. Adding a little jitter to response time and maybe some misses might make the aimbot less valuable for those public server kids, but more suited towards league players.
Those games do have other kinds of projectiles, like grenades. Though those are usually not target of aimbots.

To this matter, I forgot to say that ip is quite a reliable way to identify a user.

I'm not a server admin, but from my limited experience those dynamic IPs make banning quite difficult. Though the IP ranges are often linked to their geographical location, they might still vary a lot and come from entirely different subnets. So you'd either have to monitor every ISP's address range quite closely or risk banning too many or to little addresses to catch that one specific cheater and no false positives.

Indeed, most people think that it's easy to find a proxy, but most people are used to HTTP proxy. UDP proxies (which is needed to obscure one's ip in OA) are much harder to find and much less reliable, because you need a relatively high bandwidth to play, which most proxies don't provide.

Actually, SOCKS proxies are not that rare. Besides you don't need that much bandwith (Quake 3 worked fine with 56k back in those days), but rather proper latencies. Even though most Quake 3 forks are Unlagged now, anything above ping 200 is quite tiresome to play with from what I remember.
The proxy does not need to be entirely anonymous. These kind of proxies are only needed for the torough illegal stuff (think; child pornography). Some dirty little cheater on public servers only needs a new IP, no true anonymity.
Luckily enough you can catch quite a lot of those proxies by using realtime DNS blacklists.
I'm still waiting for IPv6 were everyone will get like a zillion addresses for private use..

So I still think that a global shareable auto-updateable banlist is still the best, easier, and most accessible solution we have right now for OpenArena.

This list would need quite some features; Ideally I'd like to
Have a verified way to add entries into it, i.e. no entries out of nowhere. Thus entries need an author and maybe even digital signatures or at least a checksum which is proven by all incorporated admins.
Each entry needs a date, reason, id and proof in form of a demo. Screenshots or word-of-mouth are not enough.
Entries need to be grouped by reasons in case I don't want to ban users from the "misbehaving", "racist", "camper", "suspicious" etc. categories, i.e. separate lists.
One needs to be able to decline a ban (the usual "it was my brother" excuses, you know).
Each and every server using the banlist must point banned players to the appropriate entry in the list and explain why they are banned and whom to contact.

[grey matter]

So why not generate a uuid automatically from data gathered from the user's hard- and software? By concatenating and xoring data like the MAC-addresses of the network devices, name of the operating system, type of processor, device names on the pci bus etc. the generated uuid would have a high probability of being unique and is not very easily changeable by the user.

That's roughly what Punkbuster did, yet it was easily defeated. Even more since OpenArena's anti-cheat would have to be open source, which will just not work.

Besides I'd strongly boycott such spyware and just play other games

[7]

That's roughly what Punkbuster did, yet it was easily defeated. Even more since OpenArena's anti-cheat would have to be open source, which will just not work.

This is the same way Microsoft and a lot of other software companies uniquely identify the systems on which their products are running so they can revoke illegal installs. That's just like banning users, you know

You could try discouraging users from replacing the uuid-generator by a psuedorandom-generator by implementing aggregate scores and statistics over all servers and binding them to a user's uuid. That way, if he uses another uuid, all his nice scores and stats go up in smoke.

Besides I'd strongly boycott such spyware and just play other games

Generating the uuid is an irreversible process, so you can't tell what hard- and software a user has by looking at his uuid (version 3 of the UUID standard specifies using an MD5 hash for instance).

[grey matter]

You could try discouraging users from replacing the uuid-generator by a psuedorandom-generator by implementing aggregate scores and statistics over all servers and binding them to a user's uuid. That way, if he uses another uuid, all his nice scores and stats go up in smoke.

What prevents me from using a spam uuid for cheating and a proper one for stats?
Faking or changing hardware is not that difficult, there are quite a lot rogue device drivers (ring0 baby!) or simple application-specific hooks for this.

Generating the uuid is an irreversible process, so you can't tell what hard- and software a user has by looking at his uuid

That's not what I'm hinting at; as a user I'd just dislike a software which collects a bulk of data and also transmits (some of) it over the wire, no matter whether it's hashed, encrypted or whatnot. E.T. shall not phone home.

[7]

What prevents me from using a spam uuid for cheating and a proper one for stats?
Faking or changing hardware is not that difficult, there are quite a lot rogue device drivers (ring0 baby!) or simple application-specific hooks for this.

You'd have to use lots of spam uuids with an accurate anti-cheating system in place, and using different uuids from the same ip within a short period of time would be a strong indication of cheating in itself, so an automatic ip-ban would be imminent...

That's not what I'm hinting at; as a user I'd just dislike a software which collects a bulk of data and also transmits (some of) it over the wire, no matter whether it's hashed, encrypted or whatnot. E.T. shall not phone home.

C'mon man, 36 bytes of data which can only be used to uniquely identify players (or rather the systems they're playing at). Besides, if you want an anti-cheating system proper, you'll have to have some way or another to uniquely identify your players/clients so they have to 'phone home' some kind of id-information.

[Gig]

Of course, we can try to do something against cheaters (like that "wallhack" command), but I fear it may be hard because:
- The game is OpenSource, and cheaters would have full access to the source code of the anti-cheat system. They could even hack and use our own "wallhack", simply removing the code part that prevents its use during real game.
- Using digital signatures/hash tags checks for game binaries, to prevent the use of unofficial clients, would not allow people to build their own executables anymore, limiting unofficial ports to new platforms, making the game less "open" than its intentions.
- Using a forced and unique plaer registration before playing would probably not be technically possible for a number of reasons (backwards compatibility, fragmentation of servers, etc.), and would probably be a suicide, because we do not have a well known name with large player base like id Software had when launched QuakeLive.

I don't know what to think. Cheaters are bad, and making something against them would be good, but I don't know how well this could fit an OpenSource game. Anyway I'm not a coder, I fear I can't help too much here.

[grey matter]

You'd have to use lots of spam uuids with an accurate anti-cheating system in place, and using different uuids from the same ip within a short period of time would be a strong indication of cheating in itself, so an automatic ip-ban would be imminent...

Since I don't see how an open source anti-cheat could possibly work, one has to assume that there are no automatic bans while using a hack and one would only need a new uuid every time one gets banned by a human admin. Which, given the requirements for a global banlist outlined above, could take some time (not taking individual server bans into account).

C'mon man, 36 bytes of data which can only be used to uniquely identify players (or rather the systems they're playing at). Besides, if you want an anti-cheating system proper, you'll have to have some way or another to uniquely identify your players/clients so they have to 'phone home' some kind of id-information.

This does not change the fact that the anti-cheat queries my system for quite a lot of data ("the user's hard- and software"). Iirc Warden (Blizzard's Anti-Cheat) peeked into browser windows with online banking and submitted that data. EA games are being boycotted due to Origin. As you see, users don't like being "spyed" at, even if the software "just" has legitimate purposes.
You don't need that much information to generate a unique id, the main purpose is to make it difficult for the user to _change this id, so hiding a randomly generated key would work as well (security by obscurity..).
Anti-cheat (as in; preventing hacks) and identifying players are two separate concerns, though usually tightly coupled. I don't need any kind of anti-cheat to be identified as paying customer #42 via username/password login.

[grey matter]

- Using digital signatures/hash tags checks for game binaries, to prevent the use of unofficial clients, would not allow people to build their own executables anymore, limiting unofficial ports to new platforms, making the game less "open" than its intentions.

Don't nail me on this one, but this does not sound GPL compliant anyways.
Besides it's only an annoyance for the legitimate users, since hackers can just send fake signatures as well. You'd need to go the whole way of certified operating system and hardware to "secure" everything with signatures.

- Using a forced and unique player registration before playing would probably not be technically possible for a number of reasons (backwards compatibility, fragmentation of servers, etc.) [..]

I don't remember being able to play on 0.7.0 servers with oa 0.8.5 (read; you have to sacrify backwards compatibility at some point, so this is not an argument).
Hackers do not only target the client, there are also hacked servers out there for all the pirated games, so one can't enforce this for each and individual server anyways.

I don't know what to think. Cheaters are bad, and making something against them would be good, but I don't know how well this could fit an OpenSource game. Anyway I'm not a coder, I fear I can't help too much here.

I don't have the impression that cheaters are a serious problem right now (also see GrosBedo's post above for efficiency of current counter-measures), so the resources (developer time) should be used elsewhere imho.
Besides I still don't see how an open source anti-cheat would work anyways. It might not be entirely useless, but more annoying to end users (bugs, false positives) and developers (maintainence) than hackers ("great, just remove that check function and recompile").


P.S.: Sorry for all those double postings, I just can't type that fast and include all different posts and quotes at the same time in one huge post

[7]

Since I don't see how an open source anti-cheat could possibly work, one has to assume that there are no automatic bans while using a hack and one would only need a new uuid every time one gets banned by a human admin. Which, given the requirements for a global banlist outlined above, could take some time (not taking individual server bans into account).

Yes the game is open source but that doesn't mean you can easily change the programming of a server as a client. Since the only part of the anti-cheating system that relies on the client is the uuid generator, that's the only attack-vector you have via the code. If you build the server in such a way it can detect something strange is going on with the client's uuid-generator, you have a fairly reliable open source anti-cheating system.

I would only share uuids in a global banlist, the ip-banning would be on individual servers. Publicizing a relation between a uuid and an ip could (and should) be considered a privacy violation so that should be avoided.

This does not change the fact that the anti-cheat queries my system for quite a lot of data ("the user's hard- and software"). Iirc Warden (Blizzard's Anti-Cheat) peeked into browser windows with online banking and submitted that data. EA games are being boycotted due to Origin. As you see, users don't like being "spyed" at, even if the software "just" has legitimate purposes.

We're not gathering credit card data, we're just reading the pci bus, the /proc filesystem etc.

You don't need that much information to generate a unique id, the main purpose is to make it difficult for the user to _change this id, so hiding a randomly generated key would work as well (security by obscurity..).
Anti-cheat (as in; preventing hacks) and identifying players are two separate concerns, though usually tightly coupled. I don't need any kind of anti-cheat to be identified as paying customer #42 via username/password login.

The point is you can easily change a randomly generated key stored on your own machine, as you yourself pointed out before. A uuid generated from system specs is nearly as random, the only difference is that it's not so easily changeable.

If I'm a paying customer I have to supply lots of data to my service provider (like credit card data for instance) so he knows much more about me then when I send an md5 hash of an pci-bus read to a server that only knows my ip and if I' m a cheater or not.

[grey matter]

So, all the server has is some uuid, which could be anything and can thus not be validated by the server.
The client supplies this uuid to the server and is trusted to supply a proper one from hardware information.
The client is where I'm running my hack. The server identifies me via the uuid generated by my client.

Do you see the problem now?

P.S.: An uuid generator is no anti-cheat, that's just another way to identify a client, like a classic username/password login.

[Gig]

- Using a forced and unique player registration before playing would probably not be technically possible for a number of reasons (backwards compatibility, fragmentation of servers, etc.) [..]

I don't remember being able to play on 0.7.0 servers with oa 0.8.5 (read; you have to sacrify backwards compatibility at some point, so this is not an argument).

Yes, but even if networking code may have changed, and base package has been changed, the game works more or less the same way... you can still run mods designed for Q3 in OpenArena (luckily!). I don't know if a "global registered users" infrastructure may work without breaking mod compatibility, maybe yes, if relying in game engine only.. anyway I suppose we don't have the player base and the resources needed to create and maintain a such global system. That would make OA more similar to QL than to Q3A... (and the advantage of OA against QL is the freedom).

It's nice to know that, even if id software will shut down QuakeLive in the future, causing its end (unless they would decide to make it open source, too), anyone in the world will still be able to upload OA game files somewhere and run his own OpenArena server even if Fromhell would decide close the site.

PS: I started using OpenArena when 0.8.5 was already out, I never played 0.7 or earlier (unless I may have tried it once years ago and I don't even remember about it... but probably not at all).

PPS: About the GPL question ... I'm not sure, but that would not prevent you from creating your own game starting from OpenArena code, or using your custom OA client to play locally or on your own custom server... but to connect to servers using official executables. I don't know if it would have GPL problems... anyway, I suppose that would be against OA spirit anyway.

[grey matter]

I don't know if a "global registered users" infrastructure may work without breaking mod compatibility, maybe yes, if relying in game engine only..

That's exactly what id Quake 3 does, while being compatible to all sorts of mods (the same applies to Punkbuster within Quake 3). Both are part of the engine, no need to change the virtual machine infrastructure (because that's the reason for all these layers anyways).
Quake 3 required you to buy a valid CD key to play online (and is still not free as in free beer), which is not that different from the registration for QuakeLive (and their pro accounts anyways).

And it's nice to know that, even if id software will shut down QuakeLive in the future, [..] anyone in the world will still be able to upload OA game files somewhere and run his own OpenArena server even if Fromhell would decikde close the site.

What are you targeting at? Anyone in the World can create mods even for closed source binary applications, it's just not that easy.
Do you mean that anyone can take the oa code and recompile it on his quantum PC in year 3016?

[GrosBedo]

- The game is OpenSource, and cheaters would have full access to the source code of the anti-cheat system. They could even hack and use our own "wallhack", simply removing the code part that prevents its use during real game.

Good point, it could indeed be misused, but anyway there's nothing right now that prevents a player to modify the client binary to add such features. With OA you don't even need to code an external hook!

@7: indeed a quite reliable guid could be created this way, and I don't think the privacy would be a concern since the GUID would be computed client-side and nothing would transit on the network but the GUID. Anyway, the problem doesn't reside in the GUID, but in the process of making it: since it will always have to be computed client-side, it is flawed by nature, because with the sources, a hacker can easily tamper the GUID computation function. So it's no use anyway to do that, this only works in closed system that use obscuration as their main security objective.

After of course, you can make the GUID server side at some point, but the obscuration always take place somewhere. If you reveal all the code, there's no point anymore in making such a complicated GUID. So I think that GUID is not the right way to look for a solution to the cheating problem.

@grey matter:
About the perfect humanized aimbot: you are taking too few features in account. Humans are a very complicated entity, and it can not so easily be simulated.
Basically, what you are describing here, is a machine that would pass the Turing test (furthermore a very much complicated Turing test, because in the standard Turing test, we only test the bot's aptitude to talk, not to behave physically like a human!). You are at the same time underestimating the complexity of the AI problems, and overestimating the current state of AI research.

About SOCKS proxy, when I meant high bandwidth, I meant enough to get a stable connection! Not to play like you're on a dedicated high speed broadband! Even if you just want to get a stable connection 99% of the available SOCKS proxies don't work. Try it, you'll see!
And if they aren't totally anonymous, we can traceback the original IP, so no problem.

About IP ban range, I don't favour them at all, I think that banning a single IP is largely enough. It's a myth that you need to ban a range of IP, because most of the time the other IPs of the subrange are totally not related to the player you're banning.

About the global banlist, most of what you require are exactly what is implemented in the B3 banlist system:

- Based on a peer-to-peer architecture: you make your own banlist, and other admins subscribe to your banlist, so they get updated with your addings. Of course you can also subscribe to them, so that everyone in the chain gets updated with the same, global banlist.

- Reasons are also stored if given by the admin banning the player, and are transferred to the other banlists. There is also the date and the ID of the admin banning (but I don't know if it gets transferred, but the module can be edited for this purpose).

- Proof such as demos are not implemented, but they can be easily: B3 is opensource, and is based on a MySQL database.

- Since it's based on a relational database with SQL, you can do online analytical processing as you want and aggregate the informations the way you want to analyze it.

- About giving users a way to complaint about their ban, this is only up to the admins, but there are of course ways to do it, and I hope to implement it soon.

Lastly, about the fact that an opensource system can't reliably place security measures, this is almost true. It's harder, but it's possible. See Linux OSes and the GPG encryption system. Don't mix up obscuring and security. They are often coupled because people often rely on obscurity, but history shown that this is not always the best strategy (see Microsoft OSes or Mac).

But I agree that the security should not be client-side, this would be meaningless. Any security measure should be totally server-side with no way to cheat it by tampering the client.

[7]

So, all the server has is some uuid, which could be anything and can thus not be validated by the server.
The client supplies this uuid to the server and is trusted to supply a proper one from hardware information.
The client is where I'm running my hack. The server identifies me via the uuid generated by my client.

I think you're missing the point. The server can safely assume that a properly generated uuid coming from one and the same ip won't change very often. This means that lots of uuids coming from the same ip would indicate the client behind that ip is not properly generating its uuid for whatever reason so the server can automatically (temp)ban it on ip, exactly because the server doesn't trust the client's uuid. Having both the ip and the uuid gives you two options for banning...

(The only problem with this scheme is natted networks, but that's always the case with ip bans.)

[Gig]

And it's nice to know that, even if id software will shut down QuakeLive in the future, [..] anyone in the world will still be able to upload OA game files somewhere and run his own OpenArena server even if Fromhell would decikde close the site.

What are you targeting at? Anyone in the World can create mods even for closed source binary applications, it's just not that easy.
Do you mean that anyone can take the oa code and recompile it on his quantum PC in year 3016?

Well, in theory, it is possible. But we will not be here in 3016 to see if it will happen!
Excuse me, but with "mods" you mean "mods" like DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Mod]we usually mean them (e.g. legally allowed by apposite SDK license agreement, I think Q3 had something similar), or you mean "hacked" games (e.g. cracks, trainers), that usually are not legally allowed?

I was referencing to the fact that in OA, like in Q3A, anyone can run his own server, with the only link to other servers (and dependency from a third party service) being the master server listing, that anyway does not prevent him to play with his friends (let's keep Q3 punkbuster and cdkey check out for the moment, we are talking of a concept, and of OA mainly). In Quake Live everything is centralized, and without its master server, nothing would work at all, I suppose (but I'm not a lot inside QL architecture, maybe there may exist some workaround I don't know. I don't even know if id software itself runs all the servers, or it relies on third party people). So, playing OpenArena in 3016 is theorically possible, if a copy of the sources will survive up to that time (or even if only a copy of the binaries + game data will survive, using an emulator!). Playing QuakeLive in 3016 is theorically possible only if id Software will still maintain it.

[GrosBedo]

Having both the ip and the uuid gives you two options for banning...

This is the sort of assumption that I had when I implemented in my module for B3 called WideBan. Even with the currently unreliable GUID, it's possible to use it when possible to make the banning system a bit more reliable. But anyway, spend a lot of time to make a unique GUID still is to me a waste of time since it can be cheated client-side.

[grey matter]

About the perfect humanized aimbot: you are taking too few features in account. Humans are a very complicated entity, and it can not so easily be simulated.
Basically, what you are describing here, is a machine that would pass the Turing test (furthermore a very much complicated Turing test, because in the standard Turing test, we only test the bot's aptitude to talk, not to behave physically like a human!).

Maybe I've not been clear enough about the definition of "human aim". It's a computer program which just aims (it does not walk around or do any sophisticated game goals such as capturing a flag by itself) "like" a human, that is a spectator can't tell for sure whether the aiming is done by a human or a program. That's just it. I'm not talking about emulating more human features like stress (reduced aim skill), adrenaline or whatever you've been thinking of.

Even if you just want to get a stable connection 99% of the available SOCKS proxies don't work. Try it, you'll see!
And if they aren't totally anonymous, we can traceback the original IP, so no problem.

There are two separate concerns here. If a player is just trying to annoy people by using an obvious 100% accurate aimbot, he is not really interested in a stable connection. He just needs another IP to evade the ban and continue laming. If a player is using a human aimbot, he most likely won't be detected and thus does not need to evade any bans via new IPs.
I highly doubt that you can traceback my original IP if I use some random SOCKS proxy. If that proxy is leaking its client IPs it would not be a proper anonymous proxy. And if it does not leak, you'd have to hack the proxy server to get my IP.
If you're trying to minimize damage by distributing false statements, we should continue discussion in a more private way.

About IP ban range, I don't favour them at all, I think that banning a single IP is largely enough. It's a myth that you need to ban a range of IP, because most of the time the other IPs of the subrange are totally not related to the player you're banning.

With the dynamic IPs from European providers all I need to do is reconnect my modem to get a new one in my ISP's address range, so one IP is not enough to ban me. But this new IP will usually be from some arbitrary address range that is used for a certain area/town by the ISP, so chances are that a subnet ban will include it as well.

- Reasons are also stored if given by the admin banning the player, and are transferred to the other banlists. There is also the date and the ID of the admin banning

Uhm, this is a huge no-no. A global banlist bans players from the ENTIRE GAME. You just can not "forget" to add reasons to some of them. I don't think we're talking about the same "global" here. The B3 banlist system is per server per admin choice, which is far from being global. A global banlist has to be maintained by the game maintainer, e.g. when id Software bans a q3key.

- Proof such as demos are not implemented, but they can be easily: B3 is opensource, and is based on a MySQL database.

You'd have to record the demos on the server, since demos by a client can not be trusted, even if he has moderator or admin status. This needs a patched server executable, like the Baller Bude Smokin' Guns server.

- About giving users a way to complaint about their ban, this is only up to the admins, but there are of course ways to do it, and I hope to implement it soon.

This is only true if we're not talking about a real global banlist (see above) and only if the server admin is foolish enough to believe that his bans are always 100% accurate.

Lastly, about the fact that an opensource system can't reliably place security measures, this is almost true. It's harder, but it's possible. See Linux OSes and the GPG encryption system.

I've never mentioned "security measures", I was always talking about so called anti-cheat. You can not create an open source anti-cheat where you rely on the client to give accurate data. Obscurity and closed source plus difficult reverse engineering is what makes all these proprietary anti-cheats worth their 5cts after all.

But I agree that the security should not be client-side, this would be meaningless. Any security measure should be totally server-side with no way to cheat it by tampering the client.

What's being secured here? Are we talking about the authentificy of the incoming data to be generated by a human? That's not security. Security means not trusting the clients data in this case. One example would be storing health and ammo clientside without a verification on the server. This is not done in Quake 3 anyways, all data and gameworld events are dictated by the server, it can even tell you that you've missed when you should have hit from what you see clientside.
You can't place "security measures" serverside and expect the unsecured client to send un-tampered data. If you're not verifying the client (your only data source), you can never be sure that it's legitimate.