👩🏽‍🤝‍👨🏾 🚱 🎛️ "और असंभव संभव है": हम बाइनरी विश्लेषण का उपयोग करके एक ब्लैक बॉक्स को सफेद रंग में बदलते हैं 👩🏽‍🤝‍👨🏻 👲 🤖

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

चलो दूर से

McAfee एंटीवायरस कंपनी के अनुसार, 2017 में साइबर क्राइम से वैश्विक क्षति लगभग 600 बिलियन डॉलर थी, जो कि वैश्विक जीडीपी के 0.8% के बराबर है। हम सूचना प्रौद्योगिकी के युग में रहते हैं, जिसकी विशिष्टता मानव गतिविधि के सभी क्षेत्रों में वैश्विक नेटवर्क और इंटरनेट प्रौद्योगिकियों का तेजी से एकीकरण है। अब साइबर अपराध सामान्य से बाहर नहीं हैं। आंकड़े साइबर अपराध में तेजी से वृद्धि दिखाते हैं।

अनुप्रयोगों की भेद्यता एक गंभीर समस्या में बदल गई है: यूएस डिपार्टमेंट ऑफ होमलैंड सिक्योरिटी के अनुसार, अनुप्रयोगों में विभिन्न कमजोरियों का उपयोग करके 90% से अधिक सफल साइबर हमले लागू होते हैं। सबसे प्रसिद्ध भेद्यता शोषण के तरीके हैं:

एसक्यूएल इंजेक्शन
बफर अतिप्रवाह
क्रॉसिंग स्क्रिप्टिंग
असुरक्षित कॉन्फ़िगरेशन का उपयोग करना।

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

स्थैतिक कोड विश्लेषण (स्टेटिक एप्लीकेशन सिक्योरिटी टेस्टिंग);
डायनामिक कोड विश्लेषण (डायनामिक एप्लिकेशन सिक्योरिटी टेस्टिंग)।

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

गतिशील विश्लेषण ("ब्लैक बॉक्स" विधि) इसके निष्पादन के दौरान एक कार्यक्रम की जांच है। निम्नलिखित तरीकों को इस दृष्टिकोण से अलग किया जा सकता है।

चूँकि कमजोरियाँ निष्पादन योग्य कार्यक्रम में होती हैं, और इसके संचालन का उपयोग करके त्रुटि का पता लगाया जाता है, झूठी सकारात्मक की पीढ़ी स्थैतिक विश्लेषण की तुलना में कम है।
विश्लेषण करने के लिए कोई स्रोत कोड की आवश्यकता नहीं है।

लेकिन इसके नुकसान भी हैं।

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

स्टेटिक विश्लेषण ("व्हाइट बॉक्स" विधि) एक प्रकार का प्रोग्राम परीक्षण है जिसमें कार्यक्रम निष्पादित नहीं होता है।

हम लाभ सूचीबद्ध करते हैं।

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

विधि का एकमात्र दोष झूठी सकारात्मकता की उपस्थिति है: मूल्यांकन करने की आवश्यकता है कि क्या विश्लेषक एक वास्तविक त्रुटि को इंगित करता है, या यह संभावना है कि यह गलत सकारात्मक है।

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

बाइनरी विश्लेषण या निष्पादन योग्य फ़ाइल विश्लेषण तकनीक

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

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

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

शर्तों के बारे में थोड़ा सा

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

इस लेख में, हम जावा बाइटकोड विश्लेषण को भी द्विआधारी विश्लेषण कहते हैं, हालांकि यह पूरी तरह से सही नहीं है। हम पाठ को सरल बनाने के लिए ऐसा करते हैं। बेशक, बाइनरी सी / सी ++ कोड और ऑब्जेक्टिव-सी / स्विफ्ट का विश्लेषण करने की तुलना में जेवीएम बायटेकोड का विश्लेषण करने का कार्य सरल है। लेकिन सामान्य विश्लेषण योजना बाइटकोड और बाइनरी कोड के मामले में समान है। लेख में वर्णित मुख्य कठिनाइयाँ विशेष रूप से बाइनरी कोड के विश्लेषण से संबंधित हैं।

अपघटन बाइनरी कोड से स्रोत कोड को पुनर्प्राप्त करने की प्रक्रिया है। आप रिवर्स ट्रांसलेशन के तत्वों के बारे में बात कर सकते हैं - असंतुष्ट (द्विआधारी छवि से कोडांतरक कोड प्राप्त करना), कोडांतरक को तीन-पता कोड या अन्य प्रतिनिधित्व में अनुवाद करना, स्रोत कोड स्तर के निर्माणों को पुनर्स्थापित करना।

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

परिणाम कैसे देखें?

चलो अंत से थोड़ा शुरू करते हैं, लेकिन बाइनरी विश्लेषण के परिणामों को देखने का सवाल आमतौर पर पहले पूछा जाता है।

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

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

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

परिणाम प्रदर्शित करने के बारे में हमसे पूछा गया मुख्य प्रश्न यह है कि क्या विघटित कोड भेद्यता को समझने और स्थानीय बनाने के लिए पर्याप्त है।

नीचे इस विषय पर कुछ विचार दिए गए हैं।

अगर हम JVM bytecode के बारे में बात कर रहे हैं, तो सामान्य तौर पर इसका उत्तर "हाँ" है - बायटेकोड के लिए विघटन की गुणवत्ता बढ़िया है। लगभग हमेशा आप यह पता लगा सकते हैं कि भेद्यता क्या है।
भेद्यता के गुणात्मक स्थानीयकरण के साथ जो हस्तक्षेप कर सकता है, वह है एक साधारण अवरोधन जैसे कि कक्षा के नाम और कार्यों का नाम बदलना। हालांकि, व्यवहार में यह अक्सर पता चलता है कि भेद्यता को समझने के लिए यह निर्धारित करना अधिक महत्वपूर्ण है कि यह किस फ़ाइल में है। स्थानीयकरण की आवश्यकता तब होती है जब कोई भेद्यता को ठीक कर सकता है, लेकिन इस मामले में, डेवलपर यह भी समझ जाएगा कि विघटन विघटन कोड से कहां है।
जब हम बाइनरी कोड के विश्लेषण के बारे में बात करते हैं (उदाहरण के लिए, C ++), निश्चित रूप से, सब कुछ बहुत अधिक जटिल है। कोई उपकरण नहीं है जो पूरी तरह से यादृच्छिक सी ++ कोड को पुनर्प्राप्त करता है। हालांकि, हमारे मामले की ख़ासियत यह है कि हमें बाद में कोड संकलित करने की आवश्यकता नहीं है: भेद्यता को समझने के लिए हमें गुणवत्ता की पर्याप्त आवश्यकता है।
सबसे अधिक बार, आप पाए गए भेद्यता को समझने के लिए पर्याप्त विघटन गुणवत्ता प्राप्त कर सकते हैं। ऐसा करने के लिए, आपको कई कठिन समस्याओं को हल करने की आवश्यकता है, लेकिन आप उन्हें हल कर सकते हैं (नीचे हम संक्षेप में इसके बारे में बात करेंगे)।
C / C ++ के लिए, भेद्यता को स्थानीय बनाना और भी मुश्किल है - संकलन प्रक्रिया के दौरान पात्रों के नाम कई तरह से खो जाते हैं, आप उन्हें पुनर्स्थापित नहीं कर सकते।
ऑब्जेक्टिव-सी में स्थिति थोड़ी बेहतर है - वहां फ़ंक्शन नाम हैं, और भेद्यता को स्थानीय बनाना आसान है।
मोटापे के मुद्दे अलग खड़े हैं। कई जटिल परिवर्तन हैं जो कमजोरियों के विघटन और मानचित्रण को जटिल कर सकते हैं। व्यवहार में, यह पता चलता है कि एक अच्छा डीकॉम्पिलर अधिकांश भ्रामक रूपांतरणों को संभाल सकता है (याद रखें कि भेद्यता को समझने के लिए हमें पर्याप्त कोड गुणवत्ता की आवश्यकता है)।

निष्कर्ष के रूप में - सबसे अधिक बार यह भेद्यता दिखाने के लिए निकलता है ताकि इसे समझा और सत्यापित किया जा सके।

बाइनरी विश्लेषण की जटिलताएं और विवरण

यहां हम बायटेकोड के बारे में बात नहीं करेंगे: इसके बारे में सभी दिलचस्प बातें पहले ही ऊपर बताई जा चुकी हैं। सबसे दिलचस्प बात असली बाइनरी कोड का विश्लेषण है। यहाँ हम एक उदाहरण के रूप में C / C ++, Objective-C और Swift के विश्लेषण के बारे में बात करेंगे।

असहमति होने पर भी महत्वपूर्ण कठिनाइयाँ उत्पन्न होती हैं। सबसे महत्वपूर्ण चरण बाइनरी छवि का उपप्रोग्राम में विभाजन है। अगला, एक तकनीकी मामला - सबरूटीन्स में कोडांतरक निर्देशों का चयन करें। हमने इस बारे में विस्तार से एक लेख "साइबरस्पेस नं। 1 (14) - 2016" के लिए एक लेख में लिखा है, यहां हम संक्षेप में वर्णन करेंगे।

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

उपप्रोग्राम के शुरुआती पते को निर्धारित करने की समस्या को हल करने के लिए सबसे आम दो तरीके हैं। पहली विधि में, सबप्रोग्राम के पते मानक प्रोलॉग द्वारा निर्धारित किए जाते हैं (x86 आर्किटेक्चर के लिए यह ईबीपी है; मूव एबप, एस्प)। दूसरी विधि में, कोड के एक खंड को पुनः प्रविष्टि प्रविष्टि से उप-कॉल कॉल निर्देशों की मान्यता के साथ ट्रेस किया जाता है। शाखा निर्देशों को मान्यता देकर बाईपास किया जाता है। वर्णित विधियों के संयोजन का उपयोग तब भी किया जाता है जब एक पुनरावर्ती ट्रावेल को प्रोलॉग द्वारा शुरू किए गए पते से शुरू किया जाता है।

व्यवहार में, यह पता चलता है कि ऐसे दृष्टिकोण मान्यता प्राप्त कोड का काफी कम प्रतिशत देते हैं, क्योंकि सभी कार्यों में मानक प्रस्तावना नहीं होती है, और अप्रत्यक्ष कॉल और संक्रमण होते हैं।

निम्नलिखित एल्गोरिदम द्वारा बुनियादी एल्गोरिदम में सुधार किया जा सकता है।

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

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

आगे क्या है

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

फिर बहुत सारी दिलचस्प बातें होती हैं। मुख्य कार्यों के बारे में संक्षेप में कहें। हमने विस्तार से बात नहीं की: या तो पता है, जिसके बारे में हम स्पष्ट रूप से यहाँ नहीं लिख सकते हैं, या बहुत दिलचस्प तकनीकी और इंजीनियरिंग समाधान विवरण में नहीं हैं।

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

निष्कर्ष

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

यह लेख एंटोन प्रोकोफिअव, सोलर ऐपस्क्रिनर विश्लेषक के सहयोग से लिखा गया था