基于AM335X开发板 ARM Cortex-A8——NAND FLASH版本核心板使用说明

前 言：

NAND FLASH版本和eMMC版本核心板使用方法基本一致。本文主要描述U-Boot编译、基础设备树文件编译、固化Linux系统NAND FLASH分区说明和NAND FLASH启动系统、固化Linux系统、AND FLASH读写测试等，NAND FLASH版本与eMMC版本核心板在使用方面的不同之处，相同之处将不重复描述。

创龙科技TL335x-EVM-S是一款基于TI Sitara系列AM3352/AM3354/AM3359 ARM Cortex-A8高性能低功耗处理器设计的评估板。

评估板接口资源丰富，引出双路千兆网口、LCD、HDMI、GPMC、CAN等接口，方便用户快速进行产品方案评估与技术预研，应用在通讯管理、数据采集、人机交互、运动控制、智能电力等典型领域。

U-Boot编译

进行U-Boot编译选项配置时，请执行如下命令。

Host# make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_s_nandboot_defconfig

图 1

我司提供经过验证的U-Boot镜像文件位于产品资料“4-软件资料\Linux\U-Boot\image\u-boot-2017.01-[Git系列号]-[版本号]\”目录下，分别为MLO-nand、u-boot.img-nand。系统启动卡制作完成后，请将MLO-nand和u-boot.img-nand文件复制到系统启动卡BOOT分区下，备份原有的eMMC版本MLO、u-boot.img文件，并将MLO-nand和u-boot.img-nand文件重命名为MLO、u-boot.img。

图 2

Host# sudo cp MLO-nand MLO

Host# sudo cp u-boot.img-nand u-boot.img

图 3

基础设备树文件编译

基础设备树源文件为内核源码“arch/arm/boot/dts/”目录下的tl335x-evm-s-nandflash.dts和tl335x-evm-s-nandflash-hdmi.dts，重新编译基础设备树时请使用此文件。我司提供经过验证的基础设备树文件为产品资料“4-软件资料\Linux\Kernel\image\linux-rt-4.9.65-[Git系列号]-[版本号]\”目录下的tl335x-evm-s-nandflash.dtb和tl335x-evm-s-nandflash-hdmi.dtb，请将其分别复制到系统启动卡rootfs分区以及rootfs-backup分区的boot目录下。

图 4

请执行如下命令将tl335x-evm.dtb软链到tl335x-evm-s-nandflash.dtb文件。tl335x-evm-s-nandflash.dtb支持LCD显示，如需使用HDMI显示，则将tl335x-evm.dtb软链到tl335x-evm-nandflash-hdmi.dtb文件即可。

Host# sudo rm tl335x-evm.dtb

Host# sudo ln -s tl335x-evm-s-nandflash.dtb tl335x-evm.dtb

Host# ls -l

图 5

使用替换了U-Boot和基础设备树文件的Linux系统启动卡启动评估板，进入文件系统执行如下命令可查看到NAND FLASH分区信息，即说明文件替换成功。

Target# cat /proc/mtd

图 6

固化Linux系统

本章节介绍Linux系统固化过程，包括固化U-Boot、内核、设备树和文件系统至NAND FLASH。

NAND FLASH分区说明

进入评估板系统后执行如下命令，查看NAND FLASH分区信息。

Target# cat /proc/mtd

图 7

表 1

NAND FLASH

MTD0

nand.spl：存放U-Boot第一阶段启动文件MLO

MTD1

nand.u-boot：存放U-Boot第二阶段启动文件u-boot.img

MTD2

nand.env：存放环境变量

MTD3

nand.devicetree：存放设备树文件

MTD4

nand.kernel：存放内核镜像

MTD5

nand.logo：存放LOGO文件

MTD6

nand.mini-fs：备用分区，一般存放小型文件系统（暂未使用）

MTD7

nand.rootfs：存放文件系统

固化Linux系统

Linux系统启动卡制作时，已将系统固化的脚本文件mknandboot.sh复制到了Linux系统启动卡文件系统的“/opt/tools/”目录下。

图 8

执行如下命令进行一键固化。

Target# /opt/tools/mknandboot.sh

图 9

脚本会进行如下操作：

