android - एपीके फ़ाइल की रिवर्स इंजीनियरिंग से कैसे बचें?




security proguard (20)

1. मैं एंड्रॉइड एपीके की रिवर्स इंजीनियरिंग से पूरी तरह से कैसे बच सकता हूं? क्या यह संभव है?

AFAIK, रिवर्स इंजीनियरिंग के पूर्ण बचाव के लिए कोई चाल नहीं है।

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

2. मैं सभी ऐप के संसाधनों, संपत्तियों और स्रोत कोड की रक्षा कैसे कर सकता हूं ताकि हैकर किसी भी तरह से एपीके फ़ाइल को हैक नहीं कर सकें?

हालांकि हैकिंग को कठिन बनाने के लिए आप अलग-अलग चाल कर सकते हैं। उदाहरण के लिए, obfuscation (यदि यह जावा कोड है) का उपयोग करें। यह आम तौर पर रिवर्स इंजीनियरिंग को धीमा कर देता है।

3. हैकिंग को और अधिक कठिन या असंभव बनाने का कोई तरीका है? मेरी एपीके फ़ाइल में स्रोत कोड की सुरक्षा के लिए मैं और क्या कर सकता हूं?

जैसा कि सभी कहते हैं, और जैसा कि आप शायद जानते हैं, कोई 100% सुरक्षा नहीं है। लेकिन एंड्रॉइड के लिए शुरू करने की जगह, जिसे Google ने बनाया है, ProGuard है। यदि आपके पास साझा लाइब्रेरीज़ को शामिल करने का विकल्प है, तो आप फ़ाइल आकार, एकीकरण इत्यादि को सत्यापित करने के लिए आवश्यक कोड को C ++ में शामिल कर सकते हैं। यदि आपको प्रत्येक बिल्ड पर अपने एपीके के लाइब्रेरी फ़ोल्डर में बाहरी मूल लाइब्रेरी जोड़ने की आवश्यकता है, तो आप इसका उपयोग कर सकते हैं नीचे दिए गए सुझाव से।

लाइब्रेरी को मूल लाइब्रेरी पथ में रखें जो आपके प्रोजेक्ट फ़ोल्डर में "libs" के लिए डिफ़ॉल्ट है। यदि आपने 'आर्मेबी' लक्ष्य के लिए मूल कोड बनाया है तो इसे libs / armeabi के तहत रखें। अगर यह armeabi-v7a के साथ बनाया गया था तो इसे libs / armeabi-v7a के तहत रखें

<project>/libs/armeabi/libstuff.so

मैं एंड्रॉइड के लिए एक भुगतान प्रसंस्करण ऐप विकसित कर रहा हूं, और मैं एक हैकर को APK फ़ाइल से किसी भी संसाधन, संपत्ति या स्रोत कोड तक पहुंचने से रोकना चाहता हूं।

अगर कोई .zk एक्सटेंशन को .zip में बदलता है तो वे इसे अनजिप कर सकते हैं और आसानी से सभी ऐप के संसाधनों और संपत्तियों तक पहुंच सकते हैं, और dex2jar और जावा dex2jar का उपयोग करके, वे स्रोत कोड तक पहुंच सकते हैं। एंड्रॉइड एपीके फ़ाइल को रिवर्स इंजीनियर करना बहुत आसान है - अधिक जानकारी के लिए स्टैक ओवरफ़्लो प्रश्न एक एपीके फ़ाइल से किसी प्रोजेक्ट में इंजीनियरिंग को रिवर्स देखें।

