NTDLL Unhook

नेटिव API के माध्यम से ntdll .text सेक्शन को सही तरीके से अनहुक करना। x86/x64/wow64 समर्थित।

यह कैसे काम करता है

प्रोग्राम PEB को ट्रैवर्स करके ntdll.dll का बेस एड्रेस खोजता है और Import Address Table को छुए बिना NT API फंक्शन्स को रिज़ॉल्व करने के लिए PE एक्सपोर्ट टेबल को मैन्युअल रूप से पार्स करता है। फिर यह डिस्क से क्लीन ntdll.dll खोलने के लिए NtOpenFile का उपयोग करता है, NtCreateSection के साथ एक सेक्शन ऑब्जेक्ट बनाता है, और NtMapViewOfSection के साथ इसे प्रोसेस में मैप करता है ताकि LoadLibrary के माध्यम से दूसरी dll लोड किए बिना एक अनहुक स्रोत प्राप्त हो सके। हुक्ड .text सेक्शन को NtProtectVirtualMemory के माध्यम से PAGE_EXECUTE_READWRITE में बदल दिया जाता है, क्लीन .text को कस्टम memcpy के साथ हुक्ड वाले के ऊपर कॉपी किया जाता है, और फिर प्रोटेक्शन को मूल फ्लैग्स पर वापस बहाल कर दिया जाता है। बाइट-दर-बाइट सत्यापन के बाद कि अनहुक सफल रहा, क्लीन कॉपी को NtUnmapViewOfSection के साथ ठीक से अनमैप कर दिया जाता है ताकि मेमोरी में दूसरा ntdll लोड न रहे।

अधिकतर अनहुक्स बेकार क्यों हैं

अधिकतर पब्लिक अनहुक कोड सचमुच उसी खराब स्रोत से कॉपी-पेस्ट किया गया है (जैसे ired.team उदाहरण और मूल रूप से github पर लगभग हर ओपनसोर्स अनहुकर) और इसमें बड़ी समस्याएं हैं जो इसे किसी भी असली EDR के खिलाफ बेकार बनाती हैं। वे नेटिव APIs के बजाय VirtualProtect का उपयोग करते हैं जो पूरे उद्देश्य को ही खत्म कर देता है क्योंकि आप अनहुक करने के लिए हुक्ड फंक्शन्स को कॉल कर रहे हैं, वे .text सेक्शन पर RWX अनुमतियाँ सेट करते हैं जो एक बड़ा IOC है जिसे EDR तुरंत फ्लैग करते हैं, और वे वास्तव में क्लीन कॉपी को अनमैप नहीं करते क्योंकि सेक्शन मैपिंग पर CloseHandle मेमोरी को मुक्त नहीं करता। आपको UnmapViewOfFile या NtUnmapViewOfSection की आवश्यकता है लेकिन हर कोई इस हिस्से को भूल जाता है, इसलिए वे प्रोसेस में ntdll की दो कॉपी लोड छोड़ देते हैं जो मूल रूप से एक विशाल नियॉन साइन है जो कहता है "मैं मैलवेयर हूँ"। वे मुख्य ntdll पर FreeLibrary का उपयोग करने की भी कोशिश करते हैं जो काम भी नहीं करता और हैंडल लीक का कारण बनता है, साथ ही वे प्रोटेक्शन को बेवजह दो बार RWX में बदलते हैं जबकि ठीक से रिस्टोर करने पर एक बार ही काफी है।

OPSEC विचार