擦除NAND FLASH。将Linux系统启动卡BOOT分区中的U-Boot、LOGO固化至NAND FLASH对应分区。将Linux系统启动卡rootfs-backup分区中的文件系统boot目录下的内核镜像和基础设备树文件固化至NAND FLASH对应分区。将Linux系统启动卡rootfs-backup分区中的文件系统固化至NAND FLASH对应分区。

用时约5~10min，Linux系统固化成功，同时串口调试终端打印提示信息。

从NAND FLASH启动系统

评估板断电，将Linux系统启动卡从评估板Micro SD卡槽中取出，根据评估底板丝印将拨码开关拨为10110(1~5)，此档位为NAND FLASH启动模式。评估板上电，串口调试终端将会打印如下类似启动信息。

图 10

图 11

NAND FLASH读写测试

本章节对NAND FLASH的MTD6分区进行读写速度测试。MTD6是NAND FLASH的备用分区，一般存放小型文件系统，大小为32MByte。读写测试会将该分区内容擦除，请做好数据备份。

执行如下命令查询NAND FLASH分区，确认MTD6分区大小（读写请勿超出分区大小），将该分区内容擦除。

Target# cat /proc/mtd

Target# flash_erase /dev/mtd6 0 0

图 12

NAND FLASH写速度测试

进入评估板文件系统，执行如下命令对NAND FLASH进行写速度测试。

Target# time dd if=/dev/zero of=/dev/mtd6 bs=1024k count=30

图 13

此处一共写30MByte测试数据到NAND FLASH的MTD6分区下，可看到本次测试的NAND FLASH写速度约为：30MByte/7.79s=3.85MB/s。

NAND FLASH读速度测试

重启评估板，进入评估板文件系统，执行如下命令对NAND FLASH进行读速度测试。

Target# time dd if=/dev/mtd6 of=/dev/null bs=1024k count=30

图 14

此处从NAND FLASH的MTD6分区读取30MByte数据，可看到本次测试的NAND FLASH读速度约为：30MByte/4.44s=6.75MB/s。

怎么使用黑客手段逆向分析一点点揭开特拉斯固件更新过程

Tesla Model S如何更新其固件？对显示器和仪表盘进行逆向工程时，我们发现了什么？

第1部分：分析硬件，并在CID中完成14层PCB

第2部分：逆转固件更新过程和Suicide Bomber模式的重要性

CID VCM软件架构

与大多数嵌入式系统相比，CID更大，更复杂；对于嵌入式系统而言，CID则是Linux发行的Ubuntu的完整版本，这对嵌入式系统而言是不寻常的。

在内核中，我们找到了自定义元素，例如Harman Redbend。该内核是使用Linaro工具链构建的。

为了满足使用开源软件的法律要求，特斯拉在项目进行到一半的时候就透露了内核的来源。但是，这对逆向工程无济于事，因为它仅占系统的一小部分。

引导加载VCM

这似乎与许多Tegra设备相似。

BPMP（启动和电源管理处理器）是Tegra SoC的辅助处理器。它执行存储在ROM中的只读引导程序，并且是ARM7处理器。此时，我们关闭了Tegra中的主处理器。

当BPMP ROM引导加载程序从NOR闪存中读取一条数据时，会提供大量信息。这称为BCT（引导配置表）。信息包括：

内存中几个引导程序的地址

将引导程序加载到SDRAM的位置

SDRAM中引导加载程序的入口点

连接到系统的SDRAM的配置（需要进行引导才能访问）

将第一阶段引导加载程序复制到SDRAM之后，BPMP开始执行。此时，我们尚未打开Tegra中的主处理器。

第一阶段的引导加载程序似乎称为QUICKBOOT，其大小约为56KiBytes。明确引用了AES-CMAC（消息认证代码）。此处使用的字符串中包括“ AES-CMAC Xor”，这些字符串也可在开源引导程序U-boot中找到（github）。

来自第一阶段引导程序的字符串

人们可能会认为引导加载程序是基于U-boot的，但是特定的加密功能实际上是由Nvidia编写的，因此可以由Nvidia在其他地方免费使用。

当第一阶段引导加载程序正确设置SoC时，主处理器就会启动。然后加载第二阶段的引导加载程序，以允许主处理器运行。

当我们解压缩并运行内核时，我们发现第二阶段的引导程序非常简单。

我们没有看到任何加密保护的迹象。它似乎不是基于任何广为人知的引导程序，而是我们认为它是完全自定义的。

宽松地遵循Android bootimg格式，内核映像由一个文件中的内核和ramdisk组成。内核激活后，将运行名为/sbin/init-stage-0.sh的脚本。其主要目的是通过安装NAND闪存分区使系统完全可操作。

NOR闪光灯

我们在NOR flash中找到了BCT，第一级和第二级引导程序以及内核。

CID NOR闪存的布局

我们发现许多分区已经像到主分区和恢复分区。

NAND闪存

/ usr /文件系统存储为sqaushfs文件系统，其中包含在正常操作期间不会更改的二进制文件和脚本。

SquashFS在低资源嵌入式系统中很常见，是一种压缩的只读文件系统，它允许文件系统的不可更改部分占用较小数量的闪存。

/ var /目录包含日志，是一个小的128Mb ext4文件系统。

/ home /目录包含升级文件和临时数据，以ext4文件系统的形式存储在其余的闪存中。

/ home和/ var目录覆盖在只读文件系统上，仅允许少数几个目录被读/写，这意味着系统的大部分内容都是只读的。

双库固件

初始ROM引导加载程序运行后，引导加载过程可以选择两个映像：

ROM引导加载程序–仅提供一个副本。

除非存在灾难性的硬件问题，否则它是不变的，并且不太可能失败。

stage1_primary / stage1_recovery –由ROM引导程序顺序选择。

如果第一个失败，则第二个运行。

除了内存中的位置，这两个引导程序看上去几乎相同stage2_primary / stage2_recovery –在此运行的引导程序由哪个stage1引导程序运行确定。

同样，两个引导加载程序看起来几乎相同，除了内存中的位置kernel_a / kernel_b –这两个内核的引导参数彼此非常不同系统启动时可以挂载在线/离线usr分区。

这是两个内核的引导参数：

init-stage-0.sh脚本读取thispartid的值，并加载两个/ usr / squashfs分区之一。如果其中一个损坏，则可以使用另一个恢复。

我们还可以看到AppArmor通常处于启用状态。该强制访问控制系统允许内核将二进制文件限制为受限的资源集。Ubuntu默认情况下启用此功能。Tesla上的配置看起来是标准配置。

安全启动

Tegra支持安全启动，但是围绕它的文档和代码示例看起来很零散。在开发人员论坛中，关于如何实现它有些困惑。这在高端处理器中很常见。

我们无法最终验证使用安全启动的程度，但是我们确实发现了几件事。ROM引导加载程序通过内部存储的密钥验证BCT的签名。这称为SBK。AES-CMAC是BCT的一部分，并经过了验证。这是对称加密-如果发现了密钥，则可以生成有效的BCT。

我们无法确定SBK在每个设备/车辆上是唯一的还是较大的组所共有。我们将需要使用多个车辆来确定这一点。

另外，Tegra可以在内部仅存储一个公钥，因此可以使用公钥加密。即使发现了公钥，也仍然无法生成正确签名的BCT图像。

这是对称密钥的更强替代方案。据我们估计，在2015年之前（特斯拉CID部署后），软件支持还没有到位。

第一级引导程序执行第二级引导程序的AES-CMAC。我们无法确定在此使用了哪个密钥，但是Tegra文档指出也可以使用SBK。

第二阶段引导加载程序仅执行内核的CRC。如果信任链断开，攻击者可能会在此阶段将恶意内核加载到设备上。

用户空间软件

CID一旦启动，便进入用户空间。

一系列Qt二进制文件呈现了CID的用户界面。我们仅对它们进行了非常有限的逆向工程。一个8字符的PIN保护CID上的服务菜单，该菜单似乎每天都在变化，并由CID实现。

Shell脚本在车辆中实现了大量功能。逆向工程变得容易，因为它们是人类可读的文本文件。

固件更新机制

我们观察到了多种固件更新机制。

从车辆到特斯拉系统的出站VPN连接是所有机制的核心。我们没有观察到任何其他形式的传输加密。来自CID的所有请求都是使用未加密的HTTP发出的。

我们看到了以下更新机制：

1、Shell脚本–看起来像旧系统，但与后来的更新程序二进制机制有很多共同点。

2、更新二进制文件–大型的多调用二进制文件轮询以获取更新，下载更新并将其应用于系统。

3、内核/引导加载程序–内核和引导加载程序由特定的二进制文件更新。

4、地图– VPN连接用于下载地图数据常规ECU –通过CAN网关将固件更新从CID分发到ECU，使用了一个复杂的过程。

