Reverse Engineering an EV Charger | Hacker News Reader

Reverse Engineering an EV Charger

mnemonic.io

82 pointshoppla26 comments

> All in all, we didn’t find any critical security issues during our investigation.

> [...] we did find what appears to be Zaptec’s means of remotely debugging their devices. The first is a function called RunRemoteCommand. This passes the contents of a message received from the cloud directly to Process.Start. [...] A second interesting function called StartRemoteTunnel appears to allow Zaptec to create a reverse shell back to an SSH listener on the internet. [...]

I don't know if things have changed, but back in the day this sort of thing would be called a "backdoor". Yeah, only the manufacturer can use it, for now, but that lasts only until the manufacturer gets compromised, and either the relevant keys get leaked, or the manufacturer systems themselves get used as a jumping point.

Every time I see a 'charger' like this I'm disappointed.

This isn't a charger. It is a fancy electrical junction box. The voltage into the box and the voltage out is the same. The only function of the box is to switch the power on and off. And the car already has a switch in to switch stuff on and off anyway. So this box of expensive electronics is entirely redundant.

And they don't even provide much power - typically 32 Amps at 230 volts. Ie. about the same as a caravan hookup. But a caravan hookup doesn't need to run Linux...

You're correct it's an EVSE (EV Supply Equipment) not a "charger," but for all practical uses, the word choice doesn't really matter

It’s a safety system, a billing system, and possibly a coordination system to avoid overloading an upstream circuit. Also it’s a special fancy outlet that tells the load how much current it may use.

There’s a nice open source implementation called OpenEVSE.

>Also it’s a special fancy outlet that tells the load how much current it may use.

Isn't that the sort of thing that can typically be accomplished with nothing more than a resistor or two?

It's based on a square wave duty cycle, so you'd need something more like a '555. But yes, J1772 is designed to be dead simple and cheap to implement.

By the time you implement the rest of the protocol, you might as well have an actual microcontroller, at which point you don’t need the 555.

(Please don’t build an EVSE without the big relay and its associated safety controls. No one needs an outdoor cable supplying ~240V pin-to-pin that’s live while you hold it on a rainy day.)

Simple resistor signaling wouldn’t work for current sharing; two EVSEs with a single 40A supply [32A continuous] can advertise 32A if only one is in use and switch to 16A if both are in use. (Same concept extends to a larger pool of EVSEs which can limit to a max total current across the pool.)

Ah, okay, that is fancier than just advertising a fixed max current.

Tesla's Mobile connector supports different pigtails for the input circuit. That way it can support anything from a regular outlet (NEMA 5-15) up to something more common for an electric range (14-50).

The mobile connector detects which one based upon resistance.

As others have mentioned, this is often too simple for EVSE to Vehicle connections, as that might require the power level to be dynamic. Load sharing, limitations in supply capacity, or heat may all be potential reasons to limit available power.

Not only can you coordinate several chargers (if you are in a shared garage), but you could also coordinate usage across other devices connected to the same residential fuse box (all such in Norway has a HAN interface); for instance you could restrict the charge to the car when the dishwasher is running. (Sadly, the IEC 62196 control pilot pin seems to be a very primitive system).

> And they don't even provide much power

Typical caravan hookup here is single phase, 230V, 16A. This is ~3.5kW. Typical EVSE is 3-phase and 32A — ~22kW. That is fast enought for fully charging an EV overnight/during a working day. In fact there are plenty of EVs where AC charging is limited to 11kW. This is not a roadside fast DC charger, the application is quite different. Statistically most people charge less than 20kWh to get to the full battery in such scenarios.

> The only function of the box is to switch the power on and off

That is false. These are much more sophisticated than a mere relay. Sure, there is basic logic between vehicles and EVSEs which is basically a smart relay: https://en.wikipedia.org/wiki/SAE_J1772#Signaling

...but the electronics you mentioned are for onboard controls (energy monitoring, Time of Use enforcement, load balancing between multiple units, etc). Some EVSEs are very simple, but many -- including the one in the article -- also handle upstream communication like OCPP: https://en.wikipedia.org/wiki/Open_Charge_Point_Protocol https://www.chargepoint.com/files/OCPP-Fact-Sheet.pdf

Here is an example of integrations for the model in the article: https://zaptec.com/downloads/ZapChargerPro_Integration.pdf

There are also implementations of power line communication over the Control Pilot pin in J1772, which most people notice when charging via CCS at a DC Fast Charger, but that is not limited to L3 charging. Note that QCA7005 chip in the article: https://www.qualcomm.com/products/application/wireless-netwo...

See also: Plug and Charge https://en.wikipedia.org/wiki/ISO_15118

"Charger" is a colloquial term. Technically this is Electric Vehicle Supply Equipment (EVSE). You're right that it (usually) doesn't do anything in terms of voltage regulation, but that doesn't mean it doesn't serve a useful purpose (as others in this thread have outlined).

"All in all, we didn’t find any critical security issues during our investigation. Though there is probably room for improvement in a few areas. For example, we would have had a much harder time getting root access"

This always gets me: "secure" meaning "the manufacturer remains the owner even after selling the device".

What does getting root access have to do with security? Does the threat model include the buyer of the device? If the box is physically opened by a random person, the damage has already been done - they can mess with the electrical installation already. What's the benefit of hiding the software in that situation?

Exercise your rights as the owner and ask for the sources instead. Linux is covered by the GPL.

I'd really like to learn more about analyzing images dumped from nonvolatile memory, something which this write-up glosses over. Any resources folks would recommend?

How about the two cited references?

> Damien Cauquil held a presentation at HITB Amsterdam in 2019 that went into detail about how this process works on I.MX based processors. Lucky for us, he released a tool that removes the OOB data. It produces a binary file similar to what U-Boot or Linux would see when interacting with the NAND flash.

I did check that out, but it's a bit narrower and deeper than I'm ready for. But maybe that's sort of the point - there's not a great general-purpose way to examine device flash memories.

Not having the bootloader signed is a feature: If the company go bust, the customers can change the firmware and still use their chargers.

Having it signed would provide no value for residential customers, where the chargers ostensibly would be physically secured, and should in that case actually be considered an anti-feature.

It seems to me they just included that "recommendation" because they couldn't find anything else to write.

I'd be quite interested in the billing part.

Such a charger needs to be presented some kind of authorization, but the amount of energy transferred (and thus the amount charged) is only determined later.

Is the logic for that server-side, or is it triggered from within the charger? If the latter, could you avoid being charged by power-cycling the computer inside the charger before finishing the charge?

Probably the safer option would be for the charger to send a message like "for authorization XYZ, I've, until now, supplied 5.003kWh" every 5 seconds, then a server-side stream processor can detect the end of the charge and initiate billing.

The relay seems to be a N/O that is held closed when charging.

A reboot will stop the charging process.

This is some serious reverse-engineering. Nice work!

Chargers use an open protocol called OCPP. There are several versions, and the older ones use XML and I would guess are likely targets for various attacks. The later ones with JSON are probably also vulnerable but with a smaller number of attacks.

There are many different implementations, and different charging vendors tend to have varying degrees of functionality, so I would expect a pretty wide assortment of vulnerable chargers (and backend servers). A lot of them also seem to only communicate via static IPs.

It's a high-voltage connector, the battery charger resides in the car.

Interesting that they didn't try to brute force the shadow file.

They mentioned that the shadow file was empty before they set their own root password.

So, nothing to brute-force except the two public SSH keys, which seem (eyeballing from the length of the key) to be at least 2048 bit RSA keys.

Reply on news.ycombinator.com