Is there any way to detect a screen capture or recording?

Question

I'm making a Winforms program for a friend, and one of the functions he wants implemented is to hide the contents of a textbox from being recorded; meaning he wants it safe from screenshots and screen recordings.

At this point I tried explaining the futility of this, explaining that

1. There are LOADS of programs that can be used to record/capture the screen, and trying to watch for all of them would not only be too exhaustive to explain, it would also be pointless, since any programmer worth his salt can put together a personal program that can take a screenshot without using any of the known names
2. Even IF you somehow manage to block every program, a person can just take a picture of the screen

To answer the issue of taking a picture of the screen, he said that while we can't make the program perfect, we CAN make it as hard as possible for someone to "hack" it. (Personal opinion is that he's sort of right, but I don't think we should go overboard for something with such a simple work-around)

His answer to the issue of there being tons of different recording program however was sort of interesting, but I don't know enough to give him answer with confidence. He theorized that there HAD to be some common action in all of the programs, since to some degree, they all grab a copy of the data that is displayed on the screen to use, and that we should be able to theoretically be able to detect that action and react accordingly.

So my question is this: Does anyone know if there is a common action for programs that record the screen, and if there is a common action, what it is?

Hixon

Answer 1

All the screen capture programs work the same in that the interact with the graphics engine to capture the image of the screen at a point in time but that is as far as it goes, there is no event trigger when a screen capture is done and so no way to detect when a capture occurs.

Edit: The way a screen capture program gets access to the screen is by calling GetDC(NULL). It then copies the contents into a bitmap using the BitBit function. There is no event triggered when calling GetDC(), there may be a method built into Windows which has not been documented by Microsoft and is hidden deep within the Windows API but nothing which has been documented at this time.

For more information on this, take a look at Windows Confidential: What You See Is What You get

Entrench

and too many programs interact with the graphics engine for something accessing it to be able to be flagged? Or does interacting with the graphics engine not trigger any event? – Hixon

The interaction doesnt trigger any known event at all. – Entrench

But if there is a specific one I'd be looking for, would I be able to detect it if I knew what to listen for? (e.g. like how snap chat detects screen shots?) – Hixon

If you knew exactly what screen capture programs you wanted to watch for and new what their service name was then you could theoretically write a program to watch for started services and when they appeared trigger an event you could work with but this method would be useless at detecting the print screen key press on the keyboard. Snapchat manages screen shot protection only because trying to take a screenshot on iOS devices interrupts the touches on the screen which is why you have to keep touching the screen for SnapChat to work, Windows has no such feature or workaround. – Entrench

GetDC(NULL) is indeed not a true solution. Bit Blitting from it blits from the primary GDI Surface and NOT from the Framebuffer itself. You MUST hook into DWM to get proper desktop image. There are some apps that don't draw on GetDC(NULL) and one of them is Magnifier. And most games. Start Magnifier, set it to lens view, hit PrintScreen and notice you get black window. Try print screen in any Exclusive Mode game. – Festivity

GetDC(NULL)/BitBlt() is operating at the GDI compatibility layer (introduced alongside the DWM in Windows Vista). A screen capture program could just directly hook into the compositor, bypassing the GDI altogether. Indeed, starting with Windows 10 1803, this has been formalized with a public API under the Windows.Graphics.Capture namespace. – Bukovina

Answer 2

In case of screen capture, if we monitor the clipboard and detect the foreground application running, we can recognize the activity. In case of snipping tool, if capture a screen shot it goes to clipboard and we can paste it directly.

Benjamin

it's a good really answer and I wish I'd thought it it way back when, but you're reviving a long dead post – Cassiecassil

There is zero correlation between capturing the screen and placing data on the clipboard. Literally none. This isn't useful in the least. – Bukovina

Answer 3

The supported way to prevent window contents to show up in a screen capture is to mark the respective window so that the OS can blank it out.

This is done using the SetWindowDisplayAffinity API call, introduced in Windows 7. Passing the WDA_MONITOR flag will allow the window to display on a monitor. The window will appear with no content everywhere else (such as when capturing the screen).

Take note that SetWindowDisplayAffinity can only be used on top-level windows. There is no public API to selectively apply the same behavior to child windows (such as an EDIT control).

Bukovina