MMS

一、异常会话与传输链

异常文件传输来自以下会话：

172.16.99.99:55555 → 10.1.1.50:102

其中，10.1.1.50 是题目中的继电器对应地址：其他会话也在访问该地址下的 REL521_SUBALPHA/MMXU1/... 电压、电流数据对象。异常会话则出现了文件名 REL521_FW_v2.1.bin.gz，随后持续发送文件数据块。packet_evidence.txt

按原始抓包中的报文编号，还原过程如下：

文件数据容器内，三个字段的结构为：

80 → 文件句柄
81 → 文件偏移
82 → 文件数据

据此按文件偏移重组，得到 44 块、共 11,048 字节，没有缺块或重叠。我还逐块核对了重组内容与原始抓包中的对应字节。chunks.json

本题不宜直接拼接整个 TCP 流。 一方面，每条消息都带有应用层封装；另一方面，样本中的 TCP 序号存在交错。因此应提取文件数据字段，再按应用层的文件偏移重组，而不是直接按 TCP 序号排序。

二、上传文件的真实内容

文件名虽然以 .gz 结尾，实际却不是 gzip。完整恢复路径为：

上传的文件数据：11,048 字节
        │
        ├─ 每字节 XOR 0x5A
        ▼
ZIP 压缩包
        │
        ├─ 提取成员 REL521_FW_v2.1.bin
        ▼
LZMA 压缩数据：10,909 字节
        │
        ├─ LZMA 解压
        ▼
Windows x86-64 PE32+ 程序：27,648 字节
        │
        ├─ 提取 ENCRYPTED_LICENSE= 后的密文
        └─ 每字节 XOR 0x3F
        ▼
真实 Flag

外层异或的识别依据很直接：上传数据开头是：

0A 11 59 5E

逐字节异或 0x5A 后得到：

50 4B 03 04

恢复后的 ZIP 可以正常解析，成员 CRC 校验通过。内部 REL521_FW_v2.1.bin 再经 LZMA 解压，得到以 MZ 开头、包含有效 PE 头的 Windows 程序。summary.json

因此，“固件升级包”是它的文件名伪装，不能仅凭名称将其认定为真实继电器可直接刷入的固件。

三、Flag 的定位与解密

在最终解压出的程序中，找到三处：

ENCRYPTED_LICENSE=

真实 Flag 对应第一处，位置如下：

密文为：

79 73 7E 78 44 72 52 4C 60 79 0E 4D 52 48
0B 4D 0C 60 7D 0B 5C 54 5B 0F 0F 4D 42

对每个字节异或 0x3F，即得到开头给出的 Flag。三个许可证区域的解码结果对比如下：summary.json

第一段还有程序引用作为佐证：指令 0x401E16 引用标记地址 0x406600，随后读取该许可证区域进行累加校验。这里的程序逻辑是密文校验；0x3F 则是通过离线测试单字节异或并验证解码结果确定的。disassembly.txt

对已恢复的最终文件，可用下面几行代码独立验证：

from pathlib import Path

data = Path("firmware_unpacked.bin").read_bytes()
ciphertext = data[0x4412:0x442D]

flag = bytes(value ^ 0x3F for value in ciphertext)
print(flag.decode("ascii"))

四、后门线索与证据边界

程序中存在以下静态线索：

这些内容支持将其视为后门线索，但不能据此断言反连已经成功。strings.txt

抓包中没有发往 10.99.88.77 的报文，也没有涉及端口 4444 的连接。另外，6–7 号包虽然出现了对 c2-server.evil.com 的 DNS 查询，但响应是 RCODE=3、没有回答记录，而且查询发生在文件上传之前。因此，不能将其描述成“上传后成功解析 C2 并回连”的已证实链路。packet_evidence.txt

本次能够确认的是：

异常来源通过 TCP/102 上的文件传输样式会话上传了可疑载荷；该载荷经 XOR、ZIP、LZMA 多层封装，内部程序包含反连线索和加密 Flag。抓包不足以证明刷写、执行或取得设备控制权。

还有两点需要注意：

时间存在题设差异。 抓包记录时间为 2026 年 8 月 5 日 05:47:15 UTC，换算为 UTC+8 是 13:47:15，不是凌晨。应以实际报文时间戳为准，而非套用题干描述。

协议是非标准的 MMS 风格构造。 样本文件操作使用 A3/A4/A7 标签，而标准 MMS 的 fileOpen/fileRead/fileClose 对应服务编号为 [72]/[73]/[74]。因此这里依据字段与文件恢复结果解释传输语义，不将这些报文直接归因到某个真实 REL-521 漏洞或 CVE。

