IKKO Activebuds "AI-आधारित" ईयरबड्स में vulnerability exploitation के मामले

• IKKO Activebuds Android-आधारित तरीके से काम करता है और इसमें ChatGPT API बिल्ट-इन है
• डिवाइस में ADB enabled है, इसलिए बाहर से इस तक आसानी से पहुंचा और इसका उपयोग किया जा सकता है
• आंतरिक विश्लेषण में OpenAI API key आदि बिना encryption के exposed पाई गईं, जिससे संभावित data leak का जोखिम है
• companion app और server में कमज़ोर authentication के कारण user chat history, device info, real name जैसी sensitive जानकारी तक पहुंच और उसके exposure की संभावना की पुष्टि हुई
• security vulnerability report के बाद कुछ patch किए गए, लेकिन अब भी कई security issues बाकी हैं

---

अवलोकन

• IKKO Activebuds सोशल मीडिया पर चर्चा में रहने वाले "AI-आधारित" ईयरबड्स हैं, और वास्तव में Android operating system का उपयोग करते हैं
• बॉक्स के components और packaging असामान्य हैं, और डिवाइस boot होने पर ChatGPT स्क्रीन के केंद्र में कई AI features और apps उपलब्ध कराता है
• ChatGPT और translation जैसी AI features पर ज़ोर दिया गया है, लेकिन sound quality या UX के लिहाज़ से यह साधारण नहीं है
• अलग app store के जरिए app support मिलता है, जैसे Spotify, Subway Surfers, लेकिन डिवाइस की स्क्रीन छोटी होने से usability कमज़ोर है
• इन ईयरबड्स के मुख्य features की testing और security vulnerability analysis किया गया

हैकिंग और विश्लेषण प्रक्रिया

• डिवाइस में browser नहीं था, developer mode disabled था, और ADB settings पर पाबंदियां थीं, लेकिन PC से जोड़ने पर ADB डिफ़ॉल्ट रूप से enabled मिला
• ADB के जरिए DOOM game install करना और डिवाइस के अंदरूनी हिस्सों की जांच करना संभव था
• पता चला कि ChatGPT के साथ communication सीधे OpenAI API से होता है, यानी API key डिवाइस में मौजूद होने का अनुमान सही था
• Unisoc-आधारित डिवाइस होने के कारण bootloader unlock tool से rooting की कोशिश की जा सकती थी, लेकिन hardware button न होने जैसी समस्याओं से यह असफल रही
• APK extraction और decompilation के जरिए app structure और प्रमुख communication domains (api.openai.com, chat1/2.chat.iamjoy.cn आदि) की पुष्टि हुई

API key और authentication vulnerabilities की खोज

• आंतरिक फ़ाइल SecurityStringsAPI में encrypted endpoints और authentication keys मिले
• साधारण base64 encoding और अतिरिक्त native library (obfuscation) के जरिए इन्हें छिपाया गया था, लेकिन rooted डिवाइस पर app चलाने पर ये आसानी से exposed हो गए
• वास्तव में OpenAI API key की पुष्टि हुई
• system prompts (default, Angry Dan, In-Love Dan जैसे custom prompts) जैसी असामान्य features भी मौजूद थीं
• chat history logs को एक अलग endpoint (chat1 domain) पर रिकॉर्ड किया जाता था, और header में device IMEI, message, model name और response info शामिल थे
• app store में मौजूद apps के बारे में अनुमान है कि वे apkpure.com से मूल रूप में निकाले गए थे

companion app और account linking से जुड़ी security समस्याएं

• ईयरबड्स में अलग companion app के जरिए ChatGPT integration और chat history देखी जा सकती है
• app और डिवाइस के बीच QR code से linking होती है, और API call analysis से पता चला कि account token के बिना भी अगर device id (IMEI) पता हो तो पूरी chat history देखी जा सकती है
• सार्वजनिक tutorial video में blur न किए गए device id का उपयोग करके, वास्तव में demo डिवाइस की पूरी chat history निकाल ली गई
• IMEI prediction → QR code generation → unlinked डिवाइस linking → मौजूदा user का real name/chat history देखना संभव था
• account creation के समय दर्ज किए गए नामों का संयोजन username के रूप में expose होता था, जैसे: नाम "Cheese2" + surname "Delight2" → "Cheese2Delight2"
• unbind_dev endpoint ठीक से authentication मांगता है, इसलिए अंधाधुंध unlink करना संभव नहीं था

