There is a sticker on the bottom with some technical information about the unit. The sticker notes the specific CMU model being MAZDA_GEN_65_CMU.
底部有一个贴纸，上面有一些关于该装置的技术信息。贴纸上注明了正在MAZDA_GEN_65_CMU的特定 CMU 型号。

On the back, the unit provides multiple connectors that carry power, audio input/output, USB and CAN signals, and a serial console.
在背面，该装置提供多个连接器，用于传输电源、音频输入/输出、USB 和 CAN 信号以及串行控制台。

Inside, the unit is built on a single PCB which carries an application SoC (Freescale part number SCIMX06DAVT10AC), an assortment of memory ICs (a serial Flash on the back of the board, a NAND Flash, and an eMMC), an auxiliary MCU (Renesas part number R5F35MCEJFF), and a Bluetooth module (Murata part number LBEE6Z2U0C-584).
在内部，该单元构建在单个 PCB 上，该 PCB 带有一个应用 SoC（飞思卡尔零件编号 SCIMX06DAVT10AC）、各种存储器 IC（电路板背面的串行闪存、NAND 闪存和 eMMC）、一个辅助 MCU（瑞萨电子零件编号 R5F35MCEJFF）和一个蓝牙模块（村田零件编号 LBEE6Z2U0C-584）。

While there is a login prompt, authentication credentials for the latest software version are not publicly known. The console proceeds to serve a vast amount of logging output, which could be useful for testing exploits.
虽然存在登录提示，但最新软件版本的身份验证凭证并不公开。控制台继续提供大量的日志记录输出，这可能对测试漏洞很有用。

When fully booted, the system has the following file systems mounted:
完全引导后，系统挂载了以下文件系统：

All the persistent memory storage is accessible from the OS. The serial Flash is present as the mtdblockpartitions, the NAND is present as the ffx01 partitions, and the eMMC as the mmcblk partitions. Notably, several file systems are mounted read-write as signified by the rw string included in parentheses.
所有持久内存存储都可以从操作系统访问。串行闪存作为 mtdblock分区存在，NAND 作为 ffx01 分区存在，eMMC 作为 mmcblk 分区存在。值得注意的是，多个文件系统是读写挂载的，如括号中的 rw 字符串所示。

The Software Update Process
软件更新过程

The software on the unit can be updated from the diagnostic menu:
可以从诊断菜单更新设备上的软件：

The update process expects a file with the .up extension to be located on a mass storage device connected via USB. The dealer could then enter this diagnostic menu and start the update process.
更新过程需要扩展名为 .up 的文件位于通过 USB 连接的大容量存储设备上。然后，经销商可以进入此诊断菜单并开始更新过程。

Software update files are password-protected ZIP archives containing multiple directories for various steps in the update process, as well as an “instruction” file describing how to perform the update. There are 21 steps in the latest update file. Of special interest is the contents of the following directories:
软件更新文件是受密码保护的 ZIP 存档文件，其中包含用于更新过程中各个步骤的多个目录，以及描述如何执行更新的“说明”文件。最新更新文件包含 21 个步骤。特别值得关注的是以下目录的内容：

• rootfs1upd containing a .tar.gz archive of the entire root file system,
• rootfs1upd 包含整个根文件系统的 .tar.gz 存档，
• linux1 containing the Linux kernel 3.0.35,
• linux1 包含 Linux 内核 3.0.35，
• ibc1 and ibc2 containing a bootloader,
• 包含引导加载程序的 ibc1 和 ibc2，
• bootstrap containing yet another bootloader,
• 包含另一个引导加载程序的 bootstrap，
• passwdupdate containing the replacement passwd file,
• passwdupdate 包含替换 passwd 文件，
• vip containing the update image for the auxiliary MCU.
• vip 包含辅助 MCU 的更新映像。

The majority of the update process is implemented in several shared objects. All business logic is located in svcjciupdatea.so and svcjciupdates.so, which use supporting code in libjcireflashua.so and libjcisecurity.so. The update process was investigated only up to the point of signature verification. Further investigation would assume the ability to produce either properly signed updates or a signature verification bypass. Unfortunately, the former was not available at the time of this research, and the latter was not discovered during this effort.
大部分更新过程都是在多个共享目标文件中实现的。所有业务逻辑都位于 svcjciupdatea.so 和 svcjciupdates.so 中，它们使用 libjcireflashua.so 和 libjcisecurity.so 中的支持代码。更新过程仅在签名验证之前进行调查。进一步的调查将假设能够生成正确签名的更新或绕过签名验证。不幸的是，前者在这项研究时不可用，后者在这项研究中也没有被发现。

