Originally Posted by
uNrEaL
Hi,
I just wanted to say thanks for the laughs, of few of your are so off-base with this that it's not even funny.
However, to contribute something useful:
The anti-cheat has levels that you all haven't even encountered yet. Sure, they do work in the kernel, and that's always a pain to deal with. But, if you code efficiently, you won't have to touch anything in ring0, you can let them operate correctly without having any problems with detection. There are no CRC checks to bypass, no APIs to worry about (so long as your module doesn't show in the PEB/TEB linked module list).
Their only real issue, from what I personally have had to contend with, on a few occurrences, is their ability to nail your injecting process. Quite honestly, if you're using a common packer, or anything that implements a static, and easily identifiable signature into your module as protection, you're leaving yourself very susceptible to their scans.
Now, I haven't even begun to tear into the anti-cheat, it hasn't really been necessary. But, from what I gather (and can actually prove this, if someone really wants to challenge me on it), is that they're iterating all processes (not even enuming them, they're literally looping from 0 to 65536 and attempting to OpenProcess on all PIDs. If the call is successful, they hold a handle to it, and ReadProcessMemory (yes, using the ring3 API), to compare data. Where they're doing this from will surprise you.
Let their anti-cheat function, simply evade. If you hide well enough, they'll never find you.
Anyway, that's all I'm going to share for now, just a few quick thoughts. But again, this thread was an interesting laugh, and to my user who pointed me here, I thank you for the entertainment.
Cheers,
uNrEaL