3 ms·

Eventually those signals can accumulate to some threshold and they will ban single users. They do improve their anti cheat pretty regularly and a cheat that onl

Eventually those signals can accumulate to some threshold and they will ban single users. They do improve their anti cheat pretty regularly and a cheat that only provided 1 or 2 suspicious signals (e.g. rxw memory in the kernal space that isn't backed by some valid module) might eventually provide 3 or 4 as they improve their anti cheat (maybe they start looking in some obscure windows table to find evidence that you loaded a bad driver in the past or they stackwalk your kernel thread to find it executing in unbacked memory).

therein 4y ago
> (e.g. rxw memory in the kernal space that isn't backed by some valid module) They do flag you for this but not actionable on its own as PatchGuard demonstrates the exact same kind of behavior. RWX memory in Kernel Space that's not associated with a signed module. As you also surely know, there is also a lot of rwx memory that's not actually utilized yet allocated by many drivers that you can deploy your shellcode into.
- google234123 4y ago
  > They do flag you for this but not actionable on its own as PatchGuard demonstrates the exact same kind of behavior. RWX memory in Kernel Space that's not associated with a signed module. I'm sure most cheats use drivers that are pretty similar to each other (e.g. will have the same imports that show up as plaintext I think) so they can look for that. And PG threads/pages have plenty of identifiers. > As you also surely know, there is also a lot of rwx memory that's not actually utilized yet allocated by many drivers that you can deploy your shellcode into. Usually most cheats will use this shellcode to still jump back into the larger suspicious RWX memory region. I guess discardable sections might be large enough to hold an entire driver. I haven't really been following the latest developments in this field≥

therein 4y ago

> (e.g. rxw memory in the kernal space that isn't backed by some valid module) They do flag you for this but not actionable on its own as PatchGuard demonstrates the exact same kind of behavior. RWX memory in Kernel Space that's not associated with a signed module. As you also surely know, there is also a lot of rwx memory that's not actually utilized yet allocated by many drivers that you can deploy your shellcode into.

google234123 4y ago
> They do flag you for this but not actionable on its own as PatchGuard demonstrates the exact same kind of behavior. RWX memory in Kernel Space that's not associated with a signed module. I'm sure most cheats use drivers that are pretty similar to each other (e.g. will have the same imports that show up as plaintext I think) so they can look for that. And PG threads/pages have plenty of identifiers. > As you also surely know, there is also a lot of rwx memory that's not actually utilized yet allocated by many drivers that you can deploy your shellcode into. Usually most cheats will use this shellcode to still jump back into the larger suspicious RWX memory region. I guess discardable sections might be large enough to hold an entire driver. I haven't really been following the latest developments in this field≥