On a high level, the update verification process is contained in the svcjciupdates.so:updates_sys_srv_ValidatePackageOperationThread() function, which calls other functions to perform verification steps in the given order:
概括地说，更新验证过程包含在 svcjciupdates.so:updates_sys_srv_ValidatePackageOperationThread() 函数中，该函数调用其他函数以按给定顺序执行验证步骤：

• updates_sys_srv_LoadUP() parses the specified update file, extracts the main_instructions.ini and versions.ini files, and stores them in memory for later use.
• updates_sys_srv_LoadUP（） 解析指定的更新文件，提取 main_instructions.ini 和 versions.ini 文件，并将其存储在内存中以供以后使用。
• updates_sys_srv_ValidateUPStructure() validates whether the internal structure of the update file matches the expected layout. This was not an issue when the format of proper update files was followed to create an exploit.
• updates_sys_srv_ValidateUPStructure() 验证更新文件的内部结构是否与预期布局匹配。当遵循正确的更新文件格式来创建漏洞时，这不是问题。
• updates_sys_srv_ExtractCertificates() extracts the signing certificate chain from the update file to be used for update verification. The chain contains the publisher certificate used to sign the update and an intermediate CA certificate that issued the publisher certificate. The intermediate CA certificate is issued by the JCI root CA.
• updates_sys_srv_ExtractCertificates() 从更新文件中提取签名证书链以用于更新验证。该链包含用于对更新进行签名的发布者证书和颁发发布者证书的中间 CA 证书。中间 CA 证书由 JCI 根 CA 颁发。
• updates_sys_sec_VerifyUPCertificates() verifies the extracted certificate chain to ensure the chain properly terminates in the expected root CA stored on the device.
• updates_sys_sec_VerifyUPCertificates() 验证提取的证书链，以确保该链正确终止于设备上存储的预期根 CA。
• updates_sys_sec_VerifyUPSignature() verifies the signature of a specified update file against the publisher certificate. The signature in this case is located at the end of the update file and is 256 bytes long.
• updates_sys_sec_VerifyUPSignature() 根据发布者证书验证指定更新文件的签名。在本例中，签名位于更新文件的末尾，长度为 256 字节。
• updates_sys_srv_RemoveExtractedCertificates() cleans up after the verification process.
• updates_sys_srv_RemoveExtractedCertificates() 验证过程后进行清理。

Of particular note is the fact that multiple operations are performed on the supplied update file by the updates_sys_srv_LoadUP() function and its callees before any integrity checks occur against the user-supplied file.
特别值得注意的是，在对用户提供的文件进行任何完整性检查之前，updates_sys_srv_LoadUP（） 函数及其被调用方会对提供的更新文件执行多个操作。

The specific vulnerability exists in the eInsertDeviceEntry() function of the /jci/devicemanager/libdevicemanager.so library. When attempting to insert a new Apple device into the DeviceDatabase.db SQLite database, several values are taken from the device and used in an SQL statement without sanitization. See the following pseudocode implementation of the eInsertDeviceEntry() function:
具体漏洞存在于 /jci/devicemanager/libdevicemanager.so 该库的 eInsertDeviceEntry（） 函数中。尝试将新的 Apple 设备插入 DeviceDatabase.db SQLite 数据库时，将从设备中获取多个值并在 SQL 语句中使用，而无需进行清理。请参阅以下 eInsertDeviceEntry（） 函数的伪代码实现：

Because of this, when the infotainment system detects an Apple device has been connected and requests, for example, its iAP serial number, a spoofed iPod or other Apple device can instead reply with a string along the lines of:
因此，当信息娱乐系统检测到已连接 Apple 设备并请求（例如）其 iAP 序列号时，欺骗性的 iPod 或其他 Apple 设备可以改为使用以下字符串进行回复：

One of the multitude of functions supporting the update process is the REFLASH_DDU_FindFile() function found in the libjcireflashua.so shared object. The pseudocode for this function is reproduced below for clarity:
支持更新过程的众多函数之一是 libjcireflashua.so 共享目标文件中的 REFLASH_DDU_FindFile（） 函数。为清楚起见，此函数的伪代码复制如下：

