Android Applications Basics
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
दो परतें हैं:
OS, जो स्थापित अनुप्रयोगों को एक-दूसरे से अलग रखता है।
अनुप्रयोग स्वयं, जो डेवलपर्स को कुछ कार्यक्षमताओं को उजागर करने की अनुमति देता है और अनुप्रयोग क्षमताओं को कॉन्फ़िगर करता है।
प्रत्येक अनुप्रयोग को एक विशिष्ट उपयोगकर्ता आईडी सौंपा जाता है। यह ऐप के इंस्टॉलेशन के दौरान किया जाता है ताकि ऐप केवल अपनी उपयोगकर्ता आईडी द्वारा स्वामित्व वाले फ़ाइलों या साझा फ़ाइलों के साथ इंटरैक्ट कर सके। इसलिए, केवल ऐप स्वयं, OS के कुछ घटक और रूट उपयोगकर्ता ऐप के डेटा तक पहुंच सकते हैं।
दो अनुप्रयोगों को समान UID का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है। यह जानकारी साझा करने के लिए उपयोगी हो सकता है, लेकिन यदि इनमें से एक समझौता किया जाता है तो दोनों अनुप्रयोगों का डेटा समझौता कर लिया जाएगा। यही कारण है कि इस व्यवहार को नकारा जाता है।
समान UID साझा करने के लिए, अनुप्रयोगों को अपने मैनिफेस्ट में समान android:sharedUserId मान को परिभाषित करना चाहिए।
Android Application Sandbox प्रत्येक अनुप्रयोग को एक अलग उपयोगकर्ता आईडी के तहत एक अलग प्रक्रिया के रूप में चलाने की अनुमति देता है। प्रत्येक प्रक्रिया की अपनी वर्चुअल मशीन होती है, इसलिए एक ऐप का कोड अन्य ऐप्स से अलग-थलग चलता है। Android 5.0(L) से SELinux लागू किया गया है। मूल रूप से, SELinux ने सभी प्रक्रिया इंटरैक्शन को अस्वीकार कर दिया और फिर उनके बीच केवल अपेक्षित इंटरैक्शन की अनुमति देने के लिए नीतियाँ बनाई।
जब आप एक ऐप इंस्टॉल करते हैं और यह अनुमतियों के लिए पूछता है, तो ऐप AndroidManifest.xml फ़ाइल में uses-permission तत्वों में कॉन्फ़िगर की गई अनुमतियों के लिए पूछ रहा है। uses-permission तत्व अनुरोधित अनुमति के नाम को name attribute के अंदर इंगित करता है। इसमें maxSdkVersion attribute भी है जो निर्दिष्ट संस्करण से उच्च संस्करणों पर अनुमतियों के लिए पूछना बंद कर देता है।
ध्यान दें कि एंड्रॉइड अनुप्रयोगों को शुरुआत में सभी अनुमतियों के लिए पूछने की आवश्यकता नहीं है, वे डायनामिकली अनुमतियों के लिए भी पूछ सकते हैं लेकिन सभी अनुमतियों को मैनिफेस्ट में घोषित करना चाहिए।
जब एक ऐप कार्यक्षमता को उजागर करता है, तो यह केवल उन ऐप्स तक पहुंच को सीमित कर सकता है जिनके पास एक निर्दिष्ट अनुमति है। एक अनुमति तत्व में तीन विशेषताएँ होती हैं:
अनुमति का नाम
permission-group attribute, जो संबंधित अनुमतियों को समूहित करने की अनुमति देता है।
protection-level जो इंगित करता है कि अनुमतियाँ कैसे दी जाती हैं। चार प्रकार हैं:
Normal: जब ऐप के लिए कोई ज्ञात खतरे नहीं होते। उपयोगकर्ता को इसे स्वीकृत करने की आवश्यकता नहीं है।
Dangerous: इंगित करता है कि अनुमति अनुरोध करने वाले अनुप्रयोग को कुछ उच्च पहुंच प्रदान करती है। उपयोगकर्ताओं से उन्हें स्वीकृत करने के लिए कहा जाता है।
Signature: केवल उसी प्रमाणपत्र द्वारा हस्ताक्षरित ऐप्स को अनुमति दी जा सकती है जो घटक को निर्यात कर रहा है। यह सुरक्षा का सबसे मजबूत प्रकार है।
SignatureOrSystem: केवल उसी प्रमाणपत्र द्वारा हस्ताक्षरित ऐप्स या सिस्टम-स्तरीय पहुंच के साथ चलने वाले ऐप्स को अनुमतियाँ दी जा सकती हैं।
ये ऐप्स आमतौर पर /system/app या /system/priv-app निर्देशिकाओं में पाए जाते हैं और इनमें से कुछ अनुकूलित होते हैं (आपको classes.dex फ़ाइल भी नहीं मिल सकती है)। ये अनुप्रयोग जांचने के लायक हैं क्योंकि कभी-कभी वे बहुत सारी अनुमतियों के साथ चल रहे होते हैं (जैसे रूट)।
AOSP (Android OpenSource Project) ROM के साथ शिप किए गए
डिवाइस निर्माता द्वारा जोड़े गए
सेल फोन प्रदाता द्वारा जोड़े गए (यदि उन्हें उनसे खरीदा गया हो)
एक भौतिक एंड्रॉइड डिवाइस में रूट एक्सेस प्राप्त करने के लिए आपको आमतौर पर 1 या 2 कमजोरियों का शोषण करने की आवश्यकता होती है जो आमतौर पर डिवाइस और संस्करण के लिए विशिष्ट होती हैं।
एक बार जब शोषण काम कर जाता है, तो आमतौर पर लिनक्स su बाइनरी को उपयोगकर्ता के PATH env वेरिएबल में निर्दिष्ट स्थान पर कॉपी किया जाता है जैसे /system/xbin।
एक बार जब su बाइनरी कॉन्फ़िगर हो जाती है, तो su बाइनरी के साथ इंटरफेस करने के लिए एक और एंड्रॉइड ऐप का उपयोग किया जाता है और रूट एक्सेस के लिए अनुरोधों को संसाधित किया जाता है जैसे Superuser और SuperSU (जो Google Play स्टोर में उपलब्ध हैं)।
ध्यान दें कि रूटिंग प्रक्रिया बहुत खतरनाक है और डिवाइस को गंभीर रूप से नुकसान पहुँचा सकती है
यह संभव है कि कस्टम फर्मवेयर स्थापित करके OS को बदलें। ऐसा करने से एक पुराने डिवाइस की उपयोगिता बढ़ाना, सॉफ़्टवेयर प्रतिबंधों को बायपास करना या नवीनतम एंड्रॉइड कोड तक पहुंच प्राप्त करना संभव है। OmniROM और LineageOS उपयोग करने के लिए दो सबसे लोकप्रिय फर्मवेयर हैं।
ध्यान दें कि कस्टम फर्मवेयर स्थापित करने के लिए डिवाइस को रूट करना हमेशा आवश्यक नहीं है। कुछ निर्माता अपने बूटलोडर्स को अच्छी तरह से प्रलेखित और सुरक्षित तरीके से अनलॉक करने की अनुमति देते हैं।
एक बार जब एक डिवाइस रूट हो जाता है, तो कोई भी ऐप रूट के रूप में एक्सेस का अनुरोध कर सकता है। यदि एक दुर्भावनापूर्ण एप्लिकेशन इसे प्राप्त करता है, तो यह लगभग सब कुछ तक पहुंच प्राप्त कर लेगा और यह फोन को नुकसान पहुंचा सकेगा।
एंड्रॉइड अनुप्रयोगों का प्रारूप APK फ़ाइल प्रारूप के रूप में संदर्भित किया जाता है। यह मूल रूप से एक ZIP फ़ाइल है (फ़ाइल एक्सटेंशन को .zip में बदलने पर, सामग्री को निकाला और देखा जा सकता है)।
APK सामग्री (पूर्ण नहीं)
AndroidManifest.xml
resources.arsc/strings.xml
resources.arsc: पूर्व-संकलित संसाधनों को शामिल करता है, जैसे बाइनरी XML।
res/xml/files_paths.xml
META-INF/
यहीं पर प्रमाणपत्र स्थित है!
classes.dex
डेलविक बाइटकोड शामिल करता है, जो संकलित जावा (या कोटलिन) कोड का प्रतिनिधित्व करता है जिसे अनुप्रयोग डिफ़ॉल्ट रूप से निष्पादित करता है।
lib/
मूलभूत पुस्तकालयों को रखता है, जो उपनिर्देशिकाओं में CPU आर्किटेक्चर द्वारा विभाजित होते हैं।
armeabi: ARM आधारित प्रोसेसर के लिए कोड
armeabi-v7a: ARMv7 और उच्चतर आधारित प्रोसेसर के लिए कोड
x86: X86 प्रोसेसर के लिए कोड
mips: केवल MIPS प्रोसेसर के लिए कोड
assets/
ऐप द्वारा आवश्यक विविध फ़ाइलों को संग्रहीत करता है, जिसमें अतिरिक्त मूलभूत पुस्तकालय या DEX फ़ाइलें शामिल हो सकती हैं, जिन्हें कभी-कभी मैलवेयर लेखक अतिरिक्त कोड को छिपाने के लिए उपयोग करते हैं।
res/
संसाधनों को शामिल करता है जो resources.arsc में संकलित नहीं होते हैं।
एंड्रॉइड विकास में, Java या Kotlin का उपयोग ऐप बनाने के लिए किया जाता है। डेस्कटॉप ऐप्स की तरह JVM का उपयोग करने के बजाय, एंड्रॉइड इस कोड को Dalvik Executable (DEX) बाइटकोड में संकलित करता है। पहले, डेलविक वर्चुअल मशीन इस बाइटकोड को संभालती थी, लेकिन अब, नए एंड्रॉइड संस्करणों में, एंड्रॉइड रनटाइम (ART) इसका प्रभार लेता है।
रिवर्स इंजीनियरिंग के लिए, Smali महत्वपूर्ण हो जाता है। यह DEX बाइटकोड का मानव-पठनीय संस्करण है, जो स्रोत कोड को बाइटकोड निर्देशों में अनुवादित करके असेंबली भाषा की तरह कार्य करता है। इस संदर्भ में Smali और baksmali असेंबली और डिसअसेंबली उपकरणों को संदर्भित करते हैं।
Intents एंड्रॉइड ऐप्स के बीच उनके घटकों या अन्य ऐप्स के साथ संवाद करने के प्राथमिक साधन हैं। ये संदेश वस्तुएं ऐप्स या घटकों के बीच डेटा ले जा सकती हैं, जैसे HTTP संचार में GET/POST अनुरोधों का उपयोग किया जाता है।
तो एक Intent मूल रूप से घटकों के बीच पारित किया गया एक संदेश है। Intents विशिष्ट घटकों या ऐप्स की ओर निर्देशित किए जा सकते हैं, या बिना किसी विशिष्ट प्राप्तकर्ता के भेजे जा सकते हैं। सरलता के लिए Intent का उपयोग किया जा सकता है:
एक गतिविधि शुरू करने के लिए, आमतौर पर एक ऐप के लिए उपयोगकर्ता इंटरफ़ेस खोलना
सिस्टम और ऐप्स को परिवर्तनों की जानकारी देने के लिए प्रसारण के रूप में
एक पृष्ठभूमि सेवा को शुरू करने, रोकने और संवाद करने के लिए
ContentProviders के माध्यम से डेटा तक पहुँचने के लिए
घटनाओं को संभालने के लिए कॉलबैक के रूप में
यदि कमजोर हैं, तो Intents का उपयोग विभिन्न प्रकार के हमलों को करने के लिए किया जा सकता है।
Intent Filters परिभाषित करते हैं कैसे एक गतिविधि, सेवा, या ब्रॉडकास्ट रिसीवर विभिन्न प्रकार के Intents के साथ इंटरैक्ट कर सकता है। मूल रूप से, वे इन घटकों की क्षमताओं का वर्णन करते हैं, जैसे कि वे कौन से कार्य कर सकते हैं या वे किस प्रकार के प्रसारण को संसाधित कर सकते हैं। इन फ़िल्टरों की घोषणा करने के लिए प्राथमिक स्थान AndroidManifest.xml फ़ाइल के भीतर है, हालांकि ब्रॉडकास्ट रिसीवर्स के लिए, उन्हें कोडिंग करना भी एक विकल्प है।
Intent Filters श्रेणियों, क्रियाओं और डेटा फ़िल्टरों से बने होते हैं, जिसमें अतिरिक्त मेटाडेटा शामिल करने की संभावना होती है। यह सेटअप घटकों को उन विशिष्ट Intents को संभालने की अनुमति देता है जो घोषित मानदंडों से मेल खाते हैं।
एंड्रॉइड घटकों (गतिविधियाँ/सेवाएँ/सामग्री प्रदाता/ब्रॉडकास्ट रिसीवर्स) का एक महत्वपूर्ण पहलू उनकी दृश्यता या सार्वजनिक स्थिति है। एक घटक को सार्वजनिक माना जाता है और यह अन्य ऐप्स के साथ इंटरैक्ट कर सकता है यदि इसे exported के मान के साथ true के रूप में सेट किया गया है या यदि इसके लिए मैनिफेस्ट में एक Intent Filter घोषित किया गया है। हालाँकि, डेवलपर्स के लिए इन घटकों को स्पष्ट रूप से निजी रखना संभव है, यह सुनिश्चित करते हुए कि वे अनजाने में अन्य ऐप्स के साथ इंटरैक्ट न करें। यह उनके मैनिफेस्ट परिभाषाओं में exported attribute को false पर सेट करके प्राप्त किया जाता है।
इसके अलावा, डेवलपर्स के पास इन घटकों तक पहुंच को और सुरक्षित करने का विकल्प होता है, विशेष अनुमतियों की आवश्यकता करके। permission attribute को सेट किया जा सकता है ताकि केवल उन ऐप्स को अनुमति दी जा सके जिनके पास निर्दिष्ट अनुमति है, जो सुरक्षा और नियंत्रण की एक अतिरिक्त परत जोड़ता है कि कौन इसके साथ इंटरैक्ट कर सकता है।
Intents को एक Intent कंस्ट्रक्टर का उपयोग करके प्रोग्रामेटिक रूप से बनाया जाता है:
The Action of the previously declared intent is ACTION_SEND and the Extra is a mailto Uri (the Extra if the extra information the intent is expecting).
यह इरादा मैनिफेस्ट के अंदर निम्नलिखित उदाहरण के रूप में घोषित किया जाना चाहिए:
An intent-filter को संदेश प्राप्त करने के लिए action, data और category से मेल खाना चाहिए।
"Intent resolution" प्रक्रिया यह निर्धारित करती है कि प्रत्येक संदेश को कौन सा ऐप प्राप्त करना चाहिए। यह प्रक्रिया priority attribute पर विचार करती है, जिसे intent-filter declaration में सेट किया जा सकता है, और उच्च प्राथमिकता वाला चयनित होगा। यह प्राथमिकता -1000 और 1000 के बीच सेट की जा सकती है और एप्लिकेशन SYSTEM_HIGH_PRIORITY मान का उपयोग कर सकते हैं। यदि conflict उत्पन्न होता है, तो एक "choser" Window प्रकट होती है ताकि उपयोगकर्ता निर्णय ले सके।
एक explicit intent उस वर्ग नाम को निर्दिष्ट करता है जिसे यह लक्षित कर रहा है:
अन्य अनुप्रयोगों में पूर्व में घोषित इरादे तक पहुँचने के लिए आप उपयोग कर सकते हैं:
ये अन्य अनुप्रयोगों को आपके अनुप्रयोग की ओर से क्रियाएँ करने की अनुमति देते हैं, आपके ऐप की पहचान और अनुमतियों का उपयोग करते हुए। एक Pending Intent बनाने के लिए एक इरादा और क्रिया को निर्दिष्ट किया जाना चाहिए। यदि घोषित इरादा स्पष्ट नहीं है (यह नहीं बताता कि कौन सा इरादा इसे कॉल कर सकता है) तो एक दुष्ट अनुप्रयोग घोषित क्रिया को पीड़ित ऐप की ओर से कर सकता है। इसके अलावा, यदि कोई क्रिया निर्दिष्ट नहीं की गई है, तो दुष्ट ऐप पीड़ित की ओर से कोई भी क्रिया कर सकेगा।
पिछले इरादों के विपरीत, जो केवल एक ऐप द्वारा प्राप्त होते हैं, ब्रॉडकास्ट इरादे कई ऐप द्वारा प्राप्त किए जा सकते हैं। हालाँकि, API संस्करण 14 से, यह निर्धारित करना संभव है कि कौन सा ऐप संदेश प्राप्त करना चाहिए Intent.set Package का उपयोग करके।
वैकल्पिक रूप से, ब्रॉडकास्ट भेजते समय एक अनुमति निर्दिष्ट करना भी संभव है। रिसीवर ऐप को उस अनुमति की आवश्यकता होगी।
ब्रॉडकास्ट के दो प्रकार होते हैं: सामान्य (असिंक्रोनस) और क्रमबद्ध (सिंक्रोनस)। क्रम रिसीवर तत्व के कॉन्फ़िगर की गई प्राथमिकता पर आधारित है। प्रत्येक ऐप ब्रॉडकास्ट को संसाधित, पुनः प्रसारित या छोड़ सकता है।
आप Context क्लास से sendBroadcast(intent, receiverPermission) फ़ंक्शन का उपयोग करके ब्रॉडकास्ट भेजना संभव है।
आप LocalBroadCastManager से sendBroadcast फ़ंक्शन का भी उपयोग कर सकते हैं जो सुनिश्चित करता है कि संदेश ऐप से कभी बाहर नहीं जाता। इसका उपयोग करते समय आपको रिसीवर घटक को निर्यात करने की भी आवश्यकता नहीं होगी।
इस प्रकार के ब्रॉडकास्ट उनके भेजे जाने के लंबे समय बाद भी पहुंचा जा सकता है। इनका API स्तर 21 में निराधारित किया गया था और इनका उपयोग न करने की सिफारिश की गई है। ये किसी भी अनुप्रयोग को डेटा को स्निफ़ करने, बल्कि इसे संशोधित करने की अनुमति देते हैं।
यदि आप "sticky" शब्द वाले फ़ंक्शंस जैसे sendStickyBroadcast या sendStickyBroadcastAsUser पाते हैं, तो प्रभाव की जांच करें और उन्हें हटाने का प्रयास करें।
Android अनुप्रयोगों में, डीप लिंक का उपयोग एक क्रिया (Intent) को सीधे एक URL के माध्यम से प्रारंभ करने के लिए किया जाता है। यह एक गतिविधि के भीतर एक विशिष्ट URL स्कीम घोषित करके किया जाता है। जब एक Android डिवाइस इस स्कीम के साथ एक URL तक पहुँचने की कोशिश करता है, तो अनुप्रयोग के भीतर निर्दिष्ट गतिविधि लॉन्च होती है।
स्कीम को AndroidManifest.xml फ़ाइल में घोषित किया जाना चाहिए:
पिछले उदाहरण से योजना examplescheme:// है (ध्यान दें कि category BROWSABLE भी है)
फिर, डेटा फ़ील्ड में, आप host और path निर्दिष्ट कर सकते हैं:
वेब से इसे एक्सेस करने के लिए एक लिंक सेट करना संभव है जैसे:
In order to find the code that will be executed in the App, go to the activity called by the deeplink and search the function onNewIntent.
Learn how to call deep links without using HTML pages.
The Android Interface Definition Language (AIDL) is designed for facilitating communication between client and service in Android applications through interprocess communication (IPC). Since accessing another process's memory directly is not permitted on Android, AIDL simplifies the process by marshalling objects into a format understood by the operating system, thereby easing communication across different processes.
Bound Services: ये सेवाएँ IPC के लिए AIDL का उपयोग करती हैं, जिससे गतिविधियाँ या घटक एक सेवा से बंध सकते हैं, अनुरोध कर सकते हैं, और प्रतिक्रियाएँ प्राप्त कर सकते हैं। सेवा की कक्षा में onBind विधि बातचीत शुरू करने के लिए महत्वपूर्ण है, इसे कमजोरियों की खोज में सुरक्षा समीक्षा के लिए एक महत्वपूर्ण क्षेत्र के रूप में चिह्नित किया गया है।
Messenger: एक बंधी सेवा के रूप में कार्य करते हुए, Messenger IPC को सुविधाजनक बनाता है, जो onBind विधि के माध्यम से डेटा को संसाधित करने पर ध्यान केंद्रित करता है। किसी भी असुरक्षित डेटा हैंडलिंग या संवेदनशील कार्यों के निष्पादन के लिए इस विधि का ध्यानपूर्वक निरीक्षण करना आवश्यक है।
Binder: हालांकि AIDL के अमूर्तता के कारण Binder वर्ग का प्रत्यक्ष उपयोग कम सामान्य है, यह समझना फायदेमंद है कि Binder विभिन्न प्रक्रियाओं की मेमोरी स्थानों के बीच डेटा स्थानांतरण को सुविधाजनक बनाने वाला एक कर्नेल-स्तरीय ड्राइवर के रूप में कार्य करता है। आगे की समझ के लिए, एक संसाधन https://www.youtube.com/watch?v=O-UHvFjxwZ8 पर उपलब्ध है।
These include: Activities, Services, Broadcast Receivers and Providers.
In Android apps, activities are like screens, showing different parts of the app's user interface. An app can have many activities, each one presenting a unique screen to the user.
The launcher activity is the main gateway to an app, launched when you tap the app's icon. It's defined in the app's manifest file with specific MAIN and LAUNCHER intents:
नहीं सभी ऐप्स को एक लॉन्चर गतिविधि की आवश्यकता होती है, विशेष रूप से वे जो उपयोगकर्ता इंटरफ़ेस के बिना होते हैं, जैसे बैकग्राउंड सेवाएँ।
गतिविधियों को अन्य ऐप्स या प्रक्रियाओं के लिए उपलब्ध कराया जा सकता है, उन्हें मैनिफेस्ट में "निर्यातित" के रूप में चिह्नित करके। यह सेटिंग अन्य ऐप्स को इस गतिविधि को शुरू करने की अनुमति देती है:
हालांकि, किसी अन्य ऐप से एक गतिविधि तक पहुंचना हमेशा एक सुरक्षा जोखिम नहीं होता है। चिंता तब होती है जब संवेदनशील डेटा गलत तरीके से साझा किया जा रहा हो, जो जानकारी के लीक का कारण बन सकता है।
एक गतिविधि का जीवनचक्र onCreate विधि के साथ शुरू होता है, UI सेटअप करना और उपयोगकर्ता के साथ बातचीत के लिए गतिविधि को तैयार करना।
Android विकास में, एक ऐप के पास Application क्लास का एक उपक्लास बनाने का विकल्प होता है, हालांकि यह अनिवार्य नहीं है। जब ऐसा उपक्लास परिभाषित किया जाता है, तो यह ऐप के भीतर पहली क्लास बन जाती है जिसे इंस्टेंट किया जाता है। यदि इस उपक्लास में attachBaseContext विधि लागू की गई है, तो इसे onCreate विधि से पहले निष्पादित किया जाता है। यह सेटअप शेष एप्लिकेशन शुरू होने से पहले प्रारंभिक प्रारंभ की अनुमति देता है।
Services पृष्ठभूमि ऑपरेटिव्स हैं जो बिना उपयोगकर्ता इंटरफ़ेस के कार्यों को निष्पादित करने में सक्षम हैं। ये कार्य तब भी चलते रह सकते हैं जब उपयोगकर्ता विभिन्न अनुप्रयोगों में स्विच करते हैं, जिससे सेवाएँ दीर्घकालिक संचालन के लिए महत्वपूर्ण हो जाती हैं।
सेवाएँ बहुपरकारी हैं; इन्हें विभिन्न तरीकों से आरंभ किया जा सकता है, जिसमें Intents मुख्य विधि है जो उन्हें एक अनुप्रयोग के प्रवेश बिंदु के रूप में लॉन्च करने के लिए उपयोग की जाती है। एक बार जब startService विधि का उपयोग करके सेवा शुरू की जाती है, तो इसका onStart विधि सक्रिय हो जाती है और तब तक चलती रहती है जब तक कि stopService विधि को स्पष्ट रूप से नहीं बुलाया जाता। वैकल्पिक रूप से, यदि किसी सेवा की भूमिका एक सक्रिय क्लाइंट कनेक्शन पर निर्भर करती है, तो bindService विधि का उपयोग क्लाइंट को सेवा से जोड़ने के लिए किया जाता है, डेटा पास करने के लिए onBind विधि को सक्रिय करते हुए।
सेवाओं का एक दिलचस्प अनुप्रयोग पृष्ठभूमि संगीत प्लेबैक या नेटवर्क डेटा फ़ेचिंग शामिल है, बिना उपयोगकर्ता के किसी ऐप के साथ इंटरैक्शन को बाधित किए। इसके अलावा, सेवाओं को निर्यात के माध्यम से एक ही डिवाइस पर अन्य प्रक्रियाओं के लिए सुलभ बनाया जा सकता है। यह डिफ़ॉल्ट व्यवहार नहीं है और इसके लिए Android Manifest फ़ाइल में स्पष्ट कॉन्फ़िगरेशन की आवश्यकता होती है:
Broadcast receivers एक मैसेजिंग सिस्टम में श्रोता के रूप में कार्य करते हैं, जिससे कई एप्लिकेशन सिस्टम से समान संदेशों का जवाब दे सकते हैं। एक ऐप दो प्रमुख तरीकों से एक रिसीवर को रजिस्टर कर सकता है: ऐप के Manifest के माध्यम से या ऐप के कोड में registerReceiver API के माध्यम से डायनामिकली। Manifest में, ब्रॉडकास्ट को अनुमतियों के साथ फ़िल्टर किया जाता है, जबकि डायनामिकली रजिस्टर किए गए रिसीवर रजिस्ट्रेशन के समय अनुमतियों को भी निर्दिष्ट कर सकते हैं।
Intent filters दोनों रजिस्ट्रेशन विधियों में महत्वपूर्ण हैं, यह निर्धारित करते हैं कि कौन से ब्रॉडकास्ट रिसीवर को ट्रिगर करते हैं। एक बार जब एक मेल खाने वाला ब्रॉडकास्ट भेजा जाता है, तो रिसीवर का onReceive मेथड सक्रिय होता है, जिससे ऐप को प्रतिक्रिया देने की अनुमति मिलती है, जैसे कि कम बैटरी अलर्ट के जवाब में व्यवहार को समायोजित करना।
ब्रॉडकास्ट असिंक्रोनस हो सकते हैं, जो सभी रिसीवर्स तक बिना क्रम के पहुँचते हैं, या सिंक्रोनस, जहाँ रिसीवर्स सेट प्राथमिकताओं के आधार पर ब्रॉडकास्ट प्राप्त करते हैं। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि संभावित सुरक्षा जोखिम है, क्योंकि कोई भी ऐप खुद को प्राथमिकता देकर एक ब्रॉडकास्ट को इंटरसेप्ट कर सकता है।
एक रिसीवर की कार्यक्षमता को समझने के लिए, उसकी क्लास में onReceive मेथड की तलाश करें। इस मेथड का कोड प्राप्त Intent को संशोधित कर सकता है, जिससे रिसीवर्स द्वारा डेटा सत्यापन की आवश्यकता को उजागर किया जाता है, विशेष रूप से Ordered Broadcasts में, जो Intent को संशोधित या छोड़ सकते हैं।
Content Providers ऐप्स के बीच संरचित डेटा साझा करने के लिए आवश्यक हैं, डेटा सुरक्षा सुनिश्चित करने के लिए अनुमतियों को लागू करने के महत्व पर जोर देते हैं। वे ऐप्स को विभिन्न स्रोतों से डेटा तक पहुँचने की अनुमति देते हैं, जिसमें डेटाबेस, फ़ाइल सिस्टम, या वेब शामिल हैं। विशिष्ट अनुमतियाँ, जैसे readPermission और writePermission, पहुँच को नियंत्रित करने के लिए महत्वपूर्ण हैं। इसके अतिरिक्त, ऐप के मैनिफेस्ट में grantUriPermission सेटिंग्स के माध्यम से अस्थायी पहुँच प्रदान की जा सकती है, जिसमें विस्तृत पहुँच नियंत्रण के लिए path, pathPrefix, और pathPattern जैसे गुणों का उपयोग किया जाता है।
इनपुट सत्यापन कमजोरियों को रोकने के लिए अत्यंत महत्वपूर्ण है, जैसे SQL इंजेक्शन। Content Providers बुनियादी संचालन का समर्थन करते हैं: insert(), update(), delete(), और query(), जो एप्लिकेशनों के बीच डेटा हेरफेर और साझा करने की सुविधा प्रदान करते हैं।
FileProvider, एक विशेष Content Provider, फ़ाइलों को सुरक्षित रूप से साझा करने पर केंद्रित है। इसे ऐप के मैनिफेस्ट में विशिष्ट गुणों के साथ परिभाषित किया गया है जो फ़ोल्डरों तक पहुँच को नियंत्रित करते हैं, जिसे android:exported और android:resource द्वारा फ़ोल्डर कॉन्फ़िगरेशन की ओर इंगित किया जाता है। संवेदनशील डेटा को अनजाने में उजागर करने से बचने के लिए निर्देशिकाएँ साझा करते समय सावधानी बरतने की सलाह दी जाती है।
FileProvider के लिए उदाहरण मैनिफेस्ट घोषणा:
और filepaths.xml में साझा फ़ोल्डरों को निर्दिष्ट करने का एक उदाहरण:
For further information check:
WebViews एंड्रॉइड ऐप्स के अंदर मिनी वेब ब्राउज़र की तरह होते हैं, जो सामग्री को या तो वेब से या स्थानीय फ़ाइलों से खींचते हैं। इन्हें सामान्य ब्राउज़रों के समान जोखिमों का सामना करना पड़ता है, फिर भी कुछ विशेष सेटिंग्स के माध्यम से इन जोखिमों को कम करने के तरीके हैं।
एंड्रॉइड दो मुख्य WebView प्रकार प्रदान करता है:
WebViewClient बुनियादी HTML के लिए अच्छा है लेकिन JavaScript अलर्ट फ़ंक्शन का समर्थन नहीं करता, जो XSS हमलों का परीक्षण करने के तरीके को प्रभावित करता है।
WebChromeClient पूर्ण Chrome ब्राउज़र अनुभव की तरह कार्य करता है।
एक महत्वपूर्ण बिंदु यह है कि WebView ब्राउज़र कुकीज़ को डिवाइस के मुख्य ब्राउज़र के साथ साझा नहीं करते।
सामग्री लोड करने के लिए, loadUrl, loadData, और loadDataWithBaseURL जैसे तरीके उपलब्ध हैं। यह सुनिश्चित करना महत्वपूर्ण है कि ये URLs या फ़ाइलें उपयोग के लिए सुरक्षित हैं। सुरक्षा सेटिंग्स को WebSettings क्लास के माध्यम से प्रबंधित किया जा सकता है। उदाहरण के लिए, setJavaScriptEnabled(false) के साथ JavaScript को अक्षम करना XSS हमलों को रोक सकता है।
JavaScript "Bridge" Java ऑब्जेक्ट्स को JavaScript के साथ इंटरैक्ट करने की अनुमति देता है, जिसके लिए Android 4.2 से सुरक्षा के लिए विधियों को @JavascriptInterface के साथ चिह्नित करना आवश्यक है।
सामग्री पहुंच की अनुमति देना (setAllowContentAccess(true)) WebViews को Content Providers तक पहुंचने की अनुमति देता है, जो एक जोखिम हो सकता है जब तक कि सामग्री URLs को सुरक्षित के रूप में सत्यापित नहीं किया जाता।
फ़ाइल पहुंच को नियंत्रित करने के लिए:
फ़ाइल पहुंच को अक्षम करना (setAllowFileAccess(false)) फ़ाइल सिस्टम तक पहुंच को सीमित करता है, कुछ संपत्तियों के लिए अपवाद के साथ, यह सुनिश्चित करता है कि उन्हें केवल गैर-संवेदनशील सामग्री के लिए उपयोग किया जाए।
डिजिटल साइनिंग एंड्रॉइड ऐप्स के लिए अनिवार्य है, यह सुनिश्चित करते हुए कि वे प्रामाणिक रूप से लिखित हैं। यह प्रक्रिया ऐप पहचान के लिए एक प्रमाणपत्र का उपयोग करती है और इसे इंस्टॉलेशन के समय डिवाइस के पैकेज प्रबंधक द्वारा सत्यापित किया जाना चाहिए। ऐप्स स्वयं-हस्ताक्षरित या बाहरी CA द्वारा प्रमाणित हो सकते हैं, जो अनधिकृत पहुंच से सुरक्षा प्रदान करते हैं और सुनिश्चित करते हैं कि ऐप डिवाइस पर डिलीवरी के दौरान बिना छेड़छाड़ के रहे।
Android 4.2 से शुरू होकर, Verify Apps नामक एक सुविधा उपयोगकर्ताओं को ऐप्स की सुरक्षा की जांच करने की अनुमति देती है। यह सत्यापन प्रक्रिया उपयोगकर्ताओं को संभावित रूप से हानिकारक ऐप्स के खिलाफ चेतावनी दे सकती है, या यहां तक कि विशेष रूप से दुर्भावनापूर्ण ऐप्स के इंस्टॉलेशन को रोक सकती है, जिससे उपयोगकर्ता की सुरक्षा बढ़ती है।
MDM समाधान मोबाइल उपकरणों के लिए निगरानी और सुरक्षा प्रदान करते हैं डिवाइस प्रशासन API के माध्यम से। उन्हें मोबाइल उपकरणों को प्रभावी ढंग से प्रबंधित और सुरक्षित करने के लिए एक एंड्रॉइड ऐप के इंस्टॉलेशन की आवश्यकता होती है। मुख्य कार्यों में पासवर्ड नीतियों को लागू करना, स्टोरेज एन्क्रिप्शन को अनिवार्य करना, और दूरस्थ डेटा मिटाने की अनुमति देना शामिल है, जो मोबाइल उपकरणों पर व्यापक नियंत्रण और सुरक्षा सुनिश्चित करता है।
सीखें और AWS हैकिंग का अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) सीखें और GCP हैकिंग का अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
