KernelMode.info

Hello,

I read thie post http://www.kernelmode.info/forum/viewto ... =14&t=1692 where the author writes that hooking of Win32k system call table is prohibited on Windows 5 (to be more precise: the Patchguard detects modifications of the driver).

I admit I did not expected this change because I had seen hooking of win32k.sys in quite many of well-known security software (Comodo, Kaspersky, Avast, Outpost, SandboxIE). It seems that this change will get them into a lot of troubles.

I tried to find some useful discussions about the topic, however, I did not find anything which would give me information I am looking for. I did not find any official statement what drivers and data structures exactly the Patchguard controls now.I did not see any new interfaces that would help the vendors to make their products equally functional without hooks in win32k.sys.

Do you know about any additional information about the topic?

Thanks in advance

Ronen Tzur, author of Sandboxie, has been working in Windows 8 support for some time. Considering his comments he has been having troubles to get Sandboxie supported, but actually he just needs to fix some bugs to get the thing working.

Theoretically, I am able to cope with Windows Hooks and similar stuff. Raw Input Devices, AttachThreadInput, Get(Async)KeyState (and possibly other system calls), however, are the key points of my interest.

If you just want to realize window self-protection, you can use JOB OBJECT.
I hear that process in JOB cannot access other processes which not in the same JOB.

Hello m5home,

I know about Job objects. The problem is they do not allow to decide whether certain operation (sending of a message, installation of a hook) should be permitted or blocked. They block it always (in case of Windows Hooks, processes outside the job are not hooked).

I am interested mainly in the HIPS-like behavior. I think a job object is fine for sandboxing purposes, however, I see its usage in HIPS to be problematic.

Vrtule

Vrtule wrote:I read thie post viewtopic.php?f=14&t=1692 where the author writes that hooking of Win32k system call table is prohibited on Windows 5 (to be more precise: the Patchguard detects modifications of the driver).

Does anyone know if this is true?

Vrtule wrote:I admit I did not expected this change because I had seen hooking of win32k.sys in quite many of well-known security software (Comodo, Kaspersky, Avast, Outpost, SandboxIE). It seems that this change will get them into a lot of troubles.

Maybe because of KPP Kaspersky resigned from sandbox in KIS2013?

Buster_BSA wrote:Ronen Tzur, author of Sandboxie, has been working in Windows 8 support for some time. Considering his comments he has been having troubles to get Sandboxie supported, but actually he just needs to fix some bugs to get the thing working.

Sandboxie uses a lot of UM hooks, so it can to the same job by using only them - doesn't it?

Alex wrote:

Vrtule wrote:I read thie post viewtopic.php?f=14&t=1692 where the author writes that hooking of Win32k system call table is prohibited on Windows 5 (to be more precise: the Patchguard detects modifications of the driver).

Does anyone know if this is true?

Yes. You can google full of drama topic at MSDN forums where developer of one of such BSOD-generators cry in hysterics. Very funny indeed, using well-known OS security hole in your commercial product and expect this flaw not be closed in the next version of OS, rofl.

Sandboxie uses a lot of UM hooks, so it can to the same job by using only them - doesn't it?

From what I saw in quick reversing of this dll, this is just a compatibility layer for making sandboxing of application transparent for application itself. For example translate real sandboxie registry keys into virtual names.

As for alternate to hooking, have a look on sandboxie 4.01 implementation, he seems found the way by implementing something like restricted security context.

HIPS and x64 lol, no thanks.

@myid

Use "Private messages" if you want to ask somebody about something personal. Offtopic removed.

EP_X0FF wrote: Very funny indeed, using well-known OS security hole in your commercial product and expect this flaw not be closed in the next version of OS, rofl.

To be fair, (I read) that Windows specifically didn't include Patchguard in any future x86 versions because so many commercial products violated it, so it's an understandable assumption.

moda wrote:

EP_X0FF wrote: Very funny indeed, using well-known OS security hole in your commercial product and expect this flaw not be closed in the next version of OS, rofl.

To be fair, (I read) that Windows specifically didn't include Patchguard in any future x86 versions because so many commercial products violated it, so it's an understandable assumption.

1) What is the point of this necroposting?
2) You read wrong.

Necroposting. Closed.