原星链Starlink路由器的分析和逆向工程

最新推荐文章于 2025-03-18 15:19:31 发布

Jet_58

最新推荐文章于 2025-03-18 15:19:31 发布

阅读量642

点赞数 1

文章标签：智能路由器 linux

原文链接：https://olegkutkov.me/2021/12/25/analysis-and-reverse-engineering-of-the-original-starlink-router/

版权

老实说，我喜欢这个东西的设计。这让我想起了古老的科幻小说中的一些东西。

整个设备看起来坚如磐石且平衡。遗憾的是，这个外壳的设计并不容易打开。没有胶水，但也没有螺丝。

六个挂钩将路由器的金属和塑料部件固定在一起，每侧三个。要打开这个东西，你需要以某种方式推动钩子。这会损坏塑料甚至铝。但我想，这总比没有好。

路由器内部结构

外壳的整个金属部分用作散热器：

比较简单的单板。

印刷电路板

该路由器的核心是流行的 Qualcomm IPQ4018 SoC：四核 ARM Cortex A-7、802.11ac WiFi 5GHz 和 2.4 GHz 支持，均为两个通道。此外，该 SoC 还集成了加密引擎和带有硬件 NAT 和流量引导的交换引擎。

以下是该板的所有组件及其简要说明：

TPS2378实施 IEEE802.3at PoE 标准，可处理高达 100V 的输入。

W25N01GV是一款串行NAND闪存IC。路由器操作系统存储在该芯片上。

老实说，这些双频天线并没有给我留下深刻的印象。当然，它们可以覆盖一个小公寓或几个房间，但仅此而已。

以下是射频罐下面的内容：

SKY8533-11和SKY85743-21是 WiFi RF 前端，实现 LNA、PA 和开关。

主电压转换器是LM5116 。 Starlink PoE 电压为 56 伏，但路由器可以通过网络交换机在 24 伏电压下正常运行。

以太网交换机是QCA8072 – 双端口、10/100/1000 Mbps 三速以太网 PHY。 IPQ807x是IPQ40xx平台的典型解决方案。

GD25Q128B它是一款 SPI NOR 闪存，带有 Qualcomm 引导加载程序、u-boot 和一些附加数据。

最有趣的部分是STSAFE-A芯片。这个特殊的 MCU 提供安全存储、身份验证和一些加密功能，完全受 OpenSSL 支持。 MCU 用于存储单板配置和证书。我将在下面介绍这一点。

重新创建的路由器框图：

不幸的是，我无法追踪 UART 接口。我知道相应的CPU引脚在哪里，但看起来这些引脚不用于串行控制台。再加上TX引脚几乎埋在CPU下面，很难触及。

板上有几个测试点。其中一些与 NAND 和 NOR 有关。有的是电压控制等等。
我检查了所有的测试垫，但一无所获。无论如何，这没什么大不了的。

固件

NOR 和 NAND 都被从电路板上拆除并丢弃。下面的所有数据都是用binwalk和十六进制编辑器找到的。
路由器固件基于OpenWRT，这已经不是什么秘密了。这是 SpaceX 官方存储库：https://github.com/SpaceExplorationTechnologies/starlink-wifi
当然，GitHub 存储库仅包含 GPL 代码，没有任何驱动路由器的 SpaceX 专有组件。

通过分析转储，我发现 SpaceX 遵循典型的 QCA 模式，但有一些细微的差异。
系统从烧入 SoC 的主引导加载程序 (PBL) 启动。该 PBL 正在 NOR 闪存的零地址处寻找辅助引导加载程序 (SBL)。 SBL 初始化硬件（CPU、DDR）并启动主引导加载程序（u-boot）。
u-boot 的目的是支持特定于系统的任务，例如引导环境、固件恢复和操作系统引导。

以下是 Starlink NOR 的简化布局：

分割	偏移量，字节	描述
SBL	0	QCA 辅助引导加载程序
MIBIB	0x40000	分区表
TZ	0x60000	信任区固件
CDT	0x140000	平台内存配置
UENV_0	0x180000	u-boot环境变量0
UBOOT_0	0x190000	u-boot ELF 二进制 0
UENV_1	0x290000	u-boot环境变量1
UBOOT_1	0x2D0000	u-boot ELF 二进制文件 1

信任区固件保护启动过程。这意味着只允许使用“有效”签名的引导加载程序和 Linux 内核。每个引导加载程序都包含一个安全证书。可以使用简单的dd命令提取这些证书。 u-boot证书，例如：

