把SOME落到关键对象的触发条件、可观察状态和复查材料上，先判断问题从哪里收窄。
SOME涉及源码、函数、脚本或 API 时，应先确认代码对象、调用条件和结果信号是否对应。
本节用IP安全通信的真实调用点说明代码变化会影响哪一个操作结果。
在车载以太网通信中，SOME/IP（Scalable service-Oriented MiddlewarE over IP） 协议是实现服务导向架构（SOA）的核心。而 SOME/IP-SD（Service Discovery） 作为其服务发现组件，负责服务的动态注册、查找和订阅。然而，SOME/IP-SD 协议在设计初期并未强制引入会话安全机制，其报文结构中的关键字段——如 Session ID、Message ID 和 Client ID——在缺乏加密和完整性校验的情况下，极易被攻击者伪造或重放，从而引发会话劫持攻击
理解攻击的前提是拆解报文。一个标准的 SOME/IP-SD 报文由头部（Header）和载荷（Payload）组成。头部中的 Session ID 本应标识一次服务发现会话的连续性，但在实际实现中，许多系统仅将其作为递增计数器，并未与通信双方的身份或密钥绑定。攻击者只需在网络上嗅探到一个合法的 Session ID，即可构造一个包含相同 ID 的恶意 Offer 或 Subscribe 报文，冒充合法服务端或客户端，接管通信链路。这种无状态漏洞正是 安全通信 需求产生的直接驱动力
SOME/IP-SD 的会话劫持本质上是“信任继承”漏洞：报文头部的 Session ID 被当作身份凭证，但协议本身未验证该凭证的合法性。任何未加密的 SD 报文都可能成为攻击者的“入场券”
为了后续复现攻击，我们需要明确 module_boundary（模块边界）的概念。在车载网络中，一个功能模块（如 ADAS 模块）通过 SOME/IP-SD 发布其服务。攻击者的目标就是跨越这个模块边界，向其他模块（如网关）发送伪造的 SD 报文，使其认为攻击者是合法的 ADAS 服务提供者。这个边界就是我们需要重点防护的“攻击面”
本节实验的目标是在一个可控的虚拟网络环境中，复现针对 SOME/IP-SD 的会话劫持攻击。我们采用 数据加密项 尚未部署前的“裸协议”状态作为实验基线，以此直观展示安全需求的紧迫性。实验环境基于 Ubuntu 22.04，使用 vsomeip 开源协议栈和 Wireshark 进行报文捕获与分析
首先，启动一个标准的 SOME/IP-SD 服务端（Service）和客户端（Client）。服务端在启动后会周期性发送 Offer Service 报文。使用 Wireshark 捕获网络接口，设置过滤条件为 someip，即可看到这些报文。关键观察点在于报文头部的 Session ID 字段，它通常从 0x0001 开始递增
攻击者（Attacker）节点同样接入该网络。通过 Wireshark，攻击者可以轻松获取到服务端发送的 Offer 报文，并记录下其中的 Session ID、Service ID 和 Instance ID
在某智能座舱项目中，测试团队发现，当攻击者接入车载以太网并发送一个伪造的 Offer Service 报文（仅复制了合法报文的 Session ID），部分域控制器会立即断开与原始服务的连接，转而向攻击者发送 Subscribe 请求。这导致座舱娱乐系统短暂失联，导航和语音功能中断
攻击复现的核心工具是 scapy（Python 库）或 netcat 配合原始套接字。以下是一个使用 Python 和原始套接字构造伪造 SOME/IP-SD Offer 报文的简化示例。该报文的关键在于将 Session ID 设置为嗅探到的值（例如 0x0003），并将源 IP 地址伪装成合法服务端的 IP
import socket
import struct
# 构造 SOME/IP-SD 头部 (简化)
# Message ID: 0xFFFF8100 (Offer Service)
# Length: 0x0008
# Request ID: Client ID 0x0000, Session ID 0x0003 (从嗅探报文获得)
# Protocol Version: 0x01, Interface Version: 0x01, Message Type: 0x02 (Notification)
sd_header = struct.pack('!I I I B B B B',
0xFFFF8100, # Message ID
0x00000008, # Length
0x00000003, # Request ID (Session ID = 0x0003)
0x01, # Protocol Version
0x01, # Interface Version
0x02, # Message Type (Notification)
0x00) # Return Code
# 创建原始套接字并发送
sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_UDP)
# 注意：此处需构造完整的 UDP 和 IP 头部，或使用 scapy 简化
# 实际攻击中，需将源 IP 设为服务端 IP，目标 IP 设为广播地址或客户端 IP
print("伪造的 Offer Service 报文已发送，Session ID 劫持攻击进行中...")
sock.close()这段配置属于“问题代码/原始配置”，核对键名、默认值、取值范围和修改后影响的行为。
执行上述脚本后，观察客户端日志。如果客户端接受了这个伪造的 Offer，并开始向攻击者发送 Subscribe 报文，则说明会话劫持攻击复现成功。这个实验清晰地展示了：在没有 数据加密项（如 TLS/DTLS）或消息认证码（MAC）保护时，SOME/IP-SD 会话的脆弱性
完成攻击复现后，立即在服务端和客户端之间启用 DTLS 加密。重新执行攻击脚本，观察客户端是否仍会响应伪造报文。这是验证 安全通信 措施有效性的最直接方法
通过上述实验，我们获得了两个关键的技术资产：一是攻击复现的脚本和抓包文件（PCAP），二是对风险边界的量化认识。这些资产是后续设计 安全通信 方案的基础
为了将攻击检测标准化，我们设计了一张 判断标准表，用于评估一个 SOME/IP-SD 实现是否容易遭受会话劫持
| 变量 | 对照组 | 观察结果 | 结论 |
|---|---|---|---|
| Session ID 管理 | Session ID 与通信双方的身份密钥绑定，或使用… | Session ID 仅为单调递增计数器，可被预测或重放 | 例：使用 HMAC 对 Session ID 签名。评… |
| 报文完整性校验 | 所有 SD 报文携带基于共享密钥的消息认证码（MAC） | 报文无任何完整性校验字段 | 例：使用 AES-CMAC 作为 MAC。评价：差的实… |
| 模块边界隔离 | 跨 module_boundary 的 SD 通信必须… | 任何网络节点均可直接发送 SD 报文，无访问控制 | 例：网关仅转发来自白名单 MAC 地址的 SD 报文。… |
这张表格直接对应了 异常信号与处理边界 的角色。在实际项目中，开发团队可以对照此表对现有 SOME/IP 协议栈进行安全审计。例如，如果发现 Session ID 仅由计数器生成，且报文无 MAC，那么该模块的风险等级应被判定为“高”，必须优先引入 数据加密项 进行加固
许多开发者认为“只要网络是隔离的，SOME/IP-SD 就是安全的”。然而，车载网络中的网关或 T-Box 一旦被攻破，内部网络将完全暴露。会话劫持攻击的复现实验证明，协议本身的安全缺陷才是根本问题，网络隔离只是辅助手段
最后，项目解析 的视角要求我们不仅看到攻击本身，更要看到解决方案的演进。本节复现的劫持攻击，直接引出了后续课程中将要深入讲解的 安全通信 机制，如基于 TLS/DTLS 的隧道加密和基于 SOME/IP-Sec 的报文签名。这些机制正是为了在 module_boundary 上建立可信的通信管道，从根本上杜绝会话劫持的可能性
项目收束要把解析落到下一步可执行材料上：入口在哪里、输出是什么、可观察信号能否证明当前实现已经达到目标。如果继续扩展，应先判断代码阅读线索和涉及源码哪一个会影响结果，再决定是补配置、补测试，还是补一份更清晰的结果材料。这样的尾部不重复资产清单，而是让后续协作能从具体材料判断项目能否继续推进。本节留下的复查锚点是源码结构：代码阅读线索是否还能解释项目成果，再用涉及源码核对可运行材料到案例复用的变化。第02节的交接重点是可运行材料，它决定代码阅读线索是短暂波动还是可复现证据。