क्या .NET कोड obfuscation वास्तव में इसके लायक है?

Question

जो मैंने पढ़ा है, उससे कोड obfuscation वास्तव में "क्रैक" करना मुश्किल नहीं है, और यह केवल अपरिहार्य देरी करेगा। उस मामले में, इसका उद्देश्य क्या है?

यदि कोई वास्तव में आपके स्रोत को चुरा लेना चाहता है तो वे कर सकते हैं।

यदि किसी को हानिरहित/सहायक उद्देश्यों के लिए आपके स्रोत कोड को देखने की आवश्यकता है तो वे नहीं कर सकते हैं।

आपको शायद कोड में संवेदनशील कुछ भी संग्रहित नहीं करना चाहिए, इसलिए यह कोई मुद्दा नहीं होना चाहिए।

यदि आप obfuscate नहीं करते हैं, तो भी आप पूर्ण स्रोत कोड प्रदान नहीं कर रहे हैं, इसलिए आप "स्रोत कोड लाइसेंस" बेच सकते हैं।

मजाकिया बात यह है कि एकमात्र कोड जिसे मैंने कभी देखा है, वह भयानक कोड है जिसमें इसमें बग है। कोड को देखने का एकमात्र कारण यह है कि समस्या क्या है और मैं इसे ठीक करने के लिए क्या कर सकता हूं।

उदाहरण के लिए, मुझे ASPDotNetStoreFront में कुछ छवियों को प्रतिस्थापित करने की आवश्यकता है। टैग के स्थान की तलाश करते समय, मैंने पाया कि वे संकलित कोड के भीतर निहित थे। बकवास। तो मैंने सोचा कि मैं रेगेक्स के माध्यम से किस आईएमजी टैग को प्रतिस्थापित करने के लिए कोड को संकुचित कर दूंगा। मैंने सोर्स कोड को देखने की कोशिश की कि यह देखने के लिए कि कौन सी छवियां संभवतः संकलित विधि से आ सकती हैं, और परावर्तक इसे संभाल नहीं सकता है, मुझे लगता है कि obfuscation के कारण। मेरे पास वास्तव में डी-कॉमर्स/डी-ओबफसेटर के लिए चारों ओर देखने के लिए समय नहीं है।

Answer 1

मुझे लगता है कि यह इसके लायक है। आपके लिए लागत लगभग कुछ भी नहीं है, और आप हैकर के जीवन को अधिक कठिन बनाते हैं। यहां तक ​​कि अगर वे इसे क्रैक करते हैं, तो आपको यह जानने की संतुष्टि है कि आप कई घंटों से कहीं भी अपने जीवन के कई हफ्तों तक बर्बाद हो जाते हैं। सिर्फ इसलिए कि एक ताला सही नहीं है इसका मतलब यह नहीं है कि आप अपने दरवाजे बंद नहीं करते हैं।

Answer 2

मुझे नहीं पता कि यह 'इसके लायक' है, लेकिन मैं कह सकता हूं कि obfuscation के विकल्प हैं जो अधिक सुरक्षित हैं।

उदाहरण के लिए XHEO एक उपकरण (CodeVeil) प्रदान करता है ताकि वास्तव में उन्हें नाराज करने के बजाय .NET असेंबली एन्क्रिप्ट किया जा सके।

Answer 3

केवल तभी यदि आपका प्रोजेक्ट लंबे समय से चल रहा है और इसे लागू करने के लिए किसी को बहुत समय लगेगा, तो यह इसके लायक है। यह निश्चित रूप से यहां एक राय है, लेकिन मुझे एक obfuscated .NET DLL नहीं मिला है, लेकिन मुझे पता नहीं चला कि केवल प्रतिबिंबक का उपयोग कर क्या हो रहा है।

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

एक आम मामला मुझे बहुत कुछ लगता है कि आप लाइसेंस कुंजी का उत्पादन कैसे करते हैं और/या डिक्रिप्ट करते हैं। कोई भी जो इसे समझने के लिए प्रेरित है और आपके लिए परावर्तक में खोदने के लिए नमक/डिक्रिप्शन विधियों को रोकना नहीं है, मैं कहने की हिम्मत करता हूं कि यह वास्तव में उन्हें बहुत धीमा नहीं करेगा।

Answer 4

मेरी राय में, नहीं। मैंने अलग-अलग भाषाओं में लिखे गए लोगों को हैकिंग प्रोग्राम देखा है। पेशेवर उपकरण जैसे आईडीए (अप्रबंधित कोड के लिए काम करता है) के साथ, कुछ भी 100% सुरक्षित नहीं है। Obfuscated विधानसभा अभी भी मौजूद मेटाडेटा के कारण हैक करने के लिए आसान है।

Answer 5

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

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

Answer 6

बेशक कुछ भी 100% संरक्षित नहीं है। लेकिन उस कारण से परेशान नहीं होना आपके घर के दरवाजे को बंद नहीं करना है क्योंकि "किसी भी निर्धारित चोर इसे वैसे भी खोल सकता है"। फिर भी आप दरवाजा बंद कर देते हैं !!

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

आप आवेदन प्रदाता के रूप में, पहली जगह में जिम्मेदार ठहराया जाएगा ...

BitHelmet के दोस्तों http://www.bithelmet.com/Overview.html में नहीं बल्कि अच्छी तरह से समझा।

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

मैं तब जूनियर था :), मेरे मालिक को इससे निपटना पड़ा। मुझे हमेशा आश्चर्य होता है कि इनमें से कितने चोरी कभी नहीं खोजे गए ;-)। मैं इसे कर सकता था, लेकिन कभी नहीं किया!

तथ्य यह है कि आपको कुछ स्तर की सुरक्षा में सोचना चाहिए, और आपको इनहाउस हमलावर में विचार करना चाहिए। और निर्धारित रिवर्स एंजिनर को भी जीवन कठिन बना देगा।