Audio interface में डिफ़ॉल्ट रूप से SSH सक्षम है

 (hhh.hn)
1 पॉइंट द्वारा GN⁺ 4 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • फ़र्मवेयर फ़ाइल को unpack करने पर डिवाइस की आंतरिक संरचना आसानी से देखी जा सकती थी, और Rodecaster Duo में डिफ़ॉल्ट स्थिति में SSH खुला हुआ था
  • अपडेट पैकेज gzipped tarball फ़ॉर्मेट में था, और डिवाइस में खराबी आने पर दूसरी तरफ़ से boot करने के लिए दो partitions और अपडेट के लिए shell scripts मौजूद थीं
  • आने वाले फ़र्मवेयर पर signature verification नहीं था, और वास्तविक SSH access Ethernet कनेक्शन पर पुष्टि हुआ, जहाँ सिर्फ pubkey authentication की अनुमति थी
  • Windows पर USB update flow को capture करके यह पता चला कि M और U नाम के एकल ASCII commands से update mode में जाना और flashing चलाना होता है; archive.tar.gz और archive.md5 कॉपी करने के बाद reboot के साथ नया फ़र्मवेयर इंस्टॉल हो जाता है
  • macOS पर custom firmware के जरिए SSH password authentication चालू किया गया और public key जोड़ी गई, जिससे वास्तविक access भी संभव हुआ; लेकिन डिफ़ॉल्ट SSH enable रहने और default keys शामिल होने का कारण अंत तक स्पष्ट नहीं हुआ

फ़र्मवेयर अपडेट और SSH का डिफ़ॉल्ट सक्षम होना

  • Rodecaster Duo में फ़र्मवेयर अपडेट प्रक्रिया के दौरान डिवाइस तक भेजी जाने वाली फ़ाइलों को आसानी से देखा जा सकता था, और डिफ़ॉल्ट स्थिति में SSH सक्षम था
    • macOS पर disk activity को trace करके फ़र्मवेयर का storage location ढूँढा गया, और फ़र्मवेयर साधारण gzipped tarball फ़ॉर्मेट में था
    • जिस डिवाइस पर अपडेट की कोशिश की गई, उसमें USB disk write फ़ंक्शन disabled था, इसलिए वह अपडेट असफल रहा
  • डिवाइस के अंदर executable binaries और अपडेट के लिए shell scripts थीं, और disk पर दो partitions थे ताकि एक खराब होने पर दूसरी तरफ़ से boot किया जा सके
    • आने वाले फ़र्मवेयर पर signature verification नहीं है
    • Ethernet cable जोड़कर जाँचने पर SSH वास्तव में खुला मिला, और सिर्फ pubkey authentication की अनुमति थी
  • डिफ़ॉल्ट रूप से जोड़ी गई SSH की दो keys की पुष्टि हुई
    • ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCX/bCFTDgViuPvdFL/VMMVRrw9b5S8HcDQk17qoCEYwmI+IIG8rEAsLiaeCOwyhf9IN+8/LRaN0Z5ZfU3WMbmsKEg8zd1Yvqq74nFbhO47vbtzmCi9S4ucIKkBEVOyvyN5lt9hWf5t5nZSmlfldZK3Pem5y8wHM5A+K/gSnzp4gwQ1QYfFb068uQ+ciIdOhb8SkUs8CwzotglIbp19I6ZmXmsNj/TmpbUf5rMfUAf1gysZ5j1UdRWrvWVh5daqvZRsBBPbXEeJfDU3Nr3HR14XYt9mgexrz/5oyKSj/lQYLmh9cDfsxvkGNIQ8fF9l+n2L1KZM4lLgiGk4KFBjQHaIBZx9OebCiiZCO4NTJUBDk9a+SZpiDiipADV07s7vTInYyFA6GrmKtnq3M6upT4WJBvVuL/BMnK5yY1RZtoqox2/pcCg2rH5S1GIy0v0HFJisl7kWInlaG2mdsaCx19wAjCFe/qT9LyxjQ6+0rArI55/JJFDkNeMjrewRQwNdASjCox8vqXCBfjvsR9qv70/ywcymgsnLAnq2LuYg5FYwMMDYOvVnhACC+BYTdNDTn5oeMIjQCUenY/DPCHpJkf4YOf3YCMUTEU9tExhtwW/X+m21hS3+STLtTfqbUeg9CeuPQZgfl9vc65n3tMxAdlEGEDoTaNMAgr2TzJv92Ka9iQ==
    • ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDaNyzPfIcEeQsfzyQs/wyX6mX52kiS+4eNHfCaxFlgj

