Android जल्द ही on-device ADB को सीमित कर सकता है

 (kitsumed.github.io)
2 पॉइंट द्वारा GN⁺ 4 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Google की आधिकारिक घोषणा नहीं, बल्कि चल रहे IssueTracker feature request में ADB के मुख्य maintainer ने दुरुपयोग रोकने के लिए local connections को सीमित कर ADBD को केवल wlan0 पर bind करने का विकल्प उठाया है
  • अगर सिर्फ wlan0 की अनुमति दी जाती है, तो loopback address 127.0.0.1 का उपयोग करने वाला on-device ADB ही नहीं, VPN·Ethernet आधारित ADB और कई development environments भी काम करना बंद कर सकते हैं
  • यह चर्चा Wireless ADB authentication को पूरी तरह bypass करने वाले CVE-2026-0073 से शुरू हुई, जबकि मूल अनुरोध ADBD के receiving interface को चुनने की सुविधा देने का था ताकि वह सभी networks पर expose न हो
  • सामान्य malicious apps ADBD को सीधे शुरू नहीं कर सकतीं और न ही Wireless ADB pairing·TCP/IP approval को अपने आप पूरा कर सकती हैं, इसलिए उपयोगकर्ता की manual action के बिना ADB privileges पाना कठिन है
  • अगर loopback connection को स्थायी रूप से block किया जाता है, तो Shizuku और libadb-android आधारित tools प्रभावित होंगे; इसलिए ऐसा user-selectable setting चाहिए जिसे reboot के बाद भी बंद न किया जाए

आधिकारिक घोषणा नहीं, शुरुआती चर्चा

  • यह मामला Google की तय नीति या आधिकारिक घोषणा नहीं है, बल्कि चल रहे IssueTracker feature request और ADB के मुख्य maintainer की टिप्पणियों पर आधारित है
  • maintainer ने ऐसे मामलों का हवाला दिया जहाँ apps ने ADBD के local socket का उपयोग करके privileges बढ़ाए, और ADBD को Wi-Fi interface wlan0 पर ही bind करने का विकल्प उठाया
  • सार्वजनिक चर्चा में केवल विरोध, अपमान, या एक ही use case की बार-बार पुनरावृत्ति से बचना चाहिए
    • अगर आपका कोई अलग use case है, तो workflow, संबंधित links और technical trade-offs के साथ ठोस प्रतिक्रिया दी जा सकती है
    • अगर वही मामला पहले से दर्ज है, तो टिप्पणी दोहराने के बजाय +1 और notification feature का उपयोग करना बेहतर है
    • low-quality comments की बाढ़ आने पर issue lock हो सकता है या उपयोगी feedback और public updates कम हो सकते हैं

ADB के तीन connection तरीके

  • ADB एक protocol है जो Android devices को test और manage करने वाले developers और advanced users को high-privilege command access देता है
  • इसके मुख्य connection तरीके तीन हैं
    • USB: यह मूल तरीका है, जिसमें अलग computer से USB cable के जरिए device को सीधे जोड़ा जाता है
    • ADB TCP/IP: आमतौर 5555 port का उपयोग करता है, traffic plaintext में जाता है और YES/NO approval dialog से authentication होता है। इसे सक्रिय करने के लिए पहले से ADB connection होना चाहिए
    • Wireless Debugging: Android 11 में जोड़ा गया; इसमें code या QR code से computer pair करने के बाद authenticated और encrypted connection बनाया जाता है। इसे सक्रिय करने के लिए पहले से ADB connection की जरूरत नहीं होती

