समुद्री डाकू, समुद्री डाकू, चोरी। मैं क्या कर सकता हूँ?

Question

मैंने अभी एक ऐप, एक पेड ऐप जारी किया है, 4 दिन बाद एक उपयोगकर्ता ने मुझे बताया कि चीन में एक और वेबसाइट है जो मेरा ऐप होस्ट करती है। मैंने इसे वहां से डाउनलोड किया, और यह मेरे डिवाइस पर ठीक चलाता है!

यहां पोस्ट हैं कि लोग पैकेज नाम बदल सकते हैं और एक एपीके को दोबारा प्रकाशित कर सकते हैं। लेकिन यह मेरा मामला नहीं है, क्रैक संस्करण अभी भी उसी पैकेज नाम का उपयोग करता है। मैंने कार्यक्रम में एंड्रॉइड वेंडिंग लाइसेंसिंग का उपयोग किया, लेकिन क्रैक संस्करण बिल्कुल लाइसेंसिंग जांच नहीं करता है। मैंने ProGuard को इसे खराब करने के लिए उपयोग किया, लेकिन यह हैकर्स को हतोत्साहित नहीं करता है।

प्रश्न # 1: मैंने Google के निर्देशों के अनुसार एपीके फ़ाइल पर हस्ताक्षर किए। लेकिन फिर भी, उन्होंने कोड को संशोधित किया और लाइसेंसिंग चेक भाग लिया। क्या मैं गलत हूं कि एपीके फ़ाइल पर हस्ताक्षर करने से लोगों को फ़ाइल सामग्री के साथ छेड़छाड़ करने के लिए डिज़ाइन किया गया है?

प्रश्न # 2: Win32 .exe प्रोग्राम के लिए, मैं यह निर्धारित करने के लिए चेकसम का उपयोग करता था कि फ़ाइल बदल दी गई है या नहीं। इस प्रकार यह काम करता है: जब एक .exe बनाया जाता है, तो मैंने फ़ाइल के बाइट सामग्री की गणना करने के लिए एक टूल का उपयोग किया, फिर इसे फ़ाइल में कहीं भी भर दिया, उदाहरण के लिए, पाठ पैटर्न के बाद 4 बाइट्स "मेरा हस्ताक्षर" । फिर रन टाइम पर, प्रोग्राम .exe फ़ाइल खोलता है और बाइट योग की गणना करता है, हस्ताक्षर के बाद इसे पूर्णांक के साथ तुलना करता है।

क्या किसी ने एपीके फाइलों पर इस दृष्टिकोण की कोशिश की है? अपने अनुभव साझा करने की देखभाल?

Answer 1

आखिरकार एंड्रॉइड में ऐप्स की सुरक्षा में निर्मित बहुत खराब है। यहां आपके सर्वोत्तम अभ्यास हैं।

1) हां Google कोड कोड obfuscation का उपयोग करने की सिफारिश, हस्ताक्षरित कोडित, और उनके लाइसेंस सत्यापन सर्वर सॉफ्टवेयर चोरी को रोकने के लिए डिज़ाइन किया गया है। हालांकि उनका कार्यान्वयन बेहद खराब है। एपीके को चलाने की एकमात्र आवश्यकता यह है कि यह हस्ताक्षरित है। इससे कोई फर्क नहीं पड़ता कि इसे किसने हस्ताक्षर किया था। इस बात की कोई जांच नहीं है कि आपका हस्ताक्षर वह है जिस पर हस्ताक्षर किए गए हैं। तो इसे क्रैक करने के लिए आप केवल लाइसेंस जांच को हटा दें और जो भी प्रमाण आप चाहते हैं उसके साथ पुनः हस्ताक्षर करें। फिर कोई उपयोगकर्ता अपने फोन पर "गैर बाज़ार ऐप्स को अनुमति देने" की अनुमति दे सकता है।

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