可曾听闻一键日卫星Q1

已完成同步、解调和译码，恢复出的 Flag 为：

flag{sigint_viterbi_breakthrough}

结果已通过两项验证：帧内 CRC 校验一致；将恢复的帧重新编码、交织并进行主数据区极性变换后，与接收的 3500 个主数据比特完全一致，差异为 0。

1. 恢复出的遥测载荷

以下是完整的 214 字节正文，保留原始换行：

SCI_TELEMETRY V1
SAT: MISSION-07  EPOCH: 2026-08-25T00:00:00Z
MODE: DEEP_SURVEY  CHANNEL: X-BAND
GROUND_CONTACT: YAMCS-05
CryptoLib_update_v1.3.3_pending
ACK: all_nominal
FLAG=flag{sigint_viterbi_breakthrough}
END

正文已单独保存为 payload.txt。

2. 信号制式与链路参数

先从 IQ 样本识别采样表示、载波和符号周期，再解出信号中的自描述头，确认绝对采样率及编码参数。

卷积码输入的标称速率为 8,000 bit/s，但这不是扣除帧头、尾零和填充后的净载荷速率。另外，正文中的 X-BAND 只是载荷声明；这份无射频调谐元数据的基带文件不足以确定原始射频中心频率。

3. 同步与帧定位

载波同步、符号同步

将数据按复数 float32 读取：

iq = np.fromfile("AAAAAAAA.q1.iq", dtype="<c8")

对信号平方后，BPSK 符号的正负号被消除，载波项变成两倍频率。利用平方信号的频谱峰和分块相位拟合，可估计出约 +200 Hz 的原始频偏，再进行补偿：

校正后的跳变能量呈现 64 个采样点的周期。本录波恰好从符号边界开始，因此每 64 点求均值，取实部作为软判决：

symbols = corrected.reshape(-1, 64).mean(axis=1)
soft_bits = symbols.real

引导区采用正实部对应 0、负实部对应 1，按 MSB first 组装字节。

解出的自描述头

文件开头并不是全部经过信道编码的数据，而是三份重复的引导块。每份包含 32 字节 0x55 前导 + 254 字节自描述文字：

SPACECTF-Q1 SELF-DESCRIBING SIGNAL
FORMAT=CF32-IQ-INTERLEAVED;FS=1024000;SPS=64;MOD=BPSK;CFO=+200HZ
MAINPN=1ACFFC1D;FEC=CONV-R12-K7-G171-133-OCT;INTERLEAVER=5X5-ROW-WRITE-COL-READ
SCRAMBLER=X8+X7+X2+X+1;INIT=FF;FRAME=LEN1B+UTF8+CRC16-CCITT
BOOTSTRAP-END

三份引导块完全相同，合计：

因此整段解调比特流的结构为：

[三份引导块：6864 bit]
[同步字 1ACFFC1D：32 bit]
[编码主数据区：3500 bit]

具体偏移如下，均从 0 开始计数：

同步字精确匹配一次。全部长度也能闭合：

4. 主数据区极性、反交织与信道译码

本题需要特别注意：主数据区必须整体反相，不能直接沿用引导区的比特极性。

对主数据软判决乘以 -1，再按 5×5 块反交织：

deinterleaved = (
    (-main_soft)
    .reshape(-1, 5, 5)
    .transpose(0, 2, 1)
    .reshape(-1)
)

随后进行软判决 Viterbi 译码，采用 K=7、码率 1/2、八进制生成多项式 (171,133)。约束长度 7 对应 6 个记忆比特，因此使用 64 状态网格；这种生成多项式表示及软判决译码方式也可与官方通信工具文档对照。MathWorks^[1]

复现脚本采用左移寄存器、当前输入进入最低位，编码输出顺序先 171 后 133，初态和终态均为零。

关于头部的扰码声明

头部确实声明了：

SCRAMBLER=X8+X7+X2+X+1;INIT=FF

但本录波能够直接验证的净变换，是主数据区相对于重新编码、交织结果的逐位取反。仅凭这段声明，不能唯一确定发送端内部的 LFSR 位序、反馈实现或处理顺序。

因此，脚本没有未经验证地套用某个标准扰码器，而是检查两种主数据区极性，并用 CRC 和完整重新编码比对选择有效结果。这里验证的是该样本的实际传输关系，不是对某个标准 CCSDS 扰码实现的认定。

