远程攻陷日产 Leaf：从互联网控制车身关键部件

本文根据 PCAutomotive 研究团队（Radu Motspan、Mikhail Evdokimov、Polina Smirnova）在 Black Hat Asia 2025 上的演讲《Remote Exploitation of Nissan Leaf: Controlling Critical Body Elements from the Internet》整理而成，并结合公开 CVE 与安全媒体资料进行补充。

2020 年款的第二代日产 Leaf（ZE1）——这台全球销量最高的纯电动车之一，被证明可以从”几米之外的蓝牙”，一路打通到互联网，远程控制门锁、后视镜、喇叭、车灯、雨刮器乃至方向盘调节。这不是科幻，而是一条完整的、被公开演示过的攻击链。

在本次研究中，PCAutomotive 的团队共报告了 9 个漏洞、2 个安全缺陷，涉及汽车供应商生态中的多个角色：车机（Infotainment，Bosch 制造）、蓝牙/Wi-Fi 芯片（Alps Alpine）、网关（Nissan）、远程信息处理模块 TCU（Nissan）与车身控制模块 BCM（Nissan）。离谱的是，这项研究最早在 2023 年 8 月 就已递交给日产网络安全团队，却因流程问题直到 2025 年 3 月 才完成 CVE 登记，整整跨越了一年半。

目录

1. 研究目标与实验台搭建
2. 防盗（Anti-Theft）机制逆向与绕过
3. 蓝牙 RCE：HFP 栈溢出到 root
4. 系统纵深：内核镜像、调试与 LKM
5. 持久化与数据外带（DNS 隧道）
6. CAN 通信：INC 协议、RH850 提权与任意 CAN
7. 网关过滤与日产私有 UDS 命令
8. 攻击链全景与漏洞清单
9. 披露时间线与防护建议

1. 研究目标与实验台搭建

目标：Nissan Leaf ZE1（第二代）

研究目标是 2020 年生产的第二代 Nissan Leaf，其中三个核心 ECU 构成攻击面：

实验台：闲鱼（eBay）+ 布达佩斯报废厂

由于零部件的组件间互认（mutual-authentication）机制被启用，团队无法直接从 eBay 买的散件拼出一台能用的车机。于是他们跑到布达佩斯最近的汽车报废厂，买齐了 IVI、网关、BCM、仪表（IC）和全套线束，搭出一台能通电工作的测试台。

这一步非常关键：互认机制的启用，意味着后续”换机”必须解决防盗认证问题，这直接把我们引向了第一项漏洞——运行在 CAN 总线上的防盗挑战-应答协议。

2. 防盗（Anti-Theft）机制逆向与绕过

防盗逻辑概述

为了阻止车机被盗或非法接入车辆系统，日产车机内置了三层防盗手段：

• 锁定机制：固件认证；
• VIN 编码：VIN 不匹配即禁用；
• 功能削减：使用过程中不断”捣乱”。

具体流程是：IVI 每次上电，都必须通过 CAN 总线与特定 ECU 完成一次挑战-应答（challenge-response）握手。应答错了，就触发红色错误；没有响应，则触发绿色错误——总之都不能正常工作。

从抓到的 CAN 流量可以还原出握手过程：

消息结构：脆弱的校验和

进一步分析 CAN 消息结构，发现这个”防盗”协议简单得吓人——应答由固定的算法生成，且校验和仅是字节求和后取 8 位：

Checksum calc: (0x14 + 0x01 + 0xf0 + 0x5b + 0xb5) && 0x0ff = 0x15

也就是说：种子（seed）是有限的、可枚举的，而对应的应答可以由捕捉到的样本预计算出来。团队没有逆向 IVI 固件（”we respect our time”），只分析运行时的 CAN 通信，用 Python 脚本为每一个 seed 建了一张解算表，彻底绕过防盗机制。

• 相关漏洞：CVE-2025-32056（Anti-Theft bypass）
• MITRE 描述原文：”攻击者可嗅探 CAN 流量或预先计算数值，揭示全部 32 种对应的 seed 应答，从而绕过保护。”

3. 蓝牙 RCE：HFP 栈溢出到 root

硬件与软件栈

车机底层是 i.MX6（NXP）处理器 + RH850/D1L（瑞萨）MCU，Wi-Fi/蓝牙则由 Alps Alpine 的 SoC 承载：

蓝牙协议栈名为 Bluedragon Evo（Bosch 专有实现），是一个以 root 权限运行的 ARM 32 位 ELF 可执行文件，且蓝牙逻辑被拆成多个动态库——这意味着其他使用同类协议的设备同样可能受影响。

