मेरे Bluetooth earbuds का volume adjust करना

 (blog.ornx.net)
1 पॉइंट द्वारा GN⁺ 2023-10-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Tozo T6 earbuds में pairing, connection और disconnection के system sounds बहुत तेज़ थे, इसलिए firmware के अंदर मौजूद audio files का gain सीधे कम करके इसे हल किया गया
  • chipset को Airoha AB1562 series माना गया, और AirReps156X app के ज़रिए diagnostic जानकारी देखने व modified firmware upload करने की संभावना की पुष्टि हुई
  • Tozo app के update-check traffic को mitmproxy से intercept करके /api/v1/getOtaVersionV3 response से earbuds firmware binary links हासिल किए गए
  • firmware में left/right earbuds के लिए 2 FotaPackage और 2 FileSystemImage शामिल थे, और modify किए जाने वाले filesystem image के अंदर mp3 files मूल रूप में ही मौजूद थीं
  • mp3gain से mp3 को re-encode किए बिना या उसकी लंबाई बदले बिना सिर्फ -19.5dB कम किया गया, फिर image के अंदर bytes replace करके flash किया गया; device सामान्य रूप से चला और sound काफी कम हो गया

बहुत तेज़ system sounds और शुरुआती assumptions

  • Tozo T6 earbuds pairing, connection और disconnection के समय हर बार sound play करते थे, और यह sound user की पसंद से काफी ज़्यादा तेज़ था
  • equalizer में पूरे frequency band को कुछ dB कम करने से समस्या हल नहीं हुई, और Tozo को email से पूछने पर कंपनी ने जवाब दिया कि वे कुछ नहीं कर सकते
  • लक्ष्य था device पर चल रहे firmware को modify करके संबंधित sound file का volume कम करना
  • शुरुआत में कुछ assumptions बनाकर approach लिया गया
    • device के लिए firmware binary online मिल सकती है
    • firmware ELF जैसी समझने में आसान binary structure में हो सकता है
    • audio file firmware में शामिल हो सकती है, और offset व length पता हों तो उसे modify किया जा सकता है
    • audio PCM जैसे किसी सरल format में हो सकता है
    • modified firmware को device या chipset tool से flash किया जा सकता है
  • असल में कई assumptions गलत निकले, और reverse engineering से ज़्यादा समय proxy जैसी analysis infrastructure setup करने और alternate routes तलाशने में लगा

device और chipset की पहचान

  • सस्ते consumer electronics में आम तौर पर कई parties और layers जुड़े होते हैं
    • product को brand के रूप में बेचने वाला vendor इस मामले में Tozo है
    • firmware चलाने वाला central hardware यानी chipset होता है
    • chipset ARM, MIPS जैसी base technologies से निकली ISA इस्तेमाल कर सकता है
    • अतिरिक्त coprocessor या hardware interfaces के लिए functions integrated हो सकते हैं
  • Tozo Android app को disassemble करते समय Airoha SDK, कुछ specific chip model references और device से communicate करने वाले basic functions मिले
  • Reddit के AirPods replicas से जुड़े community /r/airreps से आगे की दिशा के बारे में जानकारी मिली, और AirReps156X app भी देखा गया
  • AirReps156X app Airoha SDK इस्तेमाल करता है और Airoha devices की diagnostic जानकारी दे सकता था
  • उस app से device connect करने पर diagnostic string QW_1562U_SDK1.5.1 दिखी, और इसी आधार पर device chipset को Airoha AB1562 series माना गया
  • AirReps156X app में नया firmware flash करने की capability भी थी, इसलिए modified firmware को device पर डालने की अहम शर्त पूरी हो गई

