<summary><strong>जीरो से हीरो तक AWS हैकिंग सीखें</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
* अगर आप अपनी कंपनी की **विज्ञापनित करना चाहते हैं HackTricks** या **HackTricks को PDF में डाउनलोड करना चाहते हैं** तो [**सब्सक्रिप्शन प्लान**](https://github.com/sponsors/carlospolop) देखें!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह।
* **शामिल हों** 💬 [**डिस्कॉर्ड समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) या हमें **ट्विटर** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)** पर फॉलो** करें।
सबसे महत्वपूर्ण वंशानुभवों को खोजें ताकि आप उन्हें तेजी से ठीक कर सकें। Intruder आपकी हमले की सतह का ट्रैक करता है, प्रोएक्टिव धारणा स्कैन चलाता है, आपकी पूरी तकनीक स्टैक, API से वेब ऐप्स और क्लाउड सिस्टम तक मुद्दे खोजता है। [**आज ही मुफ्त में इसका प्रयास करें**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks)।
**प्रत्येक एप्लिकेशन को एक विशिष्ट उपयोगकर्ता आईडी सौंपी जाती है**। यह एप्लिकेशन के स्थापना के दौरान किया जाता है ताकि **एप्लिकेशन केवल अपने उपयोगकर्ता आईडी या साझा** फ़ाइलों के स्वामित्व वाले फ़ाइलों के साथ ही संवाद कर सके। इसलिए, केवल एप्लिकेशन इसे, ओएस के कुछ घटक और रूट उपयोगकर्ता एप्लिकेशन के डेटा तक पहुंच सकते हैं।
**दो एप्लिकेशनों को एक ही UID का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है**। यह सूचना साझा करने के लिए उपयोगी हो सकता है, लेकिन अगर इनमें से कोई भी संक्रमित हो जाता है तो दोनों एप्लिकेशनों के डेटा संक्रमित हो जाएगा। इसलिए यह व्यवहार **असलाह** किया जाता है।\
**एंड्रॉइड एप्लिकेशन सैंडबॉक्स** हर एप्लिकेशन को एक अलग प्रक्रिया के रूप में एक अलग उपयोगकर्ता आईडी के रूप में चलाने की अनुमति देता है। प्रत्येक प्रक्रिया का अपना वर्चुअल मशीन होता है, इसलिए एक ऐप का कोड अन्य ऐप्स से अलग चलता है।\
एंड्रॉइड 5.0(L) से **SELinux** लागू है। मूल रूप से, SELinux ने सभी प्रक्रिया अंतराक्रियाएँ निषेधित की और फिर उनके बीच केवल उम्मीद की जाने वाली अंतराक्रियाओं को **अनुमति देने के नीतियाँ बनाईं।**
जब आप एक **एप्लिकेशन स्थापित करते हैं और यह अनुमतियाँ मांगता है**, तो एप्लिकेशन **AndroidManifest.xml** फ़ाइल में **`uses-permission`** तत्वों में कॉन्फ़िगर की गई अनुमतियों के लिए मांग कर रहा है। **uses-permission** तत्व अनुमति का नाम निर्दिष्ट करता है जो **नाम****विशेषता में अनुमति के लिए मांग करता है।** इसमें **maxSdkVersion** विशेषता भी होती है जो उच्च संस्करणों पर अनुमतियों के लिए मांग करना बंद कर देती है।\
ध्यान दें कि एंड्रॉइड एप्लिकेशनों को शुरू में सभी अनुमतियों के लिए मांगने की आवश्यकता नहीं है, वे डायनामिक रूप से भी **अनुमतियों के लिए मांग सकते हैं** लेकिन सभी अनुमतियों को **मैनिफ़ेस्ट में घोषित** किया जाना चाहिए।
* **सामान्य**: जब किसी **एप्लिकेशन के लिए कोई ज्ञात खतरा नहीं** होता है। उपयोगकर्ता को **इसे स्वीकृत करने की आवश्यकता नहीं होती है**।
* **खतरनाक**: यह अनुमति अनुरोध करने वाले एप्लिकेशन को कुछ **उच्च पहुंच** प्रदान करती है। **उपयोगकर्ताओं से इन्हें स्वीकृत करने की आवश्यकता होती है**।
* **हस्ताक्षर**: केवल **उन एप्लिकेशनों को हस्ताक्षर के रूप में साइन करने वाले सर्टिफिकेट के साथ** जो घटक निर्यात कर रहा है, अनुमति दी जा सकती है। यह सबसे मजबूत सुरक्षा प्रकार है।
* **हस्ताक्षर या सिस्टम**: केवल **उन एप्लिकेशनों को हस्ताक्षर के रूप में साइन करने वाले सर्टिफिकेट के साथ** जो घटक निर्यात कर रहा है, या **सिस्टम स्तर की पहुंच के साथ चल रहे एप्लिकेशन** को अनुमति दी जा सकती हैं।
ये एप्लिकेशन आम तौर पर **`/system/app`** या **`/system/priv-app`** निर्देशिकाओं में पाए जाते हैं और इनमें से कुछ **अनुकूलित** होते हैं (आप `classes.dex` फ़ाइल भी नहीं मिल सकती है)। इन एप्लिकेशनों की जांच करने लायक है क्योंकि कभी-कभी ये **बहुत सारी अनुमतियों के साथ चल रहे होते हैं** (जै
"Intent resolution" प्रक्रिया तय करती है कि प्रत्येक संदेश किस ऐप को प्राप्त करना चाहिए। यह प्रक्रिया **प्राथमिकता विशेषता** को ध्यान में रखती है, जो **intent-filter घोषणा** में सेट किया जा सकता है, और **जिसकी प्राथमिकता अधिक होगी, वह चयनित किया जाएगा**। यह प्राथमिकता -1000 से 1000 के बीच सेट की जा सकती है और एप्लिकेशन `SYSTEM_HIGH_PRIORITY` मान का उपयोग कर सकते हैं। यदि **संघर्ष** उत्पन्न होता है, तो "चयनकर्ता" विंडो दिखाई देती है ताकि **उपयोगकर्ता निर्णय** कर सके।
ये अन्य एप्लिकेशनों को **आपकी एप्लिकेशन की पहचान और अनुमतियों का उपयोग करके कार्रवाई करने की अनुमति देते हैं**। Pending Intent बनाते समय **एक इंटेंट और करने के लिए कार्रवाई को निर्दिष्ट करना चाहिए**। यदि **घोषित इंटेंट स्पष्ट नहीं है** (जो घोषित करता है कि कौन सा इंटेंट इसे कॉल कर सकता है), तो **किसी दुरुपयोगी एप्लिकेशन को शिकार एप्लिकेशन के नाम पर घोषित कार्रवाई करने की अनुमति हो सकती है**। इसके अतिरिक्त, **यदि कोई कार्रवाई निर्दिष्ट नहीं है**, तो दुरुपयोगी एप्लिकेशन को **शिकार के नाम पर कोई भी कार्रवाई करने की अनुमति होगी**।
पिछले इंटेंट्स की विपरीतता, जो केवल एक एप्लिकेशन द्वारा प्राप्त की जाती हैं, ब्रॉडकास्ट इंटेंट्स **कई एप्लिकेशनों द्वारा प्राप्त की जा सकती हैं**। हालांकि, API संस्करण 14 से, यह **संदेश प्राप्त करने वाला ऐप स्पष्ट करना संभव है** उपयोग करके Intent.set Package करके।
ब्रॉडकास्ट के **दो प्रकार** होते हैं: **सामान्य** (असमंबद्ध) और **क्रमबद्ध** (समंबद्ध)। **क्रम** प्राप्तकर्ता तत्व के भीतर **कॉन्फ़िगर की गई प्राथमिकता पर आधारित है**। **प्रत्येक एप्लिकेशन ब्रॉडकास्ट को प्रसंस्करण, पुनर्प्रेषण या छोड़ सकता है**।
एक **ब्रॉडकास्ट भेजना** संबंधित फ़ंक्शन `sendBroadcast(intent, receiverPermission)` का उपयोग करके `Context` वर्ग से किया जा सकता है।\
आप **`LocalBroadCastManager`** से **`sendBroadcast`** फ़ंक्शन का उपयोग कर सकते हैं जिससे **संदेश कभी भी ऐप छोड़ नहीं जाता**। इसका उपयोग करके आपको एक प्राप्तकर्ता घटक को निर्यात करने की आवश्यकता नहीं होगी।
यदि आप "sticky" शब्द वाले फ़ंक्शन जैसे **`sendStickyBroadcast`** या **`sendStickyBroadcastAsUser`** पाते हैं, **उनका प्रभाव जांचें और उन्हें हटाने की कोशिश करें**।
Android एप्लिकेशन में, **गहरे लिंक** का उपयोग एक कार्रवाई (इंटेंट) को सीधे एक URL के माध्यम से प्रारंभ करने के लिए किया जाता है। इसे एक विशिष्ट **URL योजना** को एक गतिविधि के भीतर घोषित करके किया जाता है। जब एक Android उपकरण इस योजना के साथ एक URL तक पहुंचने की कोशिश करता है, तो एप्लिकेशन के भीतर निर्दिष्ट गतिविधि लॉन्च की जाती है।
**एंड्रॉयड इंटरफेस परिभाषा भाषा (AIDL)** का उद्देश्य एंड्रॉयड एप्लिकेशन में क्लाइंट और सर्विस के बीच **अंतरप्रक्रिया संचार** (IPC) को सुविधाजनक बनाना है। एंड्रॉयड पर दूसरे प्रक्रिया की मेमोरी तक सीधा पहुंचना अनुमति नहीं है, इसलिए AIDL ऑपरेटिंग सिस्टम द्वारा समझे जाने वाले एक प्रारूप में ऑब्जेक्ट्स को मार्शल करके प्रक्रियाओं के बीच संचार को सुविधाजनक बनाता है।
- **बाउंड सेवाएं**: ये सेवाएं IPC के लिए AIDL का उपयोग करती हैं, जिससे गतिविधियों या घटकों को सेवा से जोड़ने, अनुरोध करने और प्रतिक्रिया प्राप्त करने की सुविधा होती है। सेवा की कक्षा में `onBind` विधि संवेदनशीलता के लिए महत्वपूर्ण है, जिसे सुरक्षा समीक्षा के लिए महत्वपूर्ण क्षेत्र माना जाता है।
- **मेसेंजर**: एक बाउंड सेवा के रूप में काम करते हुए, मेसेंजर IPC को सुविधाजनक बनाता है जिसका मुख्य ध्यान डेटा को `onBind` विधि के माध्यम से प्रसंस्करण करने पर होता है। किसी भी असुरक्षित डेटा हैंडलिंग या संवेदनशील कार्यों के निष्पादन के लिए इस विधि की ध्यानपूर्वक जांच करना महत्वपूर्ण है।
- **बाइंडर**: AIDL की अवस्थान के कारण सीधे बाइंडर कक्षा का प्रत्यक्ष उपयोग कम होता है, लेकिन बाइंडर का उपयोग अलग-अलग प्रक्रियाओं की मेमोरी स्थानों के बीच डेटा स्थानांतरण सुविधा प्रदान करने वाले कर्नेल स्तर के ड्राइवर के रूप में करता है। अधिक समझने के लिए, एक संसाधन [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8) प्राप्त है।
कुछ एप्लिकेशन को एक लॉन्चर एक्टिविटी की आवश्यकता नहीं होती, विशेष रूप से उन एप्लिकेशनों के लिए जिनमें उपयोगकर्ता इंटरफेस नहीं होता है, जैसे बैकग्राउंड सेवाएं।
एक्टिविटी को "निर्यात" मानित करके अन्य एप्लिकेशन या प्रक्रियाओं के लिए उपलब्ध किया जा सकता है। इस सेटिंग से अन्य एप्लिकेशन को इस एक्टिविटी को शुरू करने की अनुमति मिलती है:
हालांकि, एक एक्टिविटी को दूसरे ऐप से एक्सेस करना हमेशा एक सुरक्षा जोखिम नहीं है। चिंता उत्पन्न होती है अगर संवेदनशील डेटा गलत तरीके से साझा किया जा रहा है, जिससे सूचना लीक हो सकती है।
Android विकास में, एक ऐप के पास [एप्लिकेशन](https://developer.android.com/reference/android/app/Application) क्लास का एक **सबक्लास** बनाने का विकल्प होता है, हालांकि यह अनिवार्य नहीं है। जब ऐसा सबक्लास परिभाषित किया जाता है, तो यह ऐप के भीतर पहली क्लास बन जाता है। यदि इस सबक्लास में **`attachBaseContext`** मेथड को लागू किया गया है, तो यह **`onCreate`** मेथड से पहले निष्पादित किया जाता है। यह सेटअप ऐप के शेष हिस्से शुरू होने से पहले पहले प्रारंभिकीकरण की अनुमति देता है।
[सेवाएं](https://developer.android.com/guide/components/services) **पृष्ठभूमि कार्यकर्ताओं** हैं जो उपयोगकर्ता इंटरफ़ेस के बिना कार्यों को क्रियान्वित करने में सक्षम होती हैं। ये कार्य चालू रह सकते हैं भले ही उपयोगकर्ता विभिन्न एप्लिकेशनों पर स्विच कर जाएं, जिससे सेवाएं **लंबे समय तक चलने वाले कार्यों** के लिए महत्वपूर्ण होती हैं।
सेवाएं विविध हैं; इन्हें विभिन्न तरीकों से प्रारंभ किया जा सकता है, **इंटेंट्स** इन्हें लॉन्च करने के लिए मुख्य तरीका होते हैं जैसे कि एक एप्लिकेशन का प्रवेश बिंदु। जब एक सेवा `startService` विधि का उपयोग करके शुरू की जाती है, तो इसकी `onStart` विधि कार्रवाई में आती है और `stopService` विधि को स्पष्ट रूप से बुलाया जाने तक चलती रहती है। अल्टरनेटिवली, यदि किसी सेवा की भूमिका एक सक्रिय क्लाइंट कनेक्शन पर निर्भर है, तो `bindService` विधि का उपयोग सेवा को क्लाइंट से जोड़ने के लिए किया जाता है, डेटा पासेज के लिए `onBind` विधि को सक्रिय करता है।
सेवाओं का एक दिलचस्प उपयोग बैकग्राउंड संगीत प्लेबैक या नेटवर्क डेटा प्राप्ति जैसा हो सकता है बिना उपयोगकर्ता के एप्लिकेशन के साथ बातचीत को बाधित किए। इसके अतिरिक्त, सेवाएं अन्य प्रक्रियाओं के लिए उपलब्ध बनाई जा सकती हैं जो एक ही उपकरण पर हैं **निर्यात** के माध्यम से। यह डिफ़ॉल्ट व्यवहार नहीं है और एंड्रॉइड मैनिफ़ेस्ट फ़ाइल में स्पष्ट रूप से कॉन्फ़िगरेशन की आवश्यकता होती है:
**ब्रॉडकास्ट रिसीवर** मैसेजिंग सिस्टम में सुनने वाले के रूप में काम करते हैं, जो कई एप्लिकेशनों को सिस्टम से एक ही संदेश का जवाब देने की अनुमति देते हैं। एक एप्लिकेशन **दो मुख्य तरीकों** से रिसीवर को **रजिस्टर** कर सकता है: एप्लिकेशन के **मैनिफेस्ट** के माध्यम से या एप्लिकेशन के कोड के भीतर **डायनामिक रूप से** एपीआई के माध्यम से **`registerReceiver`**। मैनिफेस्ट में, ब्रॉडकास्ट को अनुमतियों के साथ फ़िल्टर किया जाता है, जबकि डायनामिक रूप से रजिस्टर किए गए रिसीवर भी पंजीकरण के समय अनुमतियाँ निर्दिष्ट कर सकते हैं।
**इंटेंट फ़िल्टर** दोनों पंजीकरण विधियों में महत्वपूर्ण हैं, जो रिसीवर को कौन से ब्रॉडकास्ट को ट्रिगर करें यह निर्धारित करते हैं। एक मिलती जुलती ब्रॉडकास्ट भेजी जाती है, तो रिसीवर का **`onReceive`** मेथड चालू हो जाता है, जिससे एप्लिकेशन उसके अनुसार प्रतिक्रिया दे सकती है, जैसे किसी कम बैटरी अलर्ट के प्रतिक्रिया में व्यवहार समायोजित करना।
ब्रॉडकास्ट या तो **असिंक्रोनस** हो सकते हैं, जो सभी रिसीवर्स तंतु के बिना पहुंचते हैं, या **सिंक्रोनस**, जहां रिसीवर्स को सेट की गई प्राथमिकताओं के आधार पर ब्रॉडकास्ट मिलती है। हालांकि, किसी भी एप्लिकेशन को ब्रॉडकास्ट को अंतर्गत करने के लिए अपनी प्राथमिकता देने की संभावना को ध्यान में रखना महत्वपूर्ण है।
रिसीवर की कार्यक्षमता को समझने के लिए, उसकी कक्षा में **`onReceive`** मेथड देखें। इस मेथड का कोड प्राप्त इंटेंट को संशोधित कर सकता है, रिसीवर्स द्वारा डेटा मान्यता की आवश्यकता को हाइलाइट करता है, विशेषकर **ऑर्डर्ड ब्रॉडकास्ट्स** में, जो इंटेंट को संशोधित या छोड़ सकते हैं।
**कंटेंट प्रोवाइडर्स** एप्लिकेशनों के बीच **संरचित डेटा साझा** करने के लिए महत्वपूर्ण हैं, डेटा सुरक्षा सुनिश्चित करने के लिए **अनुमतियों** को लागू करने की महत्वपूर्णता को जोर देते हैं। इन्हें एप्लिकेशन को विभिन्न स्रोतों से डेटा तक पहुंचने की अनुमति देते हैं, जैसे डेटाबेस, फ़ाइलसिस्टम, या वेब से। नियंत्रण के लिए महत्वपूर्ण अनुमतियाँ, जैसे **`readPermission`** और **`writePermission`**, एक्सेस को नियंत्रित करने के लिए महत्वपूर्ण हैं। इसके अतिरिक्त, अस्थायी एक्सेस को एप्लिकेशन के मैनिफेस्ट में **`grantUriPermission`** सेटिंग के माध्यम से प्रदान किया जा सकता है, जिसमें `path`, `pathPrefix`, और `pathPattern` जैसे विस्तृत एक्सेस नियंत्रण के लिए गुणों का लाभ उठाया जा सकता है।
इनपुट मान्यता गंभीर सुरक्षा दुरुपयोग जैसे भेदभाव को रोकने के लिए महत्वपूर्ण है। कंटेंट प्रोवाइडर्स मूल ऑपरेशन्स का समर्थन करते हैं: `insert()`, `update()`, `delete()`, और `query()`, डेटा संशोधन और एप्लिकेशनों के बीच साझा करने की सुविधा प्रदान करते हैं।
**FileProvider**, एक विशेषित कंटेंट प्रोवाइडर, सुरक्षित रूप से फ़ाइलों को साझा करने पर ध्यान केंद्रित है। इसे एप्लिकेशन के मैनिफेस्ट में विशेष गुणों के साथ परिभाषित किया जाता है ताकि फ़ोल्डर का एक्सेस नियंत्रण किया जा सके, जिसे `android:exported` और `android:resource` द्वारा फ़ोल्डर कॉन्फ़िगरेशन को निर्दिष्ट किया जाता है। संवेदनशील डेटा को अनजाने में उजागर करने से बचने के लिए डायरेक्टरी को साझा करते समय सावधानी बरतने की सलाह दी जाती है।
WebViews are like **mini web browsers** inside Android apps, pulling content either from the web or from local files. They face similar risks as regular browsers, yet there are ways to **reduce these risks** through specific **settings**.
Android offers two main WebView types:
- **WebViewClient** is great for basic HTML but doesn't support the JavaScript alert function, affecting how XSS attacks can be tested.
- **WebChromeClient** acts more like the full Chrome browser experience.
A key point is that WebView browsers do **not share cookies** with the device's main browser.
For loading content, methods such as ````loadUrl````, ````loadData````, and ````loadDataWithBaseURL```` are available. It's crucial to ensure these URLs or files are **safe to use**. Security settings can be managed via the ````WebSettings```` class. For instance, disabling JavaScript with ````setJavaScriptEnabled(false)```` can prevent XSS attacks.
The JavaScript "Bridge" lets Java objects interact with JavaScript, requiring methods to be marked with ````@JavascriptInterface```` for security from Android 4.2 onwards.
Allowing content access (````setAllowContentAccess(true)````) lets WebViews reach Content Providers, which could be a risk unless the content URLs are verified as secure.
- Disabling file access (````setAllowFileAccess(false)````) limits access to the filesystem, with exceptions for certain assets, ensuring they're only used for non-sensitive content.
- **Digital signing** is a must for Android apps, ensuring they're **authentically authored** before installation. This process uses a certificate for app identification and must be verified by the device's package manager upon installation. Apps can be **self-signed or certified by an external CA**, safeguarding against unauthorized access and ensuring the app remains untampered during its delivery to the device.
- Starting from **Android 4.2**, a feature called **Verify Apps** allows users to have apps checked for safety before installation. This **verification process** can warn users against potentially harmful apps, or even prevent the installation of particularly malicious ones, enhancing user security.
### **Mobile Device Management (MDM)**
- **MDM solutions** provide **oversight and security** for mobile devices through **Device Administration API**. They necessitate the installation of an Android app to manage and secure mobile devices effectively. Key functions include **enforcing password policies**, **mandating storage encryption**, and **permitting remote data wipe**, ensuring comprehensive control and security over mobile devices.
```java
// Example of enforcing a password policy with MDM
सबसे महत्वपूर्ण सुरक्षा गड़बड़ियों को खोजें ताकि आप उन्हें तेजी से ठीक कर सकें। Intruder आपकी हमले की सतह का ट्रैक करता है, प्रोएक्टिव धारणा स्कैन चलाता है, API से वेब ऐप्स और क्लाउड सिस्टम जैसे पूरे टेक स्टैक पर मुद्दे खोजता है। [**आज ही मुफ्त में इसका प्रयास करें**](https://www.intruder.io/?utm_source=referral\&utm_campaign=hacktricks)।
<summary><strong>शून्य से हीरो तक AWS हैकिंग सीखें</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* यदि आप अपनी **कंपनी का विज्ञापन HackTricks में देखना चाहते हैं** या **HackTricks को PDF में डाउनलोड करना चाहते हैं** तो [**सब्सक्रिप्शन प्लान**](https://github.com/sponsors/carlospolop) देखें!
