ثلاث طرق للدخول، ومسار واحد للخروج عبر `ObfDereferenceObject`.

هذا لا يعني أن الكود خاطئ. إنه يعني أن **الخاصية الثابتة (invariant) موزّعة** — لا توجد دالة واحدة تملك *"هذا الكائن حي الآن،"* لذا تعتمد الصحة على اتفاق كل مستدعي على أي مرجع يحملونه وإلى متى يظل صالحًا.

الثوابت الموزّعة هي المكان الذي تعيش فيه حالات السباق، لأن السباق ليس أبدًا خللًا منطقيًا يمكنك رؤيته في دالة واحدة. بل هو خلل في افتراض مشترك عبر دالتين.

لذلك السؤال الذي بدأت أطرحه على كل دالة تلامس `PWND` لم يكن *"هل هذا الكود صحيح؟"* بل:

> **إذا نُفِّذ جسم هذه الدالة نفسه على خيطين بفارق بضع تعليمات، فأيُّهما يكون على خطأ؟**



## 3. السبب الجذري

الخلل هو **فجوة وقت-الفحص / وقت-الاستخدام (time-of-check / time-of-use) التي تقع بين تحرير المرجع وتفكيك الكائن** في مسار تدمير النافذة، دون مزامنة كافية مع مستهلك متزامن يتحقق من صحة المقبض.

