this post was submitted on 09 Mar 2024
396 points (87.6% liked)

Gaming

2520 readers
249 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.


founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] okamiueru 1 points 4 months ago* (last edited 4 months ago)

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