हम आईडीए प्रो के लिए NIOS II प्रोसेसर मॉड्यूल विकसित कर रहे हैं

आईडीए प्रो Disassembler इंटरफ़ेस स्क्रीनशॉट

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

आज मैं इस परियोजना के इतिहास के बारे में बताऊंगा और दिखाऊंगा कि अंत में क्या हुआ।

प्रागितिहास

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

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

• निर्देश और संचालन पार्स करना,
• उनका सरलीकरण और प्रदर्शन,
• ऑफ़सेट, क्रॉस-रेफरेंस और साथ ही साथ कोड और डेटा बनाना, जिसका वे संदर्भ देते हैं
• प्रसंस्करण स्विच निर्माण,
• स्टैक और स्टैक चर के साथ जोड़तोड़ को संभालना।

उस समय लगभग ऐसी कार्यक्षमता लागू की गई थी। सौभाग्य से, उपकरण एक अन्य कार्य पर काम करने की प्रक्रिया में उपयोगी था, जिसके दौरान, एक साल बाद, इसे सक्रिय रूप से उपयोग और परिष्कृत किया गया था।

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

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

NIOS II सॉफ्टवेयर मॉडल

NIOS II एक सॉफ्टवेयर प्रोसेसर है जिसे Altera FPGAs (अब इंटेल का हिस्सा) के लिए विकसित किया गया है। कार्यक्रमों के दृष्टिकोण से, इसमें निम्नलिखित विशेषताएं हैं: थोड़ा एंडियन का बाइट ऑर्डर, 32-बिट एड्रेस स्पेस, 32-बिट इंस्ट्रक्शन सेट, यानी 4 बाइट्स, 32 सामान्य और 32 विशेष-उद्देश्य रजिस्टर प्रत्येक कमांड को एन्कोड करने के लिए उपयोग किया जाता है।

Disassembly और कोड संदर्भ

इसलिए, हमने NIA II प्रोसेसर के लिए फर्मवेयर के साथ आईडीए प्रो में एक नई फ़ाइल खोली। मॉड्यूल को स्थापित करने के बाद, हम इसे आईडीए प्रो प्रोसेसर की सूची में देखेंगे। प्रोसेसर का विकल्प आंकड़ा में दिखाया गया है।



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



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



जैसा कि उदाहरण से देखा जा सकता है, नियंत्रण हस्तांतरण आदेशों से क्रॉस-रेफरेंस भी उत्पन्न होते हैं (इस मामले में, आप सशर्त कूद और प्रक्रिया कॉल देख सकते हैं)।

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



यहां, यदि आपने पहली बार आपके लिए एक नई वास्तुकला के कोडांतरक कोड का सामना किया, तो टिप्पणियों का उपयोग करके आप समझ सकते हैं कि क्या हो रहा है। इसके अलावा, कोड उदाहरण उसी रूप में होंगे - टिप्पणियों के साथ, ताकि NIOS II मैनुअल को न देखें, लेकिन कोड अनुभाग में क्या हो रहा है, यह समझने के लिए कि उदाहरण के रूप में दिया गया है।

छद्म निर्देश और आदेशों का सरलीकरण

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

• जब स्रोतों में से एक शून्य (r0) है और विचार से हटाया जा सकता है,
• जब टीम का ऋणात्मक मान होता है और टीम को इसके विपरीत बदल दिया जाता है,
• जब हालत उलट हो,
• जब 32-बिट ऑफसेट को दो टीमों में भागों (सबसे कम उम्र और सबसे पुराने) में दर्ज किया जाता है और इसे एक कमांड द्वारा बदल दिया जाता है।

पहले दो प्रकार लागू किए गए थे, क्योंकि स्थिति को बदलने से कुछ विशेष नहीं होता है, और 32-बिट ऑफ़सेट में मैनुअल में प्रस्तुत किए जाने की तुलना में अधिक विकल्प हैं।

उदाहरण के लिए, पहले दृश्य के लिए, कोड पर विचार करें।



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

छद्म निर्देशों के प्रसंस्करण को लागू करने के बाद, हमें कोड का एक ही खंड मिलता है, लेकिन अब यह अधिक पठनीय दिखता है, और इसके बजाय या के भिन्नरूपों को जोड़ते हैं और हमें कमांड के रूपांतर मिलते हैं।

स्टैक चर

NIOS II आर्किटेक्चर स्टैक का समर्थन करता है, और स्टैक पॉइंटर सपा के अलावा, fp स्टैक फ्रेम के लिए एक पॉइंटर भी है। एक छोटी सी प्रक्रिया के एक उदाहरण पर विचार करें जो स्टैक का उपयोग करता है।



