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

# Android Applications Basics

{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}

## Android Security Model

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

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

### UID Separation

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

### UID Sharing

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

### Sandboxing

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

### Permissions

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

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

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

## Pre-Installed Applications

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

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

## Rooting

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

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

{% hint style="danger" %}
ध्यान दें कि रूटिंग प्रक्रिया बहुत खतरनाक है और डिवाइस को गंभीर रूप से नुकसान पहुंचा सकती है
{% endhint %}

### ROMs

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

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

### Implications

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

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

- एंड्रॉइड अनुप्रयोगों का प्रारूप _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 में संकलित नहीं होते हैं।

### **Dalvik & Smali**

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

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

## Intents

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

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

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

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

### Intent-Filter

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

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

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

इसके अलावा, डेवलपर्स के पास इन घटकों तक पहुंच को और सुरक्षित करने का विकल्प होता है, विशेष अनुमतियों की आवश्यकता करके। **`permission`** attribute को सेट किया जा सकता है ताकि केवल उन ऐप्स को अनुमति दी जा सके जिनके पास निर्दिष्ट अनुमति है, जो सुरक्षा और नियंत्रण की एक अतिरिक्त परत जोड़ता है कि कौन इसके साथ इंटरैक्ट कर सकता है।
```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:"));
```
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).

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

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

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

आप `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://` है (ध्यान दें कि **`श्रेणी BROWSABLE`** भी है)

फिर, डेटा फ़ील्ड में, आप **होस्ट** और **पथ** निर्दिष्ट कर सकते हैं:
```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>
```
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](./#exploiting-schemes-deep-links).

## AIDL - Android Interface Definition Language

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.

### Key Concepts

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

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

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

## Components

These include: **Activities, Services, Broadcast Receivers and Providers.**

### Launcher Activity and other activities

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:
```markup
<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 **एंड्रॉइड ऐप्स** के अंदर **मिनी वेब ब्राउज़र** की तरह होते हैं, जो सामग्री को या तो वेब से या स्थानीय फ़ाइलों से खींचते हैं। इन्हें नियमित ब्राउज़रों के समान जोखिमों का सामना करना पड़ता है, फिर भी कुछ विशेष **सेटिंग्स** के माध्यम से **इन जोखिमों को कम करने** के तरीके हैं।

एंड्रॉइड दो मुख्य 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**

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

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

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

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

- **MDM समाधान** मोबाइल उपकरणों के लिए **निगरानी और सुरक्षा** प्रदान करते हैं **डिवाइस प्रशासन API** के माध्यम से। इन्हें मोबाइल उपकरणों को प्रभावी ढंग से प्रबंधित और सुरक्षित करने के लिए एक एंड्रॉइड ऐप के इंस्टॉलेशन की आवश्यकता होती है। मुख्य कार्यों में **पासवर्ड नीतियों को लागू करना**, **स्टोरेज एन्क्रिप्शन को अनिवार्य करना**, और **दूरस्थ डेटा मिटाने की अनुमति देना** शामिल है, जो मोबाइल उपकरणों पर व्यापक नियंत्रण और सुरक्षा सुनिश्चित करता है।
```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);
}
```
{% hint style="success" %}
सीखें और AWS हैकिंग का अभ्यास करें:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
सीखें और GCP हैकिंग का अभ्यास करें: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>HackTricks का समर्थन करें</summary>

* [**सदस्यता योजनाएँ**](https://github.com/sponsors/carlospolop) देखें!
* **हमारे** 💬 [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में शामिल हों या **हमें** **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)** पर फॉलो करें।**
* **हैकिंग ट्रिक्स साझा करें और** [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) गिटहब रिपोजिटरी में PRs सबमिट करें।

</details>
{% endhint %}