Openspades: Anti-cheat integration

[rz5]

BuildNShoot/OpenSpades is plagued with people using a variety of hacks like aimbots and wallhacks.

There is at least 1 plugin for PySpades which, based on the accuracy and kill/death ratio, will automatically kick potential cheaters off the server, but this is not at all enough

Ideally, OpenSpades (and PySpades by extension) would integrate BattlEye/EasyAntiCheat/Valve Anti-Cheat to stop cheaters from playing with regular users.

If OpenSpades were a Steam app, it could take advantage of the Valve Anti Cheat engine. Since it's not, I only know of BattlEye and the other two written above. I am unaware of FOSS alternatives to VAC.

[VelocityRa]

It's possible I'm missing something here, but -given that you're suggesting clients side checks- couldn't someone just remove the anti-cheat code?
We need server side control for this to make any sense (and worth our while), which means it falls into next-gen protocol territory.

[feikname]

I like the idea of having OpenSpades on Steam for next-gen, that would probably make it easier to revive the community.

[rz5]

Since the client is open source, someone could alter the client to remove cheat checks, yes. So whatever the solution is, it has to take that into account.

I'll throw this out there and see if it sticks: to join 'protected' servers, users would have to download a 'protected' build, which would be signed by the OpenSpades team. 'Protected' servers then check for this signature, somehow. The underlying idea is to try to use the concepts of public-key cryptography in here, somehow.

And I'm guessing this little idea would necessitate users to own registered accounts and stuff...

[feikname]

@rz5 thanks for the suggestion!

Ace of Spades has had a problem with cheating for a long time already, and is a issue that indeed needs to be solved urgently. However, the focus now is releasing 0.1.0 (and probably 0.1.1 next, judging from the trello board).

Any new features not compatible with current AoS 0.75/0.76, such as this one, will be left for the next-gen protocol project, which is paused for now. There is no prevision of its return, but I have hopes for 2017. The main goal is to keep and grow the current community into a continuation of AoS.

I am closing this issue for now. As soon as next-gen protocol development returns, it will be reopened and dealt with.

---

EDIT: Please note that even though this issue is closed for now, if anyone wishes to add something relevant to this thread, feel free to add your comment.

[VelocityRa]

So, I did some reading on this yesterday and my suspicions were confirmed.

You can not protect an open-source game, in the same way that you can't protect a closed source one. The only difference between them is _how easy/difficult_ it makes things for crackers/reverse engineers.

A client anti-cheat like you suggested is out of the question.

Furthermore, OpenSpades being completely free to play makes our job seemingly impossible, since hackers can get a new account and try again in seconds, even if succesfully identified by our system. There is no incentive not to hack, as you'd have with a 50$ game. A suggested solution is a free game, but a paid master serverlist that's guaranteed to be hacker-free, but I understand that's not ideal for OS.

So, given the last paragraph, what can we do?

---

1) Server-side logic

There is no way around it, don't trust the client, or expect cheaters to succeed.

• The only sure-fire way to not allow for wallhacks and the like, is to simply not send that data at all. This would require a bit of processing by the server, however, and for FPSs like OS where we need to be very considerate about visibility, implementing this will probably not be trivial.

• For aimbots, there are some possible ways to detect them depending on angular (aim) velocities and precision (for no-recoil hacks), but false positives are a posibility, which is not ideal to say the least. In addition to that we'd need to send more data to the server, which would result in more lag; both because of the need to send more data, but also because the server will have to do more of the logic for each client.

2) Admin/Report tools

The essence of the problem is social, not technical. Either only play against your friends, or live with cheaters (possibly alleviate the problem somewhat by finding a social, not technical ('cos there isn't one), solution to cope with the cheaters).

In-game ways to report and kick/ban people, could be a good solution to this.

As to how these would stick and not be bypassed by a simple username change, an IP + MAC + hardware fingerprint with a banlist could used. Those are of course bypassable too for a determined griefer, but it might be good enough for our purposes.

[VelocityRa]

This should not be closed, it has the Next-gen Protocol Milestone after all.
Edit: @feikname I saw you've closed most Next-gen Protocol Issues, I'm not sure we should do that (except for Issues that probably won't be addressed at all). On the other hand the time frame for NG is not known (could be pretty far), so I suppose it makes sense, I'll close this too.

[feikname]

@VelocityRa I am not very sure if we should leave them closed or open too.

I've decided that as next-gen protocol development is abandoned they should be closed, because:

• They're probably not going to be dealt with anytime soon
• They pollute the open issues we have to deal for now.

Recently, I also changed a lot of colors in the labels to see if it makes them more unique and easy to distinguish from one another and added some other labels too. (the ones for Pull requests start with the PR: prefix)

We can further discuss this in email (mine is [email protected]) too. But I will only be able answer later.

---

EDIT: I was not able to complete the comment because I was typing from smartphone and accidentally hit the reopen and comment button in the middle of the writing proccess.

[feikname]

I accidentally hit the reopen and comment button, I am typing from my smartphone, sorry.