फर्मवेयर का रहस्य

लेखक: पीएच.डी. चेर्नोव ए.वी. ( महाशय_चर ) और पीएच.डी. ट्रोशिना के.एन.

आधुनिक प्रोसेसर आर्किटेक्चर के ज्ञान के आधार पर सबसे सामान्य मान्यताओं का उपयोग करते हुए, क्या आप किसी अज्ञात वास्तुकला की द्विआधारी छवि से प्रोग्राम संरचना को पुनर्स्थापित कर सकते हैं, और फिर एल्गोरिदम को पुनर्स्थापित कर सकते हैं और बहुत कुछ?

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

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

डिवाइस फर्मवेयर के एक द्विआधारी विश्लेषण में निम्नलिखित उद्देश्य हो सकते हैं:

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

ऊपर प्रस्तुत बाइनरी कोड विश्लेषण कार्य को डिवाइस संगतता सुनिश्चित करने के लिए बाइनरी विश्लेषण कार्य का एक विशेष मामला माना जा सकता है।

द्विआधारी फ़ाइल प्रारूप का विश्लेषण

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

काम की शुरुआत में, हमारे लिए स्थिति इस प्रकार थी: हमें फर्मवेयर के साथ एक निश्चित फ़ाइल बिना किसी दस्तावेज के मिली। फर्मवेयर फ़ाइल के प्रारूप के बारे में कोई जानकारी नहीं थी, न ही माइक्रोकंट्रोलर की वास्तुकला के बारे में।

फर्मवेयर फ़ाइल एक पाठ फ़ाइल बन गई। इसमें निम्न फ़ॉर्म की पंक्तियाँ थीं:

:04013000260F970CF8 :10020000004D000B043F000B34AD010C002FFE4D30 :02023000FD0BC1 :1004000018001A0000001E0008005E000200190052 

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

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



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

सभी प्रोसेसर समान हैं।

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

नीचे हम आधुनिक माइक्रोप्रोसेसरों के लिए बुनियादी सिद्धांतों को सूचीबद्ध करते हैं।

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

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

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

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

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

स्टैक का उपयोग करके सबरूटीन कॉल का नेस्टिंग आयोजित किया जा सकता है, जिसका उपयोग अभी भी सबरटीन को तर्क पारित करने और स्थानीय चर को स्टोर करने के लिए किया जा सकता है, लेकिन वास्तुकला के विकास के वर्तमान स्तर पर यह जानकारी समय से पहले है।

बाइनरी कोड के प्रारंभिक विश्लेषण के लिए इन सिद्धांतों को कैसे लागू किया जा सकता है?

हम बुनियादी धारणा बनाते हैं कि प्रोसेसर कमांड सिस्टम में एक आरईटी निर्देश (एक सबरूटीन से वापसी) है। इस निर्देश में कुछ प्रकार के निश्चित द्विआधारी प्रतिनिधित्व हैं, जिन्हें हम देखेंगे। यदि RET केवल एक ही नहीं है, जैसा कि x86 में है, जहां RET का एक तर्क है - सबरूटीन पैरामीटर क्षेत्र का आकार, या यदि RET अधिक जटिल ऑपरेशन का एक साइड इफेक्ट है, जैसा कि ARMv7 में है, जहां पीसी मान को अन्य रजिस्टरों (ldmfd sp) के मान के साथ स्टैक से एक साथ लाया जा सकता है! , {fp, pc}), तो, सबसे अधिक संभावना है, हमारी अनुमानी खोज परिणाम नहीं देगी।

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

• बाइट्स की एक धारा जिसमें से निर्देश उत्पन्न होते हैं, और विभिन्न निर्देश बाइट्स की एक अलग संख्या के साथ एन्कोड किए जाते हैं। इस श्रेणी में, सबसे प्रसिद्ध प्रतिनिधि x86 परिवार है, पहले 8080 प्रोसेसर से लेकर सबसे आधुनिक 64-बिट प्रोसेसर। एक x86_64 प्रोसेसर निर्देश को 1 से 16 बाइट्स के अनुक्रम में एन्कोड किया जा सकता है। चर निर्देश लंबाई वाले प्रोसेसर के एक ही परिवार में 8051 शामिल हैं, जो कि माइक्रोकंट्रोलर में उपयोग किया जाता है।
• 16-बिट मानों की एक धारा। इसके अलावा, प्रत्येक निर्देश का एक निश्चित आकार होता है - 16 बिट्स।
• 16-बिट मानों की एक धारा, जबकि निर्देश आकार में परिवर्तनशील होते हैं। इस परिवार के प्रतिनिधियों में से एक पीडीपी -11 वास्तुकला है, जिसमें कमान पहले 16 बिट्स पर कब्जा कर लेता है, और इसके बाद प्रत्यक्ष पते के लिए या तो सीधे मान या स्मृति पते का पालन किया जा सकता है। इसमें ARM आर्किटेक्चर में THUMB कोडिंग शामिल है।
• 32-बिट मानों की एक धारा, प्रत्येक निर्देश में 32 बिट्स का एक निश्चित आकार होता है। ये 32- और 64-बिट RISC प्रोसेसर के अधिकांश हैं: ARMv7, ARMv8, MIPS।

