👨🏿‍💻 🤦🏿 🤓 प्रबल भविष्यवाणी करता है 💆🏻 📣 🎍

यहां हम कंप्यूटर सुरक्षा के कुछ पहलुओं के बारे में बात करेंगे, जो प्रोग्राम कोड के औचित्य से संबंधित हैं। यही कारण है कि मैं .NET अनुप्रयोगों के obfuscator के विकास के संबंध में रुचि रखता था - .NET कोड को हैकिंग से बचाने के लिए एक कार्यक्रम। एक और अंधेरा पक्ष है: वायरस और अन्य खराब चीजों के डेवलपर्स कोड में बहुत रुचि रखते हैं, लेकिन वे हमारे लिए दिलचस्प नहीं हैं।

एम्युलेटर्स

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

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

if ((x+x & 1) == 0) good_code else

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

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

आदर्श अंतर्निहित विधेय जनरेटर

हम तैयार करते हैं कि अंतर्निहित विधेयकों के आदर्श सुपर जनरेटर की तरह क्या दिखना चाहिए। यह P, X1, x2, ..., xn के आधार पर P (X1, x2, ..., xn) की भविष्यवाणी करता है, और यह जेनरेटर उपयोगकर्ता की इच्छा के आधार पर पहचान के अनुसार सही और हमेशा सही भविष्यवाणी नहीं कर सकता है। और जनरेटर में निम्नलिखित शानदार विशेषताएं हैं:

विधेय लंबाई से रैखिक समय में उत्पन्न होता है;
एक नियमित कार्यक्रम (चुपके) से एक सामान्य स्थिति के लिए एक विधेय बहुत समान है;
वहाँ मौजूद नहीं है और मौजूद नहीं हो सकता (!) एक एल्गोरिथ्म जो यह निर्धारित करेगा कि विधेय हमारे जनरेटर द्वारा उत्पन्न किया गया था;
वहाँ मौजूद नहीं है और मौजूद नहीं हो सकता (!) एक एल्गोरिथ्म, जो उत्पन्न विधेय पर आधारित है, हमेशा यह निर्धारित कर सकता है कि क्या यह सच है या इनपुट पैरामीटर हैं, जिस पर यह गलत है;
कोई भी संभाव्य एल्गोरिथ्म नहीं है जो कम से कम 80% मामलों में सही तरीके से निर्धारित करेगा (आंकड़ा वैज्ञानिक प्रहार की विधि द्वारा पाया गया था) क्या जनरेटर द्वारा बनाई गई विधेय पहचान सही है।

अब हमें यह समझने की आवश्यकता है कि क्या ऐसा कम से कम सैद्धांतिक रूप से संभव है।

बिंदु 4 संभव प्रतीत होता है । आपको याद दिला दूं कि डायोफैंटाइन समीकरण फॉर्म f (X1, x2, ..., xn) = 0 का एक समीकरण है, जहां f पूर्णांक गुणांक वाले एक बहुपद है, और x एक गैर-नकारात्मक पूर्णांक है। कंप्यूटर विज्ञान के सिद्धांत का फिर से जिक्र करते हुए, हम याद करते हैं कि मौजूद नहीं है और एक एल्गोरिथ्म मौजूद नहीं हो सकता है, जो किसी भी डायोफैंटीन समीकरण द्वारा निर्धारित करेगा कि इसका कोई समाधान है या नहीं। विशेष रूप से, फर्मेट के महान प्रमेय द्वारा, डायोफैंटाइन समीकरण (x + 1) * (x + 1) * (x + 1) + (y + 1) * (y + 1) * (y + 1) - (z + 1) ) * (z + 1) * (z + 1) = 0 का कोई हल नहीं है। ऐसा लग रहा था: यह वह जगह है जहाँ खुदाई करने के लिए! लेकिन जल्दी मत करो। डायोफैंटाइन समीकरण 0 से 4 बिलियन के मानों के साथ सम्स और उत्पादों के एक सेट पर नहीं है, लेकिन 0 से अनन्त तक के मानों के साथ पूर्णांक के योग और उत्पादों का एक सेट है। आपको तथाकथित "लंबे अंकगणित" का उपयोग करके उन्हें लिखना होगा और वे कोड में बहुत अजीब लगेंगे।

बिंदु 2 सभी को परेशान करता है । सहज ज्ञान युक्त गुप्त से हमारा तात्पर्य एक ऐसे विधेय से है जो वास्तविक की भीड़ में खड़ा नहीं होता है, "निहित" वास्तविक कार्यक्रमों से भविष्यवाणी करता है। स्मार्ट लोगों ने पहले से ही कई विशिष्ट अनुप्रयोगों का विश्लेषण किया है और पाया है कि उनमें से अधिकांश विधेय काफी सीधे हैं: x == 0, x == y, x> 0, आदि, जहां x, y अंतर चर हैं (ऊपर के दूसरे भाग में) लेख के ठीक ऊपर के चतुर लोग ठेठ जावा कार्यक्रमों की स्थितियों का विश्लेषण करते हैं)। किसी को यह समझने के लिए लंबे समय तक अनुमान लगाने की ज़रूरत नहीं है कि चोरी की स्थिति विधेय के लिए बहुत महत्वपूर्ण है। वास्तव में, एक हैकर बस सभी "अजीब" की भविष्यवाणी कर सकता है और किसी तरह उन्हें अलग कर सकता है या उन्हें पूरी तरह से हटा भी सकता है, जिसकी हमें बिल्कुल आवश्यकता नहीं है।

बिंदु 2 के कारण बिंदु 4 संभव नहीं है ... हालांकि । इसलिए, यदि विधेय अंकगणित है और यह "छिपा हुआ" है, तो इसमें सबसे अधिक संभावना केवल अंकगणित के साथ अंकगणित शामिल है, जिसका अर्थ है कि एक एल्गोरिथ्म है जो यह जांच करेगा कि क्या विधेय हमेशा सत्य होता है: यह उन सभी मूल्यों के माध्यम से है जो विधेय में हैं। लेकिन यह बुरा नहीं है, क्योंकि सबसे अच्छे मामले में, विधेय के विश्लेषण के लिए आपको 4 बिलियन मानों को छांटना होगा! और अगर विधेय में दो चर हैं? इसलिए हम, अच्छे विवेक में, यह मानते हुए कि पी <एनपी, जनरेटर की चौथी विशेषता को कमजोर करते हैं: इस तथ्य को प्रकट करने का कार्य कि जनरेटर द्वारा बनाई गई विधेय हमेशा सही होती है, एनपी-पूर्ण होनी चाहिए। बेशक, अगर यह पता चला कि पी = एनपी, तो यह भी शायद ही एक विकल्प है, लेकिन अभी तक आप शांति से सो सकते हैं। यहाँ मैंने 3-SAT को याद किया - प्रसिद्ध एनपी-पूर्ण कार्य जिसे स्वयं भगवान ने इस क्षण में याद करने का आदेश दिया था। लेकिन इस मार्ग के साथ प्राप्त विधेय शायद ही छिपे कहे जा सकते हैं।

हम सन्नाटे में 1, 3 और 5 से अधिक अंकों से गुजरते हैं - एक छोटे लेख के लिए एक प्रश्न भी पतला।

कार्यक्रम का निष्पादन ग्राफ

अंकगणितीय विधेय से हमारा मतलब है कि हम प्रपत्र f (X1, ..., xn) <g (X1, ... xn) या f (X1, ..., xn) = g (X1, ..., xn) की पूर्वसूचनाओं का अनुमान लगाते हैं, जहां Xs प्रकार के int हैं, और एफ और जी साधारण अंकगणितीय अभिव्यक्ति हैं। एक विधेय आवश्यक रूप से अंकगणित क्यों होना चाहिए? नहीं, मुझे नहीं करना चाहिए और मैं यह भी नहीं कहता कि नीचे दिए गए पाठ में मैं आपको समझा सकता हूं कि मुझे करना चाहिए। फिर भी, मैं ऐसे कारण दूंगा जो मुझे इस विचार की ओर ले गए कि अंकगणित की भविष्यवाणी सबसे वास्तविक है।

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

क्या एक अंकगणितीय विधेय निहित है (जो कि हमेशा सत्य होता है)? यह एक एनपी-पूर्ण समस्या है। यह सूचक प्रोग्राम में दिए गए बिंदु पर क्या इंगित करता है? यह एक बेकार समस्या है, अर्थात, इस तरह की समस्या को हल करने के लिए कोई सामान्य एल्गोरिथ्म नहीं है, जैसा कि शटडाउन समस्या के मामले में है। यह ठीक है: एनपी-पूर्ण की तुलना में अघुलनशील बेहतर है। अंतर्निहित विधेय के निर्माण के लिए एक विधि का निम्नलिखित विचार ऊपर उद्धृत दूसरे लेख (Collberg, Clark, Low) से चमकाया गया है।

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

एक अस्पष्ट कार्यक्रम में, हम स्मृति में एक बेतहाशा जटिल संरचना बनाते हैं जिसमें एक चार-बाइट संख्या और इस संख्या के लिए एक सूचक होता है। P को एक पॉइंटर होने दें। मान लीजिए कि ग्राफ के बाएं खींचे गए टुकड़े के प्रवेश द्वार पर (* p) यह होने की गारंटी है। ग्राफ निम्नानुसार संशोधित किया गया है:

यदि पहले यह स्पष्ट था कि * p == 1 मुश्किल हो सकता है, तो अब आप अतिरिक्त रूप से इस टुकड़े पर एक गलत धारणा बना सकते हैं, जो कभी-कभी आकृति के बाईं ओर * p == 7 है।

यह एक अच्छी विधि है और अंकगणितीय विधेय से बेहतर है। लेकिन एक बड़ा BUT है: वास्तव में, एक हैकर की तरह, हम निष्पादन ग्राफ को नहीं जानते हैं। यह सब डराने वाला प्रतिबिंब, कॉलबैक / प्रतिनिधि और कोड निष्पादित करने के अन्य अप्रत्याशित तरीके हैं। और यदि कोड मेमोरी में उत्पन्न होता है? हां, यह भी होता है और विशेष रूप से .NET में। हालाँकि, हम निष्पादन ग्राफ को स्थानीय रूप से जानते हैं। .NET में, कम से कम, आप प्रत्येक विशेष विधि के भीतर कोड निष्पादन के एक ग्राफ के बारे में सुनिश्चित कर सकते हैं। लेकिन यदि आप प्रत्येक विधि में स्मृति में एक निश्चित संरचना के निर्माण और निर्माण को सम्मिलित करते हैं, तो यह गुप्त होने की संभावना नहीं है। यह इस तरह से गोपनीयता, या इसके अभाव के कारण हमें इस पद्धति का उपयोग करने से रोकता है।

अंतर्निहित विधेय के निर्माण की अन्य विधियाँ हैं, लेकिन उनमें से सभी (जिन्हें मैंने अपने कान के कोने से सुना है) पूरे कार्यक्रम के निष्पादन ग्राफ से बंधी हुई हैं और एक विधि के संदर्भ में भारी दिखती हैं। अंकगणितीय विधेय एक और मामला है।

कार्यान्वयन

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

नीचे हमारे निहित विधेय जनरेटर के कुछ परिणाम दिए गए हैं। विधेय की सूची के आरंभिक, मध्य और अंत के अंश (3000 टुकड़े; ग के रूप में संचालन की प्राथमिकता # ~; * /%; + -; ""; &? ^;;; सभी अंतर चर):

  ~x != x (x + x & 1) == 0 (x + -x & 1) == 0 ~x != x * 4u >> 2 (-x & 1) == (x & 1) ((-x ^ x) & 1) == 0 (x * 0x80 & 0x56) == 0 (x << 1 ^ 0x1765) != 0 ~(-x * 0x40) != x << 6 (~(x * 0x80) & 0x3d) == 0x3d x - 0x9d227fa9 != x - 0x699c945e (y ^ y - 0x35f5f4d2) != 0x42a26409 (x * 0x20000000 & 0x19a27923) == 0 (int)(y * 9u + y * 0xf7u >> 3) >= 0 (x * 4 & 8) == (x + x * 3 - 0x1fef9d8f & 8) (x | 0xffffdbe8) - 0x1baa != x || (x & 0x10) == 0x10 (x ^ 0x1145f) != 0 || (x | 0xfffeffff) == 0xffffffff (uint)x / 0x59d7e3 != 0x90298cf9 || (x * 3 + x & 3) == 0 ((uint)x % 0x38 + 0xe4df62c8 & 0x6d755e00) == 0x64554200 (x ^ 0x770363c6) != 0 || ((uint)x >> 0x19 ^ 0x926797eb) != 0 (uint)y / 0x2369af8 - 0x78400000 != (uint)x / 0x1f2ce * 0x10 (x & 0x8e3ef800) != 0x70641deb && (uint)x / 0x9388ea != 0x3ab6921c

दिमित्री कोसोलोबोव, Appfuscator डेवलपर द्वारा पोस्ट किया गया।

प्रबल भविष्यवाणी करता है

एम्युलेटर्स

आदर्श अंतर्निहित विधेय जनरेटर

कार्यक्रम का निष्पादन ग्राफ

कार्यान्वयन

More articles: