Discussion: fixing the aimbot problem

[ronin2040]

Please, no complaining of who is or isnt an aimbotter in this topic.  It is irrelevant--one aimbotter is not the issue; the spread of them is.

It seems so far that there has been a little discussion in other topics about solutions or fixes to the aimbot problem, but it quickly degenerates into demo postings and arguments of who is and isnt an aimbotter, false accusations, etc.

I would like to have this topic be devoted to brainstorming about potential solutions.

I have a few thoughts regarding this, and brainstormed in #gnu with some others on fixes, and heres what I/we came up with. please add to this list.

*

Some form of global IP/GUID black/greylist.  This seems to be a must.  Whether or not it has potential issues (possible abuse), they can be worked around.  With a global banlist, a ban/multiple bans is/are now meaningful and a pain in the ass to work around.

*Some form of access control.  My thought on this matter was custom compiled client software.  More on this later.  There was also a suggestion of SSL certs which can be requested via game menu--essentially GUIDs which can be controlled serverside.

*require ingame username/password creation?  perhaps allow people to play as "unnamed player", but with restrictions....i dont know.?  Perhaps users having survived a certain length of time (ie, not banned/discovered cheating) get access to faster downloads (http client/map downloads--ie, from tremulous.info).  Make there actually be an incentive to being a legit player, and the anti-cheat restrictions less of an issue for respected players[/list]
Regarding the custom clients, my idea is essentially that when a server starts up, it compiles binary clients/dlls/SOMETHING that must be present on the client end in order to connect to the server.  Hardcoded in it would be the encryption key, password, or whatever required to get in.  Source to the client would be available, but the key would be specified in an external text file.  Thus, GPL requirements are met, but the key is not given out in non-binary form.  What the binary part of the client does, i dont know--im not a programmer.  But it DOES establish some form of trust in the client software, and im SURE that can be used to do many good things--such as purity checks that cant be faked.  Getting around this would require debugging, decompiling, or hex-editing, and im sure many aimbotters just dont have the skill for this.

I think that the goal of any solution to aimbotting needs to be NOT its eradication, but moving cheating back to the realm of the "leet"--so that average-joe-script-kiddie cant just waltz in and pwn everyone.  1 or 2 unstoppable cheaters every month is not a problem; random users with hax IS a problem.  Further, creating obstacles that require a one-time time investment for legitimate users, but more time for cheaters is a good thing.  If we can force a ban to mean IP reset, GUID reset, username change, re-request cert, re-download client, this is progress.

Thoughts?  Criticisms?  Flaws?

[Paradox]

ID used to have a global banlist based off of CD code, but as we dont have that, that wont work.
CPU id anyone?

[ronin2040]

why can it not be an IP/GUID ban?  have the IP part expire in a few days, and the GUID part expire in a week.  If a whole family cant play because of one griefer, well, i suppose hes gonna get his ass kicked by his family, isnt he?  isnt that a good incentive not to fuck up?

Not that this cant be worked around, but it means MORE work on the aimbotters part--GUID reset, IP reset, and possibly jumping through more hoops depending on what else is set up

[Paradox]

Ip bans =evade with proxy
GUID bans=delete guid file, presto new guid

[ronin2040]