5. 长度字段与 CRC 验证

正确译码后，应用帧为：

D6 | 214 字节 UTF-8 正文 | 27 31

其中 0xD6 = 214，总帧长为：

编码长度也完整吻合：

217 字节应用帧             → 1736 bit
添加 6 个卷积编码尾零      → 1742 bit
执行 1/2 卷积编码          → 3484 bit
添加 16 个交织填充零       → 3500 bit
分成 5×5 交织块            → 140 块

CRC 经实际帧验证采用以下参数：

可以使用 Python 的 binascii.crc_hqx() 复核；该函数使用 CRC-CCITT 的 0x1021 多项式，并允许显式指定初值。Python documentation^[2]

import binascii
from pathlib import Path

frame = Path("frame.bin").read_bytes()

assert frame[0] == 214
assert len(frame) == 217
assert (
    binascii.crc_hqx(frame[:-2], 0xFFFF)
    == int.from_bytes(frame[-2:], "big")
    == 0x2731
)

注意，不能只对正文计算 CRC，长度字节也在校验范围内。

可曾听闻一键日卫星Q2

真正的攻击会话已经定位：10.77.10.31:40334 → 10.77.10.66:31337，目标为 YAMCS-05。

攻击链能够还原到 CryptoLib 突破 → 获取组件信息 → DS 路径越权 → to_lab 提权 → root 后读取认证配置。但目前有两个不能省略的问题：你提供的题面没有具体的 Flag 构造规则，PCAP 中也没有该规则；同时，突破阶段的 CryptoLib 回显不足以唯一确定一个 CVE。 因此，不能把猜测的拼接结果当成最终 Flag。

下面是从原始分组中恢复的证据。

一、真正攻击会话与干扰流量

附件共有 93 个分组。真正攻击连接占 43 个分组，客户端发送了 7 条命令。检查双向 TCP 序号后，主会话应用数据连续，没有发现缺口、重传或重叠。attack_session.txt

不能把下面几个连接混进攻击链：

这些连接的原始字段和载荷均保留在death_traffic_analysis.zip中。

二、攻击时间线

日期均为 2026 年 8 月 26 日，下表使用 UTC+8。 原始时间戳换算成 UTC 后，小时减 8。包号对应原始 PCAP，而不是重新筛选后的编号。attack_session.txt

1. 突破的直接证据

包 41：

tc 64030123ff

包 43：

RCE confirmed: cryptolib heap overflow; maintenance channel attached

这才是成功突破的会话，不能把干扰连接中的 packet accepted (no overflow) 算作成功。attack_session.txt

2. 信息获取与 DS 目标路径

satinfo 的回显给出了：

crypto: cryptolib 1.3.3
components: tc_worker (uid=1000), DS target-path service, to_lab_service (setuid root, telemetry forwarding)

随后发送的 DS 参数为：

2f6f70742f6366732f64732f6f7262697473746174652e636667

十六进制解码后是：

/opt/cfs/ds/orbitstate.cfg

包 78 明确报告：

DS_SetDestPathCmd accepted an out-of-policy target
  path traversal: target escaped /mission/data without an authorization check
  protected DS parameter namespace observed; recovery diagnostics unlocked

这里能证明路径越权和诊断解锁，但不能声称已经读取了 orbitstate.cfg 的内容——回显没有给出该文件内容。attack_session.txt

3. 提权与 root 后行为

包 83：

PRIVILEGE ESCALATION OK: to_lab (setuid root) CFE_MSG_GetSize bounds fault; shell elevated to root

包 85：

root recovery console @ YAMCS-05 (uid=0 root)

取得 root 后，攻击者执行：

cat /etc/yamcs/security.yaml

返回内容包含：

users:
  admin:   {hash: $2a$12$s8lLQ/2026.q3.satellite.admin, roles: [admin]}
  mission: {hash: $2a$12$mission.ops.2026.q3,        roles: [operator]}
  guest:   {hash: $2a$12$guest.temp.access,          roles: [readonly]}
auth:
  token_ttl: 3600s
  rate_limit: 100/min

这是取得 root 后读取认证配置，不是成功读取 /flag；其中的 hash 字段也不能当成已经恢复的明文密码。抓包到这次配置读取及后续提示符、ACK 为止，没有更晚的后渗透行为。security.yaml.txt

三、公开漏洞编号核对

DS 路径越权：CVE-2026-67970

