BMW i3 CCS/charge port controller

[mikeselectricstuff]

That's weird - the waveforms clearly show the last byte as 0A, and this is consistent between tx and rx when trailing-edge sampling is used.
Hard to see how 09 could become 0A (1001 to 1010) unless maybe the sample rate was maginal, but even then, the clocks look clean, with jitter being well below the clock period.

Maybe once someone looks deeper into the ethernet frame structure things will become clearer. For now just be aware that there might be some data errors.

The I2SE document says the SPI frame does not include the ethernet CRC so can't use that to check

[Jack Bauer]

[EV_Builder]

That's weird - the waveforms clearly show the last byte as 0A, and this is consistent between tx and rx when trailing-edge sampling is used.
Hard to see how 09 could become 0A (1001 to 1010) unless maybe the sample rate was maginal, but even then, the clocks look clean, with jitter being well below the clock period.

Maybe once someone looks deeper into the ethernet frame structure things will become clearer. For now just be aware that there might be some data errors.

The I2SE document says the SPI frame does not include the ethernet CRC so can't use that to check

4 options; wrong mac reading by lim internal firmware, defaulting to a known generic mac address because of LIM in LIMB mode; its intentionally because who cares in a network of 2 devices and last but not least wrong capture.

My bet it is this PR didn't made it into their sprint; the 2017 LIM will be ok i bet.

(the sticker with a unique mac address is a product requirement).

[Ken_S]

Stumbled on this browsing ebay- https://www.ebay.co.uk/itm/BMW-i3-Rapid ... ontroller , part number 6135-9380352

Looking at the Munro i3 report, starting page 2093, it looks like another possible candidate for a CCS controller with suitable reversing
bmwcpc.png

After this is fully developed as a CCS solution, someone should email Sandy Munro and make him aware that his releasing of the i3 report was a contribution to the open source EV movement:)

[Jack Bauer]

Not sure if this might help getting data from saleae :
https://github.com/Marcus10110/SaleaeUt ... /tag/1.0.0

[Jack Bauer]

Looks like I could get one on these for a few days if it would help :
https://www.keysight.com/ie/en/product/ ... lyzer.html

or are we ok with the saleae?

[mikeselectricstuff]

Looks like I could get one on these for a few days if it would help :
https://www.keysight.com/ie/en/product/ ... lyzer.html

Extreme overkill, but if nothing else it would make a cool picture, in the boot at the charging station.
But you'd need to find some mains to power it - is there an AC charger nearby?

More seriously I'm not sure if it would have enough memory depth for a continuous log - AIUI the Seleae is only limited by PC memory

[davefiddes]

Well. I've made some progress. The results can be found in my fork here: https://github.com/davefiddes/BMW-i3-CCS

I've written a new tool spi2pcap.py that takes a CSV export for the Saleae Logic software and turns it into a pcap file that can be analysed in Wireshark. It's pretty crude but seems to work with the data from SPI_Caps/Part2. My repo has converted copies of those captures as pcap files you can just open. No need to wrestle with python and scapy (a pcap/packet library I use) if you just want to have a look at the files.

Looking at the captures in Wireshark is interesting. For the most part it looks like a reasonably sane set of captures. We've got IPv6 comms between the LIM MAC and the other MACs mentioned above. The major downside is that Wireshark doesn't seem to have an EXI disector so the TCP connection to the EVSE doesn't really make any sense at this point. They do seem to be talking and it's not TLS so that's something.

I think I'm seeing the signal integrity/decode problems Mike mentioned. In efcaec_startup2.pcap for example we get good bi-directional comms then half way through it flips to being only LIM originated packets but none of the corresponding replies from the EVSE (lots of TCP Ack errors in the decode). I've not investigated any further yet. Figured it was better to get what I had out there for others to look at.

Longer captures would definitely be beneficial. The Sigrok PulseView software I mentioned above would work better than Saleae Logic I think. It can do streaming SPI decodes of infinite length with the right command line incantation. I'll have a look and see if I can provide a set of step by step instructions. Sigrok works with your existing Saleae Logic HW probe.

[Jack Bauer]

