# 스타링크 사용자 터미널 분해

> Clean Markdown view of GeekNews topic #20831. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=20831](https://news.hada.io/topic?id=20831)
- GeekNews Markdown: [https://news.hada.io/topic/20831.md](https://news.hada.io/topic/20831.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-05-11T10:00:47+09:00
- Updated: 2025-05-11T10:00:47+09:00
- Original source: [darknavy.org](https://www.darknavy.org/blog/a_first_glimpse_of_the_starlink_user_ternimal/)
- Points: 1
- Comments: 1

## Topic Body

- **SpaceX**의 **스타링크 사용자 터미널**은 지구 저궤도 위성 인터넷 연결의 핵심 하드웨어임
- 사용자 단말기를 분해해보면, **무선 주파수(RF) 프런트엔드**와 **자체 설계 SoC**가 주요 부품임
- 펌웨어 분석 결과, 대부분의 핵심 소프트웨어는 **커널 우회 사용자 공간 네트워크 처리** 및 일부 암호화 기능을 포함함
- **STSAFE-A110** 보안 칩이 추가 인증 루트 역할을 하며, 데이터 암호화 및 고유 식별 제공임
- 이 터미널에는 다수의 **SSH 공개키** 설정과 의심스러운 패킷 기록 도구가 포함되어 있으나, 사용자 프라이버시 침해 단서는 나타나지 않음

---

### 개요
- 스타링크는 **SpaceX**가 제공하는 **저궤도 위성 인터넷 서비스**임
- 사용자는 터미널을 통해 인근 위성에 접속하며, 이는 지상 게이트웨이를 통해 인터넷으로 연결됨
- 신세대 위성은 **레이저 링크**를 활용해 위성 간 통신이 가능해지며, 이 기능은 글로벌 커버리지 및 효율성 향상에 기여함
- 현지 게이트웨이 없이도, 예를 들어 우크라이나와 같이, 인접국 게이트웨이를 이용해 **스타링크 단말기**가 인터넷에 접속할 수 있음
- 본 기사에서는 **DARKNAVY**의 스타링크 사용자 터미널 심층 조사 내용을 간략히 다룸

### 하드웨어 분석
- 하나의 **스타링크 사용자 터미널**은 **라우터**와 **안테나(UTA)** 두 부분으로 구성됨
- DARKNAVY는 싱가포르에서 Standard Actuated(Rev3, GenV2) 터미널을 구매해 **안테나를 분해**함
- 분해 결과, **RF 프런트엔드 칩(주로 STMicroelectronics 생산)** 이 보드 상당 부분을 차지하고 있었음
- 핵심 제어 영역엔 **SpaceX 전용 커스텀 ST SoC(쿼드코어 Cortex-A53)** 가 탑재되어 있으나, 데이터시트 정보는 비공개임
- **Black Hat USA 2022**에서 KU Leuven 소속 Lennert Wouters 박사는 1세대 터미널(GenV1) 해킹 성공 사례를 발표했고, SpaceX는 이후 펌웨어 업데이트로 **UART 디버그 인터페이스**를 비활성화했음
- 하지만 추가적인 방법으로 보안 우회가 재차 성공된 이력이 있음

### 펌웨어 추출 및 분석
- DARKNAVY는 **eMMC 칩**에서 직접 펌웨어를 덤프함
- Rev3 보드에는 별도 eMMC 디버그 핀이 없어, **eMMC를 분리 후 프로그래머로 데이터 추출** 방식 활용함
- 대부분의 펌웨어는 암호화되지 않아, **부트체인(BootROM 제외), 커널, 파일시스템 일부**가 드러남
- 커널 부팅 후에는 런타임 환경을 **/sx/local/runtime**으로 풀어 활용함
- `bin`에는 스타링크 소프트웨어 실행 파일들이, `dat`에는 설정 파일, `revision_info`에는 버전 정보가 들어있음
- 핵심 통신 프로그램 `user_terminal_frontend`는 Go로 개발되어 있고, 그 외 대부분은 심볼 없는 정적 C++ 바이너리임
- **네트워크 스택 아키텍처**가 **DPDK**와 유사하게 커널을 우회해 사용자 공간 프로그램이 패킷 처리를 담당함
- 리눅스 커널은 주로 하드웨어 드라이버 및 프로세스 관리용임
- 일부 소프트웨어에는 원래 **위성 혹은 게이트웨이 용도**로 설계된 기능이 포함되어 있음
- 기기 부팅 시 하드웨어 주변장치로 타입을 식별한 뒤, 해당 로직만 로드해 사용함

### 에뮬레이션
- 지속적 분석을 위해 QEMU 기반 **Rev3 펌웨어 에뮬레이션 환경**을 구축함
- 이 환경에서 `httpd`, `WebSocket`, `gRPC` 등 대외 서비스 일부를 실행하고 디버깅하는 데 성공함
- 주요 실행파일 및 서비스의 작동 원리를 추적 가능해짐

### 보안칩
- 메인 SoC 외에 **STSAFE-A110** 보안칩이 존재하며, **CC EAL5+** 인증을 주장함
- 해당 칩은 NDA에서 구매 가능하고, 펌웨어의 **stsafe_cli** 프로그램이 이 칩과 상호작용함
- 분석 결과 STSAFE 칩이 제공하는 기능으로는 **기기 고유 UUID 부여, 공개키 인증서(stsafe_leaf.pem) 관리, 대칭 키 도출** 등이 있음
- 이 칩은 SoC의 보안 부트와 별개의 **추가 신뢰 루트**로, 현대 임베디드 보안 설계 기준에 부합함

### 이스터에그: Elon이 당신을 지켜보는가?
- 분석 중 **Ethernet Data Recorder** 프로그램이 확인되어, **백도어 가능성**에 대한 의문을 자아냄
- 이 프로그램은 패킷 기록 기능이 있어 보이며, 내부적으로 **pcap_filter 유사 매커니즘**으로 특정 패킷을 캡처함
- 규칙을 보면, 캡처 대상은 주로 **위성 텔레메트리 관련 UDP 패킷** 임을 알 수 있음
- 포착한 트래픽은 **SoC 하드웨어 키**로 암호화되어 저장됨
- 현재까지 사용자 프라이버시 데이터를 수집하는 증거는 확인되지 않음
- 초기화 과정에서 기기가 사용자 단말로 인식되면 **/root/.ssh/authorized_keys**에 41개의 SSH 공개키가 기록되고, 포트 22는 항상 로컬 네트워크에 열려 있음
- 상용 제품에 다수의 미상 공개키가 등록되는 점은 주목할 만함

### 결론 및 전망
- 위성 기술이 다양한 산업 분야에 적용됨에 따라, **스타링크와 같은 위성 인터넷 시스템 구성요소**는 향후 보안 공격 및 방어의 핵심 전장이 될 것으로 예상됨
- 우주 보안의 특성상, 한번의 실수가 **대상과의 영구 통신 두절**로 이어질 수 있으므로 신중한 접근이 요구됨

## Comments



### Comment 38454

- Author: neo
- Created: 2025-05-11T10:00:47+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43933452) 
* 장치 초기화 시, 시스템이 사용자 터미널로 인식되면 초기화 스크립트가 자동으로 41개의 SSH 공개키를 /root/.ssh/authorized_keys 파일에 기록함을 발견함, 포트 22도 항상 로컬 네트워크에 열려 있음, 41개나 되는 키를 쓰는 게 무슨 의미인지 궁금증 생김, 결국 '당신이 소유한' 사용자 터미널에 루트 접근 권한이 없는 사람이 누구인지 의문임
  * 아마 당신일 것임, 더 진지하게 생각해보면, ISP가 제공하는 라우터에 원격 관리 시스템을 두는 것과 크게 다르지 않음, 만약 SpaceX가 사용자 터미널에 접근 권한이 없더라도, 위성이나 지상국에서 트래픽을 모니터링 할 수 있음
  * 최근에 특수 정부 업무에 관련된 사람들과 추적 가능한 SSH 키가 있는지 확인할 만한 최적의 사람이 누구일지 궁금증 생김, 최근 좋은 유출도 있었음
  * 41개 키가 단순히 41개 리전의 동일 서버 인스턴스일 수도 있음, Starlink는 글로벌 서비스이므로 딱히 걱정할 일은 아님, 41개 인스턴스가 하나의 키를 공유한다면 더 걱정할 것 같음
  * 현재 다니는 회사에서는 개발자 SSH 키만 DEV나 QA 펌웨어에 배포함, 프로덕션 이미지는 서명 후 SSH가 아예 비활성화 되어 있음, 프로덕션에서 원격 진단을 위해 별도 소프트웨어를 사용하고, 이 역시 접근권한과 데브옵스의 승인 절차로 관리됨, 그래서 SpaceX의 선택이 의아함
  * 나는 단일 사용자임에도 authorized_keys에 25개의 줄이 있음, 랩탑의 여러 yubikey, 아이패드와 아이폰의 키, 맥의 secure enclave 키 등이 섞여 있음, Starlink에 적어도 1-2명의 시스템 관리자가 더 있을 거라 상상함, 100개 공개키도 그리 어색하지 않은 숫자임
  * 오히려 이게 생각보다 평범하고 보안상 좋은 선택일 수 있음, 수백만 단말기들이 모두 똑같은 키나 소수의 키를 쓰는 것보다는, 시리얼 넘버나 생산시기에 따라 분리된 여러 키를 사용하는 게 나음, 프라이빗 키는 소수 단말기 관리용으로만 사용되고, 키 관리도 분할될 수 있음
  * 이 터미널이 현지 네트워크에 인터넷 연결도 같이 될 때만 외부에서 key로 접근이 가능할 것이라 추측함, SSH 접속을 위해 위성망을 어떻게 거치는지도 궁금함, Starlink가 NAT 등 네트워크 구조를 어떻게 쓰는지도 궁금함
* 이전에 올라왔던 유사 주제로 Starlink 사용자 터미널 분해 글 링크 공유함
* 41개의 공개키를 공개해서 어떤 개발자가 사용하는지 알아본다면 재미있을 것으로 생각함
* Starlink 관련 블로그 포스트 아카이브 링크 공유
* 저자에게 제목의 오타("ternimal")를 수정해 줄 것을 요청함
  * 이런 현상을 keming(글자 간격 불균형) 이슈의 고전적 사례임을 재치있게 언급함
* 모든 패킷이 유저스페이스에서 처리된다는 점이 놀랍게 느껴짐, 1Gbps 트래픽(100바이트 UDP 기준)이면 초당 백만 패킷임, 1GHz CPU는 패킷당 1000사이클만 사용 가능함, 이론상 가능하지만 쉽지 않음, 엔지니어가 어셈블리 직코딩에 온갖 트릭을 총동원해야 할 수준임
  * 논문에 따르면, 네트워크 스택 구조가 DPDK와 유사한 구조로 보이고, 패킷의 커널 바이패스 처리가 핵심임, 실제로는 처음 패킷만 소프트웨어가 처리하고, 세션 성립 이후에는 하드웨어로 넘길 수 있음, 일부 패턴은 계속 소프트웨어에서 처리할 수도 있음, 예전 인텔 Puma 계열 케이블 모뎀 라우터에서도 이와 유사한 방식을 경험했음
  * DPDK 스타일 포워딩의 경우 버퍼 카피가 줄어들어 오히려 더 빠를 수 있음, Starlink는 25-200Mbps 수준이고, 평균 패킷 크기가 7-8배 크다는 점에서 초당 약 3만6천 패킷 수준임, 1GHz CPU에선 감당할 만한 양임
  * 커널에서 패킷 처리하는 것보다 userspace에서 덜 효율적일 이유가 무엇인지 의문임, 하드웨어 큐를 유저스페이스로 매핑하면 커널-유저스페이스 구분이 중요하지 않아짐
  * Starlink의 경우, 100바이트 UDP 패킷보다는 일반 1500바이트 MTU를 사용함
  * userspace에서 패킷을 처리하면 불필요한 메모리 카피가 줄어들어 훨씬 빨라짐
* 이런 장비의 리버스 엔지니어링을 어떻게 시작해야 할지 궁금증을 표현함, 리버스 엔지니어링은 어렵고, 예시 대부분 오래된 혹은 비싸서 하기 어려운 경우가 많음
  * 우선 하드웨어 엔지니어링을 먼저 익혀야 함, 부품의 용도나 특성을 모르면 리버스 엔지니어링 자체가 어려움
  * 첫째는 제품을 직접 사서 분해해야 함, 둘째는 분해 후 뚫을 방법을 생각해야 함, 셋째는 실제로 시도함, 넷째는 망가졌다는 사실에 좌절함, 보통 UART 포트로 진입하는데, Starlink에는 없는 듯 하니 eMMC 메모리 칩을 떼서 분석한 사례임
* QEMU 기반 에뮬레이션 환경에서 외부 장치(GPS 등)에 연결되는 펌웨어 에뮬레이션 참고 자료나 레디 솔루션이 있는지 질문함
  * 안드로이드 QEMU 포크에서 OpenGL, GPS, GSM, 센서 등 다양한 하드웨어와 GUI 인터페이스를 에뮬레이션 한다는 점을 사례로 소개함
* 펌웨어를 리버스 엔지니어링으로부터 보호하는 방법을 배우고 싶음, SpaceX가 사용하는 기술에 대한 입문 자료가 있는지 궁금함
  * 1단계는 펌웨어 암호화와 같은 조치임, SpaceX도 딱히 선제적으로 대응하지는 않고, 꾸준히 발견되면 그때그때 패치하는 듯 함, 예전엔 디버그 핀도 있었음
  * 활용해 본 수많은 제품이 펌웨어 쪽 완성도가 낮은 경우가 많았음, 보안 목적 외에는 굳이 잠그지 말고 모두에게 도움 되는 데에 자원을 쓰길 부탁함, 파워유저는 기기를 직접 수정할 수 있으면 오히려 장점임, 정말 심각한 침해 위험이 없다면, 굳이 쓸데없이 시간 쓰지 않았으면 함, 각종 기기를 필요에 맞게 해킹해야만 하는 현실이 아쉽고 때론 우울함
  * 최소한 루트 파일 시스템을 암호화하면서,도난이나 추출이 어려운 실제 보안 칩의 시크릿 정보를 활용하는 게 기본임, 한층 더 보안 수위를 높이고 싶으면 ARM TrustZone을 이용하여 부트로더, 복호화, 이미지 서명 등 민감한 작업을 격리할 수 있음, 파일시스템을 쉽게 덤프할 수 있다는 것 자체가 SpaceX가 실질적 보호 장치를 사용하지 않는다는 뜻임, 부트로더만 보호되고 그 외엔 노출되어 있음
* 이 장비가 혹시 로켓과 같은 코드베이스를 쓰는지, 신기하다고 느낌을 표현함
  * 오히려 더 멋지게 느낀 부분은 위성과 코드베이스를 공유하거나, 위성 시뮬레이터 정도일 것 같음, 각종 텔레메트리를 보내야 하기 때문임
  * 실제로는 OpenWRT를 기반으로 함
