Pixnapping हमला

• Pixnapping एक नई अटैक तकनीक है जिसमें एक malicious Android app, दूसरे ऐप या वेबसाइट पर दिख रही व्यक्तिगत जानकारी को चुपके से चुरा सकता है
• यह हमला Android API और GPU hardware side channel का उपयोग करता है, और Google, Samsung जैसे प्रमुख निर्माताओं के अधिकांश नवीनतम डिवाइसों को प्रभावित करता है
• authentication code, chat, email जैसी स्क्रीन पर दिखने वाली कोई भी जानकारी उजागर हो सकती है, और यह हमला app permission के बिना भी संभव है
• Google Authenticator में 30 सेकंड के भीतर 2FA code चुराया जा सकता है
• Google और GPU vendor, दोनों के पास इस हमले को कम करने के लिए ठोस patch या countermeasure की कमी है

---

अवलोकन

• Pixnapping ऐसा हमला है जो malicious Android app को दूसरे ऐप या वेबसाइट पर दिख रही जानकारी, उपयोगकर्ता की जानकारी के बिना चुराने में सक्षम बनाता है
• Android API और GPU के side channel का दुरुपयोग करके जानकारी लीक की जाती है, और Google तथा Samsung डिवाइसों सहित अधिकांश हालिया Android smartphone इससे प्रभावित हैं
• पुष्टि किए गए प्रभावित ऐप्स में Gmail, Signal, Google Authenticator, Venmo, Google Maps शामिल हैं, और Google Authenticator के 2FA code भी 30 सेकंड के भीतर चुराए जा सकते हैं

शोध पत्र और डेमो

• इसे ACM CCS 2025 में “Pixnapping: Bringing Pixel Stealing out of the Stone Age” शोध पत्र के रूप में प्रस्तुत किया जाना तय है
• preprint के माध्यम से हमले के सिद्धांत और विस्तृत जानकारी देखी जा सकती है

प्रमुख प्रश्नोत्तर

कौन से डिवाइस प्रभावित हैं

• Android 13~16 चलाने वाले Google Pixel 6, 7, 8, 9, Samsung Galaxy S25 पर इसका प्रदर्शन किया गया
• अन्य निर्माताओं के डिवाइसों पर भी हमले का मूल सिद्धांत उसी तरह काम करने की संभावना अधिक है

हमले की शर्तें

• बिना permission वाले सभी Android app भी यह हमला चला सकते हैं
• app manifest file में अलग से कोई permission घोषित किए बिना भी यह काम करता है

कौन-सी जानकारी चुराई जा सकती है

• स्क्रीन पर दिखने वाली सारी जानकारी (chat, authentication code, email आदि) हमले का लक्ष्य बन सकती है
• स्क्रीन पर दिखाई न देने वाली आंतरिक जानकारी लीक नहीं की जा सकती

वास्तविक दुरुपयोग के मामले

• फिलहाल यह पुष्टि नहीं हुई है कि इसका वास्तविक दुरुपयोग हो रहा है या नहीं

उपयोगकर्ता कैसे सुरक्षित रहें

• हर नए Android security patch के आते ही उसे तुरंत install करने की सिफारिश की जाती है

डेवलपर कैसे सुरक्षा करें

• प्रभावी defense या workaround अभी तक पहचाने नहीं गए हैं
• यदि कोई security insight हो, तो शोधकर्ताओं से संपर्क करने का अनुरोध है

हमले के काम करने का तरीका

1. malicious app target app (जैसे Google Authenticator) को कॉल करता है ताकि संवेदनशील जानकारी render हो सके
2. target app की स्क्रीन पर विशिष्ट pixel पर graphic operation (जैसे blur) ज़बरदस्ती लागू किया जाता है
3. GPU.zip जैसे side channel का उपयोग कर चरण 2 के pixel को एक-एक करके निकाला जाता है

• चरण 2 और 3 को दोहराकर पूरे pixel को reconstruct किया जाता है, फिर OCR से मूल सामग्री निकाली जाती है
• इसका असर ऐसा है मानो malicious app उस स्क्रीन का screenshot ले रहा हो, जहाँ उसकी सामान्यतः पहुँच नहीं होनी चाहिए

दुरुपयोग किए गए Android API

• window blur API का उपयोग करके संवेदनशील pixel क्षेत्र पर graphic processing (blur) लागू की जाती है
• VSync callback के माध्यम से rendering time मापा जाता है, जिसे pixel extraction में इस्तेमाल किया जाता है

Google के patch और प्रतिक्रिया