मैंने एंड्रॉइड एसडीके के साथ प्रदान किए गए प्रोगार्ड टूल का उपयोग किया है। जब मैं एक हस्ताक्षरित कीस्टोर और प्रोगार्ड का उपयोग करके जेनरेट की गई एपीके फ़ाइल को इंजीनियर करता हूं, तो मुझे obfuscated कोड मिलता है। हालांकि, एंड्रॉइड घटकों के नाम अपरिवर्तित रहते हैं और कुछ कोड, जैसे कि ऐप में उपयोग किए जाने वाले प्रमुख मूल्य, अपरिवर्तित बनी हुई हैं। प्रोगार्ड दस्तावेज के अनुसार उपकरण मैनिफेस्ट फ़ाइल में उल्लिखित घटकों को खराब नहीं कर सकता है।

अब मेरे प्रश्न हैं:

  1. मैं एंड्रॉइड एपीके की रिवर्स इंजीनियरिंग से पूरी तरह से कैसे बच सकता हूं? क्या यह संभव है?
  2. मैं सभी ऐप के संसाधनों, संपत्तियों और स्रोत कोड की रक्षा कैसे कर सकता हूं ताकि हैकर किसी भी तरह से एपीके फ़ाइल को हैक नहीं कर सकें?
  3. हैकिंग को और अधिक कठिन या असंभव बनाने का कोई तरीका है? मेरी एपीके फ़ाइल में स्रोत कोड की सुरक्षा के लिए मैं और क्या कर सकता हूं?

1. मैं एंड्रॉइड एपीके की रिवर्स इंजीनियरिंग से पूरी तरह से कैसे बच सकता हूं? क्या यह संभव है?

असंभव

2. मैं सभी ऐप के संसाधनों, संपत्तियों और स्रोत कोड की रक्षा कैसे कर सकता हूं ताकि हैकर किसी भी तरह से एपीके फ़ाइल को हैक नहीं कर सकें?

असंभव

3. हैकिंग को और अधिक कठिन या असंभव बनाने का कोई तरीका है? मेरी एपीके फ़ाइल में स्रोत कोड की सुरक्षा के लिए मैं और क्या कर सकता हूं?

अधिक कठिन - संभव है, लेकिन वास्तव में यह औसत उपयोगकर्ता के लिए अधिक कठिन होगा, जो हैकिंग गाइड के लिए सिर्फ गुगल है। अगर कोई वास्तव में आपके ऐप को हैक करना चाहता है - इसे जल्द या बाद में हैक किया जाएगा।


1. मैं एंड्रॉइड एपीके की रिवर्स इंजीनियरिंग से पूरी तरह से कैसे बच सकता हूं? क्या यह संभव है?

वह असंभव है

2. मैं सभी ऐप के संसाधनों, संपत्तियों और स्रोत कोड की रक्षा कैसे कर सकता हूं ताकि हैकर किसी भी तरह से एपीके फ़ाइल को हैक नहीं कर सकें?

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

यह वास्तव में एक बहुत अच्छा टूल है और आपके कोड के पदचिह्न को कम करने के दौरान आपके कोड को 'रिवर्सिंग' करने में कठिनाई को बढ़ा सकता है।

एकीकृत ProGuard समर्थन: ProGuard अब एसडीके उपकरण के साथ पैक किया गया है। डेवलपर्स अब रिलीज बिल्ड के एकीकृत हिस्से के रूप में अपने कोड को खराब कर सकते हैं।

3. हैकिंग को और अधिक कठिन या असंभव बनाने का कोई तरीका है? मेरी एपीके फ़ाइल में स्रोत कोड की सुरक्षा के लिए मैं और क्या कर सकता हूं?

शोध करते समय, मुझे HoseDex2Jar बारे में पता HoseDex2Jar । यह टूल आपके कोड को डिकंपलिंग से सुरक्षित रखेगा, लेकिन ऐसा लगता है कि आपके कोड को पूरी तरह से सुरक्षित रखना संभव नहीं है।

सहायक लिंक में से कुछ, आप उन्हें संदर्भित कर सकते हैं।


ऐप सुरक्षा का पहला नियम: कोई भी मशीन जिस पर हमलावर को अप्रतिबंधित भौतिक या इलेक्ट्रॉनिक पहुंच प्राप्त होती है, अब आपके हमलावर से संबंधित है, भले ही यह वास्तव में कहां है या आपने इसके लिए क्या भुगतान किया है।

