UnhookMe

UnhookMe - محلل واردات ديناميكي مع إزالة الخطاف

في عصر برامج مكافحة الفيروسات وأدوات الكشف والاستجابة المتطفلة التي تقوم بإدخال تصحيحات سريعة (hot-patches) على العمليات الجارية لتحسين متطلبات المراقبة لديها، يجب أن يمتلك الخصوم المعاصرون أداة قوية للتسلل عبر هذه الحراس. إن التطبيق المقترح لمحلل الواردات الديناميكي القادر على إزالة الخطاف عن الدوال المستخدمة في الوقت الفعلي هو خطوة أخرى نحو تعزيز جهود المرونة لدى الخصوم.

الحل الذي أقدمه هنا هو الانتقال من استخدام واردات WinAPI التي يحلها الرابط (linker) والتي تبقى ظاهرة في رؤوس PE الخاصة بالملف التنفيذي (خاصة جدول عناوين الواردات - Import Address Table) إلى اعتماد نهج ديناميكي بالكامل يُصر على حل الواردات فقط بطريقة ديناميكية. يمكن تجهيز هذا المحلل الديناميكي بمنطق إزالة الخطاف الذي يعمل في الخلفية، دون أي توجيه من جانب المشغل.

أبسط مثال على الاستخدام

هذه هي الطريقة التي يمكنك من خلالها ضمان استدعاء MessageBoxW بدون خطاف وبدون مراقبة:

    RESOLVE(user32, MessageBoxW);
    _MessageBoxW(0, L"Look Ma! I'm unhooked!", L"Third - Unhooked", 0);

كل السحر يحدث داخل تعريف الماكرو RESOLVE، والذي يقوم ببناء كائن من نوع ImportResolver<T> باسم _MessageBoxW.

عرض توضيحي

إليك كيفية عمل مثال UnhookMe:

1. يعرض لنا أول MessageBoxW الذي لا يخضع للربط (hooking)
2. ثم نقوم بربط مقطع البداية (prologue) الخاص بـ MessageBoxW بأنفسنا لجعله يعيد دائمًا 0 دون عرض رسالته
3. أخيرًا، نقوم بحل MessageBoxW ديناميكيًا باستخدام المحلل UnhookingImportResolver، والذي سيكشف عن تصحيحات المقطع البداية المطبقة ويستعيد البايتات الأصلية، مما يؤدي فعليًا إلى إزالة خطاف وظيفة MessageBoxW.

أثناء ظهور مربعات الرسائل، هذه هي سطور السجل المطبوعة على stdout لوحدة التحكم:

