The license is with regards to “GOG Service”, not “GOG Contents”. You need the former to get access to the latter, sure. But what isn’t clear about this?
You still own the contents (though, as mentioned, individual titles may have additional blablabla). If you don’t think this distinction makes sense when it comes to GoG vs Steam, then maybe you’re just discussing something entirely different?
What do you mean? Native Linux isn’t that relevant these days. Most games run well through Proton, and some even better than on Windows. Judging by the protondb entry, you wouldn’t notice on Linux that this was a windows game: www.protondb.com/app/2142790
I was surprised to see two games called Knightfall. Not the one you’re referring to (assuming it was a typo), is a 2D dungeon crawler, and came out in 2017, with 13 reviews.
Huh, interesting that it’s OK to have such a similar name. Maybe it’s all OK until someone complains.
There are are certain calls in NT ring -1 that would require similar privilege on the Linux side to translate
Why would that be the case? I have to look this up and read more about it, because I don’t see why that needs to be the case. I’m also not sure if this is still in the context of AC “rootkits”. Because if so, I imagine the security model goes something like this
AC RootKit: Can observe app processes and all memory usage, and modify anything at any time. It observers processes for known cheats, and reports this to the game, either with a callback the game registers, or by directly modifying the game memory.
Wine: Runs in userland. Syscalls are “intercepted” as with all other windows API calls. The NT kernel doesn’t exist here. Wine just tries to answer those calls as if it did.
Game executable: Has some mechanism to talk to-from the rootkit. Likely that the RK itself, since it monitors processes, hooks straight into the game exectuable by either manipulating the memory required for the game to say “ait, RK said you’re cool”, or something like that.
Game executable running in Wine: Runs in userland, and wine has already talked to the Linux kernel and allocated memory. To the loaded game executable running through wine, the memory can be manipulated the same as a rootkit could, because after all, the wine process is the parent process of that memory range.
So, what mechanism is it that an AC RK does, that, from the perspective of a user process running on Wine, cannot be done unless actually coming from the Linux kernel? I honestly cannot think of anything.
Or rather… only possible way I can think of is a “cryptographic guarantee”, in some secureboot based signature and communicating with a remote service in order to authenticate the RK , which the game executable also confirms. Something like that. But this isn’t the case for any of the AC RKs afaik
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.
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.
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.