OpenArena Message Boards

DISCLAIMER:
For educational use only.
DO NOT USE ON MULTIPLAYER.
I am not responsible for botters. By using this bot, you agree not hold me responsible for anything that goes wrong, even if you are banned or your PC blows up ;D .
This aimbot is excellent for playing with Nightmare bots.
-
Download Link (Remember, for educational purposes ONLY!)
-

While the source code might be educational, an executable that only runs on the system I do NOT use for playing OpenArena is far from it.

"educational" is not a justifiable excuse for multiplayer cheats

Here kids have some candy... for educational purposes only... DO NOT EAT!

Here's a PC, it only contains educational programs. DON'T USE IT!

(?)

So you get to beat Nightmare bots (only... never humans... lol) by using a cheat and this will make you... happy? superior? confident? talented? admired? brimming with self-esteem?


All I can do is laugh.  The words; loser, sad, pathetic, don't even do justice to such a piece of sh*t.


Maybe I can be self-righteous because I have always been good at Quake games and gaming in general.  But even games where I did not do quite as well, it never occurred to me to cheat.  Instead, I moved on.  There is at least one game/mod out there, of the tens of thousands that exist, that you have to be good at.

Here you have someone who could be creating or contributing to something useful, assuming he is the author of the deleted code, but instead turns his coding skills to the dark side.

i've never investigated the link, but i'm betting it's the same stuff allcoholic wrote. perhaps this is even allcoholic

I did not download the file, but I've seen the youtube video (that links the file in the description :( ) during map loading screen, it mentions a certain "King-Orgy". I don't know if it is the previous hack you knew or another one.

Of course, in a game like OpenArena cheating is pointless. You don't need to beat bots at nightmare level in order to unlock all tiers. And, seeing the video, that aimbot seems to me to make the game not enjoyable: you are running in a direction, then someone spawns next to you, and in the next frame you get yourself facing in the opposite direction from where you wanted to go, forced to look at him. Confusing.

Fromhell, server admins might be interested in his IP to ban him :P. Maybe post it publicly? Cheaters don't deserve privacy nor a server to cheat on, imo.


I'm sending Edit: I've sent an e-mail to abuse@mediafire, I hope they'll remove it.

Was it a real bot or a hacked client? If it was a real bot then there is nothing to learn here except that the author is a script kiddie who doesn't know what he's doing and probably copy&pasted code from the various Q3 bots out there.

You have to be quite pathetic to use wallhacks, aimbots and the like.

Cheats are bad, mmmkay?

(http://img81.imageshack.us/img81/1413/614image20ce7.jpg) (http://imageshack.us/photo/my-images/81/614image20ce7.jpg/)

By hacked client, do you mean a modded version of openarena which included an aimbot?
The download was around 80KB in size and was named something like "OpenArenaClientHook.zip", which included an exe and dll with the same name. Looking at the video, it seems it is the same aimbot as the one ported from another ioQ3 game to OA a few years ago.

F1.


Since OA does not have any Anti-Cheat software, Admins should have a central clearing house (in a sticky thread here) where they can share and download a Community PermaBan list (something akin to what they do in Urban Terror).  Note, I am talking about bans for cheating not for actions that are only deserve a TempBan.

E+ on OA does not have access to PunkBuster like its Q3 relative but it does have a 5 level Anti-Cheat system which has caught several players on the WASP Servers.  I would be happy to share these IPs with other Admins.

Exactly


Yep, that's what I suspected, this proxy-approach makes no sense when you're writing an aimbot from scratch and you can just hack the client itself. I bet he put some nasty malware in there and the bot was just bait.

KingOrgy has copypasted various aimbots for Quake 3 forks before, most likely adjusting the good old OGC clienthook. A proxy aimbot would be way to 1337 for those kiddies, but indeed educational to look at code-wise.

I don't think posting IPs public is a good idea. At least here in Europe most ISPs hand out dynamic ones. This means you'd just be banning however has the bad luck to get the IP on next reconnect. Besides those ban lists tend to last forever, even if somebody else is now on the other end of the line.

Besides I don't see why I should let my PC play against it self, i.e. aimbot vs. game bots. If I want to burn some cpu time there's still things such as SETI@home or bitcoin mining :)

I didn't mean a real network proxy (like in the quakeworld days) but a stub exe to hook a proxy dll. There is no need to do that if the validity of the client itself isn't checked.

iirc this bot is very old and there was a time he was used in oa (0.81?).
i was never interested in examining this bots (and there are many q3 bots out there which also work on oa).
But this aimbot is that kind of "made by a kid" so everyone can see that it is an aimbot (immediately change orientation, maybe even the "look @ ceiling" :D).

I realy hope, that a good coder will make a bot, which isn´t detectable @ a 1st look.
The shown one (it is an autoaimbot if i understood right) is not for educational purpose: it is just a provocation to the oa community.

so the hardest embargo we have, would be the best solution to answer this post!
Which options we have: give away his ip? promote his email? send an abuse to his provider? include a ban list with his ip in the upcoming release? post it on facebook. make a twitter post?

or just ignore this kid and go on with 0.88? ;)

@fromhell: thx 4 deleting the link that fast! many kids around here... :(

Banning the user from the forum and removing the file link is not a long-term solution, but at the very best a short-term fix.

I support the idea of making a global public banlist over the servers, and the ExcessivePlus anti-cheat system should be more promoted as it is generally reliable.

I'm aware of that. The instant ban is all due to the intent of cheater indundation, which is obvious because this is his first and only post. And i'm aware of the streisand effect, the little guy's probably posting the same on clans' forums now.

Wasp, could you please tell us something more about E+ anticheat system? Is it something that may be integrated directly inside OA in the future?

You have a point but that can be circumvented by having expiration dates on the banned IPs or banning by GUID.

E+ (and some other mods) permit banning by player name, IP, and by GUID.  I don't play baseOA so I don't know if you can ban by GUID, but if not, it needs to.





Pedantic but... WASP is the Clan and Killer is my gaming name. :-)





Excessive Plus 2.2b (developed by Panda; a Q3 E+ Dev) is the first version of E+ to have this Anti-Cheat System (which is separate and independent of PunkBuster).

The E+ AntiCheat (AC) System was designed to catch most of the annoying aim bots and auto-shoot hacks.  That is, it's meant primarily to get rid of the easy cheaters who run their cheat the whole time.  This way, Admins don't have to watch endless demos with and without the wallhack identifier* to determine if a player is indeed cheating.

This is by no means a perfect system, in fact, setting it to level 4 or 5 will result in a few clean players getting kicked because they have buggy hardware (particularly a failing mouse that moves weird) or an Internet connection that makes constant and dramatic changes in ping.

The system only kicks.  Banning is still left up to the Admin.  It's his responsibilty to monitor his server and/or run a search on his logs for anti-cheat kicks.




I don't see why not.  E+ isn't OpenSource but the same system (hopefully better and with a different backdoor mechanism) could be coded into OA.  In fact, the best person to talk to is certainly not me or even an E+ Dev from Q3 but OA's very own GrosBedo (supeR,Grism).

He was a Dev Consultant and the only member in OA to have priviledged access to the Anti-Cheat Code, to the beta testing process, to the raw data that was in the encrypted server logs used in the trial period, to the enumeration system used:

Example, not actual legend:

a = WallHack
A = possible WallHack
b = AutoShoot
B = possible AutoShoot
c = AimBot
C = possible AimBot
d = Aim Correction
D = possible Aim Correction

and to other intimate details like the password needed to check the debug information (yes, the debug logs are coded).


*Wallhack Identifier:
If you suspect a player of cheating with a wallhack, enter the following command at the console: /wallhack rconPassword.  You must be an Admin and spectating to use the command under this circumstance.  However if a demo is recorded, anyone viewing the demo can enter /wallhack at the console to try and ascertain whether the player is legitimate or a cheater.

Thank you for infos. Maybe Sago or Fromhell may want to contact GrosBedo, who knows.
Maybe that /wallhack when viewing a demo may be easy enough to be implemented in OA? The quickest thing could be linking it to r_showtris, even if not exactly the same thing.

Sorry, I thought your nick was talking about a bug buster! :) Probably I already heard of WASP clan, but was not connecting at the time of writing (that was time for bed!)...

By the way, using clan tags when registering on forums around the net may be useful, to be univocally identified across various platforms... but in the other side, it may become a problem when the clan will change its name (e.g. after a fusion) or will end its activity, or one may leave it (to join another clan or not).

About the E+ wallhack detector, it's a very simple yet very effective system: it simply draw a beacon (just like the team beacon) over the head of every player in a demo (even behind walls!). Of course, it only works in demos, so you can't use it in a real game. This could easily be implemented in OA, but it should be accompanied with an option to make the demos more precise too in the eye of the player (I think some steps were already done towards that direction) to avoid false alerts (when you see in a demo that the player killed another behind a wall while in fact it's because at the time there was a delagging or nudge processing for the player).

About the E+ anti-cheat system, the mechanism used is quite reliable and innovative, there is no other system implementing that to my knowledge. I won't explain more about the exact mechanism since the devs want to obscure it as an added security. This system can be implemented in OA, or just simply be an external tool. Of course it would need some modification of the OA engine, but they are superficial (in the sense that they don't change any game mechanism).

Good explanations and I hope FromHell has the good sense to tap your knowledge and implement these ideas in a way that serves OA best.

However, you have one factual error.  You can use the /wallhack command during a real game IF you are an Admin.

btw, I should have made it clear, not to you GrosBedo, but to Gig and the others interested in this thread that the /wallhack command is NOT part of the Anti-Cheat System.  I have been using it as a Server Admin since 2005 under E+ 1.03 but it may well have been in earlier versions.
 




In E+ on Q3, my Forum Name was simply Killer until I was selected by the WASP Clan Founder to join WASP (my 1st and last Clan... Clan Hoppers are evil ppl in my book and never to be trusted) and became its Clan leader.

"Killer" is such a common name in any game, that some differentiation was needed especially since there is a player in Q3 E+ from Europe known as K!ller who is a notorious cheater (banned forever) and Forum troll (constantly being banned under new accounts).

Ah really? I tried to use in-game while being loggued as a ref and admin and it didn't work in v2.1b, I thought it was a security feature. 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.

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.

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.





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.




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

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.

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

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


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.

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.

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

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.

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.

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


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!


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.

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.

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.

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.

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

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.

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 :P

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.


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

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.

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.

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


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.

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.

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

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.

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.

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

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.


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


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.

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.

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.

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

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?

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.

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

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 (http://([b) (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.

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.

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.

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.

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.

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.

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 (http://bb.game-host.org/demos/).

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.

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.

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.

I'm talking about legal mods (mods that are compliant with the Quake 3 virtual machine/system calls, which is a cgame/game/q3_ui module, either qvm or shared lib).

To be honest, it's been ages since I've used by QL test account. From what I remember you could play offline matches against bots. If that's true, then you have the required server and game logic on your computer as well. It certainly requires some effort to play with your friends with this (cdkey and such), but it should be possible, just like in Q3/OA. The architecture of server+client engine and game logic in cgame, game and ui modules is still the same in QL.

Why do you need an uuid then, when you rely on the IP belonging to the very same PC? The only advantage is that you could identify multiple accounts from the same PC/IP. The IP can't be changed anyways, since it's required for network routing to work. If the IP ain't static, then you need a uuid, but then it's also the only way to identify the client and thus fails since the client can just fake it.


You can also read client cvars and binds with a clientside mod (i.e. via cgame.qvm) to generate that kind of fingerprint you're aiming at.

The point in generating a guid/uuid from hardware specs is that a server can safely assume it won't change a lot. Randomly generated guids would change with each installation of the client while uuids generated from hardware specs would not, so players with multiple installs (like coders, artists and testers) and players having trouble with the client and reinstalling it a lot would probably get banned with random guids.

- About the perfect humanized bot, yes indeed I talked about those other features, which are critical to detect a cheat. This is what makes the difference between a bot and a human, and as long as no bot can simulate all these features at the same time, we can confidently assume that we can detect them (by a human verification or a sophisticated automated system).

Another example of feature that aimbots don't simulate right now is the wrist movement. There is a great article by the author of the BrainWorks mod on the matter:
http://brainworks-ai.blogspot.com/2008/06/its-all-in-wrist.html

And as a matter of fact, I am pretty sure that the best human simulation currently for OA and Quake games is the BrainWorks mod, but yet it does lack a lot of features (and so it still is detectable), and it does have access to a lot of ingame informations since it's directly plugged in, as opposed to cheats that only hook the game and get much less pertinent data.

- About the SOCKS proxy, you are talking in a theoretical viewpoint, but in practical it's not the case, and indeed the concrete risk is weak compared to the potential high risk. From my own experience, this is not (yet) a concern. Maybe in the future with the democratization of very highspeed broadbands it will become a risk, but for now it's not, since useable SOCKS proxies are very rare.

- About dynamic IPs: indeed this is a concern, but it's highly unprobable that two players share the same dynamic IPs, and in this case they may complaint to remove it. This is indeed the limit of the global banlist, that's why an anti-cheat system may be made in the future...

- About B3 banlist: You can edit the command in B3 so that you require a reason before banning, this is an easy tweak.
And yes you can have a global banlist. For the previous supeR,Servers, this was implemented, so that a player banned on one server was banned on all servers (same for kick and warnings). Also, the banlist was public and subscribable, though noone used it.
Keep in mind that this is a distributed system, unlike Punkbuster which was centralized and maintained by a single entity. Here, you are free to use and contribute to the global banlist, or not. And you can even create your own sub global banlist, that will only apply to a subset of servers (a little like the supeR,Servers: the banlist was global only to those servers, but not for the others, since noone participated...).

- About demos and B3: of course, and there's already a patch to make automated server-side demos for OA, but this is a separate concern. My point was that you can implement it easily in B3 and share it with the banlist. The way you make the demos is up to you.

Anyway about the whole global banlist, I think I must clarify: I don't think we will ever get to a centralized system like Quake 3 and PunkBuster, and this would be quite inadequate with the open spirit of OA. A distributed system is what I have in mind, with a choice of use it or leave it for the admins. This is the most realistic and efficient way to imagine an anti-cheat system currently for OA.

-About client-side security measures: exactly, the client is never to be trusted. That's why everything is done server-side in OA and Quake3. If now we begin to compute things client-side, we can't ever know if these were tampered or not, so better avoid wasting time developping such things.

I see, in this case nice idea, but it would still not have a good false positives / false negatives ratio, because players that intentionnally change their GUID will also probably change their IPs at the same time. So we get back to the starting point...

It's not that simple: the main point of QL is not the game logic but the serverside logic, which automatically create matchs between players of similar skills, and follow their progress. So in fact, you would lose all the benefits, while having all the cons of a closed system: no editing, no update, and no mod! Because I'm not aware of any SDK for QL yet.

I concur with Gig that OA has a potentially infinite reusability compared to Q3 and QL (QL reusability when there will be no maintenance will be near 0).

I don't know if there is a way to launch QuakeLive client other than connecting to their web site (maybe there is a way to directly launch the binaries, or an hacker may "fake" that website client invoking), and I haven't checked if you can safely disconnect from the internet after launching the test match against bots.

I'm still not convinced that you can tell a lucky shot from one of the current human aimbots. It's suspicious if there are too many of them, but you won't go into great length and detail analyzing each and every shot of every player on a public server (since public servers are the score you suggested. In a local league environment you can control who's playing with which client hard- and software by providing it yourself).

Could you please rephrase that, since I don't quite get what you're talking about here.

From my time with T-Online as ISP I can't remember having the same IP twice, which means that someone else (multiple someones infact) must have used them after me.
I haven't heard of ISP tailoring their IPs to specific customers by using things such as login data or modem MAC and as such the risk of multiple different people using the very same IP is real.

Not really. Since there's currently no proper way to test the authentificy of demos without a separate demo from another trusted client, you as a server admin can not use a demo provided by some random client as a proof of cheat. If you did, no other admin should use your ban list, since it can contain bogus entries.

Okay, we've been talking about two different definitions of a global banlist then. Your distributed banlist only becomes global if each and every server admin opts in to use it, that's why I would not call it global.


Excuse me, but in how far is this of any use with cheaters, where the client and thus its uuid can not be trusted _at all?
It's certainly of use to accurately identify clients who use the official legitimate software. But this is already achieved by the current ioquake3, which stores the data for the guid in a user specific folder, no matter where you install the rest of the game (you can override that behaviour without any hacks, but you might as well flag that behaviour as an attempted cheat attempt, though you can not properly detect it on the server).

I don't, you need a uuid exactly to take dynamic ips into account.


Even with dynamic ips the client won't change ip more then once every 8 hours or so, so let's say we make a sliding time window of 4 hours for uuid change detection. A modern anti-cheating system is fairly good at identifying aimbots and autoshooters unassisted, so it would ban an autoaiming client's uuid within a few minutes and there would be lots of banned uuids from the same ip within 4 hours.


Yep, you can't make a perfect anti-cheating system, that's a fact, but you can make cheaters jump through so many hoops to cheat successfully, that only the most stubborn ones still think it's worth the effort.

@grey matter:

- About dynamic IPs: I didn't say 2 users, but 2 players. It's highly unprobable that 2 players of OpenArena will share the same dynamic IP. But 2 users in the world yes, the probability is 1.

- About SOCKS proxies: I just meant that if there were many usable SOCKS proxy, it would be a concern, but as of now in 2012, it's still not a concern because there are only a very few SOCKS proxies that can be used for this purpose, and so only a few repeated bans of the same player would lead to a complete ban for this player. He can always find another SOCKS proxy, but will spend days and days to find a few ones, so I think that's ok.

- About demos: I'm not talking about the current demo facility. Someone ported a patch from Smoking Guns to OA, so that server-side demos can automatically be recorded. This same person had a public repository to download these demos as a proof of concept. You can find it on this forum.

Seems like you didn't read my posts. Assuming that the client is willing to evade an IP ban, he can just reconnect to get a new IP. He can change his uuid at will anyways, so if you assume that a not recently seen uuid from an IP should result in immediate ban, one person could ban most of an entire ISP's IP range just by regenerating his uuid and reconnecting with new IPs all the time.
A proper client might change his IP way more often that just every 8 hours. The ISPs I know only assign the same IP to you for a time span of about one hour. If my modem disconnects on inactivity, I might get dozens of different IPs a day.

From what I've seen, this only makes people try harder. You also need to separate the hackers (or crackers) creating the cheat and its users.
It's always an arms race about obscurity and reverse engineering, one that the OA developers do not have energy to participate in.

If their match-making system is what you're after, this can be implemented in OA as well (the code for stats tracking is already been there). But this requires global infrastructue (player database), which would not longer exists "if Fromhell would decide close the site."

Afaik there's indeed no SDK. But you can edit QL (though not the game logic) by replacing or adding models, textures and maps, even for your own  servers.

Indeed, I agree, but the efficiency of the system should be carefully thought before putting too much time in it. If you can implement a quick function to do this and test its efficiency before proceeding to more development, it would be a good idea. But one shouldn't put too much time in it unless there are strong indicators that it will succeed.

I don't agree: the game is opensource, even if the original infrastructure is down, anyone can take up the project and continue it. This is one of the greatest advantages of opensource systems.

As an example, see GTV: if it was opensource, it would be used on every ioquake3 based game for leagues, or even casual servers. Actually it's dead, because there's no way to enhance it.


Missing the ability to edit the game logic is a big limitation, and so I can't see the point to choose QL over another open game. There are so many out there, and some great ones such as OA, why spend so much pain in a closed game?

Be careful with that statement, I've seen quite a lot people (maybe brothers, parents and their kids) from the same IP address due to NAT. This should not be so much of an issue with IPV6 and zillzions of addresses for private persons as well.

Thanks for clarifying! I share your opinion on this, the average lamer will not spend so much time searching :)

I do have copies of both patches; one record demos from client perspective for each client, the other one records serverwide demos and needs more modding for playback.

I don't quite get your point? You could hack the QL binaries to use your server infrastructure and create the required server software by reverse engineering. This happened to quite a few "dead" old games, which are now run as fan projects. Do you mean that it's way more troublesome (and maybe illegal by licenses) than with open source (I obviously agree on that)?

Because it has anti-cheat, global bans, stats and match-making system? :P Also see above for fan projects, those usually only emerge for great games, where the closedness (is that a word? it's late..) does not matter that much.

Okay, this'll be my final post for today. Sorry for all the late double posts or aggressive or ignorant tone. It's getting late, I'll just fall asleep now :)

We don't have a large enough population of players to attract many hackers also ;)

I hope I've shown you it's not about obscurity and that, quite to the contrary, good security shouldn't rely on obscurity but on trust. There can and should be secrets (like private keys), but the algorithms themselves shouldn't need to remain secret for the system to stay secure.


Agreed, it's still limited. To make it more efficient you'd need a third identifier besides ip and uuid, but that makes only sense if it is supplied by a third party.

You could for instance implement a central signing server that checks if a client with a certain uuid has handed the OA-server it wants to play on a valid certificate. If the client doesn't supply a correct certificate its uuid is banned. If a client acquires a new certificate for its uuid with the signing server, the signing server sends a tempban out to all OA-servers connected to it, so the client can't play online right away but has to wait a few hours after acquiring a new certificate.

@grey matter: the algorithm the signing server uses to generate certificates doesn't need to be secret, but only the key to sign the certificates.

Edit: On second thought, the validity of the certificates doesn't have to be checked by the signing server but the checking could be delegated to the OA-servers themselves. (It's getting late in Europe :))