Tozo app traffic से firmware URL ढूंढना

  • Tozo app earbuds से connect होने पर current firmware version और वह latest है या नहीं, यह दिखाता है
  • माना गया कि app server से communicate करके latest firmware information check करता है, इसलिए update-check process में actual firmware file URL खोजने का फैसला किया गया
  • decompiled code को अंत तक पढ़ने वाली static analysis के बजाय, network requests को सीधे देखने वाली dynamic analysis चुनी गई
  • wireless NIC, hostapd और mitmproxy से intercepting proxy configured किया गया
  • Tozo APK को apktool और uber apk signer से patch किया गया ताकि वह user CA store में मौजूद mitmproxy TLS certificate पर trust करे
    • Android apps अक्सर default रूप से सिर्फ system CA store देखते हैं
    • APK patch के ज़रिए user CA store भी इस्तेमाल करवाया गया, और फिर उसे re-sign किया गया ताकि वह Android पर चल सके
  • proxy configuration में AP setup, iptables से 80/443 traffic को mitmproxy port पर redirect करना, और NAT setup शामिल था
  • जब app ने firmware version के पास “current” दिखाया, तब उसने /api/v1/getOtaVersionV3 endpoint पर request भेजी, और response में ज़रूरी firmware bin links मौजूद थे

firmware file structure और analysis

  • हासिल firmware कुल 4 files से बना था
    • left/right earbuds में से प्रत्येक के लिए FotaPackage
    • left/right earbuds में से प्रत्येक के लिए FileSystemImage
  • दोनों filesystem images identical थीं, इसलिए unique files कुल 3 थीं: left/right के लिए 2 FotaPackage और 1 filesystem image
  • file, strings, hexdump, binwalk से format और embedded files check करने की कोशिश की गई
  • filesystem image में कुछ filename strings दिखीं, लेकिन binwalk expected mp3 files नहीं खोज पाया
  • mp3 में स्पष्ट magic number या footer नहीं होता, इसलिए arbitrary binary में offset और length पक्का करना मुश्किल था
    • शुरुआत 0xFFFF या 0xFFFE हो सकती है
    • दोनों ही file identifier के रूप में पर्याप्त unique नहीं हैं
  • सोचा गया कि filesystem image structure समझ में आ जाए तो हर file की शुरुआत और अंत पता चल सकता है, इसलिए image format समझने की दिशा ली गई

entropy analysis और ROFS

  • entropy analysis यह visualize करने में उपयोगी है कि file का कौन-सा हिस्सा constants, random noise या ASCII text जैसा है, और transitions कहां हैं
  • filesystem image structured दिख रहा था, लेकिन FotaPackage files compressed या encrypted लग रही थीं
  • left/right FotaPackage में header के कुछ हिस्से ही इधर-उधर अलग थे; body लगभग identical थी, लेकिन आखिरी करीब 7KB पूरी तरह अलग था
  • यह difference ठीक-ठीक क्या दर्शाता है, इसकी पुष्टि नहीं हो सकी, लेकिन माना गया कि कोई opaque transformation applied है और ज्यादा effort के बिना meaningful information निकालना कठिन होगा
  • filesystem image ASCII string ROFS से शुरू होता है
  • ROFS पर public documentation या matching format information नहीं मिली, और बाद में मिले Airoha SDK में इस image को पढ़ने वाली interface implementation शामिल थी
  • एक समय FotaPackage decrypt करने का route आज़माया गया, लेकिन सिर्फ इतना confirm हो पाया कि SDK firmware को भेजने से पहले transform नहीं करता; कोई खास नतीजा नहीं मिला

mp3 को re-encode किए बिना कम करना

  • file mp3 है, यह बात शुरुआत में risk factor थी
    • mp3 encoders में कई options होते हैं, और कोई unknown decoder कुछ valid files को handle न कर पाए, ऐसा हो सकता है
    • connect होते ही play होने वाला audio problem पैदा करे तो device दोबारा connect होने से पहले crash हो सकता है, जिससे recover न हो पाने की स्थिति बन सकती है
  • mp3 को फिर से encode करने से file length बदल सकती थी, और तब filesystem image के अंदर length information भी ठीक-ठीक modify करनी पड़ सकती थी
  • सौभाग्य से mp3 में re-encoding, length change या metadata change किए बिना gain adjust किया जा सकता था
  • यह JPEG को re-encode किए बिना rotate करने जैसा है, यानी internal data structure के सिर्फ एक हिस्से को modify करने वाला तरीका

