अपने पीई पैकर का विकास

आज हम विंडोज के लिए अपना C ++ निष्पादन योग्य पैकर विकसित करने के बारे में बात करेंगे।



एक बार, जब विंडोज एक्सपी अभी तक नहीं था, पैकर्स के बारे में जानकारी की तलाश में हम तत्कालीन युवा यूपीएक्स स्रोतों के जंगल में चढ़ गए। लेकिन या तो हमारे दिमाग में एसिटाइलकोलाइन को आवश्यक से कम संश्लेषित किया गया था, या यूपीएक्स पहले से ही बहुत उबाऊ था - सामान्य तौर पर, हमने उन प्रकारों से लगभग कुछ भी नहीं निकाला। मैट पिट्रेक, और उन्होंने अधिक मदद की। अब जानकारी के साथ यह बहुत आसान हो गया है। लगभग सब कुछ है। यहां तक ​​कि सामान्य बैंकिंग ट्रॉफी को भी डाउनलोड किया जा सकता है ( ज़ीउस 2.0.8.9 )। हां, वास्तव में वहां क्या है, विंडोज प्रकार लंबे समय से सार्वजनिक ( विंडोज 2000 ) में हैं।
पैकर्स के बारे में भी जानकारी है, लेकिन मुख्य रूप से अनुसंधान, सीधे उस पक्ष से संबंधित है जिस तरफ हम नहीं चाहते हैं। इसका एक उत्कृष्ट उदाहरण दो भागों में " गुरु के बारे में पैकर्स फॉर लास्ट टाइम" लेख है, जो कुख्यात गुरु वोलोडा और NEOx द्वारा लिखा गया है।
हम, बदले में, हमारी किसी भी आवश्यकता के लिए सबसे सरल, लेकिन आसानी से परिवर्तनीय पीई पैकर के विकास पर सबसे ठोस और सुसंगत जानकारी देने का प्रयास करेंगे।

एल्गोरिथ्म

यहाँ हमारे पास है, उदाहरण के लिए, notepad.exe। अपने सामान्य 32-बिट फॉर्म में, इसका वजन लगभग 60 Kb है। हम इसकी सभी कार्यक्षमता को संरक्षित करते हुए इसे कम करना चाहते हैं। हमारे कर्म क्या होने चाहिए? खैर, शुरुआत के लिए, हम अपनी फाइल को पहली से आखिरी बाइट तक एक एरे में पढ़ेंगे। अब हम उसके साथ कुछ भी कर सकते हैं। और हम इसे निचोड़ना चाहते हैं। हम इसे लेते हैं और इसे कुछ सरल कंप्रेसर को देते हैं, जिसके परिणामस्वरूप हमें 60 Kb में सरणी नहीं मिलती है, लेकिन, उदाहरण के लिए, 20 Kb में। यह शांत है, लेकिन एक संकुचित रूप में, हमारे नोटपैड की छवि उच्च एन्ट्रॉपी के साथ बाइट्स का एक सेट है, यह एक निष्पादन योग्य नहीं है, और इसे एक फ़ाइल में लिखकर और क्लिक करके लॉन्च नहीं किया जा सकता है। एक संपीड़ित छवि के साथ एक सरणी के लिए, हमें एक मध्यम (बूटलोडर) की आवश्यकता है, एक बहुत छोटी निष्पादन योग्य फ़ाइल, जिसके लिए हम अपने सरणी को संलग्न करेंगे और जो इसे खोल देगा और इसे लॉन्च करेगा। हम माध्यम लिखते हैं, इसे संकलित करते हैं, और फिर हमारे संकुचित नोटपैड में इसे जोड़ते हैं। तदनुसार, यदि सभी कार्यों के परिणामस्वरूप प्राप्त की गई फ़ाइल (जिसका आकार थोड़े संकुचित नोटपैड की तुलना में थोड़ा बड़ा है) लॉन्च किया गया है, तो यह अपने आप में एक पैकेज्ड इमेज को ढूंढ लेगा, इसे अनपैक कर देगा, इसकी संरचना को पार्स कर देगा और इसे चलाएगा।
जैसा कि आप देख सकते हैं, हमें एक बहुत जटिल प्रक्रिया को स्वचालित नहीं करना है। आपको केवल दो प्रोग्राम, एक लोडर और वास्तव में, एक पैकर लिखना होगा।
पैकर काम एल्गोरिथ्म:

• एक सरणी में पीई फ़ाइल पढ़ें;
• कुछ दोषरहित संपीड़न एल्गोरिथ्म के साथ सरणी को संपीड़ित करें;
• पीई प्रारूप के अनुसार, लोड किए गए टेम्पलेट को लोडर टेम्पलेट में जोड़ें।

बूटलोडर एल्गोरिथ्म:

• अंत में एक संकुचित पीई फ़ाइल के साथ एक सरणी ढूंढें;
• इसे खोलना;
• पीई-फाइल के हेडर्स को पार्स करें, सभी अधिकार निर्धारित करें, मेमोरी आवंटित करें और अंततः चलाएं।

हम लोडर से विकास शुरू करेंगे, क्योंकि बाद में इसे पैकर द्वारा हेरफेर किया जाएगा।

लोडर

तो, हमारे लोडर को पहली चीज यह करनी चाहिए कि उसके शरीर में पीई फ़ाइल की संकुचित छवि के साथ सरणी का पता है। खोज के तरीके इस बात पर निर्भर करते हैं कि पैकर ने इस सरणी को लोडर में कैसे प्रत्यारोपित किया।
उदाहरण के लिए, यदि उसने केवल डेटा के साथ एक नया खंड जोड़ा है, तो खोज इस तरह दिखाई देगी:

अंतिम अनुभाग में एक संकुचित छवि की खोज करें

//    PE-    HMODULE hModule = GetModuleHandle(NULL); PIMAGE_DOS_HEADER pDosHeader = (PIMAGE_DOS_HEADER)hModule; PIMAGE_NT_HEADERS pNTHeaders = MakePtr(PIMAGE_NT_HEADERS,hModule,pDosHeader->e_lfanew); PIMAGE_SECTION_HEADER pSections = IMAGE_FIRST_SECTION(pNTHeaders); // ,      PIMAGE_SECTION_HEADER pLastSection = &pSections[pNTHeaders->FileHeader.NumberOfSections - 1]; // ,   LPBYTE pbPackedImage = MakePtr(LPBYTE, hModule, pLastSection->VirtualAddress); //   DWORD dwPackedImageSize = pLastSection->SizeOfRawData; 

लेकिन, हमारी राय में, बूटलोडर में इस कोड को बलिदान किया जा सकता है। सामान्य तौर पर, वह सब कुछ जो एक पैकर कर सकता है, उसे और केवल उसे करने दो। बूटलोडर के पता स्थान में छवि का पता अग्रिम में गणना किया जा सकता है, पैकेजिंग के दौरान, और फिर बस सही स्थान पर दर्ज किया गया। ऐसा करने के लिए, हमारे कार्यक्रम में दो अंक छोड़ें:

 LPBYTE pbPackedImage = (LPBYTE) 0xDEADBEEF; DWORD dwPackedImageSize = 0xBEEFCACE; 

जब पैकर लोडर में एक संपीड़ित छवि के साथ एक सरणी प्रत्यारोपित करेगा, तो यह लोडर के शरीर पर एक हस्ताक्षर खोज के माध्यम से जाएगा और सरणी के पते के साथ 0xDEADBEEF और उसके आकार के साथ 0xBEEFCACE को प्रतिस्थापित करेगा।

अब जब हमने यह तय कर लिया है कि पते की खोज कैसे की जाए, तो हम अपने पैकर में उपयोग के लिए कंप्रेशन एल्गोरिदम का तैयार-तैयार कार्यान्वयन चुन सकते हैं।
एक अच्छा विकल्प aplib , नीट और बहुत कॉम्पैक्ट कोड के साथ एक छोटी सी लाइब्रेरी का उपयोग करना है जो Lempel-Ziv एल्गोरिथ्म (LZ) के आधार पर संपीड़न को लागू करता है। और हम निश्चित रूप से किसी अन्य दिन इसे चुनेंगे, हालांकि आज हम एक और भी सरल और अधिक कॉम्पैक्ट समाधान के मूड में हैं - विंडोज पर निर्मित फ़ंक्शन!

