How can I prevent users from taking screenshots of my application window?

Question

What are some methods to prevent screenshots from being taken, if any?

I've considered setting the "Print Screen" button as a hotkey, which makes the window fuzzy. However, there would be the problem of other 3rd party screenshot tools. How can I prevent their use?

Why would I want such a thing?

The idea is to create a chat client which you can't share the chatted information with others, not by copy & paste nor by print screen...

Looking for general ideas or suggestions rather than actual code.

Answer 1

I don't think that this is possible. AFAIK, You would have to change Windows functions in (I think) user32.dll. A couple of ways, going down this route, would be:

• Change GetWindowRect to check for your application
• Change the screen copy function (can't remember name) to check for your application.

Answer 2

• Screen cams (e.g. camtasia) would need to be detected - perhaps launch a check on app startup (don't run if they're even installed? or just running), then a check every 5 seconds.
• But what about if the user took a (physical) photo of the screen? ;)

As for using hotkeys etc.:

Windows implements Print Screen using a registered hotkey. Windows uses the predefined hotkeys IDHOT_SNAPDESKTOP and IDHOT_SNAPWINDOW to handle Print Screen. These correspond to Print Screen, which captures the entire screen, and Alt+Print Screen, which captures only the active window. To disable these functions all you have to do is register the hotkeys, which causes Windows to send your app a WM_HOTKEY message when the user presses either hotkey.

http://labnol.blogspot.com/2004/08/disable-print-screen-key-in-windows.html

Answer 3

I would say give up. You can't do it. There is not only local screen capture tools to worry about, but terminal services as well.

Answer 4

This is a losing battle. Once the pixels are on the screen it is game over. Any "protections" you put in could be subverted with a trivial amount of reverse engineering or ingenuity.

You need to re-think your chat client strategy because this is something you aren't going to be able to prevent. If the user can see it then it can be grabbed.

Answer 5

Just don't display anything, use other means like speech synthesis, printer, braille terminal ... but then you need to solve how to stop people from recording sound, or copying paper or taking photos of terminal.

Answer 6

To truly prevent it is impossible. How are you going to stop someone with a digital camera taking a picture of the screen, uploading it, and sharing it?

Answer 7

This sounds more like a case for your end users having the appropriate permissions set up. If they don't, there's not a lot you can do.

Answer 8

What would be fun is to show only part of the image, like every second pixel and then swap really fast between those two images. But if someone wanted to take a picture he'd be able to do so, but you could increase the amount of work he has to do.

Answer 9

I don't say it often but in this particular case ... give up before you start. Nice concept that many people have tried to do and ALL have failed :)

Answer 10

You can not stop it from happening, even if you some how manage to completely lock out screen monitoring software, they can run the software inside a VM take the shot from the host OS, or if you stop the software from running inside a VM and lock out screen captures it's still nothing a good old camera wouldn't take care of.

Nothing short of developing a new OS for a new CPU type and a new type of monitor which manages to run in such a way cameras can not take pictures of it, and even then maybe.

Answer 11

The quick answer is that it's not possible and not worth doing beyond getting rid of the most common methods people would use such as disabling the print-screen hotkey and even that if you absolutely have to. Anything beyond that would probably get kind of intrusive or otherwise just annoy users.

But for ideas there's an interesting and rather extreme example of something that achieves this in http://silverspaceship.com/static/ which is a simple platformer game uses differently animated/moving white noise for the entirety of it's graphics.

However it'd hardly be feasible for displaying any amount of text and while it'd take slightly more effort, it'd still be possible to capture videos of it.

And I wouldn't really encourage trying something this because it's ultimately still futile as "copy protection" can always be cracked with enough effort.

Answer 12

OK, so if you hid your chat and required users to wear these glasses to read it, even if they took a picture the message would be hidden. Except, of course, if someone were to attach the glasses to a camera and took a picture, but that's just silly.

Answer 13

Disabling the PrintScreen key only disables the key. Instead you could monitor the Windows Clipboard for CF_BITMAP content. Basically if anyone captures your window to the clipboard, either by PrintScreen or other app, you can deal with it as soon as it happens by removing the content. This does not solve the entire issue I know, but as most basic capture methods use the clipboard it would stop the casual offender.

Windows API should provide everything necessary to do this.

Answer 14

Ship your app as one of those MagicEye 3d picture renders. I can never see those.

