Kernel Mode Game Hacking

Posts 1–15 of 23 · Page 1 of 2

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):

How much marijuana did you smoke to assume that VAC doesn't detect kernel level cheats?
ROFL. What is this? 2009 ?

Originally Posted by Hitokiri~

How much marijuana did you smoke to assume that VAC doesn't detect kernel level cheats?
ROFL. What is this? 2009 ?

This is supposed to be a discussion, not a debate, so swallow your hostility.

Originally Posted by nullptr_t

This is supposed to be a discussion, not a debate, so swallow your hostility.

And in this discussion, I'm asking you what drugs did you take to think VAC doesn't detect ring0 drivers?
That's not hostility, just a simple question.

P.S. If you've seen me post before, you'd know I always speak like this. It's not hostility, it's personality.

Originally Posted by Hitokiri~

Okay, I agree. I made a mistake there. I assume you know what TDL is; and I kinda doubt that VAC is able to detect drivers loaded with it, since the loaded drivers are not linked to PsLoadedModuleList, instead the driver just exists as a buffer in the kernel mode. Neither are any registry keys or any shit like that created.

Either way this is just speculation, and I am not sure, that's why this thread is marked as a discussion, if VAC actually is able to detect drivers that run as "driverless" please correct me please

- - - Updated - - -

Originally Posted by JosephKat

I think VAC can't detect it automatically, but once they have your executable, they can put it in their blacklist and make it 'detectable'.

But I'm sure you can make it undetectable for anti cheats like xtrap etc. By the way I wanted to find a way to use WPM/RPM in xtrap games, I would love if you can share it. o:

Here is a simple trigger bot, just look up how to read user mode memory from kernel mode.

If you dump the VAC 3 module you'll see how it does it. It does in fact detect ring0 drivers.

Originally Posted by Hitokiri~

If you dump the VAC 3 module you'll see how it does it. It does in fact detect ring0 drivers.

What about "Driverless" TDL Drivers? Would say that they're different deal, since they are manually mapped to kernel space.

VAC is using the following functions:
As you see there are quite a few to interfere with a driver.
CREDITS cra0 @UC

Code:

SetupDiGetClassDevsA
  LocalAlloc
  VirtualAlloc
  VirtualQueryEx
  SetFilePointer
  OpenFileById
  NtQueryInformationThread
  QueryDosDeviceA
  AddVectoredExceptionHandler
  GetModuleBaseNameA
  CreateFileW
  LookupPrivilegeValueA
  GetVersionExA
  CreateFileA
  GetSystemInfo
  FindVolumeClose
  OpenThread
  ReadProcessMemory
  GetModuleFileNameExA
  EnumServicesStatusA
  EnumProcessModules
  GetFileVersionInfoSizeA
  VirtualProtect
  HeapAlloc
  SetupDiGetDeviceRegistryPropertyA
  WaitForSingleObject
  OpenProcessToken
  GetProcessHeap
  GetProcessId
  NtWow64ReadVirtualMemory64
  OpenSCManagerA
  NtQueryInformationProcess
  SymGetModuleBase64
  NtMapViewOfSection
  SetupDiEnumDeviceInfo
  GetModuleFileNameA
  GetCurrentThreadId
  SetupDiDestroyDeviceInfoList
  CreateRemoteThread
  EnumProcesses
  OutputDebugStringA
  GetLogicalDriveStringsA
  FlushInstructionCache
  GetFileSizeEx
  GetMappedFileNameA
  NtQueryVirtualMemory
  GetFileInformationByHandleEx
  CloseHandle
  IsWow64Process
  Process32First
  StackWalk64
  GetModuleInformation
  SetLastError
  NtQueryObject
  VirtualFreeEx
  SetFilePointerEx
  LoadLibraryA
  OpenEventLogA
  ReadEventLogA
  NtWow64QueryInformationProcess64
  NtQuerySystemInformation
  Process32Next
  OpenProcess
  Module32First
  NtWow64QueryVirtualMemory64
  GetCurrentThread
  SwitchToThread
  GetWindowsDirectoryA
  QueryServiceConfigA
  SuspendThread
  NtReadVirtualMemory

Originally Posted by RoPMadM

VAC is using the following functions:
As you see there are quite a few to interfere with a driver.
CREDITS cra0 @UC

Code:

SetupDiGetClassDevsA
  LocalAlloc
  VirtualAlloc
  VirtualQueryEx
  SetFilePointer
  OpenFileById
  NtQueryInformationThread
  QueryDosDeviceA
  AddVectoredExceptionHandler
  GetModuleBaseNameA
  CreateFileW
  LookupPrivilegeValueA
  GetVersionExA
  CreateFileA
  GetSystemInfo
  FindVolumeClose
  OpenThread
  ReadProcessMemory
  GetModuleFileNameExA
  EnumServicesStatusA
  EnumProcessModules
  GetFileVersionInfoSizeA
  VirtualProtect
  HeapAlloc
  SetupDiGetDeviceRegistryPropertyA
  WaitForSingleObject
  OpenProcessToken
  GetProcessHeap
  GetProcessId
  NtWow64ReadVirtualMemory64
  OpenSCManagerA
  NtQueryInformationProcess
  SymGetModuleBase64
  NtMapViewOfSection
  SetupDiEnumDeviceInfo
  GetModuleFileNameA
  GetCurrentThreadId
  SetupDiDestroyDeviceInfoList
  CreateRemoteThread
  EnumProcesses
  OutputDebugStringA
  GetLogicalDriveStringsA
  FlushInstructionCache
  GetFileSizeEx
  GetMappedFileNameA
  NtQueryVirtualMemory
  GetFileInformationByHandleEx
  CloseHandle
  IsWow64Process
  Process32First
  StackWalk64
  GetModuleInformation
  SetLastError
  NtQueryObject
  VirtualFreeEx
  SetFilePointerEx
  LoadLibraryA
  OpenEventLogA
  ReadEventLogA
  NtWow64QueryInformationProcess64
  NtQuerySystemInformation
  Process32Next
  OpenProcess
  Module32First
  NtWow64QueryVirtualMemory64
  GetCurrentThread
  SwitchToThread
  GetWindowsDirectoryA
  QueryServiceConfigA
  SuspendThread
  NtReadVirtualMemory

Those APIs only work for regular windows drivers that are registered successfully, and for example listed in the PsGetLoadedModuleList. However, this driver is manually mapped to kernel space, without the windows loader, thus making the driver only a block of executable code in the kernel mode.

Originally Posted by nullptr_t

Well this doesn't change its behavior.
I really respect your work and I think you did a clean job, but unfortunately I think it won't deliver the safety you wish.

Originally Posted by RoPMadM

Well this doesn't change its behavior.
I really respect your work and I think you did a clean job, but unfortunately I think it won't deliver the safety you wish.

That's true, VAC can still develop a method to detect this even if they didn't have a method right now, assuming this would become an issue for valve. Quote from wasser:

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.

Originally Posted by nullptr_t

That's true, VAC can still develop a method to detect this even if they didn't have a method right now, assuming this would become an issue for valve. Quote from wasser:

I don't get why they 'wouldn't want to detect kernel-level cheats'.

they won't detect it until you give them a reason to.

I could have been saying the same thing for the viceversa: they will detect it until you won't give them a reason to not do it (if there is one). To belie everything (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

it means there is a primary countermeasure against kernel level cheats.

Originally Posted by javalover

I don't get why they 'wouldn't want to detect kernel-level cheats'.

I could have been saying the same thing for the viceversa: they will detect it until you won't give them a reason to not do it (if there is one). To belie everything (https://en.wikipedia.org/wiki/Valve_Anti-Cheat#History):

it means there is a primary countermeasure against kernel level cheats.

Yes we already discussed about VAC analyzing dns cache in the csgo forum's thread, but it only was effective agaist popular providers. Besides, the whole feature even got removed afterwards due to the criticism it received. There was a great debate on reddit about that few years ago, which I followed.

When I get home on sunday, will spend whole day analyzing the latest dumps and actually gonna see what is true and what not

Originally Posted by nullptr_t

DNS cache has nothing to do with providers, it's managed from your computer's operating system or web browser. However, as developers are aware of it, a countermeasure is for sure at 98% implemented.

Posts 1–15 of 23 · Page 1 of 2

Dave84311 23 long ago Combat Arms DiscussionsNew INSTANT win game hack? ALL MODESIHihaxjoh 4 long ago General Game HackingGame Hacking IMPOSSIBLE IN VISTA?

Dave84311 13 long ago General Game HackingMPGH Game Hacking Group

Dave84311 22 long ago General Game Hackinghow can i make game hack?!!!!UNUnknownID 2 long ago

Tags for this Thread

None

Kernel Mode Game Hacking

Post a Reply

Similar Threads

Tags for this Thread