Starlink यूज़र टर्मिनल का डिसअसेंबली विश्लेषण

• SpaceX का Starlink यूज़र टर्मिनल लो-अर्थ ऑर्बिट सैटेलाइट इंटरनेट कनेक्शन का मुख्य हार्डवेयर है
• यूज़र टर्मिनल को खोलकर देखने पर, radio frequency (RF) frontend और कस्टम-डिज़ाइन SoC मुख्य कंपोनेंट के रूप में सामने आते हैं
• firmware analysis के अनुसार, अधिकांश मुख्य सॉफ़्टवेयर में kernel-bypass user-space network processing और कुछ encryption फ़ंक्शन शामिल हैं
• STSAFE-A110 security chip अतिरिक्त root of trust की भूमिका निभाती है और data encryption व unique identification प्रदान करती है
• इस टर्मिनल में कई SSH public key कॉन्फ़िगरेशन और संदिग्ध packet recording tool शामिल हैं, लेकिन यूज़र प्राइवेसी के उल्लंघन के संकेत नहीं मिले

---

अवलोकन

• Starlink, SpaceX द्वारा प्रदान की जाने वाली लो-अर्थ ऑर्बिट सैटेलाइट इंटरनेट सेवा है
• यूज़र टर्मिनल के ज़रिए नज़दीकी सैटेलाइट से जुड़ते हैं, जो ground gateway के माध्यम से इंटरनेट से कनेक्ट होता है
• नई पीढ़ी के सैटेलाइट laser link का उपयोग करके सैटेलाइट-से-सैटेलाइट संचार कर सकते हैं, और यह क्षमता global coverage व efficiency बढ़ाने में योगदान देती है
• स्थानीय gateway के बिना भी, उदाहरण के लिए यूक्रेन में, Starlink टर्मिनल पड़ोसी देश के gateway का उपयोग कर इंटरनेट से जुड़ सकता है
• इस लेख में DARKNAVY की Starlink यूज़र टर्मिनल पर की गई गहन जाँच को संक्षेप में प्रस्तुत किया गया है

हार्डवेयर विश्लेषण

• एक Starlink यूज़र टर्मिनल दो हिस्सों से बना होता है: router और antenna (UTA)
• DARKNAVY ने सिंगापुर में Standard Actuated(Rev3, GenV2) टर्मिनल खरीदा और antenna को डिसअसेंबल किया
• डिसअसेंबली के परिणाम में, RF frontend chip (मुख्यतः STMicroelectronics द्वारा निर्मित) ने बोर्ड का बड़ा हिस्सा घेर रखा था
• मुख्य नियंत्रण क्षेत्र में SpaceX-विशेष custom ST SoC (quad-core Cortex-A53) लगा है, लेकिन इसकी datasheet सार्वजनिक नहीं है
• Black Hat USA 2022 में KU Leuven के Dr. Lennert Wouters ने पहली पीढ़ी के टर्मिनल (GenV1) को hack करने की सफल घटना प्रस्तुत की थी, जिसके बाद SpaceX ने firmware update के माध्यम से UART debug interface को निष्क्रिय कर दिया
• हालांकि, अतिरिक्त तरीकों से सुरक्षा bypass फिर से सफल होने का इतिहास है

फर्मवेयर एक्सट्रैक्शन और विश्लेषण

• DARKNAVY ने सीधे eMMC chip से firmware dump किया
• Rev3 बोर्ड में अलग eMMC debug pin नहीं थी, इसलिए eMMC को हटाकर programmer से data extract करने की विधि अपनाई गई
• अधिकांश firmware encrypted नहीं था, इसलिए bootchain (BootROM को छोड़कर), kernel, और filesystem का कुछ हिस्सा सामने आ गया
• kernel boot होने के बाद runtime environment को /sx/local/runtime में unpack करके उपयोग किया जाता है
• bin में Starlink सॉफ़्टवेयर executable, dat में configuration file, और revision_info में version information मौजूद है
• मुख्य communication program user_terminal_frontend Go में विकसित है, जबकि बाकी अधिकांश static C++ binary हैं जिनमें symbol नहीं हैं
• network stack architecture DPDK की तरह kernel को bypass करती है और user-space program packet processing संभालते हैं
• Linux kernel मुख्यतः hardware driver और process management के लिए उपयोग होता है
• कुछ सॉफ़्टवेयर में मूल रूप से satellite या gateway उपयोग के लिए डिज़ाइन की गई functionality शामिल है
• डिवाइस boot के समय hardware peripheral के आधार पर type पहचानता है और केवल संबंधित logic को load करता है

