ชำแหละเทอร์มินัลผู้ใช้ Starlink

 (darknavy.org)
1 คะแนน โดย GN⁺ 2025-05-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • DARKNAVY ชำแหละเสาอากาศของ Starlink Standard Actuated ที่ซื้อจากสิงคโปร์ เพื่อวิเคราะห์เบื้องต้นด้านฮาร์ดแวร์ เฟิร์มแวร์ ชิปความปลอดภัย และความเป็นไปได้ในการอีมูเลต
  • PCB ของเสาอากาศส่วนใหญ่ถูกครอบครองโดย RF front-end ของ STMicroelectronics และส่วนควบคุมหลักถูกรวมไว้ที่ด้านหนึ่งของบอร์ด ทำให้มีโครงสร้างคล้ายอุปกรณ์ IoT ทั่วไป
  • เฟิร์มแวร์ Rev3 ถูกดัมพ์โดยการถอด eMMC ออก และข้อมูลส่วนใหญ่ยังอยู่ในสถานะ ไม่เข้ารหัส ทำให้ตรวจสอบบางส่วนของ boot chain, เคอร์เนล, บางส่วนของไฟล์ซิสเต็ม และการตั้งค่ารันไทม์ได้
  • ซอฟต์แวร์ที่ดึงออกมามีฟังก์ชันที่ดูเหมือนใช้ได้ไม่เฉพาะกับเทอร์มินัลผู้ใช้ แต่รวมถึงดาวเทียมและเกตเวย์ภาคพื้นด้วย และดูเหมือนจะมีโครงสร้างที่ระบุประเภทอุปกรณ์จาก อุปกรณ์ต่อพ่วงฮาร์ดแวร์ ตอนเริ่มระบบ
  • Ethernet Data Recorder บันทึกแพ็กเก็ตที่เกี่ยวข้องกับ telemetry ของดาวเทียมและเข้ารหัสด้วยคีย์ฮาร์ดแวร์ แต่ใน UTA มีการลงทะเบียน SSH public key จำนวน 41 คีย์โดยอัตโนมัติ และพอร์ต 22 เปิดค้างไว้บนเครือข่ายท้องถิ่นเสมอ

เทอร์มินัลผู้ใช้ Starlink และขอบเขตการวิเคราะห์

  • Starlink คือบริการ อินเทอร์เน็ตผ่านดาวเทียมวงโคจรต่ำ ของ SpaceX โดยผู้ใช้จะเชื่อมต่อกับดาวเทียมวงโคจรใกล้โลกผ่านเทอร์มินัลผู้ใช้ แล้วเชื่อมสู่อินเทอร์เน็ตผ่านเกตเวย์ภาคพื้น
  • ดาวเทียมรุ่นใหม่เริ่มทยอยเพิ่ม ลิงก์เลเซอร์ เข้ามา ทำให้ดาวเทียมบางดวงสื่อสารกันเองได้โดยตรง
    • ช่วยลดการพึ่งพาสถานีภาคพื้น เพิ่มประสิทธิภาพการส่งข้อมูล และปรับปรุงการครอบคลุมทั่วโลก
    • แม้ในสมรภูมิยูเครนที่ไม่มีสถานีภาคพื้นในพื้นที่ เทอร์มินัลผู้ใช้ Starlink ก็สามารถเชื่อมต่อทางอ้อมไปยังเกตเวย์ในประเทศข้างเคียงผ่านลิงก์ระหว่างดาวเทียมได้
  • การตรวจสอบของ DARKNAVY ไม่ได้ครอบคลุมเทอร์มินัลผู้ใช้ Starlink ทั้งชุด แต่โฟกัสที่องค์ประกอบเสาอากาศคือ User Terminal Antenna, UTA
    • อุปกรณ์เป้าหมายคือ Starlink Standard Actuated ที่ซื้อจากสิงคโปร์
    • เรียกอีกชื่อว่า Rev3 หรือ GenV2

