Display Driver and NtGdiBitblt

Hi all!!

I hope this is the appropriate place to ask this, I found no other.
I want to intercept (I didn?t say hook because as I have read this is “ilegal” and dangerous and bad, …) the NtGdiBitblt function. I have seen some antispywares that change the SDT to do precisely that so they can avoid capturing the screen. My questions are:

1.- Are they actually hooking the SDT?

2.- How can I do that without hooking? Is a display driver the option?

Thank you all very much!!

xxxxx@gmail.com wrote:

I hope this is the appropriate place to ask this, I found no other.
I want to intercept (I didn?t say hook because as I have read this is “ilegal” and dangerous and bad, …)

It isn’t the word that’s bad, it’s the concept. Whether you call it
hooking or intercepting or redirecting or subverting or proxying, it’s
still dangerous in kernel code.

the NtGdiBitblt function. I have seen some antispywares that change the SDT to do precisely that so they can avoid capturing the screen. My questions are:

1.- Are they actually hooking the SDT?
2.- How can I do that without hooking? Is a display driver the option?

BitBlt originates as a user-mode API call. It’s certainly possible to
hook API calls in user-mode

Let’s say you could intercept NtGdiBitBlt. What would you plan to do
with it?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thank you Tim!

What I want to do is to implement a very simple anti screen capture software (I know it is impossible to write a robust one: DirextX, Video memory, digital cameras, …) so the screen capture softwares that use Bitblt functions and the like (getpixel, stretchblt, …), and only those softwares, won?t work.

As I said, all antispyware softwares I have seen so far hook NtGdiBitblt function (and some more). I have checked that through the SDT Shadow. I image the reason of that is to prevent all processes from capturing the screen, so that?s why I proposed to do this in kernel land. So now I wonder how they managed to hook these functions.

Thanks you!

xxxxx@gmail.com wrote:

As I said, all antispyware softwares I have seen so far hook NtGdiBitblt function (and some more). I have checked that through the SDT Shadow. I image the reason of that is to prevent all processes from capturing the screen, so that?s why I proposed to do this in kernel land. So now I wonder how they managed to hook these functions.

You can still do hooking on 32-bit Win 7. It’s just the 64-bit version
where they actively prevent it.

I’m not sure I understand the theory. If I have malware on my machine
that is displaying popup ads, I don’t just want to hide the ads. I want
to eliminate the malware and the resources it is consuming. Hiding the
ads is just masking the problem. Who knows what else that malicious
software might be doing?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Yes, all known antispyware apps usually hook win32k functions to block
BitBlt/… functions.
Usually they hook NtGdiBitBlt fn, but they forget to handle
NtGdiBitBltInternal fn for Win7/Win8 (this fn is called in internel win32k
functions, alt+prtscr/prtscr, scrolling, etc).
This won’t work for Win8 x64, because Win8 Kernel Patch Protection checks
win32k’s ssdt table and win32k image.

If you don’t need to map HDC to WND/PID, then you can play with DrvBitBlt
callback, but I think you won’t be able to say if this fn copies from
desktop or window.

This research is good to see how win32k/gdi “works”, but I don’t recommend
you to use it in commercial software.

Thank you both very much for you help!!