DllShimmer

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

DllShimmer मूल DLL को पार्स करता है और निर्यात किए गए फ़ंक्शनों (नाम, क्रम संख्या, और फ़ॉरवर्डर जानकारी) के बारे में जानकारी निकालता है। इस जानकारी के आधार पर, DllShimmer एक बॉयलरप्लेट C++ फ़ाइल (.cpp) बनाता है। जेनरेट की गई फ़ाइल आपको प्रोग्राम के सामान्य संचालन को बाधित किए बिना, मूल DLL से निर्यात किए गए प्रत्येक फ़ंक्शन में अपना कोड जोड़ने की अनुमति देती है। किसी रिवर्स इंजीनियरिंग या इंस्ट्रुमेंटेशन की आवश्यकता नहीं है, क्योंकि DllShimmer फ़ंक्शन सिग्नेचर पर निर्भर नहीं करता है (अधिक जानकारी के लिए "सीमाएँ" देखें)।

दूसरी जनरेट की गई फ़ाइल एक .def फ़ाइल है, जो सुनिश्चित करती है कि संकलन के बाद प्रॉक्सी से निर्यात किए गए सभी DLL के नाम और क्रम संख्याएँ मूल DLL के समान हों।

संकलन के बाद, प्रॉक्सी DLL में EAT, मूल DLL में EAT की सटीक प्रति होती है। निर्यात किए गए फ़ंक्शनों के सभी नाम और क्रम संख्याएँ मेल खाती हैं, और फ़ॉरवर्ड किए गए फ़ंक्शन भी फ़ॉरवर्ड किए जाते हैं। DllShimmer सभी फ़ंक्शनों को (अधिकांश टूल्स की तरह) स्पष्ट रूप से फ़ॉरवर्ड नहीं करता है, जिससे एक पूरी तरह से नई और संदिग्ध EAT संरचना बनती है।

स्थापना

Go सोर्स कोड को संकलित करें या संकलित बाइनरी डाउनलोड करें.

निर्भरताएँ:

• x86_64-w64-mingw32-g++
• x86_64-w64-mingw32-dlltool

उपयोग

उदाहरण:

# Backdoor version.dll (proxy to absolute path)
./DllShimmer -i version.dll -o project/ -x "C:/Windows/System32/version.dll" -m

# Backdoor random chat.dll (proxy to relative path)
./DllShimmer -i chat.dll -o project/ -x "lib/chat2.dll" -m

# Backdoor random app.dll (static linking to the original DLL)
./DllShimmer -i app.dll -o project/ -x "app2.dll" -m --static

पैरामीटर:

-i / --input <path> [आवश्यक]

वह मूल DLL जिसे आप बैकडोर करना चाहते हैं।

-o / --output <path> [आवश्यक]

उस निर्देशिका का पथ जहाँ DllShimmer सभी जनरेट की गई फ़ाइलों को सहेजेगा।

-x / --original <path> [आवश्यक]

डायनामिक लिंकिंग (डिफ़ॉल्ट) के मामले में वह पथ प्रदान करें जहाँ प्रॉक्सी DLL को लक्ष्य सिस्टम पर मूल DLL मिलेगा।

स्टैटिक लिंकिंग (--static) के मामले में, केवल मूल DLL का नाम निर्दिष्ट करें। इसे Windows पर डिफ़ॉल्ट लोडिंग क्रम के अनुसार खोजा जाएगा।

-m / --mutex [वैकल्पिक]

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

--static [वैकल्पिक]

प्रॉक्सी DLL (IAT) और मूल DLL (EAT) के बीच स्टैटिक लिंकिंग सक्षम करें। यह आउटपुट निर्देशिका में एक अतिरिक्त .lib फ़ाइल उत्पन्न करता है, जो स्टैटिक संकलन के लिए मूल DLL के रूप में कार्य करती है।

इस तकनीक की डायनामिक लिंकिंग की तुलना में कुछ गंभीर सीमाएँ हैं:

• आप मूल DLL के लिए पूर्ण या सापेक्ष पथ परिभाषित नहीं कर सकते। सिस्टम लोडर केवल प्रॉक्सी IAT से DLL नाम का उपयोग करता है और डिफ़ॉल्ट पथों में खोजता है।
• सीमित डीबगिंग जानकारी। यदि मूल DLL लोड होने में विफल रहता है, तो प्रोग्राम आमतौर पर अतिरिक्त जानकारी के बिना क्रैश हो जाएगा।

हालाँकि, स्टैटिक लिंकिंग कुछ परिदृश्यों में अधिक गुप्त और स्वाभाविक हो सकती है।

डिफ़ॉल्ट: DllShimmer हमेशा LoadLibraryA() और GetProcAddress() फ़ंक्शनों के साथ डायनामिक लिंकिंग का उपयोग करता है।

--debug-file <path> [वैकल्पिक]

डीबग लॉग्स को एक फ़ाइल में सहेजें। प्रोग्राम चलने के दौरान लॉग्स लगातार एक फ़ाइल में लिखे जाते हैं। यदि चुना जाता है, तो लॉग्स STDOUT पर प्रिंट नहीं किए जाते हैं।