عند تجريده إلى شكله الأساسي:```c
/* Thread A — teardown */
NtUserDestroyWindow(HWND hwnd)
{
    PWND pWnd = ValidateHwnd(hwnd);
    if (pWnd) {
        ObfDereferenceObject(pWnd);   /* reference released */

        /* <-- race window: object may become reclaimable here */

        FreeWindowObject(pWnd);       /* teardown proceeds on a pointer
                                         no longer guaranteed live      */
    }
}

if (pWnd->fnid == FNID_BUTTON)    /* use-after-free */
    ...

يجب أن يتحقق أمران حتى يكون لهذا أهمية، وقد تحقق كلاهما:

**(أ) النافذة حقيقية.** `ValidateHwnd` هي البوابة التي يُفترض أن تجعل الوصول المعتمد على المقابض آمنًا. إذا كان التحقق يمكن أن ينجح ضد كائن بدأ تفكيكه بالفعل، فهذه البوابة ليست بوابة — بل اقتراح.

**(ب) الذاكرة المحررة قابلة للتأثير من قِبل المهاجم.** الحقول التي تُقرأ مباشرة بعد التحقق تتضمن `fnid`، الذي يوجّه توزيع الرسائل. قرار التوزيع المُتخذ من ذاكرة مستعادة هو الفرق بين *"انهيار غير موثوق"* و*"انتهاك لحدود الأمان"*. هذا التمييز هو السبب الكامل لكون هذا CWE-362 مع تأثير تصعيد الصلاحيات (EoP) وليس خلل استقرار.

> إن **الفساد** الملاحظ هو استخدام بعد التحرير (use-after-free)؛ أما **السبب** فهو CWE-362، وهو تنفيذ متزامن يستخدم موردًا مشتركًا دون مزامنة صحيحة. هاتان عبارتان مختلفتان وMSRC تهتم بالثانية. **أبلغ عن السبب، وليس العرض فقط.**

### لماذا سباقات win32k أصعب هيكليًا مما تبدو

إذا كنت قد سبقت خللًا في أنظمة فرعية أخرى، فسوف يُحبِطك win32k، لأن البنية تقاومك بثلاث طرق محددة.

**النوافذ لها تقارب مع الخيوط (thread affinity).** تنتمي النافذة إلى الخيط الذي أنشأها. جزء كبير من النظام الفرعي مبني على افتراض أن الخيط المالك هو من يلمس الكائن، مما يعني أن النهج الساذج "أدر خيطين يستدعيان نفس الواجهة البرمجية" غالبًا لا يُحدث أي تداخل — أنت لا تخلق سباقًا، بل تخلق طابور انتظار. جعل مسارين يصطدمان فعليًا على نفس الكائن يتطلب فهم العمليات التي تنفذ فعليًا على خيط المتصل مقابل تلك التي تُمرَّر إلى خيط المالك.

**توزيع الرسائل يفرض تسلسلًا جزئيًا عليك.** الإرساليات (Sends) والمنشورات (Posts) تتصرف بشكل مختلف، والتوزيع عبر الخيوط يختلف عن التوزيع داخل نفس الخيط مجددًا. بعض ما يبدو فرصة للتوازي يُحوَّل بصمت إلى عملية مرتبة قبل أن يصل حتى إلى الكود الذي يهمك. إذا كنت لا تعرف أي فئة يقع فيها محفزك، فستستنتج أن السباق الحقيقي غير قابل للوصول — وهي نتيجة سلبية كاذبة تبدو مطابقة لـ"لا خلل هنا".

**القسم الحرج مختبئ في المتصل.** يعمل جزء كبير من النظام الفرعي تحت قفل خشن (coarse lock) يُكتسب أعلى بكثير من الدالة التي تنظر إليها. هذا هو أكبر مصدر وحيد لإهدار الوقت في تدقيق win32k: دالة لا تحتوي على أي مزامنة مرئية لكنها آمنة تمامًا لأن كل مسار إليها مُسلسَل بالفعل. **تغطية القفل خاصية عابرة للإجراءات.** يجب أن تصعد في مخطط الاستدعاءات، لا أن تقرأ الدالة فحسب.

تلك النقطة الثالثة هي السبب في أن *"لا يوجد قفل في هذه الدالة"* لا تساوي شيئًا تقريبًا كإشارة، والسبب في أن معظم العمل في هذا البحث أُنفق على قابلية الوصول بدلاً من العيب نفسه.

## 4. لماذا تقييم الأثر هو ما هو عليه

قيّمت MSRC هذا بأنه **مهم، تصعيد صلاحيات، CVSS 8.8، ناقل هجوم محلي، مصادق عليه.** هناك خاصيتان تدفعان إلى ذلك:

**قابلية الوصول من مستوى نزاهة منخفض.** سطح استدعاءات رسائل Win32k قابل للوصول من سياقات أدنى بكثير من SYSTEM. هذا ما يجعله ذا صلة بسلاسل الهروب من العزل (sandbox-escape) — فالعملية التي أنجزت تنفيذ كود داخل صندوقها الرملي ما تزال تستطيع الوصول إلى هذا السطح. خطورة خلل النواة هي غالبًا دالة لـ*من يمكنه لمسه*، وليس مدى ذكاء الفساد.

**فساد يؤثر على التوزيع.** إفساد حقل يعمل عليه `switch` أسوأ نوعيًا من إفساد حقل يُسجَّل فقط. الأول يحول خلل ذاكرة إلى مسألة تدفق تحكم.

أريد أن أكون دقيقًا هنا بشأن شيء ما، لأنني رأيت منشورات أول CVE تبالغ في هذا: **أنا أثبتُ السباق والاستخدام بعد التحرير. لم أنتج استغلالًا مسلحًا على مستوى SYSTEM.** إطار الهروب من العزل يصف *فئة السلسلة* التي ينتمي إليها هذا النوع من الخلل ولماذا هذا السطح قيّم — إنها حجة حول قابلية الوصول، وليست ادعاءً بأنني بنيت واحدة. المبالغة في الأثر هي أسرع طريقة لحرق المصداقية لدى البائع، وتقييم MSRC هو الرقم المهم، وليس تقييمي.

## 5. التفنيد جاء أولاً — معظم المرشحين سقطوا

الجزء الذي لا يكتب عنه أحد: لم يكن هذا المرشح الأول. بل كان هو الذي نجا.

قاعدتي العملية هي أن **المرشح مذنب حتى تثبت إدانته.** كل نمط واعد يحصل على سبب محدد ومكتوب يوضح لماذا *لا* ينبغي أن يكون قابلاً للاستغلال، وأذهب لأثبت ذلك السبب قبل أن أحاول تشغيله. المرشحون الذين أغلقته قبل هذا تضمنوا:

- مسارات بدت غير متزامنة لكنها كانت مُسلسَلة بقفل يُكتسب إطارًا واحدًا للأعلى،
- مسارات كان فيها الكائن "المحرَّر" مخزَّنًا مؤقتًا فعليًا بدلاً من تحريره،
- مسارات كانت حقًا بها سباق لكنها غير قابلة للوصول من أي متصل يمكن لمستخدم منخفض الصلاحيات تشغيله.

كل واحد من تلك كان نتيجة *لم أرسلها* إلى MSRC. هذه هي النقطة. إنتاجية الباحث ليست عدد المرشحين الذين يولدهم — بل مدى سرعة قتل المرشحين الخاطئين حتى لا يظل ممسكًا بهم في الثانية بعد منتصف الليل.

**الأسئلة الثلاثة التي قتلت معظم المرشحين:**

1. **هل أي شيء فوقي يحمل قفلًا؟** عابر للإجراءات، وليس محليًا. غياب القفل في دالة لا يعني شيئًا.
2. **هل يمكن لمتصل غير مميز الوصول فعليًا إلى الجانبين؟** السباق بين مسارين يتطلبان مستويين مختلفين من الصلاحيات ليس سباقًا، بل تجربة فكرية.
3. **هل الذاكرة المحررة قابلة للاستعادة في نافذة يمكنني التأثير عليها؟** إذا اكتمل الإنهاء (teardown) بشكل ذري لأغراض عملية، فلا يوجد خلل يستحق الإبلاغ.

## 6. التحقق: التحليل الساكن يعطي فرضيات، والمصحح يعطي الحقيقة

التحليل الساكن لـ `win32kfull.sys` أعطاني الفرضية. لم يكن بإمكانه أبدًا أن يعطيني الخلل. **حالات السباق غير مرئية في مفكك الترميز (decompiler)** لأن العيب ليس في التعليمات — بل في التشابك (interleaving).

### المختبر

| الدور | الإعداد |
| --- | --- |
| المضيف / المصحح | Windows 11, WinDbg |
| الهدف | Windows Server 2022, Build 20348.2159 |
| التحليل | Kali Linux + Windows 11 VM |
| ناقل التصحيح | VMware serial COM، تصحيح أخطاء النواة من المضيف إلى الهدف |
| التحليل الساكن | Ghidra عبر GhidraMCP |
| مساعدة الفرز | تمريرة بمساعدة الذكاء الاصطناعي على المخرجات المفككة |

ثلاث طبقات من الأدوات قامت بالعمل الفعلي.

### التجمع الخاص ومدقق برنامج التشغيل

إنها الخطوة الأعلى تأثيرًا في أي تحقيق في استخدام الذاكرة بعد تحريرها (UAF) في النواة. افتراضيًا، تُعاد استخدام ذاكرة التجمع المحررة فورًا تقريبًا بواسطة التخصيص التالي بحجم مشابه — مما يعني أن الاستخدام بعد التحرير عادةً *لا يُحدث خطأ*. فهو يقرأ بيانات صحيحة لشخص آخر، ويواصل التنفيذ، وينفجر في مكان غير ذي صلة بعد دقائق. بعدها تقضي ثلاثة أيام في تدقيق دالة بريئة.

التجمع الخاص يغير ذلك. يحصل كل تخصيص على صفحته الخاصة مع صفحة حراسة مجاورة، وتُعلَّم الصفحات المحررة بأنها غير قابلة للوصول بدلاً من إعادة تدويرها. النتيجة هي أن إلغاء الإشارة المخالف يُحدث خطأ **عند التعليمات التي تنفذه**، لا في مرحلة لاحقة:```
!verifier 0x1 win32kfull.sys        ; special pool on the target driver
!verifier 0x8 win32kfull.sys        ; pool tracking