dd if=GD25Q128B@WSON8.BIN of=cert0.der bs=1 skip=4002248 count=1165

此外，还有多个具有不同环境的 u-boot 二进制文件。它可以用于冗余或不同模式。我不知道。
u-boot 源代码在这里：https: //github.com/SpaceExplorationTechnologies/starlink-wifi/tree/master/qca/src/uboot-1.0

看来第一个 u-boot 使用了一些默认环境。偏移量0x180000处的环境变量：

baudrate=115200
bootcmd=bootipq
bootdelay=2
ipaddr=192.168.1.11
burn-fail=0
burn-in=0
count=0

此外，此引导加载程序会加载此处定义的默认环境。

bootcmd=bootipq
bootdelay=2
baudrate=115200
ipaddr=192.168.1.11
serial_number=WISNEW-200600011
default_password=Starlink-pass-111
default_ssid=Starlink_00000000
eth_mac_addr=94:10:3E:E9:7F:D5
wps_device_pin=28680758

相反，辅助 u-boot 在偏移量0x290000处包含工厂配置。

此外，NOR 闪存还包含 WiFi 校准数据，也称为“ART”分区。 QCA WiFi 驱动程序使用此数据；我不会在当前的文章中讨论这一点。

NAND图像

NAND 闪存包含 Linux 内核映像和 rootfs。但获得可用的 NAND 映像有些棘手。
OOB（带外）数据——它是与数据页相邻的备用区域。一般来说，NAND Flash中存在OOB来实现ECC（纠错码）和坏块管理。
我们来看看W25N01GV NAND 数据表。

这意味着每个 2048 个数据页包含一个额外的 64 字节尾部。这些 OOB 块应与实际数据分离并正确处理。
最初，我尝试使用这个 Python 脚本：

import sys

NAND_PAGE_SIZE = 0x800 # 2048 bytes
NAND_PAGE_BLK = 64 # 64 pages per block
NAND_SECTOR_PER_PAGE = 4 # 4 sectors in page
NAND_SECTOR_SIZE = NAND_PAGE_SIZE/NAND_SECTOR_PER_PAGE
OOBLEN = 64

inf = open(sys.argv[1] , "rb")
of = open(sys.argv[2], "wb")

def page2off(pgno):
    return pgno * 0x840 # (NAND_PAGE_SIZE + NAND_SECTOR_PER_PAGE*OOBLEN)

def read_page(inf, blkno, pgno):
    blklen = page2off(NAND_PAGE_BLK)
    fileoff = blklen * blkno + page2off(pgno)

    print "reading block %d page %d: offset %08X" % (blkno, pgno, fileoff)

    inf.seek(fileoff, 0)
    block = inf.read(blklen)
    buf = ""

    for i in range(NAND_PAGE_SIZE):
        buf += block[i]

   return s

for blkn in range(1024):
    for pagen in range(64):
        res = read_page(inf, blkn, pagen)
        of.write(res)

页面大小、扇区数和块数取自数据表。

运行并测试结果：

$ python oob_strip.py W25N01GV@WSON8.BIN test_nand_out.bin

$ file test_out.bin 
test_out.bin: UBI image, version 1

好吧，我们有UBI 了。对于 NAND 来说这是一个相当合理的解决方案。
让我们尝试使用ubi_reader 分析并提取该图像：

$ ubireader_display_info test_out.bin 
UBI File
---------------------
    Min I/O: 2048
    LEB Size: 126976
    PEB Size: 131072
    Total Block Count: 1024
    Data Block Count: 407
    Layout Block Count: 4
    Internal Volume Block Count: 0
    Unknown Block Count: 613
    First UBI PEB Number: 0

    Image: 1911121817
    ---------------------
        Image Sequence Num: 1911121817
        Volume Name:kernel
        Volume Name:ubi_rootfs
        Volume Name:rootfs_data
        PEB Range: 512 - 1023

        Volume: kernel
        ---------------------
        Volume: ubi_rootfs
        ---------------------
        Volume: rootfs_data
        ---------------------
******
    Image: 1899964099
    ---------------------
        Image Sequence Num: 1899964099
        Volume Name:kernel
        Volume Name:ubi_rootfs
        Volume Name:rootfs_data
        PEB Range: 0 - 511

        Volume: kernel
        ---------------------
        Volume: ubi_rootfs
        ---------------------
        Volume: rootfs_data
        ---------------------

很好的结果。这里我们有两个图像，每个图像包含三个体积。

