[TF2] Anti Cheat requests

[sapphonie]

Hello,

I've done a ton of anticheat for Source 1 games and mods. I've also written a from scratch serverside anticheat solution that has banned thousands of cheaters - though strictly server side anticheat should never be the ultimate solution to cheating in multiplayer games - I do have some server side suggestions to seriously curtail several networking issues exploitable by cheats in Team Fortress 2.

For the record, these fixes ( specifically the sv_maxunlag bandaid, and the sv_maxusrcmdprocessticks adjustment ) have been heavily tested, not only by myself with StAC, but also by players in the popular TF2 mods Open Fortress, and Team Fortress 2 Classic, with no noticeable issues - though these are all small fry situations compared to a game as gargantuan as TF2.

"Backtracking"

Backtracking is an exploit involving crafting ( or replaying ) a usercmd with a tickcount behind what the client's tickcount should be, to hit a client further "in the past" than what would normally be allowed. This can be exploited to backtrack players (hit them) up to up tosv_maxunlag seconds in the past.

Example:

backtracking        Usercmd - tickcount 100 <- You can now hit a client 28 ticks in the past!
previous legitimate Usercmd - tickcount 127
2nd prev legitimate Usercmd - tickcount 126
3rd prev legitimate Usercmd - tickcount 125
4th prev legitimate Usercmd - tickcount 124

There are several possible solutions to this problem.

Solution number one: A bandaid

Set sv_maxunlag to 0.2, down from 1.0, this is the default for CS:GO and a lot of other Source games. This clamps the maximum amount of time that a client can hit someone in the past to 200ms.

This is a bandaid fix, and hurts clients with more than 200ms of ping, as their shots will need to be "led" above this ping (probably? Haven't verified.) Further, I'm not sure of the impact this would have on projectiles. Though, in this scenario, they are likely not having what I would call a "playable" experience anyway... so who knows.

Solution number two: A proper fix

Disallow clients from replaying / using tickcounts significantly in the past, by keeping a record of the client's "maximum" tickcount value, and discarding usercmds with tickcounts older than ticks in the past, e.g. 4? 8? 16? etc.

E.g. something vaguely like this, I haven't tested this, but this is about what I mean.

// Called during player movement to set up/restore after lag compensation
void CLagCompensationManager::StartLagCompensation( CBasePlayer *player, CUserCmd *cmd )

    ...

    // correct tick send by player
    int targettick = cmd->tick_count - lerpTicks;

    uint tickWiggleRoom = 8; // Adjust as needed, probably put in a cvar
    if (cmd->tick_count <= (player->maxTickCount - tickWiggleRoom)
    {
        Warning("Client tried to send a usercmd with a tickcount significantly lower than their most recent usercmd??\n");
        // cmd.Reset();      maybe?
        // CUserCmd nullcmd; maybe?
        // cmd = &nullcmd;   maybe?
        return;
    }

You could also clamp the tickcount and avoid discarding the usercmd. That's up to preference.

You could also keep an array of the client's previous ticks up to TIME_TO_TICKS( sv_maxunlag ) etc and check them individually, but that would be slow, and ugly.

Fake latency

Fake latency is when a client delays their packets to the server by manipulating their sequence number ( in INetChannel::SendDatagram ) . I'm not sure of the best way to fix this, but a naive (shotgun) approach would be setting sv_maxunlag to 0.2 as explained above. Another possible solution could be clamping m_nInSequenceNr somehow? Maybe implementing some clever checksumming / encrypting into packets to try to prevent tampering? You could check if their reported netchannel ping is anywhere near what INetChannelInfo::GetLatency returns? To me, checking GetLatency seems like the best solution, but I haven't tested any implementations of any of the above.

Fakelag

"Fakelag" is when a client regularly "lags" (stutters), by periodically choking and sending packets at set intervals, essentially becoming impossible to hit by other clients.

A naive punitive "fix" to this would be to implement some sort of checking based on usercmd timings, but there is a better solution: adjusting the value of sv_maxusrcmdprocessticks, which also fixes the next exploit...

Doubletap

"Doubletap" is when a client manipulates their m_nTickBase in such a way that they can quickly fire off two hitscan ( and possibly projectile? I haven't checked ) shots ( you can see an implementation of this cheat in action here and here ).

I don't have a super in depth understanding of this cheat in particular, but it is also essentially clamped to the value of sv_maxusrcmdprocessticks, as if a client calls CL_Move more than sv_maxusrcmdprocessticks times, extra usercmds will get discarded.

sv_maxusrcmdprocessticks is defaulted to 8 in CS:GO (and several other Source games); I see no reason why this couldn't be set in TF2 as well... unless there's some wacky edge / corner case that I don't know about.

Bots

Unfortunately, I don't have any blockbuster ideas to fix bots, at least not in game, as VAC would have to be updated, likely with some sort of AI trained solution - I'm very sure there's ways to differentiate a headless client using a navmesh from a legitimate client, and to find and ban a cheater thru extremely abnormal mouse movement - though while I'm thinking about it, it would help if TF2 networked much more accurate mouse movement in usercmds, as it would make it much more possible to implement something even vaguely resembling this thru serverside mods / plugins.

Short of that, a possible bandaid would be to disallow more than <x> connections from the same IP address, but this is likely a bad solution.

Anyway, I hope this can be of some assistance, and thank you for your time.

Thanks

- sappho

[Platina6978]

this is terrible information

Care to explain why?

[Ashetf2]

this is terrible information

Care to explain why?

It's a stolen account just to troll people

[sapphonie]

they are barebone explanations of cheat features valve already knows about with no explanation of how to patch them (yes, clients WILL send commands that seem to go back in time and it's not just due to UDP either). sharklaser has more thorough explanations and source code that they can drop in to patch

sure, these are pretty simple explanations and vague fixes. i'm not a valve employee, nor am I getting paid to do this, i don't have any interest in doing an excessive amount of free labor for a multi billion dollar company which has proven time and time again that it does not care for the players of several of it's most popular games - i only care about the players and communities suffering because of this lack of care. however, i would hope that valve wouldn't just "drop in" any code from... anyone who isn't paid by valve, because of IP/copyright etc issues as well as potential security issues (which has seemingly been proven from the few small fixes that i've gotten in the game, which were not just "copy pasted", but rewritten by valve employees / contractors) - let alone code from a known and prolific cheat developer.

as for commands that go back in time, yes, this is absolutely true, but tickcount should essentially never be repeated or go backwards. this is confirmed by experimental evidence and by... how the engine works - how could a client even manage to jump backwards more than a few ticks? there's no mechanism i can find that would allow for this, outside of insane packet loss / poor networking conditions, in which case the client is already mispredicting and having a terrible time anyway, so why should that be catered for...? even so, a simple buffer solution of a few ticks (8 is a good starting point and probably already too high) would work better than the literal nothing that exists currently.

[feuiuxbe]

As a player who bought this game 17 years ago, can I ask if Valve does something with cheaters and bots? Sorry for necroposting

[AwesomeCoder412412]

As a player who bought this game 17 years ago, can I ask if Valve does something with cheaters and bots? Sorry for necroposting

They have not, are not, and most likely will not ever work on a serious anti-cheat for this game. The most we will get are band-aid fixes and such. The situation will not significantly change until the bots hosters get bored and stop, or valve shuts down the servers for this game.