मैं जावा में कुछ कोड लिखने के शाम को विचार करने के लिए उत्सुक हूं क्योंकि यह डिकंपाइल करना कितना आसान है। क्या जावा में लिखने का कोई तरीका है और मुझे डिकंपेलर के बारे में चिंता करने की ज़रूरत नहीं है? मैं समझता हूं कि कुछ भी को पर्याप्त समय दिया गया इंजीनियर दिया जा सकता है, इसलिए मैं जो पूछ रहा हूं वह है: क्या जावा क्लास ओबफ्यूसेटर प्रतिरोधी विघटन के लिए पर्याप्त प्रभावी हैं?जावा कोड obfuscation वास्तव में प्रभावी बनाम decompilers बनाम है?
जावा अनुभव को कम करने के व्यक्तिगत अनुभव से, मैं कहूंगा कि obfuscation किसी को भी बहुत परेशान और मुश्किल को अपनाने के प्रयास कर सकता है। मेरे लिए सबसे परेशान करना तब होता है जब अंतिम कक्षाओं को बनाता है, सभी को "ए.क्लास, बी। क्लास, सी। क्लास" नाम दिया जाता है और इसी तरह, बड़ी मात्रा में डमी फेंक दिए जाते हैं। कोड obfuscation के संदर्भ में, कोशिश करें/कैच डिकंपेलर के लिए गड़बड़ सामग्री का एक अच्छा काम करते हैं।
आम तौर पर, जो कुछ भी आप संकुचित करते हैं वह संकलित नहीं होगा, लेकिन आपको कार्यक्रम के सामान्य कार्यों के बारे में संकेत देगा।
जावा क्लास obfuscators प्रतिरोधी विघटन के लिए पर्याप्त प्रभावी हैं?
मैं "नहीं" कहूंगा। जब मैं किसी को कुछ करने के तरीके को समझने के इरादे से स्रोत कोड को संकुचित करता हूं, तो मुझे पहले से ही पता है कि मैं क्या देख रहा हूं। तो मुझे पूरे कार्यक्रम को समझने की ज़रूरत नहीं है - उस समय केवल एक टुकड़ा जो मेरे लिए रूचि रखता है। विधियों पर पर्याप्त परेशानियों और कॉल श्रृंखला को थोड़ा पीछे हटाना, आमतौर पर यह निर्धारित करना संभव है कि बिना किसी प्रयास के हुड के नीचे क्या है।
फ्रैंकली बोलने की संख्या कोई फर्क नहीं पड़ता कि आप हास्यास्पद रूप से कोड को कैसे रोकते हैं, अगर कोई जानता है कि वह आपके कोड से दस लाख डॉलर निकाल सकता है, तो वह आपकी कक्षा फाइलों को डीकंपाइल करेगा और कोड प्राप्त करेगा।
वहाँ विकल्प हालांकि इस प्रकार हैं:
वितरण beofre exe करने के लिए अपने जावा कार्यक्रम में रूपांतरित करें। आपको पता होना चाहिए कि यहां कैच हैं।
आपको एक कुंजी के साथ कक्षा फ़ाइलों को एन्क्रिप्ट करें। एक कस्टम क्लासलोडर बनाएं जो इसे स्मृति में लोड करने से पहले निजी कुंजी का उपयोग कर कक्षा फ़ाइलों को डीकोड कर सकता है। यहां दो समस्याएं हैं, ए) लोड समय बढ़ता है, बी) आप निजी कुंजी कैसे छिपाएंगे।
इनमें से कोई भी * वास्तव में * विघटन को रोक देगा - 1.) इसका मतलब है कि उन्हें मूल निष्पादन योग्य असेंबली को अपूर्ण करने की आवश्यकता है - http://stackoverflow.com/questions/2244321/does-compilng-java-code-to-exe -eg-use-launch4java-sure-code-can-be-rev 2. 2. यदि कोई कस्टम क्लासलोडर कक्षा को डिक्रिप्ट कर सकता है, तो वे इसे क्लासलोडर से प्राप्त कर सकते हैं - http://stackoverflow.com/questions/1175008/encrypting -वार-फाइल/1178074 # 1178074 – Nate
@nate ... इसके बाद आसान कहा जाता है। .1) अगर पूर्व में असेंबली को मूल रूप से अपनाना पड़ता है तो एक्सई के मामले में वास्तव में मदद मिलेगी तो पृथ्वी पर कोई कोड सुरक्षित नहीं होगा 2) अगर आपका केवल क्लासलोडर कुंजी को जानता है –
क्या आपने लिंक भी पढ़े हैं? 1.) कोई कोड (जिसे उपयोगकर्ता के पास सीधी पहुंच है) * * रिवर्स इंजीनियरिंग से * "सुरक्षित" है - किसी भी निष्पादन योग्य को असेंबली में विघटित किया जा सकता है - और ऐसे लोग हैं जो प्रोग्राम असेंबली के साथ-साथ जावा भी कर सकते हैं। 2.) क्लास एन्क्रिप्शन बेकार है, एन्क्रिप्शन योजना से कोई फर्क नहीं पड़ता, क्योंकि क्लासलोडर के लिए एक जेवीएम में काम करने के लिए, इसे * unencrypted * class को defineClass() विधि के माध्यम से JVM को प्रदान करना होता है - किसी को बस उपयोग करने से रोकने के लिए क्या करना है आपके क्लासलोडर को उनके लिए अपनी कक्षाओं को डिक्रिप्ट करने के लिए, और उन्हें अनएन्क्रिप्टेड से बचाने के लिए? – Nate
"पर्याप्त प्रभावी" पूरी तरह से निर्भर करता है कि आपको इसे कितना प्रभावी होना चाहिए। और यह उस पर निर्भर करता है कि आप क्या रक्षा कर रहे हैं, और किससे। परंपरागत तरीकों में से कोई भी नहीं (obfuscation, बाइटकोड को एन्क्रिप्ट करना, "exe" से संकलित करना) एक कुशल और निर्धारित हमलावर को पर्याप्त समय और प्रोत्साहन के साथ रोक देगा। लेकिन यह प्रोग्रामिंग के सभी रूपों पर काफी अधिक लागू होता है। (आप सी/सी ++ ऐप्स को भी डिस्सेम्बल या डिस्प्लेइल कर सकते हैं ...)
एक गंभीर रिवर्स इंजीनियरिंग प्रयास के खिलाफ आप रक्षा कर सकते हैं एकमात्र तरीका एक सुरक्षित निष्पादन मंच का उपयोग करना है; जैसे TPM पर आधारित कुछ का उपयोग करना। फिर भी, यदि बुरे लोग आपके कोड को चलाने वाली प्रणाली में एक तर्क विश्लेषक संलग्न कर सकते हैं, तो वे मूल रूप से निष्पादित किए जा रहे मूल कोड को कैप्चर कर सकते हैं और फिर रिवर्स इंजीनियरिंग पथ पर शुरू कर सकते हैं।
संपादित: किसी कथित तौर पर है एक लोकप्रिय TPM चिप तोड़ने, एक इलेक्ट्रॉन माइक्रोस्कोप का उपयोग करने में सफल रहा; this Register article देखें। और दिलचस्प बात यह है कि उनका मूल प्रेरणा Xbox 360 कंसोल हैक करना था!
सच है, लेकिन शायद यह कहना उचित है कि लक्षित दर्शकों में से अधिकांश में ऐप तोड़ने के लिए उपकरण या जरूरी नहीं होंगे। टीपीएम आधारित संरक्षित के साथ ... तब तक कहा गया है जब तक कि आवेदन की सफलता के स्तर का अर्थ यह नहीं है कि लेखकों की परवाह नहीं होगी क्योंकि वे पहले ही कमाई से सेवानिवृत्त हुए हैं। –
@SoftwareMonkey - यह सच है। लेकिन फ्लिप-पक्ष यह है कि अधिकांश डेवलपर्स के पास अपने अनुप्रयोगों की सुरक्षा के लिए टीपीएम का उपयोग करने के लिए समान नहीं है! टीपीएम का मेरा उल्लेख है ... काफी हद तक काल्पनिक। –
यदि आपका प्रश्न है तो क्या मैं यह सुनिश्चित कर सकता हूं कि कोई भी मेरे कोड को हैक कर सकता है, जवाब नहीं होगा .. चाहे वह जावा या विजुअल सी ++ में हो। जब तक आपका सॉफ़्टवेयर बाई या बिट्स से बना होता है तब तक हैकर द्वारा सीधे पहुंचा जा सकता है।
कारण सरल है।
हालांकि आपने एन्कोड किया है, जिसे डीकोड किया जा सकता है।
सर्वोत्तम रणनीति एक वेब सेवा बनाने और अपने गुप्त तर्क को तैनात करने के लिए हो सकती है। दूसरों को आपके द्वारा लिखे गए पहुंच के बिना आपकी सेवा का उपयोग करने दें।
जावा और अन्य भाषाओं में Obfuscation, केवल एक निवारक है। यह हमलावर के लिए बस उठाता है। इसका मतलब यह नहीं है कि obfuscation का कोई मूल्य नहीं है, यह सिर्फ गारंटी नहीं है।
आप किस चीज की रक्षा करने की कोशिश कर रहे हैं और आप किस प्रकार का बाजार लक्षित कर रहे हैं?
बाजार में लाइसेंस एल्गोरिदम की रक्षा करने के लिए बाधा जो कि समुद्री डाकू से भरा हुआ है, इसका मतलब यह नहीं होगा। हालांकि, एसएमबी के लिए, यह अधिकांश आरामदायक समुद्री डाकू काटने के लिए पर्याप्त हो सकता है।
यदि आप प्रतिस्पर्धा से आईपी की रक्षा करने की कोशिश कर रहे हैं, तो मुझे दो उत्तरों दिखाई देते हैं। विचार, रक्षा करना मुश्किल होगा। कोड को देखकर एक सक्षम इंजीनियर तर्क के रत्नों को समझ लेगा और पुन: कार्यान्वित करने में सक्षम होगा। Obfuscation लोगों को सिर्फ कोड लेने और इसे अपने उत्पाद में शामिल करने के लिए बहुत कठिन बना देगा। रखरखाव लागत बढ़ती रहेगी क्योंकि वे बदलाव करने का प्रयास करते हैं (मैं कहूंगा कि यह साफ-सुथरा कोड के लिए भी सच है)।
मेरे कंपनी के लिए विकसित जावा उत्पाद obfuscated हैं। क्या उन्होंने हमें चोरी से बचाया है ... मुझे शक है। लेकिन, हमारी विकास लागत के संदर्भ में, obfuscation उस महंगा नहीं था। एक छोटी सी कीमत के लिए सुरक्षा का एक छोटा सा हिस्सा खराब व्यापार-बंद नहीं है।
obfuscation की लागत obfuscator की कीमत से परे विस्तारित। Obfuscation प्रदर्शन और पोर्टेबिलिटी भी कम कर देता है। – Antimony
@ एंटीमोनी मैं सहमत हूं, हालांकि मैं कभी भी प्रदर्शन ड्रॉप को माप नहीं सकता था। बाइट कोड मान्य था, लेकिन मैंने हॉटस्पॉट कंपाइलर (1.6 जेवीएम) में बग को ट्रिगर किया है जिससे क्रैश हो जाता है (परिणामस्वरूप आसानी से उत्पादित किया जाता है जिसके परिणामस्वरूप कक्षा को ओबफसकेटर में सूचीबद्ध किया जाना चाहिए)। संगतता समस्याएं दोषपूर्ण JVMs के आसपास अधिक होंगी जो वैध बाइट कोड को संभाल नहीं सकती थीं। गैर जावा कंपेलरों धीरे-धीरे कुछ लोकप्रियता प्राप्त करने के साथ, यह एक मुद्दा से कम होना चाहिए। –
पोर्टेबिलिटी द्वारा, मैं असुरक्षित या गैर-मानक API पर भी निर्भरता का जिक्र कर रहा था। उदाहरण के लिए, एक स्ट्रिंगर obfuscated ऐप सेट असफल या Google ऐप इंजन पर आंतरिक सूर्य एपीआई पर निर्भरता के कारण एक अविश्वसनीय एप्लेट के रूप में चलाने के लिए नहीं जा रहा है (नहीं कि आप जीएई पर वैसे भी obfuscated कोड चलाने के लिए चाहते हैं)। – Antimony
यदि आप मेरी पोस्ट https://stackoverflow.com/a/26717791/2132826 पढ़ते हैं तो आप देखेंगे कि मुझे एक अच्छा जावा डी-ओबफ्यूसेटर नहीं मिला जो वास्तव में अपेक्षित काम करता है।
इसलिए वर्तमान उत्तर है: नहीं।
कृपया ध्यान दें, आपको अपने डीबग बिल्ड में कोई भी परेशानी नहीं करनी चाहिए, बस रिलीज बिल्ड में! obfuscated कोड के साथ काम करना बहुत मुश्किल है। – revenantphoenix