• Google ने ऐप द्वारा कॉल की जाने वाली blur processing activity की संख्या सीमित करके प्रतिक्रिया दी, लेकिन जल्द ही उसका workaround मिल गया
• यह workaround फिलहाल non-public (embargo) स्थिति में है

hardware स्तर का side channel

• GPU.zip नामक GPU-आधारित side channel से pixel जानकारी निकाली जाती है
• अक्टूबर 2025 तक GPU निर्माताओं में से किसी ने अलग patch plan घोषित नहीं किया है

vulnerability identification information (CVE)

• इसे आधिकारिक तौर पर CVE-2025-48561 के रूप में दर्ज किया गया है

अन्य operating system पर प्रभाव

• Android इस हमले का लक्ष्य इसलिए बनता है क्योंकि ऐप्स दूसरे ऐप्स की screen data पर graphic operation कर सकते हैं और side effect को माप सकते हैं
• अन्य OS पर इसकी लागू होने की संभावना की पुष्टि नहीं हुई है

App List Bypass अतिरिक्त vulnerability

• एक app list bypass vulnerability भी है, जिसके ज़रिए बिना किसी अलग permission या manifest declaration के, डिवाइस में इंस्टॉल दूसरे ऐप्स की सूची पहचानी जा सकती है
• इसका उपयोग user profiling में किया जा सकता है, और यह पुराने bypass तरीकों से अलग, बिना अतिरिक्त declaration के काम करता है
• Google ने इसे “Infeasible” माना और बिना किसी अलग कार्रवाई के मामला बंद कर दिया

लोगो, source code और license

