सॉफ्टवेयर लाइसेंस कुंजी कैसे उत्पन्न और मान्य करें?

Question

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

जैसे कि एक लाइसेंस कुंजी का उपयोग करना आम तौर पर मुझे आश्चर्य हो रहा है:

1. यह कैसे आमतौर पर हल है?
2. मैं कुंजी कैसे उत्पन्न कर सकता हूं और इसे एप्लिकेशन द्वारा कैसे मान्य किया जा सकता है?
3. मैं इंटरनेट पर प्रकाशित होने वाली कुंजी और दूसरों द्वारा उपयोग किए जाने से कैसे बच सकता हूं, जिन्होंने लाइसेंस का भुगतान नहीं किया है (एक कुंजी जो मूल रूप से "उनके" नहीं है)।

मुझे लगता है कि मुझे किसी तरह एप्लिकेशन के संस्करण की कुंजी को भी टाई करना चाहिए ताकि फीचर संस्करणों में नई कुंजी के लिए चार्ज करना संभव होगा।

इस परिदृश्य में मुझे कुछ और सोचना चाहिए?

Answer 1

कैविएट: आप उपयोगकर्ताओं को समुद्री डाकू से नहीं रोक सकते, लेकिन केवल ईमानदार उपयोगकर्ताओं के लिए सही काम करना आसान बनाते हैं।

मान लें कि आप प्रत्येक उपयोगकर्ता के लिए एक विशेष निर्माण नहीं करना चाहते हैं, तो:

• अपने आप को उत्पाद के लिए एक गुप्त कुंजी उत्पन्न करें
• उपयोगकर्ता का नाम लें
• उपयोगकर्ताओं के नाम और गुप्त कुंजी और उदाहरण के लिए (SHA1) के साथ हैशेटनेट करें
• SHA1 हैश को अल्फ़ान्यूमेरिक स्ट्रिंग के रूप में अनपैक करें। यह व्यक्तिगत उपयोगकर्ता की "उत्पाद कुंजी" है
• कार्यक्रम के भीतर, एक ही हैश करें, और उत्पाद कुंजी के साथ तुलना करें। यदि बराबर है, ठीक है।

लेकिन, मैं दोहराता हूं: यह चोरी को नहीं रोकेगा

---

मैंने हाल ही में पढ़ा है कि यह दृष्टिकोण क्रिप्टोग्राफिक रूप से बहुत ध्वनि नहीं है। लेकिन यह समाधान पहले से ही कमजोर है ( जैसा कि सॉफ्टवेयर में ही गुप्त कुंजी को कहीं न कहीं शामिल करना है ), इसलिए मुझे नहीं लगता कि यह खोज जहां तक ​​जाती है समाधान को अमान्य कर देता है।

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

Comments

यदि कार्यक्रम में गुप्त कुंजी शामिल है (जैसा कि ऊपर दिए गए चरणों द्वारा निहित है), तो यह तुच्छ है

— स्टीवन ए। लोव

अधिक स्पष्ट होने के लिए संपादित; ओवर-कुछ पर जोर नहीं दे सकता है कि मूलभूत ;-)

— स्टीवन ए। लोव

कोड में रहस्य एम्बेड करने से बचने के लिए उत्पाद कुंजी को उत्पन्न करने और डिकोड करने के लिए एक असममित क्रिप्टोग्राफ़िक विधि (जैसे RSA) का उपयोग करें।

— आमिर मोघिमी

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

— जेमीबी

क्या लाइसेंस कुंजी में प्रतिबंध शामिल करना आम है? उदाहरण के लिए, समय की पाबंदी, समवर्ती उपयोगकर्ता गणना, स्थापित करने के लिए मॉड्यूल, आदि?

— कार्लो

Answer 2

लाइसेंस कुंजी उत्पन्न करने के कई तरीके हैं, लेकिन उनमें से बहुत कम ही तरीके वास्तव में सुरक्षित हैं। और यह अफ़सोस की बात है, क्योंकि कंपनियों के लिए, लाइसेंस कुंजी का वास्तविक नकदी के समान मूल्य है।

आदर्श रूप से, आप चाहते हैं कि आपके लाइसेंस कुंजियों में निम्नलिखित गुण हों:

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