जाहिर है, स्टैक पर स्थानीय चर के लिए स्थान आरक्षित है। यह माना जा सकता है कि रजिस्टर रा को स्टैक चर में संग्रहीत किया गया है और फिर इसे से बहाल किया गया है।

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



अब कोड थोड़ा साफ दिखता है, और आप पहले से ही स्टैक चर का नाम दे सकते हैं और क्रॉस-रेफरेंस का पालन करके अपने उद्देश्य को पार कर सकते हैं। उदाहरण में फ़ंक्शन __fastcall प्रकार का है और रजिस्टरों r4 और r5 में इसके तर्क स्टैक पर एक उपप्रकारक को कॉल करने के लिए धकेल दिए जाते हैं जो कि _stdcall का है।

32-बिट संख्या और ऑफसेट

NIOS II की ख़ासियत यह है कि एक ऑपरेशन में, अर्थात, जब एक ही कमांड को निष्पादित किया जाता है, तो आकार में 2 बाइट्स (16 बिट्स) के अधिकांश प्रत्यक्ष मूल्य पर पंजीकरण करना संभव है। दूसरी ओर, प्रोसेसर रजिस्टरों और एड्रेस स्पेस 32-बिट हैं, अर्थात्, पते के लिए, 4 बाइट्स को रजिस्टर में दर्ज किया जाना चाहिए।

इस समस्या को हल करने के लिए, दो-भाग के विस्थापन का उपयोग किया जाता है। पावरपीसी में प्रोसेसर में एक समान तंत्र का उपयोग किया जाता है: ऑफसेट में दो भाग होते हैं, सबसे पुराना और सबसे छोटा, और दो कमांड द्वारा रजिस्टर में दर्ज किया जाता है। पावरपीसी में, यह निम्नानुसार है।



इस दृष्टिकोण में, दोनों टीमों से क्रॉस-लिंक बनते हैं, हालांकि वास्तव में, पता दूसरी कमांड में कॉन्फ़िगर किया गया है। क्रॉस-रेफरेंस की संख्या गिनते समय यह कभी-कभी उपद्रव हो सकता है।

पुराने भाग के लिए ऑफ़सेट गुण गैर-मानक प्रकार HIGHA16 का उपयोग करते हैं, कभी-कभी टाइप H16 का उपयोग किया जाता है, छोटे भाग के लिए - LOW16।



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

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



इस दृष्टिकोण के साथ, 32-बिट ऑफसेट के निचले हिस्से में प्रवेश करने के लिए केवल कमांड के साथ एक क्रॉस संदर्भ बनता है।

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



NIOS II के लिए कोड में, 32-बिट संख्या को रजिस्टर में दर्ज करने के लिए निम्न तंत्र पाया जाता है। सबसे पहले, ऑफसेट का सबसे पुराना हिस्सा मोही कमांड के साथ रजिस्टर में दर्ज किया गया है। फिर छोटा हिस्सा इसमें शामिल होता है। इसे तीन तरीकों से (आज्ञाओं द्वारा) किया जा सकता है: आदी को जोड़ना, उप को जोड़ना, तार्किक ओरी।

उदाहरण के लिए, कोड के अगले भाग में, रजिस्टरों को 32-बिट संख्याओं पर सेट किया जाता है, जो तब फ़ंक्शन को कॉल करने से पहले रजिस्टरों - तर्कों में दर्ज किया जाता है।



ऑफसेट गणना को जोड़ने के बाद, हमें इस कोड ब्लॉक का निम्नलिखित प्रतिनिधित्व मिलता है।



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

जब छोटे हिस्से में प्रवेश करते हैं तो घटाव का उपयोग किया जाता है। इस उदाहरण में, इस कदम पर अंतिम 32-बिट संख्या (ऑफसेट) निर्धारित करना संभव नहीं होगा।



32-बिट संख्याओं की गणना को लागू करने के बाद, हमें निम्नलिखित फ़ॉर्म मिलते हैं।



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



सेगमेंट बढ़ाने के बाद, हमें पता चलता है कि अब सभी गणना की गई 32-बिट संख्याएं ऑफ़सेट हैं और मान्य पते दर्शाती हैं।

यह ऊपर उल्लेख किया गया था कि एक तार्किक या आदेश का उपयोग होने पर ऑफसेट की गणना करने के लिए एक और विकल्प है। यहां एक उदाहरण कोड दिया गया है जहां दो ऑफसेट की गणना इस तरह से की जाती है।



