This article is an excellent piece from the KXue Forum, author ID: kxliping
Purpose of Analyzing Attack Cases
The main purpose of studying attack cases is to understand how attackers breach vehicles and take control of them. In the research on Tesla attacks, Tencent’s Keen Lab has contributed several successful cases, which should ideally be analyzed first.
However, as an IoT security engineer, I am more interested in the complete attempt path of the attacker, as this path contains rich adversarial information, including which protective measures effectively repelled the attacker, which measures were missing or flawed, and what the most effective protective measures are, etc. The reports from Keen Lab provide very little description of this information.
Therefore, this article selects Pentest Partners’ “Reverse Engineering Tesla Hardware” as the opening of the analysis series. On one hand, it attempts to clarify the attack process of Pentest Partners; on the other hand, which is my main goal, it seeks to uncover the actual protective effects of IoT security technologies in real attack scenarios and explore the deeper reasons for protection failures.
Pentest Partners’ complete report consists of two articles: “Reverse Engineering Tesla Hardware” and “Reverse Engineering the Tesla Firmware Update Process.” The former describes the process from disassembly to restoration of the hardware architecture, while the latter describes the process of discovering and exploiting vulnerabilities through reverse engineering FOTA.
This article mainly interprets the first article, which records the disassembly and reverse exploration process of the vehicle-mounted chips in detail, making it a textbook example of board-level reverse engineering. Now, let’s begin the interpretation.
Pentest Partners Hardware Attack Process
2.1 Unprotected Physical Contact One: Directly Obtainable PCB
To facilitate reverse engineering, the researchers first disassembled the vehicle machine:
“We took the CID out of the Tesla to power it up and examine it.”
(All physical images are from the Pentest Partners blog, and this will not be mentioned again)
After disassembly, two main chips can be seen: IC and CID. IC refers to Instrument Cluster; CID refers to Central Information Display, which is the computing chip behind the Tesla entertainment screen.
There is not much description of the confirmation process for IC and CID; it may have been obtained from public information or based on markings on the chip.
(The architecture diagram restored in this step will not be explained later)
2.2 “Self-Reporting” First Shot: Confirming Information of the VCM Responsible for Computing Power
Based on the text and markings on the chip, the researchers confirmed the presence of VCM at both IC and CID:
“An NVidia VCM (Visual Compute Module) sits at the core of the CID. This is an ARM based single-board computer module that runs Linux – the operating system that drives most of the visible actions of the Tesla.
Nvidia VCM modules are used in both the CID and IC.”
“An Nvidia Tegra System-on-Chip (SoC) is used in the VCM. This has a multi-core ARM processor, GPU and various other audio and video accelerators.”
The SOC of VCM is confirmed to be Nvidia Tegra, a multi-core ARM processor that includes GPU and audio, video accelerators. This information comes from the description of Nvidia Tegra documentation, presumably from the internet.
The markings and text on the chip clearly disclose the identity information of the chip, which at least helps to understand the electrical architecture of IC and CID.
We can see that VCM provides the main computing power for IC and CID, with the VCM on the CID primarily providing computational support for images, videos, and audio on the entertainment screen.
2.3 First Setback in “Close Relative” Research: No Key Commonality Among “Distant Relatives”
After confirming the SOC of VCM, the researchers briefly elaborated on the commonality of Tesla VCM with those used in Audi, BMW, and Lamborghini.
“Audi, BMW and Lamborghini have all been associated with Nvidia VCMs. For example, we uncovered a similar module in an Audi Virtual Cockpit.”
Next, the researchers made a simple comparison between the computing power of VCM and other IVIs:
“It is significantly more powerful than SoCs used in other IVIs that we have examined, which is probably due to the large CID display.”
Although no security breakthrough was found in the commonality research and computing power comparison of VCM, do not underestimate this kind of analysis. During reverse analysis, comparative studies of similar or closely related objects can often reveal key information. Having not obtained key information in board-level comparative studies, the researchers further tried to find “close relatives” at the chip level.
2.4 Second Setback in “Close Relative” Research: The Role of NDA Agreements
The researchers further attempted to find information about chip pins and wiring through similar SOCs used in development, but found that they all required signing an NDA with the supplier to obtain.
“You can obtain technical reference manuals for the Tegra 2, 3 and 4 SoC lines, but they don’t contain ball-maps or pin-outs, so are of limited use for reverse engineering.
To gain access to documentation and forums, a valid developer account was created for Nvidia.com, but we could only find one reference for VCMs or the Jetson Pro development kit.
We wrote a forum post asking about documentation but got no response. We envisage that an NDA would have to be signed to gain access to anything significant but it is unlikely that we would be able to share any of the information with third parties.”
2.5 “Self-Reporting” Second Shot: Confirming Information of VCM Submodules
Next, the researchers compiled the information of submodules mounted on VCM at IC and CID, including NOR Flash memory, eMMC memory, Ethernet controllers, USB transceivers, SDRAM memory, power management modules, etc.
Among them, the configurations of VCM on IC and CID are not exactly the same:
1) The Tegra 2 used on IC is one version lower than the Tegra 3 on CID;
2) The eMMC capacity on IC is 4GB, which is half that of CID;
3) The 1GB RAM on IC is half that of CID.
These differences indicate that the business load carried by CID VCM is higher than that of IC VCM, meaning that CID VCM is the main computing unit for the entire vehicle machine. Additionally, both VCMs are equipped with Ethernet transceivers.
2.6 First Victory in Cost Warfare: Preventing Direct Analysis of VCM
After organizing the submodules on VCM, the researchers’ next plan was to conduct invasive analysis on VCM. Although the researchers had already confirmed the power pins using an oscilloscope, the repair cost of £3,000 to £10,000 made them abandon the direct analysis of VCM.
“We believe that the pin-outs of the two VCMs were the same – voltage supply and ground appeared to be on the same pins, which was confirmed with an oscilloscope. We did not want to direct test the VCMs from the Tesla due to risk of damaging or bricking the CID or IC. This could make the car unusable, and cost somewhere between £3,000 and £10,000 to have repaired by Tesla.”
2.7 A Small Step Forward in “Close Relative” Research: VCM Firmware Extracted, Lifecycle Issue of Components
After several failed attempts to find closely related chip models, the researchers managed to obtain a second-hand VCM, which was basically identical in submodules to the VCM in the IC, except for RAM capacity.
“We obtained a third VCM from a second-hand IC. This was the same as the VCM in the IC from the test, except it had 50% less RAM. The IC itself was a different model. We conducted invasive testing”
The researchers extracted the first and second stage bootloader, kernel, and boot-related data from the NOR Flash of this second-hand TCM. Other filesystem-related data was found in NAND Flash, with most files stored in a compressed read-only filesystem (squashfs) and a small portion in a read/write filesystem (ext4).
2.8 “Self-Reporting” Second Shot: Confirming SWITCH Information
Through the text and marking information on the Switch chip, the researchers easily confirmed that the Switch is Marvell 88E6061, which supports VLAN:
“A built-in Ethernet switch connects the VCM to the rest of the vehicle via a Marvell 88E6061. This five-port 10/100 switch supports VLANs. It is configured using SMI, a serial interface. The Ethernet switch is configured when the CID starts.”
2.9 First Breach in Communication Protocol: SMI Can Be Sniffed and Tampered
SMI communication lacks effective security measures, allowing researchers to sniff SMI commands and tamper with SMI instructions. Although VLANs segregate the broadcast domain, the lack of integrity protection for SMI commands means that VLAN configurations can be modified by tampering with commands.
“A logic analyser could sniff the SMI commands. We could not ascertain whether they were sent by the VCM or the gateway processor. Traffic is segregated from the various components using several VLANs.
There is no security functionality associated with the SMI, for example integrity protection – it trusts all signals, meaning that communications can be tampered with or modified. VLAN configuration could be modified in this way, potentially creating new routes into the system.”
2.10 “Self-Reporting” Third Shot: Confirming Gateway Information
Through the text and marking information on the gateway chip, the researchers easily confirmed the model of the gateway chip:
“Here we show the gateway with CAN transceivers. Similar devices are often found in CAN gateways. The gateway is connected to the CAN buses and the Ethernet switch. We believe the firmware on the gateway is FreeRTOS, a lightweight real-time operating system (RTOS) with multiple automotive uses.”
2.11 “Self-Reporting” Fourth Shot: Confirming Modem Information
Similarly, through the text and marking information on the Modem chip, the researchers easily confirmed the model of the Modem.
2.12 Victory in Software Architecture: eCALL Not Found
The researchers attempted to find eCALL and SMS-related applications in the CID but found no trace, suggesting that the relevant application functions are implemented in the Modem. Since the Modem does not expose attack interfaces, no further analysis was conducted on the Modem.
“Most TCUs in vehicles do not allow user-accessible and swappable SIM. Embedded or inaccessible SIMs are becoming the norm. Despite further examination of the Tesla, we did not uncover any functionality for tracking or eCall running on the CID’s VCM. This suggests these safety and security features run directly on the cellular modem, as per TCUs in other vehicles.”
Reflecting on the attacker’s mindset, we should try to avoid complex architectures in our forward designs. A good design is to encapsulate modules of the same function within the same chip and minimize the attack surface of the chip. In actual design, functions like eCALL are often placed in IVI (similar to the CID here), which significantly increases the possibility of eCALL and Modem being attacked.
2.13 First Victory in Chip Packaging: BGA Prevents Invasive Analysis of Modem
Due to the BGA packaging of the Modem chip, which is characterized by high difficulty in disassembly and reattachment, the researchers abandoned attempts to restore firmware from the Modem chip.
“Recovering firmware from a Sierra Wireless AR8522 module without causing damage is extremely difficult, being as it is a tightly packed BGA module with numerous BGA chips, all contained under a soldered-on shield.”
2.14 Second Victory in Chip Packaging: Face-Down Wi-Fi and Bluetooth Modules
Due to the face-down packaging of the Wi-Fi and Bluetooth module chips, which effectively hides the text information on the chips, attackers cannot directly obtain the chip model. Additionally, the chips use BGA packaging (which can be inferred from the context), making disassembly extremely difficult, thus effectively preventing further attacks by the researchers.
“The CID employs a Parrot Wi-Fi and Bluetooth module, mounted face-down. We could not confirm the specific model because it could not be removed from the main board.”
2.15 Unprotected Physical Contact Two: Directly Usable SD Card
The SD card lacks an integrity verification mechanism, storing the firmware used during the upgrade, and according to the article description, the SD card’s stored content should be stored in plaintext, meaning attackers can easily extract data from the SD card and write data to it. During the second stage of the attack, the attackers effectively exploited the unprotected SD card.
“On top of the CID main board are two socketed SD cards. The CID has to be taken apart to access a 4GB normal SD card. It is connected to the gateway and used for staging files during the firmware update.”
2.16 First Victory in Communication Protocol: Signature Verification Command Prevents VCM from Entering Recovery Mode
The CID contains a USB interface that connects to the VCM to enable the VCM to enter recovery mode, but the command has a signature verification, so the attackers were unable to successfully enter recovery mode.
“There is a single USB port on the CID main board connected to the VCM. Previous investigation (https://blog.lookout.com/hacking-a-tesla) discovered this could be used to gain access to a Tegra recovery mode (RCM). This had not changed; it cannot be disabled. This was still protected by security meaning that commands have to be signed before they are accepted.”
2.17 Second Victory in Cost Warfare: Preventing Exploitation of USB Vulnerability
Due to concerns that exploiting USB vulnerabilities could cause hardware damage, the researchers abandoned the exploitation of the public USB vulnerabilities; the high cost of hardware again prevented the attackers.
“The Fusée Gelée vulnerability was found in the RCM bootloader in 2018. Malicious USB packets could bypass security as a result. We confirmed with the researchers who discovered this vulnerability that it is likely to be present on the earlier Tegra SoCs used by VCMs in the Tesla. We decided not to try and exploit this vulnerability due to the risk of rendering the VCM inoperable.”
2.18 Second Victory in Communication Protocol: Handshake Protocol and VPN Prevent Attacks on Vehicle Cloud Communication
The CID communicates with the server via Ethernet, with the network running on a VPN connection, and there is a secure handshake protocol, leaving no points that can be directly exploited.
“On the CID, two Ethernet ports are exposed, using proprietary automotive connectors. Previously fully open, one is a dedicated diagnostic connector. This is now secured via a proprietary handshake and has no known vulnerabilities. A “seed” is sent from Tesla servers to and from the CID via VPN connection.”
2.19 Second Breach in Communication Protocol: Unprotected Diagnostic Interface
The OBD port has no isolation or access control, allowing arbitrary CAN commands to be sent.
“No sign of segregation or access control was observed – if someone had access to this port they could sniff and send arbitrary CAN traffic.”
2.20 Third Victory in Chip Packaging: BGA Prevents JTAG Analysis of Multiple Chips
The BGA packaging method prevented the researchers from attempting to analyze multiple chip JTAG pins.
“The only package with accessible pins and JTAG is the Analog Device ADSP-21489 – the rest are BGA.”
2.21 Third Victory in Cost Warfare: Hardware Costs Repelled JTAG Interface Analysis
The researchers roughly inferred the soldering positions of the JTAG interface from the PCB layout:
“It looks like they may be JTAG connections because these are all near microcontrollers or memory devices.”
They also proposed two feasible cracking ideas, but due to the risk of damaging the hardware, the researchers abandoned further cracking attempts.
“Several methods are available to determine the pin-out:
1. Brute-force JTAG testing (“JTAGulating”) – can produce false positives and damage the board.
2. Continuity tests to known JTAG pins on one of the devices are reliable if pins can be accessed and datasheets are available.”
2.22 Weakness of the Security Barrel: The Only Non-BGA Packaged Chip
The audio processor’s packaging method did not adopt BGA, exposing the chip pins.
“The only package with accessible pins and JTAG is the Analog Device ADSP-21489 – the rest are BGA.”
I believe that Tesla’s security engineers must have made requirements regarding the packaging method of the audio processor, as only one chip did not adopt the BGA packaging method. The supplier of this component may have simply wanted to continue using the old scheme without making any modifications to the existing hardware, including merely changing the chip’s packaging method, as changes imply additional costs.
This issue is quite common in the automotive field, where many suppliers provide components in a platform-oriented manner and refuse to make any customized services, especially prominent among foreign suppliers.
On a larger scale, this is also an important reason why traditional automakers are slow to transform, as the supply chain of a vehicle model is vast and complex. Even if automakers seek change, the supply chain will not immediately respond to your changes. Moreover, the R&D teams of traditional vehicle models are very familiar with old solutions, and continuing to use old solutions is their only choice. The conservative factions present in both the supply chain and the automaker are a significant obstacle to the transformation of traditional vehicle models.
2.23 “Self-Reporting” Fifth Shot: Confirming Audio Processor Information
Based on the markings and text on the audio processor, the researchers confirmed that the model of the processor is ADSP-21489.
“The only package with accessible pins and JTAG is the Analog Device ADSP-21489 – the rest are BGA.”
2.24 A Small Step Forward in “Close Relative” Research: Researchers Obtain Audio Processor Datasheet
By obtaining the model of the ADSP-21489 audio processor, the researchers acquired the datasheet for this chip. Based on the definitions of the chip pins in the datasheet, the researchers found the JTAG-related pins and connected and tested them but found no security vulnerabilities.
“The only package with accessible pins and JTAG is the Analog Device ADSP-21489 – the rest are BGA. The JTAG connector pin-out could be determined because the datasheet and pinout were available. We used social media to identify and order the specific type of connector. We made a cable and used a variety of JTAG adapters and a logic analyser to ascertain if any security had been enabled.”
Although no security vulnerabilities were found after connecting JTAG, this exposed a serious issue regarding the implicit risks of platform solutions from suppliers.
I believe that the ADSP-21489 is a widely used audio processor because the datasheet for a chip that can be easily obtained from the internet is unlikely to be a niche product. The widespread use of such chips means that the datasheet is likely to be widely circulated. From the perspective of business cost-benefit, platform-oriented solutions can effectively reduce costs, and the higher the installation volume, the lower the marginal cost.
However, from a security perspective, such widely used platform solutions are more likely to expose risks and bring the entire vehicle’s risk management cycle forward from the vehicle model’s lifecycle to the component’s lifecycle. This means that when our vehicle models have not yet begun design, relevant risks have already been exposed because the datasheets of the components to be used have been leaked.
2.25 Third Victory in Communication Protocol: Secure Debugging Prevents JTAG Debug Access
Although successfully connecting to the audio processor’s JTAG, the researchers were unable to execute any debugging commands because unlocking JTAG requires a 64-bit password. The researchers even tried possible default passwords but failed.
“We tried JTAG commands but the VCM on the CID and IC did not respond, leading us to think that it is likely that access is prevented due to blown SoC fuses. Using the “censorship” functionality provided by the MPC56xx series, a JTAG ID elicited a response from the gateway processor. This uses 64bit password protection. We tried the default value of FEEDFACECAFEBEEF without success. We ruled out brute-forcing this; firmware could be obtained using other methods.”
2.26 Fourth Victory in Cost Warfare: Expensive JTAG Adapters Cause Attackers to Abandon Further Attacks
For JTAG, another potentially effective means is to use a special JTAG adapter, but due to the high cost of this adapter, which is about £1,200, and the researchers speculated that even if this adapter was used, the ultimate effect would not be very good, they abandoned purchasing the adapter for further attacks.
“JTAG ID elicited a response from the ADSP-21489, but it seemed to be using 64bit password protection. This proprietary protection scheme requires a specific JTAG adapter. This would cost about £1,200 and probably merely confirm that access is not possible. We believe it would be unlikely to pose any immediate security risks.”
Summary of Security Measures that Form Effective Protection
3.1 Security Measures that Successfully Repelled Attackers
In summary of the hardware attacks against Tesla, I found that the following protective measures played a good protective effect:
1) Nvidia’s protection of chip manuals
2) The packaging of the chips is mainly BGA
3) Vehicle cloud communication implements secure handshakes and VPN connections
4) VLANs are applied in Ethernet communication to divide broadcast domains
5) Secure debugging is implemented
6) Protection against entering recovery mode is implemented
3.2 Effects of Various Protective Forms
By categorizing and statistics on each technology that formed effective protection, I found that the attackers most frequently abandoned further attacks due to cost considerations. However, it should be noted that my statistical sample is limited, which can serve as a conclusion for this article but does not possess universality.
This attack case exposed many types of weaknesses, among which I believe the most serious is the leakage of chip information, making reverse reconstruction of hardware architecture and communication architecture effortless.
Other areas with exposed risks include:
1) Firmware is stored in plaintext in Flash and should be encrypted, for example, many chips provide OTF functionality, which should be enabled when available.
2) Lifecycle management of TCM is not strict, and old components circulate in the market. A complete component lifecycle management strategy should be formulated to recover old components in a timely manner during after-sales, maintenance, and scrapping to prevent outflow.
3) Slot-type SD cards can be installed and uninstalled at will, and the SD card storage content is unprotected and unencrypted.
4) SMI signals are not verified, allowing sniffing and tampering.
Reflections on Several Thorny Issues in the Construction of IoT Security
Some risks begin from the lifecycle of the chip, even before the vehicle model is born, the relevant risks have already begun to be exposed, including:
1) Datasheet and manual leakage
2) Components of the same model and platform circulating in the market
Additionally, uncontrollable aspects of the supply chain can easily lead to security shortfalls:
1) Continuation of old solutions, reuse of hardware, and software can all cause security solutions to fail to iterate and update in a timely manner.
2) The inherent lack of security capability of suppliers. In such cases, even if OEMs have security requirements, suppliers may not have the capability to implement security, resulting in security shortfalls in the products.
References
https://www.pentestpartners.com/security-blog/reverse-engineering-tesla-hardware/
KXue ID: kxliping
https://bbs.pediy.com/user-home-890008.htm
*This article is original by KXue Forum kxliping, please indicate the source from KXue Community when reprinted.
# Previous Recommendations
1. Android Strandhogg Vulnerability Reproduction Learning
2. In-Depth Analysis of a Certain APP Reinforcement Product
3. FartExt Super Evolution: Strange New ROM Tool MikRom
4. How to Read PowerShell Scripts Containing Only Special Symbols
5. Debugging Stacks and Stack Frames
6. Python_mmdt: ssdeep, tlsh, vhash, mmdthash Comparison