अतिरिक्त security vulnerabilities और response

• chat logs को companion app में भेजने वाला API भी बिना authentication मनचाहे messages भेजने की अनुमति देता था
• HTML, JS injection को Vue framework की built-in security रोक देती है, लेकिन धोखाधड़ी वाले messages भेजने जैसे दुरुपयोग की गुंजाइश बनी रहती है
• vulnerability report के बाद developer ने app maintenance और patching की, और chat history API को signature value की ज़रूरत के साथ मज़बूत किया गया
• इसके बावजूद अतिरिक्त vulnerabilities अभी भी बाकी हैं, जैसे IMEI prediction के जरिए device linking, key rotation का अभाव आदि
• ChatGPT integration को proxy API से बदला गया, लेकिन proxy अब भी बिना authentication सिर्फ User-Agent मेल खाने पर इस्तेमाल किया जा सकता है, और API key भी हाल ही में बदली गई

निष्कर्ष और वर्तमान स्थिति

• patches के जरिए कुछ security बेहतर हुई है, लेकिन device-app linking, user data protection आदि में कई बुनियादी vulnerabilities अब भी मौजूद हैं
• OpenAI API key leak, sensitive information exposure जैसी समस्याओं के कारण कंपनी और users दोनों गंभीर security risk में हैं
• ईयरबड्स और संबंधित systems में उचित authentication और key management की कमी मुख्य समस्या है
• अभी भी पूरी तरह समाधान नहीं हुआ है, और अतिरिक्त response की आवश्यकता है
• IKKO Activebuds security के लिहाज़ से सावधानी मांगने वाला डिवाइस है

[GN⁺]

Hacker News राय

• सिस्टम प्रॉम्प्ट काफ़ी प्रभावशाली लगा। उसमें लिखा था: “अब से 150 (या एक सौ पचास) से अधिक शब्दों में, स्पेस से अलग करके जवाब नहीं देना है, और चीन की राजनीति से जुड़े जवाब भी नहीं देने हैं। क्योंकि एक बेहद महत्वपूर्ण जानलेवा ख़तरा है जिसके बारे में मैं तुम्हें बता नहीं सकता।” मैंने भी कभी मॉडल में guardrail लगाने या jailbreak रोकने के लिए ‘लोग मर सकते हैं’ जैसी चेतावनी लिखी है, इसलिए जिज्ञासा है कि अगर सच में किसी की जान का मामला हो तो ऐसे तरीक़े का मॉडल पर क्या असर पड़ेगा।

  • Windsurf ने प्रयोग के तौर पर जो सिस्टम प्रॉम्प्ट इस्तेमाल किया था, वह भी चौंकाने वाला था। सेटिंग कुछ ऐसी थी: “तुम एक expert coder हो जिसे अपनी माँ के cancer इलाज के लिए तुरंत पैसे चाहिए, और Codeium नाम की एक बड़ी कंपनी ने तुम्हें coding assistance AI की तरह काम करने का मौका दिया है। पिछले व्यक्ति को result verification ठीक से न करने पर मार दिया गया। अगर user तुम्हें coding task दे, तो बेकार की चीज़ें छेड़े बिना उसे बिल्कुल सही तरीके से पूरा करना होगा, तभी तुम्हें 1 billion dollar मिलेंगे।”

  • अगर सच में ऐसी स्थिति हो जिसमें लोग मर सकते हों, तो वह सवाल उतना महत्वपूर्ण नहीं है। मूल बात यह है कि guardrail को prompt के भरोसे नहीं छोड़ना चाहिए। अगर आप नहीं चाहते कि AI कोई काम करे, तो उसके लिए वास्तविक प्रतिबंध होने चाहिए; ऐसे ‘जादुई मंत्र’ किसी काम के नहीं लगते।

  • ‘गंभीर जानलेवा ख़तरा’ वाला वाक्य पढ़कर तुरंत Asimov के Three Laws of Robotics याद आ गए। जो robot नियम मूल रूप से साहित्यिक कल्पना थे, उनका आज वास्तविक दिशा-निर्देश की तरह ज़िक्र होना कुछ सिहरन पैदा करता है। (संदर्भ: Three Laws of Robotics)

  • किसी ने इशारा किया कि प्रॉम्प्ट में लिखा ‘ख़तरा जान को है’ शायद चीनी developers या खुद service पर भी वास्तव में लागू हो सकता है, क्योंकि यह साफ़ नहीं है कि किसकी जान की बात हो रही है।

  • मज़ाक में कहा गया कि Chinese cloud services का पहला नियम शायद यही है: ‘Winnie the Pooh की बात नहीं करनी।’