R8 रजिस्टर में जिस का मूल्यांकन किया जाता है उसे स्टैक पर धकेला जाता है।

रूपांतरण के बाद, यह देखा जा सकता है कि इस मामले में रजिस्टरों को प्रक्रियाओं की शुरुआत के पते से कॉन्फ़िगर किया गया है, अर्थात, प्रक्रिया का पता स्टैक पर धकेल दिया जाता है।

आधार के सापेक्ष पढ़ना और लिखना

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



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

निर्माणों को स्विच करें

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



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

स्विच प्रोसेसिंग जोड़ने के बाद, यह कोड इस तरह दिखेगा।



अब कूदने का संकेत दिया गया है, ऑफ़सेट के साथ तालिका का पता, मामलों की संख्या, साथ ही प्रत्येक मामले को संबंधित संख्या के साथ।

विकल्प के लिए ऑफ़सेट के साथ तालिका स्वयं इस प्रकार है। अंतरिक्ष को बचाने के लिए, पहले पांच तत्व दिए गए हैं।



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

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

कस्टम निर्देश

NIOS II वास्तुकला में एक दिलचस्प विशेषता है - कस्टम निर्देश। यह 256 उपयोगकर्ता-परिभाषित निर्देशों तक पहुंच प्रदान करता है जो NIOS II वास्तुकला में संभव हैं। अपने काम में, सामान्य-उद्देश्य रजिस्टरों के अलावा, कस्टम निर्देश 32 कस्टम-रजिस्टरों के एक विशेष सेट तक पहुंच सकता है। कस्टम कमांड को पार्स करने के लिए तर्क को लागू करने के बाद, हमें निम्नलिखित फ़ॉर्म मिलते हैं।



आप देख सकते हैं कि अंतिम दो निर्देशों में एक ही निर्देश संख्या है और एक ही क्रिया करते हैं।

कस्टम निर्देशों के अनुसार, एक अलग मैनुअल है । उनके अनुसार, कस्टम अनुदेश सेट के लिए सबसे व्यापक और अप-टू-डेट विकल्पों में से एक है NIOS II फ़्लोटिंग पॉइंट हार्डवेयर 2 घटक (FPH2) फ़्लोटिंग पॉइंट के साथ काम करने के लिए निर्देशों का सेट। FPH2 कमांड के पार्सिंग को लागू करने के बाद, उदाहरण इस तरह दिखेगा।



अंतिम दो टीमों के सम्मोहन से, हम यह सुनिश्चित करते हैं कि वे वास्तव में एक ही क्रिया करते हैं - फ़ेड्स कमांड।

रजिस्टर मूल्य द्वारा संक्रमण

जांच के तहत फर्मवेयर में, एक स्थिति अक्सर सामने आती है जब रजिस्टर के मूल्य के अनुसार एक कूद किया जाता है, जिसमें एक 32-बिट ऑफसेट, जो कूद की जगह निर्धारित करता है, पहले दर्ज किया जाता है।

कोड के एक टुकड़े पर विचार करें।



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

जंपर्स की मान्यता कार्यक्षमता जोड़ने के बाद, निम्न प्रपत्र प्राप्त किया जाता है।



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

जीपी रजिस्टर मूल्य (वैश्विक सूचक), सहेजें और लोड करें

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

इस उदाहरण में, प्रोसेसर मॉड्यूल नए डेटाबेस में जीपी रजिस्टर के मूल्य को ढूंढता है और गणना करता है। Idb database को बंद करते समय, gp value को डेटाबेस में स्टोर किया जाता है।



मौजूदा idb डेटाबेस को लोड करते समय और यदि gp मान पहले ही मिल गया है, तो इसे डेटाबेस से लोड किया जाता है, जैसा कि निम्न उदाहरण में डीबग संदेश में दिखाया गया है।

पढ़ना और लिखना जी.पी.

आम संचालन जीपी रजिस्टर के सापेक्ष ऑफसेट के साथ पढ़ और लिख रहे हैं। उदाहरण के लिए, निम्नलिखित उदाहरण में, इस तरह के तीन रीड और एक रिकॉर्ड किए जाते हैं।



चूँकि हमें gp रजिस्टर में संग्रहीत पते का मूल्य पहले ही मिल गया है, इसलिए हम इस तरह के पठन और लेखन को संबोधित कर सकते हैं।

जीपी रजिस्टर के सापेक्ष पढ़ने और लिखने की स्थितियों के लिए प्रसंस्करण को जोड़ने के बाद, हमें एक और अधिक सुविधाजनक तस्वीर मिलती है।



