UFS深入浅出 第二章 UFS结构 第三节 UFS分区

Section 3 UFS partition

第三节 UFS分区

UFS partition concept is similar to that in eMMC. However, it is not exactly the same. In eMMC, the whole user area could be used immediately after initialization. If there are some dedicated purposes to store specific data, some area called General Purpose Partition (aka GPP) could be separated from user space with its own address memory space assigned. GPP number is up to 4 per eMMC specification. Besides that, there are two boots partition and one RPMB partition in eMMC when shipped out from factory. Either GPP, or Boot/RPMB need dedicated Switch Command CMD6 for accessing to their own independent memory space areas.

UFS分区的概念和eMMC相似。但是，又不完全一样。eMMC里面的整个用户区域可以在初始化之后立即使用。如果有特定的目的去存储一些专门的数据，那么可以从用户区域里面的分出一些分配了自己独立寻址空间的区域，称为通用目的区（也叫GPP）。根据eMMC的规范，GPP的数目最多是4个。除此之外出厂的时候在eMMC里还有两个boot分区以及一个RPMB分区。eMMC里不论是GPP，或者是Boot、RPMB，都需要特定的切换指令CMD6来访问它们自己的独立的寻址空间。

UFS partitions do not work that way. In UFS, partitions have a unique name Logical Unit (aka LU). Except one RPMB logical unit, no other Logical Units are assigned by default in UFS from factory，including boot partition. UFS memory space could not be accessed unless it has been separated into pieces with independent memory space and index assigned. Each piece is so called one Logical Unit, short as LU. The process of memory space allocation for each LU is called provisioning.

UFS的分区工作方式不太一样。在UFS里，分区有一个独特的名字逻辑单元（也叫LU）。除了一个RPMB之外，在UFS里包括boot分区在内，没有其他逻辑分区在出厂的时候就默认分配好的。UFS的存储空间在分成带有独立寻址空间和序列号的小块之前，是不能被访问的。每一个小块也就是一个逻辑单元，简写成LU。分配存储空间给每个LU的过程叫做配置（provisioning）。

The job that provisioning does is actually to create a scattered mapping table of memory space LBA for all LU. There are two types of provisioning defined by UFS specification, Full Provisioning and Thin Provisioning. Full Provisioning gives a 1:1 mapping for all physical memory with its corresponding LBA to LU. While Thin provisioning only assigned all LBAs to LUs. Compared to Full Provisioning, Thin provisioning is more flexible to use physical Flash memory so to reducing NAND overhead blocks and save cost. This is also the reason UFS command UNMAP, which is to delete Logical to Physical Address entry to free the dirty data blocks, is only supported in Thin Provisioning as Full Provisioning need to keep those dirty data blocks unless extra physical Flash blocks that are out of UFS exported capacity are provided to replace them. Nowadays, all UFS vendors has no doubt to choose Thin provisioning.

Provisioning的工作实际上是为所有的LU建立一个分散的存储空间LBA的映射表。UFS规范定义了两种Provisioning模式，完全的Full Provisioning以及廋Thin Provisioning。Full Provisioning给出了所有物理存储以及对应的LBA相对于LU的1:1对应关系。而Thin Provisioning只需要分配所有的LBA个LU。和Full Provisioning相比较，Thin Provisioning可以更加灵活的使用物理闪存，从而减少额外的NAND存储块以及减少成本。这也是为什么UFS的UNMAP命令只支持Thin Provisioning方式，UNMAP命令是通过删除逻辑物理地址映射入口来释放脏数据块。因为Full Provision除非有输出容量之外的额外的物理闪存块来替换那些脏数据块，否则就得一直留着它们。今日，所有的UFS厂商都毫无意外的选择Thin Provisioning。

The index assigned is the number of the LU. Hence Logical Unit Number (aka LUN) is used in UFS protocol to address the specific LU. Generally, there are up to 32 LU in UFS, however the real number could be much less than that based on the real storage usage design.

分配给LU的索引是数字号码，所以逻辑单元号（也叫LUN）就被用在UFS协议里面作为定位特定的LU。一般来说，UFS最多有32个LU，然而实际的数目根据实际存储使用的设计可能远小于这个数字。