यह इम्प्लीमेंटेशन पब्लिक अनहुक कोड में आम बग्स को ठीक करता है: पूरे समय नेटिव APIs का उपयोग करके (NtOpenFile, NtCreateSection, NtMapViewOfSection, NtProtectVirtualMemory), NtUnmapViewOfSection के साथ क्लीन कॉपी को ठीक से अनमैप करके ताकि ntdll की दो कॉपी लोड न रहें, मुख्य ntdll पर FreeLibrary का उपयोग न करके, और मेमोरी तुलना के माध्यम से सफलता को सत्यापित करके। हालाँकि यह उन मूलभूत IOCs से नहीं बचता जिन्हें आधुनिक EDR पहचानते हैं। C:\Windows\System32\ntdll.dll पर NtOpenFile का उपयोग करना एक IOC है जो लॉग होता है, ntdll.dll की ओर इशारा करते हुए SEC_IMAGE के साथ NtCreateSection ETW के माध्यम से ट्रैक किया जाता है, ntdll के .text सेक्शन पर मेमोरी प्रोटेक्शन बदलना नेटिव APIs के साथ भी एक बड़ा रेड फ्लैग है, और .text में लिखना मेमोरी राइट कॉलबैक के माध्यम से पता लगाने योग्य है। यह तकनीक सर्वविदित है और आधुनिक EDR जैसे CrowdStrike और SentinelOne के पास पूरे पैटर्न के लिए सिग्नेचर हैं। Microsoft Defender for Endpoint और Elastic जैसे उन्नत EDR अब यूजरमोड हुक्स का उपयोग भी नहीं करते क्योंकि वे कर्नेल कॉलबैक और ETW टेलीमेट्री पर निर्भर करते हैं, इसलिए अनहुकिंग उनके खिलाफ सचमुच कुछ नहीं करती। यह केवल बेसिक EDRs के खिलाफ काम करता है जो केवल इनलाइन हुक्स और पुराने सुरक्षा उत्पादों का उपयोग करते हैं, लेकिन कर्नेल-मोड घटकों या व्यवहार विश्लेषण वाली किसी भी चीज़ के खिलाफ विफल हो जाता है। बेहतर विकल्पों में डायरेक्ट सिस्कॉल्स शामिल हैं जहाँ आप शुरू में ही हुक्ड फंक्शन्स को कभी नहीं बुलाते, wow64 बाउंड्री क्रॉसिंग के लिए हेवन्स गेट, रनटाइम पर ntdll .text से मैन्युअल सिस्कॉल निष्कर्षण, या पूरी तरह से संदिग्ध APIs से बचना, क्योंकि 2024/2025 में अनहुकिंग आम तौर पर वास्तविक एंटरप्राइज़ EDR के खिलाफ एक मृत तकनीक है।

आर्किटेक्चर समर्थन

x64 नेटिव प्रोसेस, x86 नेटिव प्रोसेस, और wow64 प्रोसेस (x64 विंडोज़ पर x86) पर काम करता है। यह स्वचालित रूप से wow64 का पता लगाता है और सही सिस्टम डायरेक्टरी (System32 बनाम SysWOW64) का उपयोग करता है ताकि आपको इसके बारे में सोचना न पड़े।

क्या अनहुक होता है

केवल ntdll.dll का .text सेक्शन छुआ जाता है क्योंकि वहाँ सभी वास्तविक फंक्शन कोड रहते हैं और वहीं EDR हुक्स को इनलाइन फंक्शन हुक्स (फंक्शन प्रोलॉग्स पर jmp निर्देश) के रूप में रखा जाता है। .data और .rdata जैसे अन्य सेक्शन्स को अकेला छोड़ दिया जाता है क्योंकि उन्हें छूने का कोई कारण नहीं है और यह केवल बिना लाभ के अधिक IOCs बनाता है।

Build

cl /EHsc /std:c++17 main.cpp /Fe:unhook.exe

या जो भी हो, कोई भी आधुनिक c++ कंपाइलर काम करता है। windows.h और winternl.h चाहिए।

CFAA

कंप्यूटर सिस्टम तक अनधिकृत पहुँच अवैध है। केवल उन सिस्टम्स पर उपयोग करें जिनके मालिक आप हैं या जिन पर परीक्षण करने का आपके पास अधिकार है। संघीय जेल असली है।

तकनीकी नोट्स

कोड LDR सूचियों को ठीक से ट्रैवर्स करने के लिए CONTAINING_RECORD मैक्रो का उपयोग करता है, सेगमेंट रजिस्टरों के माध्यम से PEB तक पहुँचता है (x64 पर gs, x86 पर fs), नाम तुलना के माध्यम से हार्डकोडेड .text सेक्शन खोज करता है जो अधिक सुंदर हो सकता था लेकिन चलता है, NTSTATUS कोड और NT_SUCCESS मैक्रो के माध्यम से त्रुटियों को संभालता है, और सुरक्षा के लिए मेमोरी ऑपरेशन्स को SEH try/except में लपेटता है। यदि आप c++ नहीं पढ़ सकते और PE फॉर्मेट की आंतरिक संरचना नहीं समझते हैं तो आपको शायद इसका उपयोग वैसे भी नहीं करना चाहिए।