Preventing Mirror Drivers from allowing remote "snooping" on local activity

Question

Background: I'm looking at ways of capturing data securely. Obviously with keyloggers being so easy to get hold of and/or build, the keyboard is off limits, so there's an on-screen keypad.
I use the CreateDesktop method in winsta to create a desktop, then the other associated methods to push my thread to it and draw the window.
This all works fine - nobody can actually get to the thread to harvest the data or watch the button clicks. Also, nobody can take a screenshot in the traditional manner - I've got that worked out too.
The thorn in my side is mirror drivers. They can see everything on the desktop, even if it's a new desktop. Not only that, but a local application can "hotwire" any installed Mirror Driver and record or transmit data using it, according to a project
on CodeProject that leverages the RDP Encoder Mirror Driver for taking screenshots. (For this reason, simply suspending the processes that I expect to be installed and using mirror drivers is really insufficient.)
So far I have:
- Enumerated display drivers (EnumDisplayDevices in user32)
- Worked out which ones are Mirror Drivers or Remote
- Got the existing mode info with EnumDisplaySettings
- Enabled "unsafe modes" with ChangeDisplaySettingsEx
- Attempted to set the resolution to a very small number (this didn't work)
- Attempted to set the bits per pixel to zero (this didn't work)
I would like to either:
- Block the whole screen
or
- Block the client area where the action is taking place
Any suggestions would be greatly appreciated.
CodeProject article about hijacking the "RDP Encoder Mirror Driver": http://www.codeproject.com/Articles/716128/Using-RDP-Encoder-Mirror-Driver-to-Capture-Screen

Answer 1

Hi,
IMHO, to reliably prevent screen capturing done by mirror driver, you need to write your own video filter which sits on top of microsoft's mirror driver and filters the screen mirroring functions. Please see below link for a similar
discussion:
http://securityresearch.in/index.php/projects/malware_lab/malware-screen-captures/
Also, you may need to monitor any other device attaching to that device stack (as the need may be). Here, I am considering usage of any other mirror drivers (such as that of Ultra VNC). Hope that helps.
(Please mark as answer if it resolves your query. Please upvote if this post is helpful.)
Rajesh.
Thanks for your input Rajesh
The page you linked seems pretty high-level and the referenced page, http://gpalem.web.officelive.com/screencap.html, seems to have an unresolvable hostname.
Writing a mirror driver seems like a potentially viable option - I could call it and tell it which regions to mask, returning a handle to each region. Then I could unmask by passing the pointer back in. However, that would require an additional driver to
be installed which may be beyond the deployment capability available.
Last night (probably your daytime) I was toying with the idea of drawing a bitmap on only the mirror drivers displays - I guess this must be the way Windows displays a "1" on your first screen and a "2" on your second screen when you
click the "Identify Monitors" button and the desktop is duplicated.
-- EDIT --
Enumerating displays with EnumDisplayDevices presents all display devices including the Mirror Drivers, but doesn't provide any DeviceContexts. Enumerating Monitors with EnumDisplayMonitors does not present any Mirror Drivers, only "Displays" that
are actually "connected." This may include the "RDPDD Chained DD" driver if the user's session is being accessed over RDP. This information can also be retrieved by checking the DisplayStateFlags returned by EnumDisplayDevices to see if
the AttachedToDesktop flag is set. This does mean it's possible to detect the use of the Chained DD Driver and thereby prevent data entry over RDP (and perhaps Remote Assistance) but doesn't solve the problem at hand (which would also prevent RDP/RA - and
would therefore be the better problem to solve.)