2. एक लाइसेंस कुंजी केवल एक कंप्यूटर पर प्रयोग करने योग्य होनी चाहिए (या कम से कम आपको इसे बहुत कसकर नियंत्रित करने में सक्षम होना चाहिए)

3. एक लाइसेंस कुंजी फोन पर टाइप या डिक्टेट करने के लिए छोटी और आसान होनी चाहिए। आप नहीं चाहते कि हर ग्राहक तकनीकी सहायता को बुलाए क्योंकि उन्हें समझ नहीं आता है कि क्या कुंजी में "l" या "1" है। आपका समर्थन विभाग आपको इसके लिए धन्यवाद देगा, और इस क्षेत्र में आपकी लागत कम होगी।

तो आप इन चुनौतियों को कैसे हल करते हैं?

1. इसका उत्तर सरल लेकिन तकनीकी रूप से चुनौतीपूर्ण है: सार्वजनिक कुंजी क्रिप्टोग्राफी का उपयोग करके डिजिटल हस्ताक्षर। आपकी लाइसेंस कुंजी वास्तव में हस्ताक्षरित "दस्तावेज़" होनी चाहिए, जिसमें आपकी कंपनी की निजी कुंजी के साथ कुछ उपयोगी डेटा शामिल हैं। हस्ताक्षर लाइसेंस कुंजी का हिस्सा होना चाहिए। उत्पाद को संबंधित सार्वजनिक कुंजी के साथ लाइसेंस कुंजियों को मान्य करना चाहिए। इस तरह, यहां तक ​​कि अगर किसी के पास आपके उत्पाद के तर्क तक पूर्ण पहुंच है, तो वे लाइसेंस कुंजी उत्पन्न नहीं कर सकते, क्योंकि उनके पास निजी कुंजी नहीं है। एक लाइसेंस कुंजी इस तरह दिखाई देगी: BASE32 (CONCAT (DATA, PRIVATE_KEY_ENCRYPTED (HASH (DATA)))) यहां सबसे बड़ी चुनौती यह है कि शास्त्रीय सार्वजनिक कुंजी एल्गोरिदम के बड़े हस्ताक्षर आकार हैं। RSA512 में 1024-बिट हस्ताक्षर हैं। आप नहीं चाहते कि आपके लाइसेंस कुंजी में सैकड़ों वर्ण हों। सबसे शक्तिशाली दृष्टिकोणों में से एक अण्डाकार वक्र क्रिप्टोग्राफी (मौजूदा पेटेंट से बचने के लिए सावधानीपूर्वक कार्यान्वयन के साथ) का उपयोग करना है। ECC कुंजियाँ समान शक्ति के लिए RSA कुंजियों से 6 गुना छोटी होती हैं। आप स्चोरिअम डिजिटल सिग्नेचर अल्गोरिथम जैसे एल्गोरिदम का उपयोग करके हस्ताक्षर आकार को और कम कर सकते हैं (पेटेंट 2008 में समाप्त हो गया - अच्छा :))

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

3. ठीक है, बस "कुंजी" जैसे "1", "एल", "0", "ओ" को अपने कुंजियों से हटा दें। वर्णों के समूहों में लाइसेंस कुंजी स्ट्रिंग को विभाजित करें।

Comments

क्या वे कोड को जोड़ने / हटाने वाले सॉफ़्टवेयर को संपादित नहीं कर सकते थे, जैसे कि चेक को पूरी तरह से छोड़ दिया गया हो?

— पचेरियर

क्या नंबर 1 के जवाब के लिए अनिवार्य रूप से एक ऑनलाइन सक्रियण / निष्क्रियकरण सेवा की आवश्यकता है?

— दान डब्ल्यू

मैं यह बताना चाहता हूं कि यह उत्तर दूसरी हैश चीज़ से कितना बेहतर है।

— एरिक एरोनिटी

@ स्पेसर कई चीजें हैं जो लाइसेंस कुंजी से सॉफ्टवेयर कंपनियों की रक्षा करती हैं। निर्वासन को संशोधित करना उनमें से एक नहीं है।

— एरिक एरोनेस्टी

