hacktricks/src/mobile-pentesting/android-app-pentesting/android-applications-basics.md

# Android Applications Basics

{{#include ../../banners/hacktricks-training.md}}

## Android Security Model

**दो परतें हैं:**

- **OS**, जो स्थापित अनुप्रयोगों को एक-दूसरे से अलग रखता है।
- **अनुप्रयोग स्वयं**, जो डेवलपर्स को **कुछ कार्यक्षमताओं को उजागर करने** की अनुमति देता है और अनुप्रयोग क्षमताओं को कॉन्फ़िगर करता है।

### UID Separation

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

### UID Sharing

**दो अनुप्रयोगों को समान UID का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है**। यह जानकारी साझा करने के लिए उपयोगी हो सकता है, लेकिन यदि उनमें से एक समझौता कर लिया जाता है तो दोनों अनुप्रयोगों का डेटा समझौता कर लिया जाएगा। यही कारण है कि इस व्यवहार को **नकारा** जाता है।\
**समान UID साझा करने के लिए, अनुप्रयोगों को अपने मैनिफेस्ट में समान `android:sharedUserId` मान को परिभाषित करना चाहिए।**

### Sandboxing

**Android Application Sandbox** प्रत्येक अनुप्रयोग को **एक अलग उपयोगकर्ता आईडी के तहत एक अलग प्रक्रिया के रूप में चलाने** की अनुमति देता है। प्रत्येक प्रक्रिया की अपनी वर्चुअल मशीन होती है, इसलिए एक ऐप का कोड अन्य ऐप्स से अलग-थलग चलता है।\
Android 5.0(L) से **SELinux** लागू किया गया है। मूल रूप से, SELinux ने सभी प्रक्रिया इंटरैक्शन को अस्वीकार कर दिया और फिर **उनके बीच केवल अपेक्षित इंटरैक्शन की अनुमति देने के लिए नीतियाँ बनाई**।

### Permissions

जब आप एक **ऐप इंस्टॉल करते हैं और यह अनुमतियों के लिए पूछता है**, तो ऐप **`uses-permission`** तत्वों में कॉन्फ़िगर की गई अनुमतियों के लिए पूछ रहा है जो **AndroidManifest.xml** फ़ाइल में हैं। **uses-permission** तत्व अनुरोधित अनुमति के नाम को **name** **attribute** के अंदर इंगित करता है। इसमें **maxSdkVersion** विशेषता भी है जो निर्दिष्ट संस्करण से उच्च संस्करणों पर अनुमतियों के लिए पूछना बंद कर देती है।\
ध्यान दें कि Android अनुप्रयोगों को शुरुआत में सभी अनुमतियों के लिए पूछने की आवश्यकता नहीं है, वे **डायनामिकली अनुमतियों के लिए भी पूछ सकते हैं** लेकिन सभी अनुमतियों को **मैनिफेस्ट में घोषित** किया जाना चाहिए।

जब एक ऐप कार्यक्षमता को उजागर करता है, तो यह **केवल उन ऐप्स तक पहुंच को सीमित कर सकता है जिनके पास एक निर्दिष्ट अनुमति है**।\
एक अनुमति तत्व में तीन विशेषताएँ होती हैं:

- अनुमति का **नाम**
- **permission-group** विशेषता, जो संबंधित अनुमतियों को समूहित करने की अनुमति देती है।
- **protection-level** जो इंगित करता है कि अनुमतियाँ कैसे दी जाती हैं। चार प्रकार हैं:
- **Normal**: जब ऐप के लिए **कोई ज्ञात खतरे** नहीं होते हैं। उपयोगकर्ता को **इसे स्वीकृत करने की आवश्यकता नहीं है**।
- **Dangerous**: इंगित करता है कि अनुमति अनुरोध करने वाले अनुप्रयोग को कुछ **उच्च पहुंच** प्रदान करती है। **उपयोगकर्ताओं से इन्हें स्वीकृत करने के लिए कहा जाता है**।
- **Signature**: केवल **उसी प्रमाणपत्र द्वारा हस्ताक्षरित ऐप्स** को अनुमति दी जा सकती है जो घटक को निर्यात कर रहा है। यह सुरक्षा का सबसे मजबूत प्रकार है।
- **SignatureOrSystem**: केवल **उसी प्रमाणपत्र द्वारा हस्ताक्षरित ऐप्स** या **सिस्टम-स्तरीय पहुंच के साथ चलने वाले ऐप्स** को अनुमतियाँ दी जा सकती हैं।

## Pre-Installed Applications

ये ऐप्स आमतौर पर **`/system/app`** या **`/system/priv-app`** निर्देशिकाओं में पाए जाते हैं और इनमें से कुछ **अनुकूलित** होते हैं (आपको `classes.dex` फ़ाइल भी नहीं मिल सकती है)। ये अनुप्रयोग जांचने के लायक हैं क्योंकि कभी-कभी ये **बहुत सारी अनुमतियों के साथ चल रहे होते हैं** (जैसे रूट)।

- **AOSP** (Android OpenSource Project) **ROM** के साथ शिप किए गए
- डिवाइस **निर्माता** द्वारा जोड़े गए
- सेल **फोन प्रदाता** द्वारा जोड़े गए (यदि उन्हें उनसे खरीदा गया हो)

## Rooting

एक भौतिक Android डिवाइस में रूट एक्सेस प्राप्त करने के लिए आपको आमतौर पर **1 या 2 कमजोरियों का शोषण** करने की आवश्यकता होती है जो **डिवाइस** और **संस्करण** के लिए **विशिष्ट** होती हैं।\
एक बार जब शोषण काम कर जाता है, तो आमतौर पर Linux `su` बाइनरी को उपयोगकर्ता के PATH env वेरिएबल में निर्दिष्ट स्थान पर कॉपी किया जाता है जैसे `/system/xbin`।

एक बार जब su बाइनरी कॉन्फ़िगर हो जाती है, तो `su` बाइनरी के साथ इंटरफेस करने के लिए एक और Android ऐप का उपयोग किया जाता है और **रूट एक्सेस के लिए अनुरोधों को संसाधित** किया जाता है जैसे **Superuser** और **SuperSU** (जो Google Play स्टोर में उपलब्ध हैं)।

> [!CAUTION]
> ध्यान दें कि रूटिंग प्रक्रिया बहुत खतरनाक है और डिवाइस को गंभीर रूप से नुकसान पहुँचा सकती है।

### ROMs

यह संभव है कि **कस्टम फर्मवेयर स्थापित करके OS को बदलें**। ऐसा करने से एक पुराने डिवाइस की उपयोगिता बढ़ाई जा सकती है, सॉफ़्टवेयर प्रतिबंधों को बायपास किया जा सकता है या नवीनतम Android कोड तक पहुंच प्राप्त की जा सकती है।\
**OmniROM** और **LineageOS** उपयोग करने के लिए सबसे लोकप्रिय फर्मवेयर में से दो हैं।

ध्यान दें कि **कस्टम फर्मवेयर स्थापित करने के लिए डिवाइस को रूट करना हमेशा आवश्यक नहीं है**। **कुछ निर्माता** अपने बूटलोडर्स को अच्छी तरह से प्रलेखित और सुरक्षित तरीके से अनलॉक करने की अनुमति देते हैं।

### Implications

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

## Android Application Fundamentals <a href="#2-android-application-fundamentals" id="2-android-application-fundamentals"></a>

- Android अनुप्रयोगों का प्रारूप _APK फ़ाइल प्रारूप_ के रूप में संदर्भित किया जाता है। यह मूल रूप से एक **ZIP फ़ाइल** है (फ़ाइल एक्सटेंशन को .zip में बदलकर, सामग्री को निकाला और देखा जा सकता है)।
- APK सामग्री (पूर्ण नहीं)
- **AndroidManifest.xml**
- resources.arsc/strings.xml
- resources.arsc: पूर्व-संकलित संसाधनों को शामिल करता है, जैसे बाइनरी XML।
- res/xml/files_paths.xml
- META-INF/
- यहीं पर प्रमाणपत्र स्थित है!
- **classes.dex**
- इसमें डलविक बाइटकोड होता है, जो संकलित Java (या Kotlin) कोड का प्रतिनिधित्व करता है जिसे अनुप्रयोग डिफ़ॉल्ट रूप से निष्पादित करता है।
- lib/
- इसमें मूलभूत पुस्तकालय होते हैं, जो उपनिर्देशिकाओं में CPU आर्किटेक्चर द्वारा विभाजित होते हैं।
- `armeabi`: ARM आधारित प्रोसेसर के लिए कोड
- `armeabi-v7a`: ARMv7 और उच्चतर आधारित प्रोसेसर के लिए कोड
- `x86`: X86 प्रोसेसर के लिए कोड
- `mips`: केवल MIPS प्रोसेसर के लिए कोड
- assets/
- ऐप द्वारा आवश्यक विविध फ़ाइलों को संग्रहीत करता है, जिसमें अतिरिक्त मूलभूत पुस्तकालय या DEX फ़ाइलें शामिल हो सकती हैं, जिन्हें कभी-कभी मैलवेयर लेखक अतिरिक्त कोड को छिपाने के लिए उपयोग करते हैं।
- res/
- संसाधनों को शामिल करता है जो resources.arsc में संकलित नहीं होते हैं।

### **Dalvik & Smali**

Android विकास में, **Java या Kotlin** का उपयोग ऐप बनाने के लिए किया जाता है। डेस्कटॉप ऐप्स की तरह JVM का उपयोग करने के बजाय, Android इस कोड को **Dalvik Executable (DEX) बाइटकोड** में संकलित करता है। पहले, डलविक वर्चुअल मशीन इस बाइटकोड को संभालती थी, लेकिन अब, नए Android संस्करणों में Android Runtime (ART) इसका प्रभार लेता है।

रिवर्स इंजीनियरिंग के लिए, **Smali** महत्वपूर्ण हो जाता है। यह DEX बाइटकोड का मानव-पठनीय संस्करण है, जो स्रोत कोड को बाइटकोड निर्देशों में अनुवाद करके असेंबली भाषा की तरह कार्य करता है। इस संदर्भ में Smali और baksmali असेंबली और डिसअसेंबली उपकरणों को संदर्भित करते हैं।

## Intents

Intents Android ऐप्स के बीच उनके घटकों या अन्य ऐप्स के साथ संवाद करने का प्राथमिक साधन हैं। ये संदेश वस्तुएं ऐप्स या घटकों के बीच डेटा ले जा सकती हैं, जैसे HTTP संचार में GET/POST अनुरोधों का उपयोग किया जाता है।

तो एक Intent मूल रूप से **घटकों के बीच पारित किया जाने वाला एक संदेश है**। Intents **विशिष्ट घटकों या ऐप्स की ओर निर्देशित** किए जा सकते हैं, **या बिना किसी विशिष्ट प्राप्तकर्ता के भेजे जा सकते हैं**।\
सरलता से, Intent का उपयोग किया जा सकता है:

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

यदि कमजोर हैं, तो **Intents का उपयोग विभिन्न प्रकार के हमलों को करने के लिए किया जा सकता है**।

### Intent-Filter

**Intent Filters** परिभाषित करते हैं **कैसे एक गतिविधि, सेवा, या Broadcast Receiver विभिन्न प्रकार के Intents के साथ इंटरैक्ट कर सकता है**। मूल रूप से, वे इन घटकों की क्षमताओं का वर्णन करते हैं, जैसे कि वे कौन से कार्य कर सकते हैं या वे किस प्रकार के प्रसारण को संसाधित कर सकते हैं। इन फ़िल्टरों की घोषणा करने का प्राथमिक स्थान **AndroidManifest.xml फ़ाइल** के भीतर है, हालांकि Broadcast Receivers के लिए, उन्हें कोडिंग करना भी एक विकल्प है।

Intent Filters श्रेणियों, क्रियाओं और डेटा फ़िल्टरों से बने होते हैं, जिसमें अतिरिक्त मेटाडेटा शामिल करने की संभावना होती है। यह सेटअप घटकों को उन विशिष्ट Intents को संभालने की अनुमति देता है जो घोषित मानदंडों से मेल खाते हैं।

Android घटकों (गतिविधियाँ/सेवाएँ/सामग्री प्रदाता/प्रसारण रिसीवर) का एक महत्वपूर्ण पहलू उनकी दृश्यता या **सार्वजनिक स्थिति** है। एक घटक को सार्वजनिक माना जाता है और यह अन्य ऐप्स के साथ इंटरैक्ट कर सकता है यदि इसे **`exported`** के मान के साथ **`true`** के रूप में सेट किया गया है या यदि इसके लिए मैनिफेस्ट में एक Intent Filter घोषित किया गया है। हालाँकि, डेवलपर्स के लिए इन घटकों को स्पष्ट रूप से निजी रखना संभव है, यह सुनिश्चित करते हुए कि वे अनजाने में अन्य ऐप्स के साथ इंटरैक्ट न करें। यह उनके मैनिफेस्ट परिभाषाओं में **`exported`** विशेषता को **`false`** पर सेट करके प्राप्त किया जाता है।

इसके अलावा, डेवलपर्स के पास इन घटकों तक पहुंच को और सुरक्षित करने का विकल्प होता है, विशेष अनुमतियों की आवश्यकता करके। **`permission`** विशेषता को सेट किया जा सकता है ताकि केवल उन ऐप्स को अनुमति दी जा सके जिनके पास निर्दिष्ट अनुमति है, जिससे सुरक्षा और नियंत्रण की एक अतिरिक्त परत जोड़ी जा सके कि कौन इसके साथ इंटरैक्ट कर सकता है।
```java
<activity android:name=".MyActivity" android:exported="false">
<!-- Intent filters go here -->
</activity>
```
### Implicit Intents

Intents को एक Intent कंस्ट्रक्टर का उपयोग करके प्रोग्रामेटिक रूप से बनाया जाता है:
```java
Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));
```
**Action** पहले घोषित किए गए इरादे का **ACTION_SEND** है और **Extra** एक मेलटू **Uri** है (Extra वह अतिरिक्त जानकारी है जिसकी इरादा अपेक्षा कर रहा है)।

इस इरादे को मैनिफेस्ट के अंदर निम्नलिखित उदाहरण के रूप में घोषित किया जाना चाहिए:
```xml
<activity android:name="ShareActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
```
एक intent-filter को संदेश प्राप्त करने के लिए **action**, **data** और **category** से मेल खाना चाहिए।

"Intent resolution" प्रक्रिया यह निर्धारित करती है कि प्रत्येक संदेश को कौन सा ऐप प्राप्त करना चाहिए। यह प्रक्रिया **priority attribute** पर विचार करती है, जिसे i**ntent-filter declaration** में सेट किया जा सकता है, और **उच्च प्राथमिकता वाला चयनित होगा**। यह प्राथमिकता -1000 और 1000 के बीच सेट की जा सकती है और एप्लिकेशन `SYSTEM_HIGH_PRIORITY` मान का उपयोग कर सकते हैं। यदि **conflict** उत्पन्न होता है, तो एक "choser" Window प्रकट होती है ताकि **उपयोगकर्ता निर्णय ले सके**।

### Explicit Intents

एक स्पष्ट intent उस वर्ग नाम को निर्दिष्ट करता है जिसे यह लक्षित कर रहा है:
```java
Intent downloadIntent = new (this, DownloadService.class):
```
अन्य अनुप्रयोगों में पूर्व में घोषित इरादे तक पहुँचने के लिए आप उपयोग कर सकते हैं:
```java
Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);
```
### Pending Intents

ये अन्य अनुप्रयोगों को **आपके अनुप्रयोग की ओर से क्रियाएँ करने** की अनुमति देते हैं, आपके ऐप की पहचान और अनुमतियों का उपयोग करते हुए। एक Pending Intent बनाने के लिए **एक इरादा और प्रदर्शन करने के लिए क्रिया को निर्दिष्ट किया जाना चाहिए**। यदि **घोषित इरादा स्पष्ट नहीं है** (यह नहीं बताता कि कौन सा इरादा इसे कॉल कर सकता है) तो एक **दुष्ट अनुप्रयोग घोषित क्रिया को पीड़ित ऐप की ओर से प्रदर्शन कर सकता है**। इसके अलावा, **यदि कोई क्रिया निर्दिष्ट नहीं की गई है**, तो दुष्ट ऐप **पीड़ित की ओर से कोई भी क्रिया कर सकेगा**।

### Broadcast Intents

पिछले इरादों के विपरीत, जो केवल एक ऐप द्वारा प्राप्त होते हैं, ब्रॉडकास्ट इरादे **कई ऐप द्वारा प्राप्त किए जा सकते हैं**। हालाँकि, API संस्करण 14 से, यह **संदेश प्राप्त करने वाले ऐप को निर्दिष्ट करना संभव है** Intent.set Package का उपयोग करके।

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

ब्रॉडकास्ट के **दो प्रकार** होते हैं: **सामान्य** (असिंक्रोनस) और **क्रमबद्ध** (सिंक्रोनस)। **क्रम** रिसीवर तत्व के **कॉन्फ़िगर की गई प्राथमिकता** पर आधारित है। **प्रत्येक ऐप ब्रॉडकास्ट को संसाधित, पुनः प्रसारित या छोड़ सकता है।**

आप `Context` क्लास से `sendBroadcast(intent, receiverPermission)` फ़ंक्शन का उपयोग करके **ब्रॉडकास्ट** **भेजना** संभव है।\
आप **`LocalBroadCastManager`** से **`sendBroadcast`** फ़ंक्शन का भी उपयोग कर सकते हैं जो सुनिश्चित करता है कि **संदेश ऐप से बाहर नहीं जाता**। इसका उपयोग करते समय आपको रिसीवर घटक को निर्यात करने की भी आवश्यकता नहीं होगी।

### Sticky Broadcasts

इस प्रकार के ब्रॉडकास्ट **भेजे जाने के लंबे समय बाद भी एक्सेस किए जा सकते हैं**।\
इनका API स्तर 21 में निराधारित किया गया था और **इनका उपयोग न करने की सिफारिश की गई है**।\
**ये किसी भी अनुप्रयोग को डेटा को स्निफ़ करने, बल्कि इसे संशोधित करने की अनुमति देते हैं।**

यदि आप "sticky" शब्द वाले फ़ंक्शंस जैसे **`sendStickyBroadcast`** या **`sendStickyBroadcastAsUser`** पाते हैं, तो **प्रभाव की जांच करें और उन्हें हटाने का प्रयास करें**।

## Deep links / URL schemes

Android अनुप्रयोगों में, **डीप लिंक** का उपयोग एक क्रिया (Intent) को सीधे एक URL के माध्यम से आरंभ करने के लिए किया जाता है। यह एक गतिविधि के भीतर एक विशिष्ट **URL स्कीम** घोषित करके किया जाता है। जब एक Android डिवाइस **इस स्कीम के साथ एक URL तक पहुँचने की कोशिश करता है**, तो अनुप्रयोग के भीतर निर्दिष्ट गतिविधि लॉन्च होती है।

स्कीम को **`AndroidManifest.xml`** फ़ाइल में घोषित किया जाना चाहिए:
```xml
[...]
<activity android:name=".MyActivity">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="examplescheme" />
</intent-filter>
[...]
```
पिछले उदाहरण से योजना है `examplescheme://` (ध्यान दें कि **`category BROWSABLE`** भी है)

फिर, डेटा फ़ील्ड में, आप **host** और **path** निर्दिष्ट कर सकते हैं:
```xml
<data android:scheme="examplescheme"
android:host="example"
/>
```
इसे वेब से एक्सेस करने के लिए एक लिंक सेट करना संभव है:
```xml
<a href="examplescheme://example/something">click here</a>
<a href="examplescheme://example/javascript://%250dalert(1)">click here</a>
```
ऐप में निष्पादित होने वाले **कोड को खोजने के लिए**, उस गतिविधि पर जाएं जिसे डीपलिंक द्वारा कॉल किया गया है और **`onNewIntent`** फ़ंक्शन को खोजें।

सीखें कि [HTML पृष्ठों का उपयोग किए बिना डीप लिंक कैसे कॉल करें](#exploiting-schemes-deep-links)।

## AIDL - Android इंटरफेस परिभाषा भाषा

**Android इंटरफेस परिभाषा भाषा (AIDL)** का उद्देश्य Android अनुप्रयोगों में **इंटरप्रोसेस संचार** (IPC) के माध्यम से क्लाइंट और सेवा के बीच संचार को सुविधाजनक बनाना है। चूंकि Android पर किसी अन्य प्रक्रिया की मेमोरी को सीधे एक्सेस करना अनुमति नहीं है, AIDL इस प्रक्रिया को सरल बनाता है, जिससे ऑब्जेक्ट्स को एक ऐसे प्रारूप में परिवर्तित किया जाता है जिसे ऑपरेटिंग सिस्टम समझता है, इस प्रकार विभिन्न प्रक्रियाओं के बीच संचार को आसान बनाता है।

### प्रमुख अवधारणाएँ

- **बाउंड सेवाएँ**: ये सेवाएँ IPC के लिए AIDL का उपयोग करती हैं, जिससे गतिविधियाँ या घटक एक सेवा से बंध सकते हैं, अनुरोध कर सकते हैं और प्रतिक्रियाएँ प्राप्त कर सकते हैं। सेवा की कक्षा में `onBind` विधि इंटरैक्शन शुरू करने के लिए महत्वपूर्ण है, इसे कमजोरियों की खोज में सुरक्षा समीक्षा के लिए एक महत्वपूर्ण क्षेत्र के रूप में चिह्नित किया गया है।

- **मैसेंजर**: एक बाउंड सेवा के रूप में कार्य करते हुए, मैसेंजर IPC को सुविधाजनक बनाता है, जो `onBind` विधि के माध्यम से डेटा को संसाधित करने पर ध्यान केंद्रित करता है। किसी भी असुरक्षित डेटा हैंडलिंग या संवेदनशील कार्यों के निष्पादन के लिए इस विधि की निकटता से जांच करना आवश्यक है।

- **बाइंडर**: हालांकि बाइंडर वर्ग का प्रत्यक्ष उपयोग AIDL के अमूर्तता के कारण कम सामान्य है, यह समझना फायदेमंद है कि बाइंडर एक कर्नेल-स्तरीय ड्राइवर के रूप में कार्य करता है जो विभिन्न प्रक्रियाओं की मेमोरी स्पेस के बीच डेटा ट्रांसफर को सुविधाजनक बनाता है। आगे की समझ के लिए, एक संसाधन उपलब्ध है [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8)।

## घटक

इनमें शामिल हैं: **गतिविधियाँ, सेवाएँ, ब्रॉडकास्ट रिसीवर्स और प्रदाता।**

### लॉन्चर गतिविधि और अन्य गतिविधियाँ

Android ऐप्स में, **गतिविधियाँ** स्क्रीन की तरह होती हैं, जो ऐप के उपयोगकर्ता इंटरफ़ेस के विभिन्न भागों को दिखाती हैं। एक ऐप में कई गतिविधियाँ हो सकती हैं, प्रत्येक एक अद्वितीय स्क्रीन प्रस्तुत करती है।

**लॉन्चर गतिविधि** ऐप का मुख्य गेटवे है, जो तब लॉन्च होती है जब आप ऐप के आइकन पर टैप करते हैं। इसे ऐप के मैनिफेस्ट फ़ाइल में विशिष्ट MAIN और LAUNCHER इरादों के साथ परिभाषित किया गया है:
```html
<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
```
सभी ऐप्स को एक लॉन्चर गतिविधि की आवश्यकता नहीं होती, विशेष रूप से वे जो उपयोगकर्ता इंटरफ़ेस के बिना होते हैं, जैसे बैकग्राउंड सेवाएं।

गतिविधियों को अन्य ऐप्स या प्रक्रियाओं के लिए उपलब्ध कराया जा सकता है, यदि उन्हें मैनिफेस्ट में "निर्यातित" के रूप में चिह्नित किया गया हो। यह सेटिंग अन्य ऐप्स को इस गतिविधि को प्रारंभ करने की अनुमति देती है:
```markdown
<service android:name=".ExampleExportedService" android:exported="true"/>
```
हालांकि, किसी अन्य ऐप से गतिविधि तक पहुंचना हमेशा एक सुरक्षा जोखिम नहीं होता है। चिंता तब होती है जब संवेदनशील डेटा गलत तरीके से साझा किया जा रहा हो, जिससे जानकारी लीक होने की संभावना होती है।

एक गतिविधि का जीवनचक्र **onCreate विधि के साथ शुरू होता है**, UI सेटअप करते हुए और उपयोगकर्ता के साथ बातचीत के लिए गतिविधि को तैयार करते हुए।

### एप्लिकेशन उपवर्ग

Android विकास में, एक ऐप के पास [Application](https://developer.android.com/reference/android/app/Application) वर्ग का **उपवर्ग** बनाने का विकल्प होता है, हालांकि यह अनिवार्य नहीं है। जब ऐसा उपवर्ग परिभाषित किया जाता है, तो यह ऐप के भीतर पहली कक्षा बन जाती है जिसे इंस्टेंट किया जाता है। यदि इस उपवर्ग में **`attachBaseContext`** विधि लागू की गई है, तो इसे **`onCreate`** विधि से पहले निष्पादित किया जाता है। यह सेटअप शेष एप्लिकेशन शुरू होने से पहले प्रारंभिक प्रारंभ की अनुमति देता है।
```java
public class MyApp extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// Initialization code here
}

@Override
public void onCreate() {
super.onCreate();
// More initialization code
}
}
```
### Services

[Services](https://developer.android.com/guide/components/services) **बैकग्राउंड ऑपरेटिव्स** हैं जो बिना उपयोगकर्ता इंटरफेस के कार्यों को निष्पादित करने में सक्षम हैं। ये कार्य तब भी चलते रह सकते हैं जब उपयोगकर्ता विभिन्न अनुप्रयोगों में स्विच करते हैं, जिससे सेवाएँ **लंबी अवधि के संचालन** के लिए महत्वपूर्ण हो जाती हैं।

सेवाएँ बहुपरकारी हैं; इन्हें विभिन्न तरीकों से आरंभ किया जा सकता है, जिसमें **Intents** मुख्य विधि हैं जो उन्हें एक अनुप्रयोग के प्रवेश बिंदु के रूप में लॉन्च करने के लिए उपयोग की जाती हैं। एक बार जब `startService` विधि का उपयोग करके एक सेवा शुरू की जाती है, तो इसका `onStart` विधि सक्रिय हो जाती है और तब तक चलती रहती है जब तक कि `stopService` विधि को स्पष्ट रूप से नहीं बुलाया जाता। वैकल्पिक रूप से, यदि किसी सेवा की भूमिका एक सक्रिय क्लाइंट कनेक्शन पर निर्भर करती है, तो क्लाइंट को सेवा से जोड़ने के लिए `bindService` विधि का उपयोग किया जाता है, जो डेटा पास करने के लिए `onBind` विधि को सक्रिय करता है।

सेवाओं का एक दिलचस्प अनुप्रयोग बैकग्राउंड संगीत प्लेबैक या नेटवर्क डेटा फ़ेचिंग है जो उपयोगकर्ता के ऐप के साथ इंटरैक्शन को बाधित किए बिना होता है। इसके अलावा, सेवाओं को **निर्यात** करके एक ही डिवाइस पर अन्य प्रक्रियाओं के लिए उपलब्ध बनाया जा सकता है। यह डिफ़ॉल्ट व्यवहार नहीं है और इसके लिए Android Manifest फ़ाइल में स्पष्ट कॉन्फ़िगरेशन की आवश्यकता होती है:
```xml
<service android:name=".ExampleExportedService" android:exported="true"/>
```
### Broadcast Receivers

**Broadcast receivers** एक मैसेजिंग सिस्टम में श्रोता के रूप में कार्य करते हैं, जिससे कई एप्लिकेशन सिस्टम से एक ही संदेशों का उत्तर दे सकते हैं। एक ऐप **दो मुख्य तरीकों** से **एक रिसीवर को पंजीकृत** कर सकता है: ऐप के **Manifest** के माध्यम से या ऐप के कोड में **`registerReceiver`** API के माध्यम से **डायनामिकली**। Manifest में, ब्रॉडकास्ट को अनुमतियों के साथ फ़िल्टर किया जाता है, जबकि डायनामिकली पंजीकृत रिसीवर पंजीकरण के समय अनुमतियों को भी निर्दिष्ट कर सकते हैं।

**Intent filters** दोनों पंजीकरण विधियों में महत्वपूर्ण होते हैं, यह निर्धारित करते हैं कि कौन से ब्रॉडकास्ट रिसीवर को ट्रिगर करते हैं। एक बार जब एक मेल खाने वाला ब्रॉडकास्ट भेजा जाता है, तो रिसीवर का **`onReceive`** मेथड सक्रिय होता है, जिससे ऐप को प्रतिक्रिया देने की अनुमति मिलती है, जैसे कि कम बैटरी अलर्ट के जवाब में व्यवहार को समायोजित करना।

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

एक रिसीवर की कार्यक्षमता को समझने के लिए, उसकी क्लास के भीतर **`onReceive`** मेथड की तलाश करें। इस मेथड का कोड प्राप्त Intent को संशोधित कर सकता है, जिससे रिसीवर्स द्वारा डेटा सत्यापन की आवश्यकता को उजागर किया जा सकता है, विशेष रूप से **Ordered Broadcasts** में, जो Intent को संशोधित या छोड़ सकते हैं।

### Content Provider

**Content Providers** ऐप्स के बीच **संरचित डेटा** साझा करने के लिए आवश्यक हैं, डेटा सुरक्षा सुनिश्चित करने के लिए **अनुमतियों** को लागू करने के महत्व पर जोर देते हैं। वे ऐप्स को विभिन्न स्रोतों से डेटा तक पहुँचने की अनुमति देते हैं, जिसमें डेटाबेस, फ़ाइल सिस्टम, या वेब शामिल हैं। विशिष्ट अनुमतियाँ, जैसे **`readPermission`** और **`writePermission`**, पहुँच को नियंत्रित करने के लिए महत्वपूर्ण हैं। इसके अतिरिक्त, ऐप के मैनिफेस्ट में **`grantUriPermission`** सेटिंग्स के माध्यम से अस्थायी पहुँच प्रदान की जा सकती है, जिसमें `path`, `pathPrefix`, और `pathPattern` जैसे गुणों का उपयोग करके विस्तृत पहुँच नियंत्रण किया जा सकता है।

इनपुट सत्यापन कमजोरियों को रोकने के लिए अत्यंत महत्वपूर्ण है, जैसे कि SQL इंजेक्शन। Content Providers बुनियादी संचालन का समर्थन करते हैं: `insert()`, `update()`, `delete()`, और `query()`, जो डेटा हेरफेर और ऐप्लिकेशनों के बीच साझा करने की सुविधा प्रदान करते हैं।

**FileProvider**, एक विशेष Content Provider, फ़ाइलों को सुरक्षित रूप से साझा करने पर केंद्रित है। इसे ऐप के मैनिफेस्ट में विशिष्ट गुणों के साथ परिभाषित किया गया है ताकि फ़ोल्डरों तक पहुँच को नियंत्रित किया जा सके, जिसे `android:exported` और `android:resource` द्वारा फ़ोल्डर कॉन्फ़िगरेशन की ओर इंगित किया गया है। संवेदनशील डेटा को अनजाने में उजागर करने से बचने के लिए निर्देशिकाएँ साझा करते समय सावधानी बरतने की सलाह दी जाती है।

FileProvider के लिए उदाहरण मैनिफेस्ट घोषणा:
```xml
<provider android:name="androidx.core.content.FileProvider"
android:authorities="com.example.myapp.fileprovider"
android:grantUriPermissions="true"
android:exported="false">
<meta-data android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/filepaths" />
</provider>
```
`filepaths.xml` में साझा फ़ोल्डरों को निर्दिष्ट करने का एक उदाहरण:
```xml
<paths>
<files-path path="images/" name="myimages" />
</paths>
```
For further information check:

- [Android Developers: Content Providers](https://developer.android.com/guide/topics/providers/content-providers)
- [Android Developers: FileProvider](https://developer.android.com/training/secure-file-sharing/setup-sharing)

## WebViews

WebViews Android ऐप्स के अंदर **मिनी वेब ब्राउज़र्स** की तरह होते हैं, जो सामग्री को वेब या स्थानीय फ़ाइलों से खींचते हैं। इन्हें सामान्य ब्राउज़रों के समान जोखिमों का सामना करना पड़ता है, फिर भी कुछ विशेष **सेटिंग्स** के माध्यम से **इन जोखिमों को कम करने** के तरीके हैं।

Android दो मुख्य 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)`) फ़ाइल सिस्टम तक पहुंच को सीमित करता है, कुछ संपत्तियों के लिए अपवाद के साथ, यह सुनिश्चित करते हुए कि उन्हें केवल गैर-संवेदनशील सामग्री के लिए उपयोग किया जाए।

## Other App Components and Mobile Device Management

### **Digital Signing of Applications**

- **Digital signing** Android ऐप्स के लिए अनिवार्य है, यह सुनिश्चित करते हुए कि वे स्थापना से पहले **प्रामाणिक रूप से लिखित** हैं। यह प्रक्रिया ऐप पहचान के लिए एक प्रमाणपत्र का उपयोग करती है और स्थापना के समय डिवाइस के पैकेज प्रबंधक द्वारा सत्यापित की जानी चाहिए। ऐप्स **स्वयं-हस्ताक्षरित या बाहरी CA द्वारा प्रमाणित** हो सकते हैं, अनधिकृत पहुंच के खिलाफ सुरक्षा करते हुए और यह सुनिश्चित करते हुए कि ऐप डिवाइस पर डिलीवरी के दौरान बिना छेड़छाड़ के रहे।

### **App Verification for Enhanced Security**

- **Android 4.2** से शुरू होकर, **Verify Apps** नामक एक सुविधा उपयोगकर्ताओं को स्थापना से पहले ऐप्स की सुरक्षा की जांच करने की अनुमति देती है। यह **सत्यापन प्रक्रिया** उपयोगकर्ताओं को संभावित हानिकारक ऐप्स के खिलाफ चेतावनी दे सकती है, या यहां तक कि विशेष रूप से दुर्भावनापूर्ण ऐप्स की स्थापना को रोक सकती है, उपयोगकर्ता सुरक्षा को बढ़ाते हुए।

### **Mobile Device Management (MDM)**

- **MDM समाधान** मोबाइल उपकरणों के लिए **निगरानी और सुरक्षा** प्रदान करते हैं **Device Administration API** के माध्यम से। उन्हें मोबाइल उपकरणों को प्रभावी ढंग से प्रबंधित और सुरक्षित करने के लिए एक Android ऐप की स्थापना की आवश्यकता होती है। प्रमुख कार्यों में **पासवर्ड नीतियों को लागू करना**, **स्टोरेज एन्क्रिप्शन को अनिवार्य करना**, और **दूरस्थ डेटा मिटाने की अनुमति देना** शामिल है, जो मोबाइल उपकरणों पर व्यापक नियंत्रण और सुरक्षा सुनिश्चित करता है।
```java
// Example of enforcing a password policy with MDM
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName adminComponent = new ComponentName(context, AdminReceiver.class);

if (dpm.isAdminActive(adminComponent)) {
// Set minimum password length
dpm.setPasswordMinimumLength(adminComponent, 8);
}
```
## AIDL / बाइंडर सेवाओं की गणना और शोषण

Android *Binder* IPC कई **सिस्टम और विक्रेता-प्रदान की गई सेवाओं** को उजागर करता है। जब ये सेवाएँ उचित अनुमति जांच के बिना निर्यात की जाती हैं, तो ये **हमले की सतह** बन जाती हैं (AIDL परत स्वयं *कोई* पहुँच-नियंत्रण नहीं करती है)।

### 1. चल रही सेवाओं का पता लगाना
```bash
# from an adb shell (USB or wireless)
service list               # simple one-liner
am list services           # identical output, ActivityManager wrapper
```
1. Android एप्लिकेशन के लिए पेंटेस्टिंग एक महत्वपूर्ण प्रक्रिया है।
2. यह प्रक्रिया सुरक्षा कमजोरियों की पहचान करने और उन्हें ठीक करने में मदद करती है।
3. पेंटेस्टिंग के दौरान, हम विभिन्न तकनीकों का उपयोग करते हैं।
4. यह सुनिश्चित करना आवश्यक है कि एप्लिकेशन सुरक्षित है और डेटा लीक नहीं हो रहा है।
5. Android एप्लिकेशन के लिए पेंटेस्टिंग में कई चरण शामिल होते हैं।
```
145  mtkconnmetrics: [com.mediatek.net.connectivity.IMtkIpConnectivityMetrics]
146  wifi             : [android.net.wifi.IWifiManager]
```
* **सूचकांक** (पहला कॉलम) रनटाइम पर असाइन किया जाता है - इसके लिए रिबूट के बीच भरोसा ***नहीं*** करें।
* **बाइंडर नाम** (जैसे `mtkconnmetrics`) वह है जो `service call` को पास किया जाएगा।
* ब्रैकेट के अंदर का मान वह पूर्ण-योग्य **AIDL इंटरफेस** है जिससे स्टब उत्पन्न हुआ था।

### 2. इंटरफेस विवरण प्राप्त करें (PING)
हर बाइंडर स्टब स्वचालित रूप से **लेनदेन कोड `0x5f4e5446`** (`1598968902` दशमलव, ASCII "_NTF") को लागू करता है।
```bash
# "ping" the service
service call mtkconnmetrics 1    # 1 == decimal 1598968902 mod 2^32
```
एक मान्य उत्तर `Parcel` के अंदर UTF-16 स्ट्रिंग के रूप में इंटरफेस नाम लौटाता है।

### 3. लेनदेन को कॉल करना
Syntax: `service call <name> <code> [type value ...]`

सामान्य तर्क निर्दिष्ट करने वाले:
* `i32 <int>` – साइन किया हुआ 32-बिट मान
* `i64 <long>` – साइन किया हुआ 64-बिट मान
* `s16 <string>` – UTF-16 स्ट्रिंग (Android 13+ `utf16` का उपयोग करता है)

उदाहरण – एक MediaTek हैंडसेट पर uid **1** के साथ नेटवर्क मॉनिटरिंग शुरू करें:
```bash
service call mtkconnmetrics 8 i32 1
```
### 4. अज्ञात विधियों का ब्रूट-फोर्सिंग
जब हेडर फ़ाइलें उपलब्ध नहीं होती हैं, तो आप **कोड को दोहराते हैं** जब तक कि त्रुटि इस से बदल न जाए:
```
Result: Parcel(00000000 00000000)  # "Not a data message"
```
एक सामान्य `Parcel` प्रतिक्रिया या `SecurityException`।
```bash
for i in $(seq 1 50); do
printf "[+] %2d -> " $i
service call mtkconnmetrics $i 2>/dev/null | head -1
done
```
यदि सेवा को **proguard** के साथ संकलित किया गया था, तो मैपिंग का अनुमान लगाना होगा - अगले चरण को देखें।

### 5. मैपिंग कोड ↔ विधियाँ onTransact() के माध्यम से
उस जार/ओडेक्स को डिकंपाइल करें जो इंटरफेस को लागू करता है (AOSP स्टब्स के लिए `/system/framework` जांचें; OEM अक्सर `/system_ext` या `/vendor` का उपयोग करते हैं)।
`Stub.onTransact()` के लिए खोजें - इसमें एक विशाल `switch(transactionCode)` है:
```java
case TRANSACTION_updateCtaAppStatus:      // 5
data.enforceInterface(DESCRIPTOR);
int appId  = data.readInt();
boolean ok = data.readInt() != 0;
updateCtaAppStatus(appId, ok);
reply.writeNoException();
return true;
```
अब प्रोटोटाइप और **पैरामीटर प्रकार** स्पष्ट हैं।

### 6. अनुमति जांच की कमी को पहचानना
क्रियान्वयन (अक्सर एक आंतरिक `Impl` वर्ग) प्राधिकरण के लिए जिम्मेदार है:
```java
private void updateCtaAppStatus(int uid, boolean status) {
if (!isPermissionAllowed()) {
throw new SecurityException("uid " + uid + " rejected");
}
/* privileged code */
}
```
ऐसी लॉजिक या विशेषाधिकार प्राप्त UIDs (जैसे `uid == 1000 /*system*/`) की अनुपस्थिति एक **कमजोरी संकेतक** है।

केस स्टडी – *MediaTek* `startMonitorProcessWithUid()` (लेनदेन **8**) बिना किसी अनुमति गेट के एक Netlink संदेश को पूरी तरह से निष्पादित करता है, जिससे एक अप्रिविलेज्ड ऐप को कर्नेल के Netfilter मॉड्यूल के साथ इंटरैक्ट करने और सिस्टम लॉग को स्पैम करने की अनुमति मिलती है।

### 7. मूल्यांकन को स्वचालित करना
बाइंडर अन्वेषण को तेज़ करने वाले उपकरण / स्क्रिप्ट:
* [binderfs](https://android.googlesource.com/platform/frameworks/native/+/master/cmds/binderfs/) – प्रति-सेवा नोड्स के साथ `/dev/binderfs` को उजागर करता है
* [`binder-scanner.py`](https://github.com/adenflare/binder-scanner) – बाइंडर तालिका को चलाता है और ACLs को प्रिंट करता है
* फ्रिडा शॉर्टकट: `Java.perform(()=>console.log(android.os.ServiceManager.listServices().toArray()))`

---

## संदर्भ

- [Android Services 101 – Pentest Partners](https://www.pentestpartners.com/security-blog/android-services-101/)
- [Android Developer Docs – AIDL](https://developer.android.com/guide/components/aidl)
- [Android Developer Docs – IBinder](https://developer.android.com/reference/android/os/IBinder)
- [Understanding Binder, Talk @ Google](https://www.youtube.com/watch?v=O-UHvFjxwZ8)

{{#include ../../banners/hacktricks-training.md}}