एक चर-लंबाई वाली बाइट स्ट्रीम और शब्दों की 16-बिट स्ट्रीम के बीच चयन करने से मेमोरी इमेज को "आंख से" देखने में मदद मिलेगी। कोई फर्क नहीं पड़ता कि कैसे प्रोसेसर निर्देश एन्कोड किए गए हैं, पर्याप्त लंबाई के एक कार्यक्रम में वे अनिवार्य रूप से दोहराए जाएंगे। उदाहरण के लिए, x86 निर्देश पर

 add %ebx,%eax 

जो ईएक्स और ईबेक्स रजिस्टर के मूल्यों को जोड़ता है और ईईएक्स में परिणाम डालता है, दो बाइट्स में एन्कोडेड है:

 01 d8. 

ARMv7 निर्देश पर

 add r0, r0, r1 

जो रजिस्टरों के मानों को r0 और r1 में जोड़ता है और परिणाम को r0 में डालता है, को 32-बिट मान e0800001 द्वारा एन्कोड किया जाता है।

पर्याप्त रूप से बड़े कार्यक्रम में, ऐसे निर्देशों को एक से अधिक बार दोहराया जाएगा। यदि हमारे लिए बाइट्स का एक क्रम (उदाहरण के लिए, 01 डी 8) एक अनियंत्रित पते पर होता है, तो हम मान सकते हैं कि प्रोसेसर निर्देश चर आकार के बाइट्स की एक धारा द्वारा एन्कोड किए गए हैं। यदि मान, उदाहरण के लिए, e0800001 केवल 4 के गुणकों के पते पर पाया जाता है, तो हम प्रोसेसर निर्देशों के एक निश्चित आकार के बारे में एक धारणा बना सकते हैं। बेशक, यहाँ एक गलती है कि हमने एक निर्देश के लिए डेटा बाइट्स लिया, या ऐसा संयोग से हुआ कि कुछ निर्देश हमेशा संरेखित हो गए। हालांकि, पर्याप्त आकार के कार्यक्रम पर इस तरह के "शोर" का प्रभाव छोटा होगा।

जब हमने इस कोण से विश्लेषण किए गए फर्मवेयर को देखा, तो यह स्पष्ट हो गया कि सबसे अधिक संभावना है कि प्रश्न में प्रोसेसर के निर्देश 16-बिट मानों के साथ एन्कोड किए गए हैं।

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

  (hex)   0b01 854 5.1% 0800 473 2.8% 8c0d 432 2.6% 2b00 401 2.4% 4e1c 365 2.2% 0801 277 1.6% 

हम इन 16-बिट मूल्यों के बीच आरईटी निर्देश की खोज करेंगे जो कोड में सबसे अधिक बार सामना करते हैं। तुरंत हम कॉल निर्देश के लिए देखेंगे - आरईटी निर्देश के लिए जोड़ा गया। CALL निर्देश में कम से कम एक पैरामीटर है - जंप एड्रेस, इसलिए निश्चित मान अपरिहार्य हैं।

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

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

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

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

उपरोक्त सभी बातों को ध्यान में रखते हुए, हम बाइनरी कोड में CALL / RET जोड़ी की खोज के लिए निम्न गणना स्थान प्राप्त करते हैं।

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

• बिग-एंडियन और लिटिल-एंडियन शब्द बाइट ऑर्डर
• निर्देश में नियमित पते का पूर्ण और सापेक्ष कोडिंग।

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

ऊपर वर्णित खोज स्थान में प्रत्येक विकल्प के लिए, हम आंकड़ों की गणना करते हैं:

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

यदि CALL / RET निर्देशों की एक जोड़ी के बारे में हमारी धारणा सही है, तो इसे वर्णित गणना स्थान में होना चाहिए। लेकिन झूठी सकारात्मकता भी हो सकती है। खैर, हम खोज शुरू करते हैं।

और हम केवल एक ही संभव विकल्प पाते हैं!

 Trying 8c0d as RET After-ret-addr-set-size: 430 Matching call opcodes for 1, ff00ff00, 1: 000b003d: total: 1275, hits: 843 (66%), misses: 432 (33%), coverage: 76% 

तो, 16-बिट शब्द 8c0d आरईटी अनुदेश के लिए एक उम्मीदवार के रूप में उपयुक्त है। कुल मिलाकर, फर्मवेयर में इस निर्देश के तुरंत बाद प्रोग्राम पतों की 430 स्थिति होती है। हमने 32-बिट मान (एक पंक्ति में दो 16-बिट शब्द) पर, एफएफ 00 एफएफ 00 के एक एड्रेस मास्क मूल्य के साथ, कोड 00 0 बी 00 3 डी के साथ एक निर्देश पाया था। 1275 ऐसे निर्देश हैं, जिनमें से 843 (यानी 66%) आरईटी के लिए उम्मीदवार के तुरंत बाद बिंदु पर नियंत्रण स्थानांतरित करते हैं। इस प्रकार, दो निर्देशों की पहचान की गई है:

• RET: 8c0d (16-बिट लिटिल-एंडियन)
• कॉल एचएचएलएल: 0 बीएचएच 3 डीएलएल (2 16-बिट लिटिल-एंडियन)

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

जारी रखने के लिए ...

आगे हम बताएंगे कि सशर्त और बिना शर्त संक्रमण और कुछ अंकगणित और तार्किक संचालन कैसे बहाल किए गए थे।