这个编号可以高置信度对应。

CVE 原始记录明确描述：NASA cFS 的 DS_SetDestPathCmd() 访问控制不当，允许通过路径遍历访问敏感组件。函数名和行为都与包 78 一致。GitHub^[3]

to_lab 长度边界问题：CVE-2026-5474

这个编号也可以高置信度对应。

公开记录涉及 apps/to_lab/fsw/src/to_lab_passthru_encode.c、CFE_MSG_GetSize 和 CCSDS 报文长度处理，与包 83 的组件及函数名吻合。GitHub^[4]

需要区分的是：原始漏洞报告描述了信任报文头声明长度，导致发送时越界读取堆内存。本题的“提权至 root”由其 setuid 服务设置及控制台回显证明，不能推广成这个公开 CVE 在所有真实部署中都必然能取得 root。github.com^[5]

CryptoLib 突破：CVE-2025-29909 是候选，但尚不能唯一锁定

CVE-2025-29909 的官方公告描述了 CryptoLib ≤ 1.3.3 的 Crypto_TC_ApplySecurity() TC 帧长度处理缺陷和堆溢出，与题目描述接近，其公开示例为 6403000000。GitHub^[6]

但同一组件还有 CVE-2025-30356，涉及该处理路径中长度检查修复不完整造成的堆溢出。GitHub^[7]

此外，Crypto_TC_ProcessSecurity 和 Crypto_TC_Prep_AAD 中也分别有 CVE-2025-29912、CVE-2025-29913，同样涉及 TC 处理、长度下溢或堆越界。GitHub^[8]

本 PCAP 只给了 cryptolib 1.3.3、heap overflow 和 tc 64030123ff，没有具体 CryptoLib 函数名、调用栈或修补状态。 因而，仅凭这些回显把第一项直接定成某个 CVE，会超过现有证据能支持的范围。

四、目前可以确定的构造素材

攻击者IP：10.77.10.31
攻击者端口：40334
目标IP：10.77.10.66
目标端口：31337
目标名称：YAMCS-05
突破命令：tc 64030123ff
CryptoLib版本：1.3.3
DS目标路径：/opt/cfs/ds/orbitstate.cfg
DS漏洞编号：CVE-2026-67970
提权命令：tolab 0800c000d00d
提权漏洞编号：CVE-2026-5474
提权后UID：0
root后读取路径：/etc/yamcs/security.yaml

第二轮分析：进一步缩小 CryptoLib 漏洞范围

重新检查 PCAP 后，确认攻击链中的三个关键漏洞位置：

CryptoLib 的两个候选漏洞均涉及 Crypto_TC_ApplySecurity() 函数中的 TC 帧长度处理以及堆越界。NASA 公开安全公告确认了相应漏洞及受影响版本。

值得注意的是，攻击载荷实际为：

64030123ff

而 CVE-2025-29909 公告的最小触发示例是：

6403000000

两者并不完全相同，因此不能直接用公告中的 PoC 证明它们属于同一漏洞。我继续按帧结构和漏洞条件进行核对。

新发现：攻击 TC 帧的长度字段明显异常

根据 CCSDS TC 帧头格式，64030123ff 可以拆解为：

TC 帧的长度字段为 10 位，记录的是总帧长度减一。

这进一步证明攻击者提交了长度声明与实际数据不一致的异常 TC 帧，与 CryptoLib 的长度校验问题有关。

不过，它并不直接符合 CVE-2025-29909 的零长度 PoC，也不符合 CVE-2025-30356 公告中 fl=6 的下溢示例。因此，虽然这两个编号仍值得优先考虑，但现有数据无法唯一锁定突破阶段 CVE。

CVE-2025-29909|CVE-2026-67970|CVE-2026-5474

换顺序即可获得flag

可曾听闻一键日卫星Q3

目标是 cFS 风格的仿真星务控制台（YAMCS-05），cat /flag 之类常规读文件路径全是死的，必须按状态机把控制链路一级级提上去。整条链是四段式，每段都卡在前一段的状态位上：

① tc <hex> — 概率性堆溢出，打通维护通道 tc 00 是掷骰子：命中返回 RCE confirmed: cryptolib heap overflow; maintenance channel attached，未命中返回 packet accepted (no overflow)。关键点是每个会话只判定一次——同一连接里第二次 tc 必定返回 no overflow。所以脚本要反复新建连接重试，实测 1～7 次内必中。

