Exploiting the Emporia EV Charger: A Hacker’s Point of View

November 13, 2024
CyberThreat Research Lab
Exploiting the Emporia EV Charger: A Hacker’s Point of View

By Jay Turla (Principal Security Researcher)

As part of the team that developed challenges for VicOne and Block Harbor’s Automotive CTF, we drew inspiration from the targets at Pwn2Own Automotive 2024. Fortunately, the Zero Day Initiative (ZDI), VicOne’s co-host for Pwn2Own Automotive and partner in vulnerability discovery and disclosure, generously provided us with both an electric vehicle (EV) charger and an in-vehicle infotainment (IVI) system. We chose to focus on the EV charger first, specifically the Emporia Level 2 EV charger, as it presented a unique and intriguing challenge for an automotive-focused CTF (capture the flag) competition.

This blog post is written from a hacker’s point of view, emphasizing how exposed hardware or debug interfaces can be exploited for attacks. We ask: What does a hardware hacker see in an EV charger?

And so, let the hacking begin.

Teardown and setup

Before powering up the Emporia Level 2 EV charger, we performed a classic teardown to inspect its hardware. Notably, this EV charger was previously exploited by the researchers Tobias Scharnowski and Felix Buchmann through a buffer overflow in its Wi-Fi stack during Pwn2Own Automotive 2024.


Figure 1. Inside the Emporia Level 2 EV charger

The Emporia EV charger comes with both input and output power cables pre-attached. We’ll explore the process of powering up the device later in this write-up.

Figure 2. The Emporia Level 2 EV charger’s input and output power connectors

Figure 2. The Emporia Level 2 EV charger’s input and output power connectors

Upon spotting the ESP32 module on the board, we examined the hardware further. Referring to the ZDI security researcher Jonathan Andersson’s presentation “Electric Vehicle Chargers: Survey of Devices from Pwn2Own Automotive 2024,” at CanSecWest 2024, we quickly identified the exposed UART (universal asynchronous receiver-transmitter), a key serial or debugging interface.

Figure 3. The ESP32 microcontroller with exposed serial interfaces

Figure 3. The ESP32 microcontroller with exposed serial interfaces

Powering up the Emporia EV charger

As mentioned earlier, the Emporia EV charger comes with both input and output power cables attached to the unit. To proceed, we removed the output cable with the SAE J1772 connector, which is typically used to plug into the vehicle. We then replaced the power input cable with a three-pronged cable, enabling it to connect to a step-up/step-down transformer.

Figure 4. Replacing the power input cable with a three-pronged cable

Figure 4. Replacing the power input cable with a three-pronged cable



Figure 5. Powering up the Emporia Level 2 EV charger

With everything set up — fortunately, without any mishaps — the Emporia EV charger was now ready for benchtop experiments and security research.

Risks of exposed serial interfaces

The exposed serial programming interfaces on the Emporia EV charger’s board could enable attackers to tamper with the device, dump the firmware, extract sensitive information, gain root access via the serial interface, or modify the device to carry out additional attacks, potentially exploiting it for malicious purposes.

Connecting a UART bridge, such as the Flipper Zero, to the exposed serial interface enables access to the EV charger’s debug logs. However, we do not recommend using the Flipper Zero in development mode, as we encountered issues with dumping or flashing the firmware. A UART-to-USB converter is a more reliable option.


Figure 6. Using a Flipper Zero to act as a UART bridge

As a proof of concept, we successfully flashed a different firmware, the ESP32 Wi-Fi penetration tool, since the ESP32 module on the EV charger’s board does not perform firmware verification. This means that an attacker could easily use the esptool command line to dump or upload firmware.

Figure 7. Flashing the ESP32 Wi-Fi penetration tool

Figure 7. Flashing the ESP32 Wi-Fi penetration tool

Exploiting an EV charger to stage an attack

The ESP32, a versatile and cheap system on a chip (SoC) microcontroller, is widely used by hackers, hobbyists, and penetration testers for various projects and proofs of concepts, including:

  • Wi-Fi deauthentication attacks
  • Deploying rogue access points
  • Bluetooth attacks and spam, including iOS crash payloads
  • Creating IoT botnets capable of conducting distributed denial-of-service (DDoS) attacks
  • Other Wi-Fi exploits, such as capturing pairwise master key identifiers (PMKIDs) from handshakes

Many open-source projects related to these activities are available on GitHub. Besides the ESP32 Wi-Fi penetration tool, which is used by Wi-Fi penetration testers, there’s also the ESP32 Wifi Marauder.

In this exercise, after flashing the ESP32 Wi-Fi penetration tool, we were able to simulate Wi-Fi attacks within our own network.

Figure 8. When connecting to the ESP32 via Wi-Fi, a new interface is displayed.

Figure 8. When connecting to the ESP32 via Wi-Fi, a new interface is displayed.

Figure 9. The Emporia EV charger’s ESP32 microcontroller is now an attacker tool.

Figure 9. The Emporia EV charger’s ESP32 microcontroller is now an attacker tool.

From a hacker’s point of view, the possibilities are limitless with an exposed serial interface.

Conclusion

While the bug discovered by fuzzware.io at Pwn2Own Automotive 2024 was a stack-based buffer overflow and likely not a hardware issue, this does not diminish the broader security implications of an exposed serial interface. The vulnerability discussed here is among the OWASP Internet of Things (IoT) Top 10 2018, specifically “I10 Lack of Physical Hardening.” It was straightforward to locate the debug ports and tamper with the firmware.

Now, imagine an attacker gaining access to the same hardware, dumping the firmware, and embedding malicious code into the board. This could result in the creation of an IoT botnet capable of launching various attacks. This in turn highlights a critical issue: While hardware protection is essential, it is not sufficient on its own.

Best practices for mitigation include disabling and isolating debugging ports, implementing signature-based firmware validation, employing anti-tamper techniques, and encrypting storage systems. Assuming that firmware will remain secure without these measures is dangerously optimistic.

Once hackers gain physical access to a device, they can bypass many defenses by analyzing and modifying its firmware. Therefore, it’s important not only to protect hardware interfaces but also to implement robust measures to ensure firmware integrity and prevent unauthorized access or modification.

Our News and Views

Gain Insights Into Automotive Cybersecurity

Visit Our Blog

Accelerate Your Automotive Cybersecurity Journey Today

Contact Us