XP के साथ शुरू, हमारे पसंदीदा ntdll.dll ने दो महान सुविधाओं का निर्यात शुरू किया:

 NTSTATUS RtlCompressBuffer( __in USHORT CompressionFormatAndEngine, __in PUCHAR UncompressedBuffer, __in ULONG UncompressedBufferSize, __out PUCHAR CompressedBuffer, __in ULONG CompressedBufferSize, __in ULONG UncompressedChunkSize, __out PULONG FinalCompressedSize, __in PVOID WorkSpace ); NTSTATUS RtlDecompressBuffer( __in USHORT CompressionFormat, __out PUCHAR UncompressedBuffer, __in ULONG UncompressedBufferSize, __in PUCHAR CompressedBuffer, __in ULONG CompressedBufferSize, __out PULONG FinalUncompressedSize ); 

उनके नाम खुद के लिए बोलते हैं - संपीड़न के लिए एक फ़ंक्शन, विघटन के लिए एक और। बेशक, अगर हम वास्तव में एक गंभीर उत्पाद विकसित कर रहे थे, तो हम इन कार्यों को नहीं छूते थे, क्योंकि हमारे पास अभी भी विंडोज 2000 के साथ कंप्यूटर थे, और यहां तक ​​कि NT 4.0,;) के साथ भी लेकिन हमारे मामूली उद्देश्यों के लिए, RtlCompressBuffer \ RtDDecompressBuffer काफी उपयुक्त है।
प्लेटफ़ॉर्म SDK हेडर में ये फ़ंक्शन नहीं होते हैं, हम उन्हें सांख्यिकीय रूप से लिंक नहीं कर सकते हैं, इसलिए आपको GetProcAdds का उपयोग करना होगा:

अनपैक करने के लिए फ़ंक्शन का पता निर्धारित करना

 //   RtlDecompressBuffer      DWORD (__stdcall *RtlDecompressBuffer)(ULONG,PVOID,ULONG,PVOID,ULONG,PULONG); //    RtlDecompressBuffer  ntdll.dll (FARPROC&)RtlDecompressBuffer = GetProcAddress(LoadLibrary("ntdll.dll"), "RtlDecompressBuffer" ); 

जब अनपैक करने के लिए कुछ होता है और अनपैक करने के लिए कुछ होता है, तो आप अंततः इसे पहले से ही कर सकते हैं। ऐसा करने के लिए, हम एक मार्जिन के साथ मेमोरी आवंटित करेंगे (क्योंकि हम अनपैक किए गए फ़ाइल की मात्रा को नहीं जानते हैं) और ऊपर परिभाषित फ़ंक्शन चलाते हैं:

 DWORD dwImageSize = 0; DWORD dwImageTempSize = dwPackedImageSize * 15; //      LPVOID pbImage = VirtualAlloc( NULL, dwImageTempSize, MEM_COMMIT, PAGE_READWRITE ); //  RtlDecompressBuffer(COMPRESSION_FORMAT_LZNT1, pbImage, dwImageTempSize, pbPackedImage, dwPackedImageSize, &dwImageSize); 

COMPRESSION_FORMAT_LZNT1 पैरामीटर का अर्थ है कि हम क्लासिक LZ संपीड़न का उपयोग करना चाहते हैं। फ़ंक्शन अन्य एल्गोरिदम के साथ संपीड़ित कर सकता है , लेकिन यह हमारे लिए पर्याप्त है।
अब हमारे पास मेमोरी (pbImage) में पीई फाइल की कच्ची छवि है। इसे शुरू करने के लिए, आपको उन जोड़तोड़ों की एक श्रृंखला को अंजाम देना होगा जो आमतौर पर देशी विंडोज पीई लोडर करता है। हम सूची को सबसे आवश्यक लोगों तक कम कर देंगे:

1. वैकल्पिक हेडर (OPTIONAL_HEADER) की छवि बेस फ़ील्ड में निर्दिष्ट पते पर छवि (हेडर) की शुरुआत रखें।
2. अनुभाग तालिका में इंगित पते पर पीई फ़ाइल के अनुभाग रखें।
3. आयात तालिका को पार्स करें, फ़ंक्शन के सभी पते ढूंढें और उन्हें संबंधित कोशिकाओं में दर्ज करें।

