मैलवेयर विश्लेषण तकनीक: रिंग 3 में ड्राइवर को अनपैक करना

ट्रोजन और हर मैलवेयर के विश्लेषण में रोजमर्रा के काम में, पर्याप्त आवधिकता के साथ ऐसे उदाहरण हैं जो एन्क्रिप्ट किए गए ड्राइवरों को छोड़ देते हैं। लेकिन मैं मामूली रूप से आलसी हूं और रिंग 3 में काम करता था, इसलिए मैं आपको निम्न-स्तरीय डिबगर्स का सहारा लिए बिना ड्राइवरों को अनपैक करने का एक तरीका दिखाऊंगा।

प्रविष्टि

शुरू करने के लिए, यह कहने योग्य है कि यह विधि उन ड्राइवरों के लिए उपयुक्त है जो कर्नेल और सिस्टम लाइब्रेरी से बहुत कम संख्या में एपीआई आयात करते हैं। दर्जनों कार्यों के एक जोड़े का क्रम। अन्यथा, हम एक नहीं बल्कि काम के इंतजार में हैं, जो इसके लायक नहीं है।

ड्राइवर की तैयारी

स्वयं चालक, इसकी संरचना में, सामान्य गतिशील पुस्तकालयों के लगभग समान है। और इसे रिंग 3 में लोड करने के लिए, आपको पीई-हेडर में कुछ फ़ील्ड बदलने की आवश्यकता है, अर्थात्:

• Windows GUI पर मूल के साथ सबसिस्टम टाइप करें। (PeTools में, वैकल्पिक हैडर बटन);
• IMAGE_FILE_HEADER.Characteristics फ़ील्ड में Dll विशेषता सेट करें। (PeTools में, फ़ाइल हैडर बटन, और फिर अभिलक्षण);

अब आपको सिस्टम को निम्न-स्तरीय पुस्तकालयों से ड्राइवर को खोलना होगा। ऐसा करने के लिए, हम आवश्यक कार्यों के स्टब्स के साथ अपना स्वयं का डीएल (या किसी को, जैसा भी चाहें) लिखेंगे। हम आयातित API की सूची खोलते हैं और MSDN या अन्य सूचना संसाधनों में उनके प्रोटोटाइप की तलाश करते हैं।
मेरे मामले में, सूची इस प्रकार है:


ताकि ड्राइवर हमारे dll को ठीक से लोड कर सके, न कि सिस्टम एक को, हमारे द्वारा तैयार किए गए आयातित मॉड्यूल के नामों को पैच कर सके।


अब हमारे ड्राइवर को उपयोगकर्ता-मोड डिबगर में लोड किया जा सकता है, उदाहरण के लिए, ओलीडबग।

जैसे-जैसे आप पूरे होते हैं, समस्याओं को खोलना और हल करना

इस मामले में, पैकर आदिम है - एक्सोर और एलजेड एल्गोरिथ्म का एक बदलाव। मैं इस तथ्य के बावजूद, कि यह थोड़ा फिसड्डी है, एक्सोर डिक्रिप्टर पर विचार नहीं करेगा। डिक्रिप्शन के बाद, हमें निम्न कोड प्राप्त होते हैं:


यह पहली मुसीबत है। यदि आप कोड को जाने देते हैं, तो तुरंत अपवाद ACCESS_VIOLATION को पकड़ लें। कोड सेवा संरचना से ntoskrnl.exe के अंदर पते को लेता है और ImageBase मॉड्यूल को ढूंढता है। लेकिन जब से हम रिंग 3 में हैं, एफएस सेगमेंट में स्थित संरचना परमाणु से अलग है। और यदि आप कोड को कोड करते हैं, तो एफएस से: [38] 0 माना जाता है, और अगला कमांड 0 + 4 पर पढ़ा जाएगा। स्वाभाविक रूप से, हमारे पास या तो हमारी मेमोरी में कोई भी ntoskrnl नहीं है, इसलिए मान लें कि हमें ntdll पता मिलता है (इसके API में से अधिकांश कर्नेल फ़ंक्शन के समान है)।

मेमोरी कार्ड खोलें और देखें कि एफएस सेगमेंट में क्या है। TIB - थ्रेड सूचना ब्लॉक देखना चाहिए। थोड़ा देखने के बाद, आप इसे पीईबी - प्रोसेस एनवायरनमेंट ब्लॉक के लिए एक पॉइंटर में देख सकते हैं। हम ntdll में किसी भी उपयुक्त पते का चयन करते हैं (मैंने PEB.FastPebLock को चुना)।


आप बस कोड भर सकते हैं, और ट्रेस के दौरान पता बदलकर ntdll कर सकते हैं। लेकिन हम अलग तरह से कार्य करेंगे - हम विस्थापन को बदल देंगे।


अगली समस्या जो हम पाठ्यक्रम के दौरान सामना करते हैं वह यह है कि अनपैक गतिशील रूप से आवश्यक परमाणु कार्यों के पते प्राप्त करता है। स्क्रीनशॉट छद्म फ़ंक्शन xGetProcAddress के साथ नामों की सूची के माध्यम से लूप दिखाता है, जो सिस्टम का एक एनालॉग है। इसकी शुरुआत, जहां यह एमजेड हेडर को पार्स करता है, सबसे नीचे देखा जा सकता है।


