क्या आप अपने वाणिज्यिक जावा कोड को खराब कर देते हैं?

मुझे आश्चर्य है कि अगर कोई अपने वाणिज्यिक उत्पाद पर वाणिज्यिक/मुक्त जावा obfuscators का उपयोग करता है। मैं केवल एक परियोजना के बारे में जानता हूं जो वास्तव में रिलीज के लिए चींटी निर्माण चरण में एक अप्रिय कदम था।

क्या आप obfuscate? और यदि हां, तो आप क्यों परेशान हैं?

क्या यह वास्तव में कोड की रक्षा करने का एक तरीका है या क्या डेवलपर्स/प्रबंधकों के लिए यह एक बेहतर भावना है?

edit: Ok, I to be exact about my point: Do you obfuscate to protect your IP (your algorithms, the work you've put into your product)? I won't obfuscate for security reasons, that doesn't feel right. So I'm only talking about protecting your applications code against competitors.

@staffan has a good point:

कोड प्रवाह को धुंधला करने से दूर रहने का कारण यह है कि उनमें से कुछ परिवर्तन JVM के लिए कोड को कुशलता से अनुकूलित करने के लिए असंभव बनाता है। असल में यह वास्तव में आपके आवेदन के प्रदर्शन को कम कर देगा।

0
जोड़ा संपादित
विचारों: 14
स्रोत
ro fr bn
मैंने अभी तक एक अच्छा obfuscator नहीं देखा है, लेकिन हो सकता है कि आप इस धागे को देखना चाहें, यहां तक ​​कि यह .Net: http://stackoverflow.com/questions/12075/should-i-be-worried‌ -about-obfusicating- और जेडडब्ल्यूएनजे, मेरे निवल कोड
जोड़ा लेखक John Smithers, स्रोत

7 उत्तर

मैं ProGuard का उपयोग करता हूं और अत्यधिक अनुशंसा करता हूं। जबकि obfuscation आकस्मिक हमलावरों से आपके कोड की रक्षा करता है, यह मुख्य लाभ अप्रयुक्त वर्गों और विधियों को हटाने और सभी पहचानकर्ताओं को 1 या 2 वर्णों को छोटा करने का कम करने का प्रभाव है।

0
जोड़ा
स्रोत
@ user384706: हां मैं कोड के साथ ProGuard का उपयोग करता हूं जो प्रतिबिंब का व्यापक रूप से उपयोग करता है। Class.forName() के सरल उपयोग को छोड़कर आपको प्रतिबिंबित वस्तुओं को रखने के लिए इसे कॉन्फ़िगर करना होगा।
जोड़ा लेखक Lawrence Dol, स्रोत
मैं सोच रहा था कि क्या आपने कभी कोड को अपवित्र किया है जो प्रतिबिंब का व्यापक रूप से उपयोग करता है? क्या आपको कोई समस्या है?
जोड़ा लेखक Cratylus, स्रोत

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

0
जोड़ा
स्रोत

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

जैसे

public void doSomething()
{
    /* Generated config class containing static finals: */
    if (Configuration.ISMOTOROLA)
    {
        System.out.println("This is a motorola phone");
    }
    else
    {
        System.out.println("This is not a motorola phone");
    }
}

यह संकलित हो जाता है, obfuscated, और वर्ग फ़ाइल समाप्त होता है जैसा कि आपने लिखा था:

public void doSomething()
{
    System.out.println("This is a motorola phone");
}

तो आपके पास अंतिम निष्पादन योग्य वर्ग फ़ाइलों को बुलाने के बिना JVM/लाइब्रेरी कार्यान्वयन में निर्माता बग के आसपास काम करने के लिए कोड के रूप हो सकते हैं।

मेरा मानना ​​है कि कुछ वाणिज्यिक obfuscators कुछ मामलों में कक्षा फ़ाइलों को एक साथ विलय कर सकते हैं। यह उपयोगी है क्योंकि आपके पास जितनी अधिक कक्षाएं हैं, आपके पास ज़िप (जार) फ़ाइल में आकार का ओवरहेड बड़ा है।

0
जोड़ा
स्रोत
असल में, सशर्त कोड के संबंध में, जावा विनिर्देश के लिए आवश्यक है कि संकलक इस तरह एक मृत कोड छोड़ दें बशर्ते स्थिति को स्थैतिक रूप से झूठी अभिव्यक्ति के माध्यम से असाइन किया गया हो। सभी प्रोगुआर्ड क्या कर सकते हैं।
जोड़ा लेखक Lawrence Dol, स्रोत

यदि आप obfuscate करते हैं, तो obfuscators से दूर रहें जो कोड प्रवाह को बदलकर कोड को संशोधित करते हैं और/या अपवाद ब्लॉक जोड़ते हैं और इस तरह इसे अलग करना मुश्किल बनाते हैं। कोड को पढ़ने योग्य बनाने के लिए आमतौर पर विधियों, फ़ील्ड और कक्षाओं के सभी नामों को बदलने के लिए पर्याप्त होता है।

कोड प्रवाह को बदलने से दूर रहने का कारण यह है कि इनमें से कुछ परिवर्तन JVM के लिए कोड को कुशलता से अनुकूलित करने के लिए असंभव बनाता है। असल में यह वास्तव में आपके आवेदन के प्रदर्शन को कम कर देगा।

0
जोड़ा
स्रोत
मुझे समयपूर्व अनुकूलन की तरह लगता है।
जोड़ा लेखक NateS, स्रोत

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

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

0
जोड़ा
स्रोत

मुझे लगता है कि obfuscation का पुराना (शास्त्रीय) धीरे-धीरे इसकी प्रासंगिकता खो रहा है। क्योंकि ज्यादातर मामलों में शास्त्रीय obfuscators एक स्टैक ट्रेस तोड़ने (यह आपके ग्राहकों का समर्थन करने के लिए अच्छा नहीं है)

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

दिलचस्प तथ्य: हमारे पास स्ट्रिंग्स में यह सभी संवेदनशील डेटा है। दरअसल स्ट्रिंग्स हमारे अनुप्रयोगों के तर्क का लगभग 50-80% है। ऐसा लगता है कि obfuscation का भविष्य "स्ट्रिंग एन्क्रिप्शन उपकरण" है।

लेकिन अब "स्ट्रिंग एन्क्रिप्शन" सुविधा केवल वाणिज्यिक obfuscators में उपलब्ध है, जैसे: Allatori , ज़ेलिक्स KlassMaster , Smokescreen , स्ट्रिंगर जावा Obfuscation टूलकिट , DashO ।

N.B. मैं लाइसेंस एलएलसी में सीईओ हूं। स्ट्रिंगर जावा Obfuscator के डेवलपर।

0
जोड़ा
स्रोत
ये बहुत सही है। इन दिनों में इतनी खुली स्रोत परियोजनाएं हैं कि कोई भी अन्य लोगों के वाणिज्यिक स्रोत कोड की परवाह नहीं करता है। मुख्य बिंदु बिल्कुल कुछ (छोटी) विशिष्ट जानकारी, जैसे कि निजी कुंजी और पासवर्ड की रक्षा करना है।
जोड़ा लेखक marcolopes, स्रोत

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

    if(i < ll1) goto _L6; else goto _L5
_L5:
    char ac[] = run(stop(lI1l));
    l7 = (long)ac.length << 32 & 0xffffffff00000000L ^ l7 & 0xffffffffL;
    if((int)((l7 & 0xffffffff00000000L) >> 32) != $5$)
    {
        l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
    } else
    {
        for(l3 = (long)III & 0xffffffffL ^ l3 & 0xffffffff00000000L; (int)(l3 & 0xffffffffL) < ll1; l3 = (long)(S$$ + (int)(l3 & 0xffffffffL)) ^ l3 & 0xffffffff00000000L)
        {
            for(int j = III; j < ll1; j++)
            {
                l2 = (long)actionevent[j][(int)(l3 & 0xffffffffL)] & 65535L ^ l2 & 0xffffffffffff0000L;
                l6 = (long)(j << -351) & 0xffffffffL ^ l6 & 0xffffffff00000000L;
                l1 = (long)((int)(l6 & 0xffffffffL) + j) & 0xffffffffL ^ l1 & 0xffffffff00000000L;
                l = (long)((int)(l1 & 0xffffffffL) + (int)(l3 & 0xffffffffL)) << 16 & 0xffffffff0000L ^ l & 0xffff00000000ffffL;
                l = (long)ac[(int)((l & 0xffffffff0000L) >> 16)] & 65535L ^ l & 0xffffffffffff0000L;
                if((char)(int)(l2 & 65535L) != (char)(int)(l & 65535L))
                {
                    l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
                }
            }

        }

    }

आप नहीं जानते थे कि जावा को मिला है? खैर, जेवीएम उनका समर्थन करता है =)