यह ध्यान देने योग्य है कि एसिमेट्रिक क्रिप्टोग्राफी निजी / सार्वजनिक कुंजी के साथ, यह अभी भी नकली लाइसेंस उत्पन्न करना संभव है, बस सार्वजनिक कुंजी को सॉफ़्टवेयर में किसी अन्य सार्वजनिक कुंजी के साथ बदलकर, और नकली लाइसेंस पर हस्ताक्षर करने के लिए अपनी संबंधित निजी कुंजी का उपयोग करके। यही कारण है कि हमारे पास विश्वसनीय प्रमाणपत्र प्राधिकारी बीटीडब्ल्यू हैं, जो पहचान के लिए सार्वजनिक कुंजी को बांधते हैं। इसलिए जब यह कूदने के लिए एक और घेरा जोड़ सकता है, तो यह # 1 गारंटी नहीं देता है।

— साब अमीनी

Answer 3

सरल उत्तर - आप किस योजना का उपयोग करते हैं, इससे कोई फर्क नहीं पड़ता।

हैकर को रोकने के लिए एक प्रणाली के साथ ईमानदार ग्राहकों को दंडित न करें, क्योंकि हैकर्स इसकी परवाह किए बिना दरार करेंगे।

एक साधारण हैशेड कोड जो उनके ईमेल या समान से जुड़ा होता है, संभवतः काफी अच्छा होता है। हार्डवेयर आधारित आईडी हमेशा एक मुद्दा बन जाता है जब लोगों को हार्डवेयर को पुनर्स्थापित या अपडेट करने की आवश्यकता होती है।

मुद्दे पर अच्छा सूत्र: http://discuss.joelonsoftware.com/default.asp?biz.5.82298.34

Comments

सहमत, आप उन उपयोगकर्ताओं को परेशान नहीं करना चाहते जो वास्तव में आपके उत्पाद को खरीद रहे हैं! (pay heed m $, apple, etc ...)

— जेसन

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

— schooner

एक पब / प्राइवेट की-साइन साइनिंग स्कीम उन यूजर्स के लिए नई वैध कुंजी बनाने के लिए "क्रैक" नहीं किया जा सकता है, जो क्रैक्ड सॉफ्टवेयर के बजाय पब्लिशर्स साइट से डाउनलोड किए गए हस्ताक्षरित कोड को चलाना चाहते हैं। जबकि अमान्य लोगों से अप्रत्यक्ष रूप से नए वैध लाइसेंस कुंजियों का उत्पादन करने के लिए एक हैश / सममित योजना को क्रैक किया जा सकता है। बड़ा अंतर।

— एरिक एरोनिटी

टूटा हुआ लिंक ....

— कलंक

Answer 4

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

जब आपको एस्ट्रोविस्टा.बॉक्स में कुछ कुंजियाँ या पैच तैरने लगते हैं, तो आपको पता चल जाएगा कि आप कुछ ऐसा लोकप्रिय बनाने में सफल हुए हैं, जिसे किसी ने क्रैक करने के लिए परेशान किया है। ख़ुश हो जाओ!

Comments

"संस्करण को संक्षिप्त करना और स्ट्रिंग को संख्या का निर्माण करना न भूलें, जिस पर आप हैश की गणना करते हैं" - लेकिन क्या यह महत्वपूर्ण ब्रेक नहीं करेगा जब उपयोगकर्ता एक छोटे पैच रिलीज के लिए अपडेट करता है?

— थोमथोम

@thomthom कैसे फिर एक कुंजी के लिए एक अधिकतम संस्करण संबद्ध करने के बारे में? संस्करण विचार अपने आप में प्रशंसनीय है और अधिक सुरक्षा जोड़ता है

— मार्विन थोबजाने

@MarvinThobejane एक अधिकतम वेरिफ़िकेशन को संबद्ध करने के लिए जिसे आप अधिकतम सत्यापित कर सकते हैं कि अनुमति दी गई है, और इसका कोड इटरेट है जो थोड़ा सा संस्करण है। लेकिन नहीं> = sigs में अनुमति दी ऑप्स।

— एरिक एरोनिटी

Answer 5

इसके अलावा जो पहले ही कहा जा चुका है ...।

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

