How I Made Windows Invisible to Screen Capture, and Why Exam Proctoring Is Broken

The Vulnerability in One Sentence

Windows and macOS expose documented window-sharing or capture-affinity settings that can keep an application's window visible on the physical display while excluding it from capture paths that honour those settings. The study demonstrates the resulting gap in screen-capture-based proctoring using controlled laboratory simulations.

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 compatible screen capture paths, including:

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

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 requests exclusion from capture paths that respect the window-sharing flag. Relevant capture interfaces include:

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

Tested macOS 26.3.1 native captures remained affected. Despite Apple's documented ScreenCaptureKit changes in macOS 15, the study observed capture exclusion with .none using native capture tools. It did not test browser-based capture on macOS 26 or establish the behaviour of every ScreenCaptureKit client.

Test Results

These results concern simulated proctoring in a controlled laboratory, not commercial products. The macOS 26 evaluation used CGWindowListCreateImage and the screencapture utility, not a browser getDisplayMedia() call. Linux X11 and Wayland were not tested. The behavioural study involved n = 8 consenting research-team members; p = 0.41 does not prove that behavioural detection is impossible. The findings reflect tested software versions as of March 2026; later versions may behave differently.

Why This Is Structurally Hard to Fix

The vulnerability is a design conflict between two legitimate OS features:

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

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

Mitigation options have trade-offs and do not establish a universal integrity guarantee:

• ▹Native capture-exclusion flag enumeration and window-focus monitoring can provide additional signals, subject to the limitations discussed in the paper
• ▹Move to hardware-attested environment proofs (TPM, Secure Enclave) rather than screen content analysis
• ▹Advocate for OS-level capture-integrity APIs and assess residual risks rather than assuming capture alone proves integrity

Responsible Disclosure Timeline

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

The tested Windows and macOS capture paths can omit an application window while it remains visible to the user, without elevated privileges or observed capture artefacts. This exposes a mismatch between content-protection features and the assumption that captured pixels fully represent the physical display. The study establishes that gap within its tested laboratory scope; it does not establish that every commercial proctoring product or every capture API can be bypassed.

The full 13-page paper is linked from the project page. Full proof-of-concept source code is not publicly released; verified security researchers and proctoring vendors may request it under responsible-use agreements. The illustrative API examples above are retained as part of the article.