फैलो प्रोग्रामर ने सबसे खराब प्रोग्रामिंग प्रथाओं का इस्तेमाल किया


37

मुझे पता है कि यह कहना अजीब लगता है, लेकिन काम पर एक साथी प्रोग्रामर ने जानबूझकर खराब प्रोग्रामिंग प्रथाओं के एक जोड़े का इस्तेमाल किया! मैं समझाऊंगा। पहले मुझे यह कहना चाहिए कि वह एक बुद्धिमान लड़का है और अधिकांश भाग के लिए वह समझदार कोड लिखता है।

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

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

.. जो मुझे एक दुविधा में छोड़ देता है। क्या मैं जावा में एक ऑबफ्यूज़ेटर लाइब्रेरी की तलाश करता हूं और उसका पुराना कोड ठीक कर सकता हूं (जो उसके कोड को रीमॉडेल करने के बारे में थोड़ा मार्मिक हो सकता है), या क्या मैं इसे उतना ही छोड़ दूं, जितना कि मुझे कोई अंत नहीं है?


4
यदि आपका सवाल इस स्थिति की राजनीति को संभालने के तरीके के बारे में है, तो यहां कई उत्तर सही दिशा में इशारा कर रहे हैं, लेकिन अगर आपकी एक टिप्पणी के अनुसार, आप वास्तव में प्रस्ताव करने के लिए एक बेहतर विकल्प चाहते हैं, तो आप जांचना चाहते हैं। इस सवाल का जवाब: stackoverflow.com/questions/6018215/…
मार्क बूथ

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

2
क्या वह स्थानीय लोगों का नाम बदल रहा था? यदि हां, तो वह अपना समय बर्बाद कर रहा है - वे वैसे भी संकलित कोड में नामांकित चर के रूप में मौजूद नहीं हैं।
निक जॉनसन

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

6
"इस समस्या का उनका समाधान वस्तुतः चर-अचरजों और विधियों को कम-से-स्पष्ट नामों से पुकारना और नई कक्षाओं को उत्पन्न करने के बजाय पहले से ही भीड़भाड़ वाली कक्षाओं के अंदर रखना था।" और "पहले मुझे यह कहने दो कि वह एक बुद्धिमान लड़का है" एक ही पैराग्राफ में अच्छी तरह से मत जाओ!
नटखट Elysium

जवाबों:


94

स्थगन के माध्यम से सुरक्षा कभी भी अच्छी सुरक्षा नहीं है। अपनी बौद्धिक संपदा की सुरक्षा के बेहतर तरीके होने चाहिए। और वह यह है कि आपको और आपके सहयोगी को अपने प्रबंधक के साथ एक संयुक्त चिंता के रूप में लाना चाहिए। यदि प्रबंधन तब निर्णय लेता है कि वे बेहतर सुरक्षा पर समय या पैसा खर्च नहीं करना चाहते हैं, तो आप दोनों को उस निर्णय के साथ रहना होगा (यह आपका उत्पाद नहीं है, यह कंपनी का उत्पाद है) और बेहतर खर्च नहीं करना (बर्बाद?) किसी भी अधिक समय विषय पर।


31
+1 Obfuscation सुरक्षा नहीं है, बस एक कंबल है।
uɐɪ

7
यदि आप आक्षेप से बेहतर समाधान के साथ आ सकते हैं, तो मैं आपके उत्तर को सही मानूंगा। आप कैसे गारंटी दे सकते हैं कि युद्ध की फाइल तक पहुंच रखने वाला कोई व्यक्ति अपनी कार्यक्षमता को कम से कम क्या चिंताओं के लिए संशोधित नहीं कर सकता है?
नील

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

7
@ नील: मुख्य व्यवसाय तर्क को USB डोंगल के रूप में संलग्न एक माइक्रोकंट्रोलर में लागू करें। आपने यह नहीं कहा कि इसे सस्ता या लागू करना आसान है;)
एसएफ।

8
@SF:। टच। मुझे लगता है कि इसे तीन उपग्रहों को एक साथ लिंक करने की आवश्यकता है, बस इसके नरक के लिए। ;)
नील

84

