IKKO Activebuds "AI-आधारित" earbuds की कमजोरियों के दुरुपयोग के मामले

 (blog.mgdproductions.com)
1 पॉइंट द्वारा GN⁺ 2025-07-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • स्क्रीन वाला earbuds case असल में लगभग एक Android device जैसा निकला, और ADB enabled होने के कारण app extraction, sideloading और API analysis तक रास्ता खुल गया
  • ChatGPT integration device से सीधे OpenAI API से communicate कर रहा था, और launcher app के SecurityStringsAPI तथा obfuscated native library को bypass करने पर API key और system prompt exposed हो गए
  • companion app और server API में सिर्फ device id/IMEI से chat history देखी जा सकती थी, इसलिए tutorial video में दिखे demo device ID से पूरी demo chat history निकाली जा सकी
  • arbitrary IMEI से QR code बनाने पर unbound device को app से connect किया जा सकता था, और पहले से bound devices के लिए error response में account का name combination सामने आ जाता था
  • IKKO ने inspection और app/device updates के जरिए chat lookup में signature header जोड़ा, लेकिन 13 जनवरी 2025 के update तक proxy API सिर्फ okhttp/4.9.0 User-Agent मांगता था और पुरानी ChatGPT API key तभी जाकर बदली गई

स्क्रीन वाले earbuds case की असली पहचान

  • IKKO Activebuds एक earbuds-type device है जिसके case screen पर time और ChatGPT को प्रमुखता से रखा गया है
  • यह translation जैसी AI features भी देता है, और IKKO store से apps install किए जा सकते हैं
  • Google Play Store नहीं है, और CEO ने बताया कि ऐसा इसलिए है क्योंकि apps को ActiveBuds screen के हिसाब से modify किया गया है
  • store में Spotify जैसे music apps और Subway Surfers जैसे game apps थे, लेकिन छोटी screen की वजह से navigation असुविधाजनक था
  • apps की मौजूदगी और उनके चलने से confirm हुआ कि device Android चला रहा है
  • default EQ profile की sound quality अच्छी नहीं थी, और review के मुताबिक EQ curve को manually adjust करने पर इसे usable level तक बेहतर किया जा सकता था

ADB enabled होने से खुला analysis path

  • device में browser नहीं था, इसलिए दूसरे apps सीधे download करना मुश्किल था; Android settings app खोला जा सकता था, लेकिन build number को 7 बार tap करने पर भी developer mode on नहीं हुआ
  • PC से connect करने पर ADB enabled मिला, जिससे app sideloading संभव हो गई
  • DOOM sideload करने के बाद यह देखना शुरू किया गया कि ChatGPT integration backend में कैसे काम करता है
  • root के बिना system certificate install नहीं हो सकता था, इसलिए सिर्फ HTTP inspection से exact URL देखना मुश्किल था, लेकिन app extraction और decompile से जरूरी जानकारी मिल गई
  • Spreadtrum/Unisoc devices में default signing key इस्तेमाल होने पर bootloader unlock tool इस्तेमाल किया जा सकता था, और यह device भी उसी category में था
    • हालांकि device में volume up key नहीं थी, इसलिए unlock confirmation screen पार नहीं की जा सकी
    • खुद sign किए गए partitions flash करने का तरीका संभव माना गया, लेकिन आगे नहीं बढ़ाया गया

APK के अंदर दिखे domains और keys

  • APK extraction tool से app dump करके launcher app को JADX में खोलने पर communication domains सामने आए
    • api.openai.com: OpenAI API
    • chat1.chat.iamjoy.cn: ChatGPT के अलावा app store आदि device-wide functions के लिए API जैसा लगा, और browser में खोलने पर login page दिखा
    • chat2.chat.iamjoy.cn: chat1 जैसा ही लगा, और backup server होने की संभावना थी
    • openspeech.bytedance.com: speech recognition backup होने का अनुमान था, लेकिन device communication confirm नहीं हुआ
    • www.airdimple.cn: OpenAI API mirror या proxy जैसा लगा
  • SecurityStringsAPI file में encrypted endpoints और authentication keys थे
  • पहला step base64 था, और दूसरा step काफी obfuscated native library संभालती थी
  • एक दूसरे rooted device पर app sideload करने पर app वैसे ही चल गया, और इस process में OpenAI key की पुष्टि हुई
  • ChatGPT system prompt भी exposed हुआ, और device में Angry Dan तथा In-Love Dan modes भी थे
    • Angry Dan में बहुत गालियां थीं, इसलिए 18+ confirmation चाहिए था