其防护措施评估如下：

配对：只需要”0.5 次点击”

配对机制上，日产的实现存在一个致命的时间窗：

• IVI 只在”添加新设备（Add New）”子菜单里接受配对请求；
• 配对的完成不依赖用户交互；
• 因此攻击链是”0.5 次点击”——如果目标车主恰好停在那个菜单，就是”0 次点击”；
• 那么如何强制车主打开设置菜单？用 2.4GHz 频段干扰（Wi-Fi/蓝牙都挤在 2.4GHz，干扰会让车机诱导用户去关掉蓝牙/Wi-Fi，从而进入设置页）；
• 而连接的建立，可以在任意菜单下完成。

HFP：攻击入口

连接建立之后，攻击面就是协议栈上层基于 RFCOMM 的 HFP（Hands-Free Profile）——手机免提协议。它承载语音（走 SCO 通道）与控制信号（AT 命令），管理通话流程。其中最具价值的是厂商私有 AT 命令扩展，例如：

根因：多次栈溢出

在逆向 HF_ParseRsp() 时，团队发现了多个基于栈的缓冲区溢出。关键代码如下（params[10] 是长度仅 80 字节的栈数组）：

size_t __fastcall HF_ParseRsp(RfDlc *dlc, uint8_t *rxbf, size_t rxlen)
{
    size_t params[10];            // [sp+8Ch] [bp-94h]
    if ( j_CmpBuffer(rxbf, "+ANDROID:") )
    {
        if ( j_CmpBuffer(&rxbf[space_len + 11], "probe") )
        {
            param_cnt = j_GetParameters(probe_bf,
                        (unsigned __int16)(probe_len - 2),
                        &probe_params, probe_lens, 2u);
            switch ( param_cnt )
            {
            case 2:
                if ( (unsigned int)probe_lens[1] - 2 <= 0xC )
                {
                    v40 = probe_lens[0];
                    memcpy(params, probe_params, probe_lens[0]);   // <-- 越界写
                }
            }
        }
    }
    ...
}

缺陷本质：长度校验检查的是 probe_lens[1]，而 memcpy 拷贝的长度却是 probe_lens[0]——校验与使用不一致，导致栈缓冲区 params 被越界覆盖。相似的漏洞还存在于 "+ANDROID:audiosource" 与 "+ANDROID:vds" 两个分支中。

if ( j_CmpBuffer(rxbf, "+ANDROID:") )
{
    if ( j_CmpBuffer(&rxbf[space_len + 11], "audiosource") )
    {
        j_GetParameters(v48, (unsigned __int16)(v49 - 2),
                        tmp_params, &tmp_lens, 1u);
        memcpy(params, tmp_params[0], tmp_lens);      // <-- 越界写
    }
}
if ( j_CmpBuffer(rxbf, "+ANDROID:") )
{
    if ( j_CmpBuffer(&rxbf[space_len + 11], "vds") )
    {
        j_GetParameters(v52, (unsigned __int16)(v43 - 2),
                        tmp_params, &tmp_lens, 1u);
        memcpy(probe_lens, tmp_params[0], tmp_lens);  // <-- 越界写
    }
}

Multiple Stack-based Buffer Overflows —— 这正是 CVE-2025-32059 / 32061 / 32062 的来源。

利用：ROP + AVCTP 载荷投递

由于栈上无金丝雀，利用变得”简单直接”：

• ROP 链：调用 system() 并优雅地恢复蓝牙栈执行；
• 限制：载荷中 0x2c（,）与 0x22（"）两个字节被禁用，需要编码规避；
• 载荷存放：利用 AVCTP 蓝牙 Profile 的分片消息缓冲区（fragmentation message buffer）作为第二阶段的系统命令存储区；
• 反弹 shell：车机出站连接默认被 iptables 的 DROP 规则限制，先清掉 DROP 规则再建立反向 Shell。

这一阶段收获的能力：

4. 系统纵深：内核镜像、调试与 LKM

拿到 shell 之后，接下来是摸清系统。车机软硬件信息如下：

调试之殇：exchnd 异常处理驱动

研究需要 gdb，但一 attach 进程车机就重启。排查之后发现并非进程自身的信号处理，而是内核拦截了进程的特定信号（SIGTRAP）——罪魁祸首是板载的 exchnd（Exception Handler Driver）内核模块：它通过在内核特定函数上注册 kprobes/jprobes 来捕获进程异常，一旦发生 SIGTRAP 就触发”重启 IVI”。