यदि आप उन चरणों को नहीं करते हैं तो कोड स्वचालित रूप से क्रैक किया जा सकता है। कम से कम उन चरणों को करने से क्रैकर को हाथ तोड़ने के लिए समय निकालना पड़ता है। यह शायद सबसे अधिक कुछ घंटे ले जाएगा। लेकिन मानक Google लाइसेंसिंग परत को तुरंत क्रैक करने से कुछ घंटों अधिक समय लगता है। क्रैकर टूल्स हैं जो वास्तव में नए रिलीज किए गए एंड्रॉइड पैकेजों को केवल ऑटो-डाउनलोड करेंगे और, यदि वे मानक एंड्रॉइड लाइसेंसिंग का उपयोग करते हैं, तो उन्हें क्रैक करें और क्रैक किए गए एपीके को इन प्रकार की वेबसाइटों पर अपलोड करें। अपना कार्यान्वयन करके वेनिला कार्यान्वयन नहीं करते हैं, आप अपने अंत में केवल कुछ घंटों के प्रयासों के साथ चीजों को अधिक कठिन बनाते हैं।

2) यह एक आम एंटी-क्रैक तकनीक है। यदि आप चाहें तो एंड्रॉइड पर ऐसा कर सकते हैं। लेकिन इसे लगभग 5 मिनट में फटाया जा सकता है। यदि आप Google इस विशिष्ट तकनीक को क्रैक करने के तरीके पर ट्यूटोरियल हैं। असल में आप कोड में सीआरसी कॉल की तलाश करते हैं और सीआरसी वापस आने के बाद चेक हटा देते हैं।

एंड्रॉइड में कोई अंतर्निहित सुरक्षा नहीं है। आप किसी भी फोन को रूट कर सकते हैं और एपीके डाउनलोड कर सकते हैं। आप डीबगिंग को सक्षम करने के लिए आसानी से एपीके को हैक कर सकते हैं और कोड में संग्रहीत किसी भी कुंजी को देखने के लिए कोड को बस चरणबद्ध कर सकते हैं। तो अंत में मैं इस पर ज्यादा समय नहीं लगाऊंगा। एंड्रॉइड ऐप को सुरक्षित करना असंभव है।मैं उपर्युक्त सूची में सामान्य ज्ञान सामग्री करता हूं और आगे बढ़ता हूं।

3) क्या तुम सच में पागल आप अपने खुद के लाइसेंसिंग सर्वर पर अपने खुद के लाइसेंस लागू कर सकते हैं कर रहे हैं। यह वह दृष्टिकोण है जिसे मैंने लिया था, लेकिन चोरी के लिए ऐप की सुरक्षा के लिए उतना ही नहीं, क्योंकि यह मुझे सीधे अपनी वेबसाइट से ऐप्स बेचने के लिए एक तंत्र देना था, इसलिए जिन उपयोगकर्ताओं के पास Google Play नहीं है, वे अभी भी मेरे ऐप्स खरीद सकते हैं।

Answer 2

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

Answer 3

मैं गूगल के साथ संपर्क में मिला है और कैसे बुनियादी लाइसेंस LVL को बदलने के लिए पर एक सुपर उपयोगी बात करने के लिए निर्देशित किया गया था नहीं कर रहे हैं। गूगल आई/ओ 2011

Answer 4

निष्क्रिय/आक्रामक

scuttling मैं @metalideath साथ सहमत हैं कि मुश्किल होता और लाइसेंस कोड cludging सरल नहीं है से this talk की जाँच करें।

यहाँ एक आसानी से छिपा तकनीक मैं 'scuttling' है कि गूगल और अमेज़न के लिए तैनात किए गए एप्लिकेशन के लिए काम करता है कहते हैं। स्कटलिंग ऐप द्वारा फ्रंट एंड पाइरेसी डिटेक्शन है। एक बार पता लगाने के लिए ऐप निर्माता के पर्स में क्या करना है।

• आक्रामक स्कटलिंग: उदा। पायरेटेड ऐप पर समाप्ति और/या अलार्म। नेटवर्क संचार जरूरी नहीं है।
• निष्क्रिय स्कटलिंग: कोई ऐप संशोधन नहीं। उदाहरण के लिए। ट्रैकिंग सक्षम करें।
• निष्क्रिय/आक्रामक स्कटलिंग: सूक्ष्म ऐप संशोधन। उदाहरण के लिए। चुपचाप कुंजी विशेषताओं को अक्षम करें। सोचने में लीड समुद्री डाकू, और पायरेटेड ऐप अप्रकाशित करने में।

