Support us on Patreon
PayPalUpdate: 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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
19 comments
Perkeleen_Vittupää Jun 26, 2020
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.
This driver seems running in user mode so it thinks it is in the kernel, but actually in a user mode process.
0 Likes
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.
2 Likes, Who?
Just imagin: cheaters taking code from wine to run it on windows to run cheats.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.
My inner troll wanting to see the world burn had a little giggle on that though xD.
3 Likes, Who?
I feel the same.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.
2 Likes, Who?
Use rootkit to play some games? Are you dumb?
If you very, very want to play some games with that kind of rootkits, try to avoid it on your main system, install that shit on external drive with other OS.
If you very, very want to play some games with that kind of rootkits, try to avoid it on your main system, install that shit on external drive with other OS.
3 Likes, Who?
Interesting, both technically and on the fact it can end up bringing more games compatible with wine!
But this also brought a new question : As a consumer will I support company choosing such drm technology ? (at the end of the day, we vote with our wallets)
But this also brought a new question : As a consumer will I support company choosing such drm technology ? (at the end of the day, we vote with our wallets)
2 Likes, Who?
rustybroomhandle Jun 26, 2020
Use rootkit to play some games? Are you dumb?
If you very, very want to play some games with that kind of rootkits, try to avoid it on your main system, install that shit on external drive with other OS.
This is running in user-space.
4 Likes, Who?
Asked 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.I feel the same.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.
5 Likes, Who?
Interesting, Crucible does use it and works without any issues.
0 Likes
Interesting, Crucible does use it and works without any issues.
That probably means they failed to use it correctly. Even Fortnite was playable in Wine for a few days a good while back because Epic apparently messed up its EAC implementation with an update. So I would take it as proof that it isn't actually working.
1 Likes, Who?
gradyvuckovic Jun 26, 2020
Asked 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.I feel the same.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.
0 Likes
TimSweeneyEpic reacted on Twitter, they also working on it, he says... https://twitter.com/TimSweeneyEpic/status/1276538519826153473?s=20
1 Likes, Who?
inability 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.
0 Likes
inability 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
2 Likes, Who?
Why 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.
Well, I'm not an expert, but this makes sense.
0 Likes
Why 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).
0 Likes
Why 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.
0 Likes
Why 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).
1 Likes, Who?
See more from me