The function attempts to find a specific file within the update package specified via the provided file path. This is performed by interpolating the provided path into a command line for the unzip program. Unfortunately, no sanitization is performed before that occurs, and attacker-controlled input (e.g., /dev/sda1/path/file.up) is passed to the system() function. This allows the attacker to inject arbitrary OS commands that will be executed by the head unit OS shell, allowing for a full compromise of the system. The attacker can control both the path and file elements of the overall path.
该函数尝试在通过提供的文件路径指定的更新包中查找特定文件。这是通过将提供的路径插入到 unzip 程序的命令行中来执行的。遗憾的是，在此之前没有执行清理，攻击者控制的输入（例如，/dev/sda1/path/file.up）被传递给 system（） 函数。这允许攻击者注入任意 OS 命令，这些命令将由主机 OS shell 执行，从而允许完全破坏系统。攻击者可以控制整个路径的 path 和 file 元素。

The affected function can be reached via the following call graph:
可以通过以下调用图访问受影响的函数：

• UPDATES_SYS_IPC_INTERFACE_GetPackageInfo_svc in svcjciupdates.so
• svcjciupdates.so UPDATES_SYS_IPC_INTERFACE_GetPackageInfo_svc
• UPDATES_SYS_SRV_GetPackageInfo
• UPDATES_SYS_SRV_GetPackageInfo
• updates_sys_srv_GetPackageInfoOperationThread
• updates_sys_srv_GetPackageInfoOperationThread
• updates_sys_srv_LoadUP • updates_sys_srv_LoadUP
• REFLASH_UA_LoadUP in libjcireflashua.so
• libjcireflashua.so REFLASH_UA_LoadUP
• REFLASH_DDU_FindFile  • REFLASH_DDU_FindFile

One of the multitude of functions supporting the update process is the REFLASH_DDU_ExtractFile() function found in the libjcireflashua.so shared object. The pseudocode for this function is reproduced below for clarity:
支持更新过程的众多函数之一是 libjcireflashua.so 共享目标文件中的 REFLASH_DDU_ExtractFile（） 函数。为清楚起见，此函数的伪代码复制如下：

The function attempts to extract a specific file from the update package specified by the path supplied through the up_path argument. This interpolates the provided path into a command line for the unzip program. Unfortunately, no sanitization is performed before that occurs, and attacker-controlled input (e.g., /dev/sda1/path/file.up) is passed to the system() function. The attacker can control both path and file elements of the overall path. This allows the attacker to inject arbitrary OS commands that will be executed by the head unit OS shell, allowing for a full compromise of the system.
该函数尝试从更新包中提取特定文件，该更新包由通过 up_path 参数提供的路径指定。这会将提供的路径插入到 unzip 程序的命令行中。遗憾的是，在此之前没有执行清理，攻击者控制的输入（例如，/dev/sda1/path/file.up）被传递给 system（） 函数。攻击者可以控制整个路径的 path 和 file 元素。这允许攻击者注入任意 OS 命令，这些命令将由主机 OS shell 执行，从而允许完全破坏系统。

The affected function can be reached via the following call graph:
可以通过以下调用图访问受影响的函数：

• UPDATES_SYS_IPC_INTERFACE_GetPackageInfo_svc in svcjciupdates.so
• svcjciupdates.so UPDATES_SYS_IPC_INTERFACE_GetPackageInfo_svc
• UPDATES_SYS_SRV_GetPackageInfo
• UPDATES_SYS_SRV_GetPackageInfo
• updates_sys_srv_GetPackageInfoOperationThread
• updates_sys_srv_GetPackageInfoOperationThread
• updates_sys_srv_LoadUP • updates_sys_srv_LoadUP
• REFLASH_UA_LoadUP in libjcireflashua.so
• libjcireflashua.so REFLASH_UA_LoadUP
• REFLASH_DDU_ExtractFile
• REFLASH_DDU_ExtractFile

One of the various functions supporting the update process is the UPDATES_ExtractFile() function found in the svcjciupdates.so shared object. The pseudocode for this function is partially reproduced below for clarity:
支持更新过程的各种函数之一是 svcjciupdates.so 共享目标文件中的 UPDATES_ExtractFile（） 函数。为清楚起见，此函数的伪代码部分复制如下：

The function attempts to extract a specific file from the update package specified by the path supplied through the up_path argument. This interpolates the provided path into a command line for the unzip program. As with the other bugs, no sanitization is performed before that occurs, and attacker-controlled input (e.g., /dev/sda1/path/file.up) is passed to the system() function. The attacker can control both path and file elements of the overall path. This allows the attacker to inject arbitrary OS commands that will be executed by the head unit OS shell, allowing for a full compromise of the system.
该函数尝试从更新包中提取特定文件，该更新包由通过 up_path 参数提供的路径指定。这会将提供的路径插入到 unzip 程序的命令行中。与其他错误一样，在此之前不会执行清理，攻击者控制的输入（例如 /dev/sda1/path/file.up）会传递给 system（） 函数。攻击者可以控制整个路径的 path 和 file 元素。这允许攻击者注入任意 OS 命令，这些命令将由主机 OS shell 执行，从而允许完全破坏系统。

The affected function can be reached via the following call graph:
可以通过以下调用图访问受影响的函数：

• UPDATES_SYS_IPC_INTERFACE_GetPackageInfo_svc in svcjciupdates.so
• svcjciupdates.so UPDATES_SYS_IPC_INTERFACE_GetPackageInfo_svc
• UPDATES_SYS_SRV_GetPackageInfo
• UPDATES_SYS_SRV_GetPackageInfo
• updates_sys_srv_GetPackageInfoOperationThread
• updates_sys_srv_GetPackageInfoOperationThread
• updates_sys_srv_LoadUP • updates_sys_srv_LoadUP
• updates_sys_srv_ExtractCertificates
• updates_sys_srv_ExtractCertificates
• updates_sys_srv_ExtractPubCert
• updates_sys_srv_ExtractPubCert
• UPDATES_ExtractFile(“publisher_cert.pem”, “/tmp/reflash/publisher_cert.pem”)
• UPDATES_ExtractFile（“publisher_cert.pem”， “/tmp/reflash/publisher_cert.pem”）

Here, the mtd0 partition stores the bootstrap code, which appears to be the first piece of code to be executed on the system. The application SoC was found to be missing any authentication of this bootstrap code. Additionally, none of the subsequent OS boot steps perform any authentication of the next boot stage before passing control to it. This results in the following opportunities for an attacker who has gained code execution on the Linux system:
在这里，mtd0 分区存储引导代码，它似乎是在系统上执行的第一段代码。发现应用程序 SoC 缺少此引导代码的任何身份验证。此外，在将控制权传递给下一个引导阶段之前，任何后续 OS 引导步骤都不会对下一个引导阶段执行任何身份验证。这会导致在 Linux 系统上获得代码执行的攻击者获得以下机会：

• Manipulate the root filesystem, changing arbitrary files and e.g. gaining persistence on the system,
• 操作根文件系统，更改任意文件，例如在系统上获得持久性，
• Manipulate configuration data residing in the mtd5 partition, e.g. installing arbitrary SSH keys, and
• 操纵驻留在 mtd5 分区中的配置数据，例如安装任意 SSH 密钥，以及
• Manipulate the bootstrap code, gaining the ability to execute arbitrary code prior to OS boot.
• 操纵引导代码，获得在操作系统启动之前执行任意代码的能力。

The MCU in question is identified as VIP in the strings found in the CMU software. Through the analysis of software update packages, it was discovered the VIP is also updated during the software update process. The tools to do so, as well as the update image, are found in the vip subdirectory of the update package.
有问题的 MCU 在 CMU 软件中的字符串中被标识为 VIP。通过对软件更新包的分析，发现 VIP 也会在软件更新过程中进行更新。执行此操作的工具以及更新映像位于更新包的 vip 子目录中。

The vcm tool allows performing the following operations against the VIP:
vcm 工具允许对 VIP 执行以下操作：

Specifically, the --write-image command allows writing an update image to the VIP. This command is normally used by the update script and takes an input file formatted as Motorola S-records. Of particular interest is also querying the versions of VIP software components. The following is reported on the unit running software cmu150_NA_74.00.324A:
具体来说，--write-image 命令允许将更新映像写入 VIP。此命令通常由更新脚本使用，并采用格式为 Motorola S 记录的输入文件。特别有趣的是查询 VIP 软件组件的版本。在运行软件 cmu150_NA_74.00.324A 的设备上报告以下内容：

These strings can be located in the update file image-vip_appvfbl.mot and are destined to be programmed at memory address 0xC000A in the VIP MCU memory space and appear to be part of the application image spanning addresses 0xC0000 through 0xFFFFF. By modifying these strings, it is possible to determine whether the image is validated before being programmed into the internal memory.
这些字符串可以位于更新文件 image-vip_appvfbl.mot 中，并且注定要在 VIP MCU 内存空间的内存地址0xC000A进行编程，并且似乎是跨地址 0xC0000 到 0xFFFFF 的应用程序映像的一部分。通过修改这些字符串，可以确定图像在编程到内部存储器之前是否经过验证。

The original S-record file was manipulated to change one string to produce a visible indication of different firmware, and the resulting image was programmed back to the VIP MCU:
原始 S 记录文件纵以更改一个字符串以产生不同固件的可见指示，并将生成的图像编程回 VIP MCU：

Using the same command for version check, it is possible to confirm the tampered image was accepted:
使用相同的命令进行版本检查，可以确认被篡改的镜像已被接受：

Exploitation of the OS command injection vulnerabilities is relatively straightforward. All the attacker needs to do is create a file on a FAT32-formatted USB mass storage device where the name will contain the OS commands to be executed. The filename must end with .up for it to be recognized by the software update handling code. While all three command injection vulnerabilities are exploited via the file name, the easiest one to exploit is by far the ZDI-CAN-23420 as there are no specific exploitation requirements such as validity of the crafted update file.
利用 OS 命令注入漏洞相对简单。攻击者需要做的就是在 FAT32 格式的 USB 大容量存储设备上创建一个文件，该文件的名称将包含要执行的操作系统命令。文件名必须以 .up 结尾，以便软件更新处理代码能够识别它。虽然所有三个命令注入漏洞都是通过文件名利用的，但到目前为止最容易利用的是 ZDI-CAN-23420，因为没有特定的利用要求，例如构建的更新文件的有效性。

Exploitation of the described command injection vulnerabilities can be further facilitated by the fact that software update installation can be triggered automatically upon connecting a USB mass storage device; this is a “known feature” which is activated by simply placing an empty file named jci-autoupdate on the storage device.
通过在连接 USB 大容量存储设备时可以自动触发软件更新安装，可以进一步促进对所述命令注入漏洞的利用;这是一个“已知功能”，只需在存储设备上放置一个名为 jci-autoupdate 的空文件即可激活。

Once the initial compromise is achieved, the attacker can gain persistence through manipulation of the root file system, such as installing backdoored system components which will persist across system restarts.
一旦实现最初的入侵，攻击者就可以通过操纵根文件系统来获得持久性，例如安装后门系统组件，这些组件将在系统重启后仍然存在。

Furthermore, the attacker can move laterally and install a specially crafted VIP microcontroller software allowing unfettered access to vehicle networks, potentially impacting vehicle operation and safety. Specific impacts (what could be controlled and how) were not investigated during this research effort.
此外，攻击者可以横向移动并安装特制的 VIP 微控制器软件，从而允许不受限制地访问车辆网络，从而可能影响车辆运行和安全。在这项研究工作中，没有调查具体影响（可以控制什么以及如何控制）。

In the lab environment, the entire attack chain – from plugging in a USB drive to installing a crafted update on the VIP – takes only a few minutes. Currently, there is no reason to believe a similar attack will take significantly more time against a unit installed in a car. This means that the vehicle can be compromised while, for example, it is being handled by a valet, during a ride share, or via USB malware. Naturally, the same can be done in a shop environment where there are no significant time pressures.
在实验室环境中，整个攻击链 – 从插入 USB 驱动器到在 VIP 上安装精心设计的更新 – 只需几分钟。目前，没有理由相信针对安装在汽车中的装置进行类似的攻击会花费更多时间。这意味着车辆可能会受到损害，例如，当它由代客泊车、拼车期间或通过 USB 恶意软件处理时。当然，在没有重大时间压力的车间环境中也可以这样做。

The CMU can then be compromised and “enhanced” to, for example, attempt to compromise any connected device in targeted attacks that can result in DoS, bricking, ransomware, safety compromise, etc.
然后，CMU 可以被入侵和“增强”，例如，尝试在有针对性的攻击中入侵任何连接的设备，从而导致 DoS、变砖、勒索软件、安全危害等。