چگونه پنجره‌ها را از ضبط صفحه پنهان کردم و چرا نظارت آزمون مشکل دارد

آسیب‌پذیری در یک جمله

Windows و macOS تنظیمات مستند اشتراک پنجره یا تعیین حضور پنجره در ضبط صفحه دارند که می‌توانند پنجره برنامه را روی نمایشگر فیزیکی قابل مشاهده نگه دارند و از مسیرهای ضبطی که این تنظیمات را رعایت می‌کنند حذف کنند. این پژوهش، خلأ حاصل در نظارت آزمون مبتنی بر ضبط صفحه را با شبیه‌سازی‌های کنترل‌شده آزمایشگاهی نشان می‌دهد.

پیش‌زمینه: نظارت آزمون چگونه کار می‌کند؟

سامانه‌های نظارت از راه دور مبتنی بر WebRTC، از همان نوعی که دانشگاه‌های سراسر جهان از 2020 به کار گرفته‌اند، هنگام آزمون صفحه دانشجو را ضبط می‌کنند. افزونه مرورگر یا کلاینت بومی یک جریان getDisplayMedia() درخواست می‌کند، آن را به سرور ناظر می‌فرستد و مواردی مانند پنجره‌های باز، برنامه‌های قابل مشاهده و فعالیت کلیپ‌بورد را علامت می‌زند. فرض ضمنی مدل امنیتی چنین است:

اگر صفحه شما را ضبط کنم، همه چیز روی آن را می‌بینم.

این فرض در Windows و macOS درست نیست.

بخش Windows: SetWindowDisplayAffinity

Microsoft این API را در Win32 SDK به‌عنوان سازوکار مدیریت حقوق دیجیتال مستند کرده است. کاربرد در نظر گرفته‌شده آن، جلوگیری از ضبط ویدئوهای محافظت‌شده است؛ مثلاً در برنامه دسکتاپ Netflix. امضای تابع ساده است:

BOOL SetWindowDisplayAffinity(HWND hWnd, DWORD dwAffinity);

دادن پرچم WDA_EXCLUDEFROMCAPTURE به Windows می‌گوید پنجره هدف را از مسیرهای سازگار ضبط صفحه کنار بگذارد، از جمله:

• ▹BitBlt / PrintWindow (GDI قدیمی)
• ▹IDXGIOutputDuplication (API تکثیر دسکتاپ)
• ▹Windows.Graphics.Capture (WinRT جدید)
• ▹مسیر ضبط getDisplayMedia() در WebRTC

پنجره همچنان به‌طور عادی روی نمایشگر فیزیکی رسم می‌شود. کاربر آن را می‌بیند؛ جریان نظارت آزمون آن را نمی‌بیند.

مجوز مدیر لازم نیست. API روی پنجره‌های متعلق به فرایند فراخوان کار می‌کند و در محدوده عملکرد معمول فضای کاربر قرار دارد. نیازی به تغییر هسته، دورزدن امضای درایور یا افزایش سطح دسترسی نیست.

اثبات مفهوم (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;
}

بخش macOS: NSWindow.SharingType.none

معادل Apple در AppKit قرار دارد. هر نمونه NSWindow ویژگی sharingType دارد که از macOS 10.6 (2009) در مرجع AppKit مستند شده است:

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)

تنظیم sharingType روی .none درخواست می‌کند پنجره از مسیرهای ضبطی که پرچم اشتراک را رعایت می‌کنند حذف شود. رابط‌های مرتبط ضبط عبارت‌اند از:

• ▹CGWindowListCreateImage (ضبط قدیمی Core Graphics)
• ▹ScreenCaptureKit (SCStreamConfiguration، چارچوب جدید ضبط Apple)
• ▹AVCaptureScreenInput (ضبط صفحه در AV Foundation)
• ▹getDisplayMedia() در WebRTC روی macOS

ضبط‌های بومیِ آزموده‌شده در macOS 26.3.1 همچنان تحت تأثیر بودند. با وجود تغییرات مستند Apple در ScreenCaptureKit در macOS 15، پژوهش با ابزارهای ضبط بومی، حذف پنجره با .none را مشاهده کرد. ضبط مبتنی بر مرورگر در macOS 26 آزموده نشد و رفتار همه کلاینت‌های ScreenCaptureKit نیز اثبات نشد.