解法：利用”无内核模块签名校验”这个能力（CVE-2025-32060），上传自定义 LKM，把 exchnd 注册的 kprobes/jprobes 全部卸载。

此后团队可以正常调试任意进程。

内核镜像：神秘的 ih_comp = 0x4d 与 LZ77

从固件中能直接找到内核镜像，但它显然是压缩的（uImage）。用标准的 xz/lzma/gunzip 都解不开，binwalk 也毫无线索。回头分析 U-boot 引导器的 bootm_load_os() 反汇编：

int __fastcall bootm_load_os(...)
{
    if ( comp == 1 ) {
        // GUNZIP: uncompress
    }
    else if ( comp ) {
        if ( comp != 0x4d ) {
            printf("Unimplemented compression type %d\n", comp);
            return -3;
        }
        v16 = lz77_decompress(load_buf, lzma_len, image_buf, image_len);
    }
}

原来它的压缩类型是 ih_comp = 0x4d，对应自定义的 LZ77 实现。公共的 LZ77 开源实现无法解出该镜像，于是团队直接用 Qiling 框架仿真运行 lz77_decompress()，成功还原出未压缩的内核。

至此，整个系统对攻击者全面敞开：内核级代码执行 + 卸载异常处理驱动 + 任意进程调试。

5. 持久化与数据外带（DNS 隧道）

找可写分区

持久化的第一步是找可写的存储位置：

SSH 服务与防火墙开关

系统里有一个 ALD（Authorization Level Daemon） 守护进程，负责在系统安全等级之间自动切换，典型的受控服务包括 sshd、firewall。SSH 服务可以开在 Wi-Fi 或 USB2Ethernet 接口上，只要修改下述标记文件：

rm /var/opt/bosch/dynamic/ald/SSHdisabled
rm /var/opt/bosch/dynamic/ald/rootLogindisabled
touch /var/opt/bosch/dynamic/ald/SSHenabled
touch /var/opt/bosch/dynamic/ald/rootLogindenabled
rm /var/opt/bosch/dynamic/ald/FWdisabled

但系统还有一道校验服务 tty-ssh-checker：只要 ALD 安全等级低于 30，就会把 SSHenabled 标记撤掉、恢复 SSHdisabled。团队随后以该服务为依赖项做了补丁绕过，最终稳定开启 SSH。

攻坚安全启动：HAB 上的 N-day

要让持久化扛过重启，光开 SSH 还不够，因为根文件系统还有 dm-verity 完整性保护。突破口是 i.MX6 的 HAB（High Assurance Boot）：

• HAB 代码位于 Boot ROM，加载在地址 0，系统启动后这段内存仍在；
• 可用 /dev/mem 把物理地址 0x0 - 0x12000 的 HAB 代码 dump 出来；
• 而 HAB 的解析逻辑里藏着一个 Quarkslab 早已发布的 CVE-2017-7932（CSF 证书处理的栈溢出）。

利用该漏洞可以禁用对 DTB（设备树）的签名校验，并给 dm-verity 追加 ignore_corruption 参数——完美绕过根文件系统完整性。最后改写每次上电都会执行的启动脚本 /opt/bosch/base/bin/app_fcswupdate_wrapper.sh，实现持久化。

数据外带：域名即信道

车机本身通过 TCU 走蜂窝网络访问互联网，而且——DNS 请求不过滤。于是数据外带与远程控制的信道定为 DNS：

• 使用 dnscat2 把 DNS 查询当作信道，建立到车机的 TCP 隧道；
• 信标域名形如 *.attacker-srv.com，既是编码通道又能天然穿透绝大多数边界防火墙。

6. CAN 通信：INC 协议、RH850 提权与任意 CAN

三条路线

在 CAN 总线取得任意访问权限，有几种思路：

• 利用合法接口与 API（最快、最稳）；
• 篡改 RH850 固件；
• 攻击通信协议本身的漏洞。

信息收集：找到 INC 网络服务

车机是 OPKG 包管理器，直接 grep 包描述里的 “CAN” 字样，发现服务都依赖一个 inc-scc 网络服务，且这个接口上的流量”非典型”。好在 Bosch 在官网发布了 OSS SDK 源码，其中 /opt/bosch/base/bin/inc_send_out.out 可以直接作为 CAN 通信的测试样例。

INC 是 Bosch 自研的车机与 MCU（如 RH850）之间的网络协议。其端口定义在 include/linux/inc_ports.h：

• 基础端口号：0xc700；
• 例如 DOWNLOAD 端口 = 0xc700 | 11。

合法路径：csm_proc_out

/opt/bosch/base/bin/csm_proc_out.out 提供两种发送 CAN 消息的能力：

