كيف أخفيت النوافذ عن التقاط الشاشة، ولماذا تعاني مراقبة الاختبارات من خلل

الثغرة في جملة واحدة

يوفّر Windows وmacOS إعدادات موثّقة لمشاركة النوافذ أو ارتباطها بالالتقاط، يمكنها إبقاء نافذة التطبيق ظاهرة على الشاشة الفعلية مع استبعادها من مسارات الالتقاط التي تحترم هذه الإعدادات. يوضح البحث الفجوة الناتجة في مراقبة الاختبارات المبنية على التقاط الشاشة باستخدام محاكاة مخبرية مضبوطة.

الخلفية: كيف تعمل مراقبة الاختبارات؟

تعمل أنظمة المراقبة عن بُعد المبنية على WebRTC، التي تستخدمها جامعات حول العالم منذ 2020، بالتقاط شاشة الطالب أثناء الاختبار. تطلب إضافة المتصفح أو العميل الأصلي تدفق getDisplayMedia()، وترسله إلى خادم المراقب، ثم ترصد مؤشرات مثل النوافذ المفتوحة والتطبيقات الظاهرة ونشاط الحافظة. ويقوم نموذج الأمن الضمني على الافتراض التالي:

إذا التقطت شاشتك، فسأرى كل ما عليها.

هذا الافتراض غير صحيح على Windows وmacOS.

جانب Windows: SetWindowDisplayAffinity

وثّقت Microsoft هذه الواجهة في Win32 SDK بوصفها آلية لإدارة الحقوق الرقمية. الغرض المقصود هو منع التقاط محتوى الفيديو المحمي، كما في تطبيق Netflix المكتبي. توقيع الدالة بسيط:

BOOL SetWindowDisplayAffinity(HWND hWnd, DWORD dwAffinity);

تمرير الراية WDA_EXCLUDEFROMCAPTURE يطلب من Windows استبعاد النافذة المستهدفة من مسارات الالتقاط المتوافقة، ومنها:

• ▹BitBlt / PrintWindow (GDI القديم)
• ▹IDXGIOutputDuplication (واجهة نسخ سطح المكتب)
• ▹Windows.Graphics.Capture (WinRT الحديث)
• ▹مسار التقاط getDisplayMedia() في WebRTC

تستمر النافذة في الظهور بصورة طبيعية على الشاشة الفعلية. يراها المستخدم، لكن تدفق المراقبة لا يراها.

لا تتطلب صلاحيات مسؤول. تعمل الواجهة على النوافذ التي تملكها العملية المستدعية، ضمن عمليات مساحة المستخدم المعتادة. لا حاجة إلى تعديل النواة أو تجاوز توقيع برامج التشغيل أو رفع الصلاحيات.

إثبات مفهوم (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، موثّقة في مرجع AppKit منذ 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)

ضبط 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) بدل تحليل محتوى الشاشة
• ▹الدعوة إلى واجهات سلامة الالتقاط على مستوى نظام التشغيل وتقييم المخاطر المتبقية بدل افتراض أن الالتقاط وحده يثبت النزاهة

الجدول الزمني للإفصاح المسؤول

أكدت ردود المزوّدين معرفتهم بآلية نظام التشغيل. تتمثل الصعوبة الأساسية في أن المشكلة تقع ضمن ميزة موثّقة في النظام، وليست خطأ في كود المزوّد؛ وهذا يحد مما يمكن لأي مزوّد إصلاحه دون تعاون على مستوى نظام التشغيل.

الخلاصة

يمكن لمسارات الالتقاط المختبرة على Windows وmacOS إغفال نافذة تطبيق مع بقائها ظاهرة للمستخدم، دون صلاحيات مرتفعة أو آثار مرصودة في الالتقاط. يبيّن هذا تعارضًا بين حماية المحتوى وافتراض أن البكسلات الملتقطة تمثل الشاشة الفعلية بالكامل. يثبت البحث هذه الفجوة ضمن نطاقه المخبري المختبر؛ ولا يثبت إمكان تجاوز كل منتج تجاري للمراقبة أو كل واجهة التقاط.

توجد وصلة إلى الورقة الكاملة ذات 13 صفحة في صفحة المشروع. لا يُنشر الكود الكامل لإثبات المفهوم علنًا؛ ويمكن للباحثين الأمنيين المتحقق منهم ومزوّدي المراقبة طلبه بموجب اتفاقيات استخدام مسؤول. حُفظت أمثلة الواجهات التوضيحية أعلاه بوصفها جزءًا من المقال.