स्वाभाविक रूप से, मानक पीई लोडर अन्य कार्यों का एक पूरा गुच्छा करता है, और उन्हें प्रतिबंधित करके, हम कुछ पीई फ़ाइलों के साथ अपने पैकर की संगतता को सीमित करते हैं। लेकिन पूर्ण बहुमत के लिए, ये क्रियाएं पर्याप्त होंगी - आप झुंडों, फ़िक्सेस और अन्य दुर्लभ और गंदा कचरे को ठीक नहीं कर सकते।
यदि अचानक आप गंभीर संगतता चाहते हैं, तो आप या तो खुद एक शांत पीई-लोडर लिखते हैं, या वेब पर सबसे अधिक पूर्ण कार्यान्वयन पाते हैं - हम अपने खुद के लिखने के लिए बहुत आलसी थे, और हमने नरकंकालों से जीआर 8 के काम का उपयोग करते हुए सब कुछ फेंक दिया जो हम इसे समझ नहीं पाए। ;) यहां तक ​​कि एक काट-छाँट के रूप में, पीई-लोडर का कार्य एक सौ लाइनें है, कम नहीं है, इसलिए यहां हम केवल अपना प्रोटोटाइप (डिस्क पर पूर्ण कोड) देते हैं:

 HMODULE LoadExecutable (LPBYTE image, DWORD* AddressOfEntryPoint) 

यह हमारी अनपैक्ड छवि के लिए एक पॉइंटर लेता है और लोड किए गए मॉड्यूल (पते के बराबर जहां पीई फ़ाइल लोड की जाती है) और प्रवेश बिंदु के पते (AddressOfEntryPoint पॉइंटर द्वारा) का हैंडल लौटाता है। यह फ़ंक्शन मेमोरी में छवि को सही ढंग से रखने के लिए सब कुछ करता है, लेकिन सब कुछ नहीं ताकि आप अंत में वहां नियंत्रण स्थानांतरित कर सकें।
तथ्य यह है कि सिस्टम अभी भी हमारे द्वारा लोड किए गए मॉड्यूल के बारे में कुछ भी नहीं जानता है। यदि हम अभी प्रवेश बिंदु को कॉल करते हैं, जिससे संपीड़ित प्रोग्राम निष्पादन शुरू करता है, तो कई समस्याएं पैदा हो सकती हैं। कार्यक्रम काम करेगा, लेकिन कुटिल।
उदाहरण के लिए, GetModuleHandle (NULL) लोडर मॉड्यूल का इमेज बेस लौटाएगा, न कि अनपैक्ड प्रोग्राम। FindResource और LoadResource फ़ंक्शंस हमारे बूटलोडर के माध्यम से अफवाह करेंगे, जिसमें कोई संसाधन नहीं हैं। अधिक विशिष्ट ग्लिच हो सकते हैं। यह सब होने से रोकने के लिए, लोड किए गए मॉड्यूल के पते के साथ लोडर मॉड्यूल के पते की जगह, प्रक्रिया के सिस्टम संरचनाओं में हर जगह जानकारी को अपडेट करना आवश्यक है।
सबसे पहले, आपको पीईबी (प्रोसेस एनवायरमेंट ब्लॉक) को ठीक करने की आवश्यकता है, जो पुराने छवि आधार को इंगित करता है। PEB पता प्राप्त करना बहुत आसान है, उपयोगकर्ता मोड में यह हमेशा FS खंड में 0x30 ऑफसेट पर रहता है।

 PPEB Peb; __asm { push eax mov eax, FS:[0x30]; mov Peb, eax pop eax } // hModule —      PE- Peb->ImageBaseAddress = hModule; 

पीईबी द्वारा संदर्भित LDR_DATA संरचना में मॉड्यूल की सूची को ठीक करने के लिए भी चोट नहीं पहुंचती है। कुल तीन सूचियाँ हैं:

• InLoadOrderModuleList - बूट क्रम में मॉड्यूल की एक सूची;
• InMemoryOrderModuleList - स्मृति स्थान के क्रम में मॉड्यूल की एक सूची;
• InInitializationOrderModuleList - इनिशियलाइज़ेशन ऑर्डर में मॉड्यूल की एक सूची।