यदि आपके ऐप का नाम बदल दिया गया था और/या Google या अमेज़ॅन के अलावा किसी अन्य स्रोत से स्थापित किया गया था, तो स्कटल() सत्य लौटाता है।

// Dont just copy/paste this code - that is what automated crackers look for - cludge it! 
// No network communication is required at runtime. 
// myPackageName should decode at runtime to "com.yourpackagename" 
// google  should decode at runtime to "com.android.vending"; 
// amazon  should decode at runtime to "com.amazon.venezia"; 

public boolean scuttle(Context context, String myPackageName, String google, String amazon) 
{ 
    //Scallywags renamed your app? 

    if (context.getPackageName().compareTo(myPackageName != 0) 
    return true; // BOOM! 

    //Rogues relocated your app? 

    String installer = context.getPackageManager().getInstallerPackageName(myPackageName); 

    if (installer == null) 
    return true; // BOOM! 

    if (installer.compareTo(google) != 0 && installer.compareTo(amazon) != 0) 
    return true; // BOOM! 

    return false; 
} 

परिणाम

निम्नलिखित स्क्रीनशॉट कि आक्रामक scuttling के साथ पुन: वितरित किया गया था playstore (com.android.vending) से एक पायरेटेड पता लगाया नि: शुल्क एप्लिकेशन दिखा गूगल एनालिटिक्स से लिया गया है (गैर playstore का पता चला और समाप्त इंस्टॉल) । गैर-प्लेस्टोर (सेट-सेट) ट्रैकिंग बूंदें नहीं। ट्रैकिंग की आवश्यकता नहीं थी, लेकिन इन मापों के लिए सक्षम।

चर्चा

नोट सेवा पर हस्ताक्षर scuttling में एक भूमिका निभाता: पैकेज प्रबंधक अद्वितीय हस्ताक्षरों के साथ अद्वितीय पैकेज के नाम लागू करता है।

यह (एप्लिकेशन द्वारा पता लगाया समुद्री डाकू) जब अनुप्रयोग विफल रहा है कि क्या करना है का सवाल प्रस्तुत करता है। पाइरेसी आपके ऐप के वायरलाइजेशन (अनियंत्रित वितरण) का एक रूप है। एनालिटिक्स ट्रैकिंग बैक-एंड को सक्षम करके यह पहले ही पता लगाया जा सकता है। स्कटलिंग ऐप निर्माता को ट्रैक के साथ या बिना किसी फ्रंट-एंड प्रतिक्रिया को अनुकूलित करने की अनुमति देता है।

आक्रामक scuttling जाहिर द्वारा समुद्री डाकुओं का पता लगता है (बूम!)। यह और क्रैकिंग को प्रोत्साहित करता है। निष्क्रिय स्कटलिंग बहुत कम स्पष्ट है, लेकिन ट्रैकिंग शामिल हो सकती है।

समुद्री डाकू रोकथाम योग्य नहीं हो सकता है लेकिन यह अनुमानित, पता लगाने योग्य और ट्रैक करने योग्य है।

ट्रैकिंग समुद्री डाकू को दुर्बल समस्याएं पेश कर सकती है, लेकिन यह अपने स्वयं के नैतिक मुद्दों को भी प्रस्तुत करती है।

निष्क्रिय/आक्रामक स्कटलिंग को ऊपर उल्लिखित नेटवर्क संचार की आवश्यकता नहीं है, शायद सबसे अच्छा समाधान है। यह आसानी से छुपाया जाता है (लाइसेंसिंग के विपरीत) और जितना संभव हो उतना अनजान होने के लिए तैयार किया जा सकता है।

Answer 5

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

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

अंत में, एंटी-वायरस विक्रेताओं को समुद्री डाकू प्रतियों की रिपोर्ट करें। एपीके की आपूर्ति प्रतियां। वे अपने डेटाबेस में हस्ताक्षर जोड़ देंगे ताकि यह संभावित रूप से खतरनाक हो सके।