ऐप सुरक्षा का दूसरा नियम: कोई भी सॉफ्टवेयर जो भौतिक सीमाओं को छोड़ देता है जिसके अंदर एक हमलावर घुसपैठ नहीं कर सकता है, अब आपके हमलावर से संबंधित है, इस पर ध्यान दिए बिना कि आप इसे कितना समय बिताते हैं।

तीसरा नियम: कोई भी जानकारी जो उन भौतिक सीमाओं को छोड़ देती है जो हमलावर घुसपैठ नहीं कर सकते हैं अब आपके हमलावर से संबंधित हैं, इससे कोई फर्क नहीं पड़ता कि यह आपके लिए कितना मूल्यवान है।

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

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

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

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

आपके द्वारा हार्ड-कोड किए गए इन महत्वपूर्ण मानों को एप्लिकेशन के स्रोत कोड से पूरी तरह हटा दिया जाना चाहिए। इसके बजाय, वे तीन स्थानों में से एक में होना चाहिए; डिवाइस पर अस्थिर स्मृति, जो एक हमलावर के लिए ऑफ़लाइन प्रति प्राप्त करने के लिए कठिन (लेकिन अभी भी असंभव नहीं है); सर्वर क्लस्टर पर स्थायी रूप से, जिसके लिए आप लोहा मुट्ठी के साथ पहुंच नियंत्रित करते हैं; या किसी दूसरे डेटा स्टोर में आपके डिवाइस या सर्वर से संबंधित नहीं है, जैसे भौतिक कार्ड या आपके उपयोगकर्ता की यादों में (जिसका अर्थ यह अंततः अस्थिर स्मृति में होगा, लेकिन यह लंबे समय तक नहीं होना चाहिए)।

निम्नलिखित योजना पर विचार करें। उपयोगकर्ता ऐप के लिए डिवाइस में मेमोरी से अपने क्रेडेंशियल्स में प्रवेश करता है। दुर्भाग्यवश, आपको विश्वास करना चाहिए कि उपयोगकर्ता की डिवाइस पहले से ही एक कीलॉगर या ट्रोजन द्वारा समझौता नहीं किया गया है; इस संबंध में सबसे अच्छा आप बहु-कारक सुरक्षा को कार्यान्वित करना है, उपयोगकर्ता द्वारा उपयोग किए जाने वाले उपकरणों (मैक / आईपी, आईएमईआई, आदि) के बारे में कठोर पहचानने वाली जानकारी को याद करके, और कम से कम एक अतिरिक्त चैनल प्रदान करना जो एक अपरिचित डिवाइस पर लॉगिन प्रयास सत्यापित किया जा सकता है।

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

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

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

अब, हमलावर जो कंप्यूटर चाहता है वह आपका सर्वर है, क्योंकि क्लाइंट ऐप / डिवाइस वह चीज है जो उसे पैसे कमा सकती है या अन्य लोगों को उनके आनंद के लिए दर्द कर सकती है। ठीक है; आप अपने ग्राहकों को सुरक्षित रखने की कोशिश करने से सर्वर को सुरक्षित करने के लिए अपने पैसे खर्च करने और प्रयास के लिए बहुत अधिक धमाके प्राप्त करते हैं। सर्वर सभी प्रकार के फायरवॉल और अन्य इलेक्ट्रॉनिक सुरक्षा के पीछे हो सकता है, और अतिरिक्त रूप से स्टील, कंक्रीट, कीकार्ड / पिन एक्सेस, और 24 घंटे की वीडियो निगरानी के पीछे शारीरिक रूप से सुरक्षित किया जा सकता है। आपके हमलावर को वास्तव में सर्वर पर किसी भी तरह की पहुंच प्राप्त करने के लिए वास्तव में बहुत परिष्कृत होना आवश्यक है, और आप तुरंत इसके बारे में जानना चाहिए (चाहिए)।

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


Nothing is secure when you put it on end-users hand but some common practice may make this harder for attacker to steal data.

  • Put your main logic (algorithms) into server side.
  • Communicate with server and client; make sure communication b/w server and client is secured via SSL or HTTPS; or use other techniques key-pair generation algorithms (ECC, RSA). Ensure that sensitive information is remain End-to-End encrypted.
  • Use sessions and expire them after specific time interval.
  • Encrypt resources and fetch them from server on demand.
  • Or you can make Hybrid app which access system via webview protect resource + code on server

Multiple approaches; this is obvious you have to sacrifice among performance and security


AFAIK, आप अभी सुरक्षित / सुरक्षित निर्देशिका में फ़ाइलों को सुरक्षित नहीं कर सकते हैं।

हालांकि, आपके स्रोत कोड की सुरक्षा के लिए आप कुछ कदम उठा सकते हैं, या कम से कम यह सब कुछ नहीं होने पर क्या करता है।

  1. ProGuard जैसे टूल का प्रयोग करें। ये आपके कोड को खराब कर देंगे, और असंभव नहीं होने पर अपूर्ण होने पर इसे पढ़ने में कठिनाई होगी।
  2. ऐप से सेवा के सबसे महत्वपूर्ण हिस्सों को ले जाएं, और एक webservice में, PHP सर्वर जैसे सर्वर साइड भाषा के पीछे छुपाएं। उदाहरण के लिए, यदि आपके पास एक एल्गोरिदम है जो आपको लिखने के लिए दस लाख डॉलर ले गया है। आप स्पष्ट रूप से नहीं चाहते हैं कि लोग इसे आपके ऐप से चुरा लें। एल्गोरिदम को ले जाएं और इसे दूरस्थ सर्वर पर डेटा संसाधित करें, और ऐप का उपयोग केवल डेटा के साथ प्रदान करने के लिए करें। या एनएसके का उपयोग उन्हें .so फाइलों में मूल रूप से लिखने के लिए करें, जो एपीक्स की तुलना में कम हो जाने की संभावना कम है। मुझे नहीं लगता कि .so फाइलों के लिए एक डिकंपेलर अभी भी मौजूद है (और यदि यह भी हुआ, तो यह जावा डिकंपेलर जितना अच्छा नहीं होगा)। इसके अतिरिक्त, टिप्पणियों में उल्लिखित @nikolay के रूप में, सर्वर और डिवाइस के बीच बातचीत करते समय आपको SSL का उपयोग करना चाहिए।
  3. डिवाइस पर मूल्यों को संग्रहीत करते समय, उन्हें कच्चे प्रारूप में संग्रहित न करें। उदाहरण के लिए, यदि आपके पास कोई गेम है, और आप गेम मुद्रा में राशि संग्रहीत कर रहे हैं तो उपयोगकर्ता को SharePreferences में है। आइए मान लें कि यह 10000 सिक्के है। 10000 सीधे सहेजने के बजाय, इसे एल्गोरिदम ((currency*2)+1)/13 जैसे ((currency*2)+1)/13 का उपयोग करके सहेजें। तो 10000 बजाय, आप 1538.53846154 को 1538.53846154 गए 1538.53846154 में सहेजते हैं। हालांकि, उपरोक्त उदाहरण सही नहीं है, और आपको एक समीकरण के साथ आने के लिए काम करना होगा जो गोलियों को गोल करने के लिए मुद्रा खोना नहीं होगा।
  4. आप सर्वर साइड कार्यों के लिए एक ही काम कर सकते हैं। अब एक उदाहरण के लिए, आइए वास्तव में अपना भुगतान प्रसंस्करण ऐप लें। मान लें कि उपयोगकर्ता को $200 भुगतान करना है। सर्वर पर कच्चे $200 मूल्य भेजने के बजाय, $200 तक जोड़ने वाले छोटे, पूर्वनिर्धारित, मानों की एक श्रृंखला भेजें। उदाहरण के लिए, अपने सर्वर पर एक फ़ाइल या टेबल है जो शब्दों के साथ शब्दों को समतुल्य करता है। तो मान लीजिए कि Charlie $47 और John से $3 अनुरूप है। तो $200 भेजने की बजाय, आप Charlie चार बार और John चार बार भेज सकते हैं। सर्वर पर, व्याख्या करें कि उनका क्या अर्थ है और इसे जोड़ें। यह एक हैकर को आपके सर्वर पर मनमाना मूल्य भेजने से रोकता है, क्योंकि वे नहीं जानते कि कौन सा शब्द किस मूल्य से मेल खाता है। सुरक्षा के एक अतिरिक्त उपाय के रूप में, आप इसके लिए बिंदु 3 के समान समीकरण भी प्राप्त कर सकते हैं, और प्रत्येक n संख्या में कीवर्ड बदल सकते हैं।
  5. अंत में, आप अपने ऐप में यादृच्छिक बेकार स्रोत कोड डाल सकते हैं, ताकि हैकर एक घास के मैदान में सुई की तलाश में है। इंटरनेट से स्निपेट युक्त यादृच्छिक कक्षाएं डालें, या केवल Fibonacci अनुक्रम जैसे यादृच्छिक चीजों की गणना के लिए कार्य करें। सुनिश्चित करें कि ये कक्षाएं संकलित हैं, लेकिन ऐप की वास्तविक कार्यक्षमता द्वारा उपयोग नहीं की जाती हैं। इन झूठी कक्षाओं में से पर्याप्त जोड़ें, और हैकर को आपके वास्तविक कोड को खोजने में कठिन समय लगेगा।

