mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/mobile-pentesting/android-app-pentesting/android-applic
This commit is contained in:
Translator
parent
9de0841b36
commit
ebd04f3fca
@ -25,23 +25,23 @@ Android 5.0(L) से **SELinux** लागू किया गया है।
|
||||
|
||||
### Permissions
|
||||
|
||||
जब आप एक **ऐप इंस्टॉल करते हैं और यह अनुमतियों के लिए पूछता है**, तो ऐप **`uses-permission`** तत्वों में कॉन्फ़िगर की गई अनुमतियों के लिए पूछ रहा है जो **AndroidManifest.xml** फ़ाइल में हैं। **uses-permission** तत्व अनुरोधित अनुमति के नाम को **name** **attribute** के अंदर इंगित करता है। इसमें **maxSdkVersion** attribute भी है जो निर्दिष्ट संस्करण से उच्च संस्करणों पर अनुमतियों के लिए पूछना बंद कर देता है।\
|
||||
ध्यान दें कि Android अनुप्रयोगों को शुरुआत में सभी अनुमतियों के लिए पूछने की आवश्यकता नहीं है, वे **डायनामिकली अनुमतियों के लिए भी पूछ सकते हैं** लेकिन सभी अनुमतियों को **मैनिफेस्ट में घोषित** किया जाना चाहिए।
|
||||
जब आप एक **ऐप इंस्टॉल करते हैं और यह अनुमतियों के लिए पूछता है**, तो ऐप **`uses-permission`** तत्वों में कॉन्फ़िगर की गई अनुमतियों के लिए पूछ रहा है जो **AndroidManifest.xml** फ़ाइल में हैं। **uses-permission** तत्व **name** **attribute** के भीतर अनुरोधित अनुमति का नाम इंगित करता है। इसमें **maxSdkVersion** attribute भी है जो निर्दिष्ट संस्करण से उच्च संस्करणों पर अनुमतियों के लिए पूछना बंद कर देता है।\
|
||||
ध्यान दें कि Android अनुप्रयोगों को शुरुआत में सभी अनुमतियों के लिए पूछने की आवश्यकता नहीं है, वे **डायनामिकली अनुमतियों के लिए भी पूछ सकते हैं** लेकिन सभी अनुमतियों को **मैनिफेस्ट में घोषित** करना चाहिए।
|
||||
|
||||
जब एक ऐप कार्यक्षमता को उजागर करता है, तो यह **केवल उन ऐप्स तक पहुंच को सीमित कर सकता है जिनके पास निर्दिष्ट अनुमति है**।\
|
||||
जब एक ऐप कार्यक्षमता को उजागर करता है, तो यह **केवल उन ऐप्स तक पहुंच को सीमित कर सकता है जिनके पास एक निर्दिष्ट अनुमति है**।\
|
||||
एक अनुमति तत्व में तीन विशेषताएँ होती हैं:
|
||||
|
||||
- अनुमति का **नाम**
|
||||
- **permission-group** attribute, जो संबंधित अनुमतियों को समूहित करने की अनुमति देता है।
|
||||
- **protection-level** जो इंगित करता है कि अनुमतियाँ कैसे दी जाती हैं। चार प्रकार हैं:
|
||||
- **Normal**: जब ऐप के लिए **कोई ज्ञात खतरे** नहीं होते हैं। उपयोगकर्ता को **इसे मंजूर करने की आवश्यकता नहीं है**।
|
||||
- **Dangerous**: इंगित करता है कि अनुमति अनुरोध करने वाले अनुप्रयोग को कुछ **उच्च पहुंच** प्रदान करती है। **उपयोगकर्ताओं से उन्हें मंजूर करने के लिए कहा जाता है**।
|
||||
- **Signature**: केवल **उसी प्रमाणपत्र द्वारा हस्ताक्षरित ऐप्स** को अनुमति दी जा सकती है जो घटक को निर्यात करता है। यह सुरक्षा का सबसे मजबूत प्रकार है।
|
||||
- **Dangerous**: इंगित करता है कि अनुमति अनुरोध करने वाले अनुप्रयोग को कुछ **उच्च पहुंच** प्रदान करती है। **उपयोगकर्ताओं से इन्हें मंजूर करने के लिए कहा जाता है**।
|
||||
- **Signature**: केवल **उसी प्रमाणपत्र द्वारा हस्ताक्षरित ऐप्स** को अनुमति दी जा सकती है जो घटक को निर्यात कर रहा है। यह सुरक्षा का सबसे मजबूत प्रकार है।
|
||||
- **SignatureOrSystem**: केवल **उसी प्रमाणपत्र द्वारा हस्ताक्षरित ऐप्स** या **सिस्टम-स्तरीय पहुंच के साथ चलने वाले ऐप्स** को अनुमतियाँ दी जा सकती हैं।
|
||||
|
||||
## Pre-Installed Applications
|
||||
|
||||
ये ऐप्स आमतौर पर **`/system/app`** या **`/system/priv-app`** निर्देशिकाओं में पाए जाते हैं और इनमें से कुछ **अनुकूलित** होते हैं (आपको `classes.dex` फ़ाइल भी नहीं मिल सकती है)। ये अनुप्रयोग जांचने के लायक हैं क्योंकि कभी-कभी वे **बहुत सारी अनुमतियों के साथ चल रहे होते हैं** (जैसे रूट)।
|
||||
ये ऐप्स आमतौर पर **`/system/app`** या **`/system/priv-app`** निर्देशिकाओं में पाए जाते हैं और इनमें से कुछ **अनुकूलित** होते हैं (आपको `classes.dex` फ़ाइल भी नहीं मिल सकती है)। ये अनुप्रयोग जांचने के लायक हैं क्योंकि कभी-कभी ये **बहुत सारी अनुमतियों के साथ चल रहे होते हैं** (जैसे रूट)।
|
||||
|
||||
- **AOSP** (Android OpenSource Project) **ROM** के साथ शिप किए गए
|
||||
- डिवाइस **निर्माता** द्वारा जोड़े गए
|
||||
@ -49,7 +49,7 @@ Android 5.0(L) से **SELinux** लागू किया गया है।
|
||||
|
||||
## Rooting
|
||||
|
||||
एक भौतिक Android डिवाइस में रूट एक्सेस प्राप्त करने के लिए आपको आमतौर पर **1 या 2 कमजोरियों का शोषण** करने की आवश्यकता होती है जो **डिवाइस** और **संस्करण** के लिए **विशिष्ट** होती हैं।\
|
||||
एक भौतिक Android डिवाइस में रूट एक्सेस प्राप्त करने के लिए आपको आमतौर पर **1 या 2 कमजोरियों का शोषण** करना होता है जो **डिवाइस** और **संस्करण** के लिए **विशिष्ट** होती हैं।\
|
||||
एक बार जब शोषण काम कर जाता है, तो आमतौर पर Linux `su` बाइनरी को उपयोगकर्ता के PATH env वेरिएबल में निर्दिष्ट स्थान पर कॉपी किया जाता है जैसे `/system/xbin`।
|
||||
|
||||
एक बार जब su बाइनरी कॉन्फ़िगर हो जाती है, तो `su` बाइनरी के साथ इंटरफेस करने के लिए एक और Android ऐप का उपयोग किया जाता है और **रूट एक्सेस के लिए अनुरोधों को संसाधित** किया जाता है जैसे **Superuser** और **SuperSU** (जो Google Play स्टोर में उपलब्ध हैं)।
|
||||
@ -59,14 +59,14 @@ Android 5.0(L) से **SELinux** लागू किया गया है।
|
||||
|
||||
### ROMs
|
||||
|
||||
यह **कस्टम फर्मवेयर स्थापित करके OS को बदलना** संभव है। ऐसा करने से एक पुराने डिवाइस की उपयोगिता बढ़ाई जा सकती है, सॉफ़्टवेयर प्रतिबंधों को बायपास किया जा सकता है या नवीनतम Android कोड तक पहुंच प्राप्त की जा सकती है।\
|
||||
यह संभव है कि **कस्टम फर्मवेयर स्थापित करके OS को बदलें**। ऐसा करने से एक पुराने डिवाइस की उपयोगिता बढ़ाई जा सकती है, सॉफ़्टवेयर प्रतिबंधों को बायपास किया जा सकता है या नवीनतम Android कोड तक पहुंच प्राप्त की जा सकती है।\
|
||||
**OmniROM** और **LineageOS** उपयोग करने के लिए दो सबसे लोकप्रिय फर्मवेयर हैं।
|
||||
|
||||
ध्यान दें कि **कस्टम फर्मवेयर स्थापित करने के लिए डिवाइस को रूट करना हमेशा आवश्यक नहीं है**। **कुछ निर्माता** अपने बूटलोडर को अच्छी तरह से प्रलेखित और सुरक्षित तरीके से अनलॉक करने की अनुमति देते हैं।
|
||||
ध्यान दें कि **कस्टम फर्मवेयर स्थापित करने के लिए डिवाइस को रूट करना हमेशा आवश्यक नहीं है**। **कुछ निर्माता** अपने बूटलोडर्स को अच्छी तरह से प्रलेखित और सुरक्षित तरीके से अनलॉक करने की अनुमति देते हैं।
|
||||
|
||||
### Implications
|
||||
|
||||
एक बार जब डिवाइस रूट हो जाता है, तो कोई भी ऐप रूट के रूप में एक्सेस का अनुरोध कर सकता है। यदि एक दुर्भावनापूर्ण ऐप इसे प्राप्त करता है, तो यह लगभग सब कुछ तक पहुंच प्राप्त कर लेगा और फोन को नुकसान पहुँचा सकेगा।
|
||||
एक बार जब एक डिवाइस रूट हो जाता है, तो कोई भी ऐप रूट के रूप में एक्सेस का अनुरोध कर सकता है। यदि एक दुर्भावनापूर्ण ऐप इसे प्राप्त करता है, तो यह लगभग सब कुछ तक पहुंच प्राप्त कर लेगा और यह फोन को नुकसान पहुँचा सकेगा।
|
||||
|
||||
## Android Application Fundamentals <a href="#2-android-application-fundamentals" id="2-android-application-fundamentals"></a>
|
||||
|
||||
@ -74,10 +74,10 @@ Android 5.0(L) से **SELinux** लागू किया गया है।
|
||||
- APK सामग्री (पूर्ण नहीं)
|
||||
- **AndroidManifest.xml**
|
||||
- resources.arsc/strings.xml
|
||||
- resources.arsc: पूर्व-compiled संसाधनों को शामिल करता है, जैसे बाइनरी XML।
|
||||
- resources.arsc: पूर्व-संकलित संसाधनों को शामिल करता है, जैसे बाइनरी XML।
|
||||
- res/xml/files_paths.xml
|
||||
- META-INF/
|
||||
- यहीं प्रमाणपत्र स्थित है!
|
||||
- यहीं पर प्रमाणपत्र स्थित है!
|
||||
- **classes.dex**
|
||||
- इसमें डलविक बाइटकोड होता है, जो संकलित Java (या Kotlin) कोड का प्रतिनिधित्व करता है जिसे अनुप्रयोग डिफ़ॉल्ट रूप से निष्पादित करता है।
|
||||
- lib/
|
||||
@ -87,25 +87,25 @@ Android 5.0(L) से **SELinux** लागू किया गया है।
|
||||
- `x86`: X86 प्रोसेसर के लिए कोड
|
||||
- `mips`: केवल MIPS प्रोसेसर के लिए कोड
|
||||
- assets/
|
||||
- ऐप द्वारा आवश्यक विविध फ़ाइलों को संग्रहीत करता है, जिसमें अतिरिक्त मूलभूत पुस्तकालय या DEX फ़ाइलें शामिल हो सकती हैं, जिन्हें कभी-कभी मैलवेयर लेखकों द्वारा अतिरिक्त कोड को छिपाने के लिए उपयोग किया जाता है।
|
||||
- ऐप द्वारा आवश्यक विविध फ़ाइलों को संग्रहीत करता है, जिसमें अतिरिक्त मूलभूत पुस्तकालय या DEX फ़ाइलें शामिल हो सकती हैं, जिन्हें कभी-कभी मैलवेयर लेखक अतिरिक्त कोड को छिपाने के लिए उपयोग करते हैं।
|
||||
- res/
|
||||
- संसाधनों को शामिल करता है जो resources.arsc में संकलित नहीं होते हैं।
|
||||
|
||||
### **Dalvik & Smali**
|
||||
|
||||
Android विकास में, **Java या Kotlin** का उपयोग ऐप बनाने के लिए किया जाता है। डेस्कटॉप ऐप्स की तरह JVM का उपयोग करने के बजाय, Android इस कोड को **Dalvik Executable (DEX) बाइटकोड** में संकलित करता है। पहले, डलविक वर्चुअल मशीन इस बाइटकोड को संभालती थी, लेकिन अब, नए Android संस्करणों में Android Runtime (ART) इसका प्रभार लेता है।
|
||||
Android विकास में, **Java या Kotlin** का उपयोग ऐप बनाने के लिए किया जाता है। डेस्कटॉप ऐप्स की तरह JVM का उपयोग करने के बजाय, Android इस कोड को **Dalvik Executable (DEX) बाइटकोड** में संकलित करता है। पहले, डलविक वर्चुअल मशीन इस बाइटकोड को संभालती थी, लेकिन अब, नए Android संस्करणों में Android Runtime (ART) इसका प्रबंधन करता है।
|
||||
|
||||
रिवर्स इंजीनियरिंग के लिए, **Smali** महत्वपूर्ण हो जाता है। यह DEX बाइटकोड का मानव-पठनीय संस्करण है, जो स्रोत कोड को बाइटकोड निर्देशों में अनुवादित करके असेंबली भाषा की तरह कार्य करता है। Smali और baksmali इस संदर्भ में असेंबली और डिसअसेंबली उपकरणों को संदर्भित करते हैं।
|
||||
रिवर्स इंजीनियरिंग के लिए, **Smali** महत्वपूर्ण हो जाता है। यह DEX बाइटकोड का मानव-पठनीय संस्करण है, जो स्रोत कोड को बाइटकोड निर्देशों में अनुवाद करके असेंबली भाषा की तरह कार्य करता है। इस संदर्भ में Smali और baksmali असेंबली और डिस्सेम्बली उपकरणों को संदर्भित करते हैं।
|
||||
|
||||
## Intents
|
||||
|
||||
Intents Android ऐप्स के बीच उनके घटकों या अन्य ऐप्स के साथ संवाद करने के प्राथमिक साधन हैं। ये संदेश वस्तुएं ऐप्स या घटकों के बीच डेटा ले जा सकती हैं, जैसे HTTP संचार में GET/POST अनुरोधों का उपयोग किया जाता है।
|
||||
|
||||
तो एक Intent मूल रूप से **घटकों के बीच पारित किया जाने वाला एक संदेश है**। Intents **विशिष्ट घटकों या ऐप्स की ओर निर्देशित** किए जा सकते हैं, **या बिना किसी विशिष्ट प्राप्तकर्ता के भेजे जा सकते हैं**।\
|
||||
सरलता के लिए Intent का उपयोग किया जा सकता है:
|
||||
सरलता से, Intent का उपयोग किया जा सकता है:
|
||||
|
||||
- एक गतिविधि शुरू करने के लिए, आमतौर पर एक ऐप के लिए उपयोगकर्ता इंटरफ़ेस खोलना
|
||||
- सिस्टम और ऐप्स को परिवर्तनों की जानकारी देने के लिए प्रसारण के रूप में
|
||||
- सिस्टम और ऐप्स को परिवर्तनों की सूचना देने के लिए प्रसारण के रूप में
|
||||
- एक पृष्ठभूमि सेवा के साथ प्रारंभ, रोकने और संवाद करने के लिए
|
||||
- ContentProviders के माध्यम से डेटा तक पहुँचने के लिए
|
||||
- घटनाओं को संभालने के लिए कॉलबैक के रूप में
|
||||
@ -114,13 +114,13 @@ Intents Android ऐप्स के बीच उनके घटकों य
|
||||
|
||||
### Intent-Filter
|
||||
|
||||
**Intent Filters** परिभाषित करते हैं **कैसे एक गतिविधि, सेवा, या ब्रॉडकास्ट रिसीवर विभिन्न प्रकार के Intents के साथ इंटरैक्ट कर सकता है**। मूल रूप से, वे इन घटकों की क्षमताओं का वर्णन करते हैं, जैसे कि वे कौन से कार्य कर सकते हैं या वे किस प्रकार के प्रसारण को संसाधित कर सकते हैं। इन फ़िल्टरों की घोषणा करने का प्राथमिक स्थान **AndroidManifest.xml फ़ाइल** के भीतर है, हालांकि ब्रॉडकास्ट रिसीवर्स के लिए, उन्हें कोडिंग करना भी एक विकल्प है।
|
||||
**Intent Filters** परिभाषित करते हैं **कैसे एक गतिविधि, सेवा, या Broadcast Receiver विभिन्न प्रकार के Intents के साथ इंटरैक्ट कर सकता है**। मूल रूप से, वे इन घटकों की क्षमताओं का वर्णन करते हैं, जैसे कि वे कौन से कार्य कर सकते हैं या वे किस प्रकार के प्रसारण को संसाधित कर सकते हैं। इन फ़िल्टरों की घोषणा करने का प्राथमिक स्थान **AndroidManifest.xml फ़ाइल** के भीतर है, हालांकि Broadcast Receivers के लिए, उन्हें कोडिंग करना भी एक विकल्प है।
|
||||
|
||||
Intent Filters श्रेणियों, क्रियाओं और डेटा फ़िल्टरों से बने होते हैं, जिसमें अतिरिक्त मेटाडेटा शामिल करने की संभावना होती है। यह सेटअप घटकों को उन विशिष्ट Intents को संभालने की अनुमति देता है जो घोषित मानदंडों से मेल खाते हैं।
|
||||
|
||||
Android घटकों (गतिविधियाँ/सेवाएँ/सामग्री प्रदाता/ब्रॉडकास्ट रिसीवर्स) का एक महत्वपूर्ण पहलू उनकी दृश्यता या **सार्वजनिक स्थिति** है। एक घटक को सार्वजनिक माना जाता है और यह अन्य ऐप्स के साथ इंटरैक्ट कर सकता है यदि इसे **`exported`** के मान के साथ **`true`** के रूप में सेट किया गया है या यदि इसके लिए मैनिफेस्ट में एक Intent Filter घोषित किया गया है। हालाँकि, डेवलपर्स के लिए इन घटकों को स्पष्ट रूप से निजी रखना संभव है, यह सुनिश्चित करते हुए कि वे अनजाने में अन्य ऐप्स के साथ इंटरैक्ट न करें। यह उनके मैनिफेस्ट परिभाषाओं में **`exported`** attribute को **`false`** पर सेट करके प्राप्त किया जाता है।
|
||||
Android घटकों (गतिविधियाँ/सेवाएँ/सामग्री प्रदाता/प्रसारण रिसीवर) का एक महत्वपूर्ण पहलू उनकी दृश्यता या **सार्वजनिक स्थिति** है। एक घटक को सार्वजनिक माना जाता है और यह अन्य ऐप्स के साथ इंटरैक्ट कर सकता है यदि इसे **`exported`** के मान के साथ **`true`** के रूप में सेट किया गया है या यदि इसके लिए मैनिफेस्ट में एक Intent Filter घोषित किया गया है। हालाँकि, डेवलपर्स के लिए इन घटकों को स्पष्ट रूप से निजी रखना संभव है, यह सुनिश्चित करते हुए कि वे अनजाने में अन्य ऐप्स के साथ इंटरैक्ट न करें। यह उनके मैनिफेस्ट परिभाषाओं में **`exported`** विशेषता को **`false`** पर सेट करके प्राप्त किया जाता है।
|
||||
|
||||
इसके अलावा, डेवलपर्स के पास इन घटकों तक पहुंच को और सुरक्षित करने का विकल्प होता है, विशेष अनुमतियों की आवश्यकता करके। **`permission`** attribute को सेट किया जा सकता है ताकि केवल उन ऐप्स को अनुमति दी जा सके जिनके पास निर्दिष्ट अनुमति है, जिससे सुरक्षा और नियंत्रण की एक अतिरिक्त परत जोड़ी जा सके कि कौन इसके साथ इंटरैक्ट कर सकता है।
|
||||
इसके अलावा, डेवलपर्स के पास इन घटकों तक पहुंच को और सुरक्षित करने का विकल्प होता है, विशेष अनुमतियों की आवश्यकता करके। **`permission`** attribute को सेट किया जा सकता है ताकि केवल उन ऐप्स को अनुमति दी जा सके जिनके पास निर्दिष्ट अनुमति है, जो सुरक्षा और नियंत्रण की एक अतिरिक्त परत जोड़ता है कि कौन इसके साथ इंटरैक्ट कर सकता है।
|
||||
```java
|
||||
<activity android:name=".MyActivity" android:exported="false">
|
||||
<!-- Intent filters go here -->
|
||||
@ -149,7 +149,7 @@ Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));
|
||||
|
||||
### Explicit Intents
|
||||
|
||||
एक explicit intent उस क्लास नाम को निर्दिष्ट करता है जिसे यह लक्षित कर रहा है:
|
||||
एक explicit intent उस वर्ग नाम को निर्दिष्ट करता है जिसे यह लक्षित कर रहा है:
|
||||
```java
|
||||
Intent downloadIntent = new (this, DownloadService.class):
|
||||
```
|
||||
@ -161,30 +161,30 @@ context.startService(intent);
|
||||
```
|
||||
### Pending Intents
|
||||
|
||||
ये अन्य अनुप्रयोगों को **आपके अनुप्रयोग की ओर से क्रियाएँ करने** की अनुमति देते हैं, आपके ऐप की पहचान और अनुमतियों का उपयोग करते हुए। एक Pending Intent बनाने के लिए **एक इरादा और प्रदर्शन करने के लिए क्रिया को निर्दिष्ट किया जाना चाहिए**। यदि **घोषित इरादा स्पष्ट नहीं है** (यह नहीं बताता कि कौन सा इरादा इसे कॉल कर सकता है) तो एक **दुष्ट अनुप्रयोग घोषित क्रिया को पीड़ित ऐप की ओर से प्रदर्शन कर सकता है**। इसके अलावा, **यदि कोई क्रिया निर्दिष्ट नहीं की गई है**, तो दुष्ट ऐप **पीड़ित की ओर से कोई भी क्रिया कर सकेगा**।
|
||||
ये अन्य अनुप्रयोगों को **आपके अनुप्रयोग की ओर से क्रियाएँ करने** की अनुमति देते हैं, आपके ऐप की पहचान और अनुमतियों का उपयोग करते हुए। एक Pending Intent बनाने के लिए **एक इरादा और प्रदर्शन करने के लिए क्रिया को निर्दिष्ट किया जाना चाहिए**। यदि **घोषित इरादा स्पष्ट नहीं है** (यह नहीं बताता कि कौन सा इरादा इसे कॉल कर सकता है) तो **एक दुर्भावनापूर्ण अनुप्रयोग घोषित क्रिया को पीड़ित ऐप की ओर से कर सकता है**। इसके अलावा, **यदि कोई क्रिया निर्दिष्ट नहीं की गई है**, तो दुर्भावनापूर्ण ऐप **पीड़ित की ओर से कोई भी क्रिया कर सकेगा**।
|
||||
|
||||
### Broadcast Intents
|
||||
|
||||
पिछले इरादों के विपरीत, जो केवल एक ऐप द्वारा प्राप्त होते हैं, ब्रॉडकास्ट इरादे **कई ऐप द्वारा प्राप्त किए जा सकते हैं**। हालाँकि, API संस्करण 14 से, यह **संदेश प्राप्त करने वाले ऐप को निर्दिष्ट करना संभव है** Intent.set Package का उपयोग करके।
|
||||
पिछले इरादों के विपरीत, जो केवल एक ऐप द्वारा प्राप्त होते हैं, ब्रॉडकास्ट इरादे **कई ऐप द्वारा प्राप्त किए जा सकते हैं**। हालाँकि, API संस्करण 14 से, यह **संभव है कि उस ऐप को निर्दिष्ट किया जाए जिसे संदेश प्राप्त करना चाहिए** Intent.set Package का उपयोग करके।
|
||||
|
||||
वैकल्पिक रूप से, ब्रॉडकास्ट भेजते समय **एक अनुमति निर्दिष्ट करना भी संभव है**। रिसीवर ऐप को उस अनुमति की आवश्यकता होगी।
|
||||
|
||||
ब्रॉडकास्ट के **दो प्रकार** होते हैं: **सामान्य** (असिंक्रोनस) और **क्रमबद्ध** (सिंक्रोनस)। **क्रम** रिसीवर तत्व के **कॉन्फ़िगर की गई प्राथमिकता** पर आधारित है। **प्रत्येक ऐप ब्रॉडकास्ट को प्रोसेस, रिले या ड्रॉप कर सकता है।**
|
||||
ब्रॉडकास्ट के **दो प्रकार** होते हैं: **सामान्य** (असिंक्रोनस) और **क्रमबद्ध** (सिंक्रोनस)। **क्रम** रिसीवर तत्व के **कॉन्फ़िगर की गई प्राथमिकता** पर आधारित है। **प्रत्येक ऐप ब्रॉडकास्ट को संसाधित, पुनः प्रसारित या छोड़ सकता है।**
|
||||
|
||||
आप `Context` क्लास से `sendBroadcast(intent, receiverPermission)` फ़ंक्शन का उपयोग करके **ब्रॉडकास्ट** **भेजना** संभव है।\
|
||||
आप **`LocalBroadCastManager`** से **`sendBroadcast`** फ़ंक्शन का भी उपयोग कर सकते हैं, जो सुनिश्चित करता है कि **संदेश ऐप से कभी बाहर नहीं जाता**। इसका उपयोग करते समय आपको रिसीवर घटक को निर्यात करने की भी आवश्यकता नहीं होगी।
|
||||
आप `Context` क्लास से `sendBroadcast(intent, receiverPermission)` फ़ंक्शन का उपयोग करके **ब्रॉडकास्ट** **भेज** सकते हैं।\
|
||||
आप **`LocalBroadCastManager`** से **`sendBroadcast`** फ़ंक्शन का भी उपयोग कर सकते हैं जो सुनिश्चित करता है कि **संदेश ऐप से बाहर नहीं जाता**। इसका उपयोग करते समय आपको रिसीवर घटक को निर्यात करने की भी आवश्यकता नहीं होगी।
|
||||
|
||||
### Sticky Broadcasts
|
||||
|
||||
इस प्रकार के ब्रॉडकास्ट **भेजे जाने के लंबे समय बाद भी एक्सेस किए जा सकते हैं**।\
|
||||
इनका API स्तर 21 में डिप्रिकेट किया गया था और **इनका उपयोग न करने की सिफारिश की गई है**।\
|
||||
इस प्रकार के ब्रॉडकास्ट **भेजे जाने के लंबे समय बाद भी पहुंचा जा सकता है**।\
|
||||
इनका API स्तर 21 में निराधारित किया गया था और **इनका उपयोग न करने की सिफारिश की गई है**।\
|
||||
**ये किसी भी अनुप्रयोग को डेटा को स्निफ़ करने, बल्कि इसे संशोधित करने की अनुमति देते हैं।**
|
||||
|
||||
यदि आप "sticky" शब्द वाले फ़ंक्शंस जैसे **`sendStickyBroadcast`** या **`sendStickyBroadcastAsUser`** पाते हैं, तो **प्रभाव की जांच करें और उन्हें हटाने का प्रयास करें**।
|
||||
|
||||
## Deep links / URL schemes
|
||||
|
||||
Android अनुप्रयोगों में, **डीप लिंक** का उपयोग एक क्रिया (Intent) को सीधे एक URL के माध्यम से प्रारंभ करने के लिए किया जाता है। यह एक गतिविधि के भीतर एक विशिष्ट **URL स्कीम** घोषित करके किया जाता है। जब एक Android डिवाइस **इस स्कीम के साथ एक URL तक पहुँचने की कोशिश करता है**, तो अनुप्रयोग के भीतर निर्दिष्ट गतिविधि लॉन्च होती है।
|
||||
Android अनुप्रयोगों में, **डीप लिंक** का उपयोग एक क्रिया (Intent) को सीधे एक URL के माध्यम से आरंभ करने के लिए किया जाता है। यह एक गतिविधि के भीतर एक विशिष्ट **URL स्कीम** घोषित करके किया जाता है। जब एक Android डिवाइस **इस स्कीम के साथ एक URL तक पहुँचने की कोशिश करता है**, तो अनुप्रयोग के भीतर निर्दिष्ट गतिविधि लॉन्च होती है।
|
||||
|
||||
स्कीम को **`AndroidManifest.xml`** फ़ाइल में घोषित किया जाना चाहिए:
|
||||
```xml
|
||||
@ -215,17 +215,17 @@ android:host="example"
|
||||
|
||||
सीखें कि [HTML पृष्ठों का उपयोग किए बिना डीप लिंक कैसे कॉल करें](#exploiting-schemes-deep-links)।
|
||||
|
||||
## AIDL - Android इंटरफेस परिभाषा भाषा
|
||||
## AIDL - एंड्रॉइड इंटरफेस परिभाषा भाषा
|
||||
|
||||
**Android इंटरफेस परिभाषा भाषा (AIDL)** का उद्देश्य Android अनुप्रयोगों में **इंटरप्रोसेस संचार** (IPC) के माध्यम से क्लाइंट और सेवा के बीच संचार को सुविधाजनक बनाना है। चूंकि Android पर किसी अन्य प्रक्रिया की मेमोरी को सीधे एक्सेस करना अनुमति नहीं है, AIDL इस प्रक्रिया को सरल बनाता है, जिससे ऑब्जेक्ट्स को एक ऐसे प्रारूप में परिवर्तित किया जाता है जिसे ऑपरेटिंग सिस्टम समझता है, इस प्रकार विभिन्न प्रक्रियाओं के बीच संचार को आसान बनाता है।
|
||||
**एंड्रॉइड इंटरफेस परिभाषा भाषा (AIDL)** का उद्देश्य एंड्रॉइड अनुप्रयोगों में **इंटरप्रोसेस संचार** (IPC) के माध्यम से क्लाइंट और सेवा के बीच संचार को सुविधाजनक बनाना है। चूंकि एंड्रॉइड पर किसी अन्य प्रक्रिया की मेमोरी को सीधे एक्सेस करना अनुमति नहीं है, AIDL इस प्रक्रिया को ऑब्जेक्ट्स को एक ऐसे प्रारूप में मार्शल करके सरल बनाता है जिसे ऑपरेटिंग सिस्टम समझता है, इस प्रकार विभिन्न प्रक्रियाओं के बीच संचार को आसान बनाता है।
|
||||
|
||||
### प्रमुख अवधारणाएँ
|
||||
|
||||
- **बाउंड सेवाएँ**: ये सेवाएँ IPC के लिए AIDL का उपयोग करती हैं, जिससे गतिविधियाँ या घटक एक सेवा से बंध सकते हैं, अनुरोध कर सकते हैं, और प्रतिक्रियाएँ प्राप्त कर सकते हैं। सेवा की कक्षा में `onBind` विधि इंटरैक्शन शुरू करने के लिए महत्वपूर्ण है, इसे कमजोरियों की खोज में सुरक्षा समीक्षा के लिए एक महत्वपूर्ण क्षेत्र के रूप में चिह्नित किया गया है।
|
||||
- **बाउंड सेवाएँ**: ये सेवाएँ IPC के लिए AIDL का उपयोग करती हैं, जिससे गतिविधियाँ या घटक एक सेवा से बंध सकते हैं, अनुरोध कर सकते हैं और प्रतिक्रियाएँ प्राप्त कर सकते हैं। सेवा की कक्षा में `onBind` विधि बातचीत शुरू करने के लिए महत्वपूर्ण है, इसे कमजोरियों की खोज में सुरक्षा समीक्षा के लिए एक महत्वपूर्ण क्षेत्र के रूप में चिह्नित किया गया है।
|
||||
|
||||
- **मैसेंजर**: एक बाउंड सेवा के रूप में कार्य करते हुए, मैसेंजर IPC को सुविधाजनक बनाता है, जिसका ध्यान `onBind` विधि के माध्यम से डेटा को संसाधित करने पर है। किसी भी असुरक्षित डेटा हैंडलिंग या संवेदनशील कार्यों के निष्पादन के लिए इस विधि की निकटता से जांच करना आवश्यक है।
|
||||
- **मैसेंजर**: एक बाउंड सेवा के रूप में कार्य करते हुए, मैसेंजर IPC को सुविधाजनक बनाता है, जो `onBind` विधि के माध्यम से डेटा को संसाधित करने पर ध्यान केंद्रित करता है। किसी भी असुरक्षित डेटा हैंडलिंग या संवेदनशील कार्यों के निष्पादन के लिए इस विधि का निकटता से निरीक्षण करना आवश्यक है।
|
||||
|
||||
- **बाइंडर**: हालांकि बाइंडर क्लास का प्रत्यक्ष उपयोग AIDL के अमूर्तता के कारण कम सामान्य है, यह समझना फायदेमंद है कि बाइंडर विभिन्न प्रक्रियाओं की मेमोरी स्पेस के बीच डेटा ट्रांसफर को सुविधाजनक बनाने वाला एक कर्नेल-स्तरीय ड्राइवर है। आगे की समझ के लिए, एक संसाधन उपलब्ध है [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8)।
|
||||
- **बाइंडर**: हालांकि बाइंडर कक्षा का प्रत्यक्ष उपयोग AIDL के अमूर्तता के कारण कम सामान्य है, यह समझना फायदेमंद है कि बाइंडर विभिन्न प्रक्रियाओं की मेमोरी स्पेस के बीच डेटा ट्रांसफर को सुविधाजनक बनाने वाला एक कर्नेल-स्तरीय ड्राइवर है। आगे की समझ के लिए, एक संसाधन उपलब्ध है [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8)।
|
||||
|
||||
## घटक
|
||||
|
||||
@ -233,9 +233,9 @@ android:host="example"
|
||||
|
||||
### लॉन्चर गतिविधि और अन्य गतिविधियाँ
|
||||
|
||||
Android ऐप्स में, **गतिविधियाँ** स्क्रीन की तरह होती हैं, जो ऐप के उपयोगकर्ता इंटरफ़ेस के विभिन्न भागों को दिखाती हैं। एक ऐप में कई गतिविधियाँ हो सकती हैं, प्रत्येक एक अद्वितीय स्क्रीन प्रस्तुत करती है।
|
||||
एंड्रॉइड ऐप्स में, **गतिविधियाँ** स्क्रीन की तरह होती हैं, जो ऐप के उपयोगकर्ता इंटरफ़ेस के विभिन्न भागों को दिखाती हैं। एक ऐप में कई गतिविधियाँ हो सकती हैं, प्रत्येक एक अद्वितीय स्क्रीन प्रस्तुत करती है।
|
||||
|
||||
**लॉन्चर गतिविधि** ऐप का मुख्य गेटवे है, जो तब लॉन्च होती है जब आप ऐप के आइकन पर टैप करते हैं। इसे ऐप के मैनिफेस्ट फ़ाइल में विशिष्ट MAIN और LAUNCHER इंटेंट के साथ परिभाषित किया गया है:
|
||||
**लॉन्चर गतिविधि** ऐप का मुख्य गेटवे है, जो तब लॉन्च होती है जब आप ऐप के आइकन पर टैप करते हैं। इसे ऐप के मैनिफेस्ट फ़ाइल में विशिष्ट MAIN और LAUNCHER इरादों के साथ परिभाषित किया गया है:
|
||||
```html
|
||||
<activity android:name=".LauncherActivity">
|
||||
<intent-filter>
|
||||
@ -244,19 +244,19 @@ Android ऐप्स में, **गतिविधियाँ** स्क्
|
||||
</intent-filter>
|
||||
</activity>
|
||||
```
|
||||
सभी ऐप्स को एक लॉन्चर गतिविधि की आवश्यकता नहीं होती, विशेष रूप से उन ऐप्स को जिनका कोई उपयोगकर्ता इंटरफ़ेस नहीं होता, जैसे बैकग्राउंड सेवाएं।
|
||||
सभी ऐप्स को एक लॉन्चर गतिविधि की आवश्यकता नहीं होती, विशेष रूप से वे जो उपयोगकर्ता इंटरफ़ेस के बिना होते हैं, जैसे बैकग्राउंड सेवाएं।
|
||||
|
||||
गतिविधियों को अन्य ऐप्स या प्रक्रियाओं के लिए उपलब्ध कराया जा सकता है, यदि उन्हें मैनिफेस्ट में "निर्यातित" के रूप में चिह्नित किया जाए। यह सेटिंग अन्य ऐप्स को इस गतिविधि को प्रारंभ करने की अनुमति देती है:
|
||||
गतिविधियों को अन्य ऐप्स या प्रक्रियाओं के लिए उपलब्ध कराया जा सकता है, उन्हें मैनिफेस्ट में "निर्यातित" के रूप में चिह्नित करके। यह सेटिंग अन्य ऐप्स को इस गतिविधि को शुरू करने की अनुमति देती है:
|
||||
```markdown
|
||||
<service android:name=".ExampleExportedService" android:exported="true"/>
|
||||
```
|
||||
हालांकि, किसी अन्य ऐप से गतिविधि तक पहुंचना हमेशा एक सुरक्षा जोखिम नहीं होता है। चिंता तब होती है जब संवेदनशील डेटा गलत तरीके से साझा किया जा रहा हो, जो जानकारी के लीक का कारण बन सकता है।
|
||||
हालांकि, किसी अन्य ऐप से गतिविधि तक पहुंचना हमेशा एक सुरक्षा जोखिम नहीं होता है। चिंता तब होती है जब संवेदनशील डेटा गलत तरीके से साझा किया जा रहा हो, जिससे जानकारी लीक होने की संभावना होती है।
|
||||
|
||||
एक गतिविधि का जीवनचक्र **onCreate विधि के साथ शुरू होता है**, UI सेटअप करते हुए और उपयोगकर्ता के साथ बातचीत के लिए गतिविधि को तैयार करते हुए।
|
||||
|
||||
### एप्लिकेशन उपवर्ग
|
||||
|
||||
Android विकास में, एक ऐप के पास **Application** क्लास का एक **उपवर्ग** बनाने का विकल्प होता है, हालांकि यह अनिवार्य नहीं है। जब ऐसा उपवर्ग परिभाषित किया जाता है, तो यह ऐप के भीतर पहली क्लास बन जाती है जिसे इंस्टेंटिएट किया जाता है। यदि इस उपवर्ग में **`attachBaseContext`** विधि लागू की गई है, तो इसे **`onCreate`** विधि से पहले निष्पादित किया जाता है। यह सेटअप बाकी एप्लिकेशन शुरू होने से पहले प्रारंभिक प्रारंभ की अनुमति देता है।
|
||||
Android विकास में, एक ऐप के पास [Application](https://developer.android.com/reference/android/app/Application) वर्ग का **उपवर्ग** बनाने का विकल्प होता है, हालांकि यह अनिवार्य नहीं है। जब ऐसा उपवर्ग परिभाषित किया जाता है, तो यह ऐप के भीतर पहली कक्षा बन जाती है जिसे इंस्टेंट किया जाता है। यदि इस उपवर्ग में **`attachBaseContext`** विधि लागू की गई है, तो इसे **`onCreate`** विधि से पहले निष्पादित किया जाता है। यह सेटअप शेष एप्लिकेशन शुरू होने से पहले प्रारंभिक प्रारंभ की अनुमति देता है।
|
||||
```java
|
||||
public class MyApp extends Application {
|
||||
@Override
|
||||
@ -276,29 +276,29 @@ super.onCreate();
|
||||
|
||||
[Services](https://developer.android.com/guide/components/services) **बैकग्राउंड ऑपरेटिव्स** हैं जो बिना उपयोगकर्ता इंटरफेस के कार्यों को निष्पादित करने में सक्षम हैं। ये कार्य तब भी चलते रह सकते हैं जब उपयोगकर्ता विभिन्न अनुप्रयोगों में स्विच करते हैं, जिससे सेवाएँ **लंबी अवधि के संचालन** के लिए महत्वपूर्ण हो जाती हैं।
|
||||
|
||||
सेवाएँ बहुपरकारी हैं; इन्हें विभिन्न तरीकों से प्रारंभ किया जा सकता है, जिसमें **Intents** इन्हें लॉन्च करने का प्राथमिक तरीका है, जो एक अनुप्रयोग के प्रवेश बिंदु के रूप में कार्य करता है। एक बार जब `startService` विधि का उपयोग करके सेवा शुरू की जाती है, तो इसका `onStart` विधि सक्रिय हो जाती है और तब तक चलती रहती है जब तक कि `stopService` विधि को स्पष्ट रूप से नहीं बुलाया जाता। वैकल्पिक रूप से, यदि किसी सेवा की भूमिका एक सक्रिय क्लाइंट कनेक्शन पर निर्भर करती है, तो क्लाइंट को सेवा से जोड़ने के लिए `bindService` विधि का उपयोग किया जाता है, जो डेटा पास करने के लिए `onBind` विधि को सक्रिय करता है।
|
||||
सेवाएँ बहुपरकारी हैं; इन्हें विभिन्न तरीकों से प्रारंभ किया जा सकता है, जिसमें **Intents** इन्हें लॉन्च करने का प्राथमिक तरीका है, जो एक अनुप्रयोग के प्रवेश बिंदु के रूप में कार्य करता है। एक बार जब `startService` विधि का उपयोग करके सेवा शुरू की जाती है, तो इसकी `onStart` विधि सक्रिय हो जाती है और तब तक चलती रहती है जब तक कि `stopService` विधि को स्पष्ट रूप से नहीं बुलाया जाता। वैकल्पिक रूप से, यदि किसी सेवा की भूमिका एक सक्रिय क्लाइंट कनेक्शन पर निर्भर करती है, तो क्लाइंट को सेवा से जोड़ने के लिए `bindService` विधि का उपयोग किया जाता है, जो डेटा पास करने के लिए `onBind` विधि को सक्रिय करता है।
|
||||
|
||||
सेवाओं का एक दिलचस्प अनुप्रयोग बैकग्राउंड संगीत प्लेबैक या नेटवर्क डेटा फ़ेचिंग है, जो उपयोगकर्ता के ऐप के साथ इंटरैक्शन को बाधित किए बिना होता है। इसके अलावा, सेवाओं को **निर्यात** करके एक ही डिवाइस पर अन्य प्रक्रियाओं के लिए उपलब्ध कराया जा सकता है। यह डिफ़ॉल्ट व्यवहार नहीं है और इसके लिए Android Manifest फ़ाइल में स्पष्ट कॉन्फ़िगरेशन की आवश्यकता होती है:
|
||||
सेवाओं का एक दिलचस्प अनुप्रयोग बैकग्राउंड संगीत प्लेबैक या नेटवर्क डेटा फ़ेचिंग है जो उपयोगकर्ता के ऐप के साथ इंटरैक्शन को बाधित किए बिना होता है। इसके अलावा, सेवाओं को **निर्यात** करके एक ही डिवाइस पर अन्य प्रक्रियाओं के लिए उपलब्ध बनाया जा सकता है। यह डिफ़ॉल्ट व्यवहार नहीं है और इसके लिए Android Manifest फ़ाइल में स्पष्ट कॉन्फ़िगरेशन की आवश्यकता होती है:
|
||||
```xml
|
||||
<service android:name=".ExampleExportedService" android:exported="true"/>
|
||||
```
|
||||
### Broadcast Receivers
|
||||
|
||||
**Broadcast receivers** एक मैसेजिंग सिस्टम में श्रोता के रूप में कार्य करते हैं, जिससे कई एप्लिकेशन सिस्टम से समान संदेशों का उत्तर दे सकते हैं। एक ऐप **दो मुख्य तरीकों** से **एक रिसीवर को पंजीकृत** कर सकता है: ऐप के **Manifest** के माध्यम से या ऐप के कोड में **`registerReceiver`** API के माध्यम से **डायनामिकली**। Manifest में, ब्रॉडकास्ट को अनुमतियों के साथ फ़िल्टर किया जाता है, जबकि डायनामिकली पंजीकृत रिसीवर पंजीकरण के समय अनुमतियों को भी निर्दिष्ट कर सकते हैं।
|
||||
**Broadcast receivers** एक मैसेजिंग सिस्टम में श्रोता के रूप में कार्य करते हैं, जिससे कई एप्लिकेशन सिस्टम से एक ही संदेशों का जवाब दे सकते हैं। एक ऐप **दो मुख्य तरीकों** से **एक रिसीवर को रजिस्टर** कर सकता है: ऐप के **Manifest** के माध्यम से या ऐप के कोड में **`registerReceiver`** API के माध्यम से **डायनामिकली**। Manifest में, ब्रॉडकास्ट को अनुमतियों के साथ फ़िल्टर किया जाता है, जबकि डायनामिकली रजिस्टर किए गए रिसीवर रजिस्ट्रेशन के समय अनुमतियों को भी निर्दिष्ट कर सकते हैं।
|
||||
|
||||
**Intent filters** दोनों पंजीकरण विधियों में महत्वपूर्ण हैं, यह निर्धारित करते हैं कि कौन से ब्रॉडकास्ट रिसीवर को ट्रिगर करते हैं। एक बार जब एक मेल खाने वाला ब्रॉडकास्ट भेजा जाता है, तो रिसीवर का **`onReceive`** मेथड सक्रिय होता है, जिससे ऐप को प्रतिक्रिया देने की अनुमति मिलती है, जैसे कि कम बैटरी अलर्ट के जवाब में व्यवहार को समायोजित करना।
|
||||
**Intent filters** दोनों रजिस्ट्रेशन विधियों में महत्वपूर्ण होते हैं, यह निर्धारित करते हैं कि कौन से ब्रॉडकास्ट रिसीवर को ट्रिगर करते हैं। एक बार जब एक मेल खाने वाला ब्रॉडकास्ट भेजा जाता है, तो रिसीवर का **`onReceive`** मेथड सक्रिय होता है, जिससे ऐप को प्रतिक्रिया देने की अनुमति मिलती है, जैसे कि कम बैटरी अलर्ट के जवाब में व्यवहार को समायोजित करना।
|
||||
|
||||
ब्रॉडकास्ट **असिंक्रोनस** हो सकते हैं, जो सभी रिसीवर्स तक बिना क्रम के पहुँचते हैं, या **सिंक्रोनस**, जहाँ रिसीवर्स सेट प्राथमिकताओं के आधार पर ब्रॉडकास्ट प्राप्त करते हैं। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि किसी भी ऐप को ब्रॉडकास्ट को इंटरसेप्ट करने के लिए खुद को प्राथमिकता देने का जोखिम होता है।
|
||||
ब्रॉडकास्ट या तो **असिंक्रोनस** हो सकते हैं, जो सभी रिसीवर्स तक बिना क्रम के पहुँचते हैं, या **सिंक्रोनस**, जहाँ रिसीवर्स सेट प्राथमिकताओं के आधार पर ब्रॉडकास्ट प्राप्त करते हैं। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि किसी भी ऐप को ब्रॉडकास्ट को इंटरसेप्ट करने के लिए खुद को प्राथमिकता देने का जोखिम होता है।
|
||||
|
||||
एक रिसीवर की कार्यक्षमता को समझने के लिए, उसकी क्लास के भीतर **`onReceive`** मेथड को देखें। इस मेथड का कोड प्राप्त Intent को संशोधित कर सकता है, जिससे रिसीवर्स द्वारा डेटा सत्यापन की आवश्यकता को उजागर किया जाता है, विशेष रूप से **Ordered Broadcasts** में, जो Intent को संशोधित या छोड़ सकते हैं।
|
||||
एक रिसीवर की कार्यक्षमता को समझने के लिए, उसकी क्लास के भीतर **`onReceive`** मेथड को देखें। इस मेथड का कोड प्राप्त किए गए Intent को संशोधित कर सकता है, जिससे रिसीवर्स द्वारा डेटा सत्यापन की आवश्यकता को उजागर किया जाता है, विशेष रूप से **Ordered Broadcasts** में, जो Intent को संशोधित या छोड़ सकते हैं।
|
||||
|
||||
### Content Provider
|
||||
|
||||
**Content Providers** ऐप्स के बीच **संरचित डेटा** साझा करने के लिए आवश्यक हैं, डेटा सुरक्षा सुनिश्चित करने के लिए **अनुमतियों** को लागू करने के महत्व पर जोर देते हैं। वे ऐप्स को विभिन्न स्रोतों से डेटा तक पहुँचने की अनुमति देते हैं, जिसमें डेटाबेस, फ़ाइल सिस्टम, या वेब शामिल हैं। विशिष्ट अनुमतियाँ, जैसे **`readPermission`** और **`writePermission`**, पहुँच को नियंत्रित करने के लिए महत्वपूर्ण हैं। इसके अतिरिक्त, ऐप के मैनिफेस्ट में **`grantUriPermission`** सेटिंग्स के माध्यम से अस्थायी पहुँच प्रदान की जा सकती है, जिसमें `path`, `pathPrefix`, और `pathPattern` जैसे गुणों का उपयोग विस्तृत पहुँच नियंत्रण के लिए किया जाता है।
|
||||
**Content Providers** ऐप्स के बीच **संरचित डेटा** साझा करने के लिए आवश्यक हैं, डेटा सुरक्षा सुनिश्चित करने के लिए **अनुमतियों** को लागू करने के महत्व पर जोर देते हैं। वे ऐप्स को विभिन्न स्रोतों से डेटा तक पहुँचने की अनुमति देते हैं, जिसमें डेटाबेस, फ़ाइल सिस्टम, या वेब शामिल हैं। विशिष्ट अनुमतियाँ, जैसे **`readPermission`** और **`writePermission`**, पहुँच को नियंत्रित करने के लिए महत्वपूर्ण हैं। इसके अतिरिक्त, ऐप के मैनिफेस्ट में **`grantUriPermission`** सेटिंग्स के माध्यम से अस्थायी पहुँच प्रदान की जा सकती है, जिसमें विस्तृत पहुँच नियंत्रण के लिए `path`, `pathPrefix`, और `pathPattern` जैसे गुणों का उपयोग किया जाता है।
|
||||
|
||||
इनपुट सत्यापन कमजोरियों, जैसे SQL इंजेक्शन, को रोकने के लिए महत्वपूर्ण है। Content Providers बुनियादी संचालन का समर्थन करते हैं: `insert()`, `update()`, `delete()`, और `query()`, जो एप्लिकेशनों के बीच डेटा हेरफेर और साझा करने की सुविधा प्रदान करते हैं।
|
||||
इनपुट सत्यापन कमजोरियों को रोकने के लिए महत्वपूर्ण है, जैसे SQL इंजेक्शन। Content Providers बुनियादी संचालन का समर्थन करते हैं: `insert()`, `update()`, `delete()`, और `query()`, जो डेटा हेरफेर और ऐप्लिकेशनों के बीच साझा करने की सुविधा प्रदान करते हैं।
|
||||
|
||||
**FileProvider**, एक विशेष Content Provider, फ़ाइलों को सुरक्षित रूप से साझा करने पर केंद्रित है। इसे ऐप के मैनिफेस्ट में विशिष्ट गुणों के साथ परिभाषित किया गया है जो फ़ोल्डरों तक पहुँच को नियंत्रित करते हैं, जिसे `android:exported` और `android:resource` द्वारा फ़ोल्डर कॉन्फ़िगरेशन की ओर इंगित किया गया है। संवेदनशील डेटा को अनजाने में उजागर करने से बचने के लिए निर्देशिकाएँ साझा करते समय सावधानी बरतने की सलाह दी जाती है।
|
||||
**FileProvider**, एक विशेष Content Provider, फ़ाइलों को सुरक्षित रूप से साझा करने पर केंद्रित है। इसे ऐप के मैनिफेस्ट में विशिष्ट गुणों के साथ परिभाषित किया गया है जो फ़ोल्डरों तक पहुँच को नियंत्रित करते हैं, जिसे `android:exported` और `android:resource` द्वारा फ़ोल्डर कॉन्फ़िगरेशन की ओर इंगित किया जाता है। संवेदनशील डेटा को अनजाने में उजागर करने से बचने के लिए निर्देशिकाएँ साझा करते समय सावधानी बरतने की सलाह दी जाती है।
|
||||
|
||||
FileProvider के लिए उदाहरण मैनिफेस्ट घोषणा:
|
||||
```xml
|
||||
@ -323,38 +323,38 @@ For further information check:
|
||||
|
||||
## WebViews
|
||||
|
||||
WebViews **एंड्रॉइड ऐप्स** के अंदर **मिनी वेब ब्राउज़र** की तरह होते हैं, जो सामग्री को या तो वेब से या स्थानीय फ़ाइलों से खींचते हैं। इन्हें सामान्य ब्राउज़रों के समान जोखिमों का सामना करना पड़ता है, फिर भी कुछ विशेष **सेटिंग्स** के माध्यम से इन जोखिमों को **कम करने** के तरीके हैं।
|
||||
WebViews Android ऐप्स के अंदर **मिनी वेब ब्राउज़र्स** की तरह होते हैं, जो सामग्री को वेब या स्थानीय फ़ाइलों से खींचते हैं। इन्हें सामान्य ब्राउज़रों के समान जोखिमों का सामना करना पड़ता है, फिर भी कुछ विशेष **सेटिंग्स** के माध्यम से **इन जोखिमों को कम करने** के तरीके हैं।
|
||||
|
||||
एंड्रॉइड दो मुख्य WebView प्रकार प्रदान करता है:
|
||||
Android दो मुख्य WebView प्रकार प्रदान करता है:
|
||||
|
||||
- **WebViewClient** बुनियादी HTML के लिए अच्छा है लेकिन JavaScript अलर्ट फ़ंक्शन का समर्थन नहीं करता, जो XSS हमलों का परीक्षण करने के तरीके को प्रभावित करता है।
|
||||
- **WebChromeClient** पूर्ण Chrome ब्राउज़र अनुभव की तरह कार्य करता है।
|
||||
|
||||
एक महत्वपूर्ण बिंदु यह है कि WebView ब्राउज़र **कुकीज़** को डिवाइस के मुख्य ब्राउज़र के साथ **साझा नहीं करते**।
|
||||
एक महत्वपूर्ण बिंदु यह है कि WebView ब्राउज़र्स **कुकीज़** को डिवाइस के मुख्य ब्राउज़र के साथ **साझा नहीं करते**।
|
||||
|
||||
सामग्री लोड करने के लिए, `loadUrl`, `loadData`, और `loadDataWithBaseURL` जैसे तरीके उपलब्ध हैं। यह सुनिश्चित करना महत्वपूर्ण है कि ये URLs या फ़ाइलें **उपयोग के लिए सुरक्षित** हैं। सुरक्षा सेटिंग्स को `WebSettings` क्लास के माध्यम से प्रबंधित किया जा सकता है। उदाहरण के लिए, `setJavaScriptEnabled(false)` के साथ JavaScript को अक्षम करना XSS हमलों को रोक सकता है।
|
||||
|
||||
JavaScript "Bridge" Java ऑब्जेक्ट्स को JavaScript के साथ इंटरैक्ट करने की अनुमति देता है, जिसमें Android 4.2 से सुरक्षा के लिए विधियों को `@JavascriptInterface` के साथ चिह्नित करना आवश्यक है।
|
||||
JavaScript "Bridge" Java ऑब्जेक्ट्स को JavaScript के साथ इंटरैक्ट करने की अनुमति देता है, जिसके लिए Android 4.2 से सुरक्षा के लिए विधियों को `@JavascriptInterface` के साथ चिह्नित करना आवश्यक है।
|
||||
|
||||
सामग्री पहुंच की अनुमति देना (`setAllowContentAccess(true)`) WebViews को Content Providers तक पहुंचने की अनुमति देता है, जो एक जोखिम हो सकता है जब तक कि सामग्री URLs को सुरक्षित के रूप में सत्यापित नहीं किया जाता।
|
||||
सामग्री पहुंच की अनुमति देना (`setAllowContentAccess(true)`) WebViews को Content Providers तक पहुँचने की अनुमति देता है, जो एक जोखिम हो सकता है जब तक कि सामग्री URLs को सुरक्षित के रूप में सत्यापित नहीं किया जाता।
|
||||
|
||||
फ़ाइल पहुंच को नियंत्रित करने के लिए:
|
||||
|
||||
- फ़ाइल पहुंच को अक्षम करना (`setAllowFileAccess(false)`) फ़ाइल सिस्टम तक पहुंच को सीमित करता है, कुछ संपत्तियों के लिए अपवाद के साथ, यह सुनिश्चित करता है कि उन्हें केवल गैर-संवेदनशील सामग्री के लिए उपयोग किया जाए।
|
||||
- फ़ाइल पहुंच को अक्षम करना (`setAllowFileAccess(false)`) फ़ाइल सिस्टम तक पहुंच को सीमित करता है, कुछ संपत्तियों के लिए अपवाद के साथ, यह सुनिश्चित करते हुए कि इन्हें केवल गैर-संवेदनशील सामग्री के लिए उपयोग किया जाए।
|
||||
|
||||
## Other App Components and Mobile Device Management
|
||||
|
||||
### **Digital Signing of Applications**
|
||||
|
||||
- **Digital signing** एंड्रॉइड ऐप्स के लिए अनिवार्य है, यह सुनिश्चित करते हुए कि वे **प्रामाणिक रूप से लिखित** हैं। यह प्रक्रिया ऐप पहचान के लिए एक प्रमाणपत्र का उपयोग करती है और इसे इंस्टॉलेशन के समय डिवाइस के पैकेज प्रबंधक द्वारा सत्यापित किया जाना चाहिए। ऐप्स **स्वयं-हस्ताक्षरित या बाहरी CA द्वारा प्रमाणित** हो सकते हैं, जो अनधिकृत पहुंच से सुरक्षा प्रदान करते हैं और सुनिश्चित करते हैं कि ऐप डिवाइस पर डिलीवरी के दौरान बिना छेड़छाड़ के रहे।
|
||||
- **Digital signing** Android ऐप्स के लिए अनिवार्य है, यह सुनिश्चित करते हुए कि वे स्थापना से पहले **प्रामाणिक रूप से लिखित** हैं। यह प्रक्रिया ऐप पहचान के लिए एक प्रमाणपत्र का उपयोग करती है और स्थापना के समय डिवाइस के पैकेज प्रबंधक द्वारा सत्यापित की जानी चाहिए। ऐप्स **स्वयं-हस्ताक्षरित या बाहरी CA द्वारा प्रमाणित** हो सकते हैं, अनधिकृत पहुंच से सुरक्षा करते हुए और यह सुनिश्चित करते हुए कि ऐप डिवाइस पर डिलीवरी के दौरान बिना छेड़छाड़ के रहे।
|
||||
|
||||
### **App Verification for Enhanced Security**
|
||||
|
||||
- **Android 4.2** से शुरू होकर, **Verify Apps** नामक एक सुविधा उपयोगकर्ताओं को इंस्टॉलेशन से पहले ऐप्स की सुरक्षा की जांच करने की अनुमति देती है। यह **सत्यापन प्रक्रिया** उपयोगकर्ताओं को संभावित रूप से हानिकारक ऐप्स के खिलाफ चेतावनी दे सकती है, या यहां तक कि विशेष रूप से दुर्भावनापूर्ण ऐप्स के इंस्टॉलेशन को रोक सकती है, जिससे उपयोगकर्ता की सुरक्षा बढ़ती है।
|
||||
- **Android 4.2** से शुरू होकर, **Verify Apps** नामक एक सुविधा उपयोगकर्ताओं को स्थापना से पहले ऐप्स की सुरक्षा की जांच करने की अनुमति देती है। यह **सत्यापन प्रक्रिया** उपयोगकर्ताओं को संभावित हानिकारक ऐप्स के खिलाफ चेतावनी दे सकती है, या यहां तक कि विशेष रूप से दुर्भावनापूर्ण ऐप्स की स्थापना को रोक सकती है, उपयोगकर्ता सुरक्षा को बढ़ाते हुए।
|
||||
|
||||
### **Mobile Device Management (MDM)**
|
||||
|
||||
- **MDM समाधान** मोबाइल उपकरणों के लिए **निगरानी और सुरक्षा** प्रदान करते हैं **Device Administration API** के माध्यम से। इन्हें मोबाइल उपकरणों को प्रभावी ढंग से प्रबंधित और सुरक्षित करने के लिए एक एंड्रॉइड ऐप के इंस्टॉलेशन की आवश्यकता होती है। मुख्य कार्यों में **पासवर्ड नीतियों को लागू करना**, **स्टोरेज एन्क्रिप्शन को अनिवार्य करना**, और **दूरस्थ डेटा मिटाने की अनुमति देना** शामिल है, जो मोबाइल उपकरणों पर व्यापक नियंत्रण और सुरक्षा सुनिश्चित करता है।
|
||||
- **MDM समाधान** मोबाइल उपकरणों के लिए **निगरानी और सुरक्षा** प्रदान करते हैं **Device Administration API** के माध्यम से। इन्हें मोबाइल उपकरणों को प्रभावी ढंग से प्रबंधित और सुरक्षित करने के लिए एक Android ऐप की स्थापना की आवश्यकता होती है। प्रमुख कार्यों में **पासवर्ड नीतियों को लागू करना**, **स्टोरेज एन्क्रिप्शन को अनिवार्य करना**, और **दूरस्थ डेटा मिटाने की अनुमति देना** शामिल है, जो मोबाइल उपकरणों पर व्यापक नियंत्रण और सुरक्षा सुनिश्चित करता है।
|
||||
```java
|
||||
// Example of enforcing a password policy with MDM
|
||||
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
|
||||
@ -365,4 +365,106 @@ if (dpm.isAdminActive(adminComponent)) {
|
||||
dpm.setPasswordMinimumLength(adminComponent, 8);
|
||||
}
|
||||
```
|
||||
## AIDL / Binder सेवाओं की गणना और शोषण
|
||||
|
||||
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. Android एप्लिकेशन की संरचना
|
||||
3. Android एप्लिकेशन के प्रकार
|
||||
4. Android एप्लिकेशन के लिए सामान्य सुरक्षा चिंताएँ
|
||||
5. Android एप्लिकेशन में संवेदनशील डेटा का प्रबंधन
|
||||
6. Android एप्लिकेशन में सुरक्षा परीक्षण के तरीके
|
||||
7. 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. Mapping codes ↔ methods via onTransact()
|
||||
उस jar/odex को डिकंपाइल करें जो इंटरफेस को लागू करता है (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}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user