'क्रैक-सबूत' सॉफ़्टवेयर को डिजाइन करने के लिए सलाह की आवश्यकता है

Question

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

कोई मुझे कुछ सभ्य मंच, मेलिंग सूची या ऐसा कुछ करने के लिए मार्गदर्शन कर सकता है? या किसी अन्य मदद की सराहना की जाएगी।

Answer 1

क्या आपका उत्पाद क्रैक होने पर सफलता का संकेत नहीं है? :)

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

लेकिन अभी भी सर्वव्यापी "IsValid()" विधि है जिसे हमेशा सत्य वापस करने के लिए क्रैक किया जा सकता है।

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

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

हमें विश्वास है हमारे वैध ग्राहकों लाइसेंस बायपास करने के लिए कोशिश नहीं की है, और हम स्वीकार करते हैं कि हमारे नाजायज ग्राहकों के लिए एक रास्ता मिल जाएगा।

हम और अधिक पैसा बर्बाद 'छेड़छाड़ सबूत' हमारे समाधान की प्रकृति है कि हम लोग हैं, जो सॉफ्टवेयर समुद्री डाकू ढीला imporve करने का प्रयास करेंगे।

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

वैसे भी, पर जो समाधान आप जगह में पहले से ही मिल गया है निर्भर करता है, ऊपर मेरी वर्णन आप कुछ विचार है कि संभावना किसी को अपने उत्पाद दरार होगा कम हो सकती है दे सकता है।

Answer 2

मैं आपको "क्रैकप्रूफ" की सबसे नज़दीकी चीज़ बताऊंगा: एक वेब एप्लिकेशन।

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

एक डेस्कटॉप सॉफ़्टवेयर क्लाइंट के कंप्यूटर पर चलता है, इसलिए क्लाइंट के पास इसकी पूर्ण पहुंच है। एक वेब ऐप आपके सर्वर पर चलता है, इसलिए क्लाइंट केवल इसका एक छोटा सा हिस्सा देखता है।

Answer 3

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

Answer 4

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

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

Answer 5

आपको स्थानीय हैकिंग गिरोह घुसपैठ करके शुरू करना होगा, जो 11 वर्षीय के रूप में प्रस्तुत होगा, जो इसे "हैक करना" चाहता है। एक बार जब आप अपना विश्वास अर्जित कर लेते हैं तो आप सीख सकते हैं कि उन्हें कौन सी विशेषताओं को क्रैक करने के लिए सबसे कठिन लगता है। चूंकि आप गुप्त रूप से स्थानीय संदेश बोर्डों को "अचूक" सॉफ़्टवेयर जारी करते हैं, तो आप देख सकते हैं कि वे इसके साथ क्या करते हैं। अपने आंतरिक ज्ञान पर तब तक निर्माण करें जब तक कि वे आपके सॉफ़्टवेयर को क्रैक नहीं कर सकें। जब यह किया जाता है, तो अपनी पहचान ज्ञात हो। आदर्श रूप में, इसे विश्वासघात के संकेत के रूप में देखा जाएगा, कि आप उनके खिलाफ काम कर रहे हैं। उम्मीद है कि इससे उन्हें आपके समुदाय पर हमला करने के लिए स्थानीय समुदाय के बाहर अन्य हैकर्स से संपर्क करने का मौका मिलेगा।

तब तक जारी रखें जब तक आप हैकर माफिया के शीर्ष तक नहीं पहुंच जाते। अपनी थीसिस को एक किताब के रूप में लिखें, एचबीओ को बेच दें।

Answer 6

जैसा कि नट ने कहा, किसी भी कोड को आप ग्राहक की मशीन पर छोड़ देते हैं तो यह क्रैक करने योग्य है।

"अचूक" के लिए प्रयास न करें। "मेरी संपत्तियों को उचित रूप से सुरक्षित रखने के लिए पर्याप्त प्रतिबंधक" की कोशिश करें।

क्रैकिंग की लागत को बढ़ाने और बढ़ाने के कई तरीके हैं। उनमें से अधिकांश आपको लागत देते हैं लेकिन एक चीज है जो आप कर सकते हैं जो वास्तव में क्रैकिंग की लागत में वृद्धि करते समय आपकी लागत कम कर देता है: अक्सर वितरित करें।

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

1. जिनके लिए नवीनतम सुविधाओं की आवश्यकता नहीं है और एक दरार की प्रतीक्षा कर सकते हैं।
2. जो लोग नवीनतम सुविधाओं की आवश्यकता रखते हैं और आपके सॉफ़्टवेयर के लिए भुगतान करेंगे।

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

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

Answer 7

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

यदि आप वर्चुअल मशीन पर तैनात हैं, तो यह बहुत बुरा है। वहां कई विकल्प नहीं हैं। सभी लोकप्रिय vms (जावा, clr, आदि) decompile के लिए बहुत आसान हैं, और कोई obfuscator और न ही हस्ताक्षर पर्याप्त है।

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

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

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

कुछ एंटी-डिबगिंग चाल हैं जिन्हें आप भी देख सकते हैं। लेकिन यह आपके लिए परेशानी है, क्योंकि कुछ समय में आपको रिलीज एप्लिकेशन को डीबग करने की भी आवश्यकता हो सकती है!

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