could a proper reverse dns name not be required?  It seems most if not all ISPs give clients reverse dns names like "ipxx-xxx-xxx-xx.dc.dc.cox.net." (mine, with ip x'd out).  Perhaps check against a list of proxies....noone should be gaming through a proxy--thats like using torrent through proxy.  The extra latency is no good.  Proxies can be stopped, i think.

[Evlesoa]

and that karma thing, wouldnt work...

It would be abused on me, even tho i dont hack, I would be like the first person to be banned, cuz ppl gonna negate the good, and im gonna have a karma of like

-27
Reason: Haxx0r
Reason: Something
Reason: fking HACKER!!!
Reason: STUPID HAXXER
Reason: And So On

+8
Reason: Iunno
Reason: Legit Player
Reason: And so on

and with such a big... 19 point difference im sure to land myself bans...

[David]

As I posted in the other thread, the second idea would be easy to avoid, and break the quake3 protocol.
IP and GUID bans both exist, and a way to share them would be easy.  It hasn't been done as both IP and GUID are very easy to change.
Also, ideas needing a master server have been thrown out time after time, search for the exact reasons.

The only new thing here is the compile a client idea, which I have already said about.

Traditional system wont work either because the game is free (cash), or because the game is free (freedom).
People need to start thinking much further out side the box is any usable idea is to arrive.

[ronin2040]

David: responses to your issues from other thread
(size of source, Quake3 compatibility, key being handed out, etc)

in terms of the source, etc, i checked with the people on #gnu, and they basically said, that as long as source was availible (and not necessarily sent thru the game--it could be available on the main tremulous page), youd be fine.  Further the source might contain a line like (forgive my pidgin code)

Code: [Select]

$key= read_from_key.txt
the file containing the key would not be need to be included--anyone could compile the client, just not the one needed to join any specific server.  The key is not a part of the code.  This is legal with GPLv3, as i understand it.

So there would be no need to download a 11meg tarball (posted on site) and the key would have to be extracted from the binary with a debugger or hex editor.  Im betting that alone will cause a reduction in aimbotters--how many will have access to a debugger, or know how to hex edit?  (the ones who can program arent the issue; its the ones who go and DL random hax without knowing how they work who are the majority).

As for breaking quake3 compatibility....well, i cant comment on that.  But perhaps some sacrifices would have to be made to solve this issue.

one last note, could it not be possible to have the game do HTTP downloads?  most people recommend that you download the maps directly from tremulous.info, as it is MUCH faster.  Why can the game not do this?  why can certain of the bigger servers not have their custom client hosted there, for a quicker download (perhaps throttle it to 30kbyte)

I do agree that people need to think outside the box, and that there are some flaws with my idea.  Im just throwin some out there, since not many others seem to want to.  So far the general feeling on the forums seems to be "lets just bitch and moan about the aimbotters" rather than "lets brainstorm how to fix the issue".

[David]

in terms of the source, etc, i checked with the people on #gnu, and they basically said, that as long as source was availible (and not necessarily sent thru the game--it could be available on the main tremulous page), youd be fine.  Further the source might contain a line like (forgive my pidgin code)

Code: [Select]

$key= read_from_key.txt
the file containing the key would not be need to be included--anyone could compile the client, just not the one needed to join any specific server.  The key is not a part of the code.  This is legal with GPLv3, as i understand it.

If the key is compiled in, then it has to be distributed.
As my understanding goes, everything needed to make an identical copy is needed, so the key would have to be distributed.

So there would be no need to download a 11meg tarball (posted on site) and the key would have to be extracted from the binary with a debugger or hex editor.  Im betting that alone will cause a reduction in aimbotters--how many will have access to a debugger, or know how to hex edit?  (the ones who can program arent the issue; its the ones who go and DL random hax without knowing how they work who are the majority).

Assuming you don't send the key, its still going to be relativity easy to extract, unless you encrypt it, and I have no idea how doable that would be.
hex editers and debugers are easy to come by, and people could still make hacks that automate the whole process.
Not having to send the source is a good point, although you have to make sure the source is always available, and banning IP's that download it erc would be illegal. (I think).

As for breaking quake3 compatibility....well, i cant comment on that.  But perhaps some sacrifices would have to be made to solve this issue.

Tremulous is based on ioquake3, and all the core tremulous devs are also on the ioquake3 dev team.  Breaking compatibility would be turning there back on vast amounts of code, code that otherwise would never be added to tremulous.

one last note, could it not be possible to have the game do HTTP downloads?  most people recommend that you download the maps directly from tremulous.info, as it is MUCH faster.  Why can the game not do this?  why can certain of the bigger servers not have their custom client hosted there, for a quicker download (perhaps throttle it to 30kbyte)

HTTP downloads are already on most servers.
Tremulous.info is long dead, most servers use either there own repository's or the MG one, and all the latest clients have the ability to use them.

I do agree that people need to think outside the box, and that there are some flaws with my idea.  Im just throwin some out there, since not many others seem to want to.  So far the general feeling on the forums seems to be "lets just bitch and moan about the aimbotters" rather than "lets brainstorm how to fix the issue".

Fair point.  I would love to see a solution to the problem, just I don't think this is it.  I am also surprised by the lack of posts from those in the know.  There are lots around here who know a lot more about this sort of thing than I do, who could provide a lot of valuable insight, hopefully some of them will share that insight.

[BeerBastard]

Ok we have had problems with people who can just reset there modem for a new ip. Than you keep having to do !namelog to compare subnets.  

I know if you ban a subnet you will affect more than the target.  What would help alot is, if someone wrote a patch. That tells admins when someone enters the game with the same subnet as someone who has been banned.

It doesnt really fight hackers, just gives admins another tool to do there job.

Maybe even have it list them as a possible ban dodger in listplayers.

[ronin2040]

personally, i think that if we can force the aimbotters to take extra steps (resetting modem, changing name, resetting guid) we are making progress, even if its small.  I look at it like DRM: if its working right, its making more trouble for illegitimate users than legit users.

I also wonder if its perhaps not a good idea to NOT ban by GUID?  what i mean is, i have a feeling most aimbotters are essentially ignorant of how the aimbot, the network, etc works.  So if we can make it so that they can still get in without resetting their GUID, then we still have a way of keeping tabs on them (perhaps without them realizing it), and manually kicking.  If we DO ban by GUID, chances are theyll just reset ip and GUID and we will have to find them all over again.

Just a thought.

[Odin]

Seriously, the client is open source. Making things like this are futile.

[Mispeled]

Maybe it would be a better approach to educate the community about what an aimbot looks like (and for that matter, what an aimbot doesn't look like to prevent the McCarthyism that's been going on) to allow for very quick action on a server to get the aimbotter kicked before they are there long enough to be too disruptive. For example, here's a quick list of things to look for:

1. Fires weapon at maximum speed possible. (i.e. - doesn't take time to aim.)
2. Very sudden instant jerks to target.
3. Perfectly follows target behind barriers.
4. Is extremely accurate with hitscan weapons (lasgun, shottie, MD, rifle) but no timing with slow projectile weapons (pulserifle and luci).


These are some signs of a skilled player, not an aimbot:

1. With weapons like shottie or MD, doesn't fire at maximum speed possible, but waits for target to enter crosshair before firing.
2. Smooth motion to target (or even just quick motion, but not instant).
3. When jumping around a corner, will fire at a common spot for enemies to hide/wait.
4. Comparable skill with hitscan and slow projectile weapons. (Side note, if you're accused of aimbotting, it might be a good idea to change to pulse rifle as proof you're not.)


Of course, there is the question of other hacks like auto-firing and aimbots which may have unusual behavior. Keep on the guard, but remember that everyone is innocent until proven guilty.

[David]

personally, i think that if we can force the aimbotters to take extra steps (resetting modem, changing name, resetting guid) we are making progress, even if its small.  I look at it like DRM: if its working right, its making more trouble for illegitimate users than legit users.

Hackers already have those barriers, and DRM punishes the legit people a lot more than it hurts me.

I still think that flooding the market with dodgy aimbots is the way to go.  Release 20-30 a week, spam them here and on 'hacker forums' and in game etc, and then why you run them have them log info to a remote place, and bork the users tremulous install.  Maybe bork there entire system.  Maybe even change there desktop background to goatse, and stop them changing it

[Taiyo.uk]

A global banlist will not work since this is essentially a database of client IDs that can be changed. Even the Q3 CD-key based system was broken (use someone else's key, use a keygen, etc...)

Server-generated GUIDs will only be effective if unknown clients are denied access. Then it's the administrator's problem to issue GUIDs to known non-abusive players.

Having to create an in-game username/password every time is not a deterrent to griefers, but it will be an inconvenience to legit players.

A hardcoded key is a) easily crackable and b) requires everyone to patch when it is cracked.

There will always be some people who will decon, teamkill, spam abusive chat messages, and go to great lengths to circumvent any barriers to do doing so. The heavily team-based gameplay makes tremulous a griefer magnet.

I've had the most fun and had the least grief on servers with decent and regularly active admins. I doubt there is a "silver bullet" solution to griefers.

[tuple]

Mispeled, educate on what an aimbot/wallhack/etc looks like, %100 agreement.

My ongoing suggestion, one which I am too thick headed and ignorant of C to implement, has been a username/password scheme.

*Player goes to website (any website, one set up and/or supported by a server operator or numerous server operators)

*Player sets up a username/password to access a server (website can be created by the operator/operators and all it does is store that info in a mysql DB.)

*Player connects to server X using said username/password.

*Server recieves username/password(hash really, which it could unencrypt with it's private key or using another method to prevent sending usernames/passwords unencrypted over the wire) against DB to see if this user is allowed access.

This is not easy, as it would require a modified client and server (which is my complete guess, but seems a reasonable guess.)

Its not centralized.  Noone is responsible for keeping the DB up to keep tremulous going.  Operators could choose to share a db, creating a type of centralization that is solely based on choice, but is neither required nor need be the only DB.

Potential benefits -
Multiple servers could choose to share a db, a player kicked from one server "could" be kicked from all servers sharing that particular db, be it 2 servers or 20.

Setting up of usernames/passwords could be moderated.  It doesn't have to be instantaneous, and blocking access from proxies, while not %100 effective, can stop most casual greifers/botters from bothering to set up multiple usernames.

Servers could use there own DB, or could choose to share a DB.  Banned greifers could end up being banned simultaneously from multiple servers, making a ban more severe.

Bans could be tracked based on their source server, and other servers could pick and choose which servers bans they would automatically support.

Admins could be tracked in the DB.  A server could pick and choose which server's admins they'd trust (though I see this as possible, I suspect most operators would choose to pick their own admins, and wouldn't trust other operators admin picks as much as they'd trust other admins bans.)

Servers could choose to allow X number of unauthenticated "unnamed players" to let untrusted people in to play freely.

Complications-
I imagine it would require a considerable amount of modifications to the tremulous source to work.

DB design could become complicated to account for tracking various servers, bans, admins, whitelists.

DB access would need to be tightly controlled.

DB going down could mean no access to any server, unless the server side code defaulted to letting someone in if DB access could not be obtained.  An admin whitelist could exist on the DB for individual servers, but actual admin rights held on the server so admins could still "admin" if the server went down, and calls to the DB are not required for each admin command.

The operator of a shared DB would have to be a highly trusted member of the community, as they would have an incredible amount of power over who is/isn't banned, etc depending on the number of servers sharing their particular DB.



Again, I have no ability to make this a reality.  Learning C, learning the tremulous code, learning the design necessary to connect securely to a remote DB, etc.  I suppose theoretically I could, realistically it would take me an enormous amount of time and it would probably end up filled with security flaws and bugs.

I've thought more about this, about the DB design to keep servers independent but leave them the ability to integrate to whatever level they choose while still sharing a db, but this is so long it's even boring me, so I'll stop

edit: Nah, forget it.  Lets follow david's suggestion and repackage loads of adware as "trembot-2007" and the like!

[se7ensnakes]

Aimbotting is such a problem that is killing this game.  New people start the game but they are killed instantly.  I have been playing for years and I get killed so easy.  I dont know if they are aimbots or not but as soon as I emerge I am shot by a mass driver with deathly accuracy.  No matter how i move around I get shot with very few bullets.  If you are a human the tyrants have the ability to kill you from a good distance and they never miss.  I can play with someone who is not an aimbotter.  But as soon As i play with an aimbotter it is impossible.

[/dev/humancontroller]

those are more likely to be triggerbots, by the way. they don't aim for you, but delay your attack slightly to perfect your shot's timing to be more on-target. such augmented shot timings are almost impossible to discern from purely human shot timings.

[Nux]

I dont know if they are aimbots or not

I can play with someone who is not an aimbotter.

How are you so sure about the latter, given the former?

[Undeference]

I dont know if they are aimbots or not

I can play with someone who is not an aimbotter.

How are you so sure about the latter, given the former?

I don't know if they are [adj.] or not. I can play with someone who is not [adj.].

See if it makes sense for racist, British, animate, any other adjective. (Hint: it does.)

[Nux]

I don't know if they are [adj.] or not. I can play with someone who is not [adj.].

See if it makes sense for racist, British, animate, any other adjective. (Hint: it does.)

I take it you think he's talking about personal preference. From the full quote it's pretty clear to me that isn't the case.

I can play with someone who is not an aimbotter.  But as soon As i play with an aimbotter it is impossible.

He seems to be saying he is able to hold his own against non-botters but is unable to do the same against botters.

My point is that if he can't actually tell whether or not they are botting, he can't make any well-founded statements about how well he plays against botters vs non-botters.

In other words:

I don't know if they are a player with which I don't know if I can play or not. I can play with someone who is not a player with which I don't know if I can play.

[Undeference]

I take it you think he's talking about personal preference.

I don't know what you mean in this context. I commented on what you wrote with little consideration for se7ensnakes's unquoted statements. You asked, "How are you so sure about the latter, given the former?". "I dont know if they are aimbots or not" has no affect on "I can play with someone who is not an aimbotter.", given that "someone" does not make sense as a member of "they".

However, I am convinced that when se7evnsnakes said "I dont know if they are aimbots or not", that was effectively a lie (maybe intended to be read as "I can't prove they are aimbots"). Consider the lead up:

Aimbotting is such a problem that is killing this game.
I have been playing for years and I get killed so easy.

Also note suggestive keywords in the full quote "killed instantly", "deathly accuracy", and "never miss".

[Nux]

With regards to you not understanding my saying 'I take it you think he's talking about personal preference', I can put it another way: Did you think se7ensnakes was just saying he doesn't like to play with botters?

I commented on what you wrote with little consideration for se7ensnakes's unquoted statements.

Alright. That was wrong to do. When you do that you miss out on a bunch of assumed knowledge that I leave out for brevity since the people I reply to don't need to be told the full details of what they themselves said.

I could be pedantic about this but that would know doubt go on endlessly. Suffice it to say, I don't believe se7ensnakes can tell the difference between a good player and a botter and I base this solely on his own declaration of doubt when he said "I dont know if they are aimbots or not". If I'm not to believe him about that statement, I feel I've equal justification to disregard his entire post.

P.S. I think I've missed debating off the cuff remarks made by random users of these forums.

[ULTRA Random ViruS]

I have never seen an aimbotter in two years. Also aimbots aren't 100% accurate when used on a shitty box. I tried it once, turns out my aim is bettery than nullicry's in most scenarios at the time.
As for triggerbots, they are indeed a problem, but there are a number of people in this world who play just as good. I'm not one of them, but the way I use (or used to) a mass driver is a trigger-bot style. I try to click just before the enemy goes over my crosshair. This method really only works on some servers due to the unlagged server frame-specific bias and send/receive connection pathways being inconsistent (i.e. send path is longer than receive path, forcing the user to have to aim slightly behind their target).

[CreatureofHell]

tl;dr

Virus used aimbot ban plz.