HTCinside
عند نشر منتجات البرامج الخاصة بنا ، نستخدم جميعًا للكتابة في اتفاقيات ترخيص المستخدم النهائي 'لا يجوز لك عكس هندسة البرنامج أو إلغاء تجميعه أو تفكيكه'. ولكن في العديد من المواقف ، لا تكون الكلمات هي أفضل حماية وتحتاج حقًا إلى تقديم بعض الأدوات التقنية لمنع انعكاس البرامج وحماية معرفتك من الكشف عنها.
هناك العديد من الأساليب التقنية لمنع الهندسة العكسية للبرامج: مكافحة التصحيح ، ومكافحة التفريغ ، وغيرها. في هذا المنشور ، سوف نركز على بعض أساليب مكافحة التصحيح ، حيث إنها في صميم الحماية المضادة للهندسة العكسية. يُعد إرفاق مصحح أخطاء بالعملية التي تم البحث عنها لتنفيذها خطوة بخطوة مرحلة مهمة جدًا في أي عمل عكسي - لذا دعنا نلقي نظرة على الأدوات التي يمكننا استخدامها لجعل حياة المنعكسين أكثر صعوبة.
هناك شيئان أود أن أذكرهما في البداية. الأول هو أنه لا توجد حماية شاملة أو 100٪ ضد الرصاص من الهندسة العكسية للبرامج. هناك دائمًا طريقة للانعكاس للدخول ، والاستراتيجية الوحيدة التي لدينا هي جعل عمله صعبًا ومستهلكًا للجهد قدر الإمكان.
بعد ذلك ، هناك عدد غير قليل من تقنيات الهندسة العكسية وخاصة طرق مكافحة التصحيح ، بما في ذلك الحماية المستندة إلى الوقت أو حتى التقنيات المضمنة في التعليمات البرمجية مثل النانوميت. في هذا المنشور ، سننظر فقط في العديد من الأساليب القياسية المحددة للأنظمة المستندة إلى Windows ، وأكثرها شيوعًا.
الأساليب المذكورة أدناه موصوفة بشكل عام.
محتويات
توفر لنا أنظمة Windows بعض الأدوات الجاهزة لبناء حماية بسيطة ضد تصحيح الأخطاء. تعتمد إحدى أبسط تقنيات مكافحة تصحيح الأخطاء على استدعاء وظيفة IsDebuggerPresent. ترجع هذه الدالة TRUE إذا كان مصحح أخطاء وضع المستخدم يقوم حاليًا بتصحيح العملية.
تشير هذه الوظيفة إلى PEB (كتلة بيئة العملية ، وهيكل نظام مغلق) وعلى وجه الخصوص إلى حقل BeingDebugged الخاص بها. تستخدم الانعكاسات عند تجاوز تقنية الحماية هذه الحقيقة: على سبيل المثال بتطبيق حقن DLL ، قاموا بإعداد قيمة BeingDebugged على 0 مباشرة قبل إجراء هذا الفحص في الكود المحمي.
بضع كلمات حول مكان إجراء هذا الفحص. الوظيفة الرئيسية ليست هي الخيار الأفضل: عادةً ما يتحقق المنعكسون أولاً في القائمة المفككة. من الأفضل إجراء فحص مضاد للتصحيح في TLS Callback ، كما يتم استدعاؤه قبل نقطة استدعاء الإدخال للوحدة التنفيذية الرئيسية.
خيار فحص وظيفي آخر هو CheckRemoteDebuggerPresent. على عكس الوظيفة الموضحة أعلاه ، فإنها تتحقق مما إذا كانت هناك عملية موازية أخرى تقوم حاليًا بتصحيح عملية ما. يعتمد على دالة NtQueryInformationProcess وعلى وجه الخصوص قيمة ProcessDebugPort.
بينما تم إنشاء مجموعة الطرق السابقة على التحقق من وجود مصحح الأخطاء ، ستوفر هذه الطريقة حماية نشطة منه.
بدءًا من Windows 2000 ، تتلقى الدالة NtSetInformationThread العلامة الجديدة المسماة ThreadHideFromDebugger. هذه تقنية فعالة للغاية لمكافحة تصحيح الأخطاء المتوفرة في نظام التشغيل Windows. يتوقف موضوع مع مجموعة العلامات هذه لإرسال إشعارات بأحداث التصحيح ، بما في ذلك نقاط التوقف وغيرها ، وبالتالي يخفي نفسه من أي مصحح أخطاء. سيؤدي إعداد ThreadHideFromDebugger للخيط الرئيسي إلى تعقيد عملية إرفاق مصحح الأخطاء إلى سلسلة الرسائل بشكل كبير.
تم تقديم الاستمرارية المنطقية في نظام التشغيل Windows Vista باستخدام وظيفة NtCreateThreadEx. يحتوي على المعلمة CreateFlags ، التي تقوم بإعداد علامة THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER من بين أمور أخرى. سيتم إخفاء العملية باستخدام مجموعة العلامات هذه من مصحح الأخطاء.
يمكن الكشف عن تشغيل تصحيح الأخطاء من خلال القيم المتغيرة لأعلام مختلفة في هياكل النظام والعمليات المختلفة.
يتضمن Windows NT متغيرًا عامًا يسمى NtGlobalFlag مع مجموعة من العلامات ، تُستخدم لتتبع النظام وتصحيح الأخطاء. يتضمن هيكل PEB المذكور أعلاه حقل NtGlobalFlag الخاص به. أثناء التصحيح ، يتم تغيير قيمة هذا الحقل مع مجموعة إشارات محددة متعددة. يمكن أن ينتج عن التحقق من هذه العلامات محفزات للحماية من تصحيح الأخطاء.
يمكن للملف التنفيذي إعادة تعيين علامات NtGlobalFlag لهيكل PEB عن طريق بنية محددة تسمى IMAGE_LOAD_CONFIG_DIRECTORY ، والتي تحتوي على معلمات تكوين محددة لمحمل النظام. يحتوي على حقل GlobalFlagsClear ، الذي يعيد تعيين أعلام NtGlobalFlag الخاصة بـ PEB. بشكل افتراضي ، لا تتم إضافة هذه البنية إلى ملف تنفيذي ، ولكن يمكن إضافتها لاحقًا. حقيقة أن الملف القابل للتنفيذ لا يحتوي على هذه البنية أو قيمة GlobalFlagsClear تساوي 0 ، بينما الحقل المقابل المخزن على القرص أو في ذاكرة العملية قيد التشغيل ليس صفراً ، يشير إلى وجود مصحح أخطاء مخفي. يمكن تنفيذ هذا الفحص في الكود القابل للتنفيذ.
مجموعة أخرى من الأعلام هي مجموعة العملية. يوجد حقلين في بنية _HEAP المقابلة: Flags و ForceFlags. كلاهما يغير قيمهما عندما يتم تصحيح العملية المقابلة ، وبالتالي يمكن أن يكون أساس فحص وحماية مكافحة تصحيح الأخطاء.
فحص العلم الآخر ، والذي يمكن استخدامه لاكتشاف مصحح الأخطاء ، هو فحص Trap Flag (TF). إنه في سجل EFLAGS. عندما يساوي TF 1 ، تولد وحدة المعالجة المركزية INT 01h (استثناء 'خطوة واحدة') بعد كل تنفيذ تعليمي يدعم عملية التصحيح.
تعتبر نقاط التوقف جزءًا أساسيًا من أي عملية تصحيح أخطاء ، وبالتالي اكتشافها ، يمكننا اكتشاف وتحييد مصحح الأخطاء. تعد أساليب مكافحة التصحيح المستندة إلى اكتشاف نقطة التوقف واحدة من أقوى الأساليب التي يصعب تجاوزها.
هناك نوعان من نقاط التوقف: البرامج والأجهزة.
يتم تعيين نقاط توقف البرامج بواسطة مصحح الأخطاء عن طريق حقن تعليمات int 3h في الكود. وبالتالي ، فإن طرق اكتشاف المصحح تعتمد على حساب والتحكم في المجموع الاختباري للوظيفة المقابلة.
لا توجد طريقة عالمية لمحاربة هذه الحماية - سيتعين على المتسلل العثور على جزء من الكود الذي يحسب المجموع (المجاميع) الاختباري واستبدال القيم التي تم إرجاعها لجميع المتغيرات المقابلة.
يتم تعيين نقاط توقف الأجهزة باستخدام سجلات تصحيح أخطاء محددة: DR0-DR7. باستخدامهم ، يمكن للمطورين مقاطعة تنفيذ البرنامج ونقل التحكم إلى مصحح الأخطاء. يمكن بناء الحماية المضادة للتصحيح على التحقق من قيم هذه السجلات أو أن تكون أكثر استباقية وإعادة تعيين قيمها قسريًا لإيقاف التصحيح باستخدام وظيفة SetThreadContext.
معالجة الاستثناءات الهيكلية أو SEH هي آلية تسمح للتطبيق بتلقي إعلامات حول المواقف الاستثنائية والتعامل معها بدلاً من نظام التشغيل. تسمى مؤشرات معالجات SEH بإطارات SEH وتوضع في المكدس. عند إنشاء استثناء ، تتم معالجته بواسطة إطار SEH الأول في المكدس. إذا كان لا يعرف ماذا يفعل به ، يتم تمريره إلى التالي في المكدس وما إلى ذلك حتى معالج النظام.
عندما يتم تصحيح التطبيق ، يجب أن يعترض مصحح الأخطاء عنصر التحكم بعد إنشاء int 3h ، أو سيأخذها معالج SHE. يمكن استخدام هذا لتنظيم الحماية ضد التصحيح: يمكننا إنشاء معالج SEH الخاص بنا ووضعه في أعلى المكدس ثم فرض الجيل 3 ساعات int. إذا حصل معالجنا على التحكم ، فلن يتم تصحيح العملية - وإلا يمكننا فرض إجراءات مكافحة التصحيح عندما اكتشفنا مصحح أخطاء.
هذه ليست سوى عدد قليل من تقنيات مكافحة التصحيح من مجموعة كبيرة ومتنوعة منها.
من الممارسات الجيدة الجمع بين تقنيات مختلفة لمكافحة الانعكاس مما يجعل تجاوز الحماية أكثر صعوبة. يمكن أن تؤدي الفحوصات الإضافية إلى إبطاء تنفيذ التطبيق ، ولهذا السبب يتم تطبيق أقوى تقنيات الحماية عادةً على الوحدات الأساسية التي تحتوي على التقنيات والمعرفة الحاصلة على براءة اختراع. أخيرًا ، إنها مفاضلة بين مستوى أمان الكود وأداء التطبيق.
أود أن أذكر أن الهندسة العكسية للبرامج ليست دائمًا غير قانونية ويمكن أحيانًا تطبيقها أثناء عملية البحث لمهام مثل تحسين التوافق ، والتصحيح ، واستخدام واجهة النظام غير الموثقة ، وما إلى ذلك. خدمات الهندسة العكسية القانونية التي يقدمها المحترفون يتعاملون أيضًا مع الحماية ضد تصحيح الأخطاء ولكن من جانب آخر - تجاوزها.