यहां आप देख सकते हैं कि कौन से चर एक्सेस किए जा रहे हैं, उनके उपयोग को ट्रैक करें और उनके उद्देश्य की पहचान करें।

जीपी के सापेक्ष संबोधन

चर को संबोधित करने के लिए gp रजिस्टर का एक और उपयोग है।



उदाहरण के लिए, यहां हम देखते हैं कि रजिस्टर कुछ चर या डेटा क्षेत्रों के लिए जीपी रजिस्टर के सापेक्ष कॉन्फ़िगर किए गए हैं।

ऐसी स्थितियों को पहचानने वाली कार्यक्षमता को जोड़ने के बाद, ऑफ़सेट में कनवर्ट करता है और क्रॉस-रेफरेंस जोड़ता है, हमें निम्नलिखित फ़ॉर्म मिलते हैं।



यहां आप पहले से ही देख सकते हैं कि जीपी रजिस्टरों के सापेक्ष कौन से क्षेत्र कॉन्फ़िगर किए गए हैं, और यह अधिक स्पष्ट हो जाता है कि क्या हो रहा है।

सपा के सापेक्ष संबोधन

इसी तरह, निम्नलिखित उदाहरण में, रजिस्टरों को कुछ मेमोरी क्षेत्रों में बांधा जाता है, इस बार रजिस्टर एसपी के सापेक्ष - स्टैक के लिए सूचक।



जाहिर है, रजिस्टरों को कुछ स्थानीय चरों में बांधा जाता है। ऐसी परिस्थितियां - प्रक्रिया कॉल से पहले स्थानीय बफ़र्स के लिए तर्क सेट करना - पर्याप्त सामान्य हैं।

प्रसंस्करण को जोड़ने के बाद (ऑफसेट के लिए प्रत्यक्ष मूल्यों को परिवर्तित करना), हम निम्नलिखित फॉर्म प्राप्त करते हैं।



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

कोड से संरचना क्षेत्रों तक क्रॉस-संदर्भ

आईडीए प्रो में संरचनाओं को परिभाषित करना और उनका उपयोग करना कोड विश्लेषण की सुविधा प्रदान कर सकता है।



कोड के इस भाग को देखते हुए, हम समझ सकते हैं कि फ़ील्ड field_8 बढ़ रहा है और संभवतः, एक घटना की घटना का एक काउंटर है। यदि पढ़ने और लिखने के क्षेत्रों को एक बड़ी दूरी पर कोड में अलग किया जाता है, तो क्रॉस-रेफ़रिंग मदद कर सकता है।

संरचना पर ही विचार करें।



यद्यपि संरचनाओं के क्षेत्रों तक पहुंच है, जैसा कि हम देखते हैं, कोड से संरचनाओं के तत्वों तक कोई क्रॉस-संदर्भ नहीं हैं।

ऐसी स्थितियों पर कार्रवाई होने के बाद, हमारे मामले के लिए सब कुछ निम्नानुसार होगा।



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

मैनुअल और वास्तविकता के बीच विसंगतियां

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



यहाँ एक फर्मवेयर से इस कमांड का एक उदाहरण है।



एक समान संदर्भ वाली जगह में एक और फर्मवेयर खोलना, हम एक अलग स्थिति का सामना करते हैं।



ये बाइट्स स्वचालित रूप से एक कमांड में नहीं बदले गए, हालांकि सभी कमांड की प्रोसेसिंग है। पर्यावरण, और यहां तक ​​कि एक समान पते को देखते हुए, यह एक ही टीम होनी चाहिए। चलो बाइट्स को ध्यान से देखें। यह एक ही eret कमांड है, इस अपवाद के साथ कि 22-26 बिट्स 0x1E के बराबर नहीं हैं, लेकिन शून्य के बराबर हैं।

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

आईडीए 7 समर्थन

आईडीए 7.0 के साथ शुरू, नियमित स्क्रिप्ट के लिए पायथन आईडीए द्वारा प्रदान की गई एपीआई काफी बदल गई है। प्रोसेसर मॉड्यूल के रूप में, परिवर्तन भारी हैं। इसके बावजूद, NIOS II प्रोसेसर मॉड्यूल संस्करण 7 के लिए रीमेक करने में सक्षम था, और इसमें सफलतापूर्वक काम किया।



एकमात्र अयोग्य क्षण: जब IDA 7 में NIOS II के तहत एक नई बाइनरी फ़ाइल लोड हो रही है, तो IDA 6.9 में मौजूद प्रारंभिक स्वचालित विश्लेषण नहीं होता है।

निष्कर्ष

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

द्वारा पोस्ट किया गया