on-device ADB से बना ecosystem

  • सामान्य ADB में Android device के ADBD और अलग development computer के ADB client के बीच connection होता है, लेकिन कुछ developers बिना computer के सीधे Android device पर काम भी करते हैं
  • On-Device ADB कोई आधिकारिक शब्द नहीं है; इसका मतलब Termux जैसे terminal emulator में ADB client चलाकर उसी device के ADBD से connect करना है
    • इसमें ADB TCP/IP या Wireless Debugging का उपयोग होता है
    • क्योंकि client और server दोनों एक ही device पर होते हैं, इसलिए loopback address 127.0.0.1 का उपयोग होता है
  • यह तरीका libadb-android, Shizuku जैसे developers और advanced users के लिए बने open source projects की नींव है
  • ShizuCallRecorder Shizuku पर आधारित एक app है, जिसे disability से जुड़ी रोज़मर्रा की मुश्किलें कम करने के लिए बनाया गया है
    • एक user ने इस app का उपयोग अपने दिवंगत परिवार सदस्य के voicemail को सुरक्षित रखने के लिए किया
    • Android में call recording की मांग लंबे समय से रही है; Android 11 में इसे आधिकारिक feature के रूप में लाने की कोशिश हुई थी, लेकिन बाद में रद्द कर दी गई। अभी बंद-स्रोत या privacy risk वाले workaround apps भी मौजूद हैं
    • कुछ OEM ऐसे regions में भी call recording announcement voice को अनिवार्य करते हैं जहाँ इसकी कानूनी आवश्यकता नहीं है

interface selection अनुरोध और wlan0 सीमा

  • इस नए feature request का मूल उद्देश्य ADBD किस network interface पर listen करे, यह developer को चुनने देना है
  • इसकी पृष्ठभूमि में CVE-2026-0073 है, जो Wireless ADB authentication प्रक्रिया को पूरी तरह bypass कर सकता था
  • फिलहाल ADBD उन सभी networks पर accessible हो सकता है जिनसे phone जुड़ा हो, इसलिए interface selection feature exposure कम कर सकता है
  • लेकिन अगर सिर्फ wlan0 की अनुमति दी जाए, तो ये configurations टूट सकती हैं
    • loopback का उपयोग करने वाला on-device ADB
    • VPN के जरिए ADB
    • Ethernet के जरिए ADB
    • अन्य विशेष development environments
  • Android developers ने भी computer तक पहुँच न होने पर on-device ADB का उपयोग किया है

malicious apps के सामने मौजूद सीमाएँ

  • on-device ADB का उपयोग privilege escalation के लिए किया जा सकता है, लेकिन सामान्य malicious apps अपने दम पर connection स्थापित नहीं कर सकतीं

  • सामान्य Android users

    • अगर ADB disabled है, तो ADBD चलता ही नहीं
    • malicious app के पास WRITE_SECURE_SETTINGS permission भी नहीं होती, जिसे ADB के जरिए manually grant करना पड़ता है; इसलिए ADB attack शुरू करना आसान नहीं है

  • Android 11 या बाद के version पर Wireless ADB इस्तेमाल करने वाले developers

    • उपयोगकर्ता को खुद USB debugging और Wireless ADB चालू करना पड़ता है, तभी ADBD network interface पर listen करता है
    • app को connect करने के लिए उपयोगकर्ता को settings screen से one-time pairing code निकालकर देना पड़ता है, इसलिए app अकेले connection नहीं बना सकती

  • ADB TCP/IP इस्तेमाल करने वाले developers

    • उपयोगकर्ता को USB debugging चालू करनी होती है, USB ADB से TCP/IP सक्रिय करना होता है, और फिर cable हटानी होती है
    • app connection शुरू करे तो screen पर approval dialog आता है; उपयोगकर्ता No चुने तो request reject हो जाती है
    • सामान्य authenticated स्थिति में app उपयोगकर्ता को बताए बिना connect होकर हमला नहीं कर सकती

vulnerability risk और blocking का दायरा

  • सामान्य परिस्थितियों में malicious app ADBD को सीधे शुरू नहीं कर सकती, इसलिए connection की संभावना तभी बनती है जब developer device पर ADB इस्तेमाल कर रहा हो
  • अगर CVE-2026-0073 जैसी authentication bypass vulnerability हो, तो Wireless ADB और TCP/IP environments में abuse संभव हो सकता है
    • फिर भी उपयोगकर्ता को पहले USB debugging manually enable करनी होगी
    • TCP/IP तरीके में उपयोगकर्ता को ADB TCP/IP भी खुद चालू करना होगा
  • loopback connections को default रूप से block करने और उपयोगकर्ता को उसे वापस चालू करने का विकल्प दिए बिना स्थायी रूप से block करने, इन दोनों में फर्क है
  • device admin assignment या accessibility permissions भी उपयोगकर्ता की action से malicious apps को दी जा सकती हैं, लेकिन सिर्फ इस संभावना के आधार पर उन features को हटाया नहीं जाता

