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

Quoting: Raaben

Quoting: F.UltraYou 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...

Quoting: TheRiddick

Quoting: hell0I'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.

Quoting: hell0

Quoting: Corben

Quoting: RaabenI'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.

Quoting: GryxxAccording 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

Quoting: F.UltraServer 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.

Quoting: hell0

Quoting: F.UltraServer 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

Quoting: F.Ultra

Quoting: hell0

Quoting: F.UltraServer 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.

Quoting: Guest

QuoteProcess 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.

Quoting: tuubi

Quoting: F.Ultra

Quoting: hell0

Quoting: F.UltraServer 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).