स्रोत कोड के बिना कार्यक्षमता का विस्तार

मुझे लगता है कि आप में से प्रत्येक को यह महसूस हो रहा था कि किसी विशेष कार्यक्रम में कुछ सुविधाएँ गायब थीं। यदि प्रोग्राम सोर्स कोड के साथ आता है, तो कोई समस्या नहीं है। कोई भी आवश्यक कार्यक्षमता जोड़ सकता है। लेकिन अगर कार्यक्रम बंद हो जाए तो क्या होगा? निराशा न करें, यह एक लापता मामला नहीं है। अब मैं आपको बताता हूं कि आप लेखक के लिए कैसे जोड़ सकते हैं जो गायब है।

पीछे हटना

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

चलिए शुरू करते हैं

पहला सवाल यह है कि अपना कोड कैसे जोड़ें?
दो मुख्य तरीके हैं:

• एक नया अनुभाग जोड़ें, और इसमें अपना सारा कोड डालें।
• Dll में कोड को बाहर निकालें, और फिर प्रोग्राम के खाली स्थान पर एक छोटा कॉल कोड डालें।

अन्य अधिक परिष्कृत विकल्प हैं, लेकिन मैं उन पर विचार नहीं करूंगा।

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

यह बन गया:

और हमारा कोड। पहली कॉल की चाल यह है कि यह एक एकल कमांड है और स्टैक पर लाइन के पते को धक्का देती है, और इसे कूदती है।

00401000 पर Jmp बोरलैंड C से OEP है

प्लगइन लोडिंग योजना आम है:
हम ini से प्लगइन्स के साथ फ़ोल्डर का पथ पढ़ते हैं, अगर यह नहीं है, तो हम डिफ़ॉल्ट पथ लेते हैं और GetFileAttributes के माध्यम से फ़ोल्डर की उपस्थिति की जांच करते हैं। खैर, फिर * .dll मास्क पर, FindFirstFile / FindNextFile का उपयोग करके, हम सभी फाइलों को सूचीबद्ध करते हैं।
हम प्रत्येक को LoadLibrary के माध्यम से लोड करते हैं। और प्लगइन, बदले में, हमारे द्वारा निर्यात किए जाने वाले कार्यों को खींच लेगा। चूंकि संस्करण 1.10 में सभी फ़ंक्शन एक्स से निर्यात किए गए थे, हमें समान ऑर्डिनल्स के साथ एक ही निर्यात तालिका बनाने की आवश्यकता है, ताकि सब कुछ प्लगइन्स के लिए भी पारदर्शी हो। लेकिन उस पर और बाद में।

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

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

और कुछ क्षण बाद:

यहां तक ​​कि बार-बार पुन: विश्लेषण करने से भी मदद नहीं मिलती है, ओल्गा को लगता है कि RegisterClassW के लिए एक कॉल है, हालांकि नीचे दिए गए दोनों क्षेत्रों में आप यह सुनिश्चित कर सकते हैं कि पता 005EEA44 API पते से बहुत दूर है।

इसलिए, हमें पता है कि संदेशों को कहां संसाधित करना है, अब हमें यह बनाने की आवश्यकता है कि क्या प्रक्रिया है। ऐसा करने के लिए, हम AppendMenu को उसी तरह से रोकते हैं। और हैंडलर में, हम एक मेनू को जोड़ने की अपेक्षा करते हैं, जिसके सामने हम अपने मेनू को छड़ी करना चाहते हैं।
जैसे ही यह दिखाई दिया - हमारे पास एक मेनू बनाने के लिए एक विस्तृत विकल्प है। लेकिन अब के लिए, मैंने अपने आप को एकल आइटम प्रदर्शित करने के लिए MF_STRING, पॉप-अप सबमेनस के लिए MF_POPUP, और delimiters के लिए MF_SEPARATOR तक सीमित कर दिया है। सभी मेनू आइटम थोड़ा पुराने InsertMenu के माध्यम से जोड़ा गया। सबसे पहले, कम कोड है, और दूसरी बात, ओलेग (डेवलपर ओलीडबग) खुद इस पद्धति का उपयोग करता है।
अपने लिए और हमारे बाद आने वाली मेनू शाखा के लिए मूल एपेंडेंन्यू एपीआई को कॉल करने के लिए बहुत अंत में मत भूलना।
पूरा जोड़ इस प्रकार संक्षेप में दिखेगा:
OllyDbg से AppendMenu (सहायता) -> हमारे CreateMenu () -> हमारे कई InsertMenu () -> हमारे AppendMenu (प्लगइन्स) -> हम AppendMenu (सहायता) अनुरोध को निष्पादित करते हैं।

एक मेनू बनाते हुए, आपको पहले से यह देखना होगा कि कौन सी आईडी मुफ़्त है और कौन सी नहीं होगी। WndProc में हम मेनू के लिए WM_COMMAND को पकड़ लेंगे। हम केवल हमारा फ़िल्टर करते हैं, और उदाहरण के लिए, ID => processor_address द्वारा एक साहचर्य सरणी का उपयोग करके, हम नियंत्रण को आवश्यक प्लगइन में स्थानांतरित करते हैं।

यह वही है जो मेरे हस्तक्षेप के पहले और बाद में ओलीडबग 2.00 सी संस्करण की खिड़कियां दिखती हैं:


अब सबसे मौलिक प्रश्न उन कार्यों के पते ढूंढना है जिन्हें प्लगइन्स में निर्यात किया जाना चाहिए। अनुप्रयोगों के रिलीज़ संस्करणों में डिबग जानकारी प्राप्त करने की अपेक्षा न करें, जो बहुत मदद कर सकता है।
इसलिए, आइए निम्न तरीके से चलते हैं, Ida Pro में लोड करें:

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

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

मरहम में उड़ना

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

फिलहाल, प्लग-इन प्रबंधक पूरी तरह से खरोंच से C ++ में फिर से लिखा गया है, जिसमें सभी संस्करणों के साथ संगतता की योजना है। और यहाँ कई कार्यों के अवरोधन बंद नहीं होंगे ...

ठीक है, यहाँ आप देख सकते हैं कि एक दिन में घुटने पर भी कोड लिखना आवश्यक नहीं है।
Shoals और इसलिए मुझे पता है, और इसलिए खरोंच से मेल खाती है।
झल्लाहट पर आघात
अद्यतन संस्करण बाद में होगा जब यह समाप्त हो जाएगा।

लेखक ओलीडबग और एक्सेल @ बी फोरम के प्रतिभागियों को उनके सक्रिय समर्थन के लिए, और सुधार के लिए हब्रोस्क लोगों के लिए विशेष धन्यवाद।