+- +-

+-User

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?

+-Stats

Members
Total Members: 129
Latest: dilpreetkaur
New This Month: 1
New This Week: 1
New Today: 0
Stats
Total Posts: 319
Total Topics: 160
Most Online Today: 2
Most Online Ever: 68
(October 18, 2019, 12:38:07 am)
Users Online
Members: 0
Guests: 2
Total: 2

Author Topic: Anti-Cheat  (Read 848 times)

sagaantheepic

  • Newbie
  • *
  • Posts: 2
    • View Profile
Anti-Cheat
« on: March 19, 2018, 09:14:16 pm »
well, trying to write an anti cheat to try to learn better about kernel drive.  Well to start off, i made a driver which basically strips all handle permissions from any program ( not csrss and lsass ) which tries to get a handle from a game i chose. i have also made a DLL which basically checks for loaded modules, and create threads which basically check the thread's start address and checks if their address is within the loaded module. Well, the help i need is basically a list.

Prevent thread suspension / hijacking
Handle stripping
Callback relocation / substitution
Load/create notifications
Blacklist drivers
Scan pool headers for rogue kernel modules
Physical memory scan for rogue kernel modules
Check module integrity for game (starting data, hash, then check against hash. Also check free memory and analyze any newly allocated memory)
Prevent driver loads
Prevent dll loads
Check vad entries against pages in game memory
Check for virtualization (Hypervisors/virtual machines)
Check for hooks on modules (IAT,EAT,INLINE)
Build heuristic sandbox for auto analysis of dumped drivers/hacks
Hook setthreadcontext and verify where thread will resume


Not really asking for codes ( even know i learn better by viewing at the code and how it works and by playing with them ), help such as links or anything that can get me to read up on methods to avoid all this. Thank You!!!

xchg

  • Administrator
  • Newbie
  • *****
  • Posts: 35
    • View Profile
Re: Anti-Cheat
« Reply #1 on: March 21, 2018, 06:19:55 am »
I don't understand..

So you've made your ObRegisterCallbacks driver to strip access handles, but you ask for resources regarding that exact topic? And on that note, you have quite a few topics listed above to check out.

Also, a few of these topics seem to run into one-another. For instance, integrity checks on the game should rule out the existance of inline byte patching.

I know it probably doesn't help you, but your post reminds me of what I do when I get really immersed in a project. You know, these great ideas get thrown around to create an absolutely fool-proof anti-cheat capable of catching any possible cheat module thrown at in *in the wild* with zero repercussions, but not all of the ideas are a). easily implementable and b). reliable enough to not generate false-positives. Additionally, and perhaps on a lighter note,  not all of these preventative measures are necessary to implement a decent anti-cheat. You should never have to worry about creating a "heuristic sandbox for auto analysis", as it goes beyond the scope of any realistic anti-cheat.

Edit:
Just wanted to throw in that I wish you the best of luck on your journey. Whatever you end up creating will likely be of excellent reference and aid to you in the future. And while I do believe in this instance you may want to scale back your expectations, never ever lose sight of that creativity. Having been in similar situations, it's what will always give you a leg up against other developers/engineers in this field. 
« Last Edit: March 21, 2018, 06:26:37 am by xchg »

sagaantheepic

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: Anti-Cheat
« Reply #2 on: March 21, 2018, 04:33:08 pm »
the thing right now i am worrying about is thread hijacking and using system programs to get a handle to abuse. well, i learnt alot of things throughout this journey about kernel and drivers in general by adding loaded modules checking, create thread hooking, communication between driver and a usermode program and handle stripping, but i was wondering what more i can do to avoid things like injections, hijacked threads and abusing system processes

xchg

  • Administrator
  • Newbie
  • *****
  • Posts: 35
    • View Profile
Re: Anti-Cheat
« Reply #3 on: March 23, 2018, 07:04:24 am »
the thing right now i am worrying about is thread hijacking and using system programs to get a handle to abuse. well, i learnt alot of things throughout this journey about kernel and drivers in general by adding loaded modules checking, create thread hooking, communication between driver and a usermode program and handle stripping, but i was wondering what more i can do to avoid things like injections, hijacked threads and abusing system processes

The traditional AC's approach to this problem is to monitor which processes have an access handle to your game, then check them against a list of whitelisted programs--this being the relatively short list of signed official Windows processes that would require a handle. Preventing this would allow you to ensure if an attack is to originate in usermode, it will more specifically originate from the inside of a whitelisted process; and in that you have a significantly reduced attack surface.

Notably, you could also check the integrity of system processes the same way you would for game processes. In some cases, with more accuracy.

Furthermore, you could monitor what processes have a handle open to the aforementioned system processes, however it would be irresponsible to ban for just that.

Now you come to the next detection vector, as it would pertain to injection. As it relates to widely-accessable tools and (moreover) forms of injection, the stealthiest you're going to get is manual mapping.

Assuming you have a kernel callback to become notified of traditional arbitrary modules, or a minifilter to catch them before they can even touch down in the address space of your process (or something else related to either of these), manual mapping is the next logical step for most that will attempt to hack your game.

Of course, a lot of this is contextual, and very opinionated on my part; but here's what you can do to minimize the attack surface:

If you were to, say, scan for a sig'd CRT in pages of memory that allow for execution, then correlate the located memory address of the arbitrary module with a list of valid loaded modules, you could generate a detection that way, or dump the memory at that location for further investigation (since malware could theoretically do the same thing--wouldn't want to ban someone for unintentional stupidity). This would even allow you to locate modules that have a wiped PE header.

More on the abstract side of things, you could scan for data structures in memory that resemble ones commonly found in the offical PE file format, although that is purely speculative. It would be hard to generate a justifiable ban off of just that; however, it could aid in further investigation.

The above is what I'm currently doing to cheat in a game :)

Additionally, you could scan for hooks on common interfaces like that of Direct3D (and friends).

 

+-Recent Topics

Independent Call Girls in Chandigarh by dilpreetkaur
June 21, 2021, 01:02:52 pm

Hi zwclose7. How to create process by using NT apis? by zwclose7
June 01, 2021, 03:09:52 pm

Poison of the Day by zwclose7
March 16, 2020, 06:45:08 pm

IRC by AzeS
February 17, 2020, 08:18:01 am

Native API tutorial by hMihaiDavid
January 08, 2019, 02:11:02 am

The properties of GP nerve agent by xchg
October 19, 2018, 07:40:57 pm

A new route of synthesis for G-series agents by Basquyatti
October 15, 2018, 06:12:57 am

Synthesis of Methylisobutylcarbinylsarin (GH) by APC process by Basquyatti
October 14, 2018, 07:55:33 am

Synthesis conventional of Sarin by Basquyatti
October 02, 2018, 07:57:32 am

Reaction CX-7 (Experimental) by zwclose7
October 02, 2018, 12:46:47 am