मूल: आपके बॉस क्या कहते हैं? पता करें - ऐसा करें।


मुझे ऊपर विस्तार करने के लिए कहा गया था:

सबसे पहले, मुझे लगता है कि आपके पास एक से अधिक दुविधा है:

  • क्या आपको अन्य व्यक्तियों के कोड को "ठीक" करना चाहिए?
  • क्या अन्य लोगों का कार्यान्वयन (एफ़रोम ए) इतना बुरा है कि इसे किसी और चीज़ से बदल दिया जाना चाहिए?
  • क्या एक ऑबफ्यूज़र (एफ़्रॉम बी) इसके लिए बेहतर होगा "हमारे आवेदन में लाइसेंस एम्बेड करें"?

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

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

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

दूसरे शब्दों में: आपका बॉस क्या कहता है? पता करें - ऐसा करें।

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

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

उम्मीद है कि यह मेरी बात को स्पष्ट करता है।


8
मेरा मालिक कोई प्रोग्रामर नहीं है और मुझे शायद यह समझाने में मुश्किल समय होगा कि हमें समय और पैसा ऐसा क्यों करना चाहिए, जो अंततः कार्यक्रम के व्यवहार को किसी भी तरह से संशोधित नहीं करेगा।
नील

15
@ नील: ... तो शायद यह "रखरखाव लागत" की अवधारणा के लिए अपने मालिक को पेश करने का समय है?
एसएफ।

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

8
@Aaronaught। यह उत्तर हड्डी को काटता है जब यह "कार्यान्वयन ए खराब होता है, मेरा सुझाव है कि हम कार्यान्वयन बी करते हैं" क्योंकि अतिरिक्त काम (धन को बराबर करना) करना पड़ता है। यदि यह ए या बी को लागू करने के बीच एक विकल्प होता तो उत्तर अलग होता। मेरा सुझाव है कि यदि आप अधिक अलग जवाब चाहते हैं तो आप मेटा पर एक प्रश्न खोलें।

22
"क्या यह सहकर्मियों या काम के माहौल के बारे में हर एक सवाल का डिफ़ॉल्ट जवाब बनने जा रहा है?" क्यों नहीं? यदि इसे एक तकनीकी प्रश्न के रूप में कहा जाता है। "जो कि बेहतर स्वचालित ओफ़्स्चुएशन वी का हाथ कोडित (= बुरा अभ्यास) ओफ़्फ़क्यूसेशन है" तो यह एक पूरी तरह से अलग प्रश्न है, और तकनीकी चर्चा का वारंट करता है। सभी "क्या मुझे अपने सहकर्मियों के पीछे इसे ठीक करना चाहिए?" प्रश्न अंततः "नहीं," टीम / उच्च शक्ति के ध्यान में लाने के लिए उबलते हैं
बाइनरी वॉरियर

13

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

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

आप इसे प्रोग्रामर के साथ लाए हैं, आपका अगला कदम अपनी नाक को बाहर रखना है या इसे प्रबंधन के साथ लाना है और फिर अपनी नाक को इससे बाहर रखना है।


फिर जब मैं भविष्य में इन वर्गों के माध्यम से मछली पकड़ता हूं, तो मैं सिर्फ अपनी नाक पकड़ लेता हूं।
नील

3
जब आपके पास उस कोड के लिए एक सीधी ज़िम्मेदारी होती है, तो उसे अपनी पसंद के अनुसार बदलना ठीक है, लेकिन अगर कोई संयुक्त ज़िम्मेदारी है, तो आपको किसी को मध्यस्थ बनाने की आवश्यकता होगी। कामकाजी रिश्तों को चोट पहुंचाना और इस तरह की परिस्थितियों पर समय बर्बाद करना आसान है, यदि संभव हो तो इसे एक मुद्दा नहीं बनाना बेहतर है। अगर कोई मुद्दा बनाने की जरूरत है, तो इसे एएसएपी से बाहर निकालें।
13:00 पर DKnight जूल

6