不幸的是，不可能以这种方式提取未损坏的体积。典型的 NAND 总是可能包含一定数量的坏扇区或翻转位。这些错误可以通过 OOB 纠正，通常由 NAND 控制器完成。

正确的解决方案是使用一些真正的硬件 NAND 控制器或nandsim （NAND Flash 模拟器驱动程序）。
我感谢James Hillard找出 nandsim 的正确参数并在这个阶段为我提供帮助。

sudo modprobe nandsim id_bytes=0x98,0xd1,0x90,0x15,0x76,0x14,0x01,0x00 parts=512,512
sudo nandwrite -k -a -o --input-skip=69206016 /dev/mtd1 'W25N01GV@WSON8.BIN'
sudo modprobe ubi mtd=/dev/mtd1,2048,0,2
sudo mount -t ubifs /dev/ubi2_2 /mnt/ubi2_2

现在可以读取数据了。因此，简化的 NAND 布局为：

使用两个相同的映像来实现冗余并简化固件升级过程。

卷 0包含带签名的 Linux 内核FIT 映像。
第 1 卷是带有 OpenWRT 操作系统和 SpaceX 软件的squashfs rootfs 映像。
第2卷很有趣。这是一个带有路由器配置文件的读/写ubifs映像：

nand_extract/ubi2_2
├── etc
│   └── config
│   └── WifiConfig
├── upper
│   └── etc
│   ├── config
│   │   ├── dhcp
│   │   ├── dropbear
│   │   ├── ecm
│   │   ├── macsec
│   │   ├── network
│   │   ├── nss
│   │   ├── ripd
│   │   ├── skb_recycler
│   │   ├── ssid-steering
│   │   ├── system
│   │   ├── thermal
│   │   ├── ubootenv
│   │   ├── upnpd
│   │   ├── WifiConfig
│   │   └── wireless
│   ├── conntrackd
│   │   └── conntrackd.conf
│   ├── crontabs
│   │   └── root
│   ├── dnsmasq.conf
│   ├── dropbear
│   │   ├── authorized_keys
│   │   └── dropbear_rsa_host_key

***

该卷是 OpenWrt Extroot的一部分并安装为/overlay

/etc/config/WifiConfig它是 SpaceX 专有软件使用的二进制文件。
有趣的是，该文件受到一组权限的保护。除了主人之外，没有人能读到它。

当然，文件格式未知，但看起来非常简单。
这就是我想到的：
该文件用于在运行时生成 OpenWrt uci 无线配置。

核心

FIT 映像包含多个设备树 blob、Linux 内核和 Starlink 路由器证明证书。

$ binwalk kernel-starlink

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
40 0x28 device tree image (dtb)
268 0x10C gzip compressed data, maximum compression, has original file name: "Image", from Unix, last modified: 2021-06-11 21:41:35
3754412 0x3949AC device tree image (dtb)
3779480 0x39AB98 device tree image (dtb)
3798724 0x39F6C4 device tree image (dtb)
3818016 0x3A4220 device tree image (dtb)
3839952 0x3A97D0 device tree image (dtb)
3865044 0x3AF9D4 device tree image (dtb)
3889968 0x3B5B30 device tree image (dtb)
3917528 0x3BC6D8 device tree image (dtb)
3936928 0x3C12A0 device tree image (dtb)
3961960 0x3C7468 device tree image (dtb)
3983688 0x3CC948 device tree image (dtb)
4003052 0x3D14EC device tree image (dtb)
4033728 0x3D8CC0 device tree image (dtb)
4058660 0x3DEE24 device tree image (dtb)
4083428 0x3E4EE4 Certificate in DER format (x509 v3), header length: 4, sequence length: 1161
4084593 0x3E5371 Certificate in DER format (x509 v3), header length: 4, sequence length: 947
4085544 0x3E5728 Certificate in DER format (x509 v3), header length: 4, sequence length: 945
4089868 0x3E680C Certificate in DER format (x509 v3), header length: 4, sequence length: 1161
4091033 0x3E6C99 Certificate in DER format (x509 v3), header length: 4, sequence length: 947
4091984 0x3E7050 Certificate in DER format (x509 v3), header length: 4, sequence length: 945

安全启动链使用这些证书来验证内核的有效性。

为什么有这么多 dtb 部分？单一平台需要单一的 dtb。这些 dtb 支持不同的 QCA 参考平台。
这只是一个典型的解决方案。看起来 SpaceX 没有改变 OpenWrt 构建系统中的任何内容。

Linux 内核映像是 gzip 压缩的，提取构建配置是基本的：