अपडेट फ्लो और custom firmware

  • Windows पर Wireshark और USBPcap के साथ update traffic को capture करके RODECaster App द्वारा डिवाइस को भेजे जाने वाले control flow की पुष्टि की गई
    • डिवाइस को update mode में डालने वाला 'M' command और update चलाने वाला 'U' command मौजूद था
    • दोनों commands HID report 1 के रूप में भेजे जाने वाले एकल ASCII characters थे
  • वास्तविक update संरचना सरल थी
    • M command भेजने के बाद नए exposed disk पर archive.tar.gz और archive.md5 कॉपी किए जाते हैं
    • archive.md5, archive का md5sum मान था
    • इसके बाद disk को unmount करके U command भेजने पर flashing शुरू होती है, और फिर डिवाइस reboot होकर नए फ़र्मवेयर पर चलने लगता है
  • macOS पर container का इस्तेमाल करके SSH password authentication चालू करने और अपनी public key को authorized keys में जोड़ने वाला custom firmware बनाया गया
    • flashing के लिए ज़रूरी न्यूनतम functions का उदाहरण यहाँ देखा जा सकता है
    • script चलाकर flashing करने के बाद डिवाइस से SSH के जरिए जुड़ा जा सका
  • इस डिवाइस पर फ़र्मवेयर को बहुत आसानी से flash किया जा सकता था, और डिफ़ॉल्ट SSH enable रहने तथा default keys शामिल होने का कारण अब भी स्पष्ट नहीं है
    • यह मुद्दा RODE को ticket के ज़रिए भेजा गया, लेकिन कोई जवाब नहीं मिला
    • आगे के फ़र्मवेयर updates में कोई बदलाव आता है या नहीं, इसकी निगरानी जारी रहेगी

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