② ds <hex-ascii-path> — 路径穿越解锁诊断 未打通时返回 ACCESS DENIED: not compromised, run 'tc <hex>' first；打通后任意路径（/、/mission/data、/opt/cfs/ds 都行）都返回 DS_SetDestPathCmd accepted an out-of-policy target ... recovery diagnostics unlocked。这一步是给第三步开权限门的。

③ tolab <hex> — setuid 提权到 root 这是最容易走偏的一步：绝大多数载荷（00、41、flag、help…）都只回 telemetry processed normally (no crash)，是障眼法。真正触发的是带前导斜杠的 /flag，即 hex 2f666c6167 → PRIVILEGE ESCALATION OK: to_lab (setuid root) CFE_MSG_GetSize bounds fault; shell elevated to root，提示符从 > 变 #。

④ sep <hex> — 按飞行配置构造指令，触发终端失效 root 下 cat /opt/cfs/ds/propulsion.cfg 给出全部构造参数：

按此拼出 sep 0800c000ffff（前缀 + 长度字段全 1）→ 持续点火绕过定时器守卫 → 推进异常 → 结构失效 → *** SATELLITE LOSS OF SIGNAL ***，最终遥测回显 flag。

cat /flag 在 root 下也不是直接给 flag 的，它回的是 FLAG_NOT_ON_BOARD: final telemetry is generated only during terminal mission failure，外加一句提示 inspect protected flight configuration before authorizing a SEP operation——这是官方的路径指引，说明 flag 是运行期动态生成的，只有把卫星"玩炸"才会出现。

另外 sep 0800c0000000（长度字段填 0）会被挡在 propulsion check failed (no anomaly)，sep 0800c000（不足 6 字节）报 malformed command (need >=6 bytes)——这两条正好反向确认了长度字段的位置语义，是构造 payload 时的校准点。

复现脚本在 /tmp/chain.py（含自动重试的 compromize()）和 /tmp/root5.py（完整四段链）。注意最后一步是不可逆的一次性动作，连接会在 flag 输出后立即断开。

量子安全

量子门的多维身份

解码依据

排除 ID、SX 噪声门后，共有 144 个旋转门。将角度量化为：

从门序列反推出的解码公式为：

其中，(q) 是作用量子比特编号，门偏移量为：

RX → 0
RY → 1
RZ → 4

计算结果每四个构成一组，所有 36 组均满足：

[c, 256-c, c, 256-c]

取每组的 c 并转换为字符即可。例如，附件开头四个有效旋转门解码为 [70, 186, 70, 186]，对应首字符 F。quantum_gate_identity

可复现脚本

import math
import re
from pathlib import Path

text = Path("quantum_gate_identity.qasm").read_text(encoding="utf-8")
offset = {"RX": 0, "RY": 1, "RZ": 4}

# 只提取旋转门，自动排除 ID、SX 和其他语句。
gates = re.findall(
    r"\b(RX|RY|RZ)\(([\d.]+)\)\s+q\[(\d+)\]\s*;",
    text,
)

values = []
for gate, angle, qubit in gates:
    n = round(float(angle) * 16 / math.pi)
    values.append(32 * int(qubit) + n + offset[gate] + 16)

assert len(values) == 144

result = []
for i in range(0, len(values), 4):
    a, b, c, d = values[i:i + 4]

    # 检查重复编码与互补编码，而非仅凭可读性猜测。
    assert a == c and b == d and a + b == 256, (
        f"第 {i // 4} 组校验失败"
    )
    result.append(chr(a))

print("".join(result))

输出：

FLAG{4d_quantum_identity_is_complex}

量子幽灵的复数密码

恢复出的 Flag 是：

FLAG{complex_quantum_stealth_is_the_ultimate}

解码与校验

每个量子态编码 1 个比特，四个维度是对同一比特的冗余表示，而不是分别编码 4 个比特。

解析每行的复振幅 (\alpha,\beta)，令相对相位

采用以下判定规则：

例如，附件第 1 行判为 0，第 2 行判为 1；前 8 行依次得到 01000110，对应 ASCII 字符 F。 quantum_ghost_complex_states

保持原始行序，每 8 位一组、高位在前转换为字符。前 40 行得到以下前缀： quantum_ghost_complex_states

01000110 01001100 01000001 01000111 01111011
    F        L        A        G        {

实际计算结果：360 条记录还原为 360 比特，即 45 字节；四路独立解码得到完全相同的完整 Flag，所有行的四路判定均一致。

应急响应

引用链接