🚸 🐋 🤹🏿 ब्लैक बॉक्स पर हमला। वर्चुअलाइज्ड और उत्परिवर्तित कोड की रिवर्स इंजीनियरिंग ☦️ 👨🏼‍🎨 ✍🏾

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

0x00। कोड सुरक्षा तंत्र का विश्लेषण

शुरू करने के लिए, आइए उन तकनीकों को परिभाषित करें जिन्हें हम शोध करेंगे:

1. उत्परिवर्तन एक कोड ऑबफ्यूजन विधि है जिसमें मूल प्रोग्राम एल्गोरिथ्म का उल्लंघन किए बिना, नियंत्रण निर्देशों के मूल ग्राफ को अतिरिक्त निर्देशों, शाखाओं, कचरा निर्देशों, चक्रों द्वारा पूरक द्वारा तोड़ दिया जाता है। अक्सर, स्रोत निर्देशों को अन्य निर्देशों के सबसेट में बदल दिया जाता है जो समान कार्य करते हैं।

2. वर्चुअलाइजेशन एक कोड ऑबफ्यूजन विधि है जिसमें एल्गोरिथ्म के मूल निर्देशों को रक्षक द्वारा उत्पन्न वर्चुअल मशीन के निर्देशों में अनुवादित किया जाता है। मूल एल्गोरिथ्म के स्थान पर, कोड को एम्बेडेड किया जाता है, जो रन टाइम पर, वर्चुअल मशीन में प्रवेश करने के लिए मध्यवर्ती निर्देशों को पारित करता है जो उन्हें व्याख्या करता है।

दोनों विधियां निष्पादन योग्य कोड के स्थिर और गतिशील विश्लेषण दोनों को जटिल करती हैं और अक्सर रक्षक तरीकों के संयोजन की अनुमति देते हैं।

बाद में लेख में मैं दो संरक्षकों के मुफ्त डेमो संस्करणों पर विचार करूंगा: VMProtect , Safengine , वे आपको उत्परिवर्तन के दोनों तरीकों को म्यूट करने, आभासी करने और गठबंधन करने की अनुमति देते हैं।

म्यूटेशन और कोड वर्चुअलाइजेशन तकनीकों को लागू करने के लिए, संरक्षक निम्नलिखित तरीके प्रदान करते हैं:

1. विशेष मार्कर (एसडीके) के माध्यम से विकास के स्तर पर

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