lol.  I love how this topic has blown up from being the sh*t post of a cheater to some serious discussions among lovers of OA.

It's 21:55 for me and time to play so I won't get into the latter posts but I do hope the Devs are following this thread and take away 2 points.

First, an Anti-Cheat System should be included in OA 3.0.  Be it only server-side or whatever.  As with E+, it doesn't need to find all the cheaters.  Simply kicking (not banning) some of the more common and simpler ones is sufficient.  Also, give Admins one or two simple supporting tools like the Wallhack Identifier.  The process of coding and testing may take some time but it has a multiple return on investment.  E+ took months to analyze the raw data from the logs using clean players and all known cheats on special Dev Servers to make sure that clean players were not kicked which is why they recommend using level 3 (out of a 5 level tier). 

Failure to do to will cripple OA's appeal no matter how good the gameplay and visuals are in OA3.  Right now, Combat Arms is losing players to BattleField Play4Free (which uses PB) not because the game sucks but because cheating is at pandemic levels.

In Urban Terror, which has no internal AC System, I have watched the number of active servers and especially players fall dramatically over the past 4 years.  One reason is that 4.1* was released in 2007/12 and UrT 4.2 is taking forever (the last testable release was UrT HD Alpha 0.1 in 2010/12).

But, a major reason is that while the Community has Ban lists (here (http://www.urtadmins.com/news.php)) and various player tools (here (http://www.urbanterror.info/forums/topic/25635-urstats-web-control-panel-anti-cheat/)) the lack of a built-in mechanism turns off many players and forces Admins to deal with all the kiddie cheaters as opposed to being able to play/monitor for the serious stuff.

The WildCat Clan, a well known and respected UrT Clan, recently scaled down their more than 60 UrT Servers worldwide (India, Australia, Europe, USA, etc.) to perhaps 10 and had this to say:

"We have decided to lower our support for Urban Terror and with that we will be taking down more than a few servers. The simple fact is that this game does not have a working Anti-Cheat and it doesn't like it will in the near future. We spend all of our time as a clan busting hackers and dealing with childish players and the reward is very little. We have been moving into newer games and we have decided to reduce our server fleet. We will be leaving up a few servers and still accepting new members but we won't have nearly the amount we did. We thank you for your support over the last two years and we hope you continue to use the servers that will remain. I have started taking them down today and will finish up by the end of the week. The site will be in transition for a little bit while we clean everything up but soon the banners will reflect the servers we are keeping."

- |WC|Runamuk - November 10, 2011 - http://wildcatsclan.net/index.php?topic=8400.msg32237#msg32237  (Forum Acct needed to read the original post).



Second, there will always be naysayers.  People who have no substantive and constructive ideas but make a sh*t load of sound and fury and even threaten to leave the game.  This much I know, if you make the effort to provide a level playing field casual players will appreciate it, it will get press** and become known for fairer gameplay, and the game will grow.



*UrT 4.1.1 was release in 2010 but it's mainly new maps and bug fixes.

**Press, for those non-native English speakers, means news or biographic coverage by various gaming sites and general knowledge bases like WikiPedia which indicates for every game whether is has Anti-Cheating software or not.

Sorry for this Off-Topic post. Someone above mentioned server-side demos. I already heard about them, but I don't know anything exact about them. I thought it would be nice to say something about them (writing what they are, what is needed and how to use them -or at least linking an external site which does-) in the wiki page about Demos. Someone of you can do it? Thank you!
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual/Demos#Server-side_demos

How about that signing server idea?

You set up a server with public/private key encryption to hand out certificates. A certificate consists of the clients uuid/guid, its ip and a UTC timestamp, and the certificate is encrypted with the server's private key.

The OA-server decrypts the client's certificate with the signing server's public key and tests wether the uuids and ips check out and if the timestamp is too old or too young (tempban on new certificate). If the certificate doesn't check out ok the client is simply disconnected.

Pros:
* The client has to request a new certificate when it changes ip, uuid of when its existing certificate has expired.
* The client can't play right along with a new certificate but has to wait unit the tempban on it expires.
* The client can't fake certificates successfully without the signing server's private key.
* The client can't request a lot of certificates in advance because they expire.
* The signing server can detect fraud with lots of certificate requests for different uuids coming from the same ip.

Cons:
* If the signing server goes down (DDOS) or becomes too heavily loaded the party is over and nobody can play online!
* Every player runs into the tempban period at least once a day, when he first starts playing online.
* You have to build a system into the client that requests certificates in advance while playing online, so the client has a new certificate with its tempban period expired before its present certificate expires permanently.
* People with rapidly changing dynamic ips could run into tempban periods now and then.
* The tempban an expiration periods have to be short (minutes rather than hours) so you'll need to hand out lots and lots of certificates.

Someone should activate the Sago signal. :P

I have the impression that all of this should be discussed with the ioquake3 guys, as every ioq3 based project (not only OA) might benefit a lot from this.

Indeed, all these ideas are not specific to OA but could be ported to other ioquake3 games as well, or any other game in fact.


I agree to this concept. But you need to always take good care of the clients input and consider them untrustable. But I see your point in making a trust system with certificates.

Your idea of certificates is a good one I think in theory, and it has the huge advantage of being totally transparent for players and admins, there's no overhead. Anyway, the cons have to be watched out, so that we make sure that a part of the players don't get left behind with this system.

@grey matter: I wasn't talking about NAT for SOCKS proxies, but anyway if someone cheat over a NAT network, we can deem him responsible for the NAT, so if other players on this network complaints, they should see directly with the cheater. So anyway NAT is not really a problem that belongs to the admins of servers but which should be managed directly by the NAT owner (everyone is responsible for what he's doing on the network). The point here is that for dynamical IPs, there are very little chance that we penalize a player that never done anything wrong but just inherited a dynamic IP from a previous cheater.

And about QL reverse engineering vs opensource games: yes that's what I mean, it's way more troublesome, but also reverse engineering is limited (I edited GTV myself to make it work for OA, but I'm limited and can't fix everything unluckily nor add important features that are necessary).

@WaspKiller: thank you for your insight, I wasn't aware that this cheating problem was so prevalent in the other communities. Currently we have very few cheaters because the game is considered old and unknown, but more spotlight it will bring, more problems will too.

@Gig: I will add some infos in the section you've pointed out.
/EDIT: done, and I've made the part about video recording too, though it may need some beautifying.

I think I've substantially reduced problems with my signing server scheme: the signing server should have the option of extending the trust time on a certificate if the client offers it an expired certificate with the same uuid as the client itself has. This means each uuid has to go trough the tempban time only once, which in turn means you can make the tempban and expiration times longer.

For clarity: the tempban time is essential to the scheme, it's the time the OA-servers need before they trust a client's uuid. The goal of the system is to discourage players (read cheaters) from frequently changing their uuid and it does this by punishing them with a tempban every time they do. This allows for more efficient banning on uuid for anti-cheating systems built on top of this scheme.

The problem I see here is that a rogue server admin can capture other players uuid on his server (by simply querying them from the certificate server) and then impersonate them on other servers (using a hacked client and the captured uuid to request a new certificate for his own IP).
You'd also have to use public key auth for the requests from a client to the certificate server to avoid this.

Then we can simply have 2 keys (read uuid here): one that will only be sent to the certificate server, and one that will be known publicly by game servers. Both would derive from the same secret key, but noone would be able to get one from the other, using one-way functions.

http://en.wikipedia.org/wiki/One-way_function

Been doing some more thinking :)

