🍤 ⚠️ 🕯️ यूपीएक्स में उपयोग किए जाने वाले संपीड़न अनुपात में सुधार 😶 🧦 🌂

अनुवादक से:

"हूड" के तहत एक छोटी लेकिन बेहद उपयोगी टेक्स्ट फ़ाइल "% UPX_SOURCE% \ doc \ filter.tw" का अनुवाद है। उपर्युक्त पथ में, UPX_SOURCE का अर्थ है UPX संस्करण 3.91 के स्रोत कोड के लिए फ़ाइल पथ।

दस्तावेज़ "फ़िल्टरिंग" नामक UPX ऑपरेशन के एक महत्वपूर्ण पहलू का वर्णन करता है, और जब UPX- पैक फ़ाइलों का विश्लेषण करता है, तो यह समझना बहुत महत्वपूर्ण है कि यह कैसे काम करता है। UPX के बारे में वर्णित सब कुछ अन्य पैकर्स पर भी लागू होता है।

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

फ़िल्टरिंग प्रक्रिया को समझने से पैक्ड फ़ाइलों का अध्ययन करने में मदद मिलती है, उदाहरण के लिए UPX, RLPack, आदि का उपयोग करके। पैक की गई फ़ाइलों में, आप कोड पा सकते हैं जहाँ मशीन के साथ कुछ "जादुई क्रिया" की जाती हैं। संक्रमण निर्देश बाइट्स 0xE8, 0xE9, आदि। यह "जादू" ठीक "फ़िल्टरिंग" है। इसका उद्देश्य निष्पादन योग्य फ़ाइल के संपीड़न अनुपात में सुधार करना है।

इसके अलावा, यह जानना कि फ़िल्टरिंग कैसे काम करता है, बहुत कठिन परिस्थितियों में एक विशेषज्ञ समय बचा सकता है। ऐसा कभी-कभी होता है कि एक उचित समय में फ़िल्टरिंग के साथ कोड का एक टुकड़ा प्राप्त करना पूरी तरह से असंभव है, उदाहरण के लिए, जब पॉलीमॉर्फ्स के साथ काम करना या फाइलों के साथ जहां कोड वर्चुअलाइजेशन का उपयोग किया जाता है। फिर यह जानना कि फ़िल्टरिंग कैसे काम करता है, कोड के सटीक मूल टुकड़े के बिना फ़िल्टरिंग कोड लिखने की समस्या को हल करेगा।

आइए जाने ...

यह दस्तावेज़ UPX में "फ़िल्टरिंग" की अवधारणा की व्याख्या करता है। मूल रूप से, फ़िल्टरिंग डेटा प्रीप्रोसेसिंग है जो UPX का उपयोग करके फ़ाइल संपीड़न अनुपात में सुधार कर सकता है।

UPX फिल्टर वर्तमान में एक बहुत विशिष्ट एल्गोरिथ्म पर आधारित विधि का उपयोग करते हैं। यह i386 वास्तुकला निष्पादन के लिए अच्छी तरह से अनुकूल है। UPX में, इसे "भोली" कार्यान्वयन के रूप में जाना जाता है। एक "चतुर" विधि भी है, जो केवल 32-बिट निष्पादन योग्य फ़ाइलों के लिए उपयुक्त है और पहली बार यूपीएक्स में लागू की गई थी।

आइए एक उदाहरण लेते हैं और एक कोड टुकड़े पर विचार करते हैं (यह 32-बिट फ़ाइल से एक जगह है):

00025970: E877410600 calln FatalError 00025975: 8B414C mov eax,[ecx+4C] 00025978: 85C0 test eax,eax 0002597A: 7419 je file:00025995 0002597C: 85F6 test esi,esi 0002597E: 7504 jne file:00025984 00025980: 89C6 mov esi,eax 00025982: EB11 jmps file:00025995 00025984: 39C6 cmp esi,eax 00025986: 740D je file:00025995 00025988: 83C4F4 add (d) esp,F4 0002598B: 68A0A91608 push 0816A9A0 00025990: E857410600 calln FatalError 00025995: FF45F4 inc [ebp-0C]