हमें प्रत्येक सूची में अपने बूटलोडर का पता ढूंढना होगा और उसे लोड किए गए मॉड्यूल के पते से बदलना होगा। कुछ इस तरह:

 //    ,   //       PLDR_DATA_TABLE_ENTRY pLdrEntry = (PLDR_DATA_TABLE_ENTRY)(Peb->Ldr->ModuleListLoadOrder.Flink); pLdrEntry->DllBase = hModule; ... 

अब आप लोड किए गए मॉड्यूल के प्रवेश बिंदु को सुरक्षित रूप से कॉल कर सकते हैं। यह कार्य करेगा जैसे कि इसे सबसे साधारण तरीके से बुलाया गया था।

 LPVOID entry = (LPVOID)( (DWORD)hModule + AddressOfEntryPoint ); __asm call entry; 

AddressOfEntryPoint, एंट्री पॉइंट का सापेक्ष वर्चुअल एड्रेस (RVA, रिलेटिव वर्चुअल एड्रेस) है, जो LoadExecutable फ़ंक्शन में वैकल्पिक हेडर से लिया गया है। एक पूर्ण पता प्राप्त करने के लिए, हमने बस आधार पता (यानी, एक नए सिरे से लोड किए गए मॉड्यूल) को RVA में जोड़ा।

डाउनलोडर का आकार

यदि हम वीएस 2010 में डिफ़ॉल्ट झंडे के साथ अपने बूटलोडर को संकलित और निर्मित करते हैं, तो हमें दो किलोबाइट प्रोग्राम-वाहक नहीं मिलेगा, लेकिन 10 Kb से बड़ा एक राक्षस होगा। स्टूडियो बहुत अधिक मात्रा में निर्मित होगा, और हमें इसे वहां से हटाने की आवश्यकता है।
इसलिए, लोडर परियोजना के संकलक गुणों में (C / C ++ टैब) हम निम्नलिखित करते हैं:

• "ऑप्टिमाइज़ेशन" अनुभाग में, "न्यूनतम आकार (/ O1)" का चयन करें ताकि कंपाइलर सभी कार्यों को अधिक कॉम्पैक्ट बनाने की कोशिश करे।
• उसी जगह में, हम गति (ध्वज / ओएस) पर आकार की प्राथमिकता का संकेत देते हैं।
• "कोड बनाना" अनुभाग में हम C ++ अपवाद बंद कर देते हैं, हम उनका उपयोग नहीं करते हैं।
• हमें बफर ओवरफ्लो (/ GS-) की जांच करने की भी आवश्यकता नहीं है। यह बात अच्छी है, लेकिन हमारे मामले में नहीं।

लिंकर (लिंकर) के गुणों में:

• मेनिफेस्टो में से नरक को मोड़ना। यह बड़ा है, और इसके कारण, .rsrc अनुभाग बूटलोडर में बनाया गया है, जिसकी हमें बिल्कुल आवश्यकता नहीं है। सामान्य तौर पर, पीई फ़ाइल में प्रत्येक अतिरिक्त खंड न्यूनतम 512 पूरी तरह से अनावश्यक बाइट्स है, जो संरेखण के लिए धन्यवाद है।
• डिबगिंग जानकारी के निर्माण को बंद करें।
• हम "उन्नत" टैब में चढ़ते हैं। हम "आधार पते के लिए यादृच्छिकता का परिचय" (/ DYNAMICBASE: NO) को बंद कर देते हैं, अन्यथा लिंकर एक रिले खंड (.reloc) बनाएगा।
• आधार पता निर्दिष्ट करें। चलो कुछ गैर-मानक उच्च चुनें, उदाहरण के लिए 0x02000000। यह मान है कि GetModuleHandle (NULL) बूटलोडर में वापस आ जाएगा। आप इसे हार्डकोड भी कर सकते हैं।
• हमारे प्रवेश बिंदु को निर्दिष्ट करें, न कि CRT-shnuyu: / ENTRY: WinMain। सामान्य तौर पर, हम इसे सीधे कोड से प्रज्ञा निर्देश के साथ करने के लिए उपयोग किया जाता है, लेकिन जब से हम गुणों में शामिल हो गए हैं, हम यहाँ हो सकते हैं।

लिंकर के लिए शेष सेटिंग्स सीधे कोड से सेट की गई हैं:

 #pragma comment(linker,"/MERGE:.rdata=.text") 