* Extending trust time on a certificate, as I mentioned in my last post, is not a good idea after all. You could request lots of certificates on different uuids in advance and when you get banned you extend the trust time on the next uuid/certificate you requested in advance, breaking the tempban scheme.

* I think GrosBedo's one-way functions are a good way to solve the rogue admin problem. A one-way function basically is a hash-function, so if you make the client send the unhashed uuid to the signing server but a hashed uuid to the OA-server, and make the signing server hash the client's uuid before he puts it in a certificate, you're good. This way the rogue admin only ever sees hashed uuids, but he needs unhashed uuids to request valid certificates. Because all the OA-servers ever see are hashed uuids, they can ban on them just as well as on the unhashed uuids themselves.

New finding that may be useful relating to our discussion about a distributed global banlist: metabans.com

This is a website where you can register, send and manage your bans (with reasons and all, it seems we can even discuss issues directly there), and you can subscribe to other accounts too. Plus there is a B3 plugin to automatically sync your banlists with metabans. This seems to be the perfect medium to share such a distributed global banlist.

Now I don't know very much about this system practically, I will test it out. Anyway, even if it doesn't work out, B3 still has an internal way to make and share such a distributed global banlist.

Uhm, a third-party service which does not even have a proper description for unregistered users? No thanks, I like to keep local backups anyways. I assume they're working with IPs, so this is not of much use (otherwise we wouldn't have discussed on multiple pages).