$ binwalk kernel-starlink | grep Image -A1
268 0x10C gzip compressed data, maximum compression, has original file name: "Image", from Unix, last modified: 2021-06-11 21:41:35
3754412 0x3949AC device tree image (dtb)

图像大小： 3754412 – 268 = 3754144

图像提取：

dd if=kernel-starlink of=linux_image.gz bs=1 skip=268 count=3754144

gzip -d linux_image.gz

该配置也是 gzip 压缩的。让我们找到它吧。

$ binwalk linux_image | grep gzip -A1 -B1
5236966 0x4FE8E6 MPEG transport stream data
5949576 0x5AC888 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
6174471 0x5E3707 xz compressed data
--
7370351 0x70766F LZMA compressed data, properties: 0xC0, dictionary size: 0 bytes, uncompressed size: 64 bytes
7392936 0x70CEA8 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
7761920 0x767000 ELF, 32-bit LSB shared object, ARM, version 1 (SYSV)

第一个位于0x5AC888 ：

dd if=linux_image of=kernel_config.gz bs=1 skip=5949576 count=224895

gzip -d kernel_config.gz

$ head -n10 kernel_config 
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.4.60 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y

Linux内核4.4.60！

根文件系统

基本系统与“vanilla”OpenWrt 没有太大区别。除了一件大事。
我可以在脚本中找到一些与 SpaceX 相关的自定义内容。其中一些包含精美的代码和注释：

# SpaceX: As a failsafe, we limit the uptime of our devices to 20 days. After 20 days
# this script will stop petting the watchdog, which will lead to it rebooting after
# about 2 minutes. To do this, we first take manual control of the watchdog from
# procd, using the ubus commands.
pet_watchdog() {
    # Wait one minute to let ubus system fully boot
    sleep 60

    echo "Start Petting Watchdog"
    ubus call system watchdog '{"magicclose": true}'
    ubus call system watchdog '{"stop": true}'

    # Pet every 10 seconds for 20 days (1,728,000 seconds)
    for var in `seq 1 172800`; do echo 1 ; sleep 10; done > /dev/watchdog
}

那么，Starlink 互联网每 20 天就会中断约 1 分钟吗？

但最有趣的二进制文件是/usr/sbin/wifi_control

这是一个巨大的应用程序，可以控制一切，整个路由器的操作。这个应用程序是用Go编写的，很难反汇编。
我可以看出 wifi_control 负责（至少）：

局域网配置
iptables防火墙配置
无线网络配置
热管理
统计和遥测管理
强制门户
与移动应用程序交互

似乎许多参数（例如 IP 地址和 URL）只是硬编码在应用程序中。

该 wifi_control 最初从/etc/init.d/boot脚本：

wifi_control --board=$(cat /etc/board) --early_init

这会在 /etc/config 中创建初始配置并退出 wifi_control。
wifi_control 守护进程应用程序从单独的初始化脚本/etc/init.d/wifi_control
还有来自 crontab、reset 和 sysupgrade 脚本的其他调用。

另外，我还可以找到很多有趣的字符串：

rx_beam_state
tx_beam_state
modulation
snow_active_override
auto_power_snow_melt_enabled
signal_strength
signal_level_dbm

看起来可以从 Dishy 中获得很多很酷的统计数据。

现在是时候运行一些软件了。

正在启动

缺少 UART 毫无乐趣可言。我决定使用第 3 方硬件并运行 Starlink 路由器软件。
好在 ipq40xx 如此流行，所以有很多路由器可供实验。我决定使用我碰巧拥有的 IPQ4019 参考板 AP.dk04。 IPQ4019 它是与高端系列略有不同的 SoC，共享相同的 CPU 内核和基本模块。这意味着它几乎完全兼容并且可以使用。

有两个显着差异：
– 5端口以太网交换机QCA8075代替2端口QCA8072
– 并行 NAND 而不是串行。

但这不是问题。

是否可以在不同的板上运行 Starlink 的 u-boot ？是的，这是可能的。
但这并不那么有趣。引导加载程序验证闪存 JEDEC id 并查找安全芯片。

有趣的是，第一个 u-boot 映像是 2012 年版本，第二个是 2016 年版本。

我决定从 SpaceX GitHub 存储库构建 u-boot 和 Linux 内核，并使用 Starlink rootfs 启动

构建 Starlink OpenWrt

SpaceX 存储库基于相当古老的OpenWrt 15.05.1 “Chaos Calmer”版本。