EDX आवश्यक फ़ंक्शन नामों की सूची को इंगित करता है।


चौकस थोड़ा कम MZ हेडर को नोटिस करेगा, लेकिन बाद में उस पर अधिक।
यह असामान्य कुछ भी नहीं लगता है। सब कुछ ठीक होगा, लेकिन केवल ntdll में कुछ आवश्यक API, या कम से कम प्रोटोटाइप में समान नहीं हैं। लेकिन अगर आप इसके बारे में थोड़ा सोचते हैं, तो कर्नेल 32.dll में शामिल होंगे।

1. PVOID ExAllocatePool(POOL_TYPE PoolType, SIZE_T NumberOfBytes); VOID ExFreePool(PVOID P);
2. PVOID ExAllocatePool(POOL_TYPE PoolType, SIZE_T NumberOfBytes); VOID ExFreePool(PVOID P);

से बदला जा सकता है

1. HGLOBAL WINAPI GlobalAlloc (UINT uFlags, SIZE_T dwBytes);
2. HGLOBAL WINAPI GlobalFree (HGLOBAL hMem);

हम किसी भी उपलब्ध कार्यों के लिए कोई नहीं के नाम बदल देते हैं, ताकि xGetProcAddress बस सही ढंग से काम करे। मैंने उन्हें NtClose से बदल दिया।


धीरे से ट्रेसिंग करते हुए, हम रजिस्टरों में NtClose एड्रेस को उन कर्नल 32.dll से जरूरी एड्रेस से बदल देते हैं। चक्र से बाहर काम करने के बाद, सभी आवश्यक पते प्राप्त होते हैं, जैसा कि नीचे दी गई छवि में देखा जा सकता है। यह समस्या खत्म हो गई है, हम जारी रखते हैं।


हम सुनिश्चित करते हैं कि GlobalAlloc के साथ जिस ExAllocatePool को हमने प्रतिस्थापित किया है, वह लगातार काम कर रही है।


वे चुपचाप अनपैकिंग के पास पहुँचे।


शायद कोड को कोडांतरक पर लिखा गया था, क्योंकि वहाँ कुछ भी नहीं है। स्क्रीन पर कोड मेमोरी एलोकेशन करता है, इसमें अनपैकिंग करता है, फिर इमेज तैयार करता है, जीरो करता है और मेमोरी को क्लीन करता है, और यदि सफल होता है, तो ओईपी को जम्प करता है।
मैंने विघटन एल्गोरिथ्म का अध्ययन नहीं किया, क्योंकि प्रतीत होता है कि सिकुड़ा हुआ डेटा मुझे LZW संस्करण के समान लग रहा था।


अनपैकर किसी भी एपीआई का उपयोग नहीं करता है, इसलिए यह जल्दी और बिना किसी समस्या के चलता है। दरअसल, इसके ठीक बाद आप एक स्वच्छ ड्राइवर के साथ क्षेत्र को डंप कर सकते हैं। लेकिन मैं सोच रहा था कि रिंग 3 में होने के नाते विश्लेषण में आगे बढ़ना कितना संभव होगा।
ReadyImage फ़ंक्शन अनपैक की गई छवि तैयार करता है: आवश्यक ऑफ़सेट पर अनुभागों को हटाता है, आयात से API पते प्राप्त करता है, और रिलोकेशन तालिका के अनुसार पते को पुन: संयोजित करता है।
IAT फ़ंक्शन खोज चक्र द्वारा हम उन पहियों से नियमित रूप से चिपके रहते हैं, जो न केवल उन मॉड्यूल का अनुरोध करते हैं जो हमारे पास नहीं हैं (ntoskrnl, hal, आदि), बल्कि तदनुसार कार्य भी करते हैं।


जैसा कि आप देख सकते हैं, मैं पहले ही चक्र में शामिल हो गया हूं, लेकिन ईआईपी को 0x008982d7 में बदलना, ईएसपी को कम करना और इसे EAX = 0 पर सेट करना, कम या ज्यादा सही ढंग से इसे छोड़ दिया। रिलेक्स को संपादित करने से हमें कोई परेशानी नहीं होती है, और हम अंत में OEP जाते हैं। लेकिन इसे रोकना होगा, क्योंकि आयात पते बहाल नहीं किए गए हैं, और मुझे स्टब्स के साथ एक और डीएल लिखने में कोई कारण नहीं दिखता है। शुद्ध कोड पहले से ही एक डिस्सेम्बलर में सांख्यिकीय रूप से पार्स किया जा सकता है।

आउटपुट के बजाय

करने के लिए:


... और उसके बाद:


खोज में नीचे स्क्रीनशॉट से लाइनों को चलाकर आपको पीड़ा नहीं देने के लिए, मैं तुरंत कहूंगा कि यह रस्टॉक के संस्करणों में से एक है

एक बार फिर मुझे यकीन हो गया है कि मेरा आलस्य मुझे "माथे" के फैसले से भी दूर कर सकता है।