SDK से मिला निर्णायक clue

  • chipset name से search करके Airoha SDK की copy मिली, और उसमें वैसी ही .mp3 files शामिल थीं जैसी device से सुनाई देती थीं
  • एक simple Python program bincontains.py लिखा गया ताकि यह check किया जा सके कि कौन-सी file किसी दूसरी binary के अंदर ज्यों की त्यों included है
  • verify किया गया कि SDK की mp3 files filesystem image में मूल रूप में ही मौजूद थीं
    • compressed नहीं थीं
    • blocks में split नहीं थीं
    • इसलिए image के अंदर offset और length calculate किए जा सकते थे
  • ROFS से जुड़े SDK code पर संक्षेप में नजर डाली गई, और checksum मौजूद होने का मजबूत संकेत देने वाले symbols नहीं दिखे
  • इस stage पर additional reverse engineering के बिना modification के लिए ज़रूरी conditions पूरी हो गईं
    • firmware file और flashing method मौजूद हैं
    • image में mp3 file की position और length पता की जा सकती है
    • mp3 gain को length बदले बिना adjust किया जा सकता है
    • assumption है कि सिर्फ file के अंदर bytes range बदलने से filesystem metadata नहीं टूटेगा

filesystem image modify करना और flashing

  • Bash script ने SDK की mp3 files पर iterate करते हुए filesystem image में included files ढूंढीं
  • included mp3 को temporary file में copy किया गया और फिर mp3gain से उसका gain कम किया गया
  • इस्तेमाल किया गया adjustment value -19.5dB था
  • modified mp3 का size original जैसा ही है, यह confirm करने के बाद dd से filesystem image के संबंधित offset पर bytes overwrite किए गए
  • final firmware image में binary diff के अनुसार उम्मीद के मुताबिक सिर्फ कुछ bytes बदले
  • modified firmware को device पर flash किया गया, device सामान्य रूप से काम करता रहा और system sounds शुरुआत की तुलना में काफी शांत हो गए

परिणाम और सीमाएं

  • firmware encryption decrypt करने या ROFS filesystem format को पूरी तरह समझने की जरूरत नहीं पड़ी
  • असल में reverse engineering का काफी समय ऐसे detours पर गया जो final solution के लिए सीधे तौर पर ज़रूरी नहीं थे
  • अगर system sound volume control device की built-in feature होती, तो इस तरह के modification की जरूरत नहीं पड़ती
  • audio play करने वाले device में UI level पर ऐसा volume control होना ज्यादा उचित है जो device से आने वाली सभी sounds पर लागू हो
  • इस case में firmware image के अंदर mp3 का gain ही कम करने वाला तरीका पर्याप्त workaround साबित हुआ

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