我无法在 Linux Mint 20.2 上编译该存储库，因此我决定在 Ubuntu 16.04 (LTS) 环境中使用Docker 。我不会介绍 Docker 的安装和初始配置。

这是我的Dockerfile ：

FROM ubuntu:16.04

ARG UID=1000
ARG GID=1000

# OpenWRT's dl directory.
ENV DLDIR /opt/dl

RUN apt-get update && apt-get install -y \
        apt-utils \
        build-essential \
        curl \
        ocaml \
        device-tree-compiler \
        iputils-ping \
        file \
        gawk \
        git \
        less \
        libjansson-dev \
        libncurses5-dev \
        libssl-dev \
        nodejs \
        python-m2crypto \
        python-minimal \
        sharutils \
        subversion \
        unzip \
        vim \
        squashfs-tools \
        wget

RUN groupadd -g $GID user && \
useradd --create-home --gid $GID --uid $UID user

WORKDIR /var/build/starlink-wifi

将 Dockerfile 放入 Starlink 存储库顶部目录并运行：

docker build . -t starlink-wifi-build -f Dockerfile

运行 Docker：

src_root=$(realpath "$(dirname $0)")

docker run -i $(tty -s && echo -t) \
    -v ${src_root}:/var/build/starlink-wifi \
    -v /opt/dl \
    -v ~/.gitconfig:/etc/gitconfig \
    -u $(id -u):$(id -g) \
    starlink-wifi-build "$@"

现在是时候构建固件了：

./scripts/feeds update -a
./scripts/feeds install -a
cp spacex_openwrt.config .config
make oldconfig

运行make menuconfig并转到Boot Loaders ---& gt ;
确保 uboot-ipq40xx........................ U-boot for ipq40xx based platforms 已选择，其他所有内容均未选择。

然后：

cp nand_extracted_kernel_config target/linux/ipq806x/config-4.4
make V=s -jN

如果需要N ，则计算线程数。通常，该值等于 CPU 核心的数量。
如果构建失败，请使用 -j1 重新运行以查看错误。

就我而言，正确的 Linux 内核是 bin/ipq806x/openwrt-ipq806x-qcom-ipq4019-ap.dk04.1-c1-fit-uImage.itb 因为我在 AP.DK04 上运行
从技术上讲，这些 .itb 文件是 Linux 内核 + 设备树 blob + 可选的 initramfs

运行固件

我决定使用单个 NOR 闪存并采用以下布局： 896k(SBL),64k(u-boot-env),600k(u-boot),20m(rootfs)
最好对齐这些尺寸。这就是为什么我必须在 u-boot 和 rootfs 之间放置 111496 字节。

SBL和u-boot env是从原始DK04 QSDK固件借用的。

dd if=/dev/zero of=111496_zero.bin bs=1 count=111496
cat qca_bootloader_only.bin u-boot.bin 111496_zero.bin nand_extract/squashfs-starlink > starlink_nor.bin

没有内核。我决定通过网络启动它。为什么不呢？
我把我的 openwrt-ipq806x-qcom-ipq4019-ap.dk04.1-c1-fit-uImage.itb 到本地TFTP服务器目录。

生成的 starlink_nor.bin 被烧录到备用 NOR 闪存。

开发板启动后，需要在u-boot控制台中进行一些配置：

setenv serverip 192.168.1.150
set mtdparts "mtdparts=78b5000.spi:896k(QCA-bootloader),64k(u-boot-env),600k(u-boot),20m(rootfs)"
setenv bootargs "rootfstype=squashfs root=/dev/mtdblock3 ro noinitrd init=/init console=ttyMSM0,115200 mtdparts=spi0.0:896k(QCA-bootloader),64k(u-boot-env),600k(u-boot),20m(rootfs)"
saveenv

192.168.1.150 这是我的 TFTP 服务器的地址。

现在是时候启动操作系统了：

tftpboot 84000000 openwrt-ipq806x-qcom-ipq4019-ap.dk04.1-c1-fit-uImage.itb
bootm

内核正在启动，应该挂载并运行 Starlink 的 rootfs。

耶！

可以配置网络和互联网访问：

brctl addbr br-lan
brctl addif br-lan eth0
ip addr add 192.168.1.21/24 broadcast 192.168.1.255 dev eth0
ip link set dev eth0 up
ip route add default via 192.168.1.1

这些命令中有一半本应自动执行，但出了问题。

好的，现在互联网可以工作了，但是 wifi_control 呢？

当然！它尝试访问安全芯片但失败，因为我的主板上没有这样的芯片

