文章总结： 本文探讨了AI代理在车联网安全自动化测试中的应用新思路，提出将渗透测试拆分为LLM负责的决策编排与工具链负责的执行，通过分级审批机制确保安全控制，并封装标准化Skill提升测试可复现性。文章详细梳理了车内总线、无线接入、车钥匙等关键攻击面，强调AI代理在动态编排、取证追溯方面的优势，同时指出其在协议级判断上仍需工程师把关，旨在将工程师从重复操作中解放以专注核心决策。 综合评分： 88 文章分类： 车联网安全,解决方案,安全工具,AI安全,安全运营

当 AI Agent 学会了”黑车”：车联网安全自动化测试的新思路

原创

GuDAO GuDAO

网络安全知识

2026年5月19日 08:50 湖北

在小说阅读器读本章

去阅读

如果让大模型来做渗透测试，它需要什么能力、什么约束、什么工具？

#

01｜问题：测试做得完，但复现不了

一辆智能汽车有数十个 ECU、近十种无线接口、车云通道、OTA 更新链路。UN R155、GB 44495 都要求做安全测试。

问题不在”能不能测”，而在于：

测完之后呢？

手工渗透的经验停留在工程师脑子里。换一个人来做、换一批车型来做，从头开始。测试报告写了一页又一页，但下次回归测试还是要重复同样的操作。

我们想要的是：测试过程本身可复现、可追溯、可自动化回归。

02｜思路：把渗透测试拆成”决策”和”执行”

传统自动化脚本的问题是太刚性 —— 第 3 步发现了预期外的开放端口，脚本不会自己调整第 4 步的策略。真实的渗透测试是探索性的，需要根据中间结果随时决策。

这恰好是大模型擅长的事 —— 至少在编排和工具调度层面是擅长的。具体到协议级别的判断（比如某帧 UDS 响应是否真的代表绕过成功），仍然需要工程师把关。

所以我们的架构很简单：

• LLM 负责编排

  ：看到扫描结果 → 决定下一步测哪里 → 选择合适的工具 → 初步分析结果 → 起草结论

• 工具链负责执行

  ：CAN 帧收发、蓝牙扫描、GPS 信号生成、固件分析…… 每个动作封装成标准化工具

• 人负责授权和最终判断

  ：AI 想做什么都要先过人这一关；漏洞认定和报告定稿仍由工程师签字

这不是”AI 替代安全工程师”，是”AI 帮安全工程师省掉重复操作，让人专注在判断和决策上”。

03｜攻击面：一辆车到底要测什么

从攻击面的角度梳理，车联网安全测试可以分成几个大类：

车内总线 CAN 总线是汽车的”神经系统”。要测的核心问题：ECU 之间的消息能不能伪造？UDS（ISO 14229）诊断服务的 Security Access 机制是否形同虚设？种子-密钥算法的随机性够不够、能不能被回放？

无线接入面 车上的无线接口远不止两三种 —— 蜂窝（T-Box，4G/5G）、Wi-Fi、蓝牙经典 + BLE、UWB（新一代数字钥匙）、NFC、GNSS 接收、RKE/PKE 射频、TPMS（胎压监测，单向射频）、V2X（C-V2X 或 DSRC，在配备车型上）。每一种都有独立的攻击面。 蓝牙配对是不是用了 Just Works（无 MITM 保护）？Wi-Fi 的 PSK 强度和升级机制如何？BLE 数字钥匙防不防中继？

车钥匙 遥控钥匙（RKE）的射频信号能不能录制重放？是固定码还是滚动码？NFC 钥匙卡若使用 Mifare Classic / CRYPTO-1，其底层协议自 2008 年起已被学界公开证明可破解，2024 年又被披露存在硬件后门 —— 任何仍在用 Mifare Classic 做钥匙的方案都属于已知不安全。无钥匙进入（PKES）的中继攻击自 2011 年 ETH Zurich 公开论文以来一直有效，至今仍在被用于实际盗车。

定位欺骗 GPS/北斗等 GNSS 民用信号未加密，可用 HackRF + 开源工具（如 GPS-SDR-SIM）以低成本伪造，已有公开论文演示对车载导航的诱导。这在辅助驾驶/自动驾驶场景下风险更高。

车云通道 TSP 平台的 TLS 配置、MQTT 消息队列的认证、Web API 的注入漏洞 —— 云端是另一个完整的攻击面。

固件与应用 IVI 和 T-Box 的固件逆向、CVE 扫描、车机 App 的代码保护和权限审计。

USB / 物理接口 车载 USB 口接受不接受恶意设备？一个伪装成键盘的 U 盘能不能注入指令？OBD-II 诊断口、调试口的物理可达性也属于此类。

04｜关键设计：AI 干活，但不能没人管

让 AI 自己跑渗透测试最危险的不是”它测不准”，而是”它发了一帧不该发的 CAN 消息，把 ECU 搞坏了”—— 可能触发 DTC、bus-off，严重时需要离线刷写恢复。

所以安全控制是整个系统的核心。我们的原则：

AI 任何与被测设备主动交互的动作都必须授权；纯被动嗅探在测试授权范围内可放行。

注意：被动嗅探也不是完全无成本 —— 可能捕获车内乘员的私人设备信息；在部分司法辖区，未经授权接收某些频段也涉及无线电管理法规。所以”嗅探”放行的前提是整个测试本身已被书面授权。

两个维度分类工具

每个工具有两个独立的标签：

• 危险级别

  安全（直接跑）→ 需确认 → 危险（红色警告）

• 是否与设备交互

  被动嗅探（如 CAN 抓包）vs 主动操作（如 CAN 帧注入）

这两个维度是正交的。CAN 抓包是”安全 + 不交互”→ 直接执行。蓝牙扫描是”需确认 + 交互”→ 弹窗。CAN 洪泛是”危险 + 交互”→ 红色警告 + 二次确认。

审批在对话里完成

不需要跳到另一个界面。AI 想调工具时，聊天框里直接弹出一张卡片：工具名、参数、AI 的推理理由。管理员一键批准或拒绝。所有决策记入审计日志，采用 append-only 写入与哈希链保护，事后任何篡改都可被检测到。

Plan Mode

不确定 AI 会做什么？先进 Plan Mode —— AI 只能用”只读”工具（嗅探、静态分析），制定方案但不执行任何写操作。确认后再放开。

自由渗透模式

如果你完全信任 AI（比如在隔离的实验环境里），可以开启自动审批 —— 所有工具直接执行，不弹窗。适合回归测试和自动化流水线。

05｜Skills：让测试流程标准化

有了工具链和 AI 编排，下一步是标准化。

我们把常见测试场景封装成 Skill —— 一段预定义的指令模板，告诉 AI “做什么、用什么工具、按什么顺序”。

比如”完整安全审计”这个 Skill，AI 会自动按以下顺序推进：

启动全程取证录制
  → CAN/UDS 诊断安全
  → 蓝牙安全
  → WiFi 安全
  → 应用安全
  → 安全启动检查
  → 停止取证，生成综合报告

每完成一项更新进度，遇到需要授权的步骤暂停等待。管理员全程只需要在关键节点点”批准”。

这意味着：新人也能跑完一套完整的安全审计，只要他能判断审批请求是否合理。

06｜取证：不只是”测了”，还要”证明测了”

合规审计最怕的问题是：”你怎么证明这个测试在屏蔽环境里做的？”

所以每次测试自动启动三路取证：

• 屏幕录制

  车机屏幕操作全程记录

• 网络抓包

  流量全量捕获

• CAN 日志

  总线通信完整留存

所有证据带时间戳和 SHA256 哈希，打包后任何修改都可被验证发现。加上审批系统的 append-only 审计日志 —— 谁在什么时间授权了什么操作 —— 这就构成了完整可追溯的证据链。如果对接外部时间戳服务或硬件可信模块，证据效力可以进一步增强。

07｜与传统方案对比

| | 手工测试 | 脚本自动化 | AI Agent | | — | — | — | — | | 测试编排 | 人脑逐项 | 固定流程 | 动态调整 | | 异常处理 | 靠经验 | if-else | LLM 推理 | | 报告生成 | 手写 | 模板 | AI 结构化输出 | | 可追溯性 | 截图笔记 | 日志 | 完整证据链 | | 安全控制 | 全靠人 | 无 | 分级审批 | | 上手门槛 | 精通每个工具 | 能写脚本 | 描述目标即可 |

最核心的差异是动态编排。传统脚本第 2 步发现了意外，第 3 步不会自己变。AI Agent 天然具备这种根据中间结果调整策略的能力。

需要客观说明的是：AI Agent 不是银弹。LLM 在协议级判断上仍会出错、可能误报漏判，对未见过的私有协议尤其不可靠。它最有把握的部分是编排、调度、报告组织和已知模式的识别；真正的漏洞认定和风险评级，还是要工程师拍板。

08｜写在最后

车联网安全测试正在从”手工作坊”走向”工业化”。

AI Agent 不能替代工程师对漏洞的判断，不能替代对业务逻辑的理解。但它可以替代那些重复性的操作编排和工具调度，把工程师从”这个命令怎么敲”里解放出来，专注在”这个结果意味着什么”上。

这条路才刚开始走。架构和工具链已经跑通，真正的考验是大规模车型、长周期回归之后，能沉淀出多少可复用的 Skill、能挖出多少传统流程漏掉的问题。

欢迎同行交流。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：网络安全知识 GuDAO GuDAO《当 AI Agent 学会了”黑车”：车联网安全自动化测试的新思路》