यहां हमने .rdata सेक्शन को जोड़ा है, जिसमें .text कोड सेक्शन के साथ रीड-ओनली डेटा (पंक्तियाँ, इम्पोर्ट टेबल आदि) हैं। यदि हमने वैश्विक चर का उपयोग किया है, तो हमें कोड के साथ .data अनुभाग को भी संयोजित करना होगा।

 #pragma comment(linker,"/MERGE:.data=.text") //    .data    , //        #pragma comment(linker,"/SECTION:.text,EWR") 

उपरोक्त सभी एक 1.5 Kb लोडर प्राप्त करने के लिए पर्याप्त है।

लपेटनेवाला

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

 HANDLE hFile = CreateFile(argv[1], GENERIC_READ,FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); DWORD dwImageSize = GetFileSize(hFile, 0); LPBYTE lpImage = new BYTE[dwImageSize], lpCompressedImage = new BYTE[dwImageSize]; DWORD dwReaded; ReadFile(hFile, lpImage, dwImageSize, &dwReaded, 0); CloseHandle(hFile); 

अगला, हमारे पैकर को परिणामी फ़ाइल को संपीड़ित करना चाहिए। हम यह जांच नहीं करेंगे कि क्या यह पीई फाइल है, क्या इसके हेडर सही हैं, आदि, हम सब कुछ उपयोगकर्ता के विवेक पर छोड़ देते हैं, तुरंत इसे संपीड़ित करते हैं। ऐसा करने के लिए, हम RtlCompressBuffer और RtlGetCompressionWorkSpaceSize फ़ंक्शन का उपयोग करते हैं। पहला जो हमने पहले ही ऊपर वर्णित किया है - यह बफर को संपीड़ित करता है, दूसरे को संपीड़न इंजन के संचालन के लिए आवश्यक मेमोरी की मात्रा की गणना करने की आवश्यकता है। हम मानते हैं कि हमने पहले से ही दोनों फ़ंक्शन (जैसे बूटलोडर में) को कनेक्ट किया है, यह केवल उन्हें चलाने के लिए रहता है:

 DWORD format = COMPRESSION_FORMAT_LZNT1|COMPRESSION_ENGINE_STANDARD; DWORD dwCompressedSize, dwBufferWsSize, dwFragmentWsSize; RtlGetCompressionWorkSpaceSize(format, &dwBufferWsSize, &dwFragmentWsSize); LPBYTE workspace = new BYTE [dwBufferWsSize]; RtlCompressBuffer(format , //     lpImage, //    dwImageSize, //   lpCompressedImage, //    dwImageSize, //   4096, //  ,   &dwCompressedSize, //       workspace); //    

नतीजतन, हमारे पास एक संपीड़ित बफर और इसका आकार है, हम उन्हें बूटलोडर में बांध सकते हैं। ऐसा करने के लिए, पहले आपको हमारे लोडर के संकलित कोड को पैकर में बनाना होगा। इसे प्रोग्राम में डालने का सबसे सुविधाजनक तरीका है बिन 2 एच यूटिलिटी का उपयोग करना। यह किसी भी बाइनरी को एक सुविधाजनक हेडर में बदल देगा, इसमें सभी डेटा कुछ इस तरह दिखाई देंगे:

 unsigned int loader_size=1536; unsigned char loader[] = { 0x4d,0x5a,0x00,0x00,0x01,0x00,0x00, ... 

Bin2h के साथ हैडर निर्माण को स्वचालित किया जा सकता है

हम उसे हमारे लोडर के साथ एक फाइल खिलाते हैं और आपको आगे की विकृतियों के लिए आवश्यक सब कुछ मिलता है। अब, यदि हम लेख की शुरुआत में वर्णित एल्गोरिथ्म का पालन करते हैं, तो हमें बूटलोडर को एक संपीड़ित छवि संलग्न करनी चाहिए। यहां हमें 90 के दशक को याद करना होगा और हमारे अतीत को याद रखना होगा;)। तथ्य यह है कि तीसरे पक्ष के पीई फ़ाइल में डेटा या कोड एम्बेड करना एक विशुद्ध रूप से वायरल विषय है। कार्यान्वयन बड़ी संख्या में विभिन्न तरीकों से आयोजित किया जाता है, लेकिन सबसे तुच्छ और लोकप्रिय वाले अंतिम अनुभाग का विस्तार कर रहे हैं या अपना खुद का जोड़ रहे हैं। हमारी राय में जोड़ना, संरेखण के दौरान नुकसान से भरा है, इसलिए, हमारे लोडर में एक संपीड़ित छवि को एम्बेड करने के लिए, हम इसके लिए अंतिम अनुभाग (लोडर) का विस्तार करेंगे। बल्कि, एकमात्र खंड - हमें हर चीज से छुटकारा मिला। ;)
कार्यों की एल्गोरिथ्म निम्नानुसार होगी:

• हम बूटलोडर में एकमात्र खंड (.text) पाते हैं।
• हम इसका भौतिक आकार बदलते हैं, अर्थात डिस्क पर आकार (SizeOfRawData)। यह पुराने आकार और संपीड़ित छवि के आकार के बराबर होना चाहिए और एक ही समय में फ़ाइल संरेखण (FileAlignment) के अनुसार संरेखित होना चाहिए।
• हम वर्चुअल मेमोरी साइज (Misc.VirtualSize) को बदलते हैं, इसमें कंप्रेस्ड इमेज का साइज जोड़ते हैं।
• हम पूरी बूटलोडर छवि (OptionalHeader.SizeOfImage) का प्राचीन फॉर्मूला [अंतिम खंड का आभासी आकार] + [अंतिम अनुभाग का आभासी पता] के अनुसार फाइलएग्निमेंट के साथ मान संरेखित करने के लिए भूलकर भी आकार बदलते हैं।
• संपीड़ित छवि को अनुभाग के अंत में कॉपी करें।

थोड़ी तरकीब है। तथ्य यह है कि हमारा स्टूडियो कोड के वास्तविक कोड आकार (.text) के साथ आभासी आकार (Misc.VirtualSize) बनाता है, जो कोड के वास्तविक बिना आकार के आकार के बराबर है, अर्थात यह इंगित करता है कि आकार भौतिक एक से छोटा है। तो, 511 बाइट्स तक बचाने का मौका है।
यही है, हम संरेखण शून्य के एक समूह के बाद डेटा लिखेंगे, और चिप को जानते हुए, हम इन शून्य पर लिख सकते हैं।
यह हमारे सभी विचारों को कोड में दिखेगा:

कोड अनुभाग एक्सटेंशन

 //          PBYTE pbLoaderCopy = new BYTE[simple_packer_size + dwCompressedSize + 0x1000]; memcpy(pbLoaderCopy, (LPBYTE)&simple_packer, simple_packer_size); //    PIMAGE_DOS_HEADER dos = (PIMAGE_DOS_HEADER)pbLoaderCopy; PIMAGE_NT_HEADERS nt = MakePtr(PIMAGE_NT_HEADERS, pbLoaderCopy, dos->e_lfanew); //   PIMAGE_SECTION_HEADER text = IMAGE_FIRST_SECTION(nt); //         memcpy(&pbLoaderCopy[text->PointerToRawData + text->Misc.VirtualSize], lpCompressedImage, dwCompressedSize); //   ,    Misc.VirtualSize text->SizeOfRawData = ALIGN(text->Misc.VirtualSize + dwCompressedSize, nt->OptionalHeader.FileAlignment); //   (    )  text->Misc.VirtualSize += dwCompressedSize; //    nt->OptionalHeader.SizeOfImage = ALIGN(test->Misc.VirtualSize + test->VirtualAddress, nt->OptionalHeader.FileAlignment); //     DWORD dwNewFileSize = pSections->SizeOfRawData + test->PointerToRawData; 

ओह, हम लगभग 0xDEADBEEF और 0xBEEFCACE लेबल को बूटलोडर में छोड़े गए वास्तविक मानों से बदलना भूल गए हैं! 0xBEEFCACE संपीड़ित छवि के आकार में बदलता है, और 0xDEADBEEF अपने पूर्ण पते पर। छवि पते की गणना सूत्र [छवि पता] + [अनुभाग का आभासी पता] + [अनुभाग की शुरुआत के सापेक्ष ऑफसेट छवि] द्वारा की जाती है। यह ध्यान दिया जाना चाहिए कि प्रतिस्थापन Misc.VirtualSize के मान को अपडेट करने से पहले किया जाना चाहिए, अन्यथा परिणामस्वरूप फ़ाइल काम नहीं करेगी।
हम बहुत ही सरल लूप का उपयोग करके टैग खोजते और बदलते हैं:

 for (int i = 0; i < simple_packer_size; i++) if (*(DWORD*)(&pbLoaderCopy[i]) == 0xBEEFCACE) *(DWORD*)(&pbLoaderCopy[i]) = dwCompressedSize; else if (*(DWORD*)(&pbLoaderCopy[i]) == 0xDEADBEEF) *(DWORD*)(&pbLoaderCopy[i]) = nt->OptionalHeader.ImageBase + text->VirtualAddress + text->Misc.VirtualSize; 

