एंड्रॉइड एप्लिकेशन में रनटाइम स्टेट चेक को अक्षम करना

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

किसी एक परियोजना के प्रदर्शन का आकलन करते समय, हमारी टीम ने तुरंत महसूस किया कि मामला आसान नहीं होगा। डेवलपर्स ने कार्यक्रम में सूचना सुरक्षा के मुद्दे पर अच्छी तरह से संपर्क किया और निष्पादन पर्यावरण की स्थिति पर चेक लागू किया। आवेदन निम्न शर्तों में से किसी के तहत शुरू नहीं हुआ:

• डिवाइस को रट दिया गया था;
• एक एमुलेटर का उपयोग किया गया था;
• यूएसबी के माध्यम से कनेक्शन की उपलब्धता;
• डेवलपर मोड का उपयोग करना।

डेवलपर्स ने स्रोत कोड को बाधित नहीं किया और कोड संशोधन के लिए कोई अंतर्निहित चेक नहीं था, जिसने मुझे उन तरीकों का विश्लेषण करने की अनुमति दी, जिनके द्वारा चेक किए गए थे और उनके साथ आवश्यक जोड़तोड़ करते थे।

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

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

कक्षाओं की सूची को देखने के बाद, मुझे एक फाइल मिली जो फोन की दिनचर्या (चित्र 1 देखें) के लिए ज़िम्मेदार है - rootingcheck / RootBeerNative.java।


अंजीर। 1. आवेदन वर्गों की सूची

कक्षा का विश्लेषण करने के बाद, यह स्पष्ट हो गया कि हमें कॉल के लिए फ़ंक्शंस चेकफ़ॉररूट () और सेटलॉगडेबुगमेज़ () (चित्र 2 देखें) की आवश्यकता है।


अंजीर। 2. rutovanost के लिए जाँच करने के लिए कक्षा का स्रोत कोड

Grep कमांड का उपयोग करने पर, हमें निम्नलिखित परिणाम मिलते हैं, जो हमें दिखाते हैं कि कौन सी फाइलों में कॉल CheckForRoot () और setLogDebugMessage () विधियों के लिए है।

खोज परिणाम:
root @ kali: ~ / डेस्कटॉप # grep -nr 'RootBeerNative' ******** _ v_8.9_ /