• Signals（信号）：一次性 CAN 消息，用于通知 ECU 客户端或接收它们的通知；
• Requests（请求）：带连接阶段的多条 CAN 消息，使用 NET_BROADCAST 与 NET_TP<0..8> 端口。

结论很重要：payload 可以完全控制，但只能使用白名单内的 CAN ID。

RH850 固件更新机制

要突破白名单，就得看能否篡改 RH850 固件：

• 固件位于 /ivi/firmware/v850/firmware/v850/aivi_s1_a；
• 调用 swu_common_v850_app_out.out 安装更新；
• 固件以 DNL 二进制格式交付：

更新走 INC 接口的 DOWNLOAD 端口，基于 UDS 协议：

1. 切换到 loader：10-60
2. 发起下载：34-00-44-<address>-<size>
3. 传输固件：36-00-...
4. 发送签名：2e-25-fd-...
5. 结束传输：37
6. 校验 CRC：22-...

签名会在”结束传输”以及“启动过程”中两次校验。也就是说，想直接改固件，必须绕过 RSA 签名校验。于是，团队转向第三条路线——审计 RH850 上处理 INC 请求的固件。

RH850 栈溢出：NET_BROADCAST 上的 0x50 请求

RH850 固件有大量 INC 端口、大量 handler，攻击面巨大；而 IVI 在 i.MX6 与 RH850 两侧都提供了丰富的跟踪（tracing）功能，对研究极其友好。最终在 NET_BROADCAST 端口（0xc700 | 15）的请求处理里挖到了栈溢出：

1. prepareNetBroadcastRequestBuffer   // 检查入站大小 <= 0x65
2. fillNetBroadcastRequestBuffer      // 把输入数据放入全局内存
3. processNetBroadcastRequestBuffer   // 处理全局内存，接收 i_pPacket / i_dPacketSize

触发路径如下（伪汇编）：

if (*i_pPacket == 0x50) {
    _local_30 = 0; uStack_2c = 0; uStack_28 = 0; uStack_24 = 0;
    pCurLocalStackBuffer = &sLocalStackBuffer;
    dID = *(uint32_t *)(i_pPacket + 8);
    sLocalStackBuffer = 0; local_34 = 0;
    dPayloadSize = (i_dPacketSize - 0xdU);
    uVar5 = 0;
    if (dPayloadSize != 0) {
        pPayload = i_pPacket + dPayloadSize + 0xc;
        do {
            bValue = *pPayload;
            pPayload = pPayload - 1;
            uVar5++;
            *pCurLocalStackBuffer++ = bValue;   // <-- 逐字节向栈上拷贝，无边界
        } while (uVar5 < dPayloadSize);
    }
}

dPayloadSize 来自 i_dPacketSize - 0xd，而 i_dPacketSize 由攻击者可控的请求长度决定，prepareNetBroadcastRequestBuffer 只把大小限制在 0x65，远超局部栈缓冲区的容量——直接打穿栈。

利用与工程问题

利用条件非常理想：

• payload 完全可控；
• 无栈金丝雀；
• 全局内存是 RWX（可读可写可执行）——把 shellcode 塞进 DLT 请求缓冲区（全局内存）即可跳转执行。

但有一个大麻烦：

只有一个客户端能连接到 NET_BROADCAST 端口，而 csm_proc_out.out 服务在持续占用它；一旦杀掉该服务，看门狗会检测到并重启车机。

解法：不能杀 csm_proc_out，那就把 exploit 代码直接注入到这个服务里；而注入本身，又用到之前”无内核模块签名校验”的漏洞——在内核卸载信号处理器，从而避免注入过程被杀。

最终，团队在 RH850 上获得了任意 CAN 消息发送能力，一举突破 CAN ID 白名单限制。

7. 网关过滤与日产私有 UDS 命令

网关（Gateway）过滤规则

车机通过 IDT CAN（即车机所在的 IT CAN） 向各个子网转发消息，网关只放行下列 CAN ID：

请注意加粗的 0x700–0x7FF：这个诊断地址段对所有业务 CAN 网络都放行。配合上一步 RH850 的任意发送能力，攻击者已经可以用 0x7xx 段的 CAN ID 直接访问 BCM、ADAS。而典型诊断请求（0x707/0x708 等）又正好落在这个区间——这就是”篡改流量过滤”（PCA_NISSAN_009）的根源。

挖掘日产私有 UDS 命令

最省事（但不便宜）的办法，是直接买一台诊断设备：CONSULT III。通过对诊断软件的 UI 操作捕获 USB 流量，就能定位隐藏的 UDS 命令。

