मोबाइल ऐप का छिपा हुआ API कैसे खोजें: mitmproxy, Frida और प्रॉक्सी 2026 में

```html

साइट Cloudflare द्वारा बंद है, Turnstile हर दूसरे अनुरोध पर प्रकट होता है, और लेआउट हर दो हफ्ते में बदलता है। जबकि उसी सेवा का एक मोबाइल एप्लिकेशन है, जो सीधे बैकएंड में जाता है और तैयार JSON प्राप्त करता है - बिना किसी चुनौती के, बिना किसी मार्कअप के, स्थिर फ़ील्ड स्कीमा के साथ। यही है "छिपा हुआ API": बिना दस्तावेज़ीकरण के, लेकिन पूरी तरह से कार्यात्मक इंटरफ़ेस, जिसका उपयोग आधिकारिक क्लाइंट करता है।

चरण-दर-चरण समझते हैं कि इसे mitmproxy की मदद से कैसे ढूंढना है, सर्टिफिकेट पिनिंग के साथ क्या करना है और क्यों स्केलिंग के चरण में बिना प्रॉक्सी के सब कुछ टूट जाता है।

एप्लिकेशन के ट्रैफ़िक में क्यों जाना चाहिए

वेब संस्करण को स्क्रैप करना और प्राइवेट API को कॉल करना - ये लागत के मामले में अलग-अलग कार्य हैं। तुलना करें:

• वेब। हेडलेस-ब्राउज़र, एंटी-बॉट को बायपास करना, HTML को पार्स करना, चयनकर्ताओं की नियमित मरम्मत की आवश्यकता है। एक अनुरोध = मेगाबाइट्स ट्रैफ़िक और सेकंडों की प्रोसेसर समय।
• प्राइवेट API। कुछ हेडर के साथ सामान्य HTTP अनुरोध, प्रतिक्रिया - टाइप किए गए फ़ील्ड के साथ संक्षिप्त JSON। अक्सर यह इंटरफ़ेस द्वारा प्रदर्शित डेटा से अधिक डेटा देता है: आंतरिक पहचानकर्ता, फ़्लैग, सेवा फ़ील्ड।

मोबाइल बैकएंड ऐतिहासिक रूप से वेब की तुलना में कमजोर सुरक्षा में होते हैं। कारण साधारण है: एंटी-बॉट प्लेटफ़ॉर्म ब्राउज़र ट्रैफ़िक के लिए तैयार किए गए हैं (JS-चुनौतियाँ, कैनवास, व्यवहारिक संकेत), और मोबाइल क्लाइंट उनके माध्यम से नहीं गुजरता। इसके बजाय, डेवलपर्स एप्लिकेशन के स्थिर कुंजी और TLS-पिनिंग पर भरोसा करते हैं - और दोनों को स्थानीय उपकरण पर हटाया जा सकता है।

क्या आवश्यक होगा

1. mitmproxy - ओपन-सोर्स HTTPS प्रॉक्सी इंटरसेप्टर (GitHub पर 44,000 से अधिक सितारे, वर्तमान शाखा 12.2.2 अप्रैल 2026 में जारी हुई, Python 3.12+ की आवश्यकता है)। इसे एक ही कमांड से स्थापित किया जा सकता है: pip install mitmproxy. यह HTTP/1, HTTP/2, HTTP/3, WebSocket और कच्चे TCP को समझता है, TLS 1.2 और 1.3 के साथ काम करता है।
2. Android डिवाइस या रूट के साथ एमुलेटर। प्रैक्टिस से पता चलता है कि Android 7–11 सबसे सुविधाजनक है: नए संस्करणों ने सर्टिफिकेट के साथ काम करना बहुत कठिन बना दिया है।
3. ADB डिवाइस के साथ संचार के लिए और Frida (pip install frida-tools) - यदि एप्लिकेशन सर्टिफिकेट को पिन करता है तो इसकी आवश्यकता होगी।

mitmproxy के पास एक ही इंजन के ऊपर तीन इंटरफेस हैं: mitmproxy (टर्मिनल TUI), mitmweb (वेब इंटरफेस, नए लोगों के लिए सुविधाजनक) और mitmdump (हेडलेस, स्क्रिप्ट और स्वचालन के लिए)।

चरण 1. इंटरसेप्टर को चालू करना

हम वेब इंटरफेस को इस तरह से चालू करते हैं कि यह बाहरी कनेक्शनों को सुनता है, न कि केवल localhost:

mitmweb --web-host 0.0.0.0

डिफ़ॉल्ट रूप से प्रॉक्सी पोर्ट 8080 पर चालू होती है। mitmproxy को पहली बार चालू करते समय, यह अपना खुद का प्रमाणपत्र प्राधिकरण बनाता है और कुंजी को ~/.mitmproxy निर्देशिका में रखता है। वहां चार फ़ाइलें बनेंगी: mitmproxy-ca.pem (प्रमाणपत्र के साथ निजी कुंजी), mitmproxy-ca-cert.pem (केवल प्रमाणपत्र), mitmproxy-ca-cert.p12 Windows के लिए और mitmproxy-ca-cert.cer - Android के लिए प्रारूप।

चरण 2. डिवाइस को प्रॉक्सी के माध्यम से निर्देशित करना

फोन की Wi-Fi सेटिंग्स में, हम मैनुअल प्रॉक्सी चुनते हैं: आपके कंप्यूटर का IP स्थानीय नेटवर्क में और पोर्ट 8080। इसके बाद, डिवाइस के ब्राउज़र में विशेष डोमेन mitm.it खोलते हैं - यह mitmproxy में निर्मित पृष्ठ है, जो प्लेटफ़ॉर्म को स्वचालित रूप से पहचानता है और प्रमाणपत्र के लिए आवश्यक प्रारूप के साथ निर्देश देता है।

iOS पर प्रक्रिया तीन भागों में होती है, और दूसरी आधी सभी भूल जाते हैं: Safari के माध्यम से प्रोफ़ाइल डाउनलोड करें, इसे "सेटिंग्स → सामान्य → VPN और डिवाइस प्रबंधन" में स्थापित करें, और फिर अलग से पूर्ण विश्वास चालू करें "सेटिंग्स → सामान्य → इस डिवाइस के बारे में → प्रमाणपत्रों पर विश्वास करें" में। अंतिम चरण के बिना, प्रमाणपत्र स्थापित है, लेकिन काम नहीं करेगा।

यदि Wi-Fi सेटिंग्स के साथ छेड़छाड़ करने का मन नहीं है, तो mitmproxy में एक VPN सर्वर मोड है: mitmweb --mode wireguard. डिवाइस स्टैंडर्ड WireGuard क्लाइंट के माध्यम से कनेक्ट होता है, और ट्रैफ़िक पारदर्शी रूप से इंटरसेप्ट होता है, बिना सिस्टम में प्रॉक्सी की मैनुअल सेटिंग के।

चरण 3. मुख्य दीवार - प्रमाणपत्र पर विश्वास

यहां अधिकांश प्रयास टूट जाते हैं। समस्याएँ दो हैं, और ये अलग-अलग समस्याएँ हैं।

कस्टम CA 2016 से मान्यता प्राप्त नहीं हैं

Android 7 Nougat (API 24) से शुरू होकर, एप्लिकेशन डिफ़ॉल्ट रूप से केवल सिस्टम प्रमाणपत्र संग्रह पर भरोसा करते हैं। यदि डेवलपर ने स्पष्ट रूप से इसे नेटवर्क सुरक्षा कॉन्फ़िग में अनुमति नहीं दी है - <certificates src="user" /> के माध्यम से ट्रस्ट एंकर में, तो कस्टम CA को नजरअंदाज किया जाता है। यह Google द्वारा हमले की सतह को कम करने के लिए एक जानबूझकर निर्णय था, और इसे फोन की सेटिंग्स से बायपास नहीं किया जा सकता। Chrome, वैसे, कस्टम प्रमाणपत्रों पर भी भरोसा नहीं करता। Android 11 में सीमाएँ और भी सख्त हो गई हैं।

व्यावहारिक निष्कर्ष: रूट वाले डिवाइस पर, mitmproxy का प्रमाणपत्र सिस्टम स्टोरेज में रखना चाहिए, न कि यूजर स्टोरेज में। यही कारण है कि रूट आवश्यकताओं की सूची में है, न कि "वांछनीय"।

सर्टिफिकेट पिनिंग

दूसरी दीवार - पिनिंग: एप्लिकेशन में अपेक्षित सर्वर प्रमाणपत्र का फ़िंगरप्रिंट होता है और यह किसी अन्य के साथ संवाद करने से इनकार करता है। यहां तक कि सिस्टम CA भी मदद नहीं करता। 2022 में ACM के अध्ययन ने दिखाया कि पिनिंग "उच्च जोखिम" क्षेत्रों (बैंक, टैक्सी, क्रिप्टो) में सामान्य है, लेकिन अक्सर अधूरा कार्यान्वित होता है और इसलिए इसे बायपास किया जा सकता है।

इस कार्य के लिए कई उपकरण हैं, और वे इसे अलग-अलग तरीके से हल करते हैं:

• Frida - रनटाइम में व्यवहार को संपादित करना: हम प्रमाणपत्र जांचने वाली फ़ंक्शंस को हुक करते हैं और उन्हें सफलता लौटाने के लिए मजबूर करते हैं। इस प्रक्रिया में एप्लिकेशन को संशोधित नहीं किया जाता है - यह सबसे लचीला विकल्प है। सामान्य प्रारंभ: frida -U -f com.target.app -l ssl_bypass.js --no-pause.
• apk-mitm - APK फ़ाइल से पिनिंग को स्वचालित रूप से स्थैतिक रूप से काटता है।
• android-unpinner - APK को पुनः संकलित करता है, Frida और पिनिंग को हटाने वाले स्क्रिप्ट को सम्मिलित करता है।
• objection - Frida के ऊपर एक टूलकिट, जो iOS और Android दोनों को संभालता है।
• ssl-kill-switch2 - iOS और macOS एप्लिकेशनों में पिनिंग को बंद करता है।

यदि कोई विशेष डोमेन मजबूती से पिन किया गया है और काम करने में बाधा डालता है, तो इसे ignore_hosts विकल्प के माध्यम से इंटरसेप्शन से बाहर रखा जा सकता है (जो नियमित अभिव्यक्ति को स्वीकार करता है) - ट्रैफ़िक mitmproxy के बिना डिक्रिप्शन के बिना जाएगा।

चरण 4. आवश्यक अनुरोध ढूंढना

इसके बाद - रूटीन। एप्लिकेशन खोलें, एक अर्थपूर्ण क्रिया (उत्पाद कार्ड खोलना, फ़ीड को स्क्रॉल करना, फ़िल्टर लागू करना) करें और देखें कि कौन से अनुरोध उत्पन्न हुए हैं। टर्मिनल इंटरफेस में यह जल्दी किया जाता है: Z स्ट्रीम सूची को साफ करता है, Enter चयनित अनुरोध को खोलता है, E इसे निर्यात करता है - जिसमें तैयार curl कमांड भी शामिल है।

इंटरसेप्ट किए गए अनुरोध में क्या खोजें:

• एंडपॉइंट और पैरामीटर। अक्सर, उनकी संख्या एप्लिकेशन के इंटरफेस द्वारा उपयोग की जाने वाली संख्या से अधिक होती है।
• क्लाइंट कुंजी। शैली का क्लासिक उदाहरण - एप्लिकेशन में एम्बेडेड स्थैतिक पहचानकर्ता। प्रसिद्ध MyAnimeList के सार्वजनिक API के विश्लेषण में, इस कुंजी के रूप में x-mal-client-id हेडर था, जिसका मान 6591a087c62b3e94d769cd8e35ffe909 था, जो api.myanimelist.net/v3/anime/season और /v3/anime के एंडपॉइंट्स तक पहुँच खोलता था, जिसमें दो दर्जन पैरामीटर थे।
• User-Agent. मोबाइल क्लाइंट के लिए यह विशिष्ट है और "पारस्परिकता" का एक हिस्सा है - उसी उदाहरण में यह MAL (ios, 139) है।
• टोकन और उनकी जीवनकाल। तुरंत देखें, कुंजी स्थिर है या अपडेट होती है: इससे आगे की संग्रहण वास्तुकला पर निर्भर करता है।

निर्यातित curl को कोड में बदलना curlconverter के माध्यम से सुविधाजनक है - आप तैयार अनुरोध प्राप्त करते हैं जो requests पर है, और फिर आप सामान्य HTTP क्लाइंट के साथ काम करते हैं, बिना किसी ब्राउज़र के।

चरण 5. स्केलिंग - और सब कुछ कहाँ टूटता है

इस स्थान पर निराशा आती है, जो सभी को परिचित है, जिन्होंने कोशिश की है: एक घरेलू IP से प्राइवेट API पहले आधे घंटे में शानदार प्रतिक्रिया देता है, और फिर 429 और 403 लौटाना शुरू कर देता है। मोबाइल बैकएंड क्लाइंट की नकल के लिए कमजोर सुरक्षा में होते हैं, लेकिन IP पर सीमाएँ अधिक कठोर होती हैं - सर्वर मानता है कि पते के पीछे एक फोन है, न कि बीस धागों में एक पार्सर।

यहां से व्यावहारिक निष्कर्ष हैं।

1. अनुरोधों के प्रोफ़ाइल को विश्वसनीय रखें। वास्तविक एप्लिकेशन प्रति सेकंड 50 अनुरोध नहीं करता है और सख्ती से अनुसूची के अनुसार नहीं चलता है। कॉल के क्रम का भी महत्व है: असली क्लाइंट पहले सत्र कॉन्फ़िगरेशन का अनुरोध करता है, फिर सामग्री।
2. पते के अनुसार लोड को फैलाएं। एक IP = एक "फोन"। रोटेशन रणनीतियों, जिटर के साथ देरी और एक्सपोनेंशियल बैकऑफ पर विस्तार से चर्चा की गई है कैसे प्रॉक्सी के माध्यम से API दर सीमाओं को बायपास करें पर।
3. भौगोलिक स्थिति पर विचार करें। कई मोबाइल API विभिन्न देशों के पते के आधार पर विभिन्न सामग्री और विभिन्न मूल्य प्रदान करते हैं - यह एक ही समय में एक सीमा और एक अवसर है।

डीबगिंग को mitmproxy से बाहर निकले बिना करना सुविधाजनक है: यह उच्चतर प्रॉक्सी से कनेक्ट करने में सक्षम है। कमांड mitmdump --mode upstream:http://example.com:8081 सभी ट्रैफ़िक को अपस्ट्रीम में मोड़ता है, और इसके लिए प्रमाणीकरण --upstream-auth विकल्प में username:password प्रारूप में सेट किया जाता है। इस तरह आप वही अनुरोध देख सकते हैं, जो पहले थे, लेकिन वे अब बाहरी पते से जा रहे हैं - आप तुरंत देख सकते हैं कि API किसी विशेष देश या IP प्रकार पर कैसे प्रतिक्रिया करता है।

मोबाइल API के लिए किस प्रकार की प्रॉक्सी लेनी चाहिए

यहाँ चयन अमूर्त नहीं है, यह इस पर निर्भर करता है कि आप कौन हैं।

• मोबाइल प्रॉक्सी - प्राथमिक विकल्प। आप एप्लिकेशन के ट्रैफ़िक की नकल करते हैं, और मोबाइल ऑपरेटर का पता बैकएंड के लिए पूरी तरह से स्वाभाविक दिखाई देता है: एक पते के पीछे CGNAT के कारण वास्तव में सैकड़ों ग्राहक होते हैं, इसलिए ऐसे IP पर सीमाएँ अधिक नरम होती हैं। मोबाइल 4G/LTE प्रॉक्सी उपयुक्त हैं।
• रिज़िडेंट प्रॉक्सी - कार्यशील मध्य, यदि मात्रा बड़ी है और ऑपरेटर से बंधन महत्वपूर्ण नहीं है: घरेलू IP प्रदाताओं का भौगोलिक कवरेज उचित मूल्य पर व्यापक है। यह रिज़िडेंट प्रॉक्सी है।
• डेटा सेंटर - केवल उन एंडपॉइंट्स के लिए जिनकी पते की गंभीरता की जांच नहीं होती है। उनका ASN तुरंत पहचाना जाता है, और मोबाइल बैकएंड पर यह अजीब लगता है: डेटा सेंटर में फोन नहीं होते।

छिपे हुए खतरे, जिनके बारे में बाद में पता चलता है

• HTTP/3. mitmproxy में QUIC का समर्थन है और यह डिफ़ॉल्ट रूप से सक्षम है, लेकिन वास्तविक मोबाइल ट्रैफ़िक पर यह सीमित है: अक्सर कनेक्शन को ALPN के साथ हेरफेर करके HTTP/2 पर मजबूर किया जाता है। QUIC सबसे अच्छा रिवर्स और WireGuard मोड में काम करता है।
• प्राइवेट API बिना चेतावनी के बदलता है। इसके पास पीछे की संगतता के लिए कोई बाध्यता नहीं है - यह एक आंतरिक इंटरफ़ेस है। एक बार User-Agent में एप्लिकेशन का संस्करण सेवा से बाहर हो जाएगा, और कलेक्टर चुपचाप खाली प्रतिक्रियाएँ प्राप्त करना शुरू कर देगा। केवल प्रतिक्रिया कोड नहीं, बल्कि JSON संरचना की निगरानी करें।
• "कुंजी मिली" और "अधिकार प्राप्त किया" में भ्रमित न हों। स्थैतिक क्लाइंट कुंजी - अनियंत्रित संग्रह के लिए अनुमति नहीं है।

कानूनी पक्ष के बारे में

अपने उपकरण पर ट्रैफ़िक को इंटरसेप्ट करना - एक कानूनी और दैनिक डिबगिंग प्रथा है, जिसका उपयोग मोबाइल डेवलपर्स और सुरक्षा विशेषज्ञ करते हैं। सीमाएँ आगे बढ़ती हैं: सेवा की शर्तों का पालन करें, कानूनी आधार के बिना व्यक्तिगत डेटा एकत्र न करें (EU में यह सीधे GDPR द्वारा विनियमित है), उन एंडपॉइंट्स को न छुएं जो दूसरों के प्रमाणीकरण की आवश्यकता रखते हैं, और सेवा के काम में बाधा न डालने के स्तर पर लोड रखें। व्यावहारिक मार्गदर्शक: यदि डेटा एप्लिकेशन में किसी भी उपयोगकर्ता को बिना लॉगिन के दिखाई देता है - आप अपेक्षाकृत सुरक्षित क्षेत्र में हैं; यदि पहुँच के लिए किसी अन्य खाते की आवश्यकता है - आप पहले से ही इसके बाहर हैं।

संक्षेप में

योजना कार्यशील है और एंटी-बॉट के साथ सप्ताहों की मेहनत को बचाती है: हम mitmproxy उठाते हैं, रूट वाले उपकरण के सिस्टम स्टोरेज में प्रमाणपत्र डालते हैं, आवश्यकता होने पर Frida के माध्यम से पिनिंग को हटा देते हैं, एक अर्थपूर्ण अनुरोध पकड़ते हैं, इसे curl में निर्यात करते हैं और Python पर फिर से लिखते हैं। इसके बाद "सुरक्षा को बायपास करना" श्रेणी से कार्य "लोड को सावधानीपूर्वक वितरित करना" में बदल जाता है - और इसे पते के रोटेशन, समझदारी से विराम और सही प्रकार की प्रॉक्सी के माध्यम से हल किया जाता है। शुरू करने के लिए सबसे आसान मोबाइल प्रॉक्सी के साथ है: वे उस ट्रैफ़िक के सबसे करीब हैं, जो बैकएंड देखना चाहता है।