5、Wi-Fi模块和蜂窝调制解调器的USB固件。

我们在下面考虑这些。

VPN连接

通过CID建立与Tesla服务器的OpenVPN连接。每辆车的钥匙和证书用于执行此操作。车辆的VIN是证书的主题。

示例VPN密钥

我们能够从本地访问CID的文件系统中提取这些密钥，然后通过在另一台机器上使用它们来连接到Tesla网络。

密钥已于2018年5月31日到期。如果此后没有通过固件更新进行更新，则似乎没有回退机制。使用安全配置的VPN，将无法拦截通信或对其进行篡改。可以通过Wi-Fi或蜂窝网络（无论哪个可用）建立VPN。

通信的某些方面（例如，大量下载）显示出对Wi-Fi的亲和力。大概是为了减少特斯拉的成本。

连接到VPN时，会自动建立许多路由：

32.0.0/1633.0.0/16224.0.0/24232.75.0/24232.79.0/24

根据特斯拉漏洞赏金计划，对这些范围进行了完整的端口扫描，仅发现了少数主机：

1、vn.teslamotors.com –车辆数据和状态，安全令牌更新，以访问诊断和IC SSH

2、vn.teslamotors.com –固件下载和更新

3、Firmware-bundles.vn.teslamotors.com –已失效的固件更新服务器

4、vn.teslamotors.com –地图数据和更新

根据特斯拉安全性的早期报道，VPN密钥存储在连接到网关的大型SD卡上。通过卸下SD卡，可以轻松恢复这些卡。被测车辆并非如此。在这里，它们存储在CID中VCM上的NAND闪存中。

固件服务器

来自服务器的示例JSON响应

Shell脚本固件更新

我们在Tesla文件系统上找到了旧版固件更新机制，该机制采用了一系列Shell脚本来执行更新。即使它不再运行（没有返回有效的下载URL），它也提供了许多有用的信息。

握手固件下载

通过Tesla VPN，shell脚本/ local / bin / do-firmware-handshake获取并安装固件更新。

该脚本可以通过多种来源启动：

1、定期使用新规事件管理器（尽管未在操作中看到）

2、响应名为“ firmware-handshake”的新贵事件

3、手动（尽管未观察到，但已在文件注释中指出）

该脚本从高层获取并应用更新，如下所示。

该脚本使用哨兵文件检查是否正在进行现有升级。

打开升级包并进行安装的外壳程序脚本，检查“ unpack.sh”脚本是否正在运行。

如果正在进行升级，则执行固件握手，因为更新已经在进行中。

可以假设网关正在处理升级，并且如果哨兵文件小于20分钟，则do-hardware-shash退出。因此，不会对网关执行任何主动检查以查看其是否被占用。

如果网关更新的时间早于20分钟，则将其挂起，并且握手过程将继续。要查看VPN是否已连接，脚本将检查接口tun0是否存在。

如果未连接VPN，脚本将等待30秒钟再试一次。没有积极尝试建立VPN隧道-另一个外部过程会这样做。建立VPN连接后，脚本将连接到以下URL：firmware.vn.teslamotors.com:4567/vehicles/<VIN>/handshake

发送以下数据：

vehicle_hardware_configuration_string –由“硬件ID”派生，这是一个用逗号分隔的字符串，用于描述网关存储的车辆配置。另一个外壳程序脚本/ usr / local / bin / vehicle_hardware_configuration_string生成此字符串。格式：

从/ etc / swver读取，这是在CID上运行的软件版本。

然后，服务器返回JSON字符串，该字符串应包含以下字段：

Firmware_download_url –我们将下载的文件的位置

Firmware_download_file_md5 –我们将下载的文件的MD5校验

Download_status_url –用于回传升级状态的URL

Vehicle_job_status_urlUnpack_size –解压缩的固件文件的大小

Install_size –安装固件文件所需的大小

我们发现仍然可以发出这些请求并接受响应。至关重要的是，我们发现可以使用另一辆汽车的VPN来请求任何VIN。

我们很惊讶地发现，JSON响应不是使用jq这样的健壮解决方案，而是使用awk，gsub和split手动解析。然后对这些字段进行一些基本的完整性检查。为了指示升级已经开始，将download_status_url存储在前哨文件中。

通过对文件发出HTTP HEAD请求，然后检查firmware_download_url文件的大小。我们认为这是一种奇怪的机制，因为它可以简单地在JSON响应中传输。