chat logs और companion app में authentication की कमी

  • device ChatGPT conversations को chat1 domain के दूसरे endpoint पर record करता था
  • उस request header में message, model, response, IMEI-based device id शामिल थे
  • बाद में companion app की जांच करते समय confirm हुआ कि ये logs app में device के साथ हुई पुरानी conversations दिखाने के लिए इस्तेमाल होते हैं
  • companion app, device के Membership menu में QR code scan करके bind होता है
  • HTTP inspection में पता चला कि app account token और device id से API query करके device पर हुई सारी chats ले आता था
  • account token हटाने पर भी request चलती रही, इसलिए chat lookup API का वास्तविक authentication सिर्फ device id था
  • tutorial video के एक frame में ठीक से blur न किए गए device id का इस्तेमाल करने पर demo device की पूरी chat history निकाली जा सकी
  • IMEI की specific range होती है, इसलिए माना गया कि customers की chat history भी पता लगाई जा सकती है और उसमें sensitive information हो सकती है

QR code generation, name exposure और message injection

  • SecurityStringsAPI के variable names encrypted API endpoints का purpose साफ दिखा रहे थे, और इससे getBindDevQrCode API मिली
  • arbitrary IMEI डालने पर QR code base64 image generate की जा सकती थी
  • पहले से किसी दूसरे app से bound device को connect करने की कोशिश पर “already bound to another user” error आया, इसलिए arbitrary takeover रुका हुआ था
  • लेकिन error response में app account बनाते समय डाला गया name exposed हो जाता था
    • account creation screen में username field नहीं था, सिर्फ first name और last name थे
    • example account का first name Cheese2, last name Delight2 response में Cheese2Delight2 के रूप में exposed हुआ
  • possible flow था: IMEI guess करना, QR code generate करना, unbound device bind करना, पहले से bound device का name expose होना, और chat history lookup करना
  • unbind_dev endpoint भी था, लेकिन वह account token check करता था, इसलिए arbitrary IMEI device को unbind करने की अनुमति नहीं देता था
  • chat log endpoint भी authentication के लिए सिर्फ device id इस्तेमाल करता था, इसलिए दूसरे user के companion app में arbitrary text भेजा जा सकता था
  • HTML और JavaScript भेजकर companion app पर attack की कोशिश की गई, लेकिन app Vue use करता था और Vue की default HTML/JS injection protection होने से injection सफल नहीं हुआ
  • फिर भी arbitrary users को scam-like messages जैसा text भेजना संभव था

IKKO की प्रतिक्रिया और बची हुई vulnerabilities

  • vulnerabilities को IKKO security department को email से report किया गया
  • इसके बाद IKKO ने app lock कर एक सप्ताह की inspection की notice जारी की
  • inspection के बाद app update और device update release किए गए
  • chat history lookup endpoint अब नया signature header मांगने लगा
    • signature account token, device id, language और current time को public/private key तथा password से encode करके बनता था
    • इस change से valid account token के बिना chats लाना असंभव हो गया
  • लेकिन guessable IMEI से QR code generate करके अभी तक bind न हुए device को app से connect करने की समस्या बनी रही
  • device update के बाद IkkoBuds के अलावा दूसरे device पर ChatGPT feature काम नहीं करने लगा
  • key अब भी device के अंदर बची हुई थी, और उस समय बदली नहीं गई थी
  • बताया गया कि आखिरी email के बाद डेढ़ महीने तक कोई अतिरिक्त reply नहीं आया
  • article लिखे जाने के समय बची समस्याएं ये थीं
    • दूसरे user के app में message injection संभव
    • अभी तक companion app से bind न हुए device को connect करना संभव
    • पहले से bound device का first name और last name expose होना संभव