نتایج آزمون

نتایج به نظارت آزمون شبیه‌سازی‌شده در آزمایشگاه کنترل‌شده مربوط‌اند، نه محصولات تجاری. ارزیابی macOS 26 از CGWindowListCreateImage و ابزار screencapture استفاده کرد، نه فراخوانی getDisplayMedia() در مرورگر. Linux با X11 و Wayland آزموده نشد. مطالعه رفتاری شامل n = 8 عضو تیم پژوهش با رضایت آگاهانه بود؛ p = 0.41 ناممکن‌بودن تشخیص رفتاری را ثابت نمی‌کند. یافته‌ها وضعیت نسخه‌های آزموده‌شده در مارس 2026 را بازتاب می‌دهند؛ نسخه‌های بعدی ممکن است رفتار متفاوتی داشته باشند.

چرا رفع این مشکل از نظر ساختاری دشوار است؟

آسیب‌پذیری از تعارض طراحی میان دو قابلیت مشروع سیستم‌عامل ناشی می‌شود:

1. DRM / حفاظت محتوا: شرکت‌های رسانه‌ای باید از ضبط غیرمجاز محتوای محافظت‌شده جلوگیری کنند. WDA_EXCLUDEFROMCAPTURE و NSWindow.SharingType.none برای همین نیاز وجود دارند.

2. سلامت آزمون: سامانه‌های نظارت فرض می‌کنند ضبط صفحه، نمای کاملی از دسکتاپ کاربر می‌دهد.

این دو نیاز از پایه ناسازگارند. سیستم‌عاملی که از (1) پشتیبانی می‌کند، همان‌طور که Windows و macOS در طراحی خود می‌کنند، نمی‌تواند هم‌زمان (2) را در لایه ضبط صفحه تضمین کند.

راهکارهای کاهش خطر موازنه‌هایی دارند و تضمین همگانی سلامت آزمون ایجاد نمی‌کنند:

• ▹بررسی بومی پرچم‌های حذف پنجره از ضبط و پایش تمرکز پنجره می‌توانند نشانه‌های بیشتری بدهند، با محدودیت‌هایی که مقاله توضیح می‌دهد
• ▹استفاده از اثبات محیط با گواهی سخت‌افزاری (TPM، Secure Enclave) به‌جای تحلیل محتوای صفحه
• ▹پیگیری APIهای سلامت ضبط در سطح سیستم‌عامل و ارزیابی خطر باقی‌مانده، به‌جای فرض اینکه ضبط به‌تنهایی سلامت آزمون را ثابت می‌کند

خط زمانی افشای مسئولانه

پاسخ ارائه‌دهندگان نشان داد سازوکار سطح سیستم‌عامل را می‌شناسند. مشکل اصلی این است که آسیب‌پذیری در یک قابلیت مستند سیستم‌عامل قرار دارد، نه در خطای کد ارائه‌دهنده؛ بنابراین اصلاح مستقل بدون همکاری سیستم‌عامل محدود است.

نتیجه

مسیرهای ضبط آزموده‌شده در Windows و macOS می‌توانند پنجره برنامه را حذف کنند، در حالی که کاربر آن را می‌بیند؛ بدون دسترسی بالاتر و بدون اثر مشاهده‌شده در ضبط. این وضعیت، ناسازگاری میان حفاظت محتوا و فرضِ بازنمایی کامل نمایشگر فیزیکی با پیکسل‌های ضبط‌شده را نشان می‌دهد. مطالعه این خلأ را در محدوده آزمایشگاهی خود اثبات می‌کند؛ ثابت نمی‌کند که هر محصول تجاری نظارت آزمون یا هر API ضبط قابل دورزدن است.

مقاله کامل 13 صفحه‌ای از صفحه پروژه در دسترس است. کد کامل اثبات مفهوم عمومی نشده است؛ پژوهشگران امنیتی تأییدشده و ارائه‌دهندگان نظارت آزمون می‌توانند آن را با توافق استفاده مسئولانه درخواست کنند. نمونه‌های توضیحی API در بالا به‌عنوان بخشی از مقاله حفظ شده‌اند.