If they are indeed interesting, don't hesitate to leak their "secret" way of operating ;)

QL does not have any anti cheat system. For more then one year admins say "there will be" an anti-cheat system. they wont tell when the system goes online and what it does.
so far there is none and cheaters are banned when reported by other users and admins confirmed the suspicions.  :-\

the esr and ql forums as well as the ql irc channels are full of frustrated users demanding an anti-cheat system from id software.

(punkbuster does not seem to be an option. it was there in the beta-stage, but it was so buggy, it kept way more normal players from enjoying the game then exposing and blocking cheaters)

@PopeJo: thank you for this interesting piece of information. So QL share the same problem as OpenArena, except that in OA there isn't yet a global banlist. With such a system, we should be on par in this domain. And who knows, maybe OA can surpass QL in the future in cheating detection?

@grey matter: metabans isn't in opposition to the 7's suggestion to make a certificate system to identify users and limit abuses, the two are complementary.
Metabans can work standalone (meaning that you can manually upload your banlist, and download other admins' banlists), but it can also be totally automated using third-party tools, like B3, and this is by far the main advantage. Plus, it has a field to store reasons (which B3 support natively), and a different table to watch players instead of punishing them right away.

This is nothing very innovative technologically, but the concept resides in the web interface that allows for easy sharing and subscription to other's banlists. In this sense, I think it's a very nice tool (and great if it works well, it's still in beta as of January 2012).

About your concerns for privacy, the banlists are anyway to be downloaded on your server, the game engines can't just connect directly to metabans to apply bans. Metabans is only to be used to share, not to apply, so you always have a full backup on your server anyway. Secondly, I trust the author Phogue because he seems to know one of the main dev of B3 that I deeply respect, so for now I give him the presumption of innocence and of good intention.

---------------------------

Also, there was a previous discussion one year and a half ago about the very same issue, with some related proposition (in fact there are mines which didn't change). There is also a patch to authenticate users using a GUID with a RSA 2048 bits key, this might be useful to make a stronger certificate system.

http://openarena.ws/board/index.php?topic=3206.75

The certificate system's encryption doesn't need to be very strong because the certificates are little more than vapor themselves ;) What I mean by this is that because the certificates are issued to anonymous clients which can fake their uuids and change their ips, the certificates aren't very trustworthy in the first place, so they should expire literally within minutes (the more you trust the data on a certificate, the longer the certificate can last before you make it expire). The encryption on the certificates needs to be broken before they expire to be useful for a cheater, and it has to be very weak indeed to be broken within minutes.

To make the system really annoying to cheaters, the initial tempban time on a certificate should be longer than the time the certificate is valid to play with. This way the clients must maintain a "chain" of certificates before they start playing or they can only play a few minutes before being disconnected. Because cheaters have to maintain more  chains of certificates concurrently, they're easier to detect by the signing server (which could write the number of concurrent uuids from the same ip on the certificates so the OA-servers can take action if needed).

I'm thinking about an initial tempban time of 15 minutes and a playing time of 5 minutes on a certificate, this way a player has to request a "chain" of 3 certificates a bit earlier then 15, 10 and 5 minutes before he starts playing online to be able to play uninterrupted. (One could write a little service program that runs in a players system tray and maintains a certificate chain as long as the player's machine is online, which would alleviate a lot of the hassle with tempbans for honest players.)

Edit: a stroke trough the unwarranted conclusion.

Yay!
"The file you requested has been removed from MediaFire for a violation of our Terms of Service or our Acceptable Use Policy"

It was also on his youtube channel, but I couldn't take that one down (I tried actually). I'm glad the downloadlink just got removed altogether ^^.
Btw it was actually removed 7 days ago, but somehow it ended up in my spamfolder and it got pushed down by the loads of spam I'm getting last week.

king orgy bot is trash anyway...

I can beat even the toughest Nightmare bots in single player mode on Agressor, which is probably the toughest map to beat them on since it has no pits that they keep falling in (I use no aimbot BTW). On maps like DM4ish or any map where they tend to fall in pits, they tend to defeat themselves. I find LAA-LAA to be the toughest bot to beat.

One thing I noticed with some people is I used to catch people using aimbots upon spectating them but now I notice that some people I suspect of using an aimbot seem to stop using an aimbot and their skill level drops when being spectated. Some people I suspect of using one simply leave upon being spectated. It would be trivial for someone to write an aimbot that simply turns itself off upon being spectated. Perhaps what we need is an Rcon Spectate so that we can spectate someone without possibly alerting their client (and possible aimbot) that they are being spectated.

One person I sometimes suspect of using an aimbot is C++ (who often enters with various different nicks). IIRC, he's had a history of using them (and being kicked out of various servers for it) and when I spectated him the last (two?) time(s) he shortly left afterwards. The last time he was beating me like 20 to three (and everyone else even had zero) and I've been

A: Playing considerably longer than he has

B: This is a guy who still doesn't really know how to strafe jump (though I'm not exactly the best strafe jumper myself, not by a long shot), I've at least spent some time practicing on some of those practice maps. I've seen him practice and he still has problems overcoming the first few easiest blocks.

