कोडर आवेषण ... C # में?

तो, यह कहानी तीन कारकों के संयोग से शुरू हुई। मैं एक हूँ:

1. ज्यादातर C # में लिखा है;
2. केवल मोटे तौर पर कल्पना की जाती है कि यह कैसे व्यवस्थित और काम करता है;
3. कोडांतरक में रुचि हो गई।

यह प्रतीत होता है निर्दोष मिश्रण ने एक अजीब विचार को जन्म दिया: क्या किसी तरह इन भाषाओं को जोड़ना संभव है? सी # में जोड़ें कोडांतरक आवेषण करने की क्षमता, सी ++ में बहुत पसंद है।

यदि आप इस परिणाम के लिए इच्छुक हैं, तो बिल्ली में आपका स्वागत है।

पहली मुश्किलें

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

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

पहला प्रोटोटाइप: "कॉलिंग" एक सरणी

यह कार्य संभवतः आवेषण के लिए सबसे गंभीर बाधा है। हमारे एरे को पॉइंटर प्राप्त करने के लिए भाषा टूल का उपयोग करना आसान है, लेकिन C # दुनिया में पॉइंटर्स केवल डेटा के लिए मौजूद हैं और इसे एक पॉइंटर में बदलने के लिए असंभव है, कहते हैं, एक फ़ंक्शन ताकि आप इसे बाद में कॉल कर सकें (अच्छी तरह से, या कम से कम मुझे पता नहीं कैसे हो सकता है। करने के लिए)।

सौभाग्य से (या दुर्भाग्य से), चंद्रमा के नीचे कुछ भी नया नहीं है और "सी #" और "असेंबलर आवेषण" शब्दों के लिए यैंडेक्स में एक त्वरित खोज ने मुझे पत्रिका के दिसंबर 2007 के अंक में एक लेख ]] [अकर] के लिए प्रेरित किया। ईमानदारी से समारोह को वहां से कॉपी किया और इसे अपनी आवश्यकताओं के लिए अनुकूलित किया, मुझे मिल गया

[DllImport("kernel32.dll")] extern bool VirtualProtect(int* lpAddress, uint dwSize, uint flNewProtect, uint* lpflOldProtect); public void* InvokeAsm(void* firstAsmArg, void* secondAsmArg, byte[] code) { int i = 0; int* p = &i; p += 0x14 / 4 + 1; i = *p; fixed (byte* b = code) { *p = (int)b; uint prev; VirtualProtect((int*)b, (uint)code.Length, 0x40, &prev); } return (void*)i; } 

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

हम उस जादू से InvokeAsm() जो InvokeAsm() में अधिक विस्तार से InvokeAsm() है। सबसे पहले, हम एक स्थानीय चर घोषित करते हैं, जो निश्चित रूप से, स्टैक पर दिखाई देता है, फिर हमें इसका पता मिलता है (जिससे स्टैक के शीर्ष का पता प्राप्त होता है)। इसके बाद, हम इसे डिबगर में गणना करते हुए दर्द निवारक द्वारा प्राप्त एक निश्चित जादू की स्थिरांक से जोड़ते हैं, जो स्टैक के शीर्ष के सापेक्ष वापसी पते की भरपाई करता है, वापसी पते को बचाने और हमारे बाइट सरणी का पता लिखने के बजाय। वापसी पते को बचाने का पवित्र अर्थ स्पष्ट है - हमें अपने सम्मिलन के बाद कार्यक्रम को निष्पादित करना जारी रखने की आवश्यकता है, जिसका अर्थ है कि हमें यह जानना होगा कि इसके बाद नियंत्रण कहां स्थानांतरित करना है। इसके बाद कर्नेल 32.dll लाइब्रेरी - VirtualProtect() से WinAPI फ़ंक्शन को कॉल आता है। यह मेमोरी पेज की विशेषताओं को बदलने के लिए आवश्यक है, जिस पर इन्सर्ट कोड स्थित है। बेशक, कार्यक्रम को संकलित करते समय, यह डेटा अनुभाग में दिखाई देता है, और संबंधित मेमोरी पेज ने एक्सेस पढ़ा और लिखा है। हमें इसकी सामग्री को निष्पादित करने के लिए अनुमति जोड़ने की भी आवश्यकता है। अंत में, हम संग्रहीत वास्तविक रिटर्न पता लौटाते हैं। बेशक, यह पता उस कोड को नहीं लौटाया जाएगा जिसे InvokeAsm() कहा जाता है, क्योंकि return (void*)i; तुरंत बाद निष्पादन return (void*)i; डालने में "विफल"। हालांकि, वर्चुअल मशीन द्वारा उपयोग किए जाने वाले कॉलिंग कन्वेंशन (अनुकूलन के साथ अनुकूलन और सक्षम के साथ फास्टकॉल) का अर्थ है ईएएक्स रजिस्टर के माध्यम से मूल्य वापस करना, अर्थात। डालने से लौटने के लिए, हमें दो निर्देशों का पालन करने की आवश्यकता है: push eax (कोड 0x50) और रिट (कोड 0xC3)।


