Vehicle Vulnerabilities
What keeps an automotive electronic control unit (ECU) secure? A lot of this depends on its main MCU’s security, so in this article Colin investigates how electromagnetic fault injection (EMFI) can bypass security of a particular automotive MCU. Knowing this will help you make smarter decisions about building a device—even with the vulnerability present.
In this article, I will be looking at some work I started last year. In particular, this was driven by an interesting article headline I read that claimed the 2020 C8 Corvette would have an “unhackable” ECU [1]. Of course, such claims are going to generate immediate interest from me! Here, I’m exploring a slightly older device to understand where vulnerabilities lie. I grabbed an ECU from a Chevrolet Silverado 2500 HD, part number 12691652. In the model number lingo of GM ECUs, this is a E41 ECU, whereas the C8 Corvette is a E99 ECU.
A photo of the main board of the E41 is shown in Figure 1 and the E99 is in Figure 2. The main difference here is the microcontroller (MCU) used. The E41 uses a NXP MPC5676R device from NXP Semiconductor and the E99 uses NXP’s MPC5777C device. The newer MPC5777C has improved security features compared to the MPC5676R, so even with that tantalizing lead-in I am not actually looking at the E99 device! Instead, I am going to be looking at (what appears to be) one generation before the E99 ECU. There is still a lot to learn about this device. I will explore how a simple fault injection attack allows bypassing of security as configured on this device. I will also examine how the security of this chip can be improved—just in case you are using it elsewhere!
The work in this article will be relevant to the MPC55xx and MPC56xx series devices from NXP. The later devices (MPC57xx) use a different architecture for the boot module, which is more complicated. In particular, the earlier devices have a pin strap that allows entry into a bootloader. This bootloader is always enabled, making it an easy target from an attack perspective, given that we can force it to execute. There is still a password to prevent easy misuse, and this password will be of interest to us. First, let’s look at the Boot Assist Module (BAM) and how it runs under normal circumstances.
BOOT ASSIST MODULE (BAM)
Most devices in the MPC55xx and MPC56xx series include the boot assist module (BAM) code, which includes a serial or CAN bootloader mode. In these devices, various pin strappings are used to enable the bootloader. There is no method of disabling the bootloader entry, as the pin strapping takes priority over internal flash. Later devices in the MPC57xx series allow ignoring of external pin strapping.
The MPC5676R and device—along with most others in the series—allow both a UART (serial) or CAN-based bootloader. Both of these bootloaders have a similar protocol, shown here:
1. Receive an 8-byte password.
2. If the password is incorrect, STOP and wait for watchdog reset.
3. Receive 8 bytes of header information, including number of bytes (N) to follow.
4. Receive N bytes of bootloader program, which will be written to SRAM.
5. Jump to SRAM bootloader.
— ADVERTISMENT—
—Advertise Here—
In order to ensure that data was received correctly, any processed data is echoed back. When using the UART bootloader, data is echoed back one byte at a time. For CAN, the echo is transmitted as a block using a different CAN-ID.
Depending on censorship and bootloader settings stored in a specific “shadow memory” address (this “shadow memory” is effectively just a separate area of FLASH), the bootloader will use one of two passwords. The first is a default (hard-coded) password of FEED FACE CAFE BEEF which is called the “public” password. If a device is censored, the bootloader can still be specified to use only the public password. In this case, internal flash access is disabled. The bootloader can also be specified to use a password from the shadow memory, which then allows flash access even for a censored device. This mode is called a “private” password, since the user can specify any arbitrary password.
This means there are three possible device configurations of interest:
1. Public Password: In this configuration, the bootloader uses the public FEEDFACECAFEBEEF password. The bootloader will only accept the public password, and disables flash access from resulting code when running in RAM. The device should, however, freely run any such code in RAM—any data left in RAM will be fully accessible, as well.
2. Flash Password: In this configuration, the bootloader uses the flash-based (private user-defined) password. The bootloader will only accept the private password, and if the password matches correctly, will allow the download of code to RAM and execution of this code. The device will allow flash access during this code execution (the censorship is “turned off”).
3. Invalid Flash Password: In this configuration, the bootloader is configured to use the flash password, but the password includes either 0x0000 or 0xFFFF. These are considered invalid passwords and the bootloader will reject any authentication attempt.
BAM POWER ANALYSIS
When does the password check happen? An easy way to verify this is to compare the password of a known-good and a known-bad example. I can configure my device with a specific password, and then examine how the power analysis differs between these two cases.
An example of this is shown in Figure 3. Here, a device has been configured with a password, and I can send either the correct or the incorrect password to the device. You can see that shortly after receiving the last byte of the password, the device goes into one of two different states. This suggests that we can insert a fault injection at that moment in time to knock it into the “wrong” state.
If we are successful, it means the device will continue to receive the rest of the downloaded file. I mentioned earlier that the algorithm will immediately stop if the password is incorrect, so it makes it easy to detect when our attack succeeds. Our objective is not just to download the data, but also to run the downloaded code. The device may receive the data, but another protection may stop it from running—or from accessing flash memory.
— ADVERTISMENT—
—Advertise Here—
BAM EM ATTACK
The attack will be demonstrated first on a purpose-build development board, shown in Figure 4. This CW308T-MPC5676R board from NewAE Technology is also used for the power analysis work previously.
The attack will concentrate on the device as configured to use a private password. This configuration is one that appears to be widely used in real-life applications. This configuration allows the device manufacturer to perform device recovery or failure analysis, as they maintain the device passwords. If the device was instead configured to be censored (and using only the public password), the device would no longer allow access to flash memory.
With the device configured with a private flash password, there are two possible attacks setups:
1. Sending the public password FEEDFACECAFEBEEF.
2. Sending an incorrect password (here we use 1122334455667788).
After each password is sent, a fault injection attack is attempted. There are six potential results from the attack:
1. No effect (password not accepted): Normal.
2. Target reset: Err-Reset.
3. Password accepted, error during code download: Err-Protocol.
4. Password accepted, code downloads, but does not start: Err-RunFail.
5. Code downloads and runs, but flash access is still disabled: Err-RunFail.
6. Code downloads and runs, printing private (flash) password: Success.
The fault injection is performed with a ChipSHOUTER EMFI tool, as you can see positioned over the device in Figure 4. It is targeted to inject the pulse around the location of where the comparison should be happening.
The results in Table 1 show that a moderate success rate can be found. Of course, we need just a single success for the attack — thus once the attack is working, even a small (less than 1%) success rate is still a win for the attacker. In practice, we can find a successful glitch in less than 10 minutes with a known setup, or within a few hours if a more complex sweep of interesting areas is required.
MOVING TO REAL LIFE
A real-life attack is shown in Figure 5. You will notice that I now have an actual ECU under the NewAE Technology ChipSHOUTER, instead of just the development board. The attack here is similar—I am again using the serial (UART) bootloader, in this case taken off of one of the chips on the board that interfaces to those pins.
The results in Table 2 show that it is similarly successful. Therefore, the complete attack chain works on both the developmental board and the real-life ECU. This means that there is potential for an attacker to read/write the flash memory, even if it is disabled with the vendor-specific settings.
When I enumerated possible device configurations, one of them was with a public (known) password. In this state, the device is censored (flash access disabled), but configured to use the public password. There is no way to unlock the device in this state. Vendors may dislike this because they cannot perform failure analysis on returned units for example.
All that said, the previous EMFI attack was unsuccessful in this configuration. Note that because the device is listening for the public password, we performed most of the search using the 1122334455667788 password. When the device receives the public password, the actual download of the BAM image is slow (approx. 45 seconds), which slows down the search process substantially. When using the public password, you are unaware of whether the attack was successful or not until the BAM image runs. Compared to the situation where we can gauge attack success by seeing the device accept the password, requiring the full BAM download is a much slower search.
FALSE POSITIVES
You will notice that I validate that the actual attack was successful (printed the secret password). A quicker test would be to simply validate that the password is accepted, and assume that the accepted password will allow device access.
We discovered that this raises a high likelihood of false positives. In fact, it appears that performing an EMFI attack on the device before it has finished echoing the password causes the device to look for the public password, instead of the private password. The device does remain censored, meaning that the attack is not truly successful. Using a simple reporting process would have given a false positive about our attack success rate!
As demonstrated by these results, configuring the device as censored with a public serial password seems to provide the most robust protection against fault injection attacks. For the MPC5676R, the (unused) private password should be set to a non-default value to ensure a fault injection campaign would need at least two successful faults. Using an invalid value will make it more difficult to access the device via JTAG. This may introduce other attack vectors (because the attacker now can read/write SRAM), so switching to this mode must be done with great caution.
— ADVERTISMENT—
—Advertise Here—
CONCLUSIONS
EMFI is a practical way of performing attacks. This article demonstrates that we can take lessons learned from a development board and transfer them to real devices. This will prove useful when developing new products because it will often be easier to perform testing on development boards than on a final product. If you are able to identify specific problems early on, you can make the correct decisions when it comes to product design.
If you happen to be using the specific family I talked about in this article (hello, automotive readers!), you can use some of these hints. I also have results in a published article that is at https://eprint.iacr.org/2020/937 [2]. 
RESOURCES
References:
[1] https://www.hotcars.com/mid-engine-corvette-ecu-encryption/
[2] “BAM BAM!! On Reliability of EMFI for in-situ Automotive ECU Attacks” by Colin O’Flynn
https://eprint.iacr.org/2020/937
NewAE Technology | www.newae.com
NXP Semiconductors | www.nxp.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • NOVEMBER 2020 #364 – Get a PDF of the issue
Sponsor this Article
Colin O’Flynn has been building and breaking electronic devices for many years. He is an assistant professor at Dalhousie University, and also CTO of NewAE Technology both based in Halifax, NS, Canada. Some of his work is posted on his website (see link above).