firmware_download_url在获得的所有响应中都指向服务器firmware-bundles.vn.teslamotors.com。尽管是通过握手过程发出的，但没有任何链接有效。

使用JSON响应中的unpack_size和install_size，对Flash文件系统上的备用空间执行基本检查。为了防止CID休眠60分钟，将对在端口4035上的CID上运行的Web API发出请求。现在下载文件。

它作为一个部分进行下载-不会以任何方式分块或拆分。如果不是预期的大小，则再次尝试下载。

无法逃避这种情况，这意味着脚本可能会陷入无限循环。对于测试期间获得的示例firmware_download_url示例，这些文件仅只能通过Tesla VPN下载。

然后将文件的md5校验和与期望值进行比较。如果文件不匹配，则再次尝试下载文件。下载文件后，将通过CID屏幕上的弹出窗口提示用户升级。

另一个shell脚本/ usr / local / bin / get-response执行此操作。它向端口4070上CID上运行的Web API发出请求，并等待一个小时以做出响应。

如果用户接受更新，则下载的文件将移至/ home / tesla / dropbox，准备安装。

USB更新

使用USB记忆棒，也可以将更新文件放入/ home / tesla / dropbox。Shell脚本/ usr / local / bin / usb-upgrade执行此操作。

该脚本在文件夹/ toinstall中查找文件名，格式为文件名：ui_full_package_*_<code>_pedigree_v*.tar.gz

使用下表，从车辆的VIN码中查找<code>：

某些VIN通过USB更新的处理方式有所不同

他的表格显示有带有预设VINS的开发工具。如果此文件名中没有CID上的软件的当前版本，则将文件复制到Dropbox中，然后安装。

由于检查是幼稚的，并且忽略了实际版本，因此可以进行固件的升级和降级。

脚本中似乎有一个错误。如果脚本中不存在车辆的VIN，则返回的<code>只是空白。这将导致以下形式的文件匹配：ui_full_package_*__pedigree_v*.tar.gz。

在USB记忆棒上的给定文件夹中，攻击者似乎可以放置特制的固件更新文件并执行任意代码。我们尝试了很多次，但无法触发。另一个安全控制措施是阻止脚本被调用，但是我们无法确定它是什么。

Dropbox安装

位于/ local / bin的脚本“ unpack.sh”安装位于/ home / tesla / dropbox文件夹中的软件包。

该脚本描述了该过程，并对其进行了大量注释和。

尽管它是自定义的，但软件包格式非常简单，攻击者很容易重新创建。从高层次来看，该过程如下：检查是否提供了文件名，并且该文件存在。一旦汽车“停放”，另一个shell脚本将执行此检查-/ usr / local / bin / car-is-parked。

在CID的端口4035上，这会向Web API发出HTTP请求，以检查汽车是否处于“停车”档。

值得注意的是，停放脚本包含检查速度为零的函数，但是这些函数不会被调用。

脚本等待5分钟，然后再次检查汽车是否未停放。

为了防止CID休眠20分钟，然后在端口4035上向Web API发出请求。使用实用程序mktemp在/home/tesla/unpack.tmp-XXXXX中创建一个临时目录。tar文件已解压缩到临时目录中。检查是否存在4个文件：

NAME of the packageVERSION number of the packagemd5sums of files in the packagetar.gz – files associated with the package

该过程不会检查它是否存在，但是它期望文件“ install.sh”存在。为了检查文件的完整性，将文件md5sums馈送到工具md5sum。这不增加安全性，而纯粹是完整性检查。

将名称，版本和data.tar.gz作为参数传递后，将执行文件install.sh。为了最终控制软件包的功能，install.sh可以执行root用户通常可以执行的任何操作。

install.sh文件可以包含任意命令，并且整个过程以root用户身份运行。为了控制，攻击者可以将有效的升级程序包放置在保管箱中，以对CID或IC进行任意操作。

我们已经看到一些评论，这些评论表明，众所周知，此过程不健全且存在问题：

这种机制远非安全，它在VPN提供的传输加密之外几乎没有保护措施。这可能是不推荐使用的主要原因。我们不知道为什么它仍然存在于系统中。

开发人员可能会担心删除众多脚本之一可能会导致意想不到的后果。

更新程序更新

