cheat protection is non-existent on the linux client

[jarcode-foss]

There's a (linux) cheat that actually utilizes the in-game outlines that is normally used in demos and is able to simply change the memory for player entities in a particular struct to get a working wallhack - this is ridiculous and there should be some sort of safegaurd to prevent this (re-using the game's code/shaders for most of the cheat to work is a joke).

I also have reason to believe VAC simply does not do anything on linux:

• You can open upon /proc/<pid>/mem and hack away at the game. You can periodically check for file descriptors open in linux, one way is using libprocstat (an example can be found in fuser's source code).
• I have not tried LD_PRELOAD'ing any libraries, of which the best fix would be to used a patched linker for ELF executables in the steam runtime (if it is currently possible to exploit).
• The ptrace system call is also very likely to work to peak into the process's memory space. I can't think of a sane solution to prevent use of this system call, but I found this gem on SO where they hack away the syscall by writing to kernel memory.

even though most client-side AC measures will eventually get hacked away, it's probably worth preventing the most trivial cheats from working.

[Vash63]

VAC doesn't prevent cheats on any OS, it never has. It is designed to detect and ban accounts using them at a later date. Generally the bans are delayed after they're reviewed by Valve.

I hope you didn't do your testing on a primary account because I'd hate to see it ban you later for it.

[jarcode-foss]

In my own test case, (and responses from many others using the same source code for the cheat), VAC does absolutely nothing. Some people have been using it for months.

And as far as I'm concerned, there are mechanisms to prevent other programs from opening the game's process handle on Windows and they sure don't allow the game's outline shader to be used as a cheat.

(delayed game bans also make no sense for something that could be detected immediately on the client)

[jarcode-foss]

Just because it's possible to write a kernel module to hack at the game's memory doesn't mean there should be zero measures in the first place (again, it is something within the scope of CSGO devs to add a safeguard to prevent goofing around with player outlines) - and preventing access to /proc/<pid>/mem would make any userspace cheat have to resort to using ptrace or a kernel module.

@tpruzina emacs > vim

[MrSchism]

@tpruzina That's some slick code. Thank you for not posting complete code, by the way. That'd have been a pain in the ass to moderate. As well, thank you @wacossusca34 for not putting a step-by-step. I know that I, for one, appreciate not having to handle the aforementioned copy-paste kids.

[MrSchism]

There still are. It's something like a guerrilla war we're fighting. I've left many things to just simmer because people won't listen (a la the PlayOnLinux/Wine requests).

Github accounts are free, so in those rare occasions we ban, they can come back in larger numbers.

[paziman]

Just found this thread so my cents to here too.

In windows a mouse guidance is far more simpler than LKM posted earlier and hard to detect. I can give clues to someone working with VAC tho.

I will not also post here any clues how to do those tasks.

[spychodelics]

Not that i dont want a cheat proof enviroment, the problem i see so far is, that with every method to prevent someone from abusing this.

[brcly]

^^

Interesting that you have a fork of "AimTux" on your GitHub repository.

If you want VAC then I'd recommend not using it.

[LWSS]

I think this is more of a feature than an issue, thanks guys!

[yyny]

@tpruzina Most Linux cheats push new commits pretty much daily, so good luck trying to block their binaries in the first place. Besides, were VAC to exist on Linux, cheat developers would most likely have full access to the VAC code anyway, Linux binaries are very easy to decompile, debug, and modify.

What CS:GO needs is dedicated cheat detection, no more spin bots and impossible wall bangs, they are easy to detect with dedicated detection. But Valve barely has CPU power to calculate decent deathmatch spawns (lol, but for real, they have publicly stated that they don't have the CPU power), so they will definitely not have enough CPU power to calculate even something as simple as a player perfectly spraying a person in the head through a wall without ever having seen them. They have stated recently that they are working on AI to detect cheating, but I don't see any benefits for using AI over dedicated detection, as it will have to pass a review process either way (can't go banning innocent players now, can we?), and AI will only cost more CPU power to reach dedicated detection results, if Valve is even working on making AI with reasonable performance in the first place. The only argument I have for AI is that it's cheaper to maintain in the long run. For this same reason, they are probably also looking at how to make the AI take up as little CPU time as possible, without bothering about performance too much.

@LWSS This is definitely a big issue. VAC doesn't even work reliably for Windows cheats. Every few prime games I get a blatant cheater, especially on the higher ranks. On non-prime it's even worse, can't find a single game without one there. Let's not make it any easier for them. As @tpruzina said, though, this isn't the right place for a VAC issue, and like I said, it isn't looking like Valve is trying to implement dedicated CS:GO cheat detection either.

The future looks bleak.

[LWSS]

Server sided Anti-cheats are too hard :^(((((( t. Millennial Graffiti Artist

P.S. Check out our new Glove Skins! xD!

[agrecascino]

@LWSS I know we have tons of cheaters, but hey we're making more skins! Now: Weapon and glove skins with stickers. Soon: Boot skins and helmets.

[yyny]

@tpruzina Honestly wondering if you even understand the point I make in my comment, or if you even play CS: GO to understand how terrible VAC is. I just got my 3th 7 day ban for being kicked from a game vs rage hackers.

So what? You think they do md5 on a mmaped region or executable?

They actually seem to do something very close to this, but that's not even the point. I have several debuggers, loggers, and applets running that will automatically inject CS: GO, some even specifically target it (My teamspeak client, for example). They shouldn't be detected by VAC, and AFAIK they aren't. How can VAC detect if what I'm running is a debugger or a hack if the debuggers and hacks both change shape every day? I can guarantee that I will be able to load any recently updated hack into the CS: GO Main Menu over and over again forever without being detected. Valve knows this, and doesn't care. As long as you don't use your hacks in-game, as long as you're not connected to a Valve server, you're perfectly safe.

VAC does exist on Linux. It functions virtually the same way as on windows (payload modules naturally differ).

In the context of CS: GO, it does not, or at least, is not nearly as powerful. As of December 2016, several sites have provided strong evidence that VAC (Again, in the context of CS: GO) is never running on Linux devices. @wacossusca34 provides further evidence for this.

Nonsense.

Why? Have you tried? I have, it's the biggest reason why I switched to Linux. With Windows you have to hack your way around it's security restrictions, with Linux you are given this for free. Windows provides security for private companies and closed-source software, Linux provides security for developers and users. I could very easily emulate a Hard Drive on Linux, someone has probably already written the code for me. Good luck doing that undetected on Windows. I can hook into CS: GO's X11 event loop with little effort, and though I am not on that level, other people have decompiled the Linux CS: GO binaries to prove that VAC doesn't run on Linux.

VAC is dedicated cheat detection.

Again, in the context of CS: GO, it is clearly not. AFAIK, CS: GO's VAC is little more than a lookup table with a review process. It took years for Valve to implement detection for something as simple as intentional teleport glitching and impossible camera angles, and AFAIK they don't even detect invalid memory writes (Not fully sure about this one, just never heard any cheat developers complain about it, but not that they would have the need for invalid writes).

My point is, Valve should really work on actual direct detection of impossible pixel perfect flicks and pre-fires, as this would severely reduce the amount of cheaters for many years to come (especially with the ~6 month ban delays), however, they have stated that they are afraid of an inevitable arms race between cheat developers, and are planning on taking a full blown AI approach instead, as they are less predictable. They have indicated that their limiting factor is processing power, and thus money. My point is that, if this is the case, Valve would be better of with investing in dedicated (hard-coded, as they call it) cheat detection.

An arms race will happen either way, we've already seen it happen with the current VAC system. Providers like Aimware used their superior Anti VAC detection systems as a marketing strategy. There was a time where I would meet someone using Aimware every day. However, right now these systems are well known and freely available. Even I have a reasonable understanding of VAC after reading just a few articles. Noone is scared of VAC anymore. Once cheat providers figure out how Valve's new AI works this will happen again. If their AI detects accuracy these cheats will intentionally miss as many shots as possible, if their AI detects stuttering aim these cheats will smooth out their fake mouse movements (In fact, these cheats already exist, even though they aren't detected so far. Developers will compete whether they have a common enemy or not, It's basic economics).

I wonder how you came up with that assumption

https://www.reddit.com/r/GlobalOffensive/comments/5u2xly/eli5_why_are_spinbots_not_autodetected_or_atleast/ddr7ydq/ Also featured here: https://www.youtube.com/watch?v=x7D76z4k0Kk&ab_channel=3kliksphilip The biggest reason why VAC is so horrible at doing it's job is because it doesn't have enough processing power, and Valve doesn't have the money to change that.

It's impossible to judge how well or bad their neural network works. Also, they have stated that people marked as cheaters by this thing go trough overwatch with high priority. Stop making assumptions.

This is not my point. My point is that AI can never be as efficient as dedicated detection (e.g. hard-coded detection for CS: GO) as there will always be an overhead for keeping the AI framework running. And that all cases will have to go through Overwatch (As Valve have stated in their Reddit post) is exactly what I pointed out; The review process is inherently slowing detection down, so there is no point in trying to detect cheats faster, all that matters is reliability (i.e. performance), especially because of Valve's money situation. And the ~6 month ban delay is helping VAC, not the cheaters.

It would be great if Valve manages to finally create a decent anti-cheat system for CS: GO, whether they do it with AI or with hard-coded detection, but the future is looking bleak.

Same as above, meaningless assumptions. Most neural networks nowadays run on GPUs anyway and I highly doubt that they would do it in real-time (on game servers), rather analyzing subsets of matchmaking demos that are stored on their servers.

They are probably running VAC in realtime for most of their detection. I'm not really into neural network implementations, but it doesn't really matter if neural networks use GPU or CPU, the point stays: Valve won't save time and money in the short term (1-2 years) because of the guaranteed overhead of AI. This means they will have to buy extra GPU's and CPU's to give their system a reasonable performance. And like I said, they probably only care about MONAY anyway. Everyone knows Valve makes more money the longer people keep playing CS: GO, because more people playing CS: GO = more people buying skins.

I honestly wish that mods here kill this pointless discussion at this point.

The only reason this discussion is pointless is because Valve has their own ideas for CS: GO's VAC system and won't listen to the community or common sense on it, and it's killing the game for competetive players. I'm actually considering subscribing to ESEA not because I care about their ranking system or community, but solely so I can for once have a good game without suspicion or fear of cheaters. Most people would just outright quit the game, and most of my Steam friends did.

It would probably be wise to continue this conversation externally if you wish to do so.

[infowolfe]

@YoYoYonnY You seem uninformed... a SuperMicro SYS-4028GR-TR with 2x Xeon E5-2697A, 768GB ram, a 4TB NVMe, 2x 10GbE and 8x Tesla P40 costs about $65k per box, for a higher end system with significantly more (24x 400GB SAS) SSD and dropping to a 2TB NVMe, you're still about $85k per box. Each box has, depending on efficiency of their ML code, the ability to process a minimum of 8 demos simultaneously. 20 boxes at that spec is only about $1.7M, a drop in the bucket for someone the size of Valve. The other thing that you're completely missing is that the machines are constantly self-tuning their heuristics and are now catching non-AA using rage, putting all (from what I can tell) players present in a match where >2 are using AA (though this may be lowered soon) into the priority OW queue AND the heuristics envelope is getting smaller. I've gotten reports from non-AA using ragers (using my previously "safe" no-AA + < 39 degrees/tick settings) of OW bans within hours of 1 match per 24h.

If we say for example that a single Tesla P40 can process a single match from all 10 player perspectives in 10 minutes (which would be extremely slow for a relatively small 32-tick GoTV demo of 150-200MB), 20 machines could then do 960 matches per hour. I'm assuming that they've got significantly more machines or significantly less processing time, considering the actual quantity of matches played per hour and the response time I've observed (which in some cases has been less than 60 minutes from match to game ban).

If it's a more realistic 1-2 minutes per match per card (from all 10 player perspectives) then this system could theoretically push as many as 9600 matches through the ML filters per hour. As this system is refined, obviously the inference times will drop and more matches (eventually all matches) will be "randomly selected." I've also noticed that it seems like Valve is sampling only from some regions and not others to keep the data throughput lower.

If we analyse the data from http://steamcharts.com/app/730#3m we can see that there has been a significant drop in the number of online players per day over the last 30 days and a significant rise in players after large VAC waves (such as in late Dec/early Jan). Assuming 480k online players at one time, that's 48k matches to process, or 1 in 5 matches being scanned by the system at my theoretical 9600 matches per hour.

As someone that plays HvH, mm is dead to me until we've got a better handle on what's going on, and I'm not the only one. There are LOTS of ragers that're just not playing in mm anymore because of this new system and the guarantee of an eventual overwatch ban.

So, your complaints about VAC in general are basically null and void. The new ML approach is scary effective.

Example of legit player being "caught" and referred to overwatch in a game with multiple ragers: https://youtu.be/OXNBxkSEf4k

Oh, one other thing, it's doubtful that Valve's needing to spend $85k per box to reach the performance levels they need, as a single NVMe SSD has sufficient throughput to load whatever data they need into ram for processing, they likely have the ability to reduce the total amount of ram and use lower end CPUs than I selected. Meaning the total cost of each ML filtering box could probably be kept below $60k ea, with the primary cost being the $47k in NVidia Tesla P40 ML-optimized inference cards.

Regardless, the age of the blatant cheater in MM is almost over.

[KitsuneDev]

Is this like... FOR ALL DISTROS??

[yoursummer]

I'm using aimtux for like half a year now, yep no vac on linux

[ghost]

valve no have money to pay access total in kernel unix

[slack2450]

Kappa plasam.xyz and aimtux and nyctum and realnigga.club all use linux xD

[ghost]

I used cheat on linux and play more 300 hours. NO VAC!!! Thanks Gabe Newell!

[ragespinning]

I have been using AimTux since December on my main account and no ban whatsoever. I switched to AimTux Fuzion because it's not dead like the main cheat. Big problem is Wingman, everytime I try to go non prime with my friend I end up rage hacking against one or two ragers. I would love Valve if they added Overwatch in Wingman

[yoursummer]

Everyone got banned. Including myself. Good job, too bad it took so long.

[ghost]

not all. it like half banned cheaters. good job.

[h33p]

We should close this now, the issue has been resolved. I have the vac modules.

[ghost]

i think this sounds a bit dumb but: doesnt steam/steam games need root to maybe spawn a child process which scans the game(basicly vac) while making a child process with root perms isnt possible because the main process doesnt have root access? i know steam doesnt run with root correctly.

[slack2450]

@GreenByteSoftware it was fun while it lasted. Now we have to put up with VAC, I swear it's the gdb injection method we used they picked up upon. If they're reading DNS cache it's Punkbuster all over again lmao I reckon it'd be easy to get people false banned.

[kiroma]

Spawning a child process is fairly easy and doesn't require root permissions. The main problem is how do you detect a cheat like that. It's probably not that difficult, and comes down to just checking if there are any unauthorised .so files loaded into game memory.