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

Question

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

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

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

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

@staffan एक अच्छा बिंदु है:

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

Answer 1

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

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

Answer 2

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

Answer 3

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

उदा।

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"); 
    } 
} 

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

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

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

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

Answer 4

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

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; 
       } 
      } 

     } 

    } 

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

लेकिन अब "स्ट्रिंग एन्क्रिप्शन" सुविधा केवल इस तरह के रूप में वाणिज्यिक ऑबफस्केटर, में उपलब्ध है।

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