我们认为这是更新固件的正常机制。它是一个大型的整体二进制文件，包含大量功能。幸运的是，反向工程通过静态链接（即，将所有代码编译到其中）和调试版本（即，它包含通常会被剥离的字符串和函数名）而得以加速。

与调试信息静态链接

通过更改二进制文件的名称激活，更新程序可以采用几种不同的“个性”。每个人都可以打开一个命令端口和一个HTTP端口，它们侦听设备的所有接口。

1、ic-updater – IC的更新程序。打开用于命令的端口28493，并打开21576作为Web服务器。

2、cid-updater – CID的更新程序。打开端口25956用于命令，打开20564作为Web服务器。

3、gwxfer –用于将文件传输到网关，是gwxfer shell脚本的二进制替代，sm-updater –尚不清楚“ sm”是指什么。这可能是工厂使用的东西，因为二进制文件的其余部分都引用了“ sitemaster”。

4、ethdeploy –似乎是将软件包部署到车辆内其他设备的一种方法upackager –与网关有关，采用release.tgz（用于ECU的更新）和internal.dat（车辆的配置）和vhcs（车辆配置字符串）的参数

不同规格的不同名字

根据二进制文件的开头名称，二进制文件的行为会有所不同。这包括其执行的服务，其使用的路径和技术。该代码引用了个性存储超过330次的变量。

为了易于确定代码是否基于个性而偏离，0对应于IC，1对应于CID，5对应于SM。

用于不同个性的command / http端口

将更新程序作为“集群”运行，该系统旨在与多个设备（CID和IC）一起使用。通过VPN连接并下载固件，CID充当主服务器。

在代码中称为“继电器”，然后使用命令/ HTTP端口将固件分发到IC。更新程序在启动时执行某些任务，例如检查当前系统，将出站连接到固件服务器（称为“握手”）以及启动命令和Web服务器。

基于人格的条件流示例

尽管看到了许多错误，但是可以在QEMU仿真器中运行二进制文件。二进制程序按预期启动了两个侦听服务。

在仿真器中运行IC更新器

二进制文件在初始化期间对其自身执行sha512哈希。我们惊讶地发现，尽管sha512输出64个字节，但仅保留了前8个字节。这意味着可以使用蛮力找到哈希冲突。

hash_self对二进制文件进行sha512哈希

截断的sha512哈希输出

一般sha512sum

稍后，当向固件更新服务器发出请求时，此哈希将用作User-Agent字符串的一部分。

哈希被放入请求的用户代理部分

攻击者可以在运行替代恶意软件的同时报告预期的sha512哈希，尽管这意味着服务器可以确定正在使用哪个版本的更新程序。

这不是针对恶意行为的有力保护。通过计时器或按需执行，更新程序可以在缓冲区中处理一系列命令。可以通过cid-updater或打开的命令端口输入它们，从而允许Tesla以太网上的其他设备执行操作。

以下是任务“ fwheartbeat”的示例，该任务以1小时的间隔启动，并调用了函数start_regular_timer：

在计时器上添加了fwhearbeat

通过调用函数do_after_e_ms，还可以在固定时间段后运行命令。这是重新启动固件下载的示例：

经过一段时间后，下载重新启动正在运行

这些命令由字符串引用，可以采用许多值，并存储在大型数组中。

命令数组

使用不同的参数，命令“ install”和“ patch”都最终调用函数do_install。

像交互式命令处理器一样，该过程的命令端口提供了使用技巧和其他帮助。

要求ic-updater通过HTTP提供文件的示例

通过HTTP下载提供的文件

通过命令端口报告的当前状态

需要会话令牌来保护IC和CID之间的命令。每天更改一次，并通过VPN从Tesla服务器进行同步。如果攻击者可以嗅探IC和CID之间的连接，并使用它发送自己的命令，则攻击者可以拦截此令牌。

我们能够将二进制文件放入开发模式。完成此操作后，包括签名检查在内的大多数安全功能都被禁用。

开发模式导致签名检查被跳过

二进制文件包含大量功能。从最高层次来看，最重要的过程如下：

1、握手-将请求发送到包含车辆详细信息的Tesla服务器并接收对车辆执行操作的响应的过程。

2、基于握手下载和解密各种固件更新文件将下载并解密的固件更新文件（称为补丁（完整的固件更新）。

3、bsdiff40（二进制difs）或Redbend delta（专有二进制diff））安装到脱机闪存分区中

