रिलीज कोड को बाधित करने के क्या फायदे हैं?

Question

मेरे पास मौजूद विशिष्ट उदाहरण में वर्तमान में अल्फ़ा गेम माइनक्राफ्ट शामिल है, लेकिन यह एक सामान्य सवाल है कि मुझे लगता है कि कुछ बातचीत का वारंट है।

Minecraft जावा में लिखा गया है, और स्टैक के निशान आमतौर पर इस तरह दिखते हैं (वास्तविक उदाहरण):

java.lang.NullPointerException
    at d.a(SourceFile:247)
    at gi.b(SourceFile:92)
    at bd.a(SourceFile:33)
    at bn.a(SourceFile:69)
    at bn.e(SourceFile:115)
    at bn.d(SourceFile:103)
    at net.minecraft.client.Minecraft.i(SourceFile:1007)
    at net.minecraft.client.Minecraft.run(SourceFile:596)
    at java.lang.Thread.run(Unknown Source)

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

क्या फायदा हो सकता है कि कोई व्यक्ति अपने कोड को इस तरह से प्राप्त करके आशा कर सकता है कि यह अधिक कठिन बग पहचान की कमियों को दूर करता है?

Comments

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

— मार्क बूथ

Answer 1

हम अपने जावा कोड को भी बाधित करते हैं ...।

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

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

यह वास्तव में कोई नुकसान नहीं है। :)

Comments

दिलचस्प है, मुझे कभी नहीं पता था कि वे "स्टैक ट्रेस अन-ऑब्सफेकशन" के साथ आए थे (कभी भी एक ओबफ्यूसेटर का इस्तेमाल नहीं किया था) ... क्या एक साफ विचार :-)

— डीन हार्डिंग

एकमात्र दोष जो मैंने कभी भी चलाया है, वह कभी-कभार एक obfuscator (इस मामले में एक .NET है) ने इसे उस बिंदु पर रोक दिया जहां घबराना इसे (अवैध निर्देश) भी नहीं पढ़ सका। बड़े पैमाने पर विफल।

— vcsjones

@vcsjones: यह वास्तव में तब मोटापा नहीं है ...

— विन्यासकर्ता

Answer 2

• आपको बौद्धिक संपदा की रक्षा करना

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

Comments

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

— १०:

@phresnel: हाँ obfuscator एक बहुत अच्छा काम कर सकता है

@phresnel: अधूरा, शायद, लेकिन भद्दा ...

तुम सही हो। मुझे रेपोस्ट करते हैं।

— १०:०१ पर १०

ऐसा नहीं है कि मुझे आप पर विश्वास नहीं है; मैं करता हूँ! लेकिन वे सभी अनुकूलन आमतौर पर आधुनिक संकलक द्वारा भी किए जाते हैं। कम से कम मुझे पता है कि जीसीसी उन सभी को है। इसलिए मेरी राय है: यदि कोई ऑबफ्यूज़र वास्तव में आपको एक महत्वपूर्ण स्पीडअप देता है, तो संकलक [विक्रेता] ने पर्याप्त प्रयास नहीं किया, या उसे उपयुक्त अनुकूलन ध्वज नहीं दिए गए।

— फॉटेलीन