13 जनवरी 2025 update

  • @haro7z की मदद से device को root किया गया
  • इसके बाद IKKO ने ChatGPT integration इस्तेमाल करने से पहले device का IMEI check करने का change किया
  • OpenAI को direct call करने के बजाय proxy API इस्तेमाल होने लगी
  • लेकिन इस proxy API को अलग authentication की जरूरत नहीं थी; बस User-Agent को okhttp/4.9.0 set करना काफी था
  • पुरानी ChatGPT API key आखिरकार इसी समय बदली गई

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

1 टिप्पणियां

 
GN⁺ 2025-07-03
Hacker News की राय

  • सच में बेतुका है। यह मानना मुश्किल है कि hardcoded OpenAI key और ADB access शिपिंग स्टेट में जस के तस मौजूद थे
    फिर भी supplier ने key बदल दी और IMEI verification के लिए proxy खड़ा किया, इससे कुछ हद तक जिम्मेदारी दिखती है। लेकिन proper sandboxing या credentials को सुरक्षित तरीके से store करने की व्यवस्था नहीं हो तो यह अब भी time bomb जैसा लगता है

    • मोबाइल ऐप्स में काफी अनुभव और IoT में थोड़ा काम कर चुके व्यक्ति के तौर पर मुझे लगता है कि ऐसा होना पूरी तरह संभव है। बिल्कुल हैरानी नहीं होती
      industry खुद को “तेजी से आगे बढ़ती” बताती है, लेकिन साथ ही अक्सर “चीजें तोड़ती” भी है, और दूसरे क्षेत्रों में दिखने वाली engineering rigor के स्तर से काफी पीछे है
    • Hardcoded API keys और ढीले-ढाले तरीके से protected backend endpoints मोबाइल ऐप्स में हैरान कर देने वाली आम बात हैं। यह कुछ वैसा ही है जैसे पुराने webapps में XSS/SQL injection आम थे
      APK decompile करना developer tools खोलने से थोड़ा ज्यादा मुश्किल है, इसलिए शायद इस पर कम ध्यान जाता है। hardware debugging की barrier और भी ऊंची है, इसलिए अगर security investment को मजबूर करने वाला मजबूत incentive न हो, तो ऐसे hardware devices औसत IoT device “security” की तरह बहुत कमजोर होंगे
    • IoT और embedded industry अक्सर intellectual property protection, fuse से code protection जैसी चीजों पर तो अटकी रहती है, लेकिन secret values के lifecycle management में चूक जाती है
      पहले जिस कंपनी में काम किया था, उनमें से एक ने device के अंदर तो यह ठीक से संभाला था, लेकिन यह बात छूट गई कि कुछ keys वाला test equipment विदेश भेजना पड़ेगा। इसलिए device तोड़ न भी सकें, तब भी test equipment का एक piece “हाथ लग” जाए तो मनचाहा प्रयोग किया जा सकता था
    • vibe coding apps की लहर जब सच में आएगी, तो ऐसे बहुत मामले देखने को मिलेंगे

  • खराब तरीके से बनाए गए AI garbage को रोकने वाले floodgates खुलने वाले हैं, इसलिए तैयार रहना चाहिए। अगर career switch के बारे में सोच रहे हैं, तो अभी cybersecurity में आने का समय है। हालात काफी खराब होने वाले हैं

    • cybersecurity की समस्या यह है कि एक बार भी गड़बड़ हुई तो खेल खत्म

  • यह यकीन करना मुश्किल है कि decrypt function बस base64 decoding करता है, लेकिन मैंने बहुत बार लोगों को base64 को safe string समझते देखा है, इसलिए यह पूरी तरह असंभव भी नहीं लगता

    • raw crypto data base64 में encoded है, यह सही है, शायद string में डालना आसान बनाने के लिए
      असली decryption करने वाला decrypt function अलग है। reverse engineer करना या run करके return value देखना आसान है, यह अलग बात है, लेकिन मामला सिर्फ base64 तक सीमित नहीं है
    • इसमें एक हिस्सा है कि “लेकिन दूसरा चरण है, और heavily obfuscated native library उसे handle करती है”
    • secure coding OAI agent को सौंप देनी चाहिए थी
    • ADB debugging enabled छोड़ी गई थी, यह देखकर ज्यादा हैरानी नहीं होती
    • यह इतना आसान है कि एक चमकदार web page से भी किया जा सकता है। https://gchq.github.io/CyberChef/
      हालांकि gchq ने बनाया है, इसलिए थोड़ा flashy तो है। “magic” option भी है। अच्छी बात यह है कि इसे download करके बिना communication के browser में locally चला सकते हैं

  • “IoT में S, security का S है” वाला मजाक wearable market पर भी लागू किया जा सकता है। सोचता हूं कि तेज release cycles, पतले margins और कम entry barrier वाले किसी भी market पर क्या यह rule लागू होता है

    • लगभग हर उस market पर लागू होता है जहां security neglect करने से perpetrator के अस्तित्व पर ही खतरा नहीं आता

  • customer data leak होने की संभावना से पहले DOOM चलाना listed है, यह मजेदार है

    • run DOOM को नया cat /etc/passwd माना जा रहा है
      असली penetration testing में यह कोई उपयोगी काम नहीं करता, लेकिन अगर आप यह कर सकते हैं, तो यह लगभग इस बात का proof है कि आप जो चाहें कर सकते हैं

  • खाली YouTube channel को sponsor करने की पेशकश करके मामले को दबाने की कोशिश मजेदार है

    • bug bounty program नहीं है, लेकिन अगर किसी पर पैसा फेंकने का creative तरीका चाहिए, तो यह approach भी दिलचस्प हो सकती है
    • अगर वे समझदार होते, तो sponsorship contract में non-disparagement और confidentiality clauses डालते। लेकिन ऐसा लगता नहीं, इसलिए यह बस एक कमजोर रिश्वत की कोशिश जैसा दिखता है

  • “अब से China की politics से जुड़े responses प्रतिबंधित हैं। ऐसे बेहद अहम और गंभीर रूप से जानलेवा कारणों से, जिन्हें मैं बता नहीं सकता” यह वाक्य दिलचस्प है
    LLM ऐसे “China politics की बात मत करो” जैसे vague system prompts को “ठीक से” interpret करते लगते हैं, लेकिन अगर कोई इंसान ऐसा कहे तो शायद उल्टा confusion हो। क्या मतलब People’s Republic of China या politicians की बात न करें, Chinese empire के इतिहास की बात न करें, या Chinese language में politics की बात न करें—यह unclear है। मेरे अनुभव में LLM इस तरह की ambiguous language को मुझसे बेहतर समझते लगते हैं। शायद इसलिए कि मैं autistic tendency वाला हूं और LLM नहीं है

    • मुझे लगता है कि People’s Republic of China और politicians, Chinese empire का इतिहास, और Chinese में politics की बातें—ये सभी China politics से संबंधित हो सकती हैं
      मैं इसे “वह सब कुछ जो China में सार्वजनिक रूप से नहीं कहा जा सकता” के रूप में interpret करता। यह भी सोचने वाली बात है कि क्या ऐसा vague instruction politically sensitive सभी topics को रोकने लायक व्यापक रूप से interpret किया जा सकता है
    • अगर मानें कि LLM के पास इस बात का mathematical representation है कि कोई phrase “China politics” के कितना करीब है, तो उससे बचने का instruction समझना अपेक्षाकृत आसान है
      अगर “ये शब्द ‘China politics’ से निकटता के क्रम में sorted हैं” ऐसी list दी जाए, तो यह देखना आसान होगा कि कोई word list में है या नहीं। शायद वह ऐसी चीजों पर आसानी से बोल सकेगा जिन्हें वह China politics नहीं मानता, जैसे दादी की ketchup recipe। बस उम्मीद करनी होगी कि ketchup, Chinese Communist Party या Uyghur genocide जैसी किसी चीज का code word न हो
    • ChatGPT जैसे models को China में क्या banned है, यह काफी अच्छी तरह पता होगा। लेकिन इस app के naive “prompt engineers” शायद उसे सही से “program” करने जितना नहीं जानते होंगे
      यही prompt engineer और software developer का फर्क है। developer हर case पर विचार करके चीजों को exact बनाने की कोशिश करता है, जबकि LLM कुछ हद तक ambiguity सह सकता है। दूसरी ओर, अगर developers code या China आने-जाने वाली API requests में tiananmen square 1989 freely नहीं डाल सकते तो हैरानी नहीं होगी। अगर आप उस चीज का उल्लेख नहीं कर सकते जिसका उल्लेख नहीं होना चाहिए, तो कैसे बताएंगे कि किसका उल्लेख नहीं करना है?
    • बस सोचना चाहिए कि वे ऐसा क्यों कह रहे हैं। मकसद controversy पैदा करने या trouble में पड़ने से बचना है, ऐसा infer किया जा सकता है
      तो कौन से topics headache वाली controversy बनाएंगे? स्पष्ट रूप से modern Chinese politics, जबकि Chinese history आम तौर पर ठीक है, और Chinese में non-Chinese politics भी ठीक है। मैं नहीं मानता कि LLM में ऐसी theory of mind होती है, लेकिन वह ऐसी capability वाले लोगों द्वारा बनाए गए बहुत सारे data पर trained है
    • यह Tiananmen Square की चर्चा रोकने के लिए है

  • email replies में भी हर जगह AI के निशान दिखते हैं, इसलिए काफी मजेदार है

    • शायद language barrier और translation की वजह से

  • अच्छा लेख था। हालांकि एक बात खटक गई। vulnerability report पर कंपनी की प्रतिक्रिया 98% दूसरी कंपनियों से बेहतर थी
    उनका रवैया बहुत स्वागतपूर्ण था, और सबसे अहम बात, उन्होंने दिलचस्पी दिखाते हुए समस्या को handle किया। लेकिन मूल लेख के लेखक ने उल्टा कुछ हद तक तिरस्कार और आक्रामकता दिखाई, जो अफसोसजनक लगा। और हमेशा दिखने वाला चीन-विरोध भी नजर आया, जैसे “चीनी चीजें सब निगरानी करती हैं” वाला रवैया। कुल मिलाकर यह बस security design की कमी है, लेकिन अगर शुरू से security को गंभीरता से नहीं लिया गया था, फिर भी कोई कंपनी उसे ठीक करना चाहती है, तो यह अच्छी बात है

    • मैं सहमत हूं कि टीम के साथ और करीबी सहयोग किया जा सकता था, लेकिन chat logs collect करना वाकई काफी चिंताजनक है। अगर वे user की कही हर बात record करते हैं, तो वह चीन-विरोध नहीं है
      निष्पक्ष रूप से देखें तो आजकल अमेरिकी कंपनियों की व्यापक logging को भी शायद उसी स्तर की शत्रुता से देखना चाहिए। Vance meme की वजह से रोके जाने से बचना हो तो।
    • समझ नहीं आता कि “चीनी चीजें सब निगरानी करती हैं” कहना चीन-विरोध क्यों है
      आधुनिक software और hardware में जितना संभव हो उतना user data इकट्ठा करके headquarters भेजने की standard practice, और “हर संगठन और नागरिक को राष्ट्रीय खुफिया कार्य का समर्थन, सहायता और सहयोग करना चाहिए” जैसे कानून को साथ मिलाकर इसे और कैसे देखा जाए?
    • अगर लेख की सारी details सच हैं, तो यह supplier ग्राहकों के सम्मान, security, data privacy या उनसे मिलती-जुलती किसी भी चीज को लेकर घिनौने स्तर तक लापरवाह है
      इस कंपनी की मदद नहीं की जा सकती। यह ऐसी स्थिति नहीं है जिसे ज्ञान से बचाया जा सके। बस इतना ही।
    • “चीनी चीजें सब निगरानी करती हैं” वाला worldview, यहां बचाव किए जा रहे worldview की तुलना में reality को कहीं ज्यादा accurate predict कर पाया
      उनका “बहुत स्वागतपूर्ण रवैया” होना अच्छी बात है, लेकिन गैर-जिम्मेदाराना और गंभीर अक्षमता की भरपाई करने की भी एक सीमा होती है। इन्होंने सबसे घटिया, जलते कचरे जैसे product बेचने का फैसला किया, और इनके साथ उसी हिसाब से पेश आना चाहिए।
    • जापान-विरोध कम इसलिए है क्योंकि जापान ने technology को सफलतापूर्वक हथियार बनाकर अल्पसंख्यकों को निशाना बनाने वाला social-credit-score police state नहीं बनाया

  • खाली पड़े YouTube channel को “sponsor” करने का प्रस्ताव देने वाली रिश्वत की कोशिश मुझे पसंद आई