4、中继–将固件从CID复制到IC重新部署–将固件的离线状态复制到在线状态以进行恢复其他功能包含在二进制文件中，但未使用。

握手

类似于外壳脚本更新，有关车辆的数据使用VIN进行监控，然后发送到远程服务器，该服务器以任何可用的更新作为响应。

通过功能do_handshake向固件服务器发出POST请求。要从文件连接，这需要固件服务器的配置（包括服务器名称，端口和路径）。

配置握手请求

POST请求中包含的数据比shell脚本版本复杂，包括以下内容：

1、车辆VIN –从网关检索和缓存，而不是从文件中读取。在请求的路径中发送。

2、VHCS（车辆硬件配置字符串）–基于从网关恢复的hwids.txt的字符串（使用函数fetch_vhcs生成）。作为POST参数发送。

3、当前固件签名–使用功能read_firmware_signatures读取。从保存/ usr /分区的内存分区的后40个字节中读取固件签名。发送base64编码为POST参数。

POST请求的格式字符串

函数request_HTTP发出POST请求。它只能发出HTTP请求，而不能发出HTTPS请求。更新程序二进制文件根本没有TLS功能，这意味着握手始终在纯文本中进行，这取决于Tesla VPN的安全性。

函数tun0_is_up检查VPN连接。仅检查设备tun0是否存在，这似乎很幼稚。控制了CID的攻击者可以在没有知道更新程序二进制文件的情况下建立自己的VPN。

更新程序二进制文件本身似乎没有建立VPN连接的任何功能。尽管无法确定是哪一个，但是必须通过外部过程来执行。服务器对HTTP POST请求给出JSON响应。通常，如果请求格式错误或不正确，则不会给出响应。

典型的握手响应

函数handle_handshake_download处理JSON响应。

在握手响应中，可能存在数十个字段。可以从JSON copy_handshake_var_at中提取各个字段，该字段采用字段名称的参数。对该函数的72个引用中至少使用35个不同的字段名称。

多次调用以查找JSON响应中的字段

这表明特斯拉中固件更新机制的巨大复杂性。在测试车辆的同时，很少有这些领域被使用。

这是从函数do_install的握手响应中读取md5哈希的示例。

从响应中读取字段firmware_download_file_md5

然后调用handshake_is_actionable函数。如果正在下载升级，已经在CID上升级，正在中继到IC或正在安装升级，则将阻止握手采取措施。

不进行握手的原因

如果可以进行握手，则调用函数initialize_handshake_install。握手响应存储在文件中以供以后处理，并将命令添加到队列中。

下载

握手响应中可以包含三个不同的字段，以供下载文件：

1、Firmware_download_url –根据shell脚本方法的常规更新

2、Bsdiff40_download_url –使用开源解决方案的二进制差异

3、Rbdlt_download_url –专有的Redbend增量

使用HTTP，它们似乎都以类似的方式下载。这是一个示例网址：

我们注意到了这些URL的几个有趣的特征：

1、响应每个握手请求而生成，并且显然是唯一的。

2、收到握手响应后，有效期始终为两周。

3、出现一个HMAC（哈希消息身份验证代码）以检查其余请求的完整性。

4、可从公共Internet获得从中下载它们的服务器-无需建立VPN连接。

由于到期和HMAC，我们无法猜测或暴力破解其他固件下载链接。

值得注意的是，由于使用公共Internet上的HTTP（未加密）进行下载，因此存在被拦截和篡改的风险。字段firmware_download_file_md5检查下载的完整性。

通过安全的VPN下载哈希值时，将通过公共Internet下载文件。如果攻击者篡改了下载，则MD5哈希可能不再匹配。Wi-Fi或蜂窝连接可用于执行下载。

另一个字段wifi_wait_until将允许在有限的时间内通过Wi-Fi下载。我们认为，这是为了避免通过蜂窝连接进行下载的成本，同时允许它们进行必要的更新。

在固件握手响应中可以看到涉及加密的字段：

通过开放Internet下载固件的加密密钥

Salsa20（一种轻量级算法）可用于加密下载的更新文件。函数decrypt_and_save_file实现解密。

握手响应通过VPN发送整个256位密钥，因此应保持安全，以防止通过Internet进行的固件下载被拦截。

我们看到的所有下载文件都已加密。应该可以发送未加密的文件，但是我们没有看到任何证据。

安装