我认为是时候检查一下安全芯片了。

STSAFE-A110认证芯片

STSAFE-A110 采用 UFDFPN8 2×3 mm 封装。我决定构建一个适配器以方便连接。

此外，还需要最少一组组件：旁路电容器和复位电路。

C2 和 R3 生成所需长度的复位信号。查看第 26 页的数据表。

连接到Raspberry Pi I2C总线的设备：

快速测试：

$ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

它还活着！ 0x20 这是 STSAFE 的正确地址

STSAFE-A110 有一个官方 ST 库和工具集： https ://www.st.com/en/embedded-software/stsw-stsa110-ssl.html
包装内容：
文档——文档，非常有用
src和lib – 设备接口库
示例– 示例工具和测试套件

该库可以在 Raspberry Pi 上编译。只需要 OpenSSL 标头。
下载并解压包。然后进入STSAFE-A_OpenSSL_Engine_V1.2.0

打开 make.in 并编辑 OpenSSL 路径。在标准 SSL 安装的情况下，应该如下所示：

OPENSSL_INC = /usr/include/openssl
OPENSSL_LIB = /usr/lib
OPENSSL_BIN = /usr/bin

然后运行：

make
sudo make install
sudo ldconfig

接下来创建文件openssl.conf.stsafe包含以下内容：

openssl_conf = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
Stsafe = Stsafe_section

[Stsafe_section]
dynamic_path = /usr/lib/engines-1.1/Stsafe.so
engine_id = Stsafe
default_algorithms = ALL
init = 1

现在我们准备测试：

OPENSSL_CONF=./openssl.conf.stsafe openssl engine Stsafe

命令输出中应该显示配对成功：

Main : Now let's pair ... 
About to call StSafeA_LocalEnvelopeKeySlotQuery: 0x2907d0, 0x2907e0, 0x2907f0 
StSafeA_LocalEnvelopeKeySlotQuery: StatusCode=0 slot 0: presence flag =1 
StSafeA_LocalEnvelopeKeySlotQuery: StatusCode=0 slot 1: presence flag =1 
StatusCode=0 ---HostKeySlot = 0xbef11ccc, pStSafeA->InOutBuffer.LV.Data = 0xb6ab2430
HostKeySlot->HostKeyPresenceFlag: 1 
Main : stsafe_pairing success

下一步是运行test suit以获得一些有用的输出。

cd Examples/stsafe_engine_test_suite/

请注意，某些测试可能会失败。我在test_stsafe_engine.c

构建并运行该工具：

make
./test_stsafe_engine

这就是我得到的：

抱歉部分模糊

这些十六进制数据可以复制到文本文件，然后转换为有效的pem文件：

cat device_cert.txt | xxd -r -p | openssl x509 -inform DER -out device_cert.pem -outform PEM

结果：

wifi_control怎么样？让我们在树莓派上运行它吧！
有可能吗？当然，Starlink 路由器和 Raspberry Pi 都使用“相同”的 32 位 ARM CPU 内核。
另外，Go 二进制文件非常独立，因为有内置的运行时。

先做一些准备工作。

# echo "v1 > /etc/board
# echo "2021.19.0.mr2666-prod" > /etc/version    # or version of your firmware
# ln -s /bin/true /usr/local/bin/devinfo_access

将WifiConfig从真实系统复制到您的 Raspberry /etc/

树莓派使用第二条I2C总线/dev/i2c-1
但 wifi_control 正在寻找 /dev/i2c-0
使用 udev 别名很容易修复。创造 /etc/udev/rules.d/99_sr0.rules 包含以下内容： KERNEL=="i2c-1", SYMLINK+="i2c-0"

然后运行 sudo udevadm control --reload-rules; sudo udevadm trigger 。
现在我们可以出发了。

这里正在发生很多有趣的事情！
首先，wifi_control 在/etc/config/中创建了许多文件。
然后它启动遥测线程并连接到其中一台 Starlink 服务器。
此外，我还可以看到两个 gRPC 服务器的创建。我可以看出这个进程正在尝试访问位于 Dishy (192.168.1.100) 的另一个 gRPC 服务器。
它看起来像gRPC ，而 protobuf 是 Starlink 世界中主要的 API/通信协议。

现在我尝试逆向 I2C 通信协议来了解 wifi_control 如何与 STSAFE 交互。该总线上有大量数据流量。
另外，我想弄清楚所有这些证书是如何工作的。以及如何与星链服务器通信。请求固件更新文件之类的东西会很棒。

敬请关注！