ผลการชำแหละฮาร์ดแวร์

  • เทอร์มินัลผู้ใช้ Starlink แบบสมบูรณ์ประกอบด้วย 2 ส่วนคือ เราเตอร์ และเสาอากาศ
  • PCB ของ UTA ที่ถูกชำแหละมีขนาดเกือบเท่ากับเคสภายนอก
    • พื้นที่ส่วนใหญ่ของบอร์ดถูกใช้โดย ชิป RF front-end ที่ผลิตโดย STMicroelectronics
    • ชิ้นส่วนควบคุมหลักส่วนใหญ่ถูกรวมอยู่ด้านหนึ่งของ PCB
  • เมื่อไม่นับส่วนเสาอากาศ RF แล้ว การออกแบบโดยรวมของแกนหลัก UTA คล้ายกับอุปกรณ์ IoT ทั่วไปอย่างมาก
  • SoC หลักคือ quad-core Cortex-A53 ที่ ST ผลิตแบบคัสตอมให้กับ SpaceX
    • ปัจจุบันฮาร์ดแวร์และ datasheet ของชิปนี้ยังเป็นความลับและไม่เปิดเผยสู่สาธารณะ
  • ในงาน Black Hat USA 2022 ดร. Lennert Wouters จาก KU Leuven ได้สาธิตการโจมตีแบบ fault injection กับเสาอากาศ Starlink รุ่นแรก GenV1 จนได้ root shell ของอุปกรณ์
    • หลังจากนั้น SpaceX ได้เพิ่มความต้านทานต่อการโจมตีลักษณะนี้ด้วยการปิดใช้งาน UART debug interface บน PCB ผ่านการอัปเดตเฟิร์มแวร์
    • Wouters ปรับปรุงแนวทางของตนและสามารถเจาะเข้าไปได้อีกครั้ง

การดึงเฟิร์มแวร์และโครงสร้างซอฟต์แวร์

  • เพื่อวิเคราะห์ UTA ให้ลึกขึ้น DARKNAVY ได้ ดัมพ์เฟิร์มแวร์โดยตรง จากชิป eMMC
    • บนบอร์ด Rev3 ไม่มีขา debug ของ eMMC ที่เห็นได้ชัด
    • จึงต้องถอดชิป eMMC ออกจาก PCB แล้วอ่านด้วยโปรแกรมเมอร์
  • เฟิร์มแวร์ที่ดึงออกมาส่วนใหญ่ยังอยู่ในสถานะ ไม่เข้ารหัส
    • boot chain ยกเว้น BootROM
    • เคอร์เนล
    • พื้นที่ที่ไม่เข้ารหัสของไฟล์ซิสเต็ม
  • หลังเคอร์เนลเริ่มทำงานแล้ว สภาพแวดล้อมรันไทม์ส่วนใหญ่จะถูกอ่านจาก eMMC และแตกออกไว้ในไดเรกทอรี /sx/local/runtime
  • ในโครงสร้างรันไทม์ bin เก็บไฟล์ปฏิบัติการที่จำเป็นต่อซอฟต์แวร์สแตกของ Starlink, dat เก็บไฟล์คอนฟิก และ revision_info บันทึกเวอร์ชันซอฟต์แวร์และฮาร์ดแวร์ปัจจุบัน
  • user_terminal_frontend ซึ่งจัดการการสื่อสารกับผู้ใช้ภายนอก เขียนด้วย Go ส่วนโปรแกรมที่เหลือส่วนใหญ่เป็นไฟล์ปฏิบัติการ C++ แบบ static compile ที่ไม่มี symbol
  • จากการวิเคราะห์เบื้องต้นที่อิงงานวิจัยก่อนหน้า สถาปัตยกรรม network stack มีความคล้ายกับ DPDK อยู่พอสมควร
    • โดยหลักแล้วโปรแกรม C++ ใน userspace จะประมวลผลแพ็กเก็ตเครือข่ายโดยข้ามเคอร์เนล
    • Linux kernel มีบทบาทหลักในการให้ไดรเวอร์ฮาร์ดแวร์พื้นฐานและการจัดการโปรเซส
  • ซอฟต์แวร์หลักที่ดึงจาก UTA ยังมีฟังก์ชันที่ดูเหมือนเป็นของดาวเทียมหรือเกตเวย์ภาคพื้นรวมอยู่ด้วย
    • จากการ reverse engineering เบื้องต้น ระบบดูเหมือนจะระบุ ประเภทอุปกรณ์ จากอุปกรณ์ต่อพ่วงฮาร์ดแวร์ระหว่างการเริ่มระบบ
    • จากนั้นจึงโหลดและรันลอจิกที่ตรงกับประเภทอุปกรณ์นั้น