********_v_0.9.2/smali/rootingcheck/RootBeerNative.smali:1:.class public Lrootingcheck/RootBeerNative; ********_v_0.9.2/smali/rootingcheck/RootBeerNative.smali:17: sput-boolean v0, Lrootingcheck/RootBeerNative;->?:Z ********_v_0.9.2/smali/rootingcheck/RootBeerNative.smali:28: sput-boolean v0, Lrootingcheck/RootBeerNative;->?:Z ********_v_0.9.2/smali/rootingcheck/RootBeerNative.smali:57: sget-boolean v0, Lrootingcheck/RootBeerNative;->?:Z ********_v_0.9.2/smali/o/CM.smali:591: new-instance v1, Lrootingcheck/RootBeerNative; ********_v_0.9.2/smali/o/CM.smali:593: invoke-direct {v1}, Lrootingcheck/RootBeerNative;-><init>()V ********_v_0.9.2/smali/o/CM.smali:685: new-instance v0, Lrootingcheck/RootBeerNative; ********_v_0.9.2/smali/o/CM.smali:687: invoke-direct {v0}, Lrootingcheck/RootBeerNative;-><init>()V ********_v_0.9.2/smali/o/CM.smali:689: invoke-static {}, Lrootingcheck/RootBeerNative;->?()Z ********_v_0.9.2/smali/o/CM.smali:753: new-instance v4, Lrootingcheck/RootBeerNative; ********_v_0.9.2/smali/o/CM.smali:755: invoke-direct {v4}, Lrootingcheck/RootBeerNative;-><init>()V ********_v_0.9.2/smali/o/CM.smali:764: invoke-virtual {v4, v3}, Lrootingcheck/RootBeerNative;->checkForRoot([Ljava/lang/Object;)I ********_v_0.9.2/smali/o/xZ$5.smali:257: new-instance v1, Lrootingcheck/RootBeerNative; ********_v_0.9.2/smali/o/xZ$5.smali:259: invoke-direct {v1}, Lrootingcheck/RootBeerNative;-><init>()V ********_v_0.9.2/smali/o/xZ$5.smali:261: invoke-static {}, Lrootingcheck/RootBeerNative;->?()Z 

root @ kali: ~ / डेस्कटॉप # grep -nr 'setLogDebugMessages' ******** _ v_0.9.2 /

 ********_v_0.9.2/smali/o/CM.smali:599: invoke-virtual {v1, v0}, Lrootingcheck/RootBeerNative;->setLogDebugMessages(Z)I ********_v_0.9.2/smali/o/CM.smali:761: invoke-virtual {v4, v0}, Lrootingcheck/RootBeerNative;->setLogDebugMessages(Z)I 

लेकिन ये सभी चेक नहीं थे। MainActivity.java वर्ग का विश्लेषण करने के बाद, हमने फ़ंक्शन कॉल को पाया जहां तार "सु", "परीक्षण-कुंजी" और "कौन सा" पारित किए जाते हैं, जिसकी सहायता से सत्यापन किया जाता है (चित्र 3 देखें)।


चित्र 3। नियमित जाँच

और फिर से, grep कमांड के साथ, हम दिनचर्या की जाँच के लिए smali-files में देखते हैं:

खोज परिणाम:
रूट @ काली: ~ / डेस्कटॉप # grep -nr 'su' ******** _ v_0.9.2 /

 ********_v_0.9.2/smali/o/CM.smali:443: const-string v2, "su" ********_v_0.9.2/smali/o/CM.smali:706: const-string v2, "su" ********_v_0.9.2/smali/o/xZ$5.smali:172: const-string v1, "su" ********_v_0.9.2/smali/o/xZ$5.smali:347: const-string v0, "su" 

root @ kali: ~ / डेस्कटॉप # grep -nr 'परीक्षण-कुंजी' ******** _ v_0.9.9.2

 ********_v_0.9.2/smali/o/xZ$5.smali:141: const-string v1, "test-keys" ********_v_0.9.2/smali/o/xZ$5.smali:374: const-string v0, "test-keys" 

रूट @ काली: ~ / डेस्कटॉप # grep -nr 'जो' ******** _ v_0.9.2 /

 ********_v_0.9.2/smali/o/CM.smali:437: const-string v2, "which" 

लेख में मैं रूटीन चेक के पाए गए संशोधनों में से केवल एक दिखाऊंगा। थोड़ा हेरफेर करने के बाद, अर्थात् 1 से 0 को बदलते हुए, नियमित जांच को हटा दिया गया था।


अंजीर। 4. यदि फोन रूट किया जाता है तो चर का मान एक के बराबर है


अंजीर। 5. यदि फोन रूट किया जाता है तो अब वेरिएबल का मूल्य शून्य है

उसके बाद - कार्यक्रम को इकट्ठा किया जा सकता है, आपकी रिलीज़ कुंजी के साथ हस्ताक्षर किए जा सकते हैं और मोबाइल फोन पर चल सकते हैं। लेकिन अगर दो BUT के लिए नहीं! अर्थात्:

1. यूएसबी कनेक्शन की जांच;
2. डेवलपर मोड को शामिल करने के लिए जाँच - USB कनेक्शन और शामिल डेवलपर मोड गतिशील विश्लेषण की अनुमति देता है।

डेवलपर मोड चेक को रूटीन चेक की तरह ही बंद कर दिया जाता है - चेक में यूनिट को शून्य में बदलकर

MainActivity.java वर्ग में, हम उस पंक्ति को पाते हैं जो डेवलपर मोड की जाँच के लिए ज़िम्मेदार है (चित्र 6 देखें)। उसके बाद grep वें उन फाइलों की तलाश करते हैं जिनमें स्ट्रिंग "development_settings_enabled" मौजूद है और चेक को संशोधित करें - 1 से 0 बदलें (चित्र 7 और 8 देखें)।


अंजीर। 6. जांचें कि क्या डेवलपर मोड फोन पर सक्षम है

खोज परिणाम:
grep -nr "development_settings_enabled" ******** _ v_0.9.2 \

 Binary file ********_v_0.9.2\/build/apk/classes.dex matches ********_v_0.9.2\/smali/o/xZ$1.smali:49: const-string v1, "development_settings_enabled" 

अंजीर। 7. जिस स्थान पर आपको संशोधन करने की आवश्यकता है


अंजीर। 8. संशोधन

सभी जोड़तोड़ के बाद, आप प्रोग्राम को डेवलपर मोड में चला सकते हैं।

इसके बाद, USB कनेक्शन की जांच बंद करें। यह जाँच MainActivity.java वर्ग में है (चित्र 9 देखें)। Grep के बिना, हम लाइन को MainActivity.smali में पाते हैं, हम उस लाइन को ढूंढते हैं जिसमें USB चेक - android.hardware.usb.action.USB_STATE वाली लाइन है। उसके बाद, स्माईली कोड में, हम लाइन को किसी अन्य अनुमतियों के लिए संशोधित करते हैं जो "गलत" लौटाती है (चित्र 10 देखें)।


अंजीर। 9. MainActivity.java कोड में USB कनेक्शन की जाँच करें


अंजीर। 10. MainActivity.smali में हटाए जाने वाले कोड की लाइन

अब यह आपकी रिलीज़ कुंजी उत्पन्न करने और इसके साथ एप्लिकेशन पर हस्ताक्षर करने के लिए बना हुआ है। यह निम्नानुसार किया जाता है:

1. आपको दो एप्लिकेशन इंस्टॉल करने की आवश्यकता है: Keytool और Jarsinger।
2. एप्लिकेशन को इकट्ठा करने के लिए कमांड चलाएँ:
3. apktool b C: \ Users \ User \ Desktop \ ********
4. अगला: सीडी ******** \ dist \
5. अगला: Keytool.exe -genkey -alias key.keystore -keyalg RSA -validity 20000 -keystore key.keystore
6. अगला: Jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore key.keystore ********। Apk key.keystore
7. अगला: jarsigner -verify -verbose -certs ********। Apk

यहां, सिद्धांत रूप में, सभी जोड़तोड़ समाप्त हो गए हैं। अब हम adb install या स्मार्टफोन डायरेक्टरी से फोन पर एप्लिकेशन इंस्टॉल करते हैं और आप डायनेमिक भेद्यता परीक्षण कर सकते हैं।

एप्लिकेशन इंस्टॉल करने के बाद, इसे चलाएं (चित्र 11 और छवि 12 देखें)।


निष्कर्ष

व्यावहारिक उदाहरण में, मैंने दिखाया कि आप रनटाइम की स्थिति पर कुछ चेक को कैसे अक्षम कर सकते हैं। इसके अलावा, अन्य उपकरणों की मदद से, हमने भेद्यता का विश्लेषण किया, लेकिन यह एक अलग कहानी है ...

कोड सुरक्षा के प्रति लापरवाह रवैया क्या हो सकता है:

• ये कुछ चेक के परिधि हैं जो प्रोग्राम में एम्बेडेड हैं
• तृतीय-पक्ष कोड का कार्यान्वयन, जिसके बाद कार्यक्रम को प्रकाशित किया जा सकता है और दुर्भावनापूर्ण के रूप में उपयोग किया जा सकता है

मैं अपनी रक्षा कैसे कर सकता हूं? बाइटकोड में, हमने पहिया को सुदृढ़ नहीं करने का फैसला किया और सुझाव दिया कि ग्राहक स्रोत कोड को बाधित करते हैं और उन कार्यों का उपयोग करते हैं जो स्रोत कोड के संशोधन की जांच करते हैं।

पुनश्च

आप एक अधिक उन्नत विश्लेषण विधि का उपयोग कर सकते हैं - यह बदबूदार डिबगिंग है। आप मैनुअल में इसके बारे में अधिक पढ़ सकते हैं।

संदर्भ के लिए थोड़ा, मैंने उन पंक्तियों की एक सूची तैयार की है जिनका उपयोग दिनचर्या की जाँच के लिए किया जाता है:

• "टेस्ट-कुंजी";
• "/System/app/Superuser.apk";
• "" sbin / su ";
• "" प्रणाली / बिन / सु ";
• "" प्रणाली / xbin / su ";
• "" डेटा / स्थानीय / xbin / su ";
• "" डेटा / स्थानीय / बिन / सु ";
• "" प्रणाली / एसडी / xbin / सु ";
• "" प्रणाली / बिन / असफल / सु ";
• "" डेटा / स्थानीय / सु ";
• "" सु / बिन / सु ";
• "" प्रणाली / xbin / जो ";
• "र";
• "किस"।