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.

+1  A: 

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.
Lucas Jones
+4  A: 
  • 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.

+10  A: 

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.

Zan Lynx
+114  A: 

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.

Actually, the contents of video overlays are pretty hard to grab. You pretty much have to resort to physically taking a photo of the screen.
Chris Becke
Or more simply, once the user has the information, you can't prevent them from sharing it.
Paul Fisher
@Chris Becke: And that's exactly why you cannot prevent this using software. Just take a photo and you're done. And nowadays everybody has a camera inside his phone...
+7  A: 

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.

Peter Štibraný
+59  A: 

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?

Rob Hruska
what a surreal answer. are we not talking inside the machine here and not outside of it???
Chandan .
I don't believe so. Given the question's comment, "which you can't share the chatted information with others," enforcing this on the client is near, if not totally, impossible.
Rob Hruska
Especially since in a debugging situation someone did exactly that--sent me a .jpg from their camera of the screen.
Loren Pechtel
@Loren: haha same!! really was a screen shot!

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.

Jason Baker
+13  A: 

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.

That's actually interesting. Convert the window content to a bitmap, move 1/4 of the pixels each into 4 different bitmaps, shuffle the 4 bitmaps quickly. If you lose focus, blank the window. Even an external camera will at most see 1/2 the pixels.
the pixel shuffling might make it awkward for a fully automatic point and shoot camera to work, but any even cheap camera with shutter speed and aperture control will easily get a picture of the screen.
Only for someone who has such a camera and knows how to use it. The technique also fails if someone does a motion video recording.
You would also be able to build a image with a 4+ screenshots taken, then combine them.

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 :)

+3  A: 

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.

Aaron C
+1  A: 

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 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.

That was a cool game.
A. Rex
+3  A: 

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.

+2  A: 

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.

Likewise you can disable text copy on any windows control in your app
+19  A: 

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

+1 for being clever
hehe nice one + :D

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

Richard Gadsden
I can screenshot a PDF in about .2 seconds. And that is what we are talking about here.

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.

+2  A: 

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?


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.

+1  A: 

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).

Mark Roddy
"but not retain it." part: Then why just not limit the input/output units on the machine. No cd, usb, internet access ... and such. This just seems going the hard way ...

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?!

Dylan Bennett
+30  A: 

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 -

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?

This is an interesting answer! Much more interesting than all the "it's impossible" answers.
Even with all this, if the user can see the screen on his computer.. what would prevent them from using a digital camera to capture the chat?
simucal: It's unlikely that any cameras (yes, that includes mobile phones with cameras) are allowed in such a secure environment. Photographing the secret documents is a very old gag.
Yep, Anthony is correct. Where the app runs is about 150 feet underground and you're checked for phones/ipods/anything vaguely electronic looking by people with guns at the (15 feet thick) door. Oh, plus you're in a large Faraday cage too. Might not be practical for the original questioner :-)
Worked on a similar project at a similar timeframe, but this group wanted designated users to be able to reclassify cut'n'paste snippets. So I rewrote the cut'n'paste parts to follow the modified security rules.
+1  A: 

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.

+1  A: 

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.

+7  A: 

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.

We're getting there :)
+1  A: 

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.

Adam Hawes
I love how people rate these comments down... the simple fact is that the OP can't do what he wants and hiding all the responses that point that out then scoring up the ones that say "sure it's possible" is just compounding the problem.
Adam Hawes
I liked your answer +1 ;) More or less the only option that would actually work.
sindre j
+13  A: 

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.


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.

How would this prevent chat text from being grabbed in any way? You could screencast your desktop and capture each message, hook into the program and screenshot on each received message or still do the photograph the screen trick.

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.

Loren Pechtel

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.


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


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.


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.


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.