सब कुछ, आपके ऐप को 100% सुरक्षित रखने का कोई तरीका नहीं है। आप इसे कठिन बना सकते हैं, लेकिन असंभव नहीं है। आपके वेब सर्वर से समझौता किया जा सकता है, हैकर आपके लेन-देन की मात्रा और आपके द्वारा भेजे जाने वाले कीवर्ड की निगरानी करके आपके कीवर्ड का पता लगा सकता है, हैकर दर्द से स्रोत के माध्यम से जा सकता है और यह पता लगा सकता है कि कौन सा कोड डमी है।

आप केवल लड़ सकते हैं, लेकिन कभी जीत नहीं सकते।


एंड्रॉइड एपीके की रिवर्स इंजीनियरिंग का 100% टालना संभव नहीं है, लेकिन आप इन तरीकों का उपयोग अधिक डेटा निकालने से बचने के लिए कर सकते हैं, जैसे स्रोत कोड, संपत्तियां आपके एपीके और संसाधन:

  1. आवेदन कोड obfuscate करने के लिए ProGuard का उपयोग करें

  2. अपने अनुप्रयोग कोर और .so फ़ाइलों में कोड का सुरक्षित भाग रखने के लिए सी और सी ++ का उपयोग करके एनडीके का उपयोग करें

  3. संसाधनों को सुरक्षित करने के लिए, एपीके के साथ संपत्ति फ़ोल्डर में सभी महत्वपूर्ण संसाधन शामिल न करें। आवेदन के समय इन संसाधनों को पहली बार शुरू करें।


कंप्यूटिंग के इतिहास में किसी भी समय सॉफ्टवेयर के रिवर्स-इंजीनियरिंग को रोकने के लिए कभी भी संभव नहीं है जब आप अपने हमलावर को इसकी एक कार्य प्रतिलिपि देते हैं। इसके अलावा, सबसे अधिक संभावना में, यह कभी भी संभव नहीं होगा

