CS:GO Kernel Mode Cheats

[nullptr_t]

Also if you are running your driver in kernel mode it is still going to affect the user space, and any user space modification could be analyzed by ring3 (usermode) applications. Trust me, it's not impossible.

Yes, I agree with that, for example a program could check for the loading of the driver that has a vulnerability and then trigger some action. But I doubt that VAC will implement a technique like that any time soon.

- - - Updated - - -

[SIZE=3]I Recently developed a x64 driver which can perform the task of reading/writing memory of a user mode program. The driver will be controlled from a user mode program using IOCTL. The controlling program will send information (same arguments as in RPM/WPM, with the exception of using process id instead of a handle) to the driver, which then will execute the request.

This requires no interfering with the target process from user mode; no opening handles, or any other sketchy stuff besides the ProcessId lookup (which can be done from kernel mode with PsSetLoadImageNotifyCallback if needed, or by just manually typing it to the controlling program.)

Does anyone else here have experience with kernel mode hacks? They would be practically undetectable with VAC protected games since VAC does not have a driver, nor does it scan other processes than the ones that open handles to games protected by it.

Another way of doing this would be just destroying the handle table of the external cheat from kernel mode, or hiding the process. Not sure if VAC would kick you out of the game for 'blocking' it's scanning though.

You could pretty much convert any external user mode hack to implement this technique by just replacing RPM & WPM with KernelRead & KernelWrite functions, then load the respective driver and make the cheat pretty much undetectable.

*Couldn't Edit post so*

This is what such technique using user mode application would look like:

Remember, this program does not interfere with cs:go nor steam in any way.

[javalover]

But I doubt that VAC will implement a technique like that any time soon.

What makes you think it's not implemented? VAC exists since 2002, developers for sure have experience with it. Countermeasures against it should have been implemented however a long time ago.

[l1m3w1r3]

What makes you think it's not implemented? VAC exists since 2002, developers for sure have experience with it. Countermeasures against it should have been implemented however a long time ago.

exists since 2002 and still sucks dick

[WasserEsser]

exists since 2002 and still sucks dick

Because it's not a proactive anti cheat.
It's one of the best anti cheats taking in consideration that it's ring3, isn't proactive and cares about privacy.

- - - Updated - - -

You still didn't describe the way of detecting a driver loaded the way I specified. Also, you could make the cheat 100% kernel level, with no user mode application (aside from loading ofc), how would VAC go with that then?

If you're manually mapping your driver into kernel space, you are still in memory. Your driver is present in memory which can get detected, especially if you're using anything that can get caught easily such as strings etc.. Your driver is also running a thread just like any other application, as described in a thread about TDL on another forum already.

VAC is not a proactive anti cheat and therefore doesn't detect your driver unless they want to detect it. This though is the same for any other coded cheat, they won't detect it until you give them a reason to.

[nullptr_t]

What makes you think it's not implemented? VAC exists since 2002, developers for sure have experience with it. Countermeasures against it should have been implemented however a long time ago.

Because someone would have spotted it, and it likely would be in the uc wikia & all over different forums.

- - - Updated - - -

Because it's not a proactive anti cheat.
VAC is not a proactive anti cheat and therefore doesn't detect your driver unless they want to detect it. This though is the same for any other coded cheat, they won't detect it until you give them a reason to..

Well this was kind of what I was looking for, this technique would be undetected for as long as it wouldn't have so many users that valve would actually bother to take action against it.

- - - Updated - - -

Because it's not a proactive anti cheat.
It's one of the best anti cheats taking in consideration that it's ring3, isn't proactive and cares about privacy.

VAC is still designed in the manner of being as profitable for valve as possible, and not for the interest of community / players. To be effective, it should actually have some heuristic capabilities, and not rely on human and signature based detection only.

[javalover]

Because someone would have spotted it, and it likely would be in the uc wikia & all over different forums.

Yeah, of course. Valve developers are more professional and experienced of what you think they are, they are not like 10 guys from a random forum of cheats and hacks for games. I don't think they fear those '10 guys', and if they don't make the anti-cheat operative it means they are often busy to do something other.
In fact, as I was correctly thinking: https://en.wikipedia.org/wiki/Valve_Anti-Cheat#History

In February 2014, rumors spread that the system was monitoring websites users had visited by accessing their DNS cache. Gabe Newell responded via Reddit, clarifying that the purpose of the check was to act as a secondary counter-measure to detect kernel level cheats, and that it affected one tenth of one percent of clients checked which resulted in 570 bans

[nullptr_t]

Also if you are running your driver in kernel mode it is still going to affect the user space, and any user space modification could be analyzed by ring3 (usermode) applications. Trust me, it's not impossible.

Yeah, of course. Valve developers are more professional and experienced of what you think they are, they are not like 10 guys from a random forum of cheats and hacks for games. I don't think they fear those '10 guys', and if they don't make the anti-cheat operative it means they are often busy to do something other.
In fact, as I was correctly thinking: https://en.wikipedia.org/wiki/Valve_Anti-Cheat#History

That dns cache analysis is merely a proof that VAC is interested about kernel mode cheats, something more specific is going to be needed. Also, obviously it does not do shit if the hack does not establish any connections to anywhere. I bet that there are some other techniques VAC uses to identify kernel level cheats, other than that (also it was later on removed). But I really doubt that VAC does have countermeasures against manually loaded drivers, as of this date.