कैसे करें NET.Reflector को बेवकूफ

आज मैंने सोचा कि कैसे obfuscators NET.eflector जैसी deobfuscation उपयोगिताओं से विधि कोड छिपाते हैं। अजीब तरह से पर्याप्त है, लेकिन मुझे इंटरनेट पर इस मुद्दे पर कोई उपयोगी जानकारी नहीं मिली (मैंने खराब खोज की हो सकती है) और इसलिए मुझे खुद थोड़ा शोध करना पड़ा। कटौती के तहत, परिणामों के बारे में एक संक्षिप्त नोट। नमूना कोड में, Mono.Cecil और कोड पीढ़ी का फिर से उपयोग किया जाएगा, इसलिए मेरा पहला लेख पढ़ना सुनिश्चित करें ।







सिद्धांत से शुरू करते हैं। प्रत्येक MSIL अनुदेश कोड को एक या दो बाइट्स द्वारा दर्शाया जा सकता है। उदाहरण के लिए, एनओपी निर्देश को 0x00 के रूप में दर्शाया गया है। इस प्रकार हमारे पास 65,536 विभिन्न विकल्प हैं। फिलहाल, इस स्थान में से कुछ पर मान्य MSIL अनुदेश कोड हैं, लेकिन अधिकांश स्वतंत्र हैं। JIT कंपाइलर को गलत कोड के साथ एक निर्देश पर स्विच करने से एप्लिकेशन क्रैश हो जाएगा। NET.Reflector, एक गलत निर्देश में टकराकर, विधि कोड को पार्स करना बंद कर देता है और "अमान्य विधि निकाय" संदेश को प्रदर्शित करता है, जो कि हमें चाहिए।



इस प्रकार, हमारा लक्ष्य विधि में एक गलत निर्देश सम्मिलित करना है, लेकिन ताकि किसी भी परिस्थिति में यह संक्रमण न हो सके। ऐसा करने के लिए, आप बिना शर्त कूद का उपयोग कर सकते हैं:

goto MethodCode; //    MethodCode: //   
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

परावर्तक कोड की पुनरावृत्ति का विश्लेषण नहीं करेगा, और जब एक खराब निर्देश का विश्लेषण करेगा, तो यह ठोकर खाएगा और विधि आगे का विश्लेषण नहीं करेगी। एप्लिकेशन ठीक काम करेगा, क्योंकि खराब निर्देश पर स्विच करना कभी नहीं होगा। यह मामला कुछ इस तथ्य से जटिल है कि Mono.Cecil हमें केवल एक बुरा निर्देश डालने की अनुमति नहीं देगा - सभी मान्य कोड एक गणना के रूप में प्रस्तुत किए जाते हैं और आप मानक टूल का उपयोग करके अपना स्वयं का जोड़ नहीं सकते। बेशक, आप हमेशा Mono.Cecil के स्रोतों को बदल सकते हैं, लाभ एक खुला स्रोत प्रणाली है, लेकिन मैं चाहता था कि यह एक मानक विधानसभा पर काम करे। Mono.Cecil के स्रोतों का विश्लेषण करने के आधे घंटे के बाद, मैंने पाया कि कैसे गलत निर्देश 0x0024 डाला जाए ताकि Mono.Cecil ने इसे छोड़ दिया और अपवाद न फेंके। आइए कोड को देखें:

 static void ProtectMethod(string path, string methodName) { var assembly = AssemblyDefinition.ReadAssembly(path); foreach (var typeDef in assembly.MainModule.Types) { foreach (var method in typeDef.Methods) { if (method.Name == methodName) { var ilProc = method.Body.GetILProcessor(); //   internal    OpCode var constructor = typeof(OpCode).GetConstructor(BindingFlags.Instance | BindingFlags.NonPublic, null, new Type[] { typeof(int), typeof(int) }, null); //  Mono.Cecil     -     4-(int) ,       8 ,        MSIL . ,        8   2 .       OpCode,      .        ,       , Mono.Cecil        Exception,       . int x = 0xff << 0 | //   IL  0x24 << 8 | //   IL  0x00 << 16 | (byte) FlowControl.Next << 24; //       ,    ,  Mono.Cecil     int y = (byte) OpCodeType.Primitive << 0 | (byte) OperandType.InlineNone << 8 | (byte) StackBehaviour.Pop0 << 16 | (byte) StackBehaviour.Push0 << 24; var badOpCode = (OpCode) constructor.Invoke(new object[] {x, y}); //    Instruction badInstruction = Instruction.Create(badOpCode); Instruction firstInstruction = ilProc.Body.Instructions[0]; //         ilProc.InsertBefore(firstInstruction, Instruction.Create(OpCodes.Br_S, firstInstruction)); //        ilProc.InsertBefore(firstInstruction, badInstruction); } } } assembly.Write(path); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

हमारी विधानसभा की कुछ विधि पर इस पद्धति के परिणाम पर विचार करें, जिसे हम देखने से बचाना चाहते हैं



प्रसंस्करण से पहले विधि:







प्रसंस्करण के बाद परावर्तक में विधि:







इस मामले में, प्रसंस्करण के बाद, आवेदन समस्याओं के बिना शुरू होता है। आवश्यक परिणाम प्राप्त किया गया है।



अंत में, मैं ध्यान देता हूं कि इस तरह की आपत्ति बहुत आसान है (विधानसभा में बदलाव की आवश्यकता होगी), लेकिन यह बहुत ही जानकार डेवलपर्स द्वारा कोड को देखने से बचाने में सक्षम है। इसके अलावा, मेरी राय में, जानकारी ही बहुत दिलचस्प है।