Workflow¶

最近会把与D2C文章对应的“实验环境部署”单独整理一遍

(1) DCATOR 攻击原型硬件配置

为三种不同的卫星网络（Iridium, Starlink DTC, 3GPP NTN）分别构建了一套攻击原型:

alt text

测试平台	攻击目标 (Target UE)	DCATOR 攻击原型硬件 (图10中橙色框)
1. Iridium (真实网络)	1x Iridium 9555 卫星电话	控制器: 1x 笔记本电脑嗅探器: 1x USRP B210 探测器: 1x LTE 安卓手机卫星定位器: 1x Iridium 9555 卫星电话
2. Starlink DTC (仿真)	1x LTE 手机	控制器: 1x 笔记本电脑嗅探器: 1x USRP 探测器: 1x LTE 手机卫星定位器: 1x LTE 手机
3. 3GPP NTN (仿真)	1x AMARI Callbox (天线)	控制器: 1x 笔记本电脑嗅探器: 1x AMARI Callbox (天线) 探测器: 1x AMARI Callbox (天线) 卫星定位器: 不需要

(2) 核心硬件使用方式

💻 笔记本电脑 (Controller):
- 作为攻击的大脑
- 通过 ADB (Android Debug Bridge) 工具向安卓手机（Probe）发送指令，令其执行 Ghost Call
- 通过 gr-iridium 或 LTESniffer 等软件控制 USRP，执行sniffer任务
- 在 Iridium 平台中，通过 AT 命令控制卫星电话（Locator）
📻 USRP (Sniffer):
- 作为软件定义无线电（SDR）设备
- 其核心功能是被动捕获和监听空中的无线信号（Iridium / TE 信号）
📱 手机 (Probe / Locator):
- LTE 安卓手机 (Probe): 作为主动探测器，用于拨打和取消呼叫，以迫使目标 UE 发出信号
- Iridium 卫星电话 (Locator): 作为卫星定位器，用于获取卫星的实时位置
📡 AMARI Callbox (Emulator):
- 在 NTN 仿真平台中，这是一台专业的商用 NTN 工具包
- 它被“一机多用”，通过不同天线同时模拟了攻击者的嗅探器（Sniffer）、探测器（Probe）以及受害者（Target UE）
🛰️ Starlink “星载基站”仿真 (重用 LTE 协议):
- 一台 USRP B210 充当星载基站 (eNodeB), 连接到一台 Dell Precision 7920 塔式工作站
- 工作站运行开源 srsRAN 来控制 USRP
- GNU Radio 接收StarryNet的信息, 在 srsRAN 和 USRP 之间构建虚拟用户-卫星链路, 用于调整传播延迟, 模拟卫星动态性

current design for Starlink D2C

一个让笔者大惑不解的地方是, 为什么没有CoreNet? (与srsRAN配套的, srsEPC)

(1) 核心: 模拟 UE 和星载基站 (RAN) 之间的无线信令交互

dataflow 主要发生在 UE 和运行 srsRAN 的工作站之间

(2) 硬件对应关系:

UE: Target UE (LTE Phone)
RAN (基站): Dell Precision 7920 Workstation + USRP B210
卫星链路 (时延): Dell Workstation 上的 GNU Radio + StarryNet
- GNU Radio 会人为地根据 StarryNet 计算出的TLE，给这个信号注入一个动态变化的传播时延

只要能成功模拟 UE 和 srsRAN 之间的 RRC（无线资源控制）信令交换，就可以让 Sniffer捕获到这些关键信息，从而完成攻击分析

因此不需要CoreNet的参与

Basic Design: E2E Starlink D2C Emulator

一言以蔽之:

展开细节 - Uplink:

(1) UE:

(2) RAN: (无线接入网 / 星载基站)

(3) CoreNet (核心网)

硬件: Dell Precision 7920 工作站
行为:
- [内部转发] srsRAN（RAN）将提取出的 IP 包, 通过GTP隧道, 发送给在同一台机器上运行的 srsEPC 软件（LTE核心网）
- [核心网处理] srsEPC 的 PGW（分组网关）组件对数据包进行处理
  - 解除GTP隧道封装、验证用户身份、分配IP地址 (NAT), 然后准备将其路由到外部互联网

(4) WAN (广域网)

很显然，这个workflow，依然存在两个很明显的问题