由此提取出的关键私有命令（均发往 BCM/ADAS，CAN ID 落点与网关白名单吻合）：

注：这些私有 UDS 命令（安全访问所需的 seed/key 已通过诊断流量顺带拿到）与 0x7xx 网关卡位叠加，是整条攻击链”最后一百米”的关键拼图。

8. 攻击链全景与漏洞清单

攻击链全图

五步演示动画，详见随机附带的讲解页：

完整攻击演示视频：youtu.be/56VreoKtStw

漏洞清单

9. 披露时间线与防护建议

曲折的披露过程

研究团队第一时间（2023-08-02）就把通告发给了日产安全团队，但随后的一年半里经历了一场”踢皮球”马拉松：

• 2023-08-02：PCAutomotive 向日产网络安全团队发送通告；
• 2023-08 ~ 2023-12：就漏洞严重性反复邮件沟通；
• 2024-01-04：发出完整攻击链视频演示，同步通知发布计划；
• 2024-01-26：日产确认漏洞属实，开始规划缓解，并授权团队自行申请 CVE；
• 2024-04-25：向 MITRE 申请 CVE；
• 2024-05-19：MITRE 把皮球踢给 Bosch PSIRT；
• 2024-09-10：向 Bosch PSIRT 发 CVE 登记申请；
• 2024-09-11：Bosch PSIRT 表示从未从日产处收到任何漏洞信息；
• 2024-09-23：把通告发给 Bosch PSIRT；
• 2025-03-11：Bosch PSIRT 确认内容、拒绝登记 CVE，转给 ASRG；
• 2025-03-18：向 ASRG 提交 CVE 登记。

最终由 ASRG（Automotive Security Research Group） 受理了 CVE 登记。需要说明的是：MITRE 与 CVE 编号的分配有相应规范，Bosch PSIRT 的”拒绝登记”并不等于否决漏洞本身，而通常是因为 CVE 的官方登记权归 owneing 厂商（此处为日产）。

各方的修复与缓解

• Nissan：计划通过 OTA 更新能力与硬件改版（”hardware revisions”）修复未来车型；现款 Leaf 通过经销商固件更新（媒体报道指向 2025 年 Q3）；宝马、采矿等场景的 BCM 相关建议参考日产官方公告。
• Bosch：作为车机（IVI）制造商，审核了 Redbend 服务配置与 v850/INC 协议实现；
• Alps Alpine：修复蓝牙栈的多处边界校验；
• 车主侧：在公共区域停车时关闭蓝牙；关注经销商固件更新（NHTSA 相关编号 2025-LEAF-004）；留意后视镜、车灯等异常动作。

给汽车行业的三点启示

1. 供应链即攻击面：一块车机里叠加了 Bosch（IVI）、Alps Alpine（蓝牙栈）、NXP（i.MX6 SoC / HAB）、瑞萨（RH850）等多家供应商，任何一家的疏漏都会传导到整车。共享组件（如 Bosch IVI、Bluedragon 蓝牙栈）意味着同类漏洞可能在多车型、多品牌间复现。
2. 网关过滤要”内外有别”：0x700–0x7FF 诊断段直通业务网络的疏忽，让”越权访问 BCM/ADAS”成为可能。网关应严格按最小权限原则对待诊断报文，而不是一刀切放行。
3. 老系统 + 新威胁=高浓度风险：运行 Linux 3.14、无 SELinux、无内核模块签名校验、tmpfs 可执行的系统，一旦拿到 root，整个纵深防御基本清零。

附录：参考链接

• PCAutomotive 官方通告：https://pcautomotive.com/（Security Advisories 栏目）
• 演讲视频（Black Hat Asia 2025）：https://youtu.be/56VreoKtStw
• CVE 条目（MITRE）：CVE-2025-32056 ~ 32063、CVE-2017-7932
• 媒体解读：Cyber Security News – Nissan Leaf Vulnerability Exploited（2025-04-08）
• 媒体解读：SecurityWeek – Nissan Leaf Hacked for Remote Spying, Physical Takeover
• Bosch OSS SDK（INC 协议源码）：https://oss.bosch-cm.com/download/Nissan_AIVI/2610_190620/OSS_DVD_Content.zip
• INC 协议上游补丁讨论：https://lwn.net/Articles/706002/

本文基于 PCAutomotive 在 Black Hat Asia 2025 的公开演讲内容整理与解读，全部信息均来自公开来源。文中代码、CAN 消息与漏洞描述均以演讲幻灯片原文为准。