0
जोड़ा
स्रोत
मशीन कोड स्तर पर (और इसलिए बाइटकोड में, जो बस मशीन स्वतंत्र मशीन कोड है) सभी कंप्यूटर गोटो का उपयोग करते हैं। लूप्स बस गोटो/हालत की संरचनाएं हैं। संयोग से, जारी रखें और ब्रेक लेबल का उपयोग करके प्रतिबंधित गोटो से अधिक कुछ नहीं है (कभी-कभी लेबल स्पष्ट रूप से अनुमानित होता है)।
जोड़ा लेखक Lawrence Dol, स्रोत
मैं एक और विचार जोड़ूंगा ... यदि यह वास्तव में "सरल पाश" का नतीजा है, तो यह रिवर्स इंजीनियर कोड को अस्पष्ट और अस्पष्ट बनाने के बदले में दक्षता में उच्च लागत का भुगतान कर रहा है।
जोड़ा लेखक Lawrence Dol, स्रोत
जेबीसीओ का नकारात्मक पक्ष यह है कि यह शोध गुणवत्ता कोड है। मैं इसे सरल परीक्षण मामलों पर चलाने के लिए भी नहीं प्राप्त कर सकता हूं और दस्तावेज लगभग अनौपचारिक है।
जोड़ा लेखक Antimony, स्रोत