CS:GO Kernel Mode Cheats
CS:GO Kernel Mode Cheats
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.
Here is an example (just a proof of concept):
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.
Here is an example (just a proof of concept):
Good shit 
Originally Posted by Imsobad
Good shit
Originally Posted by nullptr_t
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
Originally Posted by WasserEsser
What makes you believe that? You also don't need a driver to detect another driver.
- - - Updated - - -
Originally Posted by antep2727
Kernel mode programs are still leaving "traces" in usermode (Registry, Config files?). Vac only needs to find away to detect those and R.I.P.
Or how do you think are big p2c getting detected? They are also kernel mode hacks
Or how do you think are big p2c getting detected? They are also kernel mode hacks
Originally Posted by nullptr_t
The method I use to load the driver is done with shellcode, not with windows loader. The loaded driver will just be a block of executable code in kernel mode, and thus will not be linked on PsLoadedModuleList. So gl detecting that from usermode m8.
- - - Updated - - -
Well they do leave traces if you load them the standard way, but to my knowing VAC does not look for those traces. I am not really sure if vac is even interested about drivers in the first place. There was a debate few years ago when VAC had an update in which it looked for you DNS cache to recognize connections to known p2c provider's servers, but if I remember right it was removed afterwards as being criticized being too invasive.
- - - Updated - - -
Well they do leave traces if you load them the standard way, but to my knowing VAC does not look for those traces. I am not really sure if vac is even interested about drivers in the first place. There was a debate few years ago when VAC had an update in which it looked for you DNS cache to recognize connections to known p2c provider's servers, but if I remember right it was removed afterwards as being criticized being too invasive.
Originally Posted by nullptr_t
The method I use to load the driver is done with shellcode, not with windows loader. The loaded driver will just be a block of executable code in kernel mode, and thus will not be linked on PsLoadedModuleList. So gl detecting that from usermode m8.
Originally Posted by nullptr_t
There was a debate few years ago when VAC had an update in which it looked for you DNS cache to recognize connections to known p2c provider's servers, but if I remember right it was removed afterwards as being criticized being too invasive.
You're telling me that you can't detect the driver object that is registered because you "load the driver with shellcode"? Lol.
It was removed once P2C's noticed that and began to use proxies etc.. Apart from that, why do you even bring that up when we're talking about drivers? Traces are left behind and easily catchable. VAC does use methods to identify drivers to detect P2C's
Originally Posted by nullptr_t
I was talking with the other guy about the kernel p2c detection, and that was one of them. Why do you have to start argument on every god damn thing?
Originally Posted by WasserEsser
Looking at the DNS cache has nothing to do with drivers, that's what I'm saying.
Originally Posted by WasserEsser
You're telling me that you can't detect the driver object that is registered because you "load the driver with shellcode"? Lol
Yeah, the driver is loaded using an exploit in another signed driver which is loaded first (a well known & used one). The driver loaded using the exploit leaves no traces to PsLoadedModuleList, so want to tell me how you could possibly detect it from user mode?
Originally Posted by nullptr_t
I didn't get your reply on that yet
The module list is not the only place where a driver is present. Also, using another legit driver doesn't save you, just like using skype as a process for your dll doesn't save you. Open handles is not the only thing Valve looks out for. If they know that your application is using another legit driver, they will obviously look out for that.
Originally Posted by WasserEsser
Please read the following book: https://technet.microsoft.com/en-us/.../bb963901.aspx
The module list is not the only place where a driver is present. Also, using another legit driver doesn't save you, just like using skype as a process for your dll doesn't save you. Open handles is not the only thing Valve looks out for. If they know that your application is using another legit driver, they will obviously look out for that.
The module list is not the only place where a driver is present. Also, using another legit driver doesn't save you, just like using skype as a process for your dll doesn't save you. Open handles is not the only thing Valve looks out for. If they know that your application is using another legit driver, they will obviously look out for that.
Originally Posted by nullptr_t
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?
Originally Posted by nullptr_t
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.
Or how do you think are big p2c getting detected? They are also kernel mode hacks