अंत में, आपको दो अप्रयुक्त तर्कों पर ध्यान देना चाहिए: void* firstAsmArg और void* secondAsmArg । उन्हें उपयोगकर्ता के डेटा को असेंबलर डालने के लिए मनमाने ढंग से स्थानांतरित करने की आवश्यकता होती है। ये तर्क या तो स्टैक (stdcall) पर एक ज्ञात स्थान पर स्थित होंगे, या, फिर से, जाने-माने रजिस्टरों (Fastcall) में।

सुधार

सुरक्षित असुरक्षित से बेहतर है

बेशक, किसी भी सुरक्षा का कोई सवाल नहीं है (जिस अर्थ में यह शब्द C # में उपयोग किया जाता है)। हालांकि, ऊपर वर्णित InvokeAsm() विधि संकेत पर संचालित होती है, जिसका अर्थ है कि इसे केवल unsafe कीवर्ड के साथ चिह्नित ब्लॉक से बुलाया जा सकता है, जो हमेशा सुविधाजनक नहीं होता है - कम से कम इसे / असुरक्षित स्विच (या वीएस में परियोजना के गुणों में संबंधित चेकमार्क) के साथ संकलन की आवश्यकता होती है। इसलिए, यह एक शेल प्रदान करना तर्कसंगत लगता है जो कम से कम इंटप्रेट (सबसे खराब) पर काम करता है, और आदर्श रूप से, यह उपयोगकर्ता को प्रेषित किए जाने वाले और वापस लौटने के प्रकार निर्दिष्ट करने की अनुमति देता है। खैर, यह सामान्य की तरह लगता है, हम सामान्य लिखते हैं, और क्या है, एक पूछता है, के बारे में बात करने के लिए? वास्तव में - कुछ है।

सबसे स्पष्ट: कैसे एक तर्क के लिए एक संकेतक प्राप्त करने के लिए जिसका प्रकार अज्ञात है? T* ptr = &arg # T* ptr = &arg के प्रकारों के निर्माण की अनुमति C # में नहीं है, और, सामान्य तौर पर, इस कारण को समझना मुश्किल नहीं है: उपयोगकर्ता एक प्रकार के पैरामीटर के रूप में प्रबंधित प्रकारों में से एक का उपयोग कर सकता है, एक पॉइंटर जिसे प्राप्त नहीं किया जा सकता है। समाधान unmanaged प्रकार के एक पैरामीटर को प्रतिबंधित करने के लिए हो सकता है, लेकिन, सबसे पहले, यह केवल C # 7.3 में दिखाई दिया, और दूसरी बात, यह तर्क के रूप में तार और सरणियों को पारित करने की अनुमति नहीं देता है, हालांकि fixed ऑपरेटर उन्हें उपयोग करने की अनुमति देता है (हम पहले के लिए पॉइंटर प्राप्त करते हैं) क्रमशः वर्ण या सरणी तत्व)। खैर, इसके अलावा, मैं उपयोगकर्ता को नियंत्रित प्रकारों सहित काम करने का अवसर देना चाहूंगा - चूंकि हमने भाषा के नियमों का उल्लंघन करना शुरू कर दिया है, हम उन्हें अंत तक उल्लंघन करेंगे!

किसी प्रबंधित ऑब्जेक्ट के लिए पॉइंटर और पॉइंटर द्वारा ऑब्जेक्ट प्राप्त करना

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

बस उस समय, एक अद्भुत पुस्तक मेरे हाथों में गिर गई, जिसकी बदौलत मैंने खुद के लिए बहुत कुछ सीखा - "जेएलआर रिक्टर द्वारा सीएलआर # सीएलआर"। इसमें, बीसवें अध्याय के आसपास, हमने GCHandle संरचना के बारे में बात की, जिसमें एक Alloc() पद्धति है जो एक वस्तु और एक GCHandleType एन्यूमरेशन GCHandleType को GCHandleType । इसलिए, यदि आप इस विधि को वांछित वस्तु और GCHandle.Pinned पास करते हैं। तो, आप इस ऑब्जेक्ट का पता स्मृति में प्राप्त कर सकते हैं। इसके अलावा, GCHandle.Free() कॉल करने से पहले GCHandle.Free() ऑब्जेक्ट तय हो गया है, अर्थात कचरा कलेक्टर के प्रभाव से पूरी तरह से संरक्षित। हालांकि, कुछ समस्याएं हैं। सबसे पहले, GCHandle किसी भी तरह से "पॉइंटर → ऑब्जेक्ट" रूपांतरण, केवल "ऑब्जेक्ट → पॉइंटर" को पूरा करने में मदद नहीं करता है। अधिक महत्वपूर्ण रूप से, GCHandleType.Pinned का उपयोग करने के लिए GCHandleType.Pinned ऑब्जेक्ट का वर्ग या संरचना जिसका पता हम प्राप्त करना चाहते हैं, उसके पास [StructLayout(LayoutKind.Sequential)] विशेषता होनी चाहिए, जबकि LayoutKind.Auto उपयोग किया जाता है। तो यह विधि केवल कुछ मानक प्रकारों और उन कस्टम प्रकारों के लिए उपयुक्त है जो मूल रूप से इसे ध्यान में रखकर तैयार किए गए थे। ठीक उसी सार्वभौमिक विधि से नहीं जिसे हम खोजना चाहेंगे, है ना?

खैर, फिर से कोशिश करें। अब दो __makeref() कार्यों पर ध्यान दें, जो, फिर भी, रोसलिन द्वारा समर्थित हैं: __makeref() और __refvalue() । उनमें से पहला एक ऑब्जेक्ट लेता है और टाइप की गई संदर्भ संरचना का एक उदाहरण देता है जो ऑब्जेक्ट और इसके प्रकार के संदर्भ को संग्रहीत करता है, जबकि दूसरा ट्रांसमिट किए गए typedReference इंस्टेंस से ऑब्जेक्ट को निकालता है। ये विशेषताएं हमारे लिए महत्वपूर्ण क्यों हैं? क्योंकि TypedReference एक संरचना है! चर्चा के संदर्भ में, इसका मतलब है कि हम इसे एक संकेतक प्राप्त कर सकते हैं, जो संयोजन में, इस संरचना के पहले क्षेत्र के लिए एक संकेतक होगा। अर्थात्, यह उस वस्तु की बहुत कड़ी को संग्रहीत करता है जो हमें रुचती है। फिर, किसी प्रबंधित ऑब्जेक्ट के लिए एक पॉइंटर प्राप्त करने के लिए, हमें एक पॉइंटर के मान को पढ़ने की आवश्यकता है कि __makeref() क्या लौटेगा और इसे पॉइंटर में बदल देगा। पॉइंटर द्वारा ऑब्जेक्ट प्राप्त करने के लिए, आपको आवश्यक प्रकार की सशर्त रूप से खाली ऑब्जेक्ट से __makeref() कॉल करना होगा, लौटाए गए TypedReference उदाहरण के लिए एक पॉइंटर प्राप्त करें, उस पर ऑब्जेक्ट को एक पॉइंटर लिखें, और फिर __refvalue() कॉल करें। परिणाम कुछ इस तरह है:

 public static Tout ToInstance<Tout>(IntPtr ptr) { Tout temp = default; TypedReference tr = __makeref(temp); Marshal.WriteIntPtr(*(IntPtr*)(&tr), ptr); Tout instance = __refvalue(tr, Tout); return instance; } public static void* ToPointer<T>(ref T obj) { if (typeof(T).IsValueType) { return *(void**)&tr; } else { return **(void***)&tr; } } 

उन लोगों के लिए जिन्हें ऑपकोड याद नहीं है

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


मैं शायद इस "चमत्कार" को बनाने की प्रक्रिया के बारे में बात नहीं कर रहा हूं - इस कहानी में कुछ भी दिलचस्प नहीं है, लेकिन मैं मुख्य विशेषताओं का संक्षेप में वर्णन करूंगा। अधिकांश x86 निर्देश वर्तमान में समर्थित हैं। फ़्लोटिंग पॉइंट नंबरों और एक्सटेंशन (MMX, SSE, AVX) के साथ काम करने के गणितीय गणितीय निर्देश अभी तक समर्थित नहीं हैं। स्थिरांक, प्रक्रियाएं, स्थानीय स्टैक चर, वैश्विक चर घोषित करना संभव है, जिसके लिए मेमोरी को बाइनरी कोड के साथ एक सरणी में सीधे अनुवाद के दौरान आवंटित किया जाता है (यदि इन चर को लेबल का उपयोग करके नाम दिया जाता है, तो कॉलिंग विधियों द्वारा सम्मिलन के बाद उनका मान C # से भी प्राप्त किया जा सकता है। GetBYTEVariable() , GetWORDVariable() , GetDWORDVariable() , GetAStringVariable() और GetWStringVariable() SASMCode ऑब्जेक्ट की), addr और SASMCode मैक्रोज़ मौजूद हैं। बाहरी सुविधाओं से आयात के लिए महत्वपूर्ण विशेषताओं में से एक है बाहरी पुस्तकालयों से कार्यों का आयात extern < > lib < > निर्माण।

asmret मैक्रो एक अलग पैराग्राफ के योग्य है। अनुवाद की प्रक्रिया में, यह उपसंहार बनाते हुए 11 निर्देशों में प्रकट होता है। डिफ़ॉल्ट रूप से अनुवादित कोड की शुरुआत में प्रोलॉग जोड़ा जाता है। उनका कार्य प्रोसेसर की स्थिति को बचाने / पुनर्स्थापित करना है। इसके अलावा, प्रस्तावना में चार स्थिरांक - $first , $second , $this और $return । अनुवाद के दौरान, इन स्थिरांक को स्टैक पर पते द्वारा प्रतिस्थापित किया जाता है, जिस पर, क्रमशः, पहली और दूसरी दलीलें कोडांतरक सम्मिलित करने के लिए पारित की जाती हैं, पहली प्रविष्टि कमांड का पता और वापसी पता।

परिणाम

कोड शब्दों की तुलना में बहुत अधिक कहेंगे, और यह काफी अजीब होगा कि काफी लंबे काम के परिणाम को साझा न करें, इसलिए मैं उन सभी को आमंत्रित करता हूं जिनकी मुझे GitHub में रुचि है ।

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