इसके साथ ही, एक स्पष्ट समाधान है: अपने हमलावर को अपने रहस्य न दें। जबकि आप अपने एपीके की सामग्री की रक्षा नहीं कर सकते हैं, आप जो भी बचा सकते हैं वह वह है जिसे आप वितरित नहीं करते हैं। आम तौर पर यह सर्वर-साइड सॉफ़्टवेयर होता है जो सक्रियण, भुगतान, नियम-प्रवर्तन, और कोड के अन्य रसदार बिट्स जैसी चीजों के लिए उपयोग किया जाता है। आप अपने एपीके में उन्हें वितरित करके बहुमूल्य संपत्तियों की रक्षा कर सकते हैं। इसके बजाए, एक सर्वर स्थापित करें जो आपके ऐप से अनुरोधों का जवाब देता है, संपत्तियों का उपयोग करता है (जो भी हो सकता है) और फिर परिणाम को ऐप पर वापस भेजता है। यदि यह मॉडल आपके द्वारा दिये गये संपत्तियों के लिए काम नहीं करता है, तो आप अपनी रणनीति को फिर से सोचना चाहेंगे।

इसके अलावा, यदि आपका प्राथमिक लक्ष्य ऐप चोरी को रोकने के लिए है : यहां तक ​​कि परेशान भी न करें। इस समस्या पर आप पहले से ही अधिक समय और धन जला चुके हैं, किसी भी एंटी-पाइरेसी उपाय की संभावना शायद आपको बचाने की उम्मीद कर सकती है। इस समस्या को हल करने के लिए निवेश पर वापसी इतनी कम है कि इसके बारे में सोचने का अर्थ भी नहीं है।


यहां अन्य उल्लिखित उत्तर सही हैं। मैं सिर्फ एक और विकल्प प्रदान करना चाहता हूं।

कुछ कार्यक्षमता के लिए जो आप महत्वपूर्ण मानते हैं, आप अपने ऐप में WebView नियंत्रण होस्ट कर सकते हैं। कार्यक्षमता तब आपके वेब सर्वर पर लागू की जाएगी। ऐसा लगता है कि यह आपके आवेदन में चल रहा है।


यहां कुछ विधियां दी गई हैं जिन्हें आप आजमा सकते हैं:

  1. ProGuard जैसे obfuscation और उपकरण का उपयोग करें।
  2. स्रोत और डेटा के कुछ हिस्से को एन्क्रिप्ट करें।
  3. छेड़छाड़ का पता लगाने के लिए ऐप में एक मालिकाना इनबिल्ट चेकसम का उपयोग करें।
  4. डीबगर में लोड होने से बचने के लिए कोड का परिचय दें, यानी, ऐप को डीबगर का पता लगाने और डीबगर से बाहर निकलने / मारने की क्षमता रखने दें।
  5. एक ऑनलाइन सेवा के रूप में प्रमाणीकरण अलग करें।
  6. आवेदन विविधता का प्रयोग करें
  7. डिवाइस को प्रमाणीकृत करने से पहले विभिन्न उपप्रणाली से उपकरणों के हार्डवेयर हस्ताक्षर उदाहरण के लिए उंगली मुद्रण तकनीक का उपयोग करें।

APK signature scheme v2 in Android N

The PackageManager class now supports verifying apps using the APK signature scheme v2. The APK signature scheme v2 is a whole-file signature scheme that significantly improves verification speed and strengthens integrity guarantees by detecting any unauthorized changes to APK files.

To maintain backward-compatibility, an APK must be signed with the v1 signature scheme (JAR signature scheme) before being signed with the v2 signature scheme. With the v2 signature scheme, verification fails if you sign the APK with an additional certificate after signing with the v2 scheme.

APK signature scheme v2 support will be available later in the N Developer Preview.

http://developer.android.com/preview/api-overview.html#apk_signature_v2


Tool: Using Proguard in your application it can be restricted to reverse engineering your application


