Brawlhalla to get Easy Anti-Cheat, dev puts up Beta with EAC working on Linux with Proton

so the first EAC proton game isnt one from epic? hmmmm

Brawlhalla looks like a game made for the steamdeck. makes sense to support it

I'm curious though I doubt we can ever fully know, how bad is this Proton/WINE implementation of EAC security/privacy-wise? Yeah I know it'd be better to be safe and sandbox or still never play those games at all if concerned, but I'm just wondering if there's insight how it operates.

How difficult is it then for developers to upgrade to a newer version of Easy Anti-Cheat to get the Proton support working for Linux players? Epic originally said it was "just a few clicks" but the reality is a little different.

I disagree. Epic said that turning Linux support will be few clicks, not that upgrading EAC will. I fully expect that upgrading and testing EAC is not a easy task. Hopefuly most publishers will upgrade it for other benefits besides Linux support, so it will really be one flip of a switch at some point.

I'm curious though I doubt we can ever fully know, how bad is this Proton/WINE implementation of EAC security/privacy-wise? Yeah I know it'd be better to be safe and sandbox or still never play those games at all if concerned, but I'm just wondering if there's insight how it operates.

Same, I'm also wondering how effective EAC on Linux is, if it's not running on Kernel level as it does on Windows. I guess only time will tell. But this would also mean that more people will have to switch over to Linux (which is kinda good), if it would be easier to bypass EAC there than on Windows (which would be very bad though).
And I recently heard that even with EAC enabled there are still people successfully cheating in Fall Guys?

On the other hand, it's an evolving progress. So first we'd like to have devs enable EAC with the Linux module, then probably Epic and devs will be able to improve EAC including Linux to make it safe(r) for everybody.

And in the end, I hope those settings will become default, and not something devs have to do explicitly. I'd even prefer to have it the other way: devs would have to actively de-activate EAC in the backend for Linux (or Windows :D )

I'm curious though I doubt we can ever fully know, how bad is this Proton/WINE implementation of EAC security/privacy-wise? Yeah I know it'd be better to be safe and sandbox or still never play those games at all if concerned, but I'm just wondering if there's insight how it operates.

Same, I'm also wondering how effective EAC on Linux is, if it's not running on Kernel level as it does on Windows. I guess only time will tell. But this would also mean that more people will have to switch over to Linux (which is kinda good), if it would be easier to bypass EAC there than on Windows (which would be very bad though).
And I recently heard that even with EAC enabled there are still people successfully cheating in Fall Guys?

On the other hand, it's an evolving progress. So first we'd like to have devs enable EAC with the Linux module, then probably Epic and devs will be able to improve EAC including Linux to make it safe(r) for everybody.

And in the end, I hope those settings will become default, and not something devs have to do explicitly. I'd even prefer to have it the other way: devs would have to actively de-activate EAC in the backend for Linux (or Windows :D )

According to developers of Robocraft it is worse. At some point they disabled EAC for anything other then Ubuntu family (on Linux Native), arguing that there were too many cheaters.

I'm curious though I doubt we can ever fully know, how bad is this Proton/WINE implementation of EAC security/privacy-wise?

Same, I'm also wondering how effective EAC on Linux is, if it's not running on Kernel level as it does on Windows.

il third that concern.


for me it's creating a situation where by i have to consider running a dedicated Linux gaming machine
((as afaik some implementations have been known to be looking through browser data, indexing file names, ip logging, sniffing packets, hardware ID data-basing etc.. and having complete machine control while the game runs)).

And then i have to potentially use another machine for even casual consumption or when im dealing with sensitive files / productivity, where as now it's all on one machine. Of course the steam deck satisfies this requirement.. that would be if it was actually more powerful than a dedicated midrange GPU from 2015.
This is paradoxical, because with terrible privacy why don't i fork out for or get a promo code for Windows and run it isolated and have 100% compatibility. Or even just get a console ? And although subscription fees maybe an argument, how much is my data privacy worth to me that could be gleaned from my anti-cheat DRM laden wine games running on my 'private' Linux machine.. on Steam + origin.
you get the picture.

Still, i understand everything is a compromise but having some knowledge as to how it works and how secure/private it is VS the windows implementation would be nice. In the end it's obvious that my next Monitor choice has to include a KVM in order to quickly switch between a DRM free Linux machine and the 'practically windows at this point' Linux gaming console.

I'm curious though I doubt we can ever fully know, how bad is this Proton/WINE implementation of EAC security/privacy-wise? Yeah I know it'd be better to be safe and sandbox or still never play those games at all if concerned, but I'm just wondering if there's insight how it operates.

You are already running a closed source binary (the game itself and Steam for that matter) on your system that can already do whatever they like with your system, I don't think EAC brings anything more evil to this table since it does not run in the kernel and does not require root(?).

You are already running a closed source binary (the game itself and Steam for that matter) on your system that can already do whatever they like with your system, I don't think EAC brings anything more evil to this table since it does not run in the kernel and does not require root(?).

True, but at the same time it is an anticheat's specific job to spy on what one is doing right? It might not have root/kernel access but it can also do alot of snooping around without it.

I'm curious though I doubt we can ever fully know, how bad is this Proton/WINE implementation of EAC security/privacy-wise? Yeah I know it'd be better to be safe and sandbox or still never play those games at all if concerned, but I'm just wondering if there's insight how it operates.

Same, I'm also wondering how effective EAC on Linux is, if it's not running on Kernel level as it does on Windows. I guess only time will tell. But this would also mean that more people will have to switch over to Linux (which is kinda good), if it would be easier to bypass EAC there than on Windows (which would be very bad though).
And I recently heard that even with EAC enabled there are still people successfully cheating in Fall Guys?

I used to provide servers for several popular games years ago. I've tried to keep cheaters at bay (which is a real pita when you only partially control the server), that's how I've acquired most of my knowledge on the topic.

Client-side anti-cheats are fundamentally flawed. They try to render the client trustful by wrapping it in some thin protection, whilst running in an untrusted environment. That's the same as putting a padlock on a cardboard and leaving it without surveillance in a park overnight, expecting it to be fine and unaltered next morning. It might happen, but it won't be because of the padlock.

The truth is that any somewhat popular game will have cheats available for it. Though almost all cheats that are reliably updated to bypass anti-cheats are paid for.

According to developers of Robocraft it is worse. At some point they disabled EAC for anything other then Ubuntu family (on Linux Native), arguing that there were too many cheaters.

I've played robocraft. Whilst the game was fun and enjoyable to play, they're a prime example of trying to make up for jokingly bad cheat-proofing by using third party tools. Their servers trust everything the clients send: that weapon with a fixed unalterable 10 seconds reload is ready to fire again after 0.1s you say? Sure, go ahead! That speed you can't reach with your current setup is what you're cruising at? Seems alright!

They had cheaters before using EAC, they have cheaters after adding EAC, they will have cheaters from every OS until they implement server-side counter-measures (or the game loses enough players to no longer warrant cheat creators to bother any more).


Last edited by hell0 on 15 October 2021 at 10:15 pm UTC

I've played robocraft. Whilst the game was fun and enjoyable to play, they're a prime example of trying to make up for jokingly bad cheat-proofing by using third party tools. Their servers trust everything the clients send: that weapon with a fixed unalterable 10 seconds reload is ready to fire again after 0.1s you say? Sure, go ahead! That speed you can't reach with your current setup is what you're cruising at? Seems alright!

I've been saying this allot lately too. EAC/BE as a AC measure and nothing else is called 100% lazy development! Server side rule breaking checks need to be done. I think Mortal Online 2 has server side AC going on since they discovered early on that client side only was completely pointless!

You are already running a closed source binary (the game itself and Steam for that matter) on your system that can already do whatever they like with your system, I don't think EAC brings anything more evil to this table since it does not run in the kernel and does not require root(?).

True, but at the same time it is an anticheat's specific job to spy on what one is doing right? It might not have root/kernel access but it can also do alot of snooping around without it.

It can do no more snooping around that the game already can if it wanted to. In fact I would say that you have a much higher risk of a random game doing shady business than something like EAC since if it turned out that EAC did look at things it wasn't supposed to then EAC might find it self without any market so they have much more at stake.

Note that this is not an endorsement of things like EAC, just pointing out that since we already run closed sourced binaries on our system the game is already over so to speak. Proper sandboxing would help here (but Wine/Proton itself doesn't do that even if you remove the Z: share) but AFAIK EAC would be just as sandboxed as the game in that case anyway so the difference is back to zero again.

Huge difference on Windows where things like EAC AFAIK runs as some kernel module, but again that would only allow it to snoop on other user accounts since the game already have access to all your files and how many really run with more than one account on Windows...

I've played robocraft. Whilst the game was fun and enjoyable to play, they're a prime example of trying to make up for jokingly bad cheat-proofing by using third party tools. Their servers trust everything the clients send: that weapon with a fixed unalterable 10 seconds reload is ready to fire again after 0.1s you say? Sure, go ahead! That speed you can't reach with your current setup is what you're cruising at? Seems alright!

I've been saying this allot lately too. EAC/BE as a AC measure and nothing else is called 100% lazy development! Server side rule breaking checks need to be done. I think Mortal Online 2 has server side AC going on since they discovered early on that client side only was completely pointless!

Server side checks however is a major performance pain, having it client side means perfect load balancing. So it's not only about being "lazy", it has a real impact on the number of simultaneous clients you can have per server.

I'm curious though I doubt we can ever fully know, how bad is this Proton/WINE implementation of EAC security/privacy-wise? Yeah I know it'd be better to be safe and sandbox or still never play those games at all if concerned, but I'm just wondering if there's insight how it operates.

Same, I'm also wondering how effective EAC on Linux is, if it's not running on Kernel level as it does on Windows. I guess only time will tell. But this would also mean that more people will have to switch over to Linux (which is kinda good), if it would be easier to bypass EAC there than on Windows (which would be very bad though).
And I recently heard that even with EAC enabled there are still people successfully cheating in Fall Guys?

I used to provide servers for several popular games years ago. I've tried to keep cheaters at bay (which is a real pita when you only partially control the server), that's how I've acquired most of my knowledge on the topic.

Client-side anti-cheats are fundamentally flawed. They try to render the client trustful by wrapping it in some thin protection, whilst running in an untrusted environment. That's the same as putting a padlock on a cardboard and leaving it without surveillance in a park overnight, expecting it to be fine and unaltered next morning. It might happen, but it won't be because of the padlock.

The truth is that any somewhat popular game will have cheats available for it. Though almost all cheats that are reliably updated to bypass anti-cheats are paid for.

According to developers of Robocraft it is worse. At some point they disabled EAC for anything other then Ubuntu family (on Linux Native), arguing that there were too many cheaters.

I've played robocraft. Whilst the game was fun and enjoyable to play, they're a prime example of trying to make up for jokingly bad cheat-proofing by using third party tools. Their servers trust everything the clients send: that weapon with a fixed unalterable 10 seconds reload is ready to fire again after 0.1s you say? Sure, go ahead! That speed you can't reach with your current setup is what you're cruising at? Seems alright!

They had cheaters before using EAC, they have cheaters after adding EAC, they will have cheaters from every OS until they implement server-side counter-measures (or the game loses enough players to no longer warrant cheat creators to bother any more).

No arguments there. I'm just citing what I've heard as player.

This is great news, but unfortunately my controller doesn't work anymore in brawlhalla. Wanted to play it again yesterday, first time in ages... that was an unpleasent surprise

Server side checks however is a major performance pain, having it client side means perfect load balancing. So it's not only about being "lazy", it has a real impact on the number of simultaneous clients you can have per server.

There isn't really a need to run the checks in real time or on the same server as the game's logic. In fact it's probably a pretty poor idea to validate every action synchronously as it would lead to horrible game experience in most scenari due to network latency. It would also let cheaters know exactly what was detected or not.

The correct approach to server side anti-cheat is to analyse information statistically to find outliers and then determine whether these outliers are just good players or cheaters (using human validation if necessary).

Let's imagine a cheat letting you fire a weapon faster than intended and let's say the server records every hit. That's all we actually need. After each game the server can ship that game's record off to our anti-cheat analyser. The analyser looks at all hits recorded and find that player A has over 10 hits within 5 seconds with a 10 second reload weapon, player A gets banned.

Better yet, proceeding this way lets you detect cheats that may be invisible to normal players. If your 10s reload gun reloads in 9.75s that's an advantage but nobody will notice it with certainty. If it happens once, it could be chalked up to some weird lag compensation or chance. However if a player consistently reloads ever so slightly faster than possible, a machine will catch it over time.

In short: you should think of server-side anti-cheat as some sort of replay watcher/analyser bot, not a validation of every keypress in real time.

Server side checks however is a major performance pain, having it client side means perfect load balancing. So it's not only about being "lazy", it has a real impact on the number of simultaneous clients you can have per server.

There isn't really a need to run the checks in real time or on the same server as the game's logic. In fact it's probably a pretty poor idea to validate every action synchronously as it would lead to horrible game experience in most scenari due to network latency. It would also let cheaters know exactly what was detected or not.

The correct approach to server side anti-cheat is to analyse information statistically to find outliers and then determine whether these outliers are just good players or cheaters (using human validation if necessary).

Let's imagine a cheat letting you fire a weapon faster than intended and let's say the server records every hit. That's all we actually need. After each game the server can ship that game's record off to our anti-cheat analyser. The analyser looks at all hits recorded and find that player A has over 10 hits within 5 seconds with a 10 second reload weapon, player A gets banned.

Better yet, proceeding this way lets you detect cheats that may be invisible to normal players. If your 10s reload gun reloads in 9.75s that's an advantage but nobody will notice it with certainty. If it happens once, it could be chalked up to some weird lag compensation or chance. However if a player consistently reloads ever so slightly faster than possible, a machine will catch it over time.

In short: you should think of server-side anti-cheat as some sort of replay watcher/analyser bot, not a validation of every keypress in real time.

This approach I like! Of course it requires analysis of quite a lot of data since even with a "low sample rate" there will still be quite a lot of events to go over for each session so I think that this is still not something that every single small studio can handle, but then again a 3d party expert could sell this as a service.

And I recently heard that even with EAC enabled there are still people successfully cheating in Fall Guys?
[/quote]
Almost as if people being paid to create trainers and cheat mods have a vested interest in being better than anti cheat software or something

Server side checks however is a major performance pain, having it client side means perfect load balancing. So it's not only about being "lazy", it has a real impact on the number of simultaneous clients you can have per server.

There isn't really a need to run the checks in real time or on the same server as the game's logic. In fact it's probably a pretty poor idea to validate every action synchronously as it would lead to horrible game experience in most scenari due to network latency. It would also let cheaters know exactly what was detected or not.

The correct approach to server side anti-cheat is to analyse information statistically to find outliers and then determine whether these outliers are just good players or cheaters (using human validation if necessary).

Let's imagine a cheat letting you fire a weapon faster than intended and let's say the server records every hit. That's all we actually need. After each game the server can ship that game's record off to our anti-cheat analyser. The analyser looks at all hits recorded and find that player A has over 10 hits within 5 seconds with a 10 second reload weapon, player A gets banned.

Better yet, proceeding this way lets you detect cheats that may be invisible to normal players. If your 10s reload gun reloads in 9.75s that's an advantage but nobody will notice it with certainty. If it happens once, it could be chalked up to some weird lag compensation or chance. However if a player consistently reloads ever so slightly faster than possible, a machine will catch it over time.

In short: you should think of server-side anti-cheat as some sort of replay watcher/analyser bot, not a validation of every keypress in real time.

This approach I like! Of course it requires analysis of quite a lot of data since even with a "low sample rate" there will still be quite a lot of events to go over for each session so I think that this is still not something that every single small studio can handle, but then again a 3d party expert could sell this as a service.

It does sound like a better way to do it than traditional server-side equivalents, but doesn't solve the problem that the instrumentation needs to be built into the game engine and the anti-cheat service needs to either be bought or developed. There will always be (a majority of) game devs who take the easy/quick/cheap way out and rely on a client side solution, often added as an afterthought.

Process started, running as admin: true.

what does this imply? does it actually run as the root user or is that just a message that applies to windows and is ignored when running under wine?

Nothing fancy, it's just that Windows user access control haven't been implemented on Wine (except on staging.

Server side checks however is a major performance pain, having it client side means perfect load balancing. So it's not only about being "lazy", it has a real impact on the number of simultaneous clients you can have per server.

There isn't really a need to run the checks in real time or on the same server as the game's logic. In fact it's probably a pretty poor idea to validate every action synchronously as it would lead to horrible game experience in most scenari due to network latency. It would also let cheaters know exactly what was detected or not.

The correct approach to server side anti-cheat is to analyse information statistically to find outliers and then determine whether these outliers are just good players or cheaters (using human validation if necessary).

Let's imagine a cheat letting you fire a weapon faster than intended and let's say the server records every hit. That's all we actually need. After each game the server can ship that game's record off to our anti-cheat analyser. The analyser looks at all hits recorded and find that player A has over 10 hits within 5 seconds with a 10 second reload weapon, player A gets banned.

Better yet, proceeding this way lets you detect cheats that may be invisible to normal players. If your 10s reload gun reloads in 9.75s that's an advantage but nobody will notice it with certainty. If it happens once, it could be chalked up to some weird lag compensation or chance. However if a player consistently reloads ever so slightly faster than possible, a machine will catch it over time.

In short: you should think of server-side anti-cheat as some sort of replay watcher/analyser bot, not a validation of every keypress in real time.

This approach I like! Of course it requires analysis of quite a lot of data since even with a "low sample rate" there will still be quite a lot of events to go over for each session so I think that this is still not something that every single small studio can handle, but then again a 3d party expert could sell this as a service.

It does sound like a better way to do it than traditional server-side equivalents, but doesn't solve the problem that the instrumentation needs to be built into the game engine and the anti-cheat service needs to either be bought or developed. There will always be (a majority of) game devs who take the easy/quick/cheap way out and rely on a client side solution, often added as an afterthought.

What about a dual system for anti cheat? Client and Sever. (Though apparently a lot of games do sorta do this already, and it's still a bit ehhhh). Or suing the cheat sellers/hosts to destroy some of the source, since most cheaters are script kiddies.

What would be quite funny is if a developers made a fake cheat, that weakens the cheater ingame, announces that they cheated and makes then a target (with a verse wall-hacks) ingame to everyone on the server (with their account being pushed to cheater matchmaking/servers).