How I Made Windows Invisible to Screen Capture — and Why Exam Proctoring Is Broken | Write-ups

The Vulnerability in One Sentence

Every major operating system ships a documented API that lets any application make its window invisible to screen capture while remaining perfectly visible on the physical display. Exam proctoring software that relies on screen capture to enforce integrity is structurally defeatable with a single API call.

---

Background: How Proctoring Works

WebRTC-based remote proctoring systems — the kind deployed by universities worldwide since 2020 — work by capturing the student's screen during an exam session. The browser extension or native client requests a getDisplayMedia() stream, transmits it to the proctor's server, and flags anomalies: opened windows, visible applications, clipboard activity. The implicit security model is:

> If I capture your screen, I can see everything on it.

This assumption is wrong on Windows and macOS.

---

The Windows Side: `SetWindowDisplayAffinity`

Microsoft documented this API in the Win32 SDK as a Digital Rights Management mechanism — its intended use case is preventing screen capture of premium video content (think Netflix's desktop app). The function signature is simple:

BOOL SetWindowDisplayAffinity(HWND hWnd, DWORD dwAffinity);

Passing WDA_EXCLUDEFROMCAPTURE as the affinity flag tells Windows to exclude the target window from all screen capture paths:

▹BitBlt / PrintWindow (legacy GDI)
▹IDXGIOutputDuplication (Desktop Duplication API)
▹Windows.Graphics.Capture (modern WinRT)
▹WebRTC's getDisplayMedia() capture pipeline

The window continues to render on the physical display normally. The user sees it. The proctoring stream does not.

No administrator privileges are required. The API operates on windows owned by the calling process, which is entirely within normal user-space operation. No kernel modifications, no driver signing bypass, no privilege escalation.

PoC (Win32 C)

#include <windows.h>

int main() {

HWND hwnd = CreateWindowEx(/* ... window params ... */);

// Single API call — window now invisible to all screen capture

SetWindowDisplayAffinity(hwnd, WDA_EXCLUDEFROMCAPTURE);

ShowWindow(hwnd, SW_SHOW);

// Window is visible on physical display

// Window is absent from all capture streams

MSG msg;

while (GetMessage(&msg, NULL, 0, 0)) {

TranslateMessage(&msg);

DispatchMessage(&msg);

}

return 0;

}

---

The macOS Side: `NSWindow.SharingType.none`

Apple's equivalent is found in AppKit. Every NSWindow instance has a sharingType property, documented in the AppKit reference since macOS 10.6 (2009):

`swift

import AppKit

let window = NSWindow(

contentRect: NSRect(x: 100, y: 100, width: 800, height: 600),

styleMask: [.titled, .closable, .resizable],

backing: .buffered,

defer: false

)

// Single property assignment — window excluded from all capture

window.sharingType = .none

window.makeKeyAndOrderFront(nil)

Setting sharingType to .none excludes the window from:

▹CGWindowListCreateImage (legacy Core Graphics capture)
▹ScreenCaptureKit (SCStreamConfiguration, Apple's modern capture framework)
▹AVCaptureScreenInput (AV Foundation screen recording)
▹WebRTC's getDisplayMedia() on macOS

macOS 26.3.1 remains vulnerable. Apple introduced changes to ScreenCaptureKit in macOS 15 that were widely expected to close this gap, but testing confirmed the .none affinity still produces full capture evasion on macOS 26.3.1.

---

Test Results

| Platform | Proctoring Capture Visible? | Artifacts in Session Log? |

|----------|-----------------------------|---------------------------|

| Windows 10 | No | None |

| Windows 11 | No | None |

| macOS 14 | No | None |

| macOS 26.3.1 | No | None |

| Linux (X11) | Yes | N/A — not vulnerable |

| Linux (Wayland) | Yes | N/A — not vulnerable |

Linux is not vulnerable because neither X11 nor Wayland exposes a per-window capture exclusion API. The absence of this feature is, in this context, a security advantage.

---

Why This Is Structurally Hard to Fix

The vulnerability is not a bug — it is a design conflict between two legitimate OS features:

▹DRM / Content Protection: Media companies need to prevent unauthorized recording of premium content. WDA_EXCLUDEFROMCAPTURE and NSWindow.SharingType.none exist to serve this requirement.

▹Exam Integrity: Proctoring systems assume that capturing the screen gives a complete view of the user's desktop.

These two requirements are fundamentally incompatible. Any OS that supports (1) — which Windows and macOS do by design — cannot simultaneously guarantee (2) at the screen-capture layer.

The only mitigation paths available to proctoring vendors require moving below the OS API layer:

▹Require a native kernel extension / driver component that intercepts at the display driver level rather than the application API level
▹Move to hardware-attested environment proofs (TPM, Secure Enclave) rather than screen content analysis
▹Accept that screen-capture-based integrity is not achievable on general-purpose consumer OS platforms

---

Responsible Disclosure Timeline

| Date | Action |

|------|--------|

| January 2026 | Proctoring vendors notified with full technical writeup and PoC |

| February 2026 | Microsoft and Apple notified |

| March 2026 | Public disclosure after 90-day window; arXiv preprint published |

The vendors' responses confirmed awareness of the OS-level mechanism. The core challenge — that the vulnerability is in a documented OS feature, not a bug in vendor code — limits what any individual vendor can patch without OS-level cooperation.

---

Takeaway

Screen-capture-based exam proctoring on Windows and macOS provides a weaker integrity guarantee than its deployment context requires. The attack surface is a single API call, requires no elevated privileges, leaves no log artifacts, and works across all tested platform versions including the latest macOS release. This is not a novel implementation flaw — it is a systemic design incompatibility between content protection APIs and the integrity assumptions embedded in remote proctoring architecture.

The full 12-page paper, PoC implementations, and disclosure materials are available in the repository.