DR Hooks and Detection

[GliderPro]

Cypher will you share some details about the LuaNinja detection? I saw your post about the detection code being in the client. What was it checking for? Did it just look for a DR hook on a specific address? Are DR hooks a worse idea now?

[amadmonk]

If they're checking for DR breakpoints in the code segment, they're going to start banning a bunch of people who are debugging WoW. If they're going to ban for it, they'll likely ban on *specific* addresses in DRx, which implies that the generic hooking method would still be safe, just not that specific hook.

This is just an assumption. Until the powers that be look at what specific checks Warden is making, it's all guesswork.

Edit: I read the LuaNinja thread, and it appears that this check was snuck in in a code change in the client, not in Warden. I think that other than that, my post is still factually correct. I'll wait for Cypher to correlate/disagree, since he knows a lot more about this specific issue than I do.

[kynox]

DR hooks are safe.

luaninja was detected by the old warden memory scan but to circumlate cyphers protection he updated the code on the fly and not directly. Thats what is meant with in the client.

Kynox os theory is based on a buggy wow version which prevented the indirect update on his computer.

^ This. Warden was the detection method used to detect LuaNinja (by finding his module); all they did was circumvent Cypher's protection.

[Cypher]

Rather than detect the DR hooks they added code to the client (which then indirectly modified Warden) to bypass my hook on NtQueryVirtualMemory.

So DR hooks are still at the same point as they were previous to the LuaNinja banwave in terms of how 'safe' they are currently.

[GliderPro]

Thanks for the reply Cypher. How did they bypass your NtQueryVirtualMemory hook? Was it an IAT hook or a detour? Was the bypass specific to your hook or is it general enough to bypass all NtQueryVirtualMemory hooks?

On a side note you know your protection was solid if they had to resort to a client patch to detect it.

[amadmonk]

I wonder if they could reliably bypass a detour on NTQVM, given that there are many flavors in the wild.

IAT hooks, pfft. Easy.

[Cypher]

Thanks for the reply Cypher. How did they bypass your NtQueryVirtualMemory hook? Was it an IAT hook or a detour? Was the bypass specific to your hook or is it general enough to bypass all NtQueryVirtualMemory hooks?

On a side note you know your protection was solid if they had to resort to a client patch to detect it.

It was general enough to bypass all usermode NtQueryVirtualMemory hooks. You would have to add extra hooks to defend against the method they used.

I wonder if they could reliably bypass a detour on NTQVM, given that there are many flavors in the wild.

IAT hooks, pfft. Easy.

I wan't using an IAT hook, I was using a detour. I planted an INT3 at the top of the function and used VEH to do the redirect so their API hashing scan couldn't be used.

[flo8464]

It was general enough to bypass all usermode NtQueryVirtualMemory hooks. You would have to add extra hooks to defend against the method they used.

I don't know how their bypass looks like, but it should be pretty safe to hook NtQueryVirtualMemory's kernel equivalents by writing a driver, correct?

[kynox]

I don't know how their bypass looks like, but it should be pretty safe to hook NtQueryVirtualMemory's kernel equivalents by writing a driver, correct?

You're limiting yourself to x86 then; unless you a) Own a x64 code signing cert and b) Can bypass KPP.

[flo8464]

You're limiting yourself to x86 then; unless you a) Own a x64 code signing cert and b) Can bypass KPP.

I never wrote any drivercode since I use x64 Win7.
That means, Windows forbids me to install my selfwritten drivers unless I pay money or bypass it? Holy shit, that sucks. I am not the _administrator_ to be treated like a child by my OS...

[Cypher]

I never wrote any drivercode since I use x64 Win7.
That means, Windows forbids me to install my selfwritten drivers unless I pay money or bypass it? Holy shit, that sucks. I am not the _administrator_ to be treated like a child by my OS...

No, KPP is a good thing. It keeps malware from installing kernelmode rootkits, and it stops people abusing kernelmode drivers to do shit they shouldn't be (i.e. AV software hooking the kernel, Anti-cheat software hooking the kernel, etc).

They're not "treating you like a child", they're protecting the integrity of the OS.

KPP and driver signing are two separate things.

If you want to write and install your own drivers then you can simply test-sign them and enable test mode when you boot into Windows. However, if you want to deploy your driver to the masses, it's expected that you pay for a certificate (this gives the user liability, and Microsoft control, so the user knows that the driver is untampered and where it came from, etc, and Microsoft can request to have your certificate revoked if you start doing something you're not supposed to with it).

KPP is designed to stop hooking of the kernel (as mentioned above), and unless you're doing something you're not supposed to it's of no concern to you.

The problem here is that you are trying to do something that you're not supposed to.

[FEUP]

Bypass KPP is actually possible right?
binary modifications, etc - by Fyyre
saw some stuff from fyyre as somethings like easyhook etc.

I know nothing about device drivers , kernel related stuff so better dont try to say something really wrong.

[flo8464]

The problem here is that you are trying to do something that you're not supposed to.

Too bad that it's so much fun doing things I am not supposed to do.
I guess a Linux system would be a better playground for me.

[Cypher]

Bypass KPP is actually possible right?
binary modifications, etc - by Fyyre
saw some stuff from fyyre as somethings like easyhook etc.

I know nothing about device drivers , kernel related stuff so better dont try to say something really wrong.

Of course bypassing it is possible. But it's not a trivial task by any means, and in the past Microsoft have always reacted to public bypasses by updating KPP to break and defend against them.

Too bad that it's so much fun doing things I am not supposed to do.
I guess a Linux system would be a better playground for me.

Think of it as a rite of passage. If you're not smart enough to work out how to bypass KPP, you shouldn't be touching that shit (read: hooking the kernel) to begin with.

[nitrogrlie]

It was general enough to bypass all usermode NtQueryVirtualMemory hooks. You would have to add extra hooks to defend against the method they used.

I wan't using an IAT hook, I was using a detour. I planted an INT3 at the top of the function and used VEH to do the redirect so their API hashing scan couldn't be used.

Heh, makes it sound like they re-loaded ntdll library from disk and bypassed you by over-writing your over-written code. They could have compared a checksum or even specific bytes. I guess they could have also specifically just over-written the int3 at top of function with a hardcoded "in-client" sequence of bytes if the intent was purely for LuaNinja detection. Anyways, just shooting of the hip, and you are right, there is methods against each one of those.