ऊपर दिए गए कोड स्निपेट में, आप दो कॉल स्टेटमेंट को नोटिस कर सकते हैं, जिससे "FatalError" हो सकता है। शायद आपने अनुमान लगाया था कि कंप्रेसर इंजन दोहराए जाने वाले लाइनों के अधिक अनुक्रम पाए जाने पर संपीड़न अनुपात बेहतर होगा। हमारे मामले में, इंजन में अनुक्रम के दो बाइट्स हैं:

 E877 410600 8B and E857 410600 FF.

इसलिए, यह 3-बाइट मैच पा सकता है।

अब तरकीब लागू करें। I386 आर्किटेक्चर के लिए, "निकट कॉल" को 0xE8 के रूप में एन्कोड किया गया है, इसके बाद संक्रमण पते पर 32-बिट सापेक्ष ऑफसेट होता है। अब देखते हैं कि कॉल पोजीशन का मान ऑफ़सेट मान में जोड़ा जाए तो क्या होता है:

 0x64177 + 0x25970 = 0x89AE7 0x64157 + 0x25990 = 0x89AE7 E8 E79A0800 8B E8 E79A0800 FF

अब कंप्रेसर इंजन में 5-बाइट मैच मिलते हैं। यह हमें संपीड़ित डेटा के 2 बाइट्स को बचाने के लिए अनुमति देता है। बुरा नहीं है।

यह भोली कार्यान्वयन विधि का मुख्य विचार है। आपको बस इतना करना है कि विघटन के बाद संपीड़न और अनफ़िल्टर से पहले फ़िल्टर विधि का उपयोग करें। बस 0xE8 बाइट्स प्राप्त करके मेमोरी पर जाएं और अगले 4 बाइट्स को ऊपर बताए अनुसार प्रोसेस करें।

बेशक, ऐसी कई संभावनाएं हैं जहां इस योजना को बेहतर बनाया जा सकता है। सबसे पहले, न केवल कॉल को संसाधित किया जा सकता है, बल्कि जेएमपीएस (0xE9 + 32-बिट ऑफसेट) के पास भी इसी तरह काम करता है।

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

यदि आप 32-बिट ऑफसेट के बाइट क्रम को बदलते हैं तो एक और सुधार होगा। क्यों? यहाँ एक और कॉल है जो ऊपर दिए गए स्निपेट में है:

 000261FA: E8C9390600 calln ErrorF 0x639C9 + 0x261FA = 0x89BC3 E8 C39B 0800   E8 E79A 0800

आप देख सकते हैं कि ये दोनों फ़ंक्शन एक-दूसरे के काफी करीब हैं, हालांकि, कंप्रेसर इस जानकारी का उपयोग करने में सक्षम नहीं है (2-बाइट मैच आमतौर पर उपयोग नहीं किए जाते हैं) यदि आप बाइट ऑफ़सेट बंद करते हैं। इस मामले में:

 E8 0008 9AE7 E8 0008 9BC3

इस प्रकार, कंप्रेसर इंजन भी ऐसे 3-बाइट मैचों की तलाश में है। यह एक अच्छा सुधार है, अब "इंजन" भी पास के विस्थापन के मैचों का उपयोग करता है।

यह ठीक है, लेकिन क्या होता है जब हम 'नकली' कॉल पाते हैं? दूसरे शब्दों में, एक 0xE8 जो दूसरे निर्देश का हिस्सा है? उदाहरण के लिए, यह:

 0002A3B1: C745 E8 00000000 mov [ebp-18],00000000

फिर, इस मामले में, इन अद्भुत 0x00 बाइट्स को कुछ कम संकुचित डेटा द्वारा अधिलेखित किया जाता है। यह एक असुविधाजनक भोली कार्यान्वयन है।

आइए होशियार हो जाएं और केवल "वैध" कॉल का पता लगाने और संसाधित करने का प्रयास करें। UPX इन CALLs को खोजने के लिए एक सरल विधि का उपयोग करता है। हम सिर्फ इन कॉलों के गंतव्य पते की जाँच एक निश्चित क्षेत्र के अंदर करते हैं जैसे CALLs स्वयं (इसलिए, उपरोक्त कोड गलत है, लेकिन यह सामान्य रूप से मदद करता है)। सबसे अच्छी विधि कोड जुदा होगी, हम मदद करने में प्रसन्न होंगे :)

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

