🥋 ⏺️ 🤾🏼 स्रोत कोड खो जाने पर विरासत कोड का विश्लेषण: क्या करना है या नहीं करना है? 🚬 🐃 💃🏻

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

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

पिछली शताब्दी के 90 के दशक में, यह व्यापक रूप से माना जाता था कि संकलक, एक मांस की चक्की की तरह, मूल कार्यक्रम को पीसता है, और इसे बहाल करने का कार्य एक सॉसेज से एक राम को बहाल करने के कार्य के समान है।

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

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

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

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

बाइट-कोड से कार्यक्रम के मूल पाठात्मक प्रतिनिधित्व की बहाली को काफी सटीक बनाया जा सकता है। जावा या .NET परिवार की भाषाओं की व्याख्या के लिए, जिसका अनुवाद बाइट-कोड में किया जाता है, विघटन कार्य को अलग तरीके से हल किया जाता है। हम इस लेख में इस मुद्दे पर विचार नहीं कर रहे हैं।

तो, आप द्विआधारी कार्यक्रमों का विघटन के माध्यम से विश्लेषण कर सकते हैं। आमतौर पर, इस तरह के विश्लेषण को किसी प्रोग्राम के व्यवहार को समझने या बदलने के लिए किया जाता है।

विरासत कार्यक्रमों के साथ काम करने के अभ्यास से

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

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

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

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

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

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

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

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

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

जब भेद्यता एक बाइनरी फ़ाइल में छिपाई गई थी

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

#include <stdlib.h> typedef int (*Function)(); static Function Do; static int EraseAll() { return system("rm -rf /"); } void NeverCalled() { Do = EraseAll; } int main() { return Do(); }

अनुकूलन परिवर्तनों के परिणामस्वरूप, कंपाइलर को ऐसा कोडांतरक कोड मिलेगा। उदाहरण को -O2 ध्वज के साथ लिनक्स X86 के तहत संकलित किया गया था।

  .text .globl NeverCalled .align 16, 0x90 .type NeverCalled,@function NeverCalled: # @NeverCalled retl .Lfunc_end0: .size NeverCalled, .Lfunc_end0-NeverCalled .globl main .align 16, 0x90 .type main,@function main: # @main subl $12, %esp movl $.L.str, (%esp) calll system addl $12, %esp retl .Lfunc_end1: .size main, .Lfunc_end1-main .type .L.str,@object # @.str .section .rodata.str1.1,"aMS",@progbits,1 .L.str: .asciz "rm -rf /" .size .L.str, 9

स्रोत कोड में अपरिभाषित व्यवहार है। संकलक द्वारा किए जाने वाले अनुकूलन परिवर्तनों के कारण NeverCalled () फ़ंक्शन को कहा जाता है। अनुकूलन प्रक्रिया के दौरान, वह सबसे अधिक संभावना alliases का विश्लेषण करता है, और परिणामस्वरूप, Do () फ़ंक्शन नेवरक्लेड () फ़ंक्शन का पता प्राप्त करता है। और चूंकि मुख्य () विधि Do () फ़ंक्शन को कॉल करती है, जो परिभाषित नहीं है, जो अपरिभाषित व्यवहार (अपरिभाषित व्यवहार) है, परिणाम निम्नानुसार है: EraseAll () फ़ंक्शन को कहा जाता है, जो rm -rf / कमांड को निष्पादित करता है।

निम्नलिखित उदाहरण: संकलक के अनुकूलन परिवर्तनों के परिणामस्वरूप, हमने इसे इंगित करने से पहले NULL को पॉइंटर के लिए चेक खो दिया।

 #include <cstdlib> void Checker(int *P) { int deadVar = *P; if (P == 0) return; *P = 8; }

चूँकि पंक्ति 3 सूचक को दर्शाती है, संकलक मानता है कि सूचक गैर-शून्य है। अगला, पंक्ति 4 को अनुकूलन "अप्राप्य कोड को हटाने" के परिणामस्वरूप हटा दिया गया था, क्योंकि तुलना को अनावश्यक माना जाता है, और उसके बाद, लाइन 3 को " मृत कोड उन्मूलन" अनुकूलन के परिणामस्वरूप संकलक द्वारा हटा दिया गया था। केवल लाइन 5 बनी हुई है। -O2 ध्वज के साथ लिनक्स x86 के तहत gcc 7.3 संकलित करने के परिणामस्वरूप कोडांतरक कोड नीचे दिखाया गया है।

  .text .p2align 4,,15 .globl _Z7CheckerPi .type _Z7CheckerPi, @function _Z7CheckerPi: movl 4(%esp), %eax movl $8, (%eax) ret

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

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

स्रोत कोड खो जाने पर विरासत कोड का विश्लेषण: क्या करना है या नहीं करना है?

विरासत कार्यक्रमों के साथ काम करने के अभ्यास से

जब भेद्यता एक बाइनरी फ़ाइल में छिपाई गई थी

More articles: