Update: According to Epic's Tim Sweeney, the EAC team appears to still be working on supporting Wine and Proton themselves. When queried about it on Twitter, Sweeney said:
The team’s working on it, it’s just especially hard on Linux because the incredibly wide variety of configurations and inability to apply traditional digital signature techniques to custom compiled versions of the kernel, etc.
Original article below:
Recently we highlighted the ongoing unofficial work to get Easy Anti-Cheat working in Wine (so Steam Play Proton then too) and it appears another major step has been achieved.
We still don't know what the plan is, if any now, for Easy Anti-Cheat to officially support Wine / Proton and there's been no update from them directly or Epic Games on if it's going to happen. At least, not since they said they would work with Valve in Early 2019. With that in mind, this is very much a community-led effort from a CodeWeavers developer @Guy15241 with help from @0xdt0.
The ongoing EAC work is now at a stage where they've been able to get Dead By Daylight into a game, although with low performance (Guy mentioned 1FPS in the menu). They also shared some shots:
Hopefully EAC and Epic don't throw a spanner in the works, as they could likely at any point once this is released stop it working if they don't like how it operates. Which we highlighted Epic's Tim Sweeney talking about before on Twitter.
We're likely still quite some time away before EAC titles become properly playable under Wine and Proton and the code isn't currently public. It sounds very complicated how they're managing to do it all but it's interesting progress if EAC is blocking games you want to play on Linux under Wine and Proton. If / when code becomes public and / or there's builds available to test, we will let you know.
Article taken from GamingOnLinux.com.
gradyvuckovic Jun 26, 2020
Quoting: AllocQuoting: TheSHEEEPAsked EAC what their thoughts are on this. I fear the same as Ehvis, namely that this is basically a working EAC bypass that needs to be fixed instead of supported.Quoting: EhvisI feel the same.Quoting: Perkeleen_VittupääWhat's good too, is that it's not an actual kernel driver with root permissions?
This driver seems running in user mode so it thinks it is in the kernel, but actually in a user mode process.
It can also be seen as bad. This effectively means that EAC is being kept happy while it's not being able to what is happening on the system. If it is now possible to create some sort of cheat outside of wine, then it would essentially an exploit. If this is possible on Linux, it would be possible on Windows as well. At best EAC would try to fix that. At worst, they decide that they might switch to more drastic options. While it's pretty cool that they managed it this far, I'm still not hopeful for the future.
From a technical perspective, this is pretty amazing.
But it really doesn't solve the problem in a way that would make EAC happy, does it? It isn't hard to imagine Wine keeping EAC happy, while you run something else neither Wine nor EAC has access to on your machine.
In the end, it would probably only serve to increase the pressure on anti-cheat devs to either fully support or fully block Linux.
And I don't think any of us would like the result of that decision, at least not at the current market share.
Also note that EAC *does* fully support Linux. There are games that do that just fine, only game devs that don't care about releasing for Linux are affected as Wine is what's not supported, as that's "neither" Linux nor Windows. I suppose the only way EAC *could* be supported in Wine would be if EAC designed an EAC client module specifically for that purpose, that's basically closer to the Linux module but interacting with the Windows runtime of the game.
I always imagined that being the solution which we'd end up with. The native Linux version of EAC, installed and running, but communicating to the Windows version of EAC running in Wine via some kind of bridge.
Quoteinability to apply traditional digital signature techniques to custom compiled versions of the kernel
Digital signature of the kernel ?
Could anyone develop on that topic ?
I feel we're going down a dangerous and unlikable path there.
Quoting: aokamiQuoteinability to apply traditional digital signature techniques to custom compiled versions of the kernel
Digital signature of the kernel ?
Could anyone develop on that topic ?
I feel we're going down a dangerous and unlikable path there.
There are kernel signed by the distribution, see https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot
Well, I'm not an expert, but this makes sense.
Quoting: gustavoyaraujoWhy don't do something like anticheat-dkms and live it open source to talk to the EAC and other softwares like that?
Well, I'm not an expert, but this makes sense.
They don't want to show people what and how they are looking at so they cannot go the open-source kernal module route. In reality there is no way that they can hide this anyway in their current Windows version but they like to pretend that they do (lot's of enterprises likes to pretend that their closed source nature hides things, which it doesn't).
Quoting: F.UltraQuoting: gustavoyaraujoWhy don't do something like anticheat-dkms and live it open source to talk to the EAC and other softwares like that?
Well, I'm not an expert, but this makes sense.
They don't want to show people what and how they are looking at so they cannot go the open-source kernal module route. In reality there is no way that they can hide this anyway in their current Windows version but they like to pretend that they do (lot's of enterprises likes to pretend that their closed source nature hides things, which it doesn't).
I see, but what I mean is just some kind of opensource middleware to be implemented in the kernel as a module to let them use their anticheat solution.
Quoting: gustavoyaraujoQuoting: F.UltraQuoting: gustavoyaraujoWhy don't do something like anticheat-dkms and live it open source to talk to the EAC and other softwares like that?
Well, I'm not an expert, but this makes sense.
They don't want to show people what and how they are looking at so they cannot go the open-source kernal module route. In reality there is no way that they can hide this anyway in their current Windows version but they like to pretend that they do (lot's of enterprises likes to pretend that their closed source nature hides things, which it doesn't).
I see, but what I mean is just some kind of opensource middleware to be implemented in the kernel as a module to let them use their anticheat solution.
Then you have a module that just gives any software on your machine root-kil level access to the inner works of your kernel and also honestly it IMHO doesn't matter if that module is open or closed since "whatever EAC will do in your kernel" is closed source anyway.
They could of course make it open source dkms just to be able to build it for a wide variety of kernels of course if that was the problem to solve (just realised that perhaps that was what you meant).
Patreon
PayPal
See more from me