user choice बचाने वाला समझौता

  • loopback block ऐसा persistent setting होना चाहिए जिसे उपयोगकर्ता स्पष्ट रूप से disable कर सके
    • यह reboot के बाद भी बना रहना चाहिए, तभी Shizuku जैसे tools व्यवहारिक रूप से उपयोगी रहेंगे
    • संभव हो तो third-party apps setting state को पढ़ न सकें, ताकि banking apps या games की detection से बचने के लिए बार-बार setting बदलनी न पड़े
    • app को WRITE_SECURE_SETTINGS manually grant करने पर कुछ restrictions bypass की जा सकती हैं
  • उचित ढाँचा यह होगा कि उपयोगकर्ता security feature बंद करके on-device debugging की अनुमति दे, और साथ ही भविष्य की vulnerabilities के exposure का जोखिम भी स्वीकार करे
  • अगर on-device ADB को स्थायी रूप से block कर दिया गया, तो ऐसे niche open source ecosystem पर असर पड़ेगा

संबंधित पढ़ाई

2 टिप्पणियां

 
unsure4000 1 시간 전

छी...
 
GN⁺ 4 시간 전
Hacker News की राय

  • मैं आम तौर पर security सुधारों के पक्ष में हूँ, लेकिन यहाँ इसका व्यावहारिक लाभ लगभग नहीं दिखता। यह attack तभी संभव है जब user developer settings और remote ADB दोनों चालू करे, इसलिए 99.9% लोगों के लिए यह कोई वास्तविक attack path नहीं है, और बाकी 0.1% आम तौर पर जानते हैं कि वे क्या कर रहे हैं
    किसी खास interface या IP तक access सीमित करने वाला बदलाव ठीक है, लेकिन developers को localhost तक सीमित करने की अनुमति दी जानी चाहिए। ऐसा ज़ोरदार एहसास होता है कि Shizuku और Canta जैसी चीज़ों को collateral damage की तरह दिखाकर ब्लॉक करने की कोशिश हो रही है

    • अब software में security लगभग आपदा बन चुकी है। हर मामूली site 2-factor authentication मांगती है, हर कुछ घंटों में logout कर देती है, और agent को unlimited mode में चलाने के लिए disable sandbox तक टाइप करने पर भी mobile पर काम नहीं करता
      Firefox में unsigned extensions इंस्टॉल ही नहीं किए जा सकते, उसके लिए Developer Edition चाहिए; sites passkeys थोपती हैं; और एक S3 bucket पर भी access control, service identity, IAM, OAuth की दर्जनों परतें चिपकी होती हैं। headless devices पर न चलने वाला OAuth, TOTP की जगह dedicated app मांगने वाले bank, VPN blocking, बच्चों की सुरक्षा के नाम पर real-name surveillance, और यह कहकर open-weight models पर रोक लगाने की कोशिश कि data चीन चला जाएगा—यह सब जारी है
      convenience·usability·privacy·modifiability·openness से ऊपर security को हमेशा सर्वोच्च, पूर्ण मूल्य बना दिया गया है, और IT security industry को इस पर शर्म आनी चाहिए
    • सिर्फ developer settings और remote ADB भी काफी नहीं हैं। सामान्य Android builds में connect करते समय client key approval फिर से user से मांगा जाता है
      यह बदलाव user security के लिए नहीं बल्कि corporate हितों की रक्षा के लिए ज़्यादा लगता है
    • iPhone के बाद security feature के रूप में पेश किए गए कई बदलाव असल में device functionality हटाना थे
      शुरुआत में कहा गया कि App Store के बिना सिर्फ Safari इस्तेमाल करो, और मुझे लगता है कि इसकी जड़ Steve Jobs की वही खास सनक थी जिसमें वह cancer treatment के दौरान भी ऐसे medical devices को शरीर से लगाना पसंद नहीं करते थे जिनका design सुंदर न हो। “perfect” device को “गंदी” चीज़ों से बचाने वाला वह रवैया बाद में security की भाषा में जायज़ ठहराया गया
      उस समय कहा जाता था कि malware से भरे Windows 98 जैसी हालत से बचना है, लेकिन आधुनिक operating systems उस दौर के Windows की कमजोर security से बहुत आगे निकल चुके हैं
    • मैं Android apps deploy कर चुका developer हूँ, और एक बार screen टूट जाने पर device तक पहुँच नहीं सका क्योंकि पेचीदा remote ADB toggle बंद था। developer settings और remote ADB दोनों का एक साथ चालू होना वास्तविक दुनिया में इतना दुर्लभ है कि इसे attack path के रूप में लगभग नज़रअंदाज़ किया जा सकता है
    • “malicious actor सामान्य स्थिति में ADB connection नहीं पा सकता” — यह इस पर निर्भर करता है कि आप malicious actor को कैसे परिभाषित करते हैं
      Shizuku-आधारित rootless privacy tools को रोकने का उद्देश्य device owner नहीं बल्कि सरकार की security है। EU Digital Identity Wallet जैसे trusted execution environment applications और आगे चलकर बच्चों की सुरक्षा के नाम पर मांगी जाने वाली सुविधाएँ, इस धारणा पर बहुत निर्भर करती हैं कि user device के साथ छेड़छाड़ नहीं कर सकता या unapproved software इंस्टॉल नहीं कर सकता। Intel SGX का क्या हुआ, यह सब जानते हैं

  • ADB restriction बिल्कुल स्वाभाविक अगला कदम है। भले यह प्रस्ताव ज्यों का त्यों पास न हो, Google पहले ही सामान्य personal computing tasks को भी device-internal या USB·wireless developer interfaces पर निर्भर बना चुका है
    कभी न कभी ऐसी स्थिति आ सकती है जहाँ meaningful तरीके से Android इस्तेमाल करने के लिए identity सौंपनी पड़े और वार्षिक शुल्क देना पड़े, वरना गंभीर सीमाएँ झेलनी पड़ें। Google नहीं चाहता कि Android apps नियंत्रित distribution channels के बाहर develop हों, और जब उसने सामान्य व वैध sideloading पर रोक लगाने वाले बदलावों से पीछे हटना बंद कर दिया, तभी खेल लगभग खत्म हो गया था
    call recording warning भी Google की जिम्मेदारी है। manufacturers ने अपने बेहतर custom dialers छोड़कर Google Dialer अपनाया, इसलिए यह उन क्षेत्रों में भी एकसमान लागू हो गया जहाँ कानूनी बाध्यता नहीं थी। खासकर MediaTek SoC पर, जहाँ स्थिर third-party apps के जरिए recording को hardware स्तर पर support नहीं मिलता, यह और भी परेशान करने वाला है
    आखिरकार यह इस बात का सबूत है कि मैं अपने “अपने” device का मालिक नहीं हूँ, और कुछ साल बाद शायद Gemini स्वीकृत surveillance path के जरिए calls सुनकर उनका summary भी दे दे

    • मेरे मामले में बात अलग है। यह post GNU/Linux smartphone Librem 5 से भेजा गया है
    • अगर आप उस device पर अपना operating system इंस्टॉल कर सकते हैं, तो आप उसके मालिक हैं। Google ने इसे लगातार allow किया है, इसलिए रोकने वाले दूसरे manufacturers पर गुस्सा होना चाहिए

  • मैं जानना चाहता हूँ कि क्या वैध उपयोगों के लिए वैकल्पिक साधन भी दिए जा रहे हैं। अगर functionality हटाई जाती है और कोई alternative नहीं दिया जाता, तो developers को ज़्यादा कमजोर या कभी-कभी नियम तोड़ने वाले workarounds की तरफ धकेला जाएगा

  • यह प्रतिक्रिया गलतफहमी से उपजी बहुत बड़ी overreaction लगती है। मैं remote ADB से development के दौरान Android project के नए builds इंस्टॉल करता हूँ, logs लाता हूँ, और अभी Tailscale VPN के जरिए connect कर रहा हूँ
    लेकिन मौजूदा तरीका ऐसा है कि connect होने वाले हर public Wi‑Fi पर authentication से पहले की vulnerabilities तक उजागर हो सकती हैं। अगर इसे सिर्फ Tailscale interface तक सीमित किया जा सके, तो यह उल्टा सुधार होगा
    प्रस्ताव का सार यह है कि remote ADB सेट करते समय सभी interfaces पर bind करने के बजाय किस interface पर bind करना है, यह चुना जाए। इसमें localhost को reject करने की कोई बात नहीं है, और सिर्फ wlan0 पर bind करने वाला छोटा-सा प्रस्ताव VPN से कम भरोसेमंद है, इसलिए साफ़ तौर पर गलत था और शायद वास्तविक implementation दिशा भी नहीं है

  • अगर thread spam की वजह से Google developers issue को lock कर दें और feedback को ignore करें, तब भी अभी से कोई फर्क नहीं पड़ेगा। अगर सिर्फ आलोचना ही परेशान कर रही है, तो कीमती feedback भी lock किया जा सकता है, इसलिए बेझिझक समर्थन जताया जा सकता है

    • policy criticism और Reddit भीड़ के सामूहिक हमले में फर्क होना चाहिए
    • यह मान लेना कि Google developers ने बस कोई महत्वपूर्ण use case मिस कर दिया या गलत समझ लिया, और उन्हें बता देने भर से वे पुनर्विचार करेंगे—सच कहूँ तो यह अपमानजनक धारणा है
    • जैसे ही ऐसी post HN या Reddit पर आती है, किसी की राय बदलने की संभावना लगभग खत्म हो जाती है, और GitHub issue भी जल्द spam हो सकता है
      Google कभी-कभी app developers की feedback लेता है, लेकिन ऐसे workaround पर निर्भर open source developers की तुलना में अपने internal teams के फैसले को ज़्यादा महत्व देना स्वाभाविक है
      ADB daemon को इस तरह design किया गया था कि apps loopback address पर ADB session खोलकर call recording संभव बना दें—यह स्पष्ट रूप से उसका उद्देश्य नहीं था। https://xkcd.com/1172/ फिर याद आ गया
      इसका मतलब यह नहीं कि developers का इस बदलाव को नापसंद करना गलत है। Google ने dialer में call recording जोड़ी भी है, इसलिए मैं उस feature का समर्थन करता हूँ, लेकिन इसका यह भी मतलब नहीं कि ADB team को security hardening नहीं करनी चाहिए

  • जब Google ने पहली बार sideloading restrictions की घोषणा की थी, तब लोगों ने कहा था, “फिर भी ADB तो है”, और इसका विरोध करने वालों को कड़ी आलोचना झेलनी पड़ी थी
    अब ADB को enable करने वाले workaround का भी इंतज़ार करना पड़ेगा, और Android काफ़ी समय से iOS से ज़्यादा खुला नहीं रहा है। यह रुझान आगे भी जारी रहेगा
    क्योंकि यह Google की सोच का गैर-तकनीकी समस्या है, इसलिए इसका हल किसी तकनीकी समाधान से नहीं निकलेगा

    • जिस पल hardware remote attestation लाया गया, उसी पल Android की उम्मीद लगभग खत्म हो गई थी
      भले ही आप अपना software install कर सकें, डिवाइस को “tampered” माना जाएगा। अगर attestation fail हो जाए, तो आप trusted नहीं माने जाएंगे और communication, banking, streaming, gaming जैसी डिजिटल समाज की लगभग हर अहम जगह से बाहर कर दिए जाएंगे, यानी दूसरे दर्जे के नागरिक बन जाएंगे
      यही Android का भविष्य है, और क्योंकि कुछ कंपनियों ने चमत्कारिक रूप से GrapheneOS की attestation keys पर भरोसा करना शुरू किया है, इसलिए GrapheneOS आख़िरी उम्मीद है। अगर वह उम्मीद भी खत्म हो गई, तो बेहतर होगा कि iPhone ही खरीद लिया जाए
    • इस सोच को नियंत्रित करने वाली डोर Google management और board से भी बहुत आगे तक जाती है। Carpenter की क्लासिक रचना का OBEY याद आता है

  • यह तो होना ही था। अगली बार अगर 24 घंटे वाली sideloading restriction अनिश्चितकालीन कर दी जाए, तब भी लोग शायद चौंकेंगे

    • उससे पहले कोई व्यावहारिक विकल्प उभरता है या नहीं, इसी पर इस बात की संभावना काफ़ी निर्भर करेगी कि इसे अनिश्चितकालीन restriction में बदला जाएगा या नहीं
      पूरे बाज़ार पर कब्ज़ा करना ज़रूरी नहीं है; इतना काफ़ी है कि Google हिचके या कानूनी रूप से इसे लागू करना मुश्किल हो जाए। यह कुछ वैसा होगा जैसा Chrome के मुकाबले Firefox की आदर्श भूमिका है

  • Android का इस हद तक lock down होना गंभीर चेतावनी संकेत है। वे उन चीज़ों को एक-एक करके धीरे-धीरे हटा रहे हैं, जिन्होंने Android को अच्छा बनाया था

  • चिंता है कि जल्द ही वेबसाइटों के साथ भी यही हो सकता है। Apple डिवाइस पर साइट खोलने देने के लिए Apple को, और Android डिवाइस पर Google को मासिक शुल्क देना पड़ सकता है

    • remote attestation मांगने वाला नया reCAPTCHA पहले से ही उसी दिशा में है
      https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
      अभी शुल्क नहीं है, लेकिन Google को यह तय करने की ताकत मिल जाएगी कि किन डिवाइसों को काफ़ी वेबसाइटों तक पहुँचने दिया जाए
    • web दो हिस्सों में बँट सकता है। एक नया web, जहाँ बड़े प्रमुख sites पैसे देकर मौजूद होंगी, और एक पुराना web, जहाँ पहुँचने के लिए unrestricted browser वाले personal PC का मालिक होना ज़रूरी होगा
      यह भी काफ़ी संभव है कि पुराने web की content को AI कंपनियाँ बड़े पैमाने पर scrape करके नए web के ज़रिये आम लोगों तक फिर से पहुँचाएँ
    • Netflix जैसी video streaming services में यह पहले से कुछ हद तक हो रहा है। आपको सीधे भुगतान नहीं करना पड़ता, लेकिन open source browser इस्तेमाल नहीं कर सकते

  • smartphone के लिए Linux की ज़रूरत है। अगर banking browser से हो सके, तो app की ज़रूरत नहीं, लेकिन wireless communication device और Sonos·Spotify जैसे अहम apps चलने चाहिए

    • UK के कई banks अब न web portal देते हैं, न offline branches
      banking और public utilities जैसी ज़रूरी services के लिए ठीक से काम करने वाला web environment अनिवार्य करने वाला क़ानून चाहिए। नहीं तो मौजूदा duopoly और मज़बूत होगा
      मुझे भी web service देने वाली कंपनियों को चुनकर उन्हें और सक्रिय रूप से support करना चाहिए
    • Android·LineageOS·GrapheneOS की सिफ़ारिश करना ठीक नहीं है, और Sailfish में भी proprietary components बहुत हैं, इसलिए उसे छोड़ना बेहतर है। सबसे अच्छा विकल्प postmarketOS है, Mobian वगैरह पर भी विचार किया जा सकता है, जबकि Ubuntu Touch और UBports निराशाजनक रहे
      postmarketOS wiki में compatible devices देखकर यह जाँचा जा सकता है कि क्या आपके पास पहले से मौजूद डिवाइस supported है, और संभव हो तो support बेहतर बनाने में योगदान दिया जा सकता है। अगर नहीं, तो eBay पर अच्छी support status वाला पुराना device मिल सकता है
      Librem 5 और PinePhone की support काफ़ी अच्छी है, लेकिन OnePlus 6T जैसे पुराने Android devices price-to-performance के हिसाब से बेहतर हो सकते हैं। खरीदने से पहले यह ज़रूर देखना चाहिए कि मुख्य features काम करते हैं या नहीं
      लोकप्रिय Android apps को Waydroid से चलाया जा सकता है
    • banking websites और native apps के बीच feature parity की मांग होनी चाहिए। मेरा bank remote cheque deposit सिर्फ app में support करता है, और पुराने devices पर app नहीं चलता, इसलिए मुझे PayPal इस्तेमाल करना पड़ता है
    • सभी smartphones में unlockable bootloader होना चाहिए। तब और ज़्यादा operating systems आ सकेंगे
    • आजकल banks “security” का हवाला देकर apps थोप रहे हैं, और app के बिना काम करना लगभग असंभव हो गया है
      विकल्प के तौर पर SMS authentication भी सुरक्षित नहीं है और धीरे-धीरे खत्म हो रहा है; security के लिहाज़ से यह सही दिशा है, लेकिन इस्तेमाल करने लायक दूसरे साधन बहुत कम हैं