I agree, except I’m hesitant to include hell divers because of the kernel level anticheat. I don’t need to give a video game of all things access to my kernel. But the general idea is right, I am playing so many fire video games all made by indie devs right now.
the game’s anti cheat has access to literally everything in your computer. every file, every memory address, every input, every network packet, etc.
How that info is stored and used is entirely up to them
Yes, it’s a pretty big privacy concern, unfortunately Riot kinda already boiled that frog with Valorant. Not that Valorant was the first, but it was kinda the first one that people seemed to be okay with. Weirdly, Valorant only really got popular because CS:GO and Overwatch were getting stale, and neither Valve or Blizzard were doing much to keep their games fresh.
That’s because the anti cheat is running in a fake kernel with Proton. Developers have ways of detecting when the kernel isn’t real… Sometimes… But the Helldivers devs don’t seem to mind for now.
I don’t know where the hell you got that information but that’s not how proton works. There is no “fake kernel” it’s not a virtual machine or an emulator it’s just a translation layer that translates Windows syscalls into linux syscalls
The syscall translations that would go to the nt kernel, can be seen as a “fake kernel”, no?
Wine has a process that works as a substitute for the Windows NT Kernel. How that works in detail, which calls are abstracted with an internal model, and which are mapped on to Linux kernel calls, is a bit silly to get hung up on, no?
I think it’s perfectly fine to call that concept a “fake kernel”. I don’t know what you’d need in order to qualify more?
just a translation layer that translates Windows syscalls into linux syscalls
“Just”?. No. It also has an internal model. Which system calls end up as Linux syscalls, and how, is not a stateless translation. The NT kernel is modeled. And although you are right in your straw man argument that it isn’t a “virtual machine”, or an “emulator”. Neither of those are a requirement for the concept of a “fake kernel” either. Seems a bit rude to go so balls out hard against it, as you did.
None of the things needed for a true kernel level anti cheat are in a translation layer, some of them just can’t be. It’s why games with actual kernel level anti cheat have never worked in proton and never will. Historically the only way to play those games is either be on windows or use a vfio virtual machine (which also probably won’t work even with tons of vm hiding techniques depends on just how sensitive the ac is). Wine/proton simply can’t translate the upper parts of the nt kernel needed for it.
It’s why games with actual kernel level anti cheat have never worked in proton and never will
Some games that use EAC, BattlEye and GameGuard, work fine in proton. Afaik, whatever these do and are abstracted to, or is offhanded to some linux native process, it’s still all running in userspace. I’m sure this relies on individual game developers playing along with it, and not 100% “proton emulating the nt kernel” in order to “fool them”. Is this the point you’re arguing? That it won’t be possible by a purely proton/wine translation layer?
If you know details on how exactly this works, or want to point to some resource on this, I’d be happy to read more about it.
My guess is that there is nothing technically impossible about fooling a rootkit by faking whatever syscalls from the game, but that it becomes a impossible task to maintain, as the AC developers can make minor changes that would require a lot of hard work to “emulate”. I’d love to learn more, but it was hard to find good resources on this.
EAC has an explicit linux support that valve worked on them with, it’s not full kernel AC. same with battleye and GG those are not full kernel root anti cheat implementations. I can’t point at any specific documents unfortunately but the wine/proton irc channels are public and lurking let’s you learn a lot as they talk through issues with games and anticheat.
In order for linux to support kernel level AC a module for the Linux kernel would be needed. And i doubt Linus will ever allow that lol
In order for linux to support kernel level AC a module for the Linux kernel would be needed. And i doubt Linus will ever allow that lol
This is… correct. That in order to support kernel level anti-cheat on Linux, you need a kernel module. But that statement is a tautology.
An NT kernel AC running through Wine, and whether or not it “works” doesn’t predicate on a Linux kernel module being loaded. All it needs is the correct handling of whatever the NT kernel would communicate to the running game, and handle whatever that callback is through some other mechanism that passes the checks.
Most AC software have Linux native clients, and that’s what this “some other mechanism”. And whatever that is in practice, should, with enough reverse engineering, be technically possible for proton/wine to do as well. It’s all running on userland after all. I assume that this is not an easy task to do at all, which is why the only realistic approach is for AC developers to actually be on board, and instead just compromise on the weaker level of anti-cheat protection, compared to what you’d get with a kernel module. As far as I understand, this is the case for GG, BattlEye and EAC. Not all games work, because it depends on the developers “allowing it”.
And as for what the future might bring. I expect that with Linux gaming becoming more popular, it’s only a matter of time before a Linux AC is implemented as a kernel module. Also, neither Linus, nor anyone, need to whitelist a kernel module for it to be loaded. The only one that has an ultimate say there is you, the user.
None of the things needed for a true kernel level anti cheat are in a translation layer, some of them just can’t be. It’s why games with actual kernel level anti cheat have never worked in proton and never will. Historically the only way to play those games is either be on windows or use a vfio virtual machine (which also probably won’t work even with tons of vm hiding techniques depends on just how sensitive the ac is) . Wine/proton simply can’t translate the upper parts of the nt kernel needed for it.
If the anti cheat is working in wine/proton it’s not kernel level
I agree, except I’m hesitant to include hell divers because of the kernel level anticheat. I don’t need to give a video game of all things access to my kernel. But the general idea is right, I am playing so many fire video games all made by indie devs right now.
I’m not sure what that has to do with Hell Divers being a cheap cash grab though?
Do you have a rundown of what that means? First time I’m hearing about this
the game’s anti cheat has access to literally everything in your computer. every file, every memory address, every input, every network packet, etc. How that info is stored and used is entirely up to them
Oh wow. Are there any plans to have this removed? Isn’t this quite a major privacy concern?
Yes, it’s a pretty big privacy concern, unfortunately Riot kinda already boiled that frog with Valorant. Not that Valorant was the first, but it was kinda the first one that people seemed to be okay with. Weirdly, Valorant only really got popular because CS:GO and Overwatch were getting stale, and neither Valve or Blizzard were doing much to keep their games fresh.
No, because their plans were explicitly for adding it in. Almost at the last moment too, as if the devs knew they were gonna get backlash for it.
Are you certain it has kernelt level anti cheat? Because it’s working on Linux which it absolutely would not be doing if it had kernel anti cheat
That’s because the anti cheat is running in a fake kernel with Proton. Developers have ways of detecting when the kernel isn’t real… Sometimes… But the Helldivers devs don’t seem to mind for now.
I don’t know where the hell you got that information but that’s not how proton works. There is no “fake kernel” it’s not a virtual machine or an emulator it’s just a translation layer that translates Windows syscalls into linux syscalls
The syscall translations that would go to the nt kernel, can be seen as a “fake kernel”, no?
Wine has a process that works as a substitute for the Windows NT Kernel. How that works in detail, which calls are abstracted with an internal model, and which are mapped on to Linux kernel calls, is a bit silly to get hung up on, no?
I think it’s perfectly fine to call that concept a “fake kernel”. I don’t know what you’d need in order to qualify more?
“Just”?. No. It also has an internal model. Which system calls end up as Linux syscalls, and how, is not a stateless translation. The NT kernel is modeled. And although you are right in your straw man argument that it isn’t a “virtual machine”, or an “emulator”. Neither of those are a requirement for the concept of a “fake kernel” either. Seems a bit rude to go so balls out hard against it, as you did.
None of the things needed for a true kernel level anti cheat are in a translation layer, some of them just can’t be. It’s why games with actual kernel level anti cheat have never worked in proton and never will. Historically the only way to play those games is either be on windows or use a vfio virtual machine (which also probably won’t work even with tons of vm hiding techniques depends on just how sensitive the ac is). Wine/proton simply can’t translate the upper parts of the nt kernel needed for it.
Some games that use EAC, BattlEye and GameGuard, work fine in proton. Afaik, whatever these do and are abstracted to, or is offhanded to some linux native process, it’s still all running in userspace. I’m sure this relies on individual game developers playing along with it, and not 100% “proton emulating the nt kernel” in order to “fool them”. Is this the point you’re arguing? That it won’t be possible by a purely proton/wine translation layer?
If you know details on how exactly this works, or want to point to some resource on this, I’d be happy to read more about it.
My guess is that there is nothing technically impossible about fooling a rootkit by faking whatever syscalls from the game, but that it becomes a impossible task to maintain, as the AC developers can make minor changes that would require a lot of hard work to “emulate”. I’d love to learn more, but it was hard to find good resources on this.
EAC has an explicit linux support that valve worked on them with, it’s not full kernel AC. same with battleye and GG those are not full kernel root anti cheat implementations. I can’t point at any specific documents unfortunately but the wine/proton irc channels are public and lurking let’s you learn a lot as they talk through issues with games and anticheat.
In order for linux to support kernel level AC a module for the Linux kernel would be needed. And i doubt Linus will ever allow that lol
This is… correct. That in order to support kernel level anti-cheat on Linux, you need a kernel module. But that statement is a tautology.
An NT kernel AC running through Wine, and whether or not it “works” doesn’t predicate on a Linux kernel module being loaded. All it needs is the correct handling of whatever the NT kernel would communicate to the running game, and handle whatever that callback is through some other mechanism that passes the checks.
Most AC software have Linux native clients, and that’s what this “some other mechanism”. And whatever that is in practice, should, with enough reverse engineering, be technically possible for proton/wine to do as well. It’s all running on userland after all. I assume that this is not an easy task to do at all, which is why the only realistic approach is for AC developers to actually be on board, and instead just compromise on the weaker level of anti-cheat protection, compared to what you’d get with a kernel module. As far as I understand, this is the case for GG, BattlEye and EAC. Not all games work, because it depends on the developers “allowing it”.
And as for what the future might bring. I expect that with Linux gaming becoming more popular, it’s only a matter of time before a Linux AC is implemented as a kernel module. Also, neither Linus, nor anyone, need to whitelist a kernel module for it to be loaded. The only one that has an ultimate say there is you, the user.
Yes, and part of these make the anti cheat believe it’s running in a kernal.
None of the things needed for a true kernel level anti cheat are in a translation layer, some of them just can’t be. It’s why games with actual kernel level anti cheat have never worked in proton and never will. Historically the only way to play those games is either be on windows or use a vfio virtual machine (which also probably won’t work even with tons of vm hiding techniques depends on just how sensitive the ac is) . Wine/proton simply can’t translate the upper parts of the nt kernel needed for it.
If the anti cheat is working in wine/proton it’s not kernel level