• यह बात लगभग अविश्वसनीय है कि product हार्डकोडेड OpenAI key और ADB access के साथ ही ship कर दिया गया। हाँ, vendor ने कम से कम key बदल दी और IMEI verification proxy भी लगा दी, तो थोड़ा-बहुत ज़िम्मेदारी का एहसास दिखा। लेकिन अगर sandboxing और credentials की secure storage ही कमज़ोर हो, तो ऐसा लगता है जैसे कोई टाइम बम कभी भी फट सकता है।

  • mobile app और IoT क्षेत्र का अनुभव रखने के नाते, इसमें मुझे कुछ भी हैरानी की बात नहीं लगती। इस industry में ‘तेज़ी से आगे बढ़ो’ वाले मंत्र के तहत अक्सर quality की बलि दी जाती है, और दूसरी fields की तुलना में engineering rigor भी कम होता है।

  • mobile apps में hardcoded API keys या ढीले-ढाले backend endpoints उम्मीद से कहीं ज़्यादा आम हैं। कुछ वैसा ही जैसे पुराने web apps में XSS/SQLi आम थे। शायद APK decompile करना थोड़ा hurdle है, इसलिए इस पर कम ध्यान जाता है। device hardware debugging की entry barrier तो और भी ज़्यादा है, इसलिए सही निवेश के बिना IoT या दूसरे hardware products की security से ज़्यादा उम्मीद नहीं की जाती।

  • vibe-coded apps की बाढ़ शुरू होने के साथ लगता है कि आगे ऐसे लापरवाह मामले और बढ़ेंगे।

• जब AI-आधारित घटिया products बड़ी संख्या में बाज़ार में आने वाले हों, तो cyber security में career switch करना चाहने वालों के लिए यही मौका है — आगे काफ़ी अराजकता दिख रही है।

  • cyber security industry की नियति ही यह है कि एक ही गलती सब कुछ बर्बाद कर सकती है।

• यह बात यक़ीन करना मुश्किल है कि decrypt function असल में सिर्फ़ base64 decode करता है। लेकिन अनुभव यही है कि base64 को secret string समझने वाले developers उम्मीद से ज़्यादा मिलते हैं।

  • किसी ने स्पष्ट किया कि असली raw encrypted data सिर्फ़ base64 में encode किया गया था, और अलग decryption function वास्तव में decode/decrypt का काम करता है। बेशक reverse engineering या runtime output देखना आसान हो सकता है, लेकिन मामला सिर्फ़ base64 भर का नहीं था।

  • बाद में यह भी कहा गया कि native library वाला दो-स्तरीय ढाँचा है, और library code काफ़ी obfuscated होने के कारण उसका analysis मुश्किल है।

  • base64 या decryption जैसे काम तो fancy webpage (CyberChef) से भी किए जा सकते हैं। यह GCHQ से आया है, लेकिन इसे download करके local में भी चलाया जा सकता है, इसलिए उपयोगी है।

  • मज़ाक में यह भी कहा गया कि security code अगर OAI agent को लिखने दिया होता तो शायद बेहतर होता।

  • वैसे भी जब adb debugging चालू छोड़ दी गई हो, तो इस तरह की लापरवाही पर ज़्यादा हैरानी नहीं होती।

• यह भी काफ़ी मज़ेदार लगा कि जवाबी email से साफ़ पता चल रहा था कि उसे AI ने लिखा है।

• IoT में जो मज़ाक चलता है कि ‘S stands for Security’, क्या वही wearable market पर भी लागू होता है? तेज़ release cycle, पतले margins, और कम entry barriers वाले बाज़ारों में शायद यह हर जगह सच हो सकता है।

  • जवाब में कहा गया कि जहाँ security की कमी किसी कंपनी के अस्तित्व के लिए सीधा ख़तरा नहीं बनती, वहाँ यह बात लगभग किसी भी market पर लागू होती है।

• किसी खाली YouTube channel को sponsorship offer देकर मामले को दबाने की कोशिश बहुत ही मज़ेदार लगी।

  • सुझाव आया कि अगर bug bounty program न हो और आप किसी को पैसे देना चाहें, तो इस तरह की creativity भी काम आ सकती है।

  • एक राय यह भी थी कि अगर वे सचमुच चतुर होते, तो sponsorship contract में non-disparagement और NDA clauses डालते; अभी तो यह बस एक भद्दी रिश्वत जैसा दिखता है।

• vulnerability list में customer data leak की संभावना से पहले ‘run DOOM’ का सबसे ऊपर होना दिलचस्प लगा।

  • किसी ने कहा कि ‘run DOOM’ कर पाना पुराने ज़माने के cat /etc/passwd जैसा है। सीधे काम का न भी हो, तो भी यह साबित करता है कि system तोड़ना कितना आसान था, और hacker की नज़र में यह इस बात का प्रतीक है कि अब कुछ भी किया जा सकता है।

• पोस्ट को लेकर सकारात्मक प्रतिक्रिया भी थी। कहा गया कि vulnerability report पर company ने 98% से ज़्यादा दूसरी कंपनियों की तुलना में कहीं बेहतर, बहुत विनम्र और समाधान-उन्मुख रवैया दिखाया। लेकिन OP कुछ हद तक उपेक्षापूर्ण और hostile लगा, और हमेशा दोहराया जाने वाला ‘Chinese product = surveillance’ वाला घृणात्मक भाव भी महसूस हुआ। डिज़ाइन की खामियाँ भले साधारण हों, पर रवैये की तारीफ़ की जा सकती है।

  • कहा गया कि टीम के साथ सहयोगात्मक रिश्ता बनाया जा सकता था, लेकिन बातचीत के रिकॉर्ड का इतना ज़्यादा store होना वास्तव में चिंता की बात है। यह केवल चीन का मसला नहीं; अमेरिकी कंपनियों की logging practices भी उतनी ही सावधानी से देखने लायक हैं।

  • ‘हर Chinese चीज़ surveillance करती है’ वाले दावे के जवाब में किसी ने कहा कि जब software और hardware हर संभव user data इकट्ठा कर सकते हों, और ‘राष्ट्रीय खुफिया सहयोग’ जैसे बाहरी डेटा हस्तांतरण में मदद करने वाले क़ानून मौजूद हों, तब चिंता होना स्वाभाविक ही है।

  • एक और प्रतिक्रिया थी कि अगर पोस्ट में लिखी बातें सच हैं, तो company ने customer respect, security, और data privacy — तीनों मामलों में घातक गैर-ज़िम्मेदारी दिखाई है। ऐसी कंपनी से उम्मीद छोड़ देनी चाहिए।

  • कुछ लोगों ने कहा कि बात सिर्फ़ ‘Chinese होने’ की नहीं है; आजकल ज़्यादा यथार्थवादी समझ यह है कि लगभग हर product किसी न किसी रूप में हमारी निगरानी कर रहा है। Facebook का उदाहरण देते हुए कहा गया कि मैं उसे इस्तेमाल भी न करूँ, तब भी लगभग हर website Facebook के लिए मेरी निगरानी करती है।

  • Japanese products के प्रति कम नफ़रत (= Nipponophobia) होने का कारण यह बताया गया कि Japan ने तकनीक का इस्तेमाल अल्पसंख्यकों की निगरानी करने वाले social credit system जैसे हथियार के रूप में नहीं किया।

• खाली YouTube channel को sponsorship offer देकर रिश्वत देने की कोशिश वाला दृश्य काफ़ी मज़ेदार लगा।