Amazing stuff. Thanks Dave. Sadly Sigrok doesn't seem to support my ancient Saleae. I'll see what I can do...

[davefiddes]

Your Saleae should be fine (https://sigrok.org/wiki/Saleae_Logic) it's confusing but they use different firmware called fx2lafw which is open source rather than the proprietary Saleae firmware. The device boots over USB so you have to shutdown the Saleae Logic software and unplug before starting Sigrok to force it to load. You also have to have the fx2lafw installed (Fedora and Ubuntu have a package called sigrok-firmware-fx2lafw).

If anyone is looking at SPI decodes and trying to see if they are any good it's pretty easy to do by eye. The QCA7000 has a weird but useful framing system where they start a packet with 0xAAAA 0xAAAA and finish a packet with 0x5555 (sometimes more). MOSI is transmit and MISO is receive. My code is dumb and doesn't even bother trying to decode the rest of their SPI commands and interrupts and such.

[Jack Bauer]

Thanks Dave. Yeah I just figured that out. Trying to find how to load that firmware into the saleae now.

[davefiddes]

Thought I'd explore whether it was possible to get something out of the binary goop being sent over TCP. Tried passing it into the V2GInjector projects EXI decoder, no joy though their examples work fine. Went back and looked at Wireshark and encouraged it to try decoding the TCP stream as TLS and lo and behold it decoded fine. B*****! Because we're missing the start of the TCP connection Wireshark didn't automatically pick that up. So all comms are encrypted. I'm not sure there's much to be gained. Perhaps an SPI MiTM attack to try and force a downgrade to unecrypted? That is getting pretty wild.

[Jack Bauer]

Yeah that won't happen. Good find though Dave and thanks for the hard work. It's back to the CAN side for me.

[celeron55]

I feel so much safer charging my car when I know nobody can sniff my state-of-the-art encrypted current requests!

EDIT: That being said, does CCS allow a charger to not support TLS/SSL, so that the LIM would be forced to do plain TCP? Like a very old charger or something?

[davefiddes]

I feel so much safer charging my car when I know nobody can sniff my state-of-the-art encrypted current requests!

HomePlug is relatively easy to MiTM. Much havoc could result if it could be easily manipulated. It's not about the privacy of it.

[CCSknowitall]

Don’t give up yet.

Looks like your 2017 LIM is setting up TLS if it’s available.

Can you switch to using the 2014 LIM? That shouldn’t support TLS.

Failing that, you just need to find a station that doesn’t support TLS and capture from there.

I can’t imagine every station in your market supports TLS. Ionity is likely supporting it. Efacec I kinda doubt it.

[CCSknowitall]

Dave can you post a pcap file output (or two), I can run it through much faster than setting up python at the moment.

[CCSknowitall]

Just confirmed in my plc log of the mystery year i3 it did not ask for TLS, and only spoke DIN 70121. If you can tap your 2014 LIM, you should not see TLS packets.

[Jack Bauer]

I used the 2014 LIM at both Ionity and Efcaec chargers. Pcaps here :
https://github.com/davefiddes/BMW-i3-CC ... Caps/Part2

[CCSknowitall]

Good news- these pcaps are valid, not encrypted.

However, the efacec ones are only of the current loop, even the one labeled startup. Fortunately, what you are sending appears to be valid.

Ionity only has some homeplug frames (?), no data. Not sure what’s happening there.

I need a capture from plug in, for ~30s to a minute. You must be sending something weird in the beginning.

[Jack Bauer]

Wow! ok that's cool. The actual startup of Efcaec is Efcaec25. goes all the way from plug in to just after contactor close. I can do another batch of longer captures tomorrow now that we know the data can be read.

edit : I guess I'll need to do this on those stupid Circontrol units next

[Jack Bauer]

@davefiddles can you have a look at efcaec25? Seems very small.

[Jack Bauer]

Uh guys? So ehhh...found out why I only got 8 amps from the Tritium....... My silly prepaid access app thingy needs at least a 20 Euro balance! So as they say in America : I was outta quarters:)

[Jack Bauer]

oh it gets better! This is also why the ionity didn't work!

[Bryson]

It’s always something simple! Oh man, what a relief/frustration.