特斯拉的Autopilot是马斯克最引以为豪的系统之一，其可提供L2级别的自动驾驶功能。Autopilot系统主要依赖于摄像头、超声波传感器和雷达。此外，Autopilot在HW3.0之前的版本配备了来自 Nvidia 等制造商的计算硬件，允许车辆使用深度学习处理数据以实时对条件做出反应。
APE，即“Autopilot ECU”，是特斯拉自动驾驶技术的关键部件。虽然已经有很多文章谈论它的硬件解决方案，但关于它的软件的讨论却少得多。众所周知之前所有的 APE 2.0 和 2.5 板卡都是基于 Nvidia 的 PX2 AutoChauffeur（实际上是高度定制的）。下面讨论主要集中在APE2.5。如下图1所示，简单的展示了其内部组件是如何连接的。
APE和APE-B都是Tegra芯片，和Nvidia的PX2一样。LB是英飞凌Aurix芯片。此外，还有一个英伟达的GPU（GP106）连接到 APE。APE和APE-B上运行的软件镜像基本相同，而LB有自己的固件。在 APE中，LB 是一个协处理器，支持监控 CAN 总线上的消息，控制风扇速度，确定是否应该打开APE的部分功能等。在原始 PX2 板上，Aurix 芯片在串口上运行一个控制台 有几个有用的功能。但是在APE 2.5上，这个芯片只提供很少的控制台命令。
并非 APE 和 APE-B 都用于 Autopilot，特别是考虑到并非两个芯片都连接到所有传感器。来自雷达和其他传感器的信息通过一些 CAN 总线（包括私有的）传输，并由 LB 转发为 UDP 消息，UDP 消息可以被两个处理器接收。
但是所有摄像头，尤其是主摄像头、窄摄像头和鱼眼摄像头仅通过 CSI 接口连接到 APE。此外GPU 芯片仅连接到APE，没有看到足够的证据表明两个Tegra 芯片（以及摄像头）共享 GPU 芯片。因此我们认为 APE-B 只是一个类似“存根功能”的东西，而 APE 是执行实际工作的实际芯片。
后来对固件的调查表明，APE-B 有时可能会从用于启动 APE 的同一镜像启动。启动过程让我们相信，只要 APE 和 APE-B 运行相同的固件，我们就可以轻松实施我们的攻击。APE 的固件是一个 SquashFS 镜像，没有任何加密。该映像运行高度定制的 Linux（如 CID 和 IC）。在固件中我们观察到 APE 软件的二进制文件位于 /opt/autopilot 文件夹下。
智特斯拉的视觉系统
在本节中，我们将介绍Autopilot中视觉系统的实现细节。二元视觉是 Autopilot 的关键组件之一。Autopilot 使用它来处理从所有摄像头收集的数据。我们对使用纯计算机视觉解决方案的自动雨刷和车道识别这两个功能进行了大量反向工作。这些函数的特殊过程可以概括为两部分：它们共同的预处理，以及它们自己的神经网络计算和后处理。
我们认为特斯拉使用的是12位HDR摄像头，可能是RCCB。视觉神经网络模型并不是为了直接处理这些图像而设计的。因此，程序需要先对图像进行预处理。
如前所述，不同的可执行文件（或服务）之间的通信是通过共享内存进行的，包括从相机获取的原始图像。这些图像是根据调度图从某些文件句柄中获取的。
此外，视觉任务还会从 /dev/i2c 和其他共享内存区域获取一些控制消息。出于诊断和产品改进的目的，图像的副本也将保存到共享内存中，以便快照任务可以获取和发送它。快照任务在不同的任务中有大量的记录点，这使得调试和功能开发工作更加高效。
从快照中收集的原始数据为 HDR、1280×960 和 16 位小端整数，色调映射图像如下图3所示。
我们之前提到过函数 tesla:TslaOctopusDetector::unit_process_per_camera，它将处理来自每个相机的每一帧，包括预处理过程。首先从图像中删除一些前缀和后缀行。根据安森美为AR0132AT（可能不是特斯拉的传感器，但可能是类似型号）提供的数据手册，这些线可能仅用于像素调整和诊断目的，因此我们假设自动驾驶任务没有使用那些像素。
下一步是色调映射，调整相机HDR图像的动态范围，使其适应神经网络的输入模型。在早期版本中，这个映像是通过tmp_cuda_exp_tonemapping处理的，现在重命名的函数是tesla::t_cuda_std_tmrc::compute，有很多改进。
* linear_signal, 经过HDR转换和距离压缩的原始图像；
* detail_layer，边界检测的结果，可能会使用canny边缘检测器并进行一些改进；
* bilateral_output，可能是某些双边过滤器的结果；
此外，输出还包含一些其他层，但由于它与我们的研究没有太大关系，我们不在这里提及它们。
对不同相机的预处理可能不同。虽然目前我们只注意到代码中的去马赛克控制布尔值，但我们相信为不同的相机添加不同的预处理过滤器很容易。
预处理后的图像输出根据其类型和位置通过几个不同的模块进行处理。目前，我们观察到三种不同的类型，通过枚举来表示所有摄像头的为位置，如图4所示。
通常，这些处理过的图像都会被写入到它们对应的神经网络的输入缓冲区中。每个神经网络解析输入图像，并为 tesla::t_inference_engine<float>。各种后处理程序接收这些结果，并向控制器提供控制提示。这些后置处理器负责多项工作，包括识别汽车、物体和车道，绘制周围环境的地图，以及确定降雨量。令我们惊讶的是，这些工作大部分都是在一个感知神经网络内完成的。
自动驾驶任务的复杂性需要为不同的相机分配不同的推理引擎，配置不同的检测器，并填充几种不同的配置。因此，Tesla 使用大类来管理这些功能。解析出每个成员并不是一件容易的事，尤其是对于一个被剥离的二进制文件，填充了大类和 Boost 类型。
智远程转向控制
在本节中，我们将介绍 APE 单元如何与 EPAS（电动助力转向）单元一起实现转向系统控制。此外，由于我们已经获得了 APE 的 root 访问权限，我们将演示如何远程影响 EPAS 单元以控制特斯拉汽车在不同驾驶模式下的转向系统。
APE是特斯拉高级驾驶辅助系统的核心单元。它负责汽车在辅助驾驶和自动泊车模式下的转向系统控制和电子速度控制。据我们所知，这些先进的辅助驾驶功能是基于高级视觉和汽车总线（以太网、CAN、LIN、FlexRay）系统。
通过对APE中与CAN总线相关的一些服务(canrx、cantx等)进行逆向工程，初步了解了APE CAN总线系统的网络结构。如图6所示，APE集成了两个CAN-Bus接口(CAN0和CAN1)，通过CAN1与雷达互连。为了冗余机制或其他安全考虑，CAN0和LB一起连接到私有CAN总线。
此外，由于域隔离，APE与LB单元共享一个逻辑CAN(称为APE2LB_CAN)总线，用于与PT(动力总成)和CH(底盘)CAN总线通信。
对于特斯拉汽车，转向系统可由底盘 CAN 总线上的 EPAS 单元控制。虽然有了APE的系统的完全接入，但显然我们需要打破APE的CAN总线系统的一些安全机制障碍，比如冗余CAN总线、CAN消息计数器和域隔离。
我们主要关注 cantx 服务，它接收来自视觉系统的中间信号，然后将信号转换为车辆控制命令。这些命令将被封装到特殊的 CAN 消息（APE2LB_CAN）中，并通过 LB 单元转发到 PT/CH CAN 总线。
APE2LB_CAN 是一种基于 UDP 协议的 CAN 报文。APE 中的 cantx 服务使用 APE2LB_CAN 与 LB 单元进行通信。使用APE2LB_CAN，APE可以与LB构建逻辑CAN总线。LB 更像是一个支持以太网和 CAN 协议的网关，它负责从 APE2LB_CAN 中提取 CAN ID 和原始 CAN 报文，然后将它们封装成一个标准的 CAN 报文帧，最后将该帧传送到不同 CAN 总线上的各个 ECU（ Chassis, Body, Powertrain) 。
DasSteeringControlMessage (DSCM)是最关键的CAN信息之一，用于汽车在ACC (Adaptive Cruise control)和APC (Automatic Parking control)两种模式下的转向系统控制。
在cantx服务的DasSteeringControlMessageEmitter::populate_message()函数中，产生DSCM并封装到APE2LB_CAN的raw_can_msg中，DSCM的目的地包括一些与转向系统和汽车速度相关的ECU，如EPAS（Electric Power Assisted Steering） 和 EPB（电动驻车制动器）装置。
图8 DasSteeringControlMessage帧格式
2、第三个字节是 CAN 报文计数器和控制类型的组合。该字节的低 6 位是 CAN 报文计数器，一旦填充了一个 CAN 报文，报文计数器应增加 0x01。第三个字节的高2位表示CAN报文的控制类型。当特斯拉汽车处于ACC或APC模式时，控制类型应设置为0x01，表示启用转向角控制，LB单元允许APE让EPAS单元控制转向系统。
图9 填充DasSteeringControlMessage的代码片段
CAN消息的第四个字节是一个单字节的校验和，它是由8bit_checksum算法以CAN ID (0x0488)作为初始种子计算出来的:
图11显示了在cantx服务的DasSteeringControlMessageEmitter::finalize_message()函数中填写了DasSteeringControlMessage的校验和：
图11 DasSteeringControlMessage的代码片段
远程控制转向系统
在弄清楚APE、LB和其他与转向系统控制相关的ECU（EPAS、EPB）之间的CAN-bus通信后，我们还不能通过直接从APE向LB注入恶意DSCM来欺骗EPAS控制转向系统 . 原因是，如前所述，DSCM 受到消息时间戳和计数器的保护，以及在 APE 中称为 PARTY CAN-bus 的冗余 CAN。
最后，我们找到了一个有效的解决方案：将恶意代码动态注入 cantx 服务，并钩住 cantx 服务的 DasSteeringControlMessageEmitter::finalize_message() 函数，以重用 DSCM 的时间戳和计数器，以任意值操纵 DSCM。此外，关键部分是DSCM的控制类型必须设置为0x01，APE2LB_CAN的can_bus设置为0x01，表示DSCM的目的地是底盘CAN总线。
到目前为止，我们能够通过利用这些漏洞远程入侵 APE 的系统，从远程移动设备向 APE 中的 cantx 服务发送任意 DSCM。
为了可视化这个针对转向系统的远程攻击链，我们设法使用游戏手柄演示了远程转向控制。游戏手柄控制器的控制过程如下图所示：游戏手柄通过蓝牙连接到我们的移动设备上。同时，移动设备接收来自游戏手柄的控制信号并将该信号转换成相应的DSCM。一旦 APE 受到威胁，cantx 服务将定期通过 3G/Wi-Fi 从移动设备拉取 DSCM。此外，APE 需要不断地将实时转向角推送到移动设备，以计算出我们预期的准确转向角。
在测试中，我们发现这种方法在不同的驾驶模式下对汽车有不同的影响：
1、当汽车停放时，我们可以毫无限制地控制转向系统；
2、当汽车通过换挡手柄从R(倒车)模式切换到D(驾驶)模式时，APE似乎认为汽车处于APC(自动泊车控制)模式，该模式允许我们以大约8km /H的速度控制转向系统；
3、当汽车处于高速ACC(自适应巡航控制)模式时，转向系统也可以不受限制地控制；
4、即使汽车不在ACC(自适应巡航控制)模式下，方向盘也有可能受到影响。
以上就是通过静态逆向工程和动态调试，对APE视觉系统进行了深入分析。根据研究结果，在物理世界做了一些实验测试，成功的让Tesla APE在攻击场景下表现异常。这证明，通过一些物理环境装饰，可以在不与车辆物理或远程连接的情况下，干扰或在一定程度上控制车辆。
转发本文并点在看，截图至后台，获取Model3的dbc
详解功能安全概念阶段
详细揭秘大众ID.4的高压系统
特斯拉Model 3的BMS系统
ISO 26262中的安全分析：FMEA、FMEDA与FTA
从工程师角度看上汽掌门人谈到的与华为的合作
详解特斯拉FSD芯片的解决方案
结合AUTOSAR和DDS实现灵活的车辆架构
原文始发于微信公众号（汽车ECU开发）：特斯拉Autopilot系统安全研究|附dbc下载