1 टिप्पणियां

 
GN⁺ 2023-10-30
Hacker News की राय

  • काश कोई मेरे Bluetooth sleep mask को भी इसी तरह ठीक कर देता
    कुल मिलाकर यह काफी अच्छा है, लेकिन जब बैटरी कम होती है या बंद होने का समय आता है, तो यह बात maximum volume पर बताता है
    और वह भी sleep mask में

    • यह असल में काफी मजेदार है। जब तुम्हें पहली बार पता चला होगा, तो तुम कितने गुस्से में रहे होगे, कल्पना कर सकता हूँ
      मैंने भी एक बार ऐसा ही खराब design वाला alarm clock इस्तेमाल किया था, जिसमें MSF wireless time synchronization feature था
      लेकिन हर बार जब वह MSF time signal से दोबारा sync करता, तो 2–3 सेकंड तक alarm जैसी आवाज करता था, और उसे बंद भी नहीं किया जा सकता था
      यह हमेशा सुबह 3 बजे जैसे किसी भयानक समय पर बजता था, इसलिए आखिरकार मैंने उसे खोलकर MSF antenna काट दिया, और यह जानते हुए भी कि clock हमेशा थोड़ा गलत रहेगा, बेहतर सो पाया
    • मेरा Bluetooth ear clip battery low warning पर ऐसे काम करता है: जो audio अभी चल रहा हो उसे बंद करता है, फिर एक नाटकीय सन्नाटा, फिर कहता है “BATTERY LOW. PLEASE CHARGE NOW.”, फिर एक और नाटकीय सन्नाटा, और फिर normal mode में लौटता है
      इस दौरान मैं call पर सामने वाले ने कुछ सेकंड तक क्या कहा, उसे फिर से पकड़ने की कोशिश करता हूँ, पर ठीक से हो नहीं पाता
      यह notification कुछ न करने से भी कहीं खराब है। warning न हो तो सबसे खराब स्थिति यह होती कि sound कट जाए और सामने वाले की बात छूट जाए; ear clip जानबूझकर वही effect और जल्दी schedule पर पैदा कर देता है
      मौजूदा audio stream में बिना खटकने वाला beep pattern जैसी कोई चीज mix न कर पाने की कोई वजह नहीं है। इसमें 1 सेकंड भी नहीं लगेगा, और जिस समस्या को रोकना है, वही खुद पैदा भी नहीं करेगा
      कल्पना से परे खराब Bluetooth behavior में यह भी है कि voice chat इस्तेमाल करते ही सामान्य computer audio पूरी तरह गायब हो जाता है। voice chat अगर mic input इस्तेमाल करे, तो Bluetooth device “headset” mode में चला जाता है, और यह mode stereo को mono में बदल देता है और जब तक audio input दिया जा रहा हो या दिए जाने की संभावना हो, वही इकलौता allowed output बन जाता है
      जो apps audio input इस्तेमाल नहीं कर रहे होते, वे ऐसे Bluetooth headphones device पर play करते रहने की कोशिश करते हैं जो अब मौजूद ही नहीं है, इसलिए वे सभी sound नहीं दे पाते
      समझ नहीं आता कि device modes कई क्यों होने चाहिए। परिवार से बात करने के side effect के रूप में मैं features क्यों खोना चाहूँगा? सिर्फ इसलिए कि mic चालू हो सकता है, दोनों कानों में अलग-अलग audio signals साथ-साथ चलाना इतना मुश्किल क्यों है, समझ नहीं आता। non-Bluetooth devices यह संभाल लेते हैं, और इसे कोई खास feature भी नहीं माना जाता। “mic इस्तेमाल करते समय headphones बंद नहीं होते” यह खास क्यों होना चाहिए?
    • आखिरकार मैंने 3.5mm jack cable वाले pillow speaker इस्तेमाल करने शुरू कर दिए। Bluetooth में आने वाली ऐसी समस्याओं से बच जाता हूँ
    • वह device करता क्या है? सोने की कोशिश करते समय Bluetooth connection की जरूरत क्यों पड़ेगी, यह जानना चाहता हूँ
    • Futurama का NNY city clock याद आ गया। cutscene में वह maximum volume पर “THE TIME IS FOUR AM” चिल्लाता है

  • बढ़िया! मूल लेखक ने अंत तक करके दिखाया, कमाल है
    तेज आवाज वाले earbuds की बात चली है, तो मेरे साथ शायद उलटी समस्या है। मैं treadmill पर Bose exercise earbuds को ऐसी volume पर इस्तेमाल करता हूँ जिसे मैं comfortable और conservative मानता हूँ, लेकिन iPhone notification देता है कि volume बहुत ज्यादा है और मेरी hearing खराब कर रहा है
    क्या phone सही है? अगर हाँ, तो कानों की सेहत के लिए मैं थोड़ा आनंद त्यागने को तैयार हूँ। लेकिन एक plausible alternative hypothesis भी है। ये earbuds समान volume setting पर मेरे इस्तेमाल किए बाकी products की तुलना में actual physical volume में साफ तौर पर कम हैं, इसलिए Apple की lazy modeling मेरे जैसे गलत notifications पैदा कर सकती है
    अगर Apple ने product model और volume setting को actual physical volume से map करने वाला database बनाया है, तो मैं उसकी तारीफ करना चाहूँगा। लेकिन notification और feature description में बिल्कुल detail नहीं है, इसलिए भरोसा नहीं होता, और सिर्फ इसलिए कि Apple ने college assignment level model को real product में डाल दिया, मैं अपना workout कम enjoyable नहीं बनाना चाहता
    क्या किसी को पता है कि इस notification के पीछे की data science सच में ठीक है या नहीं?

    • iOS में मुझे Android की ठीक दो चीजें याद आती हैं, और दोनों का संबंध Bluetooth के कम घटिया तरीके से काम करने से है
      पहला, iOS में मेरे Bluetooth earbuds का minimum volume बहुत तेज है। मैंने जितने भी third-party headphones इस्तेमाल किए, सब में ऐसा था, और online 10 साल से शिकायतें चल रही हैं। EU ने इसे ठीक करने के लिए कानून तक पास किया, लेकिन spoiler: कोई असर नहीं हुआ
      कृपया UI का minimum volume hardware volume integer 1 से map होना चाहिए
      दूसरा, third-party apps car Bluetooth media browsing menu में music या podcasts expose नहीं कर सकते। Android में यह संभव है
      इसलिए Android में मैं car के jog wheel से podcasts सुन सकता हूँ और Tidal stream कर सकता हूँ, लेकिन iOS में नहीं
      Bluetooth से जुड़ी और भी शिकायतें हैं। मेरी Apple Watch car stereo को blacklist क्यों करती है? iOS versions N और N-1 का Bluetooth सचमुच बहुत buggy है
    • मेरा phone भी, Android 5 है और सच कहूँ तो मैं उसे लगभग इस्तेमाल नहीं करता, इसलिए खराब होने तक नया चाहिए भी नहीं, reboot के बाद पहली बार car से Bluetooth पर connect होते ही यही करता है
      यह बस साफ तौर पर बेवकूफी भरा feature है। अगर root कर पाता तो कहीं किसी config file में मौजूद वह switch बंद कर देता, लेकिन Samsung Galaxy J1 (2016) पर मैं कभी सफल नहीं हुआ
    • मुझे नहीं लगता operating system को पता हो सकता है कि दूसरी तरफ कितने dB निकल रहे हैं
      मेरा Bose भी Bluetooth chipset के हिसाब से अलग behave करता है। Linux में कुछ भी ठीक से सुनने के लिए volume 150% करना पड़ता है
    • Apple ने अगर ऐसी mapping बनाई भी हो, तो release होते ही वह outdated data बन जाएगी
      लेकिन यह मानने की कोई वजह नहीं कि उसने ऐसा किया है। अगर headphone manufacturers Bluetooth connection के समय dB range report करें और उससे ऐसा feature संभव हो, तो यह दिलचस्प होगा, लेकिन मैंने ऐसा कुछ नहीं सुना। 3.5mm jack के उलट, Bluetooth में ऐसी capability संभव बनाने की गुंजाइश तो है
    • Noise-cancelling headphones/earbuds इस समस्या को हल कर देते हैं
      Noise cancelling इस्तेमाल करने पर volume को 20% से नीचे रखते हुए भी कानों पर जोर डाले बिना comfortable listening संभव होती है
      मेरे मामले में कुछ साल पहले लंबी workout के बाद कानों में दर्द शुरू हुआ था, इसलिए मुझे लगता है Apple notification शायद सही था। Noise cancelling इस्तेमाल करने के बाद वह पूरी तरह गायब हो गया

  • ऐसा काम वाकई अच्छा है। अचानक यह earphone model काफ़ी दिलचस्प लगने लगा है
    साथ ही, Bluetooth devices की system sounds उन चीज़ों में से हैं जो products के बीच फर्क सबसे ज़्यादा महसूस कराती हैं। कुछ तो बेहद खराब होती हैं: https://youtu.be/J2wPsH64JEM
    लेकिन reviews या product pages में मैंने कभी नहीं देखा कि वे बताते हों कि product कैसी आवाज़ें निकालता है। जबकि इन्हें दिन में कई बार सुनना पड़ता है, और बंद करने का कोई तरीका भी नहीं होता
    सिर्फ़ इन sounds को बदलने की सुविधा देना भी काफ़ी आसान differentiation हो सकता है

    • काश मैं अपने AfterShokz का play/pause beep कम कर पाता
      earplugs लगाकर किसी शोरगुल वाले worksite में हों तो यह perfect है, लेकिन शांत office में focus करने के लिए music धीमे volume पर चलाया हो तो यह असुविधाजनक और चौंका देने वाला लगता है
      समझ नहीं आता कि system sounds volume setting को follow क्यों नहीं करतीं

  • काश phone को पता चल सके कि connected headset speaker set है, in-ear monitor है, bone conduction है वगैरह
    जब मैं normal speaker set इस्तेमाल करके जानबूझकर इतना तेज़ चलाना चाहता हूं कि घर में कहीं से भी सुनाई दे, तब “volume बहुत ज़्यादा है” notification चिढ़ दिलाता है
    bone conduction headphones में ठीक से सुनने के लिए काफ़ी तेज़ volume चाहिए होता है, इसलिए यह दोगुना परेशान करता है

  • अच्छा है कि यह बिना firmware encryption वाले Airoha target के लिए है
    अगर दिलचस्पी हो, तो firmware format के लिए 010 Editor template भी है
    https://github.com/ramikg/airoha-firmware-parser

  • skill की दाद देनी पड़ेगी, लेकिन यह अफ़सोस की बात है कि file playback volume को थोड़ा बदलने जैसे basic काम के लिए इतनी ज़्यादा मेहनत चाहिए
    tools को अपनी इच्छा के मुताबिक काम कराने के लिए इतना झंझट नहीं होना चाहिए

  • यह “समझ में आने वाली बात” नहीं है। आपने product की कीमत चुकाई है, और यह एक product issue है जिसे ठीक किया जाना चाहिए

  • यह लेख पढ़कर मैंने second-hand Tozo T6 खरीदा, और ऊपर से देखने में वह काफ़ी हाल में बना हुआ लगता था, लेकिन मैं इसे reproduce नहीं कर पाया
    official Tozo app headset को पहचान भी नहीं पाया, और मैं यह भी confirm नहीं कर सका कि वह Airoha chipset इस्तेमाल करता है या नहीं, जिसकी पहचान AAC support से होती है। मेरा वाला सिर्फ़ SBC support करता है
    लगता है या तो मैंने fake खरीदा, या लेखक के खरीदने के बाद अंदरूनी बदलाव हुए
    कुछ audio files internet पर मौजूद partial Airoha SDK में शामिल files जैसी सुनाई देती हैं, लेकिन यह कुछ दूसरी नई voice files भी play करता है
    अगर आप इस result को independently verify करना चाहते हैं या इसके साथ experiment करना चाहते हैं, तो fake AirPods शायद बेहतर route हो सकते हैं

  • काश तेज़ और खराब system sounds के बारे में और लोग शिकायत करें

  • मेरे Sony WH-1000XM4 में भी बिल्कुल यही problem है, लेकिन लगता है Sony firmware payload को encrypt करता है और device पर decrypt करता है
    मैं लगभग उसे खोलकर सब कुछ dump और explore करने वाला था, लेकिन मेरे हाथ कांपते हैं, इसलिए उसे खराब कर देने की संभावना बहुत ज़्यादा है
    hackable noise-cancelling headset के लिए मैं अच्छी-खासी रकम देने को तैयार हूं