Is there a way to hook clipboard operations in a kernel mode driver?
Thanks,
Sergey
I believe the clipboard is a user mode only construct.
Good luck,
mm
xxxxx@gmail.com wrote:
Is there a way to hook clipboard operations in a kernel mode driver?
Thanks,
Sergey
I am afraid to ask, why would you want to do this in a driver?
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Tuesday, February 12, 2008 1:41 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Hook clipboard operations in kernel driver?
I believe the clipboard is a user mode only construct.
Good luck,
mm
xxxxx@gmail.com wrote:
Is there a way to hook clipboard operations in a kernel mode driver?
Thanks,
Sergey
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Seems like another “Apparently more secured kind of hack…”.
-pro
----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, February 12, 2008 2:20 PM
Subject: RE: Re:[ntdev] Hook clipboard operations in kernel driver?
I am afraid to ask, why would you want to do this in a driver?
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Tuesday, February 12, 2008 1:41 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Hook clipboard operations in kernel driver?
I believe the clipboard is a user mode only construct.
Good luck,
mm
xxxxx@gmail.com wrote:
> Is there a way to hook clipboard operations in a kernel mode driver?
>
> Thanks,
> Sergey
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> I believe the clipboard is a user mode only construct.
Well, once it allows copying app’s A data and pasting it into app B, i.e. is some form of IPC, it cannot be user-mode only construct by its very definition (of course unless it was based upon this or that “variation on the theme” of X protocol, so that both apps were communicating with X server via TCP/IP). However, under Windows GDI and window messaging are implemented in the kernel by win32k.sys. Therefore, once it is implemented by kernel-mode win32k.sys, one can easily hook it in a driver by hooking the shadow dispatch table…
Anton Bassov
Anton:
You very well may be correct. I had thought that this was one of the
few USER features left that was still implemented in user mode, with the
system providing common storage in so that the applications need not
access each other’s address space. I really don’t know, and should have
checked before posting but did not.
Thanks,
mm
xxxxx@hotmail.com wrote:
> I believe the clipboard is a user mode only construct.
Well, once it allows copying app’s A data and pasting it into app B, i.e. is some form of IPC, it cannot be user-mode only construct by its very definition (of course unless it was based upon this or that “variation on the theme” of X protocol, so that both apps were communicating with X server via TCP/IP). However, under Windows GDI and window messaging are implemented in the kernel by win32k.sys. Therefore, once it is implemented by kernel-mode win32k.sys, one can easily hook it in a driver by hooking the shadow dispatch table…
Anton Bassov
Remember that DLLs can share data in usermode between user programs by
allocating it up above the address fence. They can also use explicit shared
sections in various ways. I’d be a little surprised if the clipboard didn’t
turn into VirtualAlloc at some level.
Loren
Anton:
You very well may be correct. I had thought that this was one of the few
USER features left that was still implemented in user mode, with the
system providing common storage in so that the applications need not
access each other’s address space. I really don’t know, and should have
checked before posting but did not.Thanks,
mm
xxxxx@hotmail.com wrote:
>> I believe the clipboard is a user mode only construct.
>
> Well, once it allows copying app’s A data and pasting it into app B, i.e.
> is some form of IPC, it cannot be user-mode only construct by its very
> definition (of course unless it was based upon this or that “variation on
> the theme” of X protocol, so that both apps were communicating with X
> server via TCP/IP). However, under Windows GDI and window messaging are
> implemented in the kernel by win32k.sys. Therefore, once it is
> implemented by kernel-mode win32k.sys, one can easily hook it in a driver
> by hooking the shadow dispatch table…
>
>
> Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
That was my reasoning as well, although as I said earlier, I really
don’t know, and just have a vague recollection of this still being a
user mode mechanism. I don’t personally see that there is much of a
point in going to the kernel. It just seems like unnecessary incurred
overhead in a situation where security isn’t really an issue, as the
whole point is to make it publicly available. There isn’t even a direct
‘you cut then I paste’ protocol, so anyone could end up with it, or
everyone could, or anyone could overwrite what someone else did.
mm
Loren Wilton wrote:
Remember that DLLs can share data in usermode between user programs by
allocating it up above the address fence. They can also use explicit
shared sections in various ways. I’d be a little surprised if the
clipboard didn’t turn into VirtualAlloc at some level.Loren
> Anton:
>
> You very well may be correct. I had thought that this was one of the
> few USER features left that was still implemented in user mode, with
> the system providing common storage in so that the applications need
> not access each other’s address space. I really don’t know, and
> should have checked before posting but did not.
>
> Thanks,
>
> mm
>
>
>
>
>
> xxxxx@hotmail.com wrote:
>>> I believe the clipboard is a user mode only construct.
>>
>> Well, once it allows copying app’s A data and pasting it into app B,
>> i.e. is some form of IPC, it cannot be user-mode only construct by
>> its very definition (of course unless it was based upon this or that
>> “variation on the theme” of X protocol, so that both apps were
>> communicating with X server via TCP/IP). However, under Windows GDI
>> and window messaging are implemented in the kernel by win32k.sys.
>> Therefore, once it is implemented by kernel-mode win32k.sys, one can
>> easily hook it in a driver by hooking the shadow dispatch table…
>>
>>
>> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Yes, I’ve done once ( specialized, very limited number of customers ), nasty
hack in the kernel that I regret for its hacky nature, but customers wanted
just that…
-pro
----- Original Message -----
From: “Martin O’Brien”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Tuesday, February 12, 2008 8:30 PM
Subject: Re:[ntdev] Hook clipboard operations in kernel driver?
> That was my reasoning as well, although as I said earlier, I really don’t
> know, and just have a vague recollection of this still being a user mode
> mechanism. I don’t personally see that there is much of a point in going
> to the kernel. It just seems like unnecessary incurred overhead in a
> situation where security isn’t really an issue, as the whole point is to
> make it publicly available. There isn’t even a direct ‘you cut then I
> paste’ protocol, so anyone could end up with it, or everyone could, or
> anyone could overwrite what someone else did.
>
> mm
>
> Loren Wilton wrote:
>> Remember that DLLs can share data in usermode between user programs by
>> allocating it up above the address fence. They can also use explicit
>> shared sections in various ways. I’d be a little surprised if the
>> clipboard didn’t turn into VirtualAlloc at some level.
>>
>> Loren
>>
>>
>>
>>> Anton:
>>>
>>> You very well may be correct. I had thought that this was one of the
>>> few USER features left that was still implemented in user mode, with the
>>> system providing common storage in so that the applications need not
>>> access each other’s address space. I really don’t know, and should have
>>> checked before posting but did not.
>>>
>>> Thanks,
>>>
>>> mm
>>>
>>>
>>>
>>>
>>>
>>> xxxxx@hotmail.com wrote:
>>>>> I believe the clipboard is a user mode only construct.
>>>>
>>>> Well, once it allows copying app’s A data and pasting it into app B,
>>>> i.e. is some form of IPC, it cannot be user-mode only construct by its
>>>> very definition (of course unless it was based upon this or that
>>>> “variation on the theme” of X protocol, so that both apps were
>>>> communicating with X server via TCP/IP). However, under Windows GDI and
>>>> window messaging are implemented in the kernel by win32k.sys.
>>>> Therefore, once it is implemented by kernel-mode win32k.sys, one can
>>>> easily hook it in a driver by hooking the shadow dispatch table…
>>>>
>>>>
>>>> Anton Bassov
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Thanks to all for your replies. The reason why I wanted to implement this in a kernel mode driver is that I already have such a driver which logs some set of I/O operations. I just wanted to put whole functionality in one place. Taking into account this conversation I would rather prefer to monitor clipboard operations in a separate DLL implementing system wide hooks.
Thanks,
Sergey
Martin,
I had thought that this was one of the few USER features left that was
still implemented in user mode,
I believe they had to move it to the kernel for the security reasons. Under NT GUI-related security boundary is defined as a desktop (which is a kernel object), so that you cannot copy-paste data from one desktop to another…
Anton Bassov
> Remember that DLLs can share data in usermode between user programs by
allocating it up above the address fence.
In Win9x only.
They can also use explicit shared sections in various ways.
Extemely nasty design, which is a primary cause of lack of stability in Win9x,
though yes, supported in NT.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> turn into VirtualAlloc at some level.
In win32k.
Current clipboard data is surely kept in win32k.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> I believe they had to move it to the kernel for the security reasons. Under
NT GUI-
related security boundary is defined as a desktop (which is a kernel object),
so
that you cannot copy-paste data from one desktop to another…
And this makes the whole idea bad.
Apps on the same WinSta are not security-isolated from one another, say,
anybody can send WM_GETTEXT to any edit control.
Creating this long a security perimeter around 1 app without the OS support
seems to be unsolvable task.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Creating this long a security perimeter around 1 app without the OS support
seems to be unsolvable task.
…unless you do it in X-like fashion. As a Linux user I can assure you that GUI-related user experience of X is not worse than that of Windows, despite the need for IPC…
Anton Bassov