this post was submitted on 09 Mar 2024
397 points (87.7% liked)
Gaming
3174 readers
85 users here now
!gaming is a community for gaming noobs through gaming aficionados. Unlike !games, we don’t take ourselves quite as serious. Shitposts and memes are welcome.
Our Rules:
1. Keep it civil.
Attack the argument, not the person. No racism/sexism/bigotry. Good faith argumentation only.
2. No sexism, racism, homophobia, transphobia or any other flavor of bigotry.
I should not need to explain this one.
3. No bots, spam or self-promotion.
Only approved bots, which follow the guidelines for bots set by the instance, are allowed.
4. Try not to repost anything posted within the past month.
Beyond that, go for it. Not everyone is on every site all the time.
Logo uses joystick by liftarn
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I mean sure they could make it a dkms module and have the user install it along with the headers but it's never going to be out of the box supported on linux was what I meant by that
As for the rest, there is a limit to what can be emulated within user space. There are are certain calls in NT ring -1 that would require similar privilege on the Linux side to translate which i doubt wine would ever do for a vast multitude of reasons
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