int main () { VMProtectMutate("Critical_code_mut"); ... // critical code here VMProtectEnd(); return 0; }

VMProtect मार्कर के साथ स्रोत कोड को चिह्नित करने का एक उदाहरण

2. डिबग फ़ाइलों के माध्यम से सुरक्षा के स्तर पर

सीधे चलने की स्थापना के दौरान, डिबग फाइल्स (पीडीबी, मैप) को पढ़ा जाता है और उनके आधार पर एप्लिकेशन ऑब्जेक्ट्स का मैप निर्धारित किया जाता है। इसके बाद, डेवलपर चुनता है कि कौन से कार्य को संरक्षित करना है और कैसे, जिसके बाद वे पूरी तरह से कोड से बाहर हो जाते हैं और संसाधित होते हैं।

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

निष्पादन योग्य फ़ंक्शन कोड शून्य परीक्षण की सरलीकृत उत्परिवर्तन योजना () {प्रिंटफ ("हैलो"); }

0x01। रक्षक के फायदे और नुकसान

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

समान रूप से महत्वपूर्ण एंटी-डिबगिंग, एंटीपैचिंग, एंटी-हुकिंग, म्यूटेशन आदि की विभिन्न तकनीकों का संयोजन है। साथ में, यह सब विश्लेषण प्रक्रियाओं की जटिलता की ओर जाता है, लेकिन उन्हें रोक नहीं पाता है।

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

यहाँ एक आदिम फ़ंक्शन का पता लगाने का एक उदाहरण दिया गया है:

 void test() { printf("This is protected message #1\n"); printf("This is protected message #2\n"); }

उत्परिवर्तन से पहले:

ट्रेस लॉग

  मुख्य 00405A2A कॉल 004059F0 ESP = 0018FEE0
 मुख्य 004059F0 PUSH EBP ESP = 0018FEDC
 मुख्य 004059F1 MOV EBP, ESP EBP = 0018FEDC
 मुख्य 004059F3 SUB ESP, 40 ESP = 0018FE9C
 मुख्य 004059F6 PUSH EBX ESP = 0018FE98
 मुख्य 004059F7 PUSH ESI ESP = 0018FE94
 मुख्य 004059F8 PUSH EDI ESP = 0018FE90
 मुख्य 004059F9 PUSH OFFSET 0040ED10 ESP = 0018FE8C
 मुख्य 004059FE कॉल DWORD PTR DS: [<और MSVCR100D.printf>] EAX = 00000012, ECX = 84CB6CA9, EDX = 7418F4B8
 मुख्य 00405A04 ADD ESP, 4 ESP = 0018FE90
 मुख्य 00405A07 PUSH OFFSET 0040ECF8 ESP = 0018FE8C
 मुख्य 00405A0C कॉल DWORD PTR DS: [<और MSVCR100D.printf>] E4 = 00000014
 मुख्य 00405A12 ADD ESP, 4 ESP = 0018FE90
 मुख्य 00405A15 POP EDI ESP = 0018FE94
 मुख्य 00405A16 पॉप ईएसआई ESP = 0018FE98
 मुख्य 00405A17 POP EBX ESP = 0018FE9C
 मुख्य 00405A18 MOV ESP, EBP ESP = 0018FEDC
 मुख्य 00405A1A POP EBP ESP = 0018FEE0, EBP = 0018FF30
 मुख्य 00405A1B RETN ESP = 0018FEE4

सफेंगी रक्षक द्वारा उत्परिवर्तन के बाद:

ट्रेस लॉग

  मुख्य 00405A2A कॉल 004059F0 ESP = 0018FEE0
 मुख्य 004059F0 JMP 004C9C6A
 मुख्य 004C9C6A JMP 004C8391
 मुख्य 004C8391 कॉल 004C82D6 ESP = 0018FEDC
 मुख्य 004C82D6 LEA ESP, [ESP + 2] ESP = 0018FEDE
 मुख्य 004C82DA LEA ESP, [ESP + 2] ESP = 0018FEE0
 मुख्य 004C82DE PUSH EBP ESP = 0018FEDC
 मुख्य 004C82DF NEG BP EBP = 001800D0
 मुख्य 004C82E2 JMP 004C812E
 मुख्य 004C812E MOV EBP, ESP EBP = 0018FEDC
 मुख्य 004C8130 एसटीसी
 मुख्य 004C8131 SUB ESP, 40 ESP = 0018FE9C
 मुख्य 004C8134 कॉल 004C8006 ESP = 0018FE98
 मुख्य 004C8006 JMP SHORT 004C7F96
 मुख्य 004C7F96 LEA ESP, [ESP + 4] ESP = 0018FE9C
 मुख्य 004C7F9A PUSH EBX ESP = 0018FE98
 मुख्य 004C7F9B कॉल 004C7F80 ESP = 0018FE94
 मुख्य 004C7F80 LEA ESP, [ESP + 4] ESP = 0018FE98
 मुख्य 004C7F84 PUSH ESI ESP = 0018FE94
 मुख्य 004C7F85 JMP SHORT 004C7FB6
 मुख्य 004C7FB6 PUSH EDI ESP = 0018FE90
 मुख्य 004C7FB7 PUSH 0040ED10 ESP = 0018FE8C
 मुख्य 004C7FBC कॉल DWORD PTR DS: [40E19C] EAX = 00000012, ECX = 93D2AD8F, EDX = 7418F4B8
 मुख्य 004C7FC2 JMP SHORT 004C7FA0
 मुख्य 004C7FA0 STC
 मुख्य 004C7FA1 JMP SHORT 004C7FDA
 मुख्य 004C7FDA ADD ESP, 4 ESP = 0018FE90
 मुख्य 004C7FDD कॉल 004C7FC4 ESP = 0018FE8C
 मुख्य 004C7FC4 LEA ESP, [ESP + 4] ESP = 0018FE90
 मुख्य 004C7FC8 PUSH 0040ECF8 ESP = 0018FE8C
 मुख्य 004C7FCD कॉल 004C7FE2 ESP = 0018FE88
 मुख्य 004C7FE2 MOV BYTE PTR SS: [ESP], CH
 मुख्य 004C7FE5 JMP SHORT 004C7FEB
 मुख्य 004C7FEB LEA ESP, [ESP + 4] ESP = 0018FE8C
 मुख्य 004C7FEF CALL DWORD PTR DS: [40E19C] EAX = 00000014
 मुख्य 004C7FF5 SETPE BH EBX = 7EFD0100
 मुख्य 004C7FF8 XCHG BL, BH EBX = 7EFD0001
 मुख्य 004C7FFA INC EBX EBX = 7EFD0002
 मुख्य 004C7FFB JMP SHORT 004C805A
 मुख्य 004C805A ADD ESP, 4 ESP = 0018FE90
 मुख्य 004C805D POP EDI ESP = 0018FE94
 मुख्य 004C805E MOV ESI, 4B536EDD ESI = 4B536EDD
 मुख्य 004C8063 MOV SI, WORD PTR SS: [ESP] ESI = 4B530000
 मुख्य 004C8067 JMP SHORT 004C801E
 मुख्य 004C801E LEA EBX, [CDDFCA2F] EBX = CDDFCA2F
 मुख्य 004C8024 POP ईएसआई ESP = 0018FE98, ESI = 00000000
 मुख्य 004C8025 CALL 004C8008 ESP = 0018FE94
 मुख्य 004C8008 पॉप वर्ड PTR एसएस: [ESP] ESP = 0018FE96
 मुख्य 004C800C MOV BX, WORD PTR SS: [ESP + 1] EBX = CDDF0000
 मुख्य 004C8011 XCHG BYTE PTR SS: [ESP], BL EBX = CDDF004C
 मुख्य 004C8014 JMP SHORT 004C8040
 मुख्य 004C8040 LEA ESP, [ESP + 2] ESP = 0018FE98
 मुख्य 004C8044 POP EBX EBX = 7EFDE000, ESP = 0018FE9C
 मुख्य 004C8045 JMP SHORT 004C802A
 मुख्य 004C802A MOV ESP, EBP ESP = 0018FEDC
 मुख्य 004C802C LEA EBP, [EDI + EAX] EBP = 00000014
 मुख्य 004C802F MOV BP, 3200 EBP = 00003200
 मुख्य 004C8033 MOV EBP, CEF73787 EBP = CEF73787
 मुख्य 004C8038 JMP 004C80ED
 मुख्य 004C80ED POP EBP ESP = 0018FEE0, EBP = 0018FF30
 मुख्य 004C80EE RETN ESP = 0018FEE4
 -------- लॉगिंग बंद हो गई

उपरोक्त उदाहरण में, कोड म्यूटेशन जटिलता के सबसे छोटे स्तर पर किया जाता है। Safengine आपको इस जटिलता को 254 गुना तक बढ़ाने की अनुमति देता है, जो अंत में आपके कोड को 10 निर्देशों से कचरा सेट में फुला सकता है जो स्रोत कार्यक्रम के आकार को एक-दो बार से अधिक कर देता है, जो काफी बेमानी है।

इसके अलावा एक नुकसान को कार्यक्रम भ्रष्टाचार के मामलों के लिए जिम्मेदार ठहराया जा सकता है, जो दुर्भाग्य से मेरी स्मृति में हुआ था। यह एक बात है अगर ऐसी विफलताएं एक नियमित कार्यक्रम में होती हैं, जो दुर्घटना का कारण बनेगी, और चालक में दुर्घटना होने पर पूरी तरह से अलग, जो पूरी तरह से अस्वीकार्य है। जैसा कि आप जानते हैं, संरक्षक विभिन्न निष्पादन योग्य वस्तुओं (जैसे, डीएल, ओएक्सएक्स, एसआईएस) को संसाधित कर सकते हैं।

विपणन नीति भी कभी-कभी वांछित होने के लिए बहुत कुछ छोड़ देती है। सुरक्षा का भ्रम पैदा करने वाले ग्राहकों के कानों में तकनीकी कचरा अच्छा नहीं है। वास्तव में, चलने वाले डेवलपर्स अपने उत्पादों के विवरण में नहीं लिखते हैं कि यह तकनीक अच्छी है, लेकिन इसमें इस तरह के दोष हैं।

0x02। अपूर्ण कोड सुरक्षा की समस्या

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

  कच्चा आभासी नाम
 ------------------------------------
 00000000 00400000 पीई हेडर
 00000200 00401000 कोड क्षेत्र
 00000400 00402000 डेटा क्षेत्र
 00000600 00403000 संसाधन क्षेत्र

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

  कच्चा आभासी नाम
 ------------------------------------
 00000000 00400000 पीई हेडर
 00000200 00401000 कोड क्षेत्र
 00000400 00402000 डेटा क्षेत्र
 00000600 00403000 रक्षक क्षेत्र
 00000800 00404000 संसाधन क्षेत्र

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

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

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

0x03। ब्लैक बॉक्स मछुआरे

ब्लैक बॉक्स की खोज के लिए एक विशिष्ट उपकरण एक अनुरेखक है। हालाँकि, मोटे कोड का मार्ग 80-99% कचरा है, इसलिए हमें किसी भी तरह इस कचरे से केवल उपयोगी जानकारी प्राप्त करने की आवश्यकता है। यह प्रक्रिया कुछ हद तक मछली पकड़ने की याद दिलाती है। कल्पना कीजिए कि मार्ग एक झील है, ट्रेसर मछली पकड़ने की छड़ी है, और इस चारा का पता लगाने के लिए शर्तें हैं। संरक्षक के उपरोक्त नुकसान का उपयोग करते हुए, हम सही चारा चुन सकते हैं और सही जानकारी पकड़ सकते हैं। आइए देखें कि यह व्यवहार में कैसा दिखता है।

मान लें कि हमारे पास निम्नलिखित कार्यक्रम हैं:

 void array_fill(unsigned char *buf, size_t size) { for (int i = 0; i < size; i++) { buf[i] = i; if (i > 0) { buf[i] ^= buf[i - 1]; } } } int main() { unsigned char buf[10]; array_fill(buf, sizeof(buf)); return 0; }

म्युटेशन और वर्चुअलाइजेशन दोनों को array_fill () फंक्शन पर सुपरइम्पोज़ किया जाए। आइए array_fill () फ़ंक्शन पर कॉल का पता लगाएँ:

चरणों की प्रारंभिक संख्या: 230

ओफिसकेशन VMProtect के बाद चरणों की संख्या: 83924

बधिया सफेंगी के बाद चरणों की संख्या: 250382

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

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

ट्रेस लॉग

  मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7700, ECX = 0018FF34
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7701, ECX = 0018FF35
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF34
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF35
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7701, ECX = 0018FF35
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7702, ECX = 0018FF36
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF35
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF36
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7703, ECX = 0018FF36
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7703, ECX = 0018FF37
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF36
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF37
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7700, ECX = 0018FF37
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7704, ECX = 0018FF38
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF37
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF38
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7704, ECX = 0018FF38
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7705, ECX = 0018FF39
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF38
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF39
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7701, ECX = 0018FF39
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7706, ECX = 0018FF3A
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF39
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF3A
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7707, ECX = 0018FF3A
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7707, ECX = 0018FF3B
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF3A
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF3B
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7700, ECX = 0018FF3B
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7708, ECX = 0018FF3C
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF3B
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF3C
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7708, ECX = 0018FF3C
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7709, ECX = 0018FF3D
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF3C
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF3D

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

और इसलिए, यदि आप ट्रैक को करीब से देखते हैं, तो एक चक्र दिखाई देता है (यह बार-बार कॉल से 004B7898 पर कोड से स्पष्ट होता है):

  ;  1 स्टेप
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7700, ECX = 0018FF34
 ;  2 कदम
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7701, ECX = 0018FF35
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF34
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF35
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7701, ECX = 0018FF35
 ;  3 कदम
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7702, ECX = 0018FF36
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF35
 मुख्य 004B7A8E MOV AL, BYTE PTR DS: [ECX] EAX = 004B7A89, ECX = 0018FF36
 मुख्य 004B7898 MOV BYTE PTR DS: [ECX], AL EAX = 004B7703, ECX = 0018FF36
 ...

और केवल 10 ऐसे चरण हैं, जो हमारे बफर के आकार से मेल खाते हैं। इसके अलावा, सब कुछ काफी सरल है, यह जानते हुए कि कौन से मूल्य लिए गए हैं और जिन्हें वापस रखा गया है, हमारे काम का एल्गोरिथ्म हमारी हथेली में है। यहां अनुमान लगाने के लिए एकमात्र चीज एक्सओआर ऑपरेशन का उपयोग है, लेकिन इस मामले में यह बिल्कुल मुश्किल नहीं है।

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

0x04। नेस्टेड कॉल विश्लेषण

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

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

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

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

खाका प्रस्ताव समारोह

यही है, जब एक मोटे कोड (ट्रेड सेक्शन) से एप्लिकेशन कोड सेक्शन पर कंट्रोल लौटाते हैं, तो हम प्रस्तावित प्रस्तावना से पहले स्थित Int3, Retn निर्देशों की जांच कर सकते हैं और पूर्व-तैयार हस्ताक्षरों के साथ प्रोलॉग को सत्यापित भी कर सकते हैं। यह हमेशा मदद नहीं करेगा, क्योंकि संकलक कोड में कुछ भी रटना कर सकता है, खासकर अनुकूलन के बाद, लेकिन यह कुछ भी नहीं से अधिक है।

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

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

0x05। ग्राफ़ रिकवरी चलाएँ

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

यदि आपके पास इस मामले में कोई ज्ञान और अनुभव है, तो यदि आप टिप्पणियों में एक-दो लिंक डालेंगे तो मैं आभारी रहूंगा।

0x06। निष्कर्ष

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

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

अंत में, यदि आप obfuscated कोड को उलटने के अपने कौशल का परीक्षण करना चाहते हैं, तो मैं इस खुर को हल करने का प्रस्ताव करता हूं ।

आपका ध्यान देने के लिए धन्यवाद।

ब्लैक बॉक्स पर हमला। वर्चुअलाइज्ड और उत्परिवर्तित कोड की रिवर्स इंजीनियरिंग

0x00। कोड सुरक्षा तंत्र का विश्लेषण

0x01। रक्षक के फायदे और नुकसान

0x02। अपूर्ण कोड सुरक्षा की समस्या

0x03। ब्लैक बॉक्स मछुआरे

0x04। नेस्टेड कॉल विश्लेषण

0x05। ग्राफ़ रिकवरी चलाएँ

0x06। निष्कर्ष

More articles: