[xqrzd]

It seems I already have the answer to this question but I'll ask anyway, is DKOH (direct kernel objects hooking) covered by PatchGuard? I remember reading a while ago from wj32 that DKOH was not covered by PatchGuard, but I think it is. I have been testing DKOH on Windows 7 64-bit and it seemed to be working until one day I got this:

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/ke ... ching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d8936cf641, Reserved
Arg2: b3b7465ee5eb3567, Reserved
Arg3: fffffa8000c38b10, Failure type dependent information
Arg4: 0000000000000008, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification

But I can't seem to reproduce it. Does PatchGuard only run randomly? I have been using DKOH for a while and only 1 BSOD...

edit: Just got another of the same BSOD, PatchGuard definitely covers DKOH. Took it a while though, several hours to detect hooked function. Guess I have to find something else :(

[Alex]

Hi! Could you tell us which structure did you modified?

[xqrzd]

I was trying to copy RkU's self-protection, I hooked OpenProcedure in process and thread objects.

[Vrtule]

Hello,

Few years ago I tried DKOH on 64-bit Windows Vista and encountered same problem. The only difference is that PatchGuard on my test machine reacted mostly after ten or twenty minutes.

At that time, I searched the web for the solution and found somewhere that there was an update to PatchGuard which adds ability to detect DKOH.

[xqrzd]

I see. Thanks for the info Vrtule :)

[EP_X0FF]

Why not sign your driver and use ObRegisterCallbacks instead?
Hooking, patching etc all this legacy stuff from x86-32 and it must die.

Or kill PG with Fyyre code :)

thread moved

[xqrzd]

you are back :mrgreen:
I am currently using ObRegisterCallbacks, I was just looking for something a bit more powerful
I would rather not bypass PG, as MS would probably revoke my digital signature :shock:

[Vrtule]

The disadvantage of ObRegisterCallback is that it supports only process and thread objects. I think that sometimes it is desired to protect also objects of other kinds.

But maybe, there were an update to the technology. It seems to me that they''ve implemented the callback by general manner.

[Flopik]

I dont think your certificate can be revoke only because of DKOH , I saw av compagnies inline patching Win32k.sys function on X64 OS

[xqrzd]

are they bypassing PG to do that? I don't know if inline hooks are detected. they better be careful though, I remember reading an article where symantec stated they would bypass PG, and MS responded by saying they would update PG to BSOD symantec computers.

edit: I guess it makes sense they would hook win32k.sys, MS didn't provide any documented way for GUI self-protection (other than SetWindowsHookEx, which is weak and doesn't work well at all)