वह, वास्तव में, सब है। अब मेमोरी में हमारे पास एक पैकेज्ड और वर्क फाइल के लिए तैयार है, बस इसे CreateFile / WriteFile फ़ंक्शन का उपयोग करके डिस्क पर सहेजें।

OllyDbg में एक बोल्ड फ़ाइल डीबग करने की प्रक्रिया

निष्कर्ष

अगर हम अपने पैकर की संपीड़न दक्षता की तुलना UPX के साथ Notepad.exe के उदाहरण से करते हैं, तो हम यूपीएक्स द्वारा 48 128 के मुकाबले 1 Kb: 46 592 बाइट्स जीतते हैं। हालाँकि, हमारा पैकर एकदम सही है। और यह बहुत ही ध्यान देने योग्य है।
तथ्य यह है कि हमने जानबूझकर संसाधनों के हस्तांतरण जैसी महत्वपूर्ण चीज को नजरअंदाज किया है। परिणामी संपीड़न फ़ाइल आइकन खो देगी! आपको लापता फ़ंक्शन को स्वयं लागू करना होगा। इस सामग्री से प्राप्त ज्ञान के लिए धन्यवाद, आपको इस मामले में कोई कठिनाई नहीं होगी।

लेख के लिए स्रोत

हमारे पैकर ने UPX से अधिक notepad.exe को संकुचित किया!

---

क्रिप्टो में बदलें

दरअसल, हमारा पैकेज क्रिप्टोर से काफी अलग है: एन्क्रिप्शन और एंटी-इम्यूलेशन तकनीकों की कमी। सबसे आसान काम जो आप अभी कर सकते हैं, वह है बूटलोडर में अनपैक करने के बाद पूरी छवि को जोड़ने के लिए। लेकिन एंटी-वायरस एमुलेटर को चोक करने के लिए, यह पर्याप्त नहीं है। किसी भी तरह कार्य को जटिल करना आवश्यक है। उदाहरण के लिए, बूटलोडर निकाय में xor कुंजी पंजीकृत न करें। यही है, बूटलोडर को पता नहीं होगा कि कोड को डिक्रिप्ट करने के लिए किस कुंजी की आवश्यकता है, यह हमारे द्वारा परिभाषित ढांचे में इस पर पुनरावृत्ति करेगा। एंटीवायरस के विपरीत, उपयोगकर्ता को कुछ समय लग सकता है।
इसके अलावा, कुंजी को कुछ गैर-उत्सर्जित फ़ंक्शन या संरचना पर निर्भर किया जा सकता है। केवल उन्हें अभी भी खोजने की आवश्यकता है।
ताकि बूटलोडर कोड हस्ताक्षर से जल न जाए, आप कूड़े और किसी भी प्रकार के कोड संशोधन के लिए पैकर के लिए कुछ उन्नत वायरस इंजन को फास्ट कर सकते हैं, क्योंकि वे वेब में बल्क हैं।

---

बूटलोडर में LoadExecutable फ़ंक्शन को निष्पादित करने के बाद, अनपैकिंग के लिए आवंटित मेमोरी को मुक्त करना अच्छा होगा - यह अब हमारे लिए उपयोगी नहीं होगा।

---

हैकर पत्रिका, फरवरी (02) 157
पीटर और भेड़िया ।

हैकर की सदस्यता लें

• 1 999 पी। पेपर विकल्प के 12 नंबरों के लिए
• 1249 आरयूआर iOS / iPad की वार्षिक सदस्यता के लिए (Android रिलीज़ जल्द ही आ रहा है!)
• एंड्रॉइड पर हैकर