इम्यूलेशन

• निरंतर विश्लेषण के लिए QEMU-आधारित Rev3 firmware emulation environment बनाया गया
• इस environment में httpd, WebSocket, gRPC जैसी कुछ बाहरी सेवाओं को चलाने और debug करने में सफलता मिली
• इससे मुख्य executable और services के काम करने के तरीके को ट्रेस करना संभव हुआ

सुरक्षा चिप

• मुख्य SoC के अलावा STSAFE-A110 security chip मौजूद है, जो CC EAL5+ certification का दावा करती है
• यह chip NDA के तहत खरीदी जा सकती है, और firmware का stsafe_cli program इसी chip के साथ interact करता है
• analysis के अनुसार, STSAFE chip द्वारा प्रदान की जाने वाली सुविधाओं में डिवाइस को unique UUID देना, public key certificate (stsafe_leaf.pem) प्रबंधन, और symmetric key derivation शामिल हैं
• यह chip SoC के secure boot से अलग एक अतिरिक्त trust root है, जो आधुनिक embedded security design मानकों के अनुरूप है

ईस्टर एग: क्या Elon आप पर नज़र रख रहा है?

• analysis के दौरान Ethernet Data Recorder program मिला, जिससे backdoor की संभावना पर सवाल उठता है
• इस program में packet recording capability दिखाई देती है, और यह अंदरूनी तौर पर pcap_filter-जैसे mechanism से विशेष packet capture करता है
• नियमों को देखने पर पता चलता है कि capture का लक्ष्य मुख्यतः satellite telemetry से जुड़े UDP packet हैं
• capture किया गया traffic SoC hardware key से encrypt होकर store होता है
• अब तक यूज़र privacy data एकत्र करने का कोई सबूत नहीं मिला है
• initialization प्रक्रिया में, यदि डिवाइस को यूज़र टर्मिनल के रूप में पहचाना जाता है, तो /root/.ssh/authorized_keys में 41 SSH public keys लिखी जाती हैं, और port 22 हमेशा local network के लिए खुला रहता है
• commercial product में बड़ी संख्या में अज्ञात public keys का दर्ज होना ध्यान देने योग्य है

निष्कर्ष और आगे की दिशा

• जैसे-जैसे satellite technology विभिन्न उद्योग क्षेत्रों में लागू हो रही है, Starlink जैसे satellite internet system के कंपोनेंट भविष्य में security attack और defense के प्रमुख रणक्षेत्र बन सकते हैं
• space security की प्रकृति के कारण, एक ही गलती लक्ष्य के साथ स्थायी संचार-विच्छेद का कारण बन सकती है, इसलिए सावधानीपूर्वक दृष्टिकोण आवश्यक है

[GN⁺]

Hacker News टिप्पणियाँ