الكتلة التي تكون *مخصّصة* بوسمٍ معقول ومحتوى عشوائي تشير إلى **تلف**. الكتلة التي تكون *محرّرة*، أو موجودة في صفحة عديمة الوصول من التجمع الخاص، تشير إلى **خلل في دورة الحياة** — أي شيء أبقى مؤشرًا يتجاوز موت الكائن. هذا هو الفرق بين *"المُهاجم كتب هنا"* و *"كان ينبغي ألا يكون هذا الكائن قابلًا للوصول"*، وهو الفرق بين تقرير تلف الكومة وتقرير CWE-362.

تحقق من نوع الكائن قبل الالتزام بأيٍّ منهما. فـ `PWND` له شكل يمكن التعرف عليه؛ إذا كانت الذاكرة التي تعطلت عليها ما تزال تحمل بقاياه، فأنت شبه متأكد من أنك أمام مشكلة عمر نافذة وليس استبدالًا عشوائيًا.

### تصحيح أخطاء النواة المباشر على التداخل

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

الطريق عبر ذلك هو التوقف عن محاولة الإمساك بالسباق عبر نقطة إيقاف، وبدلًا من ذلك:

- **توسيع النافذة بشكل مصطنع** — أي شيء يطيل الفاصل بين تحرير المرجع والتفكيك يجعل التصادم قابلًا للتحقيق بمعدلات جدولة طبيعية،
- **زيادة محاولات التصادم بدل الدقة** — تشغيل المسارين باستمرار وترك الاحتمال يقوم بالعمل،
- **استخدام نقاط إيقاف شرطية وقابلة للتفعيل لمرة واحدة** تُسلَّح فقط عندما توجد الحالة المثيرة للاهتمام، بدل كسر التنفيذ عند كل دخول،
- **تأكيد التداخل بعد حدوث العطل**، من حالة الخيوط والمكدسات، بدل محاولة ملاحظته مباشرة.

العطل نفسه، بمجرد حصولك عليه، غير مثير — إنه إلغاء مرجعية `PWND` في مسار توزيع الرسائل حيث يكون الكائن قد اجتاز التفكيك بالفعل على خيط آخر، مع `!pool` الذي يؤكد أن الكتلة حُرِّرت بدل أن تُستبدل:```
kd> !analyze -v

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Access violation
FAULTING_MODULE: win32kfull