डिफ़ॉल्ट: DllShimmer हमेशा डीबग लॉग्स को STDOUT पर लिखता है।

डीबग आउटपुट का उदाहरण:

सीमाएँ

• केवल x86-64 / AMD64 आर्किटेक्चर समर्थित है।
• सबसे अधिक संभावना है, सामान्य प्रॉक्सी कोड फ्लोटिंग-पॉइंट पैरामीटर वाले फ़ंक्शनों के लिए काम नहीं करेगा, क्योंकि वे DllShimmer द्वारा उपयोग किए जाने वाले पूर्णांक रजिस्टरों से भिन्न रजिस्टरों का उपयोग करते हैं। यदि आप फ़ंक्शन सिग्नेचर जानते हैं, तो आप इसे जनरेट की गई फ़ाइल में मैन्युअल रूप से समायोजित कर सकते हैं।
• 12 से अधिक तर्कों वाले फ़ंक्शन काम नहीं करेंगे, क्योंकि यह संख्या DllShimmer टेम्पलेट्स में हार्डकोड की गई है।
• कुछ विशाल ओबफस्केटेड DLL हैं जिनमें अजीब नाम मैंगलिंग, कॉलिंग कन्वेंशन और तरकीबें होती हैं (उदाहरण के लिए, संकलित Qt फ्रेमवर्क DLL)। मैं उन्हें प्रॉक्सी DLL के रूप में उपयोग करने की अनुशंसा नहीं करता। इस मामले में DllShimmer सबसे अधिक संभावना कुछ कचरा उत्पन्न करेगा।

समस्या निवारण

समस्या निवारण शुरू करने से पहले:

1. "सीमाएँ" पढ़ें।
2. सुनिश्चित करें कि आप स्टैटिक लिंकिंग (--static) का उपयोग नहीं कर रहे हैं। डायनामिक लिंकिंग (डिफ़ॉल्ट) के साथ डीबग करना आसान है।
3. डीबग आउटपुट को फ़ाइल (--debug-file) में सहेजें।

जनरेट की गई .cpp फ़ाइल में, मुझे मूल DLL से निर्यात किए गए सभी फ़ंक्शन दिखाई नहीं देते हैं।

मूल DLL में "फ़ॉरवर्डेड" के रूप में परिभाषित फ़ंक्शन .cpp फ़ाइल में शामिल नहीं हैं। हालाँकि, वे .def फ़ाइल में दिखाई देते हैं। संकलन के बाद वे भी मूल DLL की तरह ही निर्यात किए जाएंगे।

मूल DLL लोड करते समय अजीब लोडर त्रुटि (126)

कभी-कभी, आपका प्रॉक्सी DLL मूल DLL लोड करते समय एक त्रुटि दिखाता है, और त्रुटि कोड 126 होता है, भले ही आपने सैद्धांतिक रूप से -x पैरामीटर में सही सापेक्ष पथ निर्दिष्ट किया हो। यह काम क्यों नहीं कर रहा है?!?

DLL को वर्तमान निर्देशिका में खोजा जाता है। 98% मामलों में, यह केवल मुख्य EXE फ़ाइल का स्थान होता है, लेकिन कुछ प्रोग्राम (ज्यादातर पुराने विरासत वाले) होते हैं जो मनमाने ढंग से वर्तमान निर्देशिका को बदलते हैं, उदाहरण के लिए, SetCurrentDirectoryW() का उपयोग करके। मुख्य प्रोग्राम इस परिवर्तन से अवगत होता है, इसलिए यह आपके प्रॉक्सी DLL को सही ढंग से लोड करता है, लेकिन आप इससे अनजान होते हैं और मूल DLL को सापेक्ष रूप से लोड करने का प्रयास करते हैं, जबकि प्रोग्राम इसे बदली हुई वर्तमान निर्देशिका में खोजता है।

यह नियम मूल DLL के स्टैटिक और डायनामिक दोनों प्रकार के लोडिंग पर लागू होता है। दुर्भाग्य से, स्टैटिक लिंकिंग के साथ, इस समस्या का पता लगाना बहुत कठिन है क्योंकि हमारे पास डीबग जानकारी नहीं होती है। सिस्टम लोडर बस विफल हो जाता है और बस। यही कारण है कि मैं हमेशा पहले डिफ़ॉल्ट डायनामिक लिंकिंग का उपयोग करने की सलाह देता हूँ।

डायनामिक लिंकिंग के मामले में, हमारे पास दो विकल्प हैं:

1. -x पैरामीटर में पथ को नई वर्तमान निर्देशिका स्थिति के अनुसार समायोजित करें।
2. DLL को वहाँ खोजने के लिए वर्तमान निर्देशिका को गतिशील रूप से बदलें जहाँ हम चाहते हैं।

स्टैटिक लिंकिंग के मामले में, हमारे पास वास्तव में केवल एक विकल्प है:

1. मूल DLL को वर्तमान निर्देशिका में ले जाएँ।

TODO

• C++ मैंगल्ड फ़ंक्शन नामों के लिए समर्थन