特斯拉的OTA升级过程

腾讯科恩实验室的李兄给了我授权有关于《BlackHat 2018 | 对特斯拉汽车全方位的渗透测试》和Black Hat上的文章

《FREE-FALL: HACKING TESLA FROM WIRELESS TO CAN BUS》

《OVER-THE-AIR: HOW WE REMOTELY COMPROMISED THE GATEWAY, BCM, AND AUTOPILOT ECUS OF TESLA CARS》

里面有很大的一部分是利用Webkit漏洞进行渗透攻击。我读了以后觉得挺有趣的，其中主体分为两部分：

Tesla 的OTA的主要过程

渗透攻击的过程（这个要花一些时间再学习下）

本文主要根据这些信息，梳理一下，Tesla 的OTA过程

特斯拉的OTA升级过程大致可由几个关键步骤描述。

1）OTA过程云端通过特斯拉自有的握手协议下发固件下载地址后，特斯拉中控屏上的cid-updater会从云端下载固件，进行解密并校验其完整性

通过类似于A/B Update的方式，车内其他强运算力的联网组件（如IC、APE等）根据cid-updater提供的固件文件进行升级。

CID-updater还会负责根据固件包中的目录信息与车辆配置做比照，据此产生release.tgz文件，并和升级软件boot.img一同提供给网关。然后网关执行上述升级软件，更新在网关上连接的二十余个ECU。

备注：Tesla的OTA机制中的一些关键文件，boot.img和release.tgz，负责向ECU提供固件。 这些文件无法直接在特斯拉服务器发布的更新包中找到，关于如何从特斯拉的服务器获取更新包以及汽车方面的整个更新过程仍然不清楚，这个过程仍未公开。

1）整车企业的云端：握手和固件包（FIRMWARE BUNDLE）

特斯拉有一个OTA框架，完成OTA程序需要这些模块：

Message box

Firmware gathering

Job management

大多数模块放在CID上的QtCar和QtCarServer中，作为云代理的一部分。 一旦建立了可信通道，代理就会设置一个端口，远程服务器可以将消息直接推送到汽车。必要时将从服务器端消息框中提取未读消息。 在OTA更新期间，这些代理主要用来传递信息，而不是执行实际更新操作。

FOTA过程以消息开头，开始的时候用带有命令initiate_firmware_handshake的消息，收到消息后，代理会将握手命令发送到cid-updater，与服务器进行握手。 握手期间需要执行以下步骤：

cid-updater把整车的硬件配置字符串和package_signature一起发送到远程服务器，package_signature是根据整车ECU现有版本生成

整车企业的云端（固件服务器）将验证该信息，根据当前版本提供固件包（FIRMWARE BUNDLE），包括固件包的下载地址、校验和和解密信息。 SquashFS包含除了Autopilot以外的其他所有ECU文件

固件包通过CDN加密渠道分发，cid-updater会进行下载、验证和解密

一旦提供了合法固件，cid-updater根据汽车配置收集正确的文件，并将这些文件分发到汽车的ECU内。 在OTA更新过程中，作业管理器负责向远程服务器报告当前状态和错误信息， 每个更新作业都有一个用于跟踪使用情况的作业ID。

2）车辆端：以太网连接的ECU

中控台和仪表盘是特斯拉车中两个主要的更新组建，都有一个名为cid-updater和ic-updater的updater守护进程，这些二进制文件之间共享了一些代码，但这两个守护进程的主要目的是不同的。

cid-updater负责在可靠的通信通道建立后与远程服务器通信，获取固件包，并提供必要的文件和信息作为辅助服务器，

ic-updater则专注于更新仪表盘本身。可将cid-updater视为本地服务器，ic-updater视为远程代理。

cid-updater和ic-updater都有一个名为command_service_listener的服务，此服务将打开一个端口，服务器可以执行RPC直接调用代理上的函数。一旦准备好所有内容，代理将使用此服务获取客户端的更新代理。服务器使用以下过程控制远程代理：

1.远程单元将停止所有其他工作并准备好gostaged，会尝试下载目标的文件包。

2.本地服务器启动HTTP服务器并提供更新文件，文件准备好后，将通知远程代理。

3.远程代理下载更新文件，下载文件并验证其签名后，更新程序将进行分段

4.将更新文件刷入ECU，对于仪表盘来说

假设当前在Part A运行

将新的rootfs图像和DTB刷入 Part B

将新的Kernal写入Part B

将主引导链和恢复引导链切换到Part B

检查引导链以确保下次引导是可接受的

完成所有这些操作后，设备将处于暂停和非活动状态。

5.经过最后的准备工作后，设备将重新启动：代理和服务器之间将持续连接，服务器可以获得有关当前更新状态的最新信息

3）车辆端：网关转换的CAN总线ECU

这些ECU的更新文件存储在文件夹（squashfs-root）/ deploy / seed_artifacts_v2中 ：boot.img、release_version.txt 、version_map2.tsv和Signed_metadata_map.tsv、internal_option_defaults.tsv、ECUNAME/, like esp/, gtw/ etc

boot.img文件在升级时运行，并从release.tgz读取固件文件。 boot.img包含一个签名，在其原始EOF之后填充。 发送更新命令时，将检查此签名是否通过公钥验证。

Boot.img中的一个重要步骤是读取固件包release.tgz，包含网关用来更新相应ECU的所有文件，每个ECU只有一个固件文件。 从ECUNAME / PROVIDERID / ECUFWNAME.hex复制特定的固件文件。 在打包tar文件时，cid-updater从网关获取ECU信息和汽车信息，并根据signed_metadata_map.tsv中的表选择正确的PROVIDERID，文件格式如下：

以下是刷写ECU的关键步骤：

1.制作固件包，cid-updater将从网关获得最新的ECU硬件信息。对于每个ECU，cid-updater将搜索signed_metadata_map.tsv以查看哪条线与当前汽车具有相同的Requirements字段。找到后，它会将PATH_TO_FILE中的文件复制到名为New_name的tar文件中。为了简化更新包，cid-updater只会将signed_metadata_map.tsv中的相应行复制到release.tgz中具有相同名称的文件中。

2.根据更新模式，在SD卡中创建UPD文件, updater读取此文件以了解其当前状态。

3.更新程序boot.img上传到SD卡，并使用文件名重新启动。

当updater执行时，未修改的boot.img将每个文件读入内存，使用signed_metadata_map.tsv中相应行中的前几个字段填充，并使用符号值和启动时保存的公钥验证其签名.IMG。更新程序一旦找到不正确的固件文件就会退出，更新将导致失败。所有签名和散列算法都使用带有SHA512的Ed25519，并仔细选择所有公钥和常量。

小结：周末花了挺长时间整理了一下，确实挺有意思的，供各位读者参考，感谢科恩实验室的研究和整理，我这里主要做一些我看得懂的摘录和整理