Aren't TPM chips (Trusted Platform Module) supposed to manage protected code for you ? They are becoming common on PCs (especially Apple ones) and they may already exist in today's smartphone chips. Unfortunately there is no OS API to make use of it yet. Hopefully Android will add support for this one day. That's also the key to clean content DRM (which Google is working on for WebM).


As someone who worked extensively on payment platforms, including one mobile payments application (MyCheck), I would say that you need to delegate this behaviour to the server, no user name or password for the payment processor (whichever it is) should be stored or hardcoded in the mobile application, that's the last thing you want, because the source can be understood even when if you obfuscate the code.

Also, you shouldn't store credit cards or payment tokens on the application, everything should be, again, delegated to a service you built, it will also allow you later on, be PCI-compliant more easily, and the Credit Card companies won't breath down your neck (like they did for us).


Basically, there are 5 methods to protect your APK. Isolate Java Program, Encrypt Class Files, Convert to Native Codes, Code Obfuscation and Online Encryption I suggest you use online encryption because it is safe and convenient. You needn't spend to much time to achieve this. Such as APK Protect , it is an online encryption website for APK. It provides Java codes and C++ codes protection to achieve anti-debugging and decompile effects. The operation process is simple and easy.



If your app is this sensitive then you should consider the payment processing part at server side. Try to change your payment processing algorithms. Use android app only for collecting and displaying user information (ie account balance) and rather than processing payments within java codes, send this task to your server using a secure SSL protocol with encrypted parameters. Create fully encrypted and secure API to communicate with your server.

Of course, It can also be hacked too and it has nothing to do with source codes protection but consider it another security layer to make it harder for hackers to trick your app.


Its not possible to completely avoid RE but By making them more complex internally, you put make it more difficult for attackers to see the clear operation of the app, which may reduce the number of attack vectors.

If the application handles highly sensitive data, Various techniques exist which can increase the complexity of reverse engineering your code. One technique is to use C/C++ to limit easy runtime manipulation by the attacker. There are ample C and C++ libraries that are very mature and easy to integrate with Android offers JNI. An attacker must first circumvent the debugging restrictions in order to attack the application on a low level. This adds further complexity to an attack. Android applications should have android:debuggable=”false” set in the application manifest to prevent easy run time manipulation by an attacker or malware.

Trace Checking – An application can determine whether or not it is currently being traced by a debugger or other debugging tool. If being traced, the application can perform any number of possible attack response actions, such as discarding encryption keys to protect user data, notifying a server administrator, or other such type responses in an attempt to defend itself. This can be determined by checking the process status flags or using other techniques like comparing the return value of ptrace attach, checking parent process, blacklist debuggers in the process list or comparing timestamps on different places of the program.

Optimizations - To hide advanced mathematical computations and other types of complex logic, utilizing compiler optimizations can help obfuscate the object code so that it cannot easily be disassembled by an attacker, making it more difficult for an attacker to gain an understanding of the particular code. In Android this can more easily be achieved by utilizing natively compiled libraries with the NDK. In addition, using an LLVM Obfuscator or any protector SDK will provide better machine code obfuscation.

Stripping binaries – Stripping native binaries is an effective way to increase the amount of time and skill level required of an attacker in order to view the makeup of your application's low level functions. By stripping a binary, the symbol table of the binary is stripped, so that an attacker cannot easily debug or reverse engineer an application.You can refer techniques used on GNU/Linux systems like sstriping or using UPX.

And at last you must be aware about obfuscation and tools like ProGuard.


There is no way to completely avoid reverse engineering of an APK. To protect application assets, resources, you can use encryption.

  • Encryption will make harder to use it without decryption.choosing some strong encryption algorithm will make cracking harder.
  • Adding some spoof code into your main logic to make more harder for cracking.
  • If you can write your critical logic in any native language and that surely make harder for decompile.
  • Using any third party security frameworks like Quixxi

While I agree there's no 100% solution that's going to protect your code, v3 of HoseDex2Jar is now up if you want to give it a try.





reverse-engineering