अब आप कुंजी बनाने के लिए हार्डवेयर मान का उपयोग भी नहीं कर सकते हैं। वर्चुअल मशीनें अब किसी को 'लाइसेंस प्राप्त' मशीन की एक छवि बनाने और इसे किसी भी मंच पर चलाने की अनुमति देती हैं जो वे चुनते हैं।

यदि यह महंगा सॉफ्टवेयर है तो अन्य उपाय भी हैं। यदि यह नहीं है, तो बस आकस्मिक हैकर के लिए इसे काफी मुश्किल बना दें। और इस तथ्य को स्वीकार करें कि अंततः वहां बिना लाइसेंस वाली प्रतियां होंगी।

यदि आपका उत्पाद जटिल है, तो अंतर्निहित समर्थन मुद्दे आपके लिए कुछ सुरक्षा बनाएंगे।

Comments

वर्चुअल मशीन की वजह से हार्डवेयर मूल्यों पर कमजोरी को रोकने के लिए +1।

— मारीनुज़ो

पीई के लिए .NET और ऑथेंटिकोड के लिए मजबूत नामकरण क्या है। यदि किसी ने आपकी लाइब्रेरी को विघटित, संशोधित और पुनर्निर्मित किया है तो उस पर हस्ताक्षर नहीं किए जाएंगे और एप्लिकेशन बस नहीं चलेगा। .NET वर्चुअल मशीन इसे अनुमति नहीं देगी।

— स्टीफन ट्यूनी

हस्ताक्षर आपके द्वारा चलाए जाने वाले कार्यक्रम की उत्पत्ति को मान्य करने के लिए है। यदि उपयोगकर्ता मूल के बारे में परवाह नहीं करता है क्योंकि वह जानता है कि यह संशोधित और टूट गया है, तो पटाखा हस्ताक्षर को हटा देगा, या यहां तक ​​कि अपने स्वयं के हस्ताक्षर के साथ भी हस्ताक्षर कर सकता है। हस्ताक्षर करने से भरोसेमंद असेंबलियों को अविश्वसनीय असेंबलियों के साथ मिलाना बंद हो जाता है।

— jesusduarte

महंगे सॉफ्टवेयर के लिए ज्यूरी-रिग्ड हार्डवेयर डोंगल के रूप में मोबाइल ऐप का उपयोग किया जा सकता है .... बस ऐप का उपयोग करके भुगतान करें, और ऐप के सुरक्षित तत्व में हस्ताक्षर कुंजी को एम्बेड करें। फिर आप डेस्कटॉप + ऐप का उपयोग करके सक्रिय कर सकते हैं ... दूसरे डेस्कटॉप को निष्क्रिय कर सकते हैं। एप्लिकेशन में और / या ऑनलाइन होमोमोर्फिक कम्प्यूटेशन सेवाओं में कुछ महत्वपूर्ण अनुभाग कोड क्षेत्रों को सम्मिलित करने से तुच्छ विघटन को रोकने में मदद मिल सकती है।

— एरिक एरोनिटी

Answer 6

लाइसेंस कुंजी के लिए हम जिस C # / .NET इंजन का उपयोग करते हैं, उसे अब खुले स्रोत के रूप में बनाए रखा गया है:

https://github.com/appsoftware/.NET-Licence-Key-Generator ।

यह एक "आंशिक कुंजी सत्यापन" प्रणाली पर आधारित है, जिसका अर्थ है कि कुंजी का एक सबसेट जिसका उपयोग आप कुंजी उत्पन्न करने के लिए अपने वितरण में संकलित करने के लिए करते हैं। आप कुंजियों को स्वयं बनाते हैं, इसलिए लाइसेंस कार्यान्वयन आपके सॉफ़्टवेयर के लिए अद्वितीय है।

जैसा कि ऊपर कहा गया है, यदि आपका कोड विघटित हो सकता है, तो अधिकांश लाइसेंसिंग सिस्टम को दरकिनार करना अपेक्षाकृत आसान है।

Comments

क्या आप इस उत्पाद का उपयोग करने के लिए एक ट्यूटोरियल करने के लिए तैयार हैं? मुझे उनकी विकी थोड़ी कमी लगी।