การอีมูเลตด้วย QEMU

  • DARKNAVY ได้สร้าง สภาพแวดล้อมอีมูเลชันบน QEMU สำหรับเฟิร์มแวร์ Rev3 เพื่อให้วิเคราะห์ UTA ต่อเนื่องได้ง่ายขึ้น
  • ในสภาพแวดล้อมนี้ พวกเขาสามารถรันและดีบักซอฟต์แวร์บางส่วนที่โต้ตอบกับเอนทิตีภายนอกได้สำเร็จ
    • httpd
    • WebSocket
    • บริการ gRPC

ชิปความปลอดภัย STSAFE-A110

  • นอกจาก SoC หลักแล้ว UTA ยังติดตั้งชิปความปลอดภัยเฉพาะทาง STSAFE-A110
    • ชิปนี้อ้างระดับความปลอดภัย CC EAL5+
    • ต่างจาก SoC แบบคัสตอม เพราะสามารถซื้อได้อย่างถูกกฎหมายภายใต้ NDA
  • ในเฟิร์มแวร์ UTA มีโปรแกรม userspace ชื่อ stsafe_cli ที่ทำหน้าที่จัดการการโต้ตอบกับชิปนี้
  • จากผลการ reverse engineering ดูเหมือนว่า STSAFE จะให้ความสามารถหลักดังต่อไปนี้
    • ตัวระบุเฉพาะของอุปกรณ์แต่ละเครื่อง หรือ UUID
    • การจัดการใบรับรอง public key stsafe_leaf.pem ซึ่งคาดว่าใช้สำหรับการยืนยันตัวตนในการสื่อสารกับดาวเทียม
    • การสร้าง symmetric encryption key สำหรับการส่งข้อมูลของผู้ใช้
  • ชิปนี้ทำหน้าที่เป็น root of trust เพิ่มเติมที่แยกจากกลไก secure boot ของ SoC และสอดคล้องกับแนวทางการออกแบบความปลอดภัยของระบบ embedded สมัยใหม่

Ethernet Data Recorder และคีย์ SSH

  • ระหว่างการวิเคราะห์พบโปรแกรมชื่อ Ethernet Data Recorder ซึ่งหากดูจากชื่อและหน้าที่อย่างเดียวอาจถูกสงสัยว่าเป็นแบ็กดอร์สำหรับดักจับข้อมูลผู้ใช้
  • แต่เมื่อตรวจสอบรายละเอียด พบว่าโปรแกรมนี้บันทึกแพ็กเก็ตเครือข่ายบางประเภทด้วยกลไกคล้าย pcap_filter
    • ตัวอย่างกฎการจับข้อมูลรวมถึงเงื่อนไข udp and dst port 10017 และโฮสต์ปลายทางแบบ multicast บางรายการ
    • เมื่ออิงจากเบาะแสอื่นในเฟิร์มแวร์ แพ็กเก็ตเหล่านี้เกี่ยวข้องกับ telemetry ของดาวเทียม
  • ทราฟฟิกทั้งหมดที่ถูกจับจะถูกเข้ารหัสด้วยคีย์ฮาร์ดแวร์ที่ฟิวส์ไว้ใน SoC
  • จากข้อมูลที่มีอยู่ในตอนนี้ ยังยากจะสรุปว่าฟังก์ชันนี้เก็บ ข้อมูลความเป็นส่วนตัวของผู้ใช้
  • ระหว่างการ initialize อุปกรณ์ หากระบบระบุตัวเองว่าเป็นเทอร์มินัลผู้ใช้ สคริปต์เริ่มต้นระบบจะเขียน SSH public key จำนวน 41 คีย์ลงใน /root/.ssh/authorized_keys โดยอัตโนมัติ
    • พอร์ต 22 ของ UTA เปิดไว้บนเครือข่ายท้องถิ่นตลอดเวลา
    • การมีคีย์ล็อกอินที่ไม่ทราบที่มาจำนวนมากเช่นนี้ในผลิตภัณฑ์สำหรับผู้ใช้ถือว่าน่าสังเกต

บริบทด้านความปลอดภัยของระบบอินเทอร์เน็ตผ่านดาวเทียม

  • เมื่อเทคโนโลยีดาวเทียมยังคงพัฒนาและถูกนำไปใช้ในหลายอุตสาหกรรม องค์ประกอบแต่ละส่วนของ Starlink และระบบอินเทอร์เน็ตผ่านดาวเทียมอื่น ๆ อาจกลายเป็นพื้นที่สำคัญสำหรับปฏิบัติการโจมตีและป้องกันในอนาคต
  • ในด้านความมั่นคงปลอดภัยอวกาศ นักพัฒนาและแฮ็กเกอร์ไม่ได้ต้องรับมือแค่โลกดิจิทัลเท่านั้น แต่ยังต้องเผชิญกับ ข้อจำกัดของฟิสิกส์อวกาศ ด้วย
    • การควบคุมผิดพลาดเพียงครั้งเดียวอาจทำให้สูญเสียการติดต่อกับเป้าหมายไปอย่างถาวร

เอกสารอ้างอิง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-05-11
ความคิดเห็นบน Hacker News

  • ถ้าระบบใส่ คีย์สาธารณะ SSH 41 คีย์ ลงใน /root/.ssh/authorized_keys ให้อัตโนมัติเมื่อระบุได้ว่าเป็นเทอร์มินัลผู้ใช้ตอนเริ่มต้นระบบ ก็ยิ่งทำให้อยากรู้ว่าใครบ้างที่ ไม่มี สิทธิ์ root เข้าถึงเทอร์มินัลผู้ใช้ “ของฉัน”

    • น่าจะเป็นตัวผู้ใช้เองละมั้ง
      ถ้ามองจริงจังขึ้น ก็ไม่ต่างจากการมี ระบบบริหารจัดการระยะไกล บนเราเตอร์ที่ ISP ให้มามากนักหรือเปล่า แม้ SpaceX จะเข้าถึงเทอร์มินัลผู้ใช้โดยตรงไม่ได้ แต่ก็ยังสามารถจับทราฟฟิกได้จากดาวเทียมหรือสถานีภาคพื้นดิน
    • สงสัยว่าใครจะเหมาะที่สุดในการเชื่อมโยงบุคคลที่เพิ่งมีส่วนเกี่ยวข้องกับงานพิเศษของรัฐบาลเข้ากับคีย์บางส่วนในชุดนี้ มีข้อมูลหลุดดี ๆ อยู่บ้างเหมือนกัน
    • จำนวน 41 คีย์อาจไม่ใช่เรื่องน่ากังวลเสมอไปก็ได้ อาจเป็น อินสแตนซ์เซิร์ฟเวอร์ใน 41 ภูมิภาค ที่แต่ละตัวมีคีย์ของตัวเอง และ Starlink ก็เป็นบริการระดับโลก จึงดูเป็นเรื่องธรรมชาติ
      กลับกัน ถ้า 41 อินสแตนซ์นั้น แชร์คีย์เดียวกัน นั่นน่าจะน่ากังวลกว่า
    • authorized_keys ของผมที่เป็นผู้ใช้ส่วนตัวคนเดียวก็มี 25 บรรทัดแล้ว มี YubiKey คนละอันสำหรับแล็ปท็อปแต่ละเครื่อง คีย์ของ iPad กับ iPhone และคีย์ Secure Enclave ของ Mac
      Starlink ก็น่าจะมีผู้ดูแลระบบมากกว่า 1–2 คน ดังนั้นคีย์สาธารณะสัก 100 คีย์ก็ถือว่าสมเหตุสมผล
    • ตัวเลือกนี้เข้าใจยากจริง ๆ ที่ทำงานปัจจุบันของผมแจกจ่ายคีย์ SSH ของนักพัฒนาเฉพาะให้กับอุปกรณ์ที่ลง เฟิร์มแวร์ DEV หรือ QA เท่านั้น ส่วนอิมเมจโปรดักชันมีการเซ็น และปิด SSH ไว้ทั้งหมด
      เรามีซอฟต์แวร์เข้าถึงระยะไกลแยกต่างหากเพื่อวินิจฉัยปัญหาทางวิศวกรรมบนอุปกรณ์โปรดักชัน และสามารถเปิด REPL ได้ แต่ถูกควบคุมด้วยการควบคุมสิทธิ์และการอนุมัติจาก DevOps

  • การสนทนาก่อนหน้าของโพสต์คล้ายกัน: Teardown of the SpaceX Starlink User Terminal https://news.ycombinator.com/item?id=25277171 (2 ธันวาคม 2020 — 158 คะแนน, 138 ความเห็น)

  • ถ้าเอาคีย์สาธารณะ 41 คีย์มาเผย ก็น่าจะตรวจสอบได้ว่ามีนักพัฒนาคนไหนใช้บ้าง

  • https://web.archive.org/www.darknavy.org/blog/a_first_glimps...

  • น่าประหลาดใจที่แพ็กเก็ตทั้งหมดถูกประมวลผลใน user space
    ถ้าต้องจัดการทราฟฟิก 1Gbps ด้วยแพ็กเก็ต UDP ขนาด 100 ไบต์ ก็ต้องประมวลผล 1 ล้านแพ็กเก็ตต่อวินาที ถ้าเป็น CPU 1GHz ก็มีได้แค่ 1000 ไซเคิลต่อแพ็กเก็ต
    ทำได้ก็จริง แต่คงไม่ง่าย เว้นแต่ว่าวิศวกรจะชอบเขียนแอสเซมบลีด้วยมือและคิดสารพัดเทคนิคตาราง lookup

    • ปกติซอฟต์แวร์จะจัดการแพ็กเก็ตแรก ๆ และเมื่อ endpoint ถูกสร้างแล้ว flow หลังจากนั้นจะถูกส่งต่อไปให้ฮาร์ดแวร์ รูปแบบบางอย่างก็อาจถูกจัดการในซอฟต์แวร์เสมอ
      ซอฟต์แวร์นั้นอาจเป็นเคอร์เนลที่แพตช์แล้ว หรืออาจเป็น การบายพาสเคอร์เนลแบบ XDP ก็ได้ เป็นการเดาจากประสบการณ์ที่เคยแตะ DPDK หรือของคล้ายกันแบบผิวเผินในเราเตอร์/เกตเวย์เคเบิลโมเด็ม Intel Puma
    • สำหรับการส่งต่อ วิธีแบบ DPDK อาจเร็วกว่าเพราะลดการคัดลอกบัฟเฟอร์
      Starlink อยู่ราว 25–200Mbps และแพ็กเก็ตเฉลี่ยก็ใหญ่กว่า 7–8 เท่า ดังนั้นอย่างมากก็ประมาณ 36,000 แพ็กเก็ตต่อวินาที ซึ่ง CPU 1GHz ก็รับมือได้ค่อนข้างสบาย
    • ไม่เห็นว่าทำไมมันต้องมีประสิทธิภาพแย่กว่าการประมวลผลแพ็กเก็ตในเคอร์เนล มีวิธีแมปคิวฮาร์ดแวร์ไปยัง user space และในบทความก็บอกว่าระบบเป็น โครงสร้างคล้าย DPDK
      ถึงจุดนั้นแล้ว ก็ไม่เห็นว่าทำไมการที่โค้ด polling อยู่ในเคอร์เนลหรือไม่ถึงจะสำคัญ
    • 100 ไบต์เหรอ? Starlink ใช้ MTU 1500 ไบต์ แบบทั่วไป
    • การประมวลผลใน user space ช่วยเลี่ยง memcpy เพิ่มอีกครั้งได้ จึงเร็วกว่าเยอะ

  • อยากให้แก้คำผิดในชื่อเรื่อง ตอนนี้เขียนว่า “Ternimal”

    • เป็นปัญหา keming แบบคลาสสิก

  • สงสัยว่าเริ่มทำเรื่องแบบนี้กันอย่างไร วิศวกรรมย้อนกลับยาก และการเล่นกับฮาร์ดแวร์มักแพงมาก หรือไม่ก็เก่าจนไม่มีการพัฒนาต่อแล้วเป็นส่วนใหญ่ แม้จะมีข้อยกเว้นก็ตาม

    • หนึ่ง ซื้อของมาก่อน สอง แกะออก สาม คิดหาวิธีเจาะเข้าไป สี่ ลองทำจริง ห้า ทำพังแล้วสบถ
      ปกติจะมี UART แต่ดูเหมือนเทอร์มินัล Starlink ไม่มี UART คนนี้เลยถอด ชิปหน่วยความจำ eMMC ออกมาแทน โดยพื้นฐานก็เหมือนการ์ด microSD ที่บัดกรีติดไว้
    • คงต้องเรียน วิศวกรรมฮาร์ดแวร์ สักหน่อยก่อน ถ้าไม่รู้ว่าชิ้นส่วนทำอะไรและควรจัดการอย่างไร วิศวกรรมย้อนกลับก็ยาก

  • มีประโยคว่า “DARKNAVY built a basic QEMU-based emulation environment for the Rev3 firmware” เลยสงสัยว่ามีเอกสารหรือโซลูชันสำเร็จรูปสำหรับ จำลองการทำงาน ของเฟิร์มแวร์ที่เชื่อมต่อกับอุปกรณ์ภายนอกอย่าง GPS หรือไม่

    • https://android.googlesource.com/platform/external/qemu/+/2d...
      Android Emulator เป็น downstream ของ QEMU emulator โดยเพิ่มการรองรับการบูตอุปกรณ์ Android และจำลองฮาร์ดแวร์ Android ทั่วไป (OpenGL, GPS, GSM, เซ็นเซอร์) รวมถึงอินเทอร์เฟซ GUI Android Emulator ขยาย QEMU ในหลายรูปแบบ

  • สนใจว่าถ้าต้องการ ป้องกันการวิศวกรรมย้อนกลับ เฟิร์มแวร์ในผลิตภัณฑ์ควรป้องกันอย่างไร มีเอกสารที่แนะนำเทคนิคที่ SpaceX ใช้หรือเปล่า?

    • ขั้นแรกคงเป็นอะไรทำนองเฟิร์มแวร์ที่เข้ารหัส แต่ดูเหมือน SpaceX จะไม่ทำอะไรเลย หรือไม่ก็แค่ตอบสนองภายหลัง ก่อนที่ใครจะเผยแพร่การโจมตีโดยใช้พินเหล่านั้น ก็ยังมี พินดีบัก อยู่ด้วย
    • อย่างน้อยควรเข้ารหัส rootfs ด้วยค่าลับที่ดึงออกจาก secure element ได้ยาก ถ้าก้าวไปอีกขั้นก็ใช้ของอย่าง TrustZone ของ ARM เพื่อซ่อนงานที่อ่อนไหว เช่น bootloader, การถอดรหัส, การเซ็นอิมเมจ
      จากที่สามารถ dump filesystem ออกมาได้ตรง ๆ ดูเหมือน SpaceX จะไม่ได้ใส่การป้องกันอื่นมากนักนอกจาก bootloader ที่กล่าวถึงในบทความ
    • ในฐานะคนที่เคยใช้ผลิตภัณฑ์ดี ๆ หลายตัวแต่เฟิร์มแวร์แย่ ถ้าไม่มีเหตุผลที่แข็งแรง ใช้งานได้จริง และผ่านการวิเคราะห์มามากพอ ก็ขอร้องว่าอย่าทำแบบนั้นเลย
      ผมคิดว่าเอาทรัพยากรไปใช้ในทางที่เป็นประโยชน์กับทุกคนและทำให้ผลิตภัณฑ์ดีขึ้นจะดีกว่า สำหรับผู้ใช้ขั้นสูง ความเป็นไปได้ในเชิงทฤษฎีที่จะปรับแต่งผลิตภัณฑ์ได้ แม้แต่ในแบบที่ผู้ผลิตไม่เคยคิดถึง ก็อาจเป็นข้อดีอย่างมาก
      จากมุมมองผู้ใช้ปลายทางสายเทคนิค มันดูเป็นแบบนี้: ผมเหนื่อยและหดหู่นิด ๆ จริง ๆ ที่ต้องแฮ็กอุปกรณ์เพื่อให้ใช้งานได้ถูกต้อง ตั้งแต่หลอดไฟ เครื่องให้อาหารแมว และตอนนี้ก็เครื่องกรรเชียงบก
    • ถ้าใช้ Linux อยู่ ก็อาจนำไปสู่ การละเมิด GPL ได้

  • ถ้าอิงจากโค้ดเบสที่แชร์กับจรวดก็คงเจ๋งนะ?

    • ถ้าพูดให้เจ๋งกว่านั้น น่าจะเป็นโค้ดเบสที่แชร์กับดาวเทียม หรือไม่ก็อาจเป็น simulator ของดาวเทียม ไม่ว่าอย่างไรก็คืออะไรสักอย่างที่ต้องส่ง telemetry
    • ไม่ใช่หรอก มันอิง OpenWRT