可以更新系统的许多不同方面：

/usr partitionKernelbootloader

/ usr分区更新涉及更新程序二进制文件中的大部分功能。为此，系统分为在线和离线usr分区。尽管它们被称为usr，而不是已挂载的文件系统，但它们在每一点都被视为原始存储设备（例如/ dev / mmcblock0p1）。

“ usr”是指存储设备的只读方面。一般而言，似乎大多数固件更新都应用于脱机分区。然后，可以将脱机分区中所做的更改复制回联机分区，或直接从脱机分区运行。为了从脱机分区执行更改，会发生以下情况：

1、对脱机分区进行的更改（使用patch，bsdiff或Redbend）

2、检查联机和脱机分区的签名，以确保正确应用了补丁程序。

3、脱机分区安装为/ newusr;然后可以执行/ newusr / deploy /的内容

发生以下情况，将更改从离线复制到在线：

1、对离线分区进行了更改（使用patch，bsdiff或Redbend）

2、检查联机和脱机分区的签名，以确保正确应用了补丁程序。

3、然后更新，然后“重新部署”固件，这涉及将引导加载程序，内核和usr分区复制到在线分区。

将更改应用于脱机分区意味着系统可以在固件更新时继续运行。这似乎与恢复分区的概念背道而驰–首先将它们覆盖。由于使用了多个校验和签名，因此汽车很难变砖了。

从传递的参数可以看出，更新程序二进制文件通过对上述示例更新程序进行系统调用来对内核和引导加载程序进行更新。

选择cid / ic / sm-udpate_sample

调用* -update_sample

相关问答

手机显示加密失败怎么办?

原因:是NAND坏掉造成的。系统挂载data分区的时候发现无法挂载,所以以为是加密未成功。避免它,就得把系统和data装在sd卡上。解决办法:可以尝试进入工程模式...

手机rom存储空间怎么 分区 ?-ZOL问答

以4G的TF卡做比方,将4G的卡分成3个分区,FAT32作为正常存储音乐,图片的普通存储范围,SWAP分区是作为系统缓存,越大对系统运行缓慢的影响愈好,但一般不会超过96M...

如何让U-boot实现 Nand /Nor双启动?

这时候,Uboot通过另外的代码,实际是Nandsubsystem部分,把kernel从Nand读到内存上,再通过指令,然后CPU跳到Kernel入口地址执行。一旦Kernel跑起来,Kerne...

固态硬盘文件系统类型有哪几种?

1、磁盘的文件系统是操作系统用于明确存储设备(常见的是磁盘,也有基于NANDFlash的固态硬盘)或分区上的文件的方法和数据结构;即在存储设备上组织文件的方法。...

手机自身存储空间如何 分区 ?-ZOL问答

APP2SD的工作原理:以4G的TF卡做比方,将4G的卡分成3个分区,FAT32作为你正常存储音乐,图片的普通存储范围,SWAP分区是作为系统缓存,越大对系统运行缓慢的影响愈好...

固态硬盘的新电脑，是 分区 好还是不 分区 好?

固态硬盘到底要分区吗?大部分人的一致观点都是固态不需要分区,因为固态硬盘种种的工作原理,分两个以上分区只会导致性能损失。但是如果不分区,系统该怎么维护...

SSD固态硬盘需要进行碎片整理吗?为什么?

可能很多人已经遗忘了windows自带的磁盘碎片管理程序。这个程序已经在windows中存在了很多年,笔者刚开始接触电脑时用的win98上就自带这个工具。那时玩电脑还是...

机械硬盘 分区 需要设置对齐 分区 至此扇区数的整倍数吗-ZOL问答

机械硬盘不需要,因为他是纯物理写入而固态硬盘需要,是用nand模拟硬盘数据会有...为什么硬盘必须进行分区?分区的好处有哪些?1.5万浏览29回答9000元电脑硬...

OP 分区 预留对SSD性能到底是否有影响-ZOL问答

而NAND颗粒容量单位为1024进制,两者正好相差约7.37%。这部分空间被默认用于作...第三层OP是用户在日常使用中可以分配的,一般用户也可以自己在初次分区的时候...

手机内存卡变只读了怎么办?

可尝试以下方法解决:1、用读卡器插到电脑上,修复磁盘,或重新格式化。2、在windows的磁盘管理器中,删掉内存卡的分区,重建。3、用专用工具Panasonic_SDFor...