— एंथनी रफ़िनो

यदि यह मदद करता है तो परियोजना को अब GitHub पर खोला गया है।

— gb2d

Answer 7

मैं क्रिप्टोलेंस सॉफ़्टवेयर लाइसेंसिंग प्लेटफ़ॉर्म के पीछे डेवलपर्स में से एक हूं और 14 साल की उम्र से लाइसेंसिंग सिस्टम पर काम कर रहा हूं। इस उत्तर में, मैंने वर्षों से प्राप्त अनुभव के आधार पर कुछ युक्तियों को शामिल किया है।

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

लाइसेंस कुंजी सर्वर के लाभ

लाइसेंस कुंजी सर्वर के साथ लाभ यह है कि:

1. आप हमेशा तत्काल प्रभाव से लाइसेंस कुंजी को अपडेट या ब्लॉक कर सकते हैं।
2. प्रत्येक लाइसेंस कुंजी को कुछ निश्चित मशीनों पर बंद किया जा सकता है (यह उपयोगकर्ताओं को दूसरों के उपयोग के लिए लाइसेंस कुंजी को ऑनलाइन प्रकाशित करने से रोकने में मदद करता है)।

विचार

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

समाधान हमेशा सार्वजनिक कुंजी क्रिप्टोसिस्टम जैसे कि आरएसए या ईसीसी (संभवतः यदि आप एम्बेडेड सिस्टम पर चलने की योजना बनाते हैं) का उपयोग करके सर्वर से लाइसेंस कुंजी प्रतिक्रिया पर हस्ताक्षर करें। आपके आवेदन में केवल लाइसेंस कुंजी प्रतिक्रिया को सत्यापित करने के लिए सार्वजनिक कुंजी होनी चाहिए ।

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

ध्यान दें कि आपको हमेशा लाइसेंस कुंजी प्रतिक्रिया के प्रमाण पत्र की जांच करनी चाहिए, भले ही आप इंटरनेट से जुड़े हों), यह सुनिश्चित करने के लिए कि यह सर्वर से छूटने के बाद इसे बदला नहीं गया है (यह अभी भी करना है, भले ही आपका एपीआई लाइसेंस कुंजी सर्वर https का उपयोग करता है)

गुप्त एल्गोरिदम की रक्षा करना

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

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

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

कार्यान्वयन

यदि आप स्वयं सब कुछ लागू नहीं करना चाहते हैं, तो मैं इस ट्यूटोरियल ( क्रिप्टोलेंस का हिस्सा ) पर एक नज़र डालने की सलाह दूंगा

Comments

सहेजे गए लाइसेंस कुंजी को बहुत पुराना नहीं होने के लिए प्रतिबंधित करने के बारे में एक सवाल: चूंकि पीसी इंटरनेट से जुड़ा नहीं हो सकता है, इसलिए उनकी तारीख और समय को हमेशा उसी वैध तारीख पर रहने के लिए वापस बदला जा सकता है?

— अमीर महदी नासिरी

क्या उपयोगकर्ता विंडोज में लूपबैक होस्ट को परिभाषित करके ऑनलाइन लाइसेंस सर्वर को बायपास नहीं कर सकते हैं? मैंने देखा है कि कई अनुप्रयोगों को इस तरह से तैयार किया जा रहा है, रेस्परर और मैटलैब हैं जिन्हें मैं याद रख सकता हूं।

— अमीर महदी नासिरी

@AmirMahdiNassiri प्रश्न 1 के लिए: यदि पीसी स्थायी रूप से ऑफ़लाइन है, तो आप वास्तविक समय घड़ी (RTC) डोंगल को समय के लिए विश्वसनीय स्रोत के रूप में उपयोग कर सकते हैं। प्रश्न 2 के लिए: चूंकि विक्रेता के निजी कुंजी के साथ प्रतिक्रिया पर हस्ताक्षर किए जाते हैं (और आवेदन के अंदर सार्वजनिक कुंजी के साथ सत्यापित), एक विरोधी को निजी कुंजी को जानने के बिना फाइल पर फिर से हस्ताक्षर करने की आवश्यकता होगी, जो कि लेखन के समय है, 2048bit RSA कुंजी के साथ संभव नहीं है।

