الميزات الجديدة لـ Win 7: Console Host (ConHost.exe)

اليوم، سأقدم لكم الميزة الجديدة لنظام التشغيل Windows 7 / Windows Server 2008 R2 - مضيف وحدة التحكم (ConHost.exe).

في الواقع، سواء كمستخدمين عاديين أو مسؤولي مؤسسة، سوف نستخدم تطبيقات وحدة التحكم بشكل أو بآخر في تطبيقات Windows اليومية وعمليات التشغيل والصيانة. لا يحتوي تطبيق وحدة التحكم على واجهة مستخدم، نحتاج إلى إجراء عمليات الإدخال والإخراج عليه من خلال موجه الأوامر (CMD، هذا ليس DOS، كثير من الناس مرتبكون).

لذلك دعونا نفكر في الأمر، ما هي تطبيقات وحدة التحكم التي يأتي معها Windows؟

في الواقع، تتضمن أكثرها شيوعًا cmd.exe، وnslookup.exe، وtelnet.exe.

في الإصدارات السابقة من Windows، تم تنسيق جميع التطبيقات التي تمثل أنشطة غير واجهة المستخدم الرسومية (أي تطبيقات وحدة التحكم) من خلال عملية النظام Csrss.exe عندما أرادوا تشغيلها على سطح المكتب. عندما يحتاج تطبيق وحدة التحكم إلى تلقي أحرف، فإنه يستدعي "واجهات برمجة تطبيقات وحدة التحكم" الصغيرة في Kernel32.dll للسماح لـ Kernel32 بإنشاء LPC لاستدعاء CSRSS. في هذا الوقت، سيقوم CSRSS بفحص قائمة انتظار الإدخال الخاصة بنافذة وحدة التحكم والتحقق منها، وإرجاع نتائج وضع الأحرف إلى تطبيق وحدة التحكم من خلال Kernel32 للارتباط. تظهر آلية معالجة الرسائل لتطبيقات وحدة التحكم في إصدارات Windows المبكرة في الشكل أدناه:

لقد خلقت آلية المعالجة هذه مشكلة: حتى إذا تم تنفيذ تطبيق وحدة التحكم في سياق مستخدم عادي، فإن Csrss.exe يعمل دائمًا بموجب أذونات حساب النظام المحلي. لذلك، في بعض الحالات، قد تحصل البرامج الضارة التي طورها "الأشرار" على المزيد من الامتيازات من خلال Csrss.exe الذي يتم تنفيذه باستخدام أذونات حساب النظام المحلي. يُطلق على وضع الهجوم هذا اسم Shatter Attack.

في عصر Win7 وWindows Server 2008 R2، يتم وضع جميع تطبيقات وحدة التحكم في عملية سياق جديدة ConHost.exe للتنفيذ، ويتم تشغيل ConHost (مضيف وحدة التحكم) وبرامج وحدة التحكم في نفس سياق مستوى الأمان فيما بينها، بدلاً من إصدارها طلب رسالة LPC إلى CSRSS للمعالجة، فإنه يطلب بدلاً من ذلك ConHost. لذلك، لن تنجح أي محاولة تطبيق لاستغلال طلب رسالة للتسبب في الرفع التلقائي للامتياز. الشكل التالي هو رسم تخطيطي للآلية الجديدة المستخدمة في نظامي التشغيل Windows 7 وWindows Server 2008 R2:

يستبدل ConHost التغيير الدائم في طريقة معالجة الإدخال/الإخراج بواسطة تطبيقات وحدة التحكم. لا يمكن للمستخدمين إجبار Windows على العودة إلى سلوك وحدة التحكم "الوضع القديم" عبر السجل أو نهج المجموعة. ولذلك، يحتاج المستخدمون إلى اختبار التطبيقات بدقة قبل الترقية إلى Windows 7 أو Windows Server 2008 R2. من فضلك لا تنس أنه على الرغم من أن معظم وظائف بعض التطبيقات يتم تنفيذها من خلال واجهة المستخدم الرسومية، إلا أن البيانات لا تزال تتم معالجتها على دفعات من خلال وحدة التحكم أو الواجهات الوظيفية الأخرى في الخلفية. لذلك، من الضروري جدًا إجراء اختبار وظيفي شامل للتطبيق قبل الترحيل أو التسوية.

عندما لا يمكن استخدام أحد التطبيقات بشكل طبيعي في نظام التشغيل Windows 7، يجب علينا أولاً اختباره وتنفيذه مرة أخرى باستخدام حقوق المسؤول لمعرفة ما إذا كانت المشكلة تحدث، في الواقع، يمكننا بعد ذلك استخدام مراقبة العمليات لمراقبة ما إذا كانت حقوق وصول التطبيق إلى الملفات أو السجل طبيعية. إذا ظل التطبيق غير قادر على التشغيل بشكل طبيعي بعد استكشاف المشكلات المذكورة أعلاه وإصلاحها، فيجب عليك التفكير في الاتصال بمورد البرامج المستقل (ISV) أو المطور الخاص به.

في حالة تعطل أحد التطبيقات، يكون ملف تفريغ التعطل المقابل مفيدًا للغاية للمطورين ومقدمي البرامج المستقلين للعثور على جوهر المشكلة. إذا توقف التطبيق عن الاستجابة، فيمكنك محاولة استخدام ADPlus للاستيلاء عليه وتفريغ عملية ConHost.exe المرتبطة به. يمكن لتطبيقات وحدة التحكم مشاركة العديد من العمليات الفرعية لوحدة تحكم Windows، على سبيل المثال، عندما يقوم المستخدم بتشغيل Telnet من نافذة CMD، سيصبح Telnet.exe عملية فرعية لـ Cmd.exe. في هذه الحالة، يقوم مضيف ConHost.exe بمعالجة مثيلات الرسائل لكل من العملية الأصلية والعملية الفرعية. باستخدام Process Explorer يمكننا التأكد من العمليات التي يتعامل معها ConHost.exe:

يمكنك أيضًا استخدام وظيفة "تحليل سلسلة الانتظار" في Windows 7 Resource Monitor لعرض عملية التطبيق الخاصة بعملية ConHost.exe:

وأخيرًا، لا تنس اختبار التطبيق بالكامل قبل الترحيل!