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

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

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

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

जैसे

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 कुछ मामलों में कक्षा फ़ाइलों को एक साथ विलय कर सकते हैं। यह उपयोगी है क्योंकि आपके पास जितनी अधिक कक्षाएं हैं, आपके पास ज़िप (जार) फ़ाइल में आकार का ओवरहेड बड़ा है।

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

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

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

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

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

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

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

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

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

मैंने इस साल कुछ जावा ओबफ्यूसेटर को आजमाने की कोशिश की, और मैंने पाया कि बाकी के बाकी हिस्सों में से एक मील दूर है: 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;
                }
            }

        }

    }

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