— Artem

Answer 8

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

आप किसी भी लाइसेंस योजना के साथ केवल एक बिंदु तक ही सॉफ़्टवेयर की सुरक्षा कर सकते हैं।

Answer 9

मैं नहीं जानता कि आप कैसे प्राप्त करना चाहते हैं

लेकिन मेरा मानना ​​है कि .net हार्ड ड्राइव सीरियल नंबर को एक्सेस कर सकता है।

आप प्रोग्राम को भेज सकते हैं कि आप और कुछ ईल (जैसे उपयोगकर्ता नाम और निक का मैक पता)

आप उस पर आधारित एक कोड की गणना करते हैं और उन्हें कुंजी वापस ईमेल करते हैं।

उनके पास चाबी रखने के बाद उन्हें स्विचिंग मशीनों से रखा जाएगा।

Comments

और उन्हें एक मृत HD amoung अन्य thigns की जगह से रखने के लिए, हताशा के लिए अग्रणी। दुर्भाग्य से कोई आसान जवाब नहीं है, आपको बुनियादी लाइसेंसिंग यांत्रिकी के साथ विश्वास को संतुलित करने की आवश्यकता है।

— schooner

एक सॉफ्टवेयर इंजीनियर के रूप में कई वर्षों तक काम किया, जिसमें एक उत्पाद का उपयोग किया गया था, जो सीरियल नंबर को एचडी से दूर करता था, यह पूरी तरह से उन लोगों के लिए असुरक्षित था जो इसे अपडेट करना जानते थे।

— Oden

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

— क्रैश893

Answer 10

आपके द्वारा मांगी गई हर चीज को करने का एकमात्र तरीका सर्वर के साथ इंटरनेट एक्सेस और सत्यापन की आवश्यकता है। एप्लिकेशन को कुंजी के साथ सर्वर में साइन इन करने की आवश्यकता होती है, और फिर आपको आईपी पते की तरह सत्र विवरण संग्रहीत करने की आवश्यकता होती है। यह कुंजी को कई अलग-अलग मशीनों पर उपयोग करने से रोक देगा। यह आमतौर पर एप्लिकेशन के उपयोगकर्ताओं के साथ बहुत लोकप्रिय नहीं है, और जब तक यह बहुत महंगा और जटिल एप्लिकेशन नहीं है, तब तक इसके लायक नहीं है।

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

Comments

मैंने एक ऐसी कंपनी में काम किया, जो इंटरनेट आधारित लाइसेंसिंग योजना का उपयोग करती थी। हर बार जब यह कार्यक्रम शुरू हुआ तो यह ऑनलाइन मान्य हो गया, मुझे लगता है कि कंपनी ने अपने लाइसेंस समाधान के लिए बुनियादी ढांचे और डेवलपर्स पर अधिक $ $ खर्च किए, क्योंकि वे चोरी से खो गए थे (वे एक आला उत्पाद थे)।

— जेसन

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

— जेसन

ऐसा लगता है कि आपकी कंपनी को हर बार स्टार्टअप पर सत्यापन की आवश्यकता के कारण थोड़ा अधिक निराशा हुई थी।

— jugg1es

@ जेसन, ठीक है, उन्हें उत्पाद की कीमत बढ़ानी चाहिए।

— पेसियर

@ स्पेसर: गलत जवाब।

— लाइटवेट रेस इन ऑर्बिट

Answer 11

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

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

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

Comments

लेकिन वेब लाइसेंसिंग के साथ मुख्य समस्या यह है कि लाइसेंसिंग सेवा DDoS हमलों के लिए एक प्रमुख लक्ष्य बन जाती है .. जो या तो सेवा को पंगु बना देती है या क्लाउड लागत को बढ़ा देती है।

— afk5min

यह कहने की तरह है कि इसका कोई मतलब नहीं है क्योंकि यह डीडीओएस के हमलों के लिए असुरक्षित है ...

— jugg1es

@ jugg1es ने अपनी टिप्पणी में कहीं नहीं कहा कि "उसका कोई मतलब नहीं है"। उन्होंने बस इस तथ्य को इंगित किया कि यह एक भेद्यता है जिस पर विचार किया जाना चाहिए।