UPX निम्नलिखित विचार का उपयोग करता है, जो अच्छी तरह से काम करता है। सबसे पहले, हम मानते हैं कि फ़िल्टर किए जाने वाले क्षेत्र का आकार 16 एमबी से कम है। UPX फिर इस क्षेत्र को स्कैन करता है और 0xE8 बाइट्स का पालन करने वाले बाइट्स को संग्रहीत करता है। यदि हम भाग्यशाली हैं, तो बाइट्स होंगे जो अगले 0xE8 का पालन नहीं करते हैं। ये बाइट्स मार्कर के रूप में उपयोग के लिए हमारे उम्मीदवार हैं।

याद रखें कि हमने मान लिया था कि स्कैन क्षेत्र का आकार 16 एमबी से कम था? खैर, इसका मतलब है कि हम एक वास्तविक कॉल का प्रसंस्करण कर रहे हैं, परिणामस्वरूप, ऑफसेट भी 0x00FFFFFF से कम होगा। इसलिए, MSB हमेशा 0x00 होता है। हमारे मार्कर को संग्रहीत करने के लिए एक शानदार जगह क्या है। बेशक, हम प्राप्त ऑफसेट पर बाइट क्रम को उलट देंगे, इसलिए यह मार्कर केवल 0xE8 बाइट्स के बाद दिखाई देगा और इसके बाद 4 बाइट्स में नहीं।

वह सब है! बस मेमोरी क्षेत्र के साथ काम करें, "वास्तविक" कॉल की पहचान करें और उन्हें चिह्नित करने के लिए इस पद्धति का उपयोग करें। उसके बाद, फ़िल्टरिंग कार्य बहुत सरल है, बस 0xE8 + मार्कर अनुक्रम की खोज करें और यदि यह पाया जाता है तो फ़िल्टर करें। यह स्मार्ट है, है ना? :)

सच में, यह यूपीएक्स में इतना आसान नहीं है। एक अतिरिक्त पैरामीटर ("add_value") का उपयोग किया जा सकता है, जो चीजों को थोड़ा अधिक जटिल बनाता है (उदाहरण के लिए, एक मार्कर अनुपयोगी पाया जा सकता है, क्योंकि इसके अलावा कुछ अतिप्रवाह के कारण)।

और एक पूरे के रूप में एल्गोरिथ्म फ़िल्टरिंग में आसानी के लिए अनुकूलित है (जितना संभव हो उतना कम और तेजी से इकट्ठा किया जाता है, स्टब / मैक्रोज़.श देखें), जो फ़िल्टरिंग प्रक्रिया को कम जटिल बनाता है (fcto_ml.ch, fcto_ml2 .ch, filteri.cpp)।

जैसा कि यह फ़िल्टरी.कैप में देखा जा सकता है, इन फ़िल्टरिंग कार्यान्वयन के लिए कई विकल्प हैं: - देशी / चतुर, कॉल / कूद / कॉल और कूदता है, ऑफसेट रोटेशन के साथ या बिना - कुल में, कुल 18 अलग-अलग फ़िल्टर हैं (और 16 के लिए 9 विकल्प) -बिट प्रोग्राम)।

आप कमांड लाइन पैरामीटर "--filter =" का उपयोग करके उनमें से एक का चयन कर सकते हैं या उनमें से अधिकांश "--all-filter" आज़मा सकते हैं। या यूपीएक्स को निष्पादन योग्य प्रारूपों के लिए निर्धारित डिफ़ॉल्ट में से एक का उपयोग करने दें।

अनुवादक से:
मैं अपनी व्यक्तिगत संदेश सूची पर बग रिपोर्ट की खुशी से समीक्षा करूंगा:
* अनुवाद, वर्तनी या व्याकरण से संबंधित;
* अनुवाद की तकनीकी प्रकृति, सुनिश्चित करें कि मूल में सब कुछ सही है!

यूपीएक्स में उपयोग किए जाने वाले संपीड़न अनुपात में सुधार

More articles: