Cómo oculté ventanas a la captura de pantalla y por qué falla la supervisión de exámenes

La vulnerabilidad en una frase

Windows y macOS ofrecen ajustes documentados de uso compartido o afinidad de captura que permiten mantener una ventana visible en el monitor físico y excluirla de las rutas que respetan esos ajustes. El estudio demuestra la brecha resultante en la supervisión basada en captura mediante simulaciones de laboratorio controladas.

Contexto: cómo funciona la supervisión

Los sistemas de supervisión remota basados en WebRTC, utilizados por universidades de todo el mundo desde 2020, capturan la pantalla del estudiante durante el examen. La extensión del navegador o el cliente nativo solicita un flujo getDisplayMedia(), lo envía al servidor del supervisor y marca anomalías: ventanas abiertas, aplicaciones visibles y actividad del portapapeles. Su modelo de seguridad implícito es:

Si capturo tu pantalla, puedo ver todo lo que hay en ella.

Esta suposición es incorrecta en Windows y macOS.

En Windows: SetWindowDisplayAffinity

Microsoft documentó esta API en Win32 SDK como mecanismo de gestión de derechos digitales. Su uso previsto es impedir la captura de vídeos protegidos, por ejemplo en la aplicación de escritorio de Netflix. La firma de la función es sencilla:

BOOL SetWindowDisplayAffinity(HWND hWnd, DWORD dwAffinity);

Pasar WDA_EXCLUDEFROMCAPTURE como indicador de afinidad solicita a Windows excluir la ventana objetivo de las rutas de captura compatibles, entre ellas:

• ▹BitBlt / PrintWindow (GDI clásico)
• ▹IDXGIOutputDuplication (API de duplicación del escritorio)
• ▹Windows.Graphics.Capture (WinRT moderno)
• ▹La canalización getDisplayMedia() de WebRTC

La ventana sigue dibujándose normalmente en el monitor físico. El usuario la ve; el flujo de supervisión no.

No se necesitan privilegios de administrador. La API actúa sobre ventanas pertenecientes al proceso que la llama, dentro del funcionamiento normal del espacio de usuario. No modifica el núcleo, elude firmas de controladores ni eleva privilegios.

Prueba de concepto (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;
}

En macOS: NSWindow.SharingType.none

El equivalente de Apple está en AppKit. Cada instancia de NSWindow tiene una propiedad sharingType, documentada en la referencia de AppKit desde 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)

Asignar .none a sharingType solicita excluir la ventana de las rutas que respetan su indicador de uso compartido. Las interfaces de captura relacionadas incluyen:

• ▹CGWindowListCreateImage (captura clásica de Core Graphics)
• ▹ScreenCaptureKit (SCStreamConfiguration, el marco de captura moderno de Apple)
• ▹AVCaptureScreenInput (grabación de pantalla de AV Foundation)
• ▹getDisplayMedia() de WebRTC en macOS

Las capturas nativas probadas en macOS 26.3.1 seguían afectadas. Pese a los cambios documentados por Apple en ScreenCaptureKit con macOS 15, el estudio observó exclusión con .none mediante herramientas nativas. No probó captura desde navegadores en macOS 26 ni estableció el comportamiento de todos los clientes de ScreenCaptureKit.

Resultados

Los resultados corresponden a supervisión simulada en un laboratorio controlado, no a productos comerciales. La evaluación de macOS 26 utilizó CGWindowListCreateImage y la utilidad screencapture, no una llamada getDisplayMedia() del navegador. No se probaron Linux X11 ni Wayland. El estudio conductual incluyó n = 8 miembros del equipo con consentimiento informado; p = 0.41 no demuestra que la detección conductual sea imposible. Los hallazgos reflejan las versiones probadas hasta marzo de 2026; las posteriores pueden comportarse de otra forma.

Por qué es difícil corregirlo por diseño

La vulnerabilidad nace de un conflicto entre dos funciones legítimas del sistema operativo:

1. DRM / protección de contenido: las empresas de medios necesitan impedir grabaciones no autorizadas de contenido protegido. WDA_EXCLUDEFROMCAPTURE y NSWindow.SharingType.none existen para cubrir esa necesidad.

2. Integridad del examen: los sistemas de supervisión suponen que la captura ofrece una vista completa del escritorio del usuario.

Ambos requisitos son incompatibles en esencia. Un sistema que admite (1), como Windows y macOS por diseño, no puede garantizar simultáneamente (2) en la capa de captura de pantalla.

Las opciones de mitigación implican compromisos y no establecen una garantía universal de integridad:

• ▹Enumerar de forma nativa los indicadores de exclusión y vigilar el foco de las ventanas puede aportar señales adicionales, dentro de los límites expuestos en el artículo
• ▹Adoptar pruebas del entorno acreditadas por hardware (TPM, Secure Enclave) en lugar de analizar el contenido de la pantalla
• ▹Promover API de integridad de captura en el sistema operativo y evaluar los riesgos restantes, en lugar de suponer que la captura por sí sola demuestra integridad

Cronología de divulgación responsable

Las respuestas de los proveedores confirmaron que conocían el mecanismo del sistema operativo. El problema central reside en una función documentada del sistema, no en un fallo de su código, lo que limita las correcciones que puede realizar un proveedor sin cooperación a nivel del sistema operativo.

Conclusión

Las rutas de captura probadas en Windows y macOS pueden omitir una ventana visible para el usuario, sin privilegios elevados ni rastros observados en la captura. Esto revela una discrepancia entre la protección de contenido y la suposición de que los píxeles capturados representan todo el monitor físico. El estudio establece esa brecha dentro de su alcance de laboratorio; no demuestra que pueda eludirse cualquier producto comercial de supervisión ni cualquier API de captura.

El artículo completo de 13 páginas está enlazado desde la página del proyecto. El código completo de prueba de concepto no se publica; los investigadores verificados y proveedores de supervisión pueden solicitarlo bajo acuerdos de uso responsable. Los ejemplos ilustrativos de API anteriores se conservan como parte del artículo.