• Pixnapping का लोगो CC0 license के तहत स्वतंत्र रूप से उपयोग किया जा सकता है
• patch जारी होने के बाद source code GitHub(https://github.com/TAC-UCB/pixnapping) पर प्रकाशित किया जाएगा

प्रतिक्रिया और प्रमुख समयरेखा

• फ़रवरी 2025 से अक्टूबर 2025 के बीच Google और Samsung को चरणबद्ध तरीके से vulnerability disclose की गई और प्रतिक्रिया का अनुरोध किया गया
• Google ने Pixnapping और app list bypass के risk rating को High/Low के रूप में वर्गीकृत किया, और कुछ patch को अपर्याप्त या असंभव (Fix नहीं) माना
• दिसंबर 2025 की Android security bulletin में अतिरिक्त patch आने वाले हैं

सारांश

• Pixnapping ऐसा हमला है जो app permission संरचना और hardware व्यवहार की संयुक्त कमज़ोरियों का उपयोग करके वास्तविक स्क्रीन पर दिख रही महत्वपूर्ण जानकारी को अनुचित रूप से लीक कर सकता है
• Android software और hardware security, दोनों में संरचनात्मक सुधार की आवश्यकता है

[GN⁺]

Hacker News राय

• मेरे हिसाब से मूल समस्या यह है कि Android का permission system 백그라운드에서 실행 या 인터넷 접근 जैसी चीज़ों को user की अनुमति के बिना default रूप से allow करता है; ऐसे हमले इसलिए संभव हैं क्योंकि हर app—यहाँ तक कि offline game भी—default रूप से ये permissions रखता है। बहुत-से apps को internet access केवल "जब app इस्तेमाल हो रहा हो" तब ही मिलना चाहिए, और भले यह पूरी सुरक्षा न दे, लेकिन गलती से malicious app चला देने का जोखिम हमेशा रहता है, इसलिए इससे हमले की effectiveness काफ़ी घट सकती है.

  • यह जानने की जिज्ञासा है कि auto-update बनाम manual/no-update के risk profile पर कोई ठोस research है क्या, ख़ासकर Android जैसे half-sandboxed environment में defect rate की तुलना करने वाले अध्ययन.

  • वास्तव में internet access permission मौजूद है, और GrapheneOS में उस permission को declare करने वाले apps के लिए internet access को ही deny किया जा सकता है.

  • Android apps में internet access के लिए user permission क्यों नहीं माँगी जाती, इस पर एक काफ़ी convincing जवाब मौजूद है; यह Android dev team का सीधा जवाब है source। 백그라운드 실행 के मामले में Android 인텐트-based है, इसलिए app को किसी भी समय wake किया जा सकता है, और इस वजह से साधारण "background execution disallow" option वैसा काम नहीं कर सकता जैसा user उम्मीद करता है.

• वीडियो देखने के बाद भी यह समझना मुश्किल लग रहा है कि यह हमला वास्तव में कैसे काम करता है; app बदलने के बाद भी authenticator app के pixels तक access कैसे संभव है, यह सवाल है.

• app developer के नज़रिए से users की सुरक्षा कैसे की जाए, इस सवाल पर भले कहा गया है कि कोई public mitigation नहीं है, लेकिन मुझे लगता है कि कुछ basic कोशिशें की जा सकती हैं। जैसे passcode की position को screen पर fixed न रखना, background में छिपाना, code को लगातार move करना, color/contrast बदलना, static noise दिखाना, या पूरे code के बजाय उसके हिस्सों को थोड़ी देर blink कराना। हाँ, इससे UX पर कुछ असर पड़ेगा, लेकिन सिद्धांततः इससे attacker की मुश्किल काफ़ी बढ़ सकती है। हालांकि अगर screenshot में cached secret information पहले से मौजूद हो, तो इसकी सीमाएँ भी हैं.

  • याद है कि Google Authenticator ने कभी TOTP code को touch करने पर ही दिखाने वाला बदलाव किया था। उस समय लगा था कि इससे कोई असली threat नहीं रुकता और बस inconvenience बढ़ती है, और बहुत-से लोग सहमत भी थे, इसलिए वह feature जल्दी ही चुपचाप rollback हो गया। अब जिज्ञासा है कि कहीं वह इस vulnerability के लिए preemptive mitigation तो नहीं था.

  • unscreenshottable.vercel.app नाम का एक demo बताया गया है.

• TOTP के मामले में ज़ोर दिया गया है कि यह हमला व्यावहारिक होने के लिए font और pixel positions का पूरी तरह ज्ञात होना ज़रूरी है। paper के मुताबिक sensitive screen region चुराने में काफ़ी समय लगता है, और उदाहरण के लिए 2FA code आम तौर पर हर 30 सेकंड में refresh हो जाता है, इसलिए समय सीमा काफ़ी सख़्त है। अगर attacker 30 सेकंड के भीतर सभी 6 digits exfiltrate नहीं कर पाता, तो value गायब हो जाती है। लेकिन अगर font attacker को पता हो, तो कुछ pixels ही काफ़ी हो सकते हैं.

  • चूँकि आम तौर पर इस्तेमाल होने वाले authenticator apps बहुत कम हैं (Google, Microsoft Authenticator, Okta आदि), इसलिए यह व्यवहार में कोई बहुत बड़ी बाधा नहीं लगती.

• यह पहले से मौजूद तकनीक है, लेकिन highly targeted attack के लिए बहुत प्रभावी बताई गई है। अगर किसी target user के phone में कोई app install कराया जा सकता है, तो इतनी जटिलता के बिना भी वही app सीधे मनचाही जानकारी तक पहुँच सकता है। उदाहरण के लिए Facebook जैसा कोई app अगर privacy notice दिखाए कि "यह app समय-समय पर screen capture करता है", तो हैरानी की बात है कि बहुत-से लोग फिर भी allow कर देंगे। Pixnapping का source code patch उपलब्ध होने के बाद यहाँ publish करने की बात कही गई है, लेकिन सच कहें तो reverse engineering भी शायद बहुत मुश्किल नहीं होगी। patch आने तक इंतज़ार किया जा सकता था, लेकिन लगता है researchers जल्दी attention पाना चाहते थे.

  • असल vulnerability patch पहले से public है; इस commit के message में भी साफ़ लिखा है कि "windowों के बीच blur timing मापकर pixel theft रोका जाता है"। researchers code इसलिए नहीं जारी कर रहे क्योंकि उन्हें उस patch का bypass मिल गया है। साथ ही यह भी कहा गया है कि "GPU.zip के लिए patch का वादा करने वाला कोई GPU vendor नहीं है" और "Google भी app list bypass vulnerability को patch करने का इरादा नहीं रखता" ("Won't Fix" के रूप में बंद)। पहली disclosure date 24 फ़रवरी 2025 बताई गई है, तो researchers को जल्दबाज़ कहना ठीक नहीं होगा। और अगर "यह app समय-समय पर screen capture करता है" जैसा notice भी हो, तब भी जो screens explicitly screenshot-blocked हैं, उन्हें अलग exploit के बिना capture नहीं किया जा सकता.

  • Google को पहली रिपोर्ट 24 फ़रवरी 2025 को दी गई थी; काफ़ी समय दिया गया था.

• यह माना गया है कि हमला rendering time side channel का इस्तेमाल करने वाली एक clever technique है। यह भी कहा गया कि Google Authenticator जैसा target होने पर भी पूरा pixel set इकट्ठा करने में काफ़ी समय लगेगा। उल्टा चिंता यह है कि ऐसा तरीका text message से OTP चुराने में कितना लागू हो सकता है। GitHub notification email जैसे fixed-pattern phishing emails भी अब इतने बढ़ गए हैं कि email के भीतर links पर click करना ही बंद कर दिया है, और अब app खोलने के लिए सुझाए गए app intents का इस्तेमाल भी avoid करना चाहिए ऐसा लगने लगा है। बेहतर है app को सीधे खोला जाए और बेकार apps हटा दिए जाएँ। attack surface SDKs या web page intents के ज़रिए भी बढ़ सकता है, और यह अक्सर नज़रअंदाज़ होता है.

• सिर्फ title देखकर लगा था कि यह कोई web browser game है, इसलिए उसी हिसाब से खोजा था.

• मैं security expert नहीं हूँ, लेकिन अगर Windows desktop पर app install कर दिया जाए, तो Android के pixnapping से कहीं तेज़ और stealthy attack संभव लगता है। अगर कोई व्यक्ति एक ही password कई websites पर इस्तेमाल करता है, तो उनमें से कोई एक उसे चुराकर दूसरी जगह login कर सकती है, बशर्ते कोई अलग security layer न हो। सिद्धांत में यह कमज़ोर security है, लेकिन व्यवहार में ऐसे हमले इतने आम या आसान नहीं होते.

  • desktop पर sandboxing नहीं होती, जबकि mobile पर होती है; इसलिए mobile में sandbox escape अपने-आप में security breach है। ऊपर से desktop पर लोग हर fast-food app install नहीं करते, लेकिन mobile पर apps बहुत लापरवाही से install कर लेते हैं.

• पिछली चर्चा का लिंक साझा किया गया है.

  • पिछली चर्चा में बहुत-से लोगों की प्रतिक्रिया थी कि patch आ चुका है, इसलिए चिंता की बात नहीं; लेकिन इस मामले में कहा जा रहा है कि वह patch पूरी तरह काम नहीं करता.

• लगता है modern devices इतने जटिल हो चुके हैं कि complete security असंभव है। जिन features की ज़रूरत भी नहीं, वे लगातार जुड़ते जा रहे हैं और शायद इसी वजह से ऐसी समस्याएँ पैदा होती हैं। आगे चलकर FreeBSD जैसे minimal-feature, security-focused OS की माँग बढ़ेगी ऐसा विश्वास है.

  • ऐसी environment चाहिए जिसमें चलते-फिरते भी terminal पर make world किया जा सके.

  • Bunnie का बनाया हुआ Precursor है; काफ़ी cool है, लेकिन बहुत महँगा लगा। अगर $100 का calculator महँगा लगता है, तो Precursor आकार में भी लगभग वैसा ही है और computing power भी कुछ वैसी ही, लेकिन उसकी क़ीमत $1000 है, और उसे math exam में भी इस्तेमाल नहीं किया जा सकता। Precursor official blog (अभी accessible नहीं, बाद में खुल सकता है)

  • कई सालों तक hn comments पढ़ते हुए ऐसा महसूस हुआ है कि security knowledge और practices काफ़ी पीछे गए हैं, और generative AI के फैलाव से स्थिति और बिगड़ सकती है। आजकल fsf phone project जैसी बातों के साथ mobile banking apps की असुविधा की शिकायतें भी बहुत दिखती हैं। desktop पर हर 30 मिनट में password डालना झंझट है, यह भी लोग कहते हैं, और "क्या अब दो phones रखने पड़ेंगे" जैसी शिकायतें भी आती हैं। मेरी नज़र में अगर कोई चोर phone चुराने से पहले password enter करते देख ले, तो वह तुरंत banking app, money app खोलकर जितना संभव हो उतना data निकालने की कोशिश करेगा। ऐसे अपराध वास्तव में रोज़ होते हैं। इसलिए ऐसे apps को phone पर install ही न करना, या logged-in state में न रखना बेहतर है; 2FA apps पर भी यही लागू होता है। यह वैसा ही है जैसे महँगे branded travel luggage के साथ खुद को target बनाना। अगर आप CEO नहीं हैं या nation-state level target नहीं हैं, तब भी ज़्यादा सावधान रहना चाहिए। "minimal-feature security OS" device भी physical theft की मूल समस्या को पूरी तरह हल नहीं करता—यानी किसी ने password देख लिया और device चुरा लिया। लेकिन bar में games और ad apps वाले phone को banking, 2FA और कामकाजी use वाले phone से सख़्ती से अलग रखना चाहिए.