ओफिसकेशन और रिफैक्टरिंग के संदर्भ में आत्मनिरीक्षण के साथ कोड का संगठन

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

दूर नहीं जाने के क्रम में, एक उदाहरण के लिए हम एक साधारण वर्ग लिखेंगे।

public class SimpleClass { private readonly string theValue; public SimpleClass(string value, int ratio) { theValue = value; } public string Value { get { return theValue; } } } 

इस वर्ग में गुण जोड़ें जो आत्मनिरीक्षण तंत्र के माध्यम से अपने मेटाडेटा तक पहुँच प्रदान करता है:

 internal static PropertyInfo ValueProperty { get { return typeof(SimpleClass).GetProperty("Value"); } } internal static FieldInfo ValueField { get { return typeof(SimpleClass).GetField("theValue", BindingFlags.NonPublic | BindingFlags.Instance); } } internal static ConstructorInfo Constructor { get { return typeof(SimpleClass).GetConstructor(new[] { typeof(string), typeof( }); } } 

यदि हम इन गुणों के मान को कंसोल में आउटपुट करते हैं, तो हमें इन प्रोग्राम एलिमेंट्स के स्ट्रिंग प्रतिनिधित्व मिलते हैं। हालाँकि, यदि आप IDE में निर्मित रिफैक्टरिंग इंजन (उदाहरण के लिए, Visual Studio में यह Refactoring मेनू, Reorder पैरामीटर आइटम) का उपयोग करके निर्माण पैरामीटर को पुनर्व्यवस्थित करते हैं, तो निर्माणकर्ता मेटाडेटा को प्रतिबिंबित करने वाली संपत्ति एक खाली लिंक (अर्थात शून्य) वापस कर देगी। और यदि आप असेंबली में भी ओफ़्फ़ैक्शन लागू करते हैं, तो इस तरह से परिलक्षित होता है कि फ़ील्ड और प्रॉपर्टी पूरी तरह से असंभव हो जाएगी (मामले को छोड़कर जब ऑबफस्केशन एट्रिब्यूट विशेषता का उपयोग किया जाता है)।
स्थिति से बाहर निकलने के लिए, हम अभिव्यक्ति पेड़, भेड़ के बच्चे के अभिव्यक्ति और सामान्यीकरण के साथ खुद को बांधे रखते हैं। इस सब से हम सहायक विधि को गोंद करते हैं:

 static TMember Reflect<TDelegate, TMember>(Expression<TDelegate> memberAccess) where TDelegate : class where TMember : MemberInfo { if (memberAccess.Body is MemberExpression) return ((MemberExpression)memberAccess.Body).Member as TMember; else if (memberAccess.Body is NewExpression) return ((NewExpression)memberAccess.Body).Constructor as TMember; else if (memberAccess.Body is MethodCallExpression) return ((MethodCallExpression)memberAccess.Body).Method as TMember; else return null; } 

यह विधि दो प्रकार के मापदंडों को स्वीकार करती है: पहली दलील स्वीकार किए जाने वाले लंबोदर अभिव्यक्ति के हस्ताक्षर को एक तर्क के रूप में पारित करने के लिए उपयोग किए जाने वाले प्रतिनिधि को स्वीकार करता है, दूसरा वर्ग के प्रतिबिंबित सदस्य के प्रकार (उदाहरण के लिए, फ़ील्ड के लिए FieldInfo) को स्वीकार करता है। एक तर्क के रूप में पारित लैम्ब्डा अभिव्यक्ति उस वर्ग के सदस्य तक पहुंच का वर्णन करता है जो हमें रुचि देता है। विधि के अंदर, लैम्ब्डा अभिव्यक्ति के शरीर के लिए एक अपील की जाती है, जिसे एक अभिव्यक्ति पेड़ के रूप में दर्शाया गया है। चूंकि शरीर कक्षा के किसी सदस्य तक पहुंच का प्रतिनिधित्व करता है, हम संभावित विकल्पों के लिए शरीर के प्रकार का विश्लेषण करते हैं:

• किसी संपत्ति या क्षेत्र तक पहुंच;
• नए ऑपरेटर को कॉल करना (इस अभिव्यक्ति में कंस्ट्रक्टर का संदर्भ है);
• विधि कॉल।

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

 internal static PropertyInfo ValueProperty { get { return Reflect<Func<SimpleClass, string>, PropertyInfo>(v => v.Value); } } internal static FieldInfo ValueField { get { return Reflect<Func<SimpleClass, string>, FieldInfo>(v => v.theValue); } } internal static ConstructorInfo Constructor { get { return Reflect<Func<string, int, SimpleClass>, ConstructorInfo>((a1, a2) => new SimpleClass(a1, a2)); } } 

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

हमेशा BUT होता है

यह विधि केवल वर्तमान लेक्सिकल स्कोप में उपलब्ध प्रोग्राम तत्वों को प्रतिबिंबित करने के लिए उपयुक्त है।