• डिवाइस के initialization के समय, अगर सिस्टम इसे user terminal के रूप में पहचानता है, तो initialization script अपने-आप /root/.ssh/authorized_keys फ़ाइल में 41 SSH public keys लिख देती है, और port 22 भी हमेशा local network पर खुला रहता है। इससे यह सवाल उठता है कि 41 keys रखने का मतलब क्या है, और आख़िर वह कौन है जिसे 'आपके स्वामित्व वाले' user terminal पर root access नहीं होना चाहिए
  • शायद आप ही होंगे। थोड़ा गंभीरता से सोचें तो यह ISP द्वारा दिए गए router में remote management system होने से बहुत अलग नहीं है। अगर SpaceX के पास user terminal तक पहुँच न भी हो, तब भी वह satellite या ground station से traffic monitor कर सकता है
  • हाल में special government work से जुड़े लोगों में traceable SSH keys हैं या नहीं, यह जाँचने के लिए सबसे उपयुक्त व्यक्ति कौन होगा, इसे लेकर जिज्ञासा हुई। हाल में कुछ अच्छे leaks भी हुए हैं
  • 41 keys सिर्फ 41 regions में चल रही एक ही server instance की भी हो सकती हैं। Starlink एक global service है, इसलिए यह कोई खास चिंता की बात नहीं है। बल्कि अगर 41 instances एक ही key साझा करते, तो मुझे ज़्यादा चिंता होती
  • मेरी मौजूदा कंपनी में developer SSH keys सिर्फ DEV या QA firmware में deploy की जाती हैं। Production images sign होने के बाद SSH पूरी तरह disable कर दिया जाता है। Production में remote diagnostics के लिए अलग software इस्तेमाल होता है, और वह भी access control तथा DevOps approval process के तहत manage किया जाता है। इसलिए SpaceX का यह चुनाव अजीब लगता है
  • मैं एक single user हूँ, फिर भी मेरे authorized_keys में 25 lines हैं। इनमें laptop की कई yubikeys, iPad और iPhone की keys, और Mac की secure enclave keys मिली-जुली हैं। मैं कल्पना कर सकता हूँ कि Starlink में कम-से-कम 1-2 अतिरिक्त system administrators तो होंगे ही, इसलिए 100 public keys भी कोई बहुत अजीब संख्या नहीं है
  • उल्टा, यह उम्मीद से ज़्यादा सामान्य और security के लिहाज़ से अच्छा विकल्प हो सकता है। लाखों terminals में एक ही key या बहुत कम keys इस्तेमाल करने से बेहतर है कि serial number या production period के हिसाब से अलग-अलग keys हों। Private keys शायद सिर्फ कुछ सीमित terminals के management के लिए इस्तेमाल होती हों, और key management भी अलग-अलग हिस्सों में बँटा हो सकता है
  • मेरा अनुमान है कि इस terminal तक बाहर से key के ज़रिए पहुँच तभी संभव होगी जब local network को internet connectivity भी मिली हो। यह भी जानने की जिज्ञासा है कि SSH connection satellite network से होकर कैसे जाता होगा, और Starlink NAT जैसी network structure का इस्तेमाल कैसे करता होगा
• पहले पोस्ट किए गए मिलते-जुलते विषय के रूप में Starlink user terminal teardown लेख का लिंक साझा किया गया
• 41 public keys को सार्वजनिक करके यह पता लगाना मज़ेदार होगा कि कौन-सा developer कौन-सी key इस्तेमाल करता है
• Starlink से जुड़े blog post archive का लिंक साझा किया गया
• लेखक से शीर्षक की typo ("ternimal") ठीक करने का अनुरोध किया गया
  • मज़ाकिया ढंग से कहा गया कि यह keming (अक्षरों के बीच असंतुलित spacing) समस्या का क्लासिक उदाहरण है
• यह देखकर हैरानी होती है कि सारे packets userspace में process होते हैं। 1Gbps traffic (100-byte UDP के आधार पर) का मतलब है प्रति सेकंड 10 लाख packets। 1GHz CPU के पास प्रति packet सिर्फ 1000 cycles उपलब्ध होते हैं। सिद्धांततः यह संभव है, लेकिन आसान नहीं; यह ऐसा स्तर है जहाँ engineer को assembly hand-coding में हर तरह की tricks लगानी पड़ें
  • एक paper के अनुसार, network stack की संरचना DPDK जैसी दिखती है, और packet का kernel-bypass processing इसका मुख्य हिस्सा है। वास्तव में शायद सिर्फ शुरुआती packets software में process होते हों, और session बनने के बाद उन्हें hardware को सौंप दिया जाता हो। कुछ patterns लगातार software में भी process हो सकते हैं। Intel Puma सीरीज़ cable modem routers में भी ऐसा मिलता-जुलता तरीका देखा गया है
  • DPDK-style forwarding में buffer copy कम होती है, इसलिए यह उल्टा और तेज़ हो सकता है। Starlink 25-200Mbps स्तर पर चलता है, और average packet size 7-8 गुना बड़ा है, इसलिए यह लगभग 36 हज़ार packets per second के आसपास बैठता है। 1GHz CPU के लिए यह संभालने लायक मात्रा है
  • यह सवाल उठता है कि kernel में packet processing की तुलना में userspace में यह कम efficient क्यों होगा। अगर hardware queues को userspace में map कर दिया जाए, तो kernel-userspace का फ़र्क उतना महत्वपूर्ण नहीं रह जाता
  • Starlink के मामले में, 100-byte UDP packets की तुलना में सामान्य 1500-byte MTU का उपयोग होता है
  • userspace में packets process करने से अनावश्यक memory copy कम होती है, इसलिए यह कहीं तेज़ हो सकता है
