So, what are your thoughts on this: what if the driver were to be performing integrity checks on whatever communication protocols an attacker would 'spoof' or 'patch'? E.g. Any IRP handlers, Callbacks, Named pipes, etc.
-
-
Replying to @daax_rynd @layle_ctf and
The entire reason they're moving to the kernel is because you can't protect userland from the kernel. But you also can't protect the kernel from the kernel. Integrity checks fail when you fully control both ends, which you can do with a malicious kernel module.
1 reply 0 retweets 0 likes -
Replying to @fox8091_1 @layle_ctf and
I was asking what an attacker could do, not why they should or shouldn't be in the kernel.
1 reply 0 retweets 2 likes -
Replying to @daax_rynd @layle_ctf and
An attacker could just block the anti-cheat from loading and load their own module that just reports everything as all good (either by making the functions do nothing or returning valid responses) while allowing them to cheat as much as they want.
3 replies 0 retweets 0 likes -
Replying to @fox8091_1 @layle_ctf and
This is quite trivialized. The amount of work and expertise to accomplish such a feat is cumbersome. These drivers load on boot for a reason that you've also just stated. I'm not sure why Riot is taking all the flak when BattlEye, EAC, etc., use kernel drivers as well.
1 reply 0 retweets 2 likes -
Replying to @daax_rynd @layle_ctf and
Unless the anti-cheat drivers are ELAM signed (very unlikely), you can just change the load order and load your module on boot
1 reply 0 retweets 0 likes -
Replying to @fox8091_1 @daax_rynd and
The load order doesn't matter at all. If you really wish you can forcefully unload the driver at any time. I don't think Riot developed something that would make this impossible?
1 reply 0 retweets 1 like -
Replying to @layle_ctf @daax_rynd and
I mean, in theory they could prevent force unloading the driver by mangling the kernel API to unload modules, but that would break other stuff. But yeah, load order doesn't even matter that much
1 reply 0 retweets 0 likes -
Replying to @fox8091_1 @daax_rynd and
"Mangling the kernel API" requires you to modify things in kernel space which is something that Microsoft *does not* want you to do which is why PatchGuard exists.
1 reply 0 retweets 1 like -
Replying to @layle_ctf @daax_rynd and
There are tools to both disable PatchGuard at runtime (Shark) and at boot time (EfiGuard), but at that point it's hitting malware levels of invasive
3 replies 0 retweets 0 likes
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.