[~] Resolved symbol kernel32.dll!CreateFileA
[~] Resolved symbol kernel32.dll!ReadProcessMemory
[~] Resolved symbol kernel32.dll!MapViewOfFile
[~] Resolved symbol kernel32.dll!VirtualProtectEx
[#] Found trampoline hook in symbol: MessageBoxW . Restored original bytes from file.
[~] Resolved symbol user32.dll!MessageBoxW

كيفية استخدامه؟

يوجد إجمالاً 5 ملفات مصدرية/رأسية بلغة C++ يحتاج حلك إلى تضمينها. ومع ذلك، يحتاج ملف برنامجك الرئيسي إلى تضمين ملفين رأسيين فقط، كما هو موضح أدناه.

• resolver.h - ملف رأسي يحتوي على معظم تطبيق UnhookingImportResolver وتعريفات الماكرو المفيدة
• resolver.cpp - ملف مصدري يحتوي على الخيارات العامة المحددة
• usings.h - ملف رأسي ضخم مزعج يحتوي على عشرات تعريفات الأنواع باستخدام using لواجهات برمجة التطبيقات الشائعة لـ WinAPI
• PE.cpp - ملف مصدري لمحلل PE مخصص
• PE.h - ملف رأسي لمحلل PE مخصص

الملفات الرأسية المطلوبة

سيحتاج برنامجك إلى تضمين ملفين رأسيين فقط:

#include "usings.h"
#include "resolver.h"

الخيارات العامة

هناك عدة خيارات عامة يمكن تغييرها تؤثر على طريقة عمل المحلل أو الإبلاغ عن نشاطه. هذه الخيارات محددة في بداية ملف resolver.cpp:

خيارات المحلل العامة:

• globalQuietOption - حدد true إذا كنت لا تريد أي نوع من المخرجات
• globalVerboseOption - حدد true إذا كنت تريد مخرجات مفصلة
• globalAntiSplicingOption - إزالة خطاف الدوال المحلولة إذا كانت موصلة (hooked).
• globalLogFilePath - أين يتم توجيه سطور سجل المخرجات. إذا كان فارغًا، اختر stdout.

bool globalQuietOption = false;
bool globalVerboseOption = true;
bool globalAntiSplicingOption = true;

wchar_t globalLogFilePath[MAX_PATH] = L"";

تحديد نوع واجهة برمجة التطبيقات المخصص

من أجل استخدام المحلل، يجب أولاً الإعلان عن نوع مؤشر دالة باستخدام عبارة using بالشكل الصارم التالي:

    using fn_FunctionName = ReturnType WINAPI (
        ParamType1 paramName1,
        ...,
        ParamTypeN paramNameN,
    );

يأتي هذا المستودع مع ملف رأسي usings.h يحتوي على أنواع using معرفة مسبقًا لعشرات واجهات برمجة التطبيقات الشائعة في Windows.

سيتوافق FunctionName مع WinAPI الذي نريد أن يحله ImportResolver، ويجب أن يتم تمييز مؤشر الدالة هذا بأنه يستخدم اصطلاح استدعاء WINAPI ( __stdcall على x86 و __fastcall على x64). يجب أن يسبق ReturnType معدل نوع WINAPI.

حل الدوال واستخدامها

بعد تعريف نوع مؤشر الدالة كما هو موضح أعلاه، سنكون قادرين على استخدامه بالطريقة التالية:

    RESOLVE(libraryName, FunctionName);
    ReturnType output = _FunctionName(param1, ..., paramN);

يتولى الماكرو RESOLVE إنشاء كائن ImportResolver المُنمذَج وضبط اسم المكتبة المحددة.

يقدم المحلل العديد من تعريفات الماكرو الإضافية التي تقدم استدعاءات منشئ سهلة الاستخدام في ظروف مختلفة:

#define RESOLVE(mod, func)                    RESOLVE_PARAMETERIZED(mod, func, ::globalVerboseOption, ::globalAntiSplicingOption)
#define RESOLVE_NO_UNHOOK(mod, func)          RESOLVE_PARAMETERIZED(mod, func, ::globalVerboseOption, false)

#define RESOLVE_VERBOSE_UNHOOK(mod, func)     RESOLVE_PARAMETERIZED(mod, func, true, true)
#define RESOLVE_VERBOSE_NOUNHOOK(mod, func)   RESOLVE_PARAMETERIZED(mod, func, true, false)
#define RESOLVE_NOVERBOSE_UNHOOK(mod, func)   RESOLVE_PARAMETERIZED(mod, func, false, true)
#define RESOLVE_NOVERBOSE_NOUNHOOK(mod, func) RESOLVE_PARAMETERIZED(mod, func, false, false)

منشئ المحلل:

    template<typename Ret, typename ...Args>
    ImportResolver<Ret WINAPI(Args...)>(
            std::string dllName,
            std::string funcName,
            bool _verbose = false,
            bool _unhook = false,
            bool *_wasItHooked = nullptr
        )

كيف يعمل؟

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

الفكرة كالتالي:

1. أولاً نقوم بإصدار LoadLibrary لتحميل المكتبة التي أشار إليها المستخدم (المحددة كمعامل أول لماكرو RESOLVE) إذا تعذر الوصول إليها عبر GetModuleHandle.

2. ثم نقوم بمعالجة رؤوس PE للمكتبة المحملة/المشار إليها، وتعيين صادراتها، واسترداد مصفوفة عناوين الصادرات وكذلك حساب هذه العناوين بأنفسنا للتحقق المتبادل.

3. إذا كان عنوان الروتين المحدد في جدول عناوين الصادرات (EAT) لـ DLL لا يتوافق مع ما نتوقعه، تعتبر الصادرات موصولة (EAT hooked). الأمر نفسه ينطبق إذا تم تغيير إدخال جدول عناوين الواردات (IAT) للبرنامج القابل للتنفيذ لتلك الدالة ولم يعد يشير إلى الموقع الصحيح في قسم الكود الخاص بـ DLL - فتُعتبر الدالة موصولة IAT.

4. بافتراض عدم العثور على خطافات حتى الآن، نجلب أول N بايت من مقطع البداية للدالة ونقارنها بما هو مخزن في ملف DLL على القرص. إذا كان هناك تباين بين البايتات المسترجعة من الذاكرة وتلك الموجودة في الملف - نعتبر أن الدالة قد تم تصحيحها موضعيًا (hot-patched).

5. إذا اعتبرت الدالة موصولة – نعيد عنوان الصادرات الأصلي (الذي حسبناه بأنفسنا) و/أو نزيل خطاف الإدخال. إذا كانت هناك بايتات تصحيح في مكانها، سنقوم باستعادتها.

6. أخيرًا، لتحسين تأثير المحلل على الأداء – نقوم بتخزين جميع قواعد الصور الأساسية للوحدات المحملة وعناوين الدوال المحلولة في ذاكرة تخزين مؤقت وإعادتها من ذاكرة التخزين المؤقت (باستخدام std::map) أثناء الزيارات اللاحقة.

من بين المشكلات التي يواجهها مثل هذا المحلل الذي يزيل الخطاف ديناميكيًا هي مشكلات اجتياز واجهات برمجة التطبيقات المُعاد توجيهها (forwarded APIs) (قد يحتوي DLL على نائب تصدير يقول إن هذه الدالة غير منفذة في هذه الوحدة، ولكنها موجودة في وحدة أخرى) - على الرغم من أن هذا التطبيق يدعمها، إلا أنه أحيانًا يكسر منطق الاجتياز الخاص به.

☕ دعم المشروع ☕

هذا المشروع وغيره هو نتاج ليالٍ بلا نوم والكثير من العمل الشاق. إذا كنت تحب ما أفعله وتقدر أنني دائمًا أعود للمجتمع، فكر في شراء قهوة لي (أو الأفضل بيرة) فقط لقول شكرًا! 💪

المؤلف

   Mariusz Banach / mgeeky, 21
   <mb [at] binary-offensive.com>
   (https://github.com/mgeeky)