• ऐसी hardware का reverse engineering कैसे शुरू करें, इसे लेकर जिज्ञासा व्यक्त की गई। Reverse engineering कठिन है, और ज़्यादातर उदाहरण या तो पुराने होते हैं या इतने महंगे कि आज़माना मुश्किल हो जाता है
  • पहले hardware engineering सीखनी चाहिए। अगर components के काम या विशेषताओं का पता न हो, तो reverse engineering करना ही मुश्किल हो जाता है
  • पहला कदम है उत्पाद को खुद खरीदकर खोलना। दूसरा, खोलने के बाद उसमें घुसने का तरीका सोचना। तीसरा, वास्तव में कोशिश करना। चौथा, उसके टूट जाने पर निराश होना। आमतौर पर UART port से प्रवेश मिलता है, लेकिन Starlink में वह नहीं दिखता, इसलिए eMMC memory chip हटाकर उसका analysis करने का उदाहरण दिया गया
• पूछा गया कि क्या QEMU-आधारित emulation environment में बाहरी devices (GPS आदि) से जुड़े firmware emulation के लिए कोई reference material या ready solution मौजूद है
  • उदाहरण के तौर पर बताया गया कि Android के QEMU fork में OpenGL, GPS, GSM, sensors और GUI interface सहित कई तरह के hardware emulate किए जाते हैं
• यह जानने की इच्छा जताई गई कि firmware को reverse engineering से कैसे बचाया जाए, और SpaceX जैसी तकनीक पर शुरुआती अध्ययन सामग्री है या नहीं
  • पहला चरण firmware encryption जैसी व्यवस्था है। SpaceX भी शायद बहुत proactive नहीं है, बल्कि कुछ मिलता है तो उसे patch करता जाता है। पहले debug pins भी मौजूद थे
  • इस्तेमाल किए गए बहुत-से products में firmware की गुणवत्ता अक्सर कमज़ोर रही है। सुरक्षा के अलावा बेवजह सब कुछ बंद करने की जगह, संसाधन उन चीज़ों पर लगाने चाहिए जो सभी के काम आएँ। Power users अगर device को खुद modify कर सकें तो यह उल्टा फ़ायदा है। जब तक कोई वास्तव में गंभीर compromise risk न हो, तब तक इस पर अनावश्यक समय न लगाया जाए। यह अफ़सोसजनक, कभी-कभी उदास करने वाली बात है कि ज़रूरत के मुताबिक़ devices को hack करना ही पड़ता है
  • कम-से-कम root filesystem को encrypt करना चाहिए, और ऐसी secret जानकारी का उपयोग होना चाहिए जो किसी वास्तविक secure chip में हो ताकि चोरी या extraction कठिन बने। अगर और मज़बूत सुरक्षा चाहिए, तो ARM TrustZone का उपयोग करके bootloader, decryption, image signing जैसे sensitive कामों को isolate किया जा सकता है। यह तथ्य कि filesystem को आसानी से dump किया जा सकता है, अपने-आप में दिखाता है कि SpaceX व्यावहारिक सुरक्षा उपायों का उपयोग नहीं कर रहा। सिर्फ bootloader सुरक्षित है, बाकी सब उजागर है
• इस बात पर आश्चर्य जताया गया कि क्या यह उपकरण शायद rocket जैसी codebase इस्तेमाल करता है
  • बल्कि इससे भी ज़्यादा दिलचस्प यह लगा कि शायद यह satellites के साथ codebase साझा करता हो, या कम-से-कम satellite simulator जैसा कुछ हो, क्योंकि इसे तरह-तरह की telemetry भेजनी होती है
  • वास्तव में यह OpenWRT पर आधारित है