2012-07-19 15 views
5

ठीक है, मैं डेस्कटॉप एप्लिकेशन में लाइसेंस सत्यापन कोड के बारे में बात कर रहा हूं, उदा। एक विधि bool ValidateLicense(string licenseCode)। बेशक, किसी भी सुरक्षा योजना को एक कुशल और निर्धारित क्रैकर द्वारा इंजीनियर किया जा सकता है। हालांकि, मैं यह रोकना चाहता हूं कि कुछ बुनियादी प्रोग्रामिंग ज्ञान वाले किसी भी व्यक्ति को कुछ मिनटों में एक कीजेन बनाने के लिए परावर्तक का उपयोग कर सकते हैं।.NET प्रोग्राम तर्क (उचित रूप से) गुप्त कैसे रखें?

संभावित दृष्टिकोण

  1. अंधेरा करना। मेरी समझ यह है कि obfuscating एक प्रदर्शन ओवरहेड का कारण बनता है और (वैध) डीबगिंग बाधा डाल सकता है। ऐसे में ऐसे उपकरण हैं जो केवल चयनित विधियों को खराब करने की अनुमति देते हैं?

  2. ngen'ed असेंबली या अप्रबंधित DLL पर विधि को ले जाएं। लेकिन क्या यह डीएलएल को बदलने की निमंत्रण नहीं है? कोई विचार यह कैसे रोकें (पढ़ें: हमलावर के लिए थोड़ा कठिन बनाओ)?

  3. अन्य?

पुनश्च: प्रश्न स्पष्ट रूप से Protect .NET code from reverse engineering? से संबंधित है 1. करने के लिए वहाँ से विचार डाल करने के लिए

अद्यतन

अभ्यास करने के लिए एक पहला कदम कहानियो को निश्चित रूप से सत्यापन विधि का नाम बदलने की कोशिश कर रहा होगा। (धन्यवाद, जोनाथन)

से 2. एप्लिकेशन मानते हुए Win32 API विधियों का उपयोग करता है, कोई एक अप्रबंधित DLL के माध्यम से कॉल को फिर से रूट कर सकता है जिससे इसे एप्लिकेशन का एक अभिन्न हिस्सा बना दिया जा सके। विधि हस्ताक्षर के साथ झुकाव (उदा। नाम बदलें, स्वैप पैरामीटर) इससे कम स्पष्ट हो जाएगा। क्या आपको लगता है कि सहज दोषों को न्यायसंगत माना जाता है?

से 3. प्रमाणीकरण विधि वितरित न करें। इसे अपने सर्वर पर रखें और दूरस्थ रूप से कॉल करें, यानी ऑनलाइन सत्यापन का उपयोग करें (धन्यवाद, डेविड हेडलंड)

+0

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

+0

एक अस्पष्ट वीएम, ऑनलाइन सत्यापन का संयोजन और अपने कोड के कुछ आवश्यक (लेकिन प्रदर्शन-महत्वपूर्ण) भागों के लिए ऑनलाइन सत्यापन सेवा द्वारा प्रदान किए गए यादृच्छिक वीएम कोड का उपयोग करें। या यहां तक ​​कि ऑनलाइन सेवा में आवश्यक कार्यक्षमता (केवल सत्यापन नहीं) के कुछ हिस्सों को स्थानांतरित करें। –

उत्तर

2

Eazfuscator आपको रिलीज में केवल अपने कोड को खराब करने दें, हम इसका उपयोग किसी भी प्रदर्शन समस्या को महसूस नहीं कर रहे हैं। यह आपको चयनित तरीकों को भी खराब कर देता है। ध्यान दें कि सार्वजनिक तरीकों को अपवित्र नहीं किया जा सकता है। http://www.codeproject.com/Articles/20565/Assembly-Manipulation-and-C-VB-NET-Code-Injection

आप से बचने के लिए अपने विधानसभाओं पर हस्ताक्षर करना चाहिए:

अपने ValidateLicense की तरह किसी भी समारोह को आसानी से एक अच्छा परावर्तक एक वापसी पहली पंक्ति के रूप सच डालने :(मैं तुम्हें विधानसभाओं में कोड इंजेक्शन के बारे में इस articule की सिफारिश के साथ संशोधित किया जा सकता संशोधन, लेकिन ... हस्ताक्षर को प्रोपर टूल्स के साथ भी हटाया जा सकता है: http://www.nirsoft.net/dot_net_tools/strong_name_remove.html

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

+0

किसी भी सॉफ्टवेयर के रिवर्स इंजीनियरिंग से बचने के लिए कोई चाल नहीं है जो आपके अपने सर्वर पर नहीं रहती है। –

+1

रिफ्लेक्सिल के बारे में लेख प्रभावशाली रूप से .NET प्रतिबिंब की क्षमता का प्रदर्शन करता है! (या एक डेवलपर के परिप्रेक्ष्य से स्वेच्छा से;) –

2

एक दृष्टिकोण है कि कई सॉफ्टवेयर विक्रेताओं ने अपनाया है ऑनलाइन सक्रियण की आवश्यकता है। इस तरह, कुंजी सत्यापन कोड केवल आपके सर्वर पर निष्पादित किया जा सकता है, जो हैकर्स होने के लिए इसे कम सुलभ बना देगा।

बेशक, फिर आप एक कस्टम सर्वर को प्रमाणीकरण कॉल को फिर से राउट करने की नई भेद्यता को प्रस्तुत करते हैं जो सफलता प्रतिक्रिया भेजता है, अगर हैकर जानता है कि इस तरह की प्रतिक्रिया किस प्रकार देखने की उम्मीद है। लेकिन फिर, जैसा कि आप इंगित करते हैं, हमेशा ऐसा कोई होगा जो आपके उत्पाद को हैक करने में सक्षम होगा, इसलिए मैं अभी भी कहूंगा कि यह एक व्यवहार्य विकल्प है। सत्यापन के खिलाफ

+0

ठीक है, यह विकल्प 3 के लिए एक उत्कृष्ट बिंदु है। इसे एंटरप्राइज़ परिदृश्य में काम करने के लिए मुश्किल हो सकती है, इसलिए शायद मैं ऑफ़लाइन दृष्टिकोण से शुरू करूं और निगरानी कर सकता हूं कि मेरा ऐप वास्तव में क्रैकर्स को आकर्षित करता है या नहीं। –

2

तीन संभावित हमलों के वैध कोड

  • रिवर्स इंजीनियर सत्यापन तर्क प्रकट करने के लिए मान्यता हालत अनुमति देने के लिए संशोधित करके मुलाकात की
  • रिवर्स इंजीनियर सत्यापन तर्क यह करने के लिए कॉल को हटाने के द्वारा

    1. सत्यापन दरकिनार कर रहे हैं पर्यावरण

    एक दृष्टिकोण आपके आवेदन में कई बिंदुओं पर लाइसेंस को मान्य करना है - इससे 1 को कम करने में मदद मिलती है। कोड obfuscation 2 और 3 कम करने में मदद करता है - लेकिन आखिरकार यह एक अव्यवस्थित समस्या है।

    मेरी राय यह है कि इन दृष्टिकोणों का संयोजन बुनियादी प्रोग्रामर को आपके प्रोग्राम को चुरा लेने से रोक देगा, लेकिन फिर, अगर कुछ इसके लायक है - तो कोई ऐसा करेगा।

  • 0

    मुझे पता है कि यह जवाब नहीं है, लेकिन मैं .NET रिएक्टर http://www.eziriz.com/ का उपयोग करने का सुझाव दूंगा क्योंकि इसमें पहले से ही लाइसेंसिंग (विभिन्न लाइसेंसिंग परिदृश्यों के साथ) और मजबूत कोड सुरक्षा दोनों के लिए तंत्र हैं।

    संबंधित मुद्दे