[HN Gopher] Reverse Engineering an EV Charger
___________________________________________________________________
Reverse Engineering an EV Charger
Author : hoppla
Score : 68 points
Date : 2022-11-11 17:50 UTC (1 days ago)
(HTM) web link (www.mnemonic.io)
(TXT) w3m dump (www.mnemonic.io)
| cesarb wrote:
| > 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.
| rhn_mk1 wrote:
| "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.
| mihaigalos wrote:
| This is some serious reverse-engineering. Nice work!
| zbrozek wrote:
| 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?
| krallja wrote:
| 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.
| zbrozek wrote:
| 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.
| throwawaaarrgh wrote:
| 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.
| perlgeek wrote:
| 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.
| londons_explore wrote:
| 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...
| JshWright wrote:
| "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).
| IndrekR wrote:
| > _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.
| flounder3 wrote:
| > 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
| ezfe wrote:
| 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
| amluto wrote:
| 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.
| thfuran wrote:
| >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?
| sokoloff wrote:
| 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.)
| thfuran wrote:
| Ah, okay, that is fancier than just advertising a fixed
| max current.
| [deleted]
| jsight wrote:
| 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.
| jeffbee wrote:
| 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.
| rlkf wrote:
| 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).
| pstrateman wrote:
| Interesting that they didn't try to brute force the shadow file.
| perlgeek wrote:
| 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.
___________________________________________________________________
(page generated 2022-11-12 23:01 UTC)