क्या किसी भी प्रकार की आधिकारिक कोड समीक्षा थी - या क्या आपके पास एक अनौपचारिक "कोड समीक्षा" का टकराव था? मैं कहूंगा कि चूंकि यह एक नाजुक और महत्वपूर्ण विषय है जैसे कि सुरक्षा और लाइसेंसिंग, आपको इसे श्रृंखला को बढ़ाने की आवश्यकता है। आपने पहला भाग किया है - प्रोग्रामर का सामना करना। हालाँकि, अब वह सुन नहीं रहा है, आप इसे उठा सकते हैं। यदि आप नहीं करते हैं, तो आप समस्या का हिस्सा हो सकते हैं।

मैं उसे बताऊंगा कि आप इसे करने जा रहे हैं - यह MAY उसके दिमाग को बदल देगा। यदि ऐसा नहीं होता है, तो अपने बॉस को स्थिति के बारे में एक बहुत ही राजनीतिक रूप से सही, सटीक और संक्षिप्त ईमेल लिखें, और प्रोग्रामर को सीसी करें। ईमेल में, आप और / या किसी अन्य भाग लेने वाली पार्टी के बीच एक बैठक के लिए पूछें।

हमेशा इन चीजों को सिर पर मिलते हैं - फिर भी एक राजनीतिक और सौहार्दपूर्ण तरीके से।


निश्चित रूप से एक सराहनीय दृष्टिकोण। मैंने स्वयं कोड संशोधन देखा, एसवीएन से अपना कोड अपडेट किया। हालांकि संभावना है, अगर वह समझौते में नहीं है, तो मेरे मालिक को इन सुरक्षा सावधानियों को सुनिश्चित करने की संभावना नहीं है, क्योंकि प्रोग्रामर यह तर्क दे सकता है कि यह पहले से ही 'काम करता है'।
नील

2

यदि आप एक ऐसा ऑबफ्यूज़ेटर पा सकते हैं जो कक्षाओं (विधि नामों आदि) के हस्ताक्षर को बाधित कर सकता है, तो, इसे खरीदने और उपयोग करने का प्रस्ताव करें।

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


1
मैं आपको नहीं बता सकता कि मुझे कितना परेशान करता है, हालांकि आप शायद सही हैं कि मुझे इसके साथ रहना होगा।
नील

2

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

यदि एक पर्यवेक्षक पर्याप्त सुरक्षित नहीं है, तो क्या आपने JAR को सुरक्षित करने के अन्य तरीकों पर ध्यान दिया है, हो सकता है कि इसे एन्क्रिप्ट करने, या इसे मूल कोड में संकलित करने जैसा कुछ हो?

पुन: अपने कोड को फिर से काम: क्या यह सिर्फ नाम बदलने की बात है? कई IDE में रीफैक्टरिंग टूल होते हैं जो इसे काफी आसानी से कर सकते हैं।


वह मुझे थोड़ा पागल जैसा कहता है, हालांकि मैं देख सकता हूं कि क्यों। यदि उत्पाद हैक कर लिया गया था, तो इसका मतलब शायद उसकी नौकरी होगी। मैं यह नहीं कहूंगा कि यह संभव है, लेकिन मुझे यह जानने के लिए पर्याप्त है कि आप विधि नामों के लिए कैसे शिकार कर सकते हैं और यदि "isLicenseValid" नामक एक स्पष्ट विधि थी, तो उस वर्ग को लिखने की बात होगी जो इस पद्धति का है और हमेशा सही रहता है 'इसे हैक करें। मुझे लगता है कि इस कार्यक्रम को और अधिक जटिल किए बिना इसे जटिल बनाया गया है, हालांकि वह यह सुनिश्चित करना चाहता है। मुझे लगता है कि मैं उसका नाम बदलकर उसका कोड आसानी से तय कर सकता हूं, हां।
नील

सिर्फ इसलिए कि आपके पास "isLicenseValid" नामक एक विधि है, इसका मतलब यह नहीं है कि इसे बस उसी विधि से एक वर्ग लिखकर हैक किया जा सकता है। यदि आप अपनी कक्षा को "सील" (यानी सी # सिंटैक्स) के रूप में चिह्नित करते हैं, तो 3 पार्टियां आपकी सुरक्षा जांचों को केवल उपवर्ग लिखकर और आपके तरीके को ओवरराइड करके नहीं कर सकती हैं। किसी भी मामले में, जब तक कि यह लड़का कंपनी का सुरक्षा अधिकारी नहीं है, तो उत्पाद हैक होने पर उसकी नौकरी का क्या मतलब होगा?
Tundey

2
@ टुंडी, यह उपवर्गों की बात नहीं है (उन्हें कैसे लोड किया जाएगा?): यह उसी कक्षा को लिखने और हैक किए गए संस्करण को पहले क्लासपथ सर्च लिस्ट में डालने की बात है ।
पीटर टेलर

1
हा.मुझे जावा में क्लास लोडिंग की खुशियाँ याद हैं। फिर भी उसके खिलाफ कम करने के लिए एक बेहतर तरीका होना चाहिए। दरअसल, अगर आपके क्लास लोडर से समझौता नहीं किया जाता है, तो कोई आपकी कक्षा के समान वर्ग कैसे लिख सकता है? खासकर अगर आपका JAR हस्ताक्षरित है? अपने JAR पर हस्ताक्षर नहीं करने और अपनी कक्षाओं को सील करने से आपके समान नाम वाले किसी वर्ग को लिखने की समस्या का समाधान होगा?
Tundey

1
@ टुंडे सूर्य जेवीएम (ज्यादातर) खुला स्रोत है, आप इसे संशोधित कर सकते हैं।
स्पड 86

2

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

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


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

1

मैं इसी तरह की समस्या में भाग गया जब एक अन्य डेवलपर ने हमारे एन्क्रिप्शन / डिक्रिप्शन रूटीन str__copyऔर str__delete(दूसरे अंडरस्कोर नोटिस) का नाम दिया। यह लंगड़ा था और बेहतर किया जा सकता था, इसलिए हमने इंतजार किया जब तक कि एक कहानी नहीं थी जहां लाइसेंस को अपडेट करना आवश्यक था। प्रबंधन को अतिरिक्त मुट्ठी भर घंटों के लिए कोई समस्या नहीं थी क्योंकि हमने इसे "अगली बार जब हम लाइसेंसिंग में जाते हैं तो इसे साफ करने के रूप में वर्णित किया था, यह कम समय लेगा, यह कम समय लेगा और यह अधिक सुरक्षित होगा"। समस्या हल हो गई, कोई आहत भावना नहीं।


खैर बेशक हम इसे बाद में बदल सकते हैं, हालांकि मुझे लगता है कि बदलाव को कोड से अधिक सिर में होना चाहिए।
नील

1
@ फिर मैं आपको सुझाव दूंगा कि आपको सिर में बदलाव की आवश्यकता है। यदि कोड काम करता है, पर्याप्त परीक्षण किया है, और अच्छी तरह से टिप्पणी की है कि मार्ग का उपयोग करने के बजाय और पर्यवेक्षक सबसे अच्छा विकल्प नहीं है, लेकिन दुनिया का अंत भी नहीं है। इसे बाद में ठीक करें यदि यह एक समस्या है और बस अन्यथा आगे बढ़ें।
क्रिस्टोफर Bibbs

@Christopher_Bibbs: अपना दिमाग आराम से लगाएं। मैं आपको लगभग निश्चित रूप से आश्वस्त कर सकता हूं कि यह वास्तव में एक समस्या पेश करेगा।
नील

1

मेरा पहला विचार उस कोड का रखरखाव था। यदि कोड पहले से ही बाधित है और वह आगे बढ़ गया है, तो सौभाग्य उस कोड को संभालने की कोशिश कर रहा है। फिर आप कोड को समझने की कोशिश करने वाले हैकर होंगे।

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

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


0

मैं उन उत्तरों से बहुत सहमत हूं जो आपको अपने बॉस से इस मुद्दे के बारे में पूछना चाहिए और जो वह कहते हैं वह करें।

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


0

"एक समस्या के बारे में जानने के लिए सबसे बेहतर पेशेवर मत बनो"।

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

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


0

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

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

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

आपके पास कुछ ऐसा है जो हमलावर नहीं करता है। मूल स्रोत कोड। अपने लिए इसे बेहतर तरीके से व्यवस्थित करने का तरीका खोजें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.