When he was caught using an aimbot earlier on he promised that if he gets unbanned he would never use one again but sometimes I wonder.

I don't want to prematurely accuse him of it again but I have spectated a few people using them before and sometimes I suspect people of using it only when not being spectated. So if there were some way for those with Rcon to spectate without anyone knowing, it could be a good thing.

Rcon is a text-only system to control the server. How would you spectate someone with that?

If you wan't to have invisible spectators in game, they either must now show up in the scoreboard and ingame at all or they must be listed as a normal (free,red,blue) player.
You can currently test whether you're being spectated by looking at the scoreboard to see spectators. Depending on g_truePing, someone spectating you will always have the exact same ping as you.

While I think that invisible spectators require quite some hacks code-wise, why not just record server-side demos and review them later? This is opaque to the clients, unless the server prints a huge message about it ;)

Exactly, the decorrelation between a player's aim skills and strafing skills is a perfect example of feature that can help a lot in detecting cheating players.

About your question of making an invisible rcon player, there are two solutions:
- Recording server-side demos, by patching the server's binaries (like what grey matter proposed).
- Connecting a GTV server that will be watching the server continuously, and players connected to GTV can't be seen by playing players.

And about the player you are reporting, this seems to me to be a totally plausible and logical behaviour from a spotted cheating player, who still cheat but more carefully now.

LOL corvette I guess I know why you when spec so much last night . Anyway corvette I was just wonder do you seem to get some weird lag when he is on there just curious

I did notice the server intermittently lags, though I haven't (yet) made the potential connection between server lag and his presence. It's possible that he's doing something to lag the server? (through some twisted form of a DDOS attack?). I'll pay closer attention from now on.

Regarding being able to spectate secretly, Digichalk is not my server (I don't even have rcon there, though I know Sitting Duck does) so I wouldn't be able to do any of what you guys are saying. However, those who set up servers appoint moderators to moderate, it sort of makes sense to give those moderators with rcon the tools necessary to moderate the servers well, such as an rcon spectate command that will allow moderators to spectate in secret. I know aimbots haven't traditionally been a problem with Open Arena and so this probably wasn't thought of early on but they do seem to be a growing concern.

[added in edit]

After entering the server without him there, I notice the server seems to lag anytime anyone else enters. I don't think his presence is related to the server's recent lag, I think it's caused by too many people, though it never had these problems before.

It's called "toggling" and cheaters started doing it shortly after the 1st cheat was made for Q3 in 1999.


However, I throw my hands up when it come to the Skull-Bots... I may even have to leave OA and E+:

http://www.newscientist.com/blogs/onepercent/2012/01/curious-robots-learn-to-intera.html?DCMP=OTC-rss&nsref=online-news

Just found a similar topic in the Tremulous forums (from 2007):
http://tremulous.net/forum/index.php?topic=5386.0