UFS also inherit the concept of Well-Known Logical Unit (aka W-LU) from SCSI. There are total 4 W-LU in UFS, Device and Report LUN are two W-LU which have the same definition as that in SCSI, while Boot and RPMB are two W-LU which are newly added to implement and comply with eMMC feature. Each W-LU get its fixed number called Well-known Logical Unit Number (aka W-LUN). The fixed number is the reason that these 4 W-LU are well known. Here we only need to remember that 0xB0 is for Boot and 0xC4 is for RPMB.

UFS还集成了源自于SCSI的概念，众所周知的逻辑单元（也叫 W-LU）。UFS里一共有4个W-LU，Device和Report LUN是和SCSI定义一样的概念的W-LU。而Boot和RPMB是新加入的为了实现以及于eMMC特性保持一致的W-LU。每一个W-LU有固定的众所周知的逻辑单元码, 也就是众所周知的逻辑单元码（也叫W-LUN）。这些固定的数字码也是为什么这四个W-LU众所周知的原因。这里我们只需要记住Boot是0xB0以及RPMB是0xC4。

Boot W-LU density is part of the exported capacity of UFS, and size could be assigned up to 64MB each. This is not like eMMC. In eMMC, two boot partitions density is not counted in the exported capacity and usually is fixed for each, like 4MB. This feature gives UFS more flexibility to fit increasing demand of OS boot size requirement. Another notice for Boot W-LUs is, although it has fixed W-LUN 0xB4, it cannot be accessed until it is linked to a certain LU during the provisioning process by setting the UFS register Descriptor. RPMB W-LU is originated and does not have this limitation, W-LUN is 0xC4, which could be accessed directly. The detail will be covered in the UFS register chapter.

Boot W-LU的容量是包含在UFS的输出容量里的，大小可最大分配到64MB。这个和eMMC不一样，在eMMC里，两个Boot分区的容量是不算在输出容量里的，而且大小通常是固定的，比如说4MB。这个特性也给了UFS更多的灵活性来适应操作系统对于Boot分区尺寸逐渐增加的需求。另外一个Boot W-LU需要注意的点是，虽然它有固定的W-LUN 0xB0，但是在通过UFS寄存器设置做Provisioning把它链接到某个LU之前，它是不能访问的。 RPMB W-LU是原生的，没有这个限制，W-LUN是0xC4，直接就可以访问。具体的细节我们会在UFS寄存器的章节里讲。

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

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

相关问答

苹果4s刷机卡在，正在 nand分区 了，怎么办?手机上的进度条一直是0?

苹果4s刷机卡在正在nand分区,其原因是在刷机过程中造成了参数错误。1、首先将iPhone手机关机。2、同时按住HOME键和关机键。3、持续上一步骤10秒钟左右便可...

本本只有一个512G固体硬盘，分不 分区 好呢?-ZOL问答

SSD的分区是映射式的,与HDD的分区概念完全不同。虽然给SSD分区并不会造成SSD颗粒磨损失衡,但其实给SSD分区也并没有什么意义,只是固化了空间分配,降低了一点空...

SSD固态硬盘分多个 分区 是否影响性能-ZOL问答

分区多对性能影响不大!我实测过,可以忽视!固态硬盘建议三星的950pro来使用一下,大品牌的存储产品靠谱一点,而且算业内无论是读取速度还是开机速度都非常快...

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

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

windows xp中常用的两种文件系统?

不支持exFAT文件系统是比较可惜的。文件系统是操作系统用于明确存储设备(常见的是磁盘,也有基于NANDFlash的固态硬盘)或分区上的文件的方法和数据结构;即在...

电脑存储空间为什么采用ram,而不采用rom-ZOL问答

1、ROM是只读存储器的简称。主要的作用是存储,而不是运行程序。关机断电...如果SD卡没做过EXT分区,选择Nand备份即可,如果做过EXT分区,且分区里安装了程序...

odin三星刷机工具?

2、【Bootloader】系统引导区,如果刷机包内包含该文件夹一般是在系统版本升级,或者水货刷行货的时候遇到。【PDA】系统主程序,包含了system分区,系统就...【P...

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

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

如何查看linux根 分区 下全部目录及文件的大小-ZOL问答

将文件系统通过tftp下载到开发板板,并写入到nandFlashtftpboot30000000fsroot.yaffs2nanderaserootnandwrite.yaffs0...

k3路由器怎么看是不是三星闪存?

2.通过SSH或Telnet等方式登录到路由器的操作系统。3.在命令行界面中执行命令“cat/proc/mounts”来查看系统挂载的分区和设备信息。4.在输出中寻找有关...