— डैन बेहार्ड

और चेक अभी भी क्लाइंट में निकाले जा सकते हैं। कोई जाँच नहीं, कोई वेब लाइसेंसिंग नहीं ...

— azarai

क्या आपका मतलब "आवश्यक जानकारी" के साथ वास्तविक एप्लिकेशन कोड है? कोड जो एप्लिकेशन को चलाने के लिए आवश्यक होगा? अन्यथा मुझे लगता है कि यह अभी भी कॉल करने में परिणाम होगा चेक वाले तरीकों को कोड में।

— अजरई

Answer 12

मेरा दृढ़ता से मानना ​​है, कि केवल सार्वजनिक कुंजी क्रिप्टोग्राफी आधारित लाइसेंसिंग प्रणाली यहाँ सही दृष्टिकोण है, क्योंकि आपको लाइसेंस स्रोत के लिए आवश्यक आवश्यक जानकारी को अपने सोर्सकोड में शामिल नहीं करना है।

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

Comments

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

— डैन डब्ल्यू

नहीं, आपको ऑनलाइन सक्रियण सेवा का उपयोग करने की आवश्यकता नहीं है। आप लाइसेंस फ़ाइलों को पूरी तरह से ऑफ़लाइन उत्पन्न कर सकते हैं।

— पनपरनिसक

कुंजी वास्तव में है, कि आप कोड के लिए केवल सार्वजनिक कुंजी रख रहे हैं, जिसका उपयोग लाइसेंस उत्पादन के लिए नहीं किया जा सकता है। केवल इसके सत्यापन के लिए।

— panpernicek

Answer 13

कुछ अन्य लोगों की तरह, मैं डिफ़ॉल्ट रूप से ग्राहकों के लिए शत्रुतापूर्ण होने का बहुत बड़ा विरोधी हूं - कुछ ऐसा जो लाइसेंस उद्योग के लिए कुख्यात है। तो मैं आपकी समस्या के लिए एक अच्छे समाधान पर विस्तार करूँगा जो एक अच्छा ग्राहक UX प्रदान करता है ।

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

मैंने Keygen को इस प्रकार के लाइसेंसिंग को ध्यान में रखते हुए बनाया है। Keygen एक लाइसेंसिंग REST API है जो आपको उपयोगकर्ता खातों, लाइसेंसों और मशीन उपयोग / संघों को ट्रैक करने की अनुमति देता है।

मैं क्या करूंगा 2 लाइसेंस प्रकार ( Keygen के भीतर एक नीति ) स्थापित किया गया है, जहां एक सीमित मुफ्त संस्करण के लिए एक आधार नीति है, और दूसरा भुगतान किए गए संस्करण के लिए एक नीति है।

मुझे यकीन नहीं है कि आप भुगतान के लिए क्या उपयोग कर रहे हैं, लेकिन चलो मान लेते हैं कि आप स्ट्राइप (आजकल सुंदर मानक) जैसी किसी चीज़ का उपयोग कर रहे हैं जो वेबहूक प्रदान करती है । कीजेन में वेबहूक भी है (आप इसका उपयोग करते हैं या नहीं, यह सब अभी भी लागू है)। आप दोनों ओर से वेबहुक का उपयोग करके अपने भुगतान प्रदाता के साथ बात करने के लिए Keygen को एकीकृत कर सकते हैं (विचार करें: customer.created-> ग्राहक के लिए आधार लाइसेंस बनाएं, license.created- नए लाइसेंस के लिए ग्राहक से शुल्क लें)।

तो webhooks का उपयोग करके, हम नए ग्राहकों के लिए लाइसेंस निर्माण को स्वचालित कर सकते हैं। तो आवेदन के भीतर लाइसेंस सत्यापन के बारे में क्या? यह कई तरीकों से किया जा सकता है, लेकिन सबसे लोकप्रिय तरीका यह है कि आप अपने ग्राहक को एक इनपुट क्षेत्र में एक लंबी लाइसेंस कुंजी दर्ज करने की आवश्यकता करें, जिसे आप तब सत्यापित कर सकते हैं; मुझे लगता है कि आपके आवेदन में लाइसेंस सत्यापन को संभालने के लिए यह एक भयानक तरीका है।

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

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

