Unity Anti-Cheat solutions

Question

I'm currently working for a websites client development team and need guidance on where to go for anti-cheat with unity.

We have scripting, where a user can code in their own features via a editor we have made in lua, with a scripting api that allows them to interact with parts of the game via said scripting, others can exploit this with tools and execute scripts on games that didnt have said scripts, via "hacking". I'm trying to stop script execution exploit(eg scripts being executed that weren't put there by the author) and general hacks such as speedhacks, assembly injection, etc. We have tried the anti-cheat toolkit but it hasn't worked well for us. In terms of execution we have the lua5.2 library in a dll, of course they can hook this library and execute anything via luas execution functions built in, statistcally linking the library would help defend againist this but that is not a option that is easily done in unity, so anyone could just hook it and execute any script/lua they want. we have server-side scripts(executed on server) and client/local-side scripts(executed on client/locally), we've done our best to secure these but we're looking into more ways to help protect us, such as anti-cheat.

We have plans to possible invest into paid anti-cheats in the future such as battleeye, easyanticheat, etc.

we currently don't make a lot of capital and i have no experience making any type of anti-cheat nor anti cheat in unity, where do i start and what do i do?

Answer 1

You said you are primarily targeting web browsers as your platform. That means that 3rd party anti cheat tools (ACTs) won't work for you. These tools work by hooking into the users operating system and looking for any suspicious activity. A browser-based application does not have permission to do that, so it won't work.

But even if it would work, ACTs aren't 100% effective. In they end, they too are are just software. And any software which runs on the user's hardware can be manipulated. I have played a lot of multiplayer games where rampant cheating was going on despite there being an ACT. Hackers were able to either hack the ACT itself and disable it or were able to find hacking methods the ACT was unable to detect.

Rule number one for cheat prevention in online games is never trust the client. The client is in the hands of the enemy. The player can do what they want with your client and there is nothing you can do about it. That means that cheat prevention is not the responsibility of the client development team. It is the responsibility of the team which designs the network protocol and the server backend. They write the code which is not under the control of the end-user.

• Any calculation where cheating gives the player a notable advantage must happen on the server.
• Any information the player must not know about should not be sent to them over the network.
• Any input validation ("Can the player actually attack right now?") must happen on the server. Client-sided input validation for the convenience of the non-cheating player is optional.

If you properly follow these paradigms, then allowing client-sided scripting isn't actually all that risky. The player might try to set the coordinates of their character to somewhere at the other end of the map, but the server won't accept these coordinates and act as if the character is still in its old location. That means your scripting API should not have any functions which "do" stuff. It should only have functions which "request" stuff and allow the player to implement error handling if the server denies the request.

I would argue that adding a scripting engine makes the game even less cheatable, because the one thing you can not prevent with an authoritative server - automation - becomes a legit part of your game design.