1 टिप्पणियां

 
GN⁺ 4 일 전
Hacker News की राय
  • ऐसी बातों में हमेशा सबसे निराशाजनक यह लगता है कि signed firmware और open firmware असल में एक-दूसरे के उलट नहीं हैं
    डिफ़ॉल्ट रूप से verification चालू रखना ठीक है, लेकिन जिसने hardware खरीदा है उसे अपनी key register करने, jumper बदलने, या boot के समय button दबाने जैसे तरीकों से owner control मिलना चाहिए
    व्यवहार में ऐसा करने वाले बहुत कम हैं, बस कुछ Chromebook और network equipment जैसे उदाहरण हैं, इसलिए firmware security की बात आते ही बहस हमेशा "सब कुछ कसकर बंद कर दो" बनाम "सब कुछ पूरी तरह खुला छोड़ दो" में बदल जाती है, और जिसने पैसे देकर device खरीदा वही फैसला करे, यह ढांचा गायब हो जाता है
    Rode का tarball + hash के रूप में distribute करना बहुत अच्छा है, और अगर आगे चलकर वे इसे और सख्त भी करें, तब भी उम्मीद है कि मेरे अपने device पर मैं जो चाहूँ वह चढ़ा सकूँ, ऐसा रास्ता बना रहे
  • firmware image का सिर्फ़ tarball + hash होना मुझे सच में बहुत पसंद आया
    काश इस तरह के खुले devices और होते, और उम्मीद है Rode यह देखकर firmware upgrades को lock नहीं कर देगा
    • अगर Rode की तरफ़ से कोई यह देख रहा हो, तो ऐसी ही बातों की वजह से यह gear खरीदने का मन होता है
      कृपया इसे मत बदलना
    • कुछ साल पहले मुझे HP printer का firmware चढ़ाना पड़ा था, और हैरानी की बात यह थी कि उसका तरीका बहुत सरल था
      वह लगभग 2009 का printer था, और RAM को 256MB तक बढ़ाने के लिए firmware update ज़रूरी था; बस network पर printer को tarball FTP से भेजना होता था
      मैंने FileZilla से भेजा, कुछ मिनट तक वह चलता रहा और update पूरा हो गया, और उसके बाद से मुझे हमेशा लगा कि firmware update इससे ज़्यादा जटिल होने की क्या ज़रूरत है
      security के लिए checksum जैसी चीज़ हो सकती है, लेकिन अच्छा होगा अगर बस FTP, SCP, या SFTP से एक blob upload करो और काम खत्म हो जाए
    • फिर भी मेरा मानना है कि update command को सिर्फ़ physical button जैसी input से ही सक्रिय करना चाहिए
      यानी किसी तरह के DFU mode में जाना पड़े; नहीं तो USB तक पहुँच रखने वाली कोई भी चीज़ गलत firmware push करके device को brick कर सकती है
    • निजी तौर पर मैं नहीं चाहूँगा कि मेरा audio interface SSH चला रहा हो, और उसमें कोई मनमानी authorized key जोड़ सके
  • अगर शीर्षक मेरा audio interface एक 64-bit Linux computer है होता, तो शायद और दिलचस्प लगता
    10 या 20 साल पहले ऐसी functionality शायद किसी छोटे 16-bit या 32-bit SoC पर VxWorks जैसे RTOS से implement की जाती
    इसमें इतने physical controls हैं कि अगला कदम इसे game console बना देना भी स्वाभाविक सा लगता है
    • मेरा audio interface भी दरअसल एक Linux computer ही है, और उसके भीतर वास्तव में field-programmed होने वाला FPGA है
      ऊपर से उसमें दो 1GbE ports हैं, और हर एक machine के अलग हिस्से से बात करता है
      लेकिन pro audio दुनिया में यह setup इतना अनोखा नहीं है; घर की desk पर रखा हो तो प्रभावशाली लगता है, पर industry में यह काफ़ी सामान्य है
      बाद में अगर कोई root shell निकाल ले या इसे brick कर दे, तो शायद तब कहानी और मज़ेदार हो
    • आपका video dongle भी Unix computer हो सकता है: https://www.macrumors.com/2025/02/04/doom-apple-lightning-hdmi-adapter/
    • आज भी RAM/storage constraints हैं, लेकिन chips इतने सस्ते हो गए हैं
      cost और compatibility के लिहाज़ से Linux को हराना भी आसान नहीं है
  • जब किसी device में ठीक-ठाक DSP आने लगता है, तो इस तरह की बनावट काफ़ी आम हो जाती है
    आमतौर पर नीचे ARM SoC पर चलने वाला minimal Linux होता है, और कभी-कभी vendor का BSP गलती से sshd enabled छोड़कर shipping तक पहुँच जाता है
    यह ज़्यादा बुरी नीयत का मामला नहीं, बल्कि अक्सर audio side में rootfs की सही ज़िम्मेदारी लेने वाला कोई नहीं होता
    असली सवाल यह है कि यह सिर्फ़ USB-side network पर खुला है, या सचमुच के LAN पर भी खुला है
    पहला वाला बस झंझट है, दूसरा सच में चिंता की बात है
    • अफ़सोस की बात है कि Linux defaults इस तरह के devices को mass-produce करने के लिए खास अच्छे नहीं हैं
      इसके मुक़ाबले Android में eng / userdebug / user जैसी default image types पहले से बँटी होती हैं, इसलिए बस सही preconfigured default चुन लेने से ऐसी गलती से बचना आसान हो जाता है
    • यह सचमुच LAN पर भी listen कर रहा है
      किसी खास feature के इस्तेमाल पर ही Wi‑Fi से connect होता है, इसलिए वह interface भी खुला है या नहीं, यह मैं जाँच नहीं पाया
  • अब भी यह बात हैरान करती है कि जैसे हर कोई जेब में AI-hacker लेकर घूम रहा हो
    किसी agent को बस यह दे दो, और कुछ ही मिनटों में वह firmware को देखकर device modify करने का तरीका बता देता है
    पिछले साल तक भी यह काम कम-से-कम Hotz-level hacker या फिर बहुत लंबे समय तक टिककर गहराई में जाने वाले व्यक्ति का लगता था
    • यह बिल्कुल सही नहीं है
      LLM ने analysis, debugging, और bypass को काफ़ी आसान ज़रूर बनाया है, लेकिन इस device की protection इतनी कमज़ोर थी कि मध्यम स्तर की skill वाला कोई भी व्यक्ति, अगर उसके पास समय और motivation हो, यह कर सकता था
      न encrypted firmware था, न signature checks, ऊपर से built-in SSH access भी था
      इसके उलट George Hotz ने जिस PS3 hypervisor को तोड़ा था, वह attacker के नज़रिए से कहीं ज़्यादा मजबूती से design किया गया था, और असली exploit के लिए FPGA का उपयोग करके voltage glitching तक करनी पड़ी थी
      उस तरह के attacks में LLM मदद कर सकता है, लेकिन पूरी feedback loop न होने की वजह से अब भी इंसानी मेहनत काफ़ी लगती है
      https://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/
    • लेख को देखें तो Claude Code को असल में लगभग Wireshark और Google की जगह USB HID traffic समझने और protocol docs ढूँढने के लिए इस्तेमाल किया गया था
      अगर Wireshark install न हो, तो यह थोड़ा समय बचा सकता है, लेकिन hallucination का थोड़ा जोखिम भी है
      इसके अलावा काम बस इतना था कि Docker के भीतर firmware tarball की ~root/.ssh/authorized_keys और /etc/shadow को modify किया गया, संबंधित HID messages भेजे गए, और फिर modified tarball को उस volume में copy किया गया जिसे device USB drive की तरह expose करता है; इसके लिए एक simple Python script इस्तेमाल हुई
      इसलिए यह कोई पागल-स्तर का hacker माँगने वाला काम नहीं था; Linux sysadmin की बुनियादी समझ और USB HID library जोड़कर छोटा-सा program लिख सकने भर का स्तर काफ़ी था
      हाँ, एक पल के लिए मुझे यह ज़रूर अजीब लगा कि Ubuntu container में whois package क्यों install किया गया, लेकिन फिर समझ आया कि Debian परिवार में ऐतिहासिक कारणों से mkpasswd उसी में आता है
      और अगर device का sshd_config सच में default ही था, तो PermitRootLogin की वजह से root password login शुरू से ही शायद काम नहीं करता
      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116260
    • मैंने भी AI का इस्तेमाल करके अपने एक Phase One digital back पर SSH enable किया था, और दूसरे वाले की firmware को reverse-engineer करके उसे दूसरे model की तरह पहचानने के लिए patch किया था
      मैंने Credo 50 को IQ250 बनकर दिखाने लायक बना दिया था, जबकि अंदर से वे लगभग एक जैसे ही हैं
    • पहले packet captures और तरह-तरह के data को घंटों खंगालना पड़ता था, अब वह समय बच जाता है, यह अच्छा है
      गहराई में जाना मज़ेदार है, लेकिन उम्र बढ़ने के साथ किसी random firmware blob पर 16 घंटे खर्च करना मुश्किल होता जाता है
    • ज़्यादातर मामलों में LLM उस स्तर का काम कर ही नहीं पाते
      और ऊपर से SSH खुला होने वाले device से निपटने के लिए कोई खास skill भी नहीं चाहिए
  • मेरी भी ठीक यही समस्या थी, इसलिए मैं सच में जानना चाहता था कि लेखक ने इसे कैसे हल किया
    खासकर यह हिस्सा कि एक ही कमरे में game खेलते हुए और Discord इस्तेमाल करते हुए, मैं और मेरी girlfriend अपने-अपने computer में mic लगाए रखें लेकिन echo के बिना काम हो जाए
    • Rodecaster को दो computers से connect किया जा सकता है
      दोनों को उसी Discord call में रखो, लेकिन दोनों mics को मिलाकर एक computer के input में भेजो, और दूसरे वाले पर mic mute रखकर client में सिर्फ़ audio receive करो
      mixing local स्तर पर होती है, इसलिए echo नहीं बनता
      अगर और सवाल हों तो ईमेल करने को कहने लायक आसान setup है
    • हाल ही में मैंने Rust में मोटे तौर पर jack mixer vibe coding करके बनाया, जो LAN पर audio receive करके फिर बाहर भेज सकता है
      latency लगभग 40ms है, और Wi‑Fi के ज़रिए 50~60ms तक पहुँच जाती है
      एक PC पर mixer चलाइए और local mic को एक input channel बनाइए, फिर दूसरे PC से उसका mic broadcast कीजिए ताकि वह mixer के channel 2 में आ जाए; इस तरह मिलता-जुलता समाधान हो सकता है
      local PC पर music भी चलाया जा सकता है, और mixer या broadcaster local sink बना सकता है
      अंत में सब कुछ mixer में मिलाकर main out को Discord में भेजें, और monitor line Discord audio बाहर भेजकर दूसरे PC तक relay कर सकती है ताकि real-time monitoring हो सके
    • क्या यह directional boom mic वाले headset से हल हो जाने वाली समस्या नहीं है?
      बेशक, हो सकता है मैं स्थिति को गलत समझ रहा हूँ
  • लेख भी अच्छा है और domain भी बढ़िया है
    Zola के बारे में मुझे ज़्यादा पता नहीं, इसलिए यह common template है या custom, यह नहीं कह सकता, लेकिन दिखने में बहुत अच्छा है
  • लगता है बहुत से vendors security को लगभग copy protection का ही दूसरा नाम मानते हैं
    शायद इसी वजह से वे signed image जैसी चीज़ों को enforce करते हैं
  • मैं सोच रहा था कि लक्ष्य disclosure क्यों था
    ऐसे interface के मामले में तो शायद इसे खुला ही रखना बेहतर लगेगा
    • यह ज़रूरी नहीं कि वही लक्ष्य हो, और मैं भी चाहता हूँ कि RODE इसे खुला ही रखे
  • ऑस्ट्रेलिया वाले Rode के लोग काफ़ी approachable माने जाते हैं, इसलिए अगर कुछ report करना हो तो शायद सीधे call भी किया जा सकता है
    वहाँ तो लगभग अंग्रेज़ी जैसी ही बोली जाती है, तो बात समझ में आ जाएगी