Answer 15

Does anyone know how Adobe do it in Acrobat Reader? They certainly do a pretty good job of making secured PDFs hard to read.

Answer 16

It is impossible. If there is an output from a system, be it video, audio, anything that we can register, a machine can be created that can also register that output and record it. We can record images with a camera, sounds with a microphone... The only way to do it would be to stop the user being able to see it, or having some kind of implant!

If someone puts DRM on an audio file, you can still record the outputs to the speakers. If someone puts DRM on a video file, you can still use a camcorder to video the screen itself.

It's just impossible. Sorry.

Answer 17

How about some way of abusing the interleaved technique? Would it be possible to show every x lines and then switch to the other lines so that the human eyes perceive it as normal, but prtscrn gets it as useless?

Answer 18

Its impossible. But in case you find the answer do share with everyone. Ya, may be an interleaved technique ... but then what about people clicking the screen with digital camera? give up bro.

Answer 19

I'd suggest looking into alternative display technologies that Print Screen (and 3rd party apps) would not be aware of, perhaps a simple character LCD.

In regards to many people's answers that only address the quality of the question, there seem to be a lot of assumptions that aren't fair to the OP. This functionality smells of software to be used in the intelligence communities/government contractors who are often allowed to access data but not retain it.

In that case many of the issues such as taking a photograph of the screen/Terminal Services/video capture may not even be an issue as security policies for using such a machine would most likely prevent any such devices being allowed. Though the worry about 3rd party apps makes me wonder if this is merely an intellectual exercise (or a help me explain to my boss why this won't be cost effective question).

Answer 20

You want User A (who wants to use the app) to see the pixels of the application and at the same time you want to prevent User B (who wants to take a screenshot) from being able to see the pixels of the application. The problem you have is that User A and User B are the same person.

Sarcastic rant: Ask the music labels how well it's working for them to prevent listeners from making digital copies of their music. They've had many more millions to throw at the problem than you will ever have, so they must be able to come up with something that works 100%... right?!

Answer 21

Ok, so I wrote a jokey answer (MagicEye) above and realized that I had actually done this before in the past. Unfortunately my answer is in the 'accurate but not at all useful to me' category.

We had more or less the exact same requirement to do this as part of a military project I worked on, where you couldn't take some 'secure' chat text and copy/paste/screengrab it around. To do this we used something called a Multilevel Security O/S - http://en.wikipedia.org/wiki/Multilevel_security

So we had an app running under DEC Unix MLS talking to Trusted Oracle 8i (you can probably get a timescale how long ago this was) and the whole project was quite the living nightmare. We had a windowing system where basically everything floated up in terms of security labels until you had to be the brother or sister of the almighty just to get to see anything of use. But cut n paste or screenshots were effectively stopped (as was any other type of useful work).

Soooo, my answer is, yes, you can do this but you have to use an operating system and corresponding window manager that is part of a Trusted Computing Base than works with a form of Mandatory Access Control. For some fun reading you could also check out the 'Orange Book' classifications and see that Windows is as 'C2' system, when what you really need is a 'B1' one.

I bet you wish you never asked now eh?

Answer 22

You could make it into some kind of sport/chat client, whereby the user has to type or move the mouse constantly or the display is instantly blanked. Although the problem would not be solved for anyone who has any friends that can take a picture whilst the user is frenziedly typing or moving the mouse, it would make it very difficult for the solo user to take a photo. Think of it as a loner tax.

You need to first analyze the typing profile on a user-by user basis and develop a fiendish algorithm which will detect any attempt at one-handed typing, hunt-and-peck and so forth, when the user has traditional been a 90-wpm-smith. In addition, this obscene logic must also allow the less adept typist use the app without let or hindrance. Maybe the odd derogatory dialog.

If the user managed to circumvent these obstacles, then at least you could remain smug in the knowledge that they would probably resemble a complete buffoon whilst attempting the keyboard/mouse logic evasion plus one-handed camera manoeuvre.

Answer 23

The simple rule: If content can reach a person's eyes or ears, it can't be protected. The more hurdles you put in place to protect content, the less users will want to use your product.

So, assuming david-ing-name's answer isn't an option, there will almost certainly be no way to keep someone from capturing the content.

My attempt, for a client running on a user's general purpose computer to which they have complete control, i would use images to disable cut&paste. In other words, all messages are presented as an image to the receiving end. You can even go so far as to make it a captcha-style image so that OCR will be difficult. To deal with screen-shots, you can only put hurdles in place but one idea, sticking with the image captchas, is to require users to enter a captcha to be able to read content, otherwise the text is simply unavailable to the client. For the user to continue to read the content, they must keep the mouse over a small area of the screen and/or hold down a certain key combination. Specifically, something that would prevent them from changing focus to another application. Still, with all that in place, anyone reasonably skilled could get around all this fairly easily by, for example, simply cracking the client. And there is no technique available to handle cracking the client unless you're writing a webapp. But with a webapp, the screen-capture becomes easier to crack and harder (impossible?) to implement.

Answer 24

You not only need a secure OS, software, and transmission, but also the user (whom you do not trust not to attempt to record) must be seated in a special room (or bunker, depending on your security requirements), access to which is controlled through a special check-in like in an airport, plus the user has to go in naked, with any strange implants disabled.

Answer 25

You could sit with your one user and make sure they don't have any external screen grabber hardware plugged in, don't use a camera of any sort, etc. That might work.

Answer 26

I am amazed that no one has mentioned this. Put your interface on a DirectShow overlay surface. Since the surface exists in a separate part of memory and is "overlayed" by the video card right before being displayed on the screen, "normal" screen grabbers won't see it.

It won't be easy but you could create a virtual source filter that draws your interface and feeds it directly into the overlay mixer. You won't have access to standard windows controls and you will have to intercept mouse coordinates and button activity and translate those coordinates to where the are on the overlay.

This would also fix the copy and paste problem because the text would exist only as a drawing, not as something that can be selected.

This is not unbeatable, but it will defeat most screen grabbers that rely on the OS to get the pixel data.

Like anything in security, nothing is impossible to break, but you can make it more difficult until the cost to break in isn't worth what you get in return.

Answer 27

Why not just rethink the idea. Have a decay timer that will remove each chat entry after, assuming, enough time passed that the other users could have read everything.

Answer 28

To extend the idea of changing the image, how about the following approach (not tested):

You'll need a big font to make this at all usable. Make a bitmap of what you wish to show. The color choice should be a reasonably dark gray on a reasonably light gray.

Now, prepare another bitmap. The initial values are random grayscale. For each pixel you maintain a running total of the errors between what was displayed and what is desired. On each iteration you pick new random values except weighted by the effects of this running total.

So long as these are blasted out frequently enough I think the human eye should be able to read it as a pattern in the static. Any snapshot will be defeated, though, as it will be nearly pure static.

This only leaves time exposures or summing repeated screenshots. These can be partially defeated by making the text blink back and forth.

This will obviously be obnoxious to read and I can't picture it being reasonable outside a secure environment and it could still be defeated by a sufficiently intelligent screen grab routine--something that could figure out which were the positive and which were the negative frames.

Answer 29

You can't without adding system-wide hooks.

(Either at the usermode level with an injected DLL or at the kernel level with a driver)

Either way though a reverser could easily bypass it.

You're fighting a loosing battle.

Answer 30

This doesn't claim to solve the taking a photo problem, but what about this program (don't know if it works)?

http://www.copysafe.net/

Answer 31

The only way I can think of doing this in an ultimately fail-proof way is by relaying the images directly to the user's brain and forgoing a screen completely.

Then again, once we get to this stage, we'd likely be able to download from our brain anyhow... hello Johnny Mnemonic.

Answer 32

A project I am working on also contains sensitive information. The main problem is that the application is a web application. This causes problems because we can't control the terminal accessing the application.

What we did was, we used a watermark on the background of the application. The watermark is automatically generated which contains the userID in the watermark. If data gets leaked, we can at least see who provided the screenshot.

Again, this is not entirely foolproof. You can always edit this in a graphic editor, or simply tone down (or up) contrasts and brightness of the image. You can always print then use whiteout and photocopy it.

Answer 33

Similar like any other encryption technology you will need two parts. A public part and a private part.

So you might come up with a chat window but you cannot read it, only when you hover a secondary application over the window you can make it readable.

On that secondary window you can stop all window events, but as mentioned in a different answer, somebody can still take a picture from it with a camera.

I'm just wondering what the use case is for this requirement. It doesn't sound like a better mouse trap to me.