😻 🤞🏿 🧙🏾 माच-ओ लाइब्रेरी में फ़ंक्शन पुनर्निर्देशन ⛲️ 👩‍👧 🙎

पिछले लेख में साझा ईएलएफ पुस्तकालयों के लिए एक कॉल पिक विधि का वर्णन किया गया था। अब हम देखेंगे कि माच-ओ- प्रारूप पुस्तकालयों के साथ भी ऐसा ही किया जाएगा।

मैं संक्षेप में स्थिति को याद करूंगा। हमारे पास मैक ओएस एक्स के लिए एक कार्यक्रम है, जो कई तृतीय-पक्ष गतिशील-लिंक पुस्तकालयों का उपयोग करता है, जो बदले में, एक-दूसरे के कार्यों का भी उपयोग करते हैं।

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

हमेशा की तरह, अधीर अभी सब कुछ डाउनलोड कर सकता है।

स्पष्टता के लिए, एक काल्पनिक उदाहरण: हमारे पास सी भाषा (फ़ाइल test.c) में "परीक्षण" नामक एक कार्यक्रम है और एक साझा पुस्तकालय (फ़ाइल libtest.c), समान सामग्री के साथ, पहले से संकलित है। यह लाइब्रेरी एक फ़ंक्शन प्रदान करती है: libtest ()। उनके कार्यान्वयन में, उनमें से प्रत्येक मानक सी भाषा पुस्तकालय (मैक ओएस के साथ आपूर्ति की, libSystem.B.dylib में निहित) से पुट () फ़ंक्शन का उपयोग करता है। आइए वर्णित स्थिति का एक योजनाबद्ध प्रतिनिधित्व देखें:

कार्य इस प्रकार है:

आपको libtest.dylib लाइब्रेरी के लिए पुट () फ़ंक्शन कॉल को हुकड_पुट्स () फ़ंक्शन कॉल के साथ मुख्य कार्यक्रम (test.c फ़ाइल) में लागू करना होगा, जो मूल पुट () का उपयोग कर सकता है;
किए गए परिवर्तनों को छोड़ दें, अर्थात, सुनिश्चित करें कि बार-बार कॉल करने के लिए libtest () से कॉल मूल पुट () में जाती है।

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

संक्षेप में मच-ओ के बारे में

मच-ओ को समझने का सबसे अच्छा तरीका नीचे दी गई छवि को देखना है।

ऐसा लगता है कि मानव जाति अभी तक अपनी संरचना को अधिक स्पष्ट रूप से चित्रित नहीं कर पाई है। पहले सन्निकटन में, सब कुछ इस तरह दिखता है:

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

पार्सर उपयोगिताओं

दूसरे सन्निकटन के लिए, आपको कुछ उपयोगिताओं से परिचित होना होगा:

ओटूल - एक कंसोल प्रोग्राम है जो सिस्टम के साथ आता है। यह फ़ाइल के विभिन्न हिस्सों की सामग्री को प्रदर्शित करने में सक्षम है: हेडर, डाउनलोड कमांड, सेगमेंट, सेक्शन, और बहुत कुछ। यह विशेष रूप से -v (क्रिया) स्विच जोड़ने के लिए उपयोगी है जब आह्वान किया जाता है।
Machoview - GPL के तहत वितरित, एक GUI है, केवल Mac OS 10.6 और उच्चतर पर काम करता है। आपको मच-ओ की पूरी सामग्री को देखने की अनुमति देता है, कुछ हिस्सों पर जानकारी को पूरक करता है, अन्य भागों के डेटा के आधार पर, जो बहुत सुविधाजनक है।

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

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

हेडर संरचना सरल है (मैं इसे 32-बिट आर्किटेक्चर के लिए उद्धृत करता हूं, 64-बिट बहुत अलग नहीं है):

struct mach_header { uint32_t magic; cpu_type_t cputype; cpu_subtype_t cpusubtype; uint32_t filetype; uint32_t ncmds; uint32_t sizeofcmds; uint32_t flags; };

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

उदाहरण के लिए:

आवश्यक बूट कमांड नीचे सूचीबद्ध हैं:

LC_SEGMENT - एक निश्चित खंड के बारे में विभिन्न जानकारी होती है: आकार, अनुभागों की संख्या, फ़ाइल में ऑफसेट और लोड होने के बाद, मेमोरी में
LC_SYMTAB - पात्रों और तारों की एक तालिका लोड करता है
LC_DYSYMTAB - एक आयात तालिका बनाता है, वर्ण तालिका से वर्ण डेटा लिया जाता है
LC_LOAD_DYLIB - कुछ तृतीय-पक्ष लाइब्रेरी पर निर्भरता को इंगित करता है

उदाहरण के लिए (क्रमशः 32- और 64-बिट संस्करण):

सबसे महत्वपूर्ण खंड इस प्रकार हैं:

__TEXT - निष्पादन योग्य कोड और अन्य केवल-पढ़ने के लिए डेटा
__DATA - लेखन के लिए उपलब्ध डेटा; आयात तालिकाओं सहित, जो देर से बाध्यकारी के दौरान गतिशील लोडर द्वारा बदला जा सकता है
__OBJC - उद्देश्य-सी रनटाइम मानक पुस्तकालय की विभिन्न जानकारी
__IMPORT - 32-बिट आर्किटेक्चर के लिए विशेष रूप से आयात तालिका (मैंने केवल मैक ओएस 10.5 पर इसे तैयार किया है)
__LEDEDIT - यहां डायनामिक लोडर पहले से लोड किए गए मॉड्यूल के लिए अपने डेटा का पता लगाता है: वर्ण, तार, आदि की तालिकाएं।

किसी भी डाउनलोड कमांड की शुरुआत निम्न क्षेत्रों से होती है:

 struct load_command { uint32_t cmd; //   uint32_t cmdsize; //     };

जिसके बाद कमांड के प्रकार के आधार पर कई और अलग-अलग क्षेत्र हो सकते हैं।

उदाहरण के लिए:

इन खंडों में सबसे दिलचस्प खंड हैं:

__TEXT, __ टेक्स्ट - वास्तविक कोड
__TEXT, __ cstring - लगातार स्ट्रिंग्स (दोहरे उद्धरण में)
__TEXT, __ कॉन्स्ट - विभिन्न स्थिरांक
__DATA, __ डेटा - आरंभिक चर (स्ट्रिंग्स और सरणियाँ)
__DATA, __ la_symbol_ptr - आयातित कार्यों के लिए संकेत तालिका
__DATA, __ bss - अनइंस्टाल्यूटेड स्टेटिक वैरिएबल
__IMPORT, __ jump_table - आयातित कार्यों के लिए कॉल के लिए स्टब्स

आगे देखते हुए, मैं ध्यान देता हूं कि एक मच-ओ में, आयात तालिका __IMPORT, __ jump_table (32 बिट्स, मैक ओएस 10.5), या __DATA, __ la_symbol_ptr (64 बिट्स, या मैक ओएस 10.6 और पुराने) हो सकती है।

खंडों में अनुभागों में निम्नलिखित संरचना है:

 struct section { char sectname[16]; char segname[16]; uint32_t addr; uint32_t size; uint32_t offset; uint32_t align; uint32_t reloff; uint32_t nreloc; uint32_t flags; uint32_t reserved1; uint32_t reserved2; };

हमारे पास सेगमेंट और स्वयं सेक्शन का नाम है, आकार, फ़ाइल में ऑफसेट, और स्मृति में पता जिस पर गतिशील लोडर ने इसे रखा है। इसके अलावा, एक विशेष खंड के लिए विशिष्ट अन्य जानकारी है।

उदाहरण के लिए:

मोटा बाइनरी

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

यहाँ C में कैसा दिखता है:

 struct fat_header { uint32_t magic; uint32_t nfat_arch; };

जहां 0xCAFEBABE जादू के तहत छिपा हुआ है (या इसके विपरीत - अलग-अलग प्रोसेसर पर मशीन शब्दों में अलग-अलग बाइट ऑर्डर के बारे में याद रखें)। और उसके बाद, तुरंत nfat_arch संरचना के प्रकार का अनुसरण करें:

 struct fat_arch { cpu_type_t cputype; cpu_subtype_t cpusubtype; uint32_t offset; uint32_t size; uint32_t align; };

वास्तव में, फ़ील्ड नाम खुद के लिए बोलते हैं: प्रोसेसर प्रकार, एक विशिष्ट मच-ओ की फाइल में ऑफसेट, आकार और संरेखण।

प्रायोगिक कार्यक्रम

आयातित फ़ंक्शन को कॉल करने के संचालन का अध्ययन करने के लिए, हम C में निम्नलिखित फ़ाइलों को लेते हैं:

फ़ाइल test.c

 void libtest(); //from libtest.dylib int main() { libtest(); //calls puts() from libSystem.B.dylib return 0; }

फ़ाइल libtest.c

 #include <stdio.h> void libtest() //just a simple library function { puts("libtest: calls the original puts()"); }

डायनेमिक लेआउट का अन्वेषण करें

हम इंटेल प्रोसेसर तक सीमित हैं। हमें मैक ओएस 10.5 है। इन फ़ाइलों को एक नए Xcode प्रोजेक्ट में जोड़ें, (32-बिट संस्करण) संकलित करें और डीबग मोड में चलाएं, जहां libtest.dylib लाइब्रेरी के libtest () फ़ंक्शन में लाइन को कहा जाता है। यहाँ libtest () के लिए कोडांतरण सूची है:

आइए एक और निर्देश पर अमल करें:

और उसकी स्मृति में देखो:

यह आयात तालिका की सेल है (इस मामले में, सेल __IMPORT, __jump_table), जो डायनेमिक लोडर (फ़ंक्शन __dyld_stub_binding_helper-interface) को लागू करने के लिए एक स्प्रिंगबोर्ड के रूप में कार्य करता है, यदि देर से बाध्यकारी (आलसी बंधन) का उपयोग किया जाता है, या लक्ष्य फ़ंक्शन के लिए तुरंत कूदता है। पुट के बाद की कॉल से इसकी पुष्टि होती है ():

और स्मृति में:

इसलिए, हम देखते हैं कि गतिशील लोडर ने JMP अप्रत्यक्ष कूद अनुदेश (0xE9) के साथ CALL अप्रत्यक्ष कॉल निर्देश (0xE8) को बदल दिया। इसलिए, __jump_table तत्वों को पुनर्निर्देशित करने के लिए, यह हमारे लिए पर्याप्त होगा कि हम उनकी प्रारंभिक सामग्री के बजाय प्रतिस्थापन समारोह की शुरुआत में अप्रत्यक्ष संक्रमण के निर्देश को लिख सकें।

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

अब हम मैक ओएस 10.6 में प्रोजेक्ट ट्रांसफर करेंगे और 32- और 64-बिट आर्किटेक्चर के लिए फैट बाइनरी संकलित करेंगे। बस मामले में, Xcode में इस तरह किया जा सकता है:

संकलित करें, 64-बिट संस्करण चलाएं (उदाहरण के लिए; स्नो लेपर्ड पर आयात तालिका 32-बिट के लिए समान होगी) और पुट () कॉल पर फिर से रुक जाती है:

और फिर, एक साधारण कॉल। हम आगे देखते हैं:

यहां सामान्य __IMPORT, __jump_table के साथ अंतर पहले से ही ध्यान देने योग्य है।

__TEXT, __symbol_stub1 में आपका स्वागत है। यह तालिका प्रत्येक आयातित फ़ंक्शन के लिए JMP निर्देशों का एक सेट है। हमारे मामले में, ऊपर प्रस्तुत केवल एक ही ऐसा निर्देश है। ऐसा प्रत्येक निर्देश __DATA, __la_symbol_ptr तालिका के संबंधित सेल में निर्दिष्ट पते पर एक संक्रमण बनाता है। उत्तरार्द्ध इस मच-ओ के लिए आयात तालिका है।

लेकिन चलो अध्ययन जारी रखें। यदि आप उस पते को देखते हैं जिसमें संक्रमण होने जा रहा है:

फिर हम निम्नलिखित देखेंगे:

हम __TEXT, __stub_helper अनुभाग में आते हैं। यह अनिवार्य रूप से Mach-O के लिए एक PLT (प्रक्रिया लिंकेज तालिका) है। पहला निर्देश (इस मामले में, यह R11 के साथ संयोजन में LEA है, या कोई साधारण PUSH हो सकता है), डायनेमिक लिंकर याद रखता है कि किस प्रतीक को पुन: असाइन करने की आवश्यकता है, दूसरा निर्देश हमेशा एक ही पते पर जाता है - __dyld_stub_binding_helper फ़ंक्शन की शुरुआत, जो बाध्यकारी को संभाल लेगा :

डायनेमिक लिंकर पुट के लिए रिलोकेशन करता है (), __DATA में संबंधित सेल, __la_symbol_ptr जैसा दिखेगा:

और यह libSystem.B.dylib मॉड्यूल से पुट () फ़ंक्शन का पता है। यही है, इसे कुछ पते के साथ बदलने पर, हमें कॉल पुनर्निर्देशित करने का वांछित प्रभाव मिलता है।

So. इस स्तर पर, हमें एक विशिष्ट उदाहरण का उपयोग करके पता चला कि गतिशील लिंकिंग कैसे होती है, मच-ओ में किस प्रकार के आयात तालिकाओं होते हैं, और वे किन तत्वों से युक्त होते हैं। अब मच-ओ को पार्स करने के लिए नीचे उतरो!

एक आयात तालिका में एक आइटम के लिए खोजें

प्रतीक के नाम से आयात तालिका में संबंधित सेल को खोजना आवश्यक है। इस क्रिया के लिए एल्गोरिथ्म कुछ हद तक nontrivial है।

सबसे पहले, आपको चरित्र तालिका में ही चरित्र को खोजने की आवश्यकता है। उत्तरार्द्ध निम्नलिखित संरचनाओं का एक सरणी है:

 struct nlist { union { int32_t n_strx; } n_un; uint8_t n_type; uint8_t n_sect; int16_t n_desc; uint32_t n_value; };

जहां n_un.n_strx इस चरित्र के नाम की स्ट्रिंग तालिका की शुरुआत से बाइट्स में ऑफसेट है। बाकी प्रतीकों के प्रकार, जिस खंड में यह स्थित है, और इसी तरह की चिंता करता है। एक शब्द में, हमारे प्रायोगिक पुस्तकालय libtest.dylib (32-बिट संस्करण) के लिए कुछ अंतिम तत्व यहां दिए गए हैं:

एक पंक्ति तालिका नामों की एक श्रृंखला है, जिनमें से प्रत्येक शून्य के साथ समाप्त होती है। हालांकि, यह ध्यान देने योग्य है कि संकलक प्रत्येक नाम की शुरुआत में अंडरस्कोर "_" जोड़ता है, इसलिए, उदाहरण के लिए, "पुट" नाम स्ट्रिंग तालिका में "_puts" जैसा दिखेगा।

यहाँ एक उदाहरण है:

आप संबंधित लोड कमांड (LC_SYMTAB) से वर्णों और तार की तालिका का पता लगा सकते हैं:

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

यहाँ सी में उसकी प्रस्तुति है:

 struct dysymtab_command { uint32_t cmd; uint32_t cmdsize; uint32_t ilocalsym; uint32_t nlocalsym; uint32_t iextdefsym; uint32_t nextdefsym; uint32_t iundefsym; uint32_t nundefsym; uint32_t tocoff; uint32_t ntoc; uint32_t modtaboff; uint32_t nmodtab; uint32_t extrefsymoff; uint32_t nextrefsyms; uint32_t indirectsymoff; uint32_t nindirectsyms; uint32_t extreloff; uint32_t nextrel; uint32_t locreloff; uint32_t nlocrel; };

यहाँ dysymtab_command.iundefsym वर्ण तालिका में सूचकांक है, जो अपरिभाषित वर्णों के सबसेट के साथ शुरू होता है। dysymtab_command.nundefsym - अपरिभाषित वर्णों की संख्या। चूँकि हम जो खोज रहे हैं वह एक जानबूझकर अनिश्चितकालीन प्रतीक है, हमें इसके लिए इस तालिका में केवल प्रतीक तालिका में खोजने की आवश्यकता है।

और अब, एक बहुत ही महत्वपूर्ण बिंदु: इसके नाम से एक प्रतीक खोजना, हमारे लिए सबसे महत्वपूर्ण बात यह है कि शुरुआत से ही प्रतीक तालिका में इसके सूचकांक को याद रखना। चूंकि इन सूचकांकों के संख्यात्मक मान एक और महत्वपूर्ण तालिका हैं - अप्रत्यक्ष प्रतीकों की एक तालिका। आप इसे dysymtab_command.indirectsymoff के मान से पा सकते हैं, और सूचकांकों की संख्या dysymtab_command.nindirects जिम निर्धारित करती है।

हमारे तुच्छ मामले में, इस तालिका में केवल एक तत्व शामिल है (वास्तविक जीवन में और भी बहुत कुछ हैं):

और अंत में, __IMPORT, __jump_table सेक्शन को देखें, जिसके कुछ तत्व हमें अंत में खोजने होंगे। यह इस तरह दिखता है:

इस अनुभाग के लिए अनुभाग .reserved1 फ़ील्ड बहुत महत्वपूर्ण है (MachOView ने इसे Indirect Sym Index कहा है)। इसका अर्थ है अप्रत्यक्ष प्रतीक तालिका में एक सूचकांक, जिसमें से __jump_table तत्वों के साथ एक-से-एक पत्राचार शुरू होता है। और हमें याद है कि अप्रत्यक्ष प्रतीक तालिका में तत्व प्रतीक तालिका में सूचक हैं। पकड़ो मुझे क्या मिल रहा है?

लेकिन, तस्वीर को पूरा करने के लिए ज्ञान के सभी टुकड़ों को एक साथ इकट्ठा करने से पहले, आइए स्नो लेपर्ड की स्थिति पर एक त्वरित नज़र डालें, जहां __DATA, __la_symbol_ptr आयात तालिका की भूमिका निभाता है। वास्तव में, मतभेद बहुत ध्यान देने योग्य नहीं हैं।

यहाँ चरित्र लोडिंग कमांड है:

और यहाँ उसके अंतिम तत्व हैं:

दो अस्पष्ट अक्षर एक नीले रंग की पृष्ठभूमि पर दिखाई देते हैं, जो गतिशील प्रतीक लोड कमांड (LC_DYSYMTAB) से डेटा से मेल खाती है:

और अप्रत्यक्ष प्रतीकों की तालिका में पहले से ही एक तत्व नहीं है, लेकिन चार:

हालांकि, यदि आप क़ीमती खंड __la_symbol_ptr के आरक्षित 1 फ़ील्ड को देखते हैं, तो आप पा सकते हैं कि अप्रत्यक्ष प्रतीकों की तालिका पर इसके तत्वों का एक-से-एक प्रतिबिंब अंतिम की शुरुआत से शुरू नहीं होता है, लेकिन चौथे तत्व (सूचकांक 3) से है:

आयात तालिका की बहुत सारी सामग्री जो __la_symbol_ptr खंड का वर्णन करती है:

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

पुनर्निर्देशन एल्गोरिथ्म

हम कोड के बाद से शब्दों में सभी कार्यों का वर्णन करेंगे, टिप्पणियों की प्रचुरता के बावजूद, इतना स्पष्ट नहीं हो सकता है:

हम LC_SYMTAB लोड कमांड के डेटा के अनुसार वर्णों और रेखाओं की तालिका पाते हैं।
हम LC_DYSYMTAB बूट कमांड से सीखते हैं कि प्रतीक तालिका के किस तत्व के साथ अपरिभाषित प्रतीकों का सबसेट शुरू होता है (iundefsym फ़ील्ड)।
हम चरित्र तालिका में अपरिभाषित वर्णों के सबसेट के बीच नाम से एक लक्षित वर्ण की तलाश कर रहे हैं।
हम प्रतीक तालिका की शुरुआत से लक्ष्य प्रतीक के सूचकांक को याद करते हैं।
हम LC_DYSYMTAB लोड कमांड (अप्रत्यक्ष रूप से फ़ील्ड) से डेटा का उपयोग करके अप्रत्यक्ष प्रतीकों की तालिका पाते हैं।
हम उस सूचकांक का पता लगाते हैं जिससे आयात तालिका प्रदर्शित होने लगती है (परोक्ष प्रतीक तालिका (आरक्षित 1 क्षेत्र) पर (__DATA की सामग्री, __la_symbol_ptr अनुभाग (या __IMPORT, __jump_table - एक बात होगी))।
इस सूचकांक से शुरू करते हुए, हम अप्रत्यक्ष प्रतीक तालिका को देखते हैं और उसमें उस मूल्य की तलाश करते हैं जो प्रतीक तालिका में लक्ष्य चिह्न के सूचकांक से मेल खाता है।
हमें याद है कि कैसे, शुरुआत से, जब आयात तालिका अप्रत्यक्ष प्रतीक तालिका पर प्रदर्शित की गई थी, तो लक्ष्य प्रतीक पकड़ा गया। संग्रहीत मान आयात तालिका में वांछित आइटम का सूचकांक है।
__La_symbol_ptr (या __jump_table) अनुभाग के डेटा के अनुसार, हम आयात तालिका (ऑफ़सेट फ़ील्ड) पाते हैं।
इसमें लक्ष्य तत्व का सूचकांक होने के बाद, हम पते को (__la_symbol_ptr के लिए) उस मान को पुन: लिखते हैं जिसकी हमें आवश्यकता है (या CALL / JMP निर्देश को JMP को ऑपरेंड के साथ बदलें - हमें उस फ़ंक्शन का पता जिसकी हमें आवश्यकता है (__jump_table के लिए))।

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

पुनर्निर्देशन कार्यान्वयन

यह आपके विचारों को कोड में बदलने का समय है। प्रत्येक पुनर्निर्देशन के साथ आवश्यक मच-ओ तत्वों की खोज को अनुकूलित करने के लिए, हम पूरे ऑपरेशन को तीन चरणों में विभाजित करते हैं:

 void *mach_hook_init(char const *library_filename, void const *library_address);

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

 struct mach_hook_handle { void const *library_address; //base address of a library in memory char const *string_table; //buffer to read string_table table from file struct nlist const *symbol_table; //buffer to read symbol table from file uint32_t const *indirect_table; //buffer to read the indirect symbol table in dynamic symbol table from file uint32_t undefined_symbols_count; //number of undefined symbols in the symbol table uint32_t undefined_symbols_index; //position of undefined symbols in the symbol table uint32_t indirect_symbols_count; //number of indirect symbols in the indirect symbol table of DYSYMTAB uint32_t indirect_symbols_index; //index of the first imported symbol in the indirect symbol table of DYSYMTAB uint32_t import_table_offset; //the offset of (__DATA, __la_symbol_ptr) or (__IMPORT, __jump_table) uint32_t jump_table_present; //special flag to show if we work with (__IMPORT, __jump_table) };

```
 mach_substitution mach_hook(void const *handle, char const *function_name, mach_substitution substitution); 
```
उपलब्ध लाइब्रेरी डिस्क्रिप्टर के अनुसार यह फ़ंक्शन, लक्ष्य प्रतीक का नाम और इंटरसेप्टर का पता, ऊपर वर्णित एल्गोरिथ्म के अनुसार ही रीडायरेक्ट करता है।
```
 void mach_hook_free(void *handle); 
```
यह किसी भी हैंडल को साफ करता है जो mach_hook_init () लौटाता है।

इन प्रोटोटाइपों को देखते हुए, परीक्षण कार्यक्रम को फिर से लिखना होगा:

 #include <stdio.h> #include <dlfcn.h> #include "mach_hook.h" #define LIBTEST_PATH "libtest.dylib" void libtest(); //from libtest.dylib int hooked_puts(char const *s) { puts(s); //calls the original puts() from libSystem.B.dylib, because our main executable module called "test" remains intact return puts("HOOKED!"); } int main() { void *handle = 0; //handle to store hook-related info mach_substitution original; //original data for restoration Dl_info info; if (!dladdr((void const *)libtest, &info)) //gets an address of a library which contains libtest() function { fprintf(stderr, "Failed to get the base address of a library!\n", LIBTEST_PATH); goto end; } handle = mach_hook_init(LIBTEST_PATH, info.dli_fbase); if (!handle) { fprintf(stderr, "Redirection init failed!\n"); goto end; } libtest(); //calls puts() from libSystem.B.dylib puts("-----------------------------"); original = mach_hook(handle, "puts", (mach_substitution)hooked_puts); if (!original) { fprintf(stderr, "Redirection failed!\n"); goto end; } libtest(); //calls hooked_puts() puts("-----------------------------"); original = mach_hook(handle, "puts", original); //restores the original relocation if (!original) { fprintf(stderr, "Restoration failed!\n"); goto end; } libtest(); //again calls puts() from libSystem.B.dylib end: mach_hook_free(handle); handle = 0; //no effect here, but just a good advice to prevent double freeing return 0; }

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

टेस्ट रन

और कुछ इस तरह की कोशिश करो:

 user@mac$ arch -i386 ./test libtest: calls the original puts() ----------------------------- libtest: calls the original puts() HOOKED! ----------------------------- libtest: calls the original puts()

 user@mac$ arch -x86_64 ./test libtest: calls the original puts() ----------------------------- libtest: calls the original puts() HOOKED! ----------------------------- libtest: calls the original puts()

कार्यक्रम का समापन बहुत शुरुआत में निर्धारित कार्य की पूर्ण पूर्ति को इंगित करता है।

उपयोगी लिंक

सौभाग्य है

माच-ओ लाइब्रेरी में फ़ंक्शन पुनर्निर्देशन