इससे आपको क्या फायदा? सबसे पहले, यह आपके और आपके ग्राहकों के लिए लाइसेंस कुंजियों पर नज़र रखने की आवश्यकता से छुटकारा दिलाता है, क्योंकि यह सभी अपने उपयोगकर्ता खाते के अंदर-और-उसके पीछे सबसे महत्वपूर्ण रूप से नियंत्रित किया जाता है : अब आप अपने ग्राहकों को स्वयं-सेवा लाइसेंस और मशीन की पेशकश कर सकते हैं सक्रियण! जब से उनके सभी लाइसेंस और मशीनें उनके उपयोगकर्ता खाते से जुड़ी होती हैं, तो आप उन्हें एक गैर-मान्यता प्राप्त मशीन पर आपके आवेदन को आग लगाने पर लाइसेंस खरीदने के लिए संकेत दे सकते हैं।

अब लाइसेंस सत्यापन पर : जब भी आपका ग्राहक आपके ईमेल / पासवर्ड के साथ आपके आवेदन में लॉग इन करता है, तो आप लाइसेंस के लिए अपने उपयोगकर्ता खाते को उनके द्वारा निर्धारित कर सकते हैं कि क्या वे सुविधा-एक्स या सुविधा-वाई का उपयोग कर सकते हैं । और जब से आपका आवेदन अब स्व-सेवा है , आप अपने ग्राहकों को अपने आवेदन में सीधे अतिरिक्त सुविधाओं को खरीदने की अनुमति दे सकते हैं!

इसलिए हमने अपने लाइसेंस प्रणाली के लिए एक टन स्वचालन प्रदान किया है, हम अलग-अलग सुविधाओं को लाइसेंस दे सकते हैं (यानी एक सीमित बनाम पूर्ण संस्करण), हमने अपने ग्राहकों के लिए एक शानदार UX की पेशकश की है और हमने सबसे बड़े कारणों में से एक को भी समाप्त कर दिया है समर्थन अनुरोधों के लिए: लाइसेंस कुंजी पुनर्प्राप्ति।

वैसे भी, यह लंबा है, लेकिन उम्मीद है कि यह किसी की मदद करता है!

Comments

किसी भी उद्यम विकास की स्थिति में इस तरह से लाइसेंस प्राप्त किए जा रहे डीएलएल की कल्पना नहीं कर सकते। उदाहरण के लिए, स्वचालित निर्माण और परिनियोजन परिदृश्यों के बारे में सोचें। या बस एक डेवलपर मशीन स्थापित करने के लिए आवश्यक कई के लिए इस कदम को जोड़ना। मेरे लिए, लाइसेंस कुंजियों को पूर्व-जारी किए जाने की आवश्यकता है, न कि व्यक्तिगत मशीनों पर आधारित, व्यावहारिक होने के लिए

— DvS

Answer 14

सॉफ्टवेयर चोरी को पूरी तरह से रोकना संभव नहीं है। आप कैज़ुअल पाइरेसी को रोक सकते हैं और यही सभी लाइसेंसिंग सॉल्यूशंस उनके काम को पूरा करते हैं।

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

Answer 15

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

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

आपको अपने तैयार सॉफ्टवेयर को De4Dot और .NetReflector के माध्यम से रिवर्स-इंजीनियर तक चलाना चाहिए और यह देखना चाहिए कि पटाखा क्या देखेगा यदि उन्होंने भी यही काम किया है और यह सुनिश्चित करने के लिए कि आपने कोई महत्वपूर्ण कोड उजागर नहीं किया है या अनजाने में नहीं छोड़ा है।

आपका सॉफ़्टवेयर अभी भी क्रैकेबल होगा, लेकिन कैज़ुअल क्रैकर के लिए यह उन्हें बंद करने के लिए पर्याप्त हो सकता है और ये सरल कदम आपके कोड को निकालने और फिर से उपयोग करने से भी रोकेंगे।

https://quantum-key.net

ConfuserEx का उपयोग कैसे करें